Itt gyakorlati helyzetem van, a cégem FTP szerver szolgáltató néhány ügyfelek. Az ügyfelek megosztják fájljaikat a FTP szerverünkön, és eddig nem volt problémájuk a hozzáférés-kezeléssel és az adatvédelmi irányelvekkel.
Nemrégiben ügyfeleink titkosítani akarják fájlok egy okból: “ Nem akarják, hogy az FTP szerver rendszergazdája hozzáférjen a fájljaikhoz “.
Cégünk emellett digitális aláírással kívánja javítani az FTP hitelesítési módszerünket. Tudom, hogy PGP titkosítást is megvalósíthatunk fájlok FTP szerverre történő elküldéséhez, de a probléma az, ha a titkosított fájlok érkeznek, azokat a szerver a saját kulcsával dekódolja és az Adminisztrátornak teljes hozzáférése van ezekhez a fájlokhoz.
A nyilvános kulcsú infrastruktúra telepítésével minden ügyfélnek intelligens kártyával kell rendelkeznie ahhoz, hogy digitális aláírással bejelentkezhessen az FTP-kiszolgálóra. De ez nem ügyfeleink számára lehetséges a fájlok titkosítása a vevő nyilvános kulcsa alapján. Mert előfordulhat, hogy több fájl címzett van, és egyetlen fájlt kell titkosítani több tucat nyilvános kulcs segítségével, ami örökké tart!
Tehát, a kérdésem a következő: “ Van-e megoldás az FTP-kiszolgálón található fájlok titkosítására, amely ebben a helyzetben telepíthető? ” Minden segítséget nagyra értékelünk.
Megjegyzések
- Nem a válasz a kérdésedre, de egyáltalán nem szabad használnod az FTP-t, mert az FTP jelszót egyértelműen továbbítják. Ahogy a theterribletrivium válaszában mondja, használjon titkosított átviteli protokollt. Ez valami olyasmi lehet, mint az SCP, az FTPS vagy az SFTP.
- BobBrown és Steffan Ullrich is halott állapotban vannak. Steffen megválaszolja az aktuális kérdést, de Bob jó észrevételt tesz. Vagyis az ügyfeleknek felelősnek kell lenniük a titkosításért. Az olyan archiválók, mint a 7-zip, lényegtelenné teszik a titkosított archívumok létrehozását, tömörítve vagy sem. Ez a Pythonon vagy esetleg a PHP-n keresztül is szkriptelhető az ‘ kliens feltöltési rutinjának részeként. Ami BobBrown ‘ pontot illeti – ha ügyfelei érzékenynek tartják, akkor biztosan nem szabad FTP-t használniuk. A titkosított alternatíva határozott igény ebben a helyzetben.
- @BobBrown Igen, amint említettem, PK-engedélyezett funkciókat fejlesztünk a bejelentkezési szolgáltatásunkhoz. Tehát nincs jelszóátvitel, a hitelesítéshez digitális aláírásunk van.
- Az ügyfeleknek valóban titkosítaniuk kell, és pl. Az SSH-t az FTP helyett szintén nem ‘ ta rossz ötlet. Érdemes azonban egy pillantást vetni a Zéró tudású szolgáltatások fogalmára: hu.wikipedia.org/wiki/Zero_knowledge
- Ha jól értem az A23149577 ‘ s kérdést, akkor a kérdés a következő: Van-e olyan FTP (akár FTPS, akár SFTP) szerver szoftver, amely képes titkosítani a bejövő adatfolyamot lemezre és visszafejteni a kimenő adatfolyam lemezről felhasználóra, így az FTP Server szoftvert futtató rendszer helyi felhasználói nem férhetnek hozzá a lemezen lévő ügyfél ‘ adatokhoz. Ez egy jogos kérdés, amelyre nem ad választ, ha az adattitkosításért felelősséget az ügyfélre dobják, vagy az A23149577 ‘ s munkafolyamatot áttervezik. Az erre adott pozitív válasz előnyei a kezelés automatizálásának megkönnyítése
Válasz
Nemrégiben ügyfeleink titkosítani akarják fájljaikat egy okból: “Nem akarják, hogy az FTP szerver rendszergazdája hozzáférjen a fájljaikhoz”.
Ennél a követelménynél a titkosítást nem szabad a szerver oldalon végrehajtani . Ellenkező esetben egy rendszergazda csak megragadhatja a tartalom, mielőtt titkosításra kerül. És természetesen a jelszavak / kulcsok kezelésének is csak az ügyfél számára kell elérhetőnek lennie.
Ez csak titkosítást hagy az ügyfél oldalán. Számos megoldás létezik rá, például jelszóval védett archívumok stb. Vagy lehetne használni a PGP-t, és segíteni az ügyfeleket egy privát PGP kulcsszerver felállításával a nyilvános kulcsok cseréjének megkönnyítése érdekében. Magának a kulcsnak természetesen magát az ügyfélnek kell generálnia, a magánkulcsot pedigaz ügyféloldal.
Megjegyzések
- Köszönöm válaszát, tudom, hogy a titkosítást kliens oldalon kell végrehajtani, és a jelszóval védett tömörítés a legegyszerűbb helyzet itt. Automatikusabb megoldásokkal akartam előállni, amelyek nem használnak szimmetrikus titkosítást és például e-mailen keresztüli kulcscserét.
- Az ügyfelek bevált aszimmetrikus titkosítást is használhatnak, mint például a PGP. Ebben az esetben csak a nyilvános kulcsot kell megkapniuk a társaktól egy fájl megosztásához.A nyilvános kulcsok megosztásának megkönnyítése érdekében beállíthat egy kulcskiszolgálót, de a kulcsok generálását és a szerveren való közzétételt az ügyfélnek újra meg kell tennie, hogy biztonságban lehessen a magánkulcs.
- Úgy gondolom, hogy ez a megoldás a legjobb, mert ebben a modellben már nem aggódunk a szimmetrikus kulcscsere miatt az ügyfelek között. Köszönöm a válaszod
- Én ‘ hozzáadtam az ötletet a válaszhoz.
Válasz
Azt javaslom, hogy az ügyfelek kezeljék a saját titkosítási jelszavukat vagy tanúsítványaikat. Bizonyos FTP-ügyfelek példaként engedélyezik a titkosítás használatát: http://www.coreftp.com/docs/web1/FTP_Encryption.htm . Szeretnék azonban megbizonyosodni arról, hogy valóban valamilyen típusú titkosítást használ-e az adataik továbbításához. Nem említi, és mivel a vanília FTP alapértelmezés szerint nem használja a titkosítást, biztos akarok lenni abban, hogy ez a rész is lefedett legyen .
Megjegyzések
- Valójában a jelenlegi FTP-kiszolgálónk SSH-kapcsolatot használ, és ‘ szinte biztonságos, de mint említettem, a digitális aláírással és a nyilvános kulcsú infrastruktúrával történő hitelesítés felé haladunk, amely segít biztonságosabbá tenni a bejelentkezési rendszerünket. Lehet, hogy valamilyen ügyes SFTP-t kell megvalósítanunk a helyzetünkhöz.