Dotaz: VPS - súkromie - bezpečnosť

[euroPacific]

Zaujímalo by ma či keď si na svoj VPS umiestnim nejaké súkromné dokumenty obchodné tajomstvá, nápady atď, ktoré by mohla potencionálna konkurencia zneužiť, či mi hrozí že sa k nim dostane aj administrátor toho cloudu. Či sa admin dokáže prihlásiť do môjho VMware image a robiť si tam či chce?

Ak áno akým spôsobom tomu čo najviac zamedziť? (Nemyslím teraz šifrovať každý dokument zvlášť)

Kde mám istotu že admin nevie moje administrátorské heslo? Heslo som zadával do nejakého formulára v setupe toho cloud-hostingu. Čo ak sa uložilo ako plaintext? Keď si ho zmením znížim tým šancu že sa mi tam bude admin prihlasovať? Viem že kto chce ten si vie dáta nejakým spôsobom vyextrahovať (ak neni zašifrovaný celý disk) ale to už zaberie nejaký čas a keď má niekto pod palcom 1000ky VPS tak prečo by to robil práve na mojej?

A má vôbec admin takejto služby v EU právo hrabať sa v cudzom VPS?

Odpovědi

[Jendа]

či mi hrozí že sa k nim dostane aj administrátor toho cloudu. Či sa admin dokáže prihlásiť do môjho VMware image a robiť si tam či chce?

Ano.

Ak áno akým spôsobom tomu čo najviac zamedziť?

Nelze.

Kde mám istotu že admin nevie moje administrátorské heslo?

Admin především vidí obsah paměti a může libovolně manipulovat s kódem, který virtualizovaný procesor vykonává. Administrátorské heslo ho vůbec nezajímá.

Viem že kto chce ten si vie dáta nejakým spôsobom vyextrahovať (ak neni zašifrovaný celý disk)

A když je, tak si může přečíst klíč z paměti. A když ho nějak obfuskuješ aby to nešlo najít triviálně dostupnými forenzními nástroji, tak infikuje běžící procesy. Atd.

a keď má niekto pod palcom 1000ky VPS tak prečo by to robil práve na mojej?

Nejspíš to opravdu dělat nebude. Buď to nebude dělat vůbec (nezajímáš ho), nebo to nebude dělat ručně (jede v nějaké větší konspiraci a má nástroj který všechny dostupné VPSky vytěží automaticky, obsah souborů zaindexuje a pak v něm může vyhledávat).

[euroPacific]

Ďakujem toto som potreboval vedieť.

[R]

Vzhladom na mnozstvo dier v HW aj SW, ktore sa neustale objavuju, moze byt administratorom viac ludi, ktori o sebe ani nemusia vediet :D A vobec nemusia byt z EU.

[Vantomas]

Řešením by mohlo být soubory šifrovat už u sebe a na VPS ukládat šifrovaná data. Třeba Nextcloud má podporu pro end2end šifrování, kdy server nemá přístup k datům a de/šifrování probíhá u klientů.

[j]

To je uplne jedno ... provozovatel, potazmo ten kdo se k verenym/uniklym datum dostane, ma neomezene mnoho casu na desifrovani. A nemusi to ani delat bruteforcem, staci si rok, dva, mozna tri pockat, az se najde nejaka dira v pouzitym algoritmu.

[LarryL]

Neomezeně času nemá nikdo a pokud se k datům dostane útočník (možná) až za pár let, tak je to menší zlo, než když se dostane k aktuálním dokumentům.

[j]

Ty vis tak leda kulovy o tom k jakym datum se dostane nebo nedostane, protoze si mu je proste dal a tim si zcela zratil jakoukoli kontrolu nad tim, co se snima deje. Zadny mensi nebo vetsi zlo pak neexistuje.

[LarryL]

Bavím se o variantě co napsal Vantomas, tzn. soubory šifrovat už u sebe a na VPS ukládat šifrovaná data. Sice jsem ztratil možnost co se s daty děje, ale pořád vím, že útočník má hodně stíženou práci. Pokud se mu k dešifrovaným datům podaří dostat za pár let, tak je to menší zlo, protože ty data (např. hesla, živé právní spisy atd.) už nemusí být vůbec aktuální. Pokud bude šifrování udělané dobře a nedochází k žádné výměně klíčů mezi localem a VPS, tak by se útočník (administrátor VPS) k dešifrovaným datům nikdy dostat neměl (když nepočítám budoucí éru kvantových počítačů, které asi dokáží dešifrovat většinu dnes šifrovaných dat).

[PetebLazar]

Pozn. Již dnes jsou snad dostupné šifrovací algoritmy záměrně navržené právě s ohledem na schopnosti kvantových počítačů.

[Jendа]

Především se bavíme o symetrickém šifrování, kde se u naprosté většiny algoritmů aktuálně jedná o „zkrácení klíče na polovinu“, takže AES-256 bude 128 a to je furt dostačující.

[Jendа]

staci si rok, dva, mozna tri pockat, az se najde nejaka dira v pouzitym algoritmu

Na který nejnovější symetrický algoritmus je znám offline útok? Podle mě jediný takový případ je bruteforce na DES a o tom se píše už v Kukaččím vejci od Stolla z roku 1990.

[Jendа]

OK, ještě mě napadl related key útok na RC4 (cca. rok 2000), které se ale mám pocit k šifrování disku moc nepoužívalo, používalo se především na síti.

[j]

Vetsinu ti napsal Jenda, ale je tu jeste jeden aspekt, provozovatel VPS bude nejspis nejaka firma/organizace, ktera jich bude provozovat stovky, tisice, nebo i stovky tisic ... a jako takova je daleko zajimavejsim cilem utoku, nez nejakej tvuj domaci NAS.

Jinak receno, pokud nepatris mezi 95% pitomcu, ktery nejsou schopny dodrzovat/nechat si nastavit/... alespon zakladni bezpecnostni pravidla, je velice nepravdepodobny, ze prave tvuj stroj nekdo napadne. Jednoduse proto, ze pokud se mu to nepovede nejakym toolem zkousejicim znamy diry, tak rozhodne nebude utocit specielne na tvuj stroj. Kdezto na stroje v nejakym cmoudu se mu vyplati investovat do utoku mnohem vic casu, potazmo penez.

Az tu zas nekdo prijde s argumentaci o profesionalech administrujicich cmoudy, tak aktualne trebas ... Avast.

[PetebLazar]

Neměla by požadovaného být schopna virtualizace s využitím technologií SEM/SEV v procesorech EPYC? Jestli jsem to pochopil správně, tak GuestVM může být šifrován klíči kterými disponuje pouze SecureProcessor (čitelná přidělená RAM je dostupna pouze z contextu GuestVM) nikoli z Hypervisoru či HostOSu (z pohledu administrátora HW/OS/HPV by tedy mělo jít o zašifrovanou paměť .. síly AES 128bit). Samozřejmě by to předpokládalo z GuestVM na storage ukládat/číst obsah zašifrovaně. První generace EPYC měla klíčů pouze 15, nová generace EPYC 7002 má podporovat snad až 509 samostatných klíčů.

https://en.wikichip.org/wiki/x86/sme https://en.wikichip.org/wiki/x86/sme#Secure_Encrypted_Virtualization

[PetebLazar]

Vypadá to, že si to již našlo cestu do KVM. Takže se to v rámci konkureční výhody možná časem dostane i do nabídek VS hostingů. https://github.com/AMDESE/AMDSEV/blob/master/README.md#intro

Dokonce to vypadá, že je v rámci HW řešeno zastavení VM (díky SEV-ES dojde k zašifrovaní stavu registrů, v rámci předejití úniků dat zkrze ně). https://developer.amd.com/sev/

[snajpa]

Tohle cloveka ochrani proti sousedum, ale root si vzdycky bude moct ty klice precist, protoze je tam musi nejdriv zavest, aby to QEMU mohl pustit...

[Jendа]

Já jsem to pochopil tak, že ti poskytoval spustí virtuálku, procesor si pro ni vygeneruje náhodný klíč a drží si ho v sobě, a virtuálka se ti pak umí prokázat že je to opravdu neporušená virtuálka spuštěná tímto způsobem.

[snajpa]

Aha, a jo... to vypada hodne solidne. Uz se tesim na dalsi nakup HW, AMD je uplne jasna volba

[PetebLazar]

Intel by měl mít něco podobného, ale údajně jde v návrhu podstatně dál s možnostmi jako sdílené klíče, vícenásobné klíče (granulace snad až na úroveň TLB). Otázkou je zda se to někomu povede úspěšně implementovat.

[Peter Golis]

A budú tie kľúče v TPM?

[PetebLazar]

Tady je pojetí Intelu vcelku obrazně vysvětleno. https://www.linux-kvm.org/images/d/d7/Mktme_kvm_forum_2018.pdf

[včera 21:08 j]

To bych chtel videt, jak budes implementovat ... specielne kdyz virtualni stroje jsou proto virtualni, ze se presunuji (za behu) z jednoho HW na jiny HW => musi se presunout uplne vse, vcetne obsahu pameti, pripadne registru CPU. Jinak receno, spravce si klidanko muze jen tak mimochodem vytvorit trebas dokonaly klon, a muze si snim pak delat co chce. Virtualni stroj se pak typicky da trebas "pauznout", coz na HW bezne nejde, da se z nej udepat snapshot atd atd. To vse znamena, ze se na disk, pripadne po siti, presunuje kompletni aktualni stav toho stroje. Pochopitelne vcetne vsech klicu.