Ik heb hier een praktische situatie, mijn bedrijf is voor sommigen een FTP serverprovider klanten. De klanten delen hun bestanden op onze FTP server en hebben tot dusver geen problemen gehad met toegangsbeheer en privacybeleid.

Sinds kort willen onze klanten hun bestanden versleutelen. bestanden om één reden: “ Ze willen niet dat de FTP-serverbeheerder toegang heeft tot hun bestanden “.

Ons bedrijf wil ook onze FTP-authenticatiemethode verbeteren met digitale handtekening. Ik weet dat we PGP-codering kunnen implementeren voor het verzenden van bestanden naar de FTP-server, maar het probleem is dat wanneer gecodeerde bestanden worden ontvangen, ze door de server worden gedecodeerd met de bijbehorende privésleutel en vervolgens heeft de beheerder volledige toegang tot die bestanden.

Door de implementatie van Public Key Infrastructure heeft elke client een smartcard nodig om met een digitale handtekening op de FTP-server in te loggen. Maar dat is het niet mogelijk voor onze klanten om hun bestanden te versleutelen op basis van de publieke sleutel van de ontvanger. Omdat er een situatie kan zijn dat er meerdere bestandsontvangers zijn en men een enkel bestand moet coderen met tientallen openbare sleutels, wat een eeuwigheid duurt!

Mijn vraag is dus: “ Is er een oplossing voor het versleutelen van bestanden op de FTP-server die in deze situatie kan worden ingezet? ” Alle hulp wordt zeer op prijs gesteld.

Opmerkingen

  • Dit is niet het antwoord op uw vraag, maar u zou FTP helemaal niet moeten gebruiken omdat het FTP-wachtwoord ongecodeerd wordt verzonden. Gebruik, zoals theterribletrivium in een antwoord zegt, een gecodeerd overdrachtsprotocol. Dat zou zoiets zijn als SCP, FTPS of SFTP.
  • BobBrown en Steffan Ullrich zijn allebei dood. Steffen beantwoordt je eigenlijke vraag, maar Bob heeft een goed punt. Dat wil zeggen dat de clients zelf verantwoordelijk moeten zijn voor codering. Archivers zoals 7-zip maken het eenvoudig om versleutelde archieven te maken, al dan niet gecomprimeerd. Dit kan ook worden gescript via Python of mogelijk PHP als onderdeel van de client ‘ uploadroutine. Wat betreft BobBrown: ‘ s punt – als uw klanten het als gevoelig beschouwen, zouden ze zeker geen FTP moeten gebruiken. Een gecodeerd alternatief is in deze situatie absoluut nodig.
  • @BobBrown Ja, zoals ik al zei, we zijn PK-Enabled-functionaliteit aan het ontwikkelen voor onze inlogservice. Er is dus geen wachtwoordoverdracht, we hebben een digitale handtekening voor authenticatie.
  • Uw klanten zouden het inderdaad zelf moeten coderen, en bijvoorbeeld SSH gebruiken in plaats van FTP, ook ain ‘ een slecht idee. U kunt echter het concept van Zero-Knowledge-services bekijken: en.wikipedia.org/wiki/Zero_knowledge
  • Als ik de vraag A23149577 ‘ s correct begrijp, is de vraag bedoeld: Is er FTP-serversoftware (of het nu FTPS of SFTP is) die de inkomende gegevensstroom naar schijf kan versleutelen en ontsleutelen de uitgaande gegevensstroom van schijf naar gebruiker zodat lokale gebruikers van het systeem waarop de FTP-serversoftware draait, geen toegang hebben tot de gegevens van de klant ‘ op schijf. Dit is een legitieme vraag die niet wordt beantwoord door de verantwoordelijkheid voor gegevenscodering bij de klant te leggen of door de workflow van de A23149577 ‘ opnieuw te ontwerpen. De voordelen van een positief antwoord hierop zijn het vergemakkelijken van het automatiseren van de afhandeling.

Answer

Onlangs wilden onze klanten hun bestanden versleutelen om één reden: “Ze willen niet dat de FTP-serverbeheerder toegang heeft tot hun bestanden”.

Met deze vereiste mag de codering niet aan de serverzijde worden gedaan . Anders zou een beheerder gewoon kunnen grijpen de inhoud voordat deze wordt versleuteld. En natuurlijk moet het beheer van de wachtwoorden / sleutels ook alleen toegankelijk zijn voor de klant.

Dit laat alleen versleuteling over aan de kant van de klant. Er zijn verschillende oplossingen voor, zoals met wachtwoord beveiligde archieven enz. Of men zou PGP kunnen gebruiken en klanten kunnen helpen door een privé PGP-sleutelserver in te stellen om de uitwisseling van openbare sleutels gemakkelijker te maken. De sleutels zelf moeten natuurlijk door de cliënt zelf worden gegenereerd en de privésleutel moet opaan de clientzijde.

Opmerkingen

  • Bedankt voor uw antwoord, ik ben me ervan bewust dat de codering aan de clientzijde moet gebeuren en dat wachtwoordbeveiligde compressie de meest eenvoudige situatie hier. Ik was van plan om meer automatische oplossingen te bedenken die geen symmetrische versleuteling gebruiken en geen sleutel uitwisselen via e-mail bijvoorbeeld.
  • Cliënten kunnen ook bewezen asymmetrische versleuteling gebruiken, zoals PGP. In dit geval hebben ze alleen de openbare sleutel van de peer nodig om een bestand te delen.Om het delen van openbare sleutels te vergemakkelijken, kunt u een sleutelserver instellen, maar het genereren en publiceren van sleutels op de server moet opnieuw door de client worden gedaan om de privésleutel veilig te houden.
  • Ik denk dat deze oplossing de beste is, omdat we ons in dit model geen zorgen meer maken over symmetrische sleuteluitwisseling tussen clients. Bedankt voor je antwoord
  • Ik ‘ heb het idee aan het antwoord toegevoegd.

Antwoord

Mijn suggestie is om uw klanten hun eigen versleutelingswachtwoord of certificaten te laten beheren. Bepaalde FTP-clients staan het gebruik van codering toe, bijvoorbeeld: http://www.coreftp.com/docs/web1/FTP_Encryption.htm . Ik wil er echter zeker van zijn dat je daadwerkelijk een soort codering gebruikt voor de overdracht van hun gegevens. Je vermeldt het niet en aangezien vanilla FTP standaard geen codering gebruikt, wil ik zeker weten dat dat deel ook wordt gedekt .

Reacties

  • Eigenlijk gebruikt onze huidige FTP-server een SSH-verbinding en is ‘ bijna veilig, maar zoals ik al zei, gaan we over op authenticatie via digitale handtekening en openbare sleutelinfrastructuur die ons helpt ons inlogsysteem veiliger te maken. Misschien moeten we echter een soort van aangepaste SFTP voor onze situatie implementeren.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *