Ochrona danych o krytycznym stopniu poufności

Tomasz Klim

Są tacy klienci, dla których optymalizacja wydajnościowa jest drugorzędna, natomiast aspektem absolutnie krytycznym i priorytetowym jest poufność danych. Poufność idąca o wiele dalej, niż są w stanie zapewnić standardy takie jak choćby PCI DSS stosowany przez instytucje finansowe.

Poufność, której naruszenie może się zakończyć zapłatą potężnych kar finansowych, pobytem w więzieniu, a nawet śmiercią lub kalectwem.

Dla takich klientów przygotowaliśmy specjalną ofertę budowy chmur prywatnych o podwyższonej poufności działania, z pełną izolacją sieciową i opcjonalnie routingiem TOR, wyposażonych w killswitche i inne mechanizmy zabezpieczające przed przejęciem danych przez wrogie służby. Szczegóły cenowe możesz znaleźć w naszym cenniku usług.

Poniżej zaś znajdziesz nasze wewnętrzne wytyczne w zakresie obsługi szyfrowanych dysków twardych w systemach Linux, oraz innych aspektów zapewniania klientom poufności. Są to wytyczne podstawowe, natomiast z każdym klientem ustalamy wytyczne szczegółowe, głównie w zakresie konkretnych procedur obsługi kluczy szyfrujących.

Komunikacja z klientem

W Polsce każda osoba może być wezwana do złożenia zeznań w roli świadka (również w drodze tzw. pomocy prawnej dla służb innego kraju). Świadek w myśl polskiego prawa nie może odmówić zeznań, nawet gdyby miały obciążyć jego klienta, dlatego też współpracując z klientami stosujemy zasadę "nie pytaj, nie mów", w myśl której klient nie powinien przekazywać nam żadnych informacji odnośnie charakteru poufnych danych (my zajmujemy się wyłącznie obsługą infrastruktury IT i wiedza nt. charakteru danych oraz usług w warstwie aplikacyjnej nie jest nam potrzebna).

Procedury techniczne

Rozważasz konkurencyjne oferty? Zapytaj wszystkich potencjalnych dostawców o standardy postępowania z poufnymi danymi, a będziesz miał jasność, komu najbezpieczniej zaufać.

Szyfrowanie i obsługa zaszyfrowanych dysków twardych

1. Szyfrowanie dysku rozruchowego:

szyfrowanie powinno być realizowane za pomocą technologii LUKS i narzędzi zawartych w systemie operacyjnym, nie wolno używać niestandardowego oprogramowania (jest to dopuszczalne tylko dla Windows)
szyfrowanie powinno być skonfigurowane na etapie instalacji systemu operacyjnego
hasło do odszyfrowania dysku powinno mieć przynajmniej 250 bitów entropii (małe i duże litery, cyfry, 60 znaków lub więcej) i nie powinno być nigdzie zapisywane w formie jawnej - tylko i wyłącznie w programie do zarządzania hasłami, np. KeePass

2. Uruchamianie systemów z zaszyfrowanym dyskiem rozruchowym:

w miarę możliwości dysk powinien być odszyfrowywany ręcznie za pomocą fizycznego monitora i klawiatury lub konsoli KVM (dla serwerów fizycznych), bądź konsoli hiperwizora (dla serwerów wirtualnych)
w pozostałych przypadkach system operacyjny powinien mieć zainstalowany serwer Dropbear pozwalający na zdalne odszyfrowanie dysku i start systemu; Dropbear powinien mieć inny klucz ssh hosta od docelowego systemu

3. Szyfrowanie dysków z danymi:

szyfrowanie powinno być realizowane za pomocą technologii LUKS bądź loop-aes i narzędzi zawartych w systemie operacyjnym, nie wolno używać niestandardowego oprogramowania (spoza repozytoriów dla danej dystrybucji)
sposób generowania kluczy i haseł określa odrębna procedura, ustalana osobno dla każdego klienta
klucze i hasła powinny być przechowywane tylko i wyłącznie na maszynach, które mają mieć dostęp do konkretnych dysków, oraz w kontenerze KeePass

4. Dostęp do odszyfrowanych dysków z danymi:

należy unikać podłączania i odszyfrowywania dysków z danymi na maszynach będących hostami OpenVZ (z wyjątkiem dysków zawierających kontenery OpenVZ przeznaczone do uruchamiania na danej maszynie)
nie wolno podłączać i odszyfrowywać dysków z danymi na maszynach będących hostami LXC (z wyjątkiem dysków zawierających kontenery LXC przeznaczone do uruchamiania na danej maszynie)
nie wolno podłączać i odszyfrowywać dysków z danymi na maszynach bez szyfrowania dysku rozruchowego
nie wolno eksportować zawartości odszyfrowanych dysków z danymi przez NFS

Zasilanie serwerów z szyfrowanymi dyskami twardymi

1. Wymagania dla maszyn z zaszyfrowanym dyskiem rozruchowym, lub ze stałym dostępem do zaszyfrowanych dysków z danymi:

zasilanie takich maszyn musi być rozłączalne za pomocą pojedynczego wyłącznika sprzętowego ("killswitcha"), również w przypadku maszyn z redundantnymi zasilaczami
forma i lokalizacja wyłącznika powinna być tak dobrana, aby umożliwić dyskretne (kilkoma prostymi ruchami ciała, bez zachowań mogących budzić podejrzenia) rozłączenie zasilania i wyłączenie wszystkich maszyn w strefie zagrożenia w przypadkach określonych odrębną procedurą

Zaufanie do serwerów poza fizyczną kontrolą klienta

1. Wymagania dla maszyn z zaszyfrowanym dyskiem rozruchowym, lub ze stałym dostępem do zaszyfrowanych dysków z danymi:

każdy taki serwer powinien pełnić (na własne potrzeby) role MTA i centralnego sysloga, jak również być samowystarczalny pod każdym innym względem
na serwerze powinny być monitorowane wszystkie zdarzenia fizyczne, których monitoring jest wykonalny w danej wersji systemu operacyjnego (za pomocą demonów udevd, acpid i innych)
nieuzgodnione z obsługą Data Center wyłączenie lub reset serwera, w szczególności poprzedzone występowaniem innych zdarzeń (np. wpięciem urządzenia do portu USB), należy traktować jako kompromitację serwera
architektura świadczonych usług i backupu danych na takich serwerach powinna być przygotowana na możliwość kompromitacji serwera (a nawet wszystkich serwerów w danej lokalizacji) w dowolnym momencie (mechanizm tzw. failover)

2. Obsługa skompromitowanych maszyn:

kompromitacja serwera najczęściej jest równoznaczna z przejęciem lub próbą przejęcia serwera przez służby prawne, krajowe lub zagraniczne (np. Policja, FBI)
nie wolno zdalnie odszyfrowywać dysku rozruchowego ani dysków z danymi na skompromitowanej maszynie
dopuszczalne jest jedynie pozyskanie (w dowolny sposób) kopii dysków twardych ze skompromitowanej maszyny i uruchomienie takiej maszyny lokalnie, w środowisku całkowicie odseparowanym od sieci, celem odzyskania danych; uruchomiona w ten sposób maszyna nie powinna być już nigdy podłączana do sieci

Ten artykuł jest częścią naszej misji wyrównywania szans przeciętnego człowieka w starciu z korporacjami i służbami obcych państw, działającymi z pozycji siły. Zobacz także pozostałe dotychczas opublikowane artykuły na ten temat:

Tomasz Klim
Administrator serwerów i baz danych, specjalista w zakresie bezpieczeństwa, architekt IT, przedsiębiorca. Ponad 20 lat w branży IT. Pracował dla największych i najbardziej wymagających firm, jak Grupa Allegro czy Wikia. Obecnie zajmuje się bezpieczeństwem projektów blockchainowych w Espeo Software. Chętnie podejmuje się ciekawych zleceń.