Jak bezpiecznie przenieść się do chmury – szyfrowanie danych w locie i w spoczynku

Jedną z najczęściej przez nas spotykanych obaw przed migracją do chmury jest troska o poufność przechowywanych tam informacji. Na szczęście jest to problem, który pomaga rozwiązać odpowiednio użyta kryptografia.

Mechanizmy kryptografii stanowią bardzo uniwersalne narzędzie osiągania poufności (ochrona przed nieautoryzowanym dostępem), integralności (spójności – ochrona przed nieautoryzowanymi zmianami), uwierzytelnienia (potwierdzenie zadeklarowanej tożsamości) czy niezaprzeczalności (ochrona przed zaprzeczeniem wykonania operacji). O ich wykorzystaniu w procesie uwierzytelnienia wspomniałem w jednym z poprzednich odcinków cyklu.  W tym skupię się na zastosowaniu ich do ochrony danych przechowywanych (data at rest)  i w trakcie przesyłu (data in transit) w chmurze.

Cykl artykułów

Artykuł jest częścią zaplanowanego na cały rok cyklu artykułów oraz webinarów sponsorowanych przez firmę Aruba Cloud – dostawcę usług chmurowych z centrum przetwarzania w Polsce. Przed nami jeszcze cztery artykuły i kilka webinarów, a w poprzednich poruszone zostały zagadnienia:

• • architektura modelu cloud computingu wg NIST SP 800-145,
  • ryzyka natury organizacyjno-prawnej i zarządzania zgodnością na przykładzie pojęcia GRC – Governance, Risk management and Compliance,
  • standardy bezpieczeństwa, jakie powinna spełniać usługa chmurowa i jak możemy sprawdzić, czy te standardy faktycznie spełnia,
  • zarządzanie tożsamością w chmurze i standardy SAML, OpenID, OAuth,
  • wdrożenie i zarządzanie uprawnieniami w chmurze,
  • przygotowania do wielkiej awarii,
  • bezpieczeństwo centrum danych,
  • bezpieczeństwo środowiska wirtualnego.

Ważnym elementem naszego cyklu są również webinary, gdzie będzie można nie tylko posłuchać o chmurze, ale także zadać swoje pytania i otrzymać na nie odpowiedzi. Najbliższe już 27 września o godzinie 20:00 i 28 września o godzinie 12:00. Temat: Zarządzanie incydentami w chmurze. Możecie zapisywać się już teraz.

Podstawowe definicje

Szyfrowanie – metoda utajnionego zapisywania, w której tekst jawny (otwarty) jest przekształcany w tekst zaszyfrowany (zwany inaczej kryptogramem).

Klucz szyfrowania – ciąg danych służących do szyfrowania wiadomości czytelnej w kryptogram za pomocą algorytmu szyfrowania.

Klucz rozszyfrowujący – ciąg danych służący do rozszyfrowania kryptogramu do postaci wiadomości czytelnej za pomocą  algorytmu deszyfrowania.

Kryptografia symetryczna – zarówno do szyfrowania, jak i do odszyfrowywania używamy tego samego klucza.

Kryptografia asymetryczna – do szyfrowania używamy jednego klucza (tzw. klucz publiczny) natomiast do odszyfrowywania używamy innego klucza (tzw. klucz prywatny).

Dlaczego szyfrujemy dane?

Bo musimy, ponieważ jesteśmy do tego zobligowani przez obowiązujące nas regulacje. I jak już wspomniałem – dla zapewnienia poufności, integralności, uwierzytelnienia czy niezaprzeczalności. Szczególnie istotne jest to w modelu chmury, gdzie korzystamy z dostarczonych usług.

Szyfrowanie jako metoda ochrony poufności, integralności czy niezaprzeczalności jest wymieniona przez wiele ustaw i regulacji branżowych. Jeśli prowadzimy biznes z wykorzystaniem usług w chmurze, powinniśmy być świadomi tych zapisów. Poniżej kilka przykładów:

• Komunikat Urzędu Komisji Nadzoru Finansowego dotyczący korzystania przez podmioty nadzorowane (m.in. sektor bankowy, ubezpieczeniowy, rynek kapitałowy, usługi płatnicze) z usług przetwarzania danych w chmurze obliczeniowej określa, że szyfrowanie i ochrona integralności transmitowanych i przechowywanych danych za pomocą nieskompromitowanych metod jest jednym ze sposobów realizacji wymagań dotyczących bezpieczeństwa informacji.

• Ustawa o ochronie informacji niejawnych wskazuje zasady ochrony informacji, których nieuprawnione ujawnienie spowodowałoby lub mogłoby spowodować szkody dla Rzeczypospolitej Polskiej. Jeśli nasz biznes związany jest z przetwarzaniem tego rodzaju informacji do ich ochrony musimy stosować metody kryptograficzne w zależności od klauzuli przesyłanych/przechowywanych  informacji (zastrzeżone, poufne, tajne, ściśle tajne – tzw. informacje klasyfikowane). Moc kryptograficzna przy przesyłaniu danych niejawnych powinna być tym większa, im wyższe są klauzule tajności danych przesyłanych przez sieć systemu teleinformatycznego. Dla dokumentów „tajnych” i „ściśle tajnych” należy stosować rozwiązania sprzętowe, gwarantujące ochronę algorytmów i kluczy kryptograficznych. Służby ochrony państwa (Służba Kontrwywiadu Wojskowego i Agencja Bezpieczeństwa Wewnętrznego) wystawiają certyfikat potwierdzający zdolność systemu do pracy z informacjami oznaczonymi odpowiednią klauzulą tajności.

• Art. 32 Rozporządzenia o ochronie danych osobowych (tzw. RODO) stwierdza, że administrator i podmiot przetwarzający wdrażają odpowiednie środki techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający temu ryzyku, w tym między innymi w stosownym przypadku:
  a) pseudonimizację i szyfrowanie danych osobowych;
  b) zdolność do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów i usług przetwarzania.

• Art. 33 pkt 1 RODO wymaga powiadamiania organu nadzorczego o każdym przypadku naruszenia bezpieczeństwa danych osobowych. W przypadku naruszenia ochrony danych osobowych administrator bez zbędnej zwłoki – w miarę możliwości, nie później niż w terminie 72 godzin po stwierdzeniu naruszenia – zgłasza je organowi nadzorczemu właściwemu zgodnie z art. 55, chyba że jest mało prawdopodobne, by naruszenie to skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych. Do zgłoszenia przekazanego organowi nadzorczemu po upływie 72 godzin dołącza się wyjaśnienie przyczyn opóźnienia.

• Z kolei art. 34 RODO zawiera zalecenia dot. zawiadamiania osoby, której dane dotyczą, o naruszeniu ochrony danych osobowych:
  Jeżeli naruszenie ochrony danych osobowych może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych, administrator bez zbędnej zwłoki zawiadamia osobę, której dane dotyczą, o takim naruszeniu.
  Jednakże dalej w tym samym artykule dowiadujemy się, że:
  Zawiadomienie, o którym mowa w ust. 1, nie jest wymagane w następujących przypadkach:
  a) administrator wdrożył odpowiednie techniczne i organizacyjne środki ochrony i środki te zostały zastosowane do danych osobowych, których dotyczy naruszenie, w szczególności środki takie jak szyfrowanie, uniemożliwiające odczyt osobom nieuprawnionym do dostępu do tych danych osobowych;
  b) administrator zastosował następnie środki eliminujące prawdopodobieństwo wysokiego ryzyka naruszenia praw lub wolności osoby, której dane dotyczą, o którym mowa w ust. 1;

Jak wynika z w/w artykułów, szyfrowanie jest dobrym sposobem na uniknięcie kar przewidzianych w RODO. W  zależności od skali zaniedbania mogą one wynieść odpowiednio do 10 000 000 EUR  lub 2% całkowitego rocznego światowego obrotu z poprzedniego roku (decyduje wartość wyższa) i do 20 000 000 EUR lub 4% całkowitego rocznego światowego obrotu z poprzedniego roku.

Korzystając z usług w chmurze, trzeba mieć świadomość, że we wszystkich rodzajach chmury ze względu na usługę (wyjątkiem jest usługa w modelu SaaS) czy lokalizację odpowiedzialność za szyfrowanie danych przechowywanych w bazach danych, systemach plików, dyskach (at rest) i podczas przesyłu przez pocztę elektroniczną, przeglądarki, aplikacje itd. (in transit) spoczywa na odbiorcy usługi. Dostawca może dostarczyć odpowiednie narzędzia i usługi, żeby to umożliwić i realizować ten proces w sposób domyślny. Generalizując, głównymi komponentami w systemach szyfrowania są dane, silnik realizujący proces szyfrowania oraz mechanizm zarządzania kluczami. Przy projektowaniu odpowiedniego systemu kluczowe jest określenie, gdzie są umieszczone poszczególne komponenty (w instancji czy sprzęcie, w chmurze publicznej czy prywatnej, w sieci czy na hoście) i przez kogo zarządzane oraz jakie są możliwości szyfrowania w poszczególnych modelach chmury.

Szyfrowanie w modelu IaaS

W IaaS rozróżniamy dwa główne modele składowania:

Wolumen (Volume storage) – wydzielony obszar pamięci masowej w postaci wirtualnych dysków podłączanych do maszyn wirtualnych (instancji) i wykorzystywanych jak fizyczne dyski lub macierze. Przykłady to VMWare VMFS, Amazon EBS, RackSpace RAID i OpenStack Cinder.

Obiektowe przechowywanie danych (object storage) – repozytorium plików, które zawierają metadane i identyfikatory tworząc obiekty. Przykłady to Amazon S3,  Aruba Cloud Object Storage, RackSpace Cloud Files, OpenStack Swift for private clouds.

Szyfrowanie wolumenów

Instance-managed encryption – w uproszczeniu działanie wygląda tak:

• silnik szyfrowania uruchamiany jest w ramach instancji,
• montowany jest zaszyfrowany wolumen,
• do odszyfrowania konieczne jest użycie klucza rozszyfrowującego w postaci hasła czy pliku klucza.

Wszystkie dane przechowywane na zaszyfrowanym wolumenie są chronione przed odczytem w przypadku utraty dysku lub nieuczciwym adminem dostawcy próbującym uzyskać dostęp przez natywne API. Dane są dostępne dla użytkowników zalogowanych do instancji, kiedy podłączony jest zaszyfrowany wolumen. W tej opcji można działać ze snapshotami. Ze względów bezpieczeństwa nie należy przechowywać pliku klucza ani hasła w ramach tej samej instancji. Przykładami są TrueCrypt i  dm-crypt Linuxa.

Externally-managed encryption – działanie podobne jak w modelu powyżej z tą różnicą, że klucze są przechowywane poza instancją, np. na serwerze zarządzającym lub HSM (Hardware Security Manager).

Źródło: Security Guidance v4.0, Cloud Security Alliance

Silnik szyfrowania łączy się z zewnętrznym serwerem zarządzającym kluczami lub HSM, pobiera klucz do RAM  i jest wykorzystany do uzyskania dostępu do zaszyfrowanego wolumenu. Większość produktów nadpisuje RAM po użyciu klucza i nigdy nie jest on przechowywany w ramach instancji.  Oprócz możliwości, które są w modelu, instance-managed encryption dodatkowo:

• Wspiera restart i autoskalowanie. Może wykonać dodatkową weryfikację bezpieczeństwa, żeby zapewnić, że tylko zatwierdzone instancje posiadają dostęp do kluczy.
• Audytowanie i raportowanie są scentralizowane.
• Centralizacja jest również zaletą przy zarządzaniu i zabezpieczaniu.
• Ułatwia tworzenie chmur hybrydowych.

Minusem mogą być zwiększone nakłady finansowe i pracy związane z zakupem (chyba że open source), instalacją i utrzymaniem dodatkowych komponentów.

Przy wyborze modelu zewnętrznego zarządzania kluczami warto rozważyć, jakie są możliwości i które z nich będą spełniały nasze oczekiwania i wymagania.

• HSM i sprzętowe zarządzanie kluczami –  dostarcza najwyższego poziomu bezpieczeństwa i zakresu. Urządzenie powinno być zainstalowane poza chmurą, z której korzystamy. Można je ulokować wewnątrz naszego centrum danych lub w prywatnej chmurze i połączyć za pomocą VPN-a.
• Virtual appliance – dostarczona przez dostawcę prekonfigurowana instancja, najlepiej, żeby była uruchomiona w prywatnej chmurze. Mniejszy poziom bezpieczeństwa niż w rozwiązaniu sprzętowym, ale tańszy i bardziej elastyczny.
• Key management software – rozwiązanie podobne do powyższego z tą różnicą, że zazwyczaj uruchamiany samodzielnie na dedykowanym serwerze lub oddzielnej instancji.
• Key management Software as a Service (SaaS, KMaaS) – wielu dostawców świadczy usługi zarządzania kluczami w wielu różnych modelach, np. AWS Key Management Service (KMS), CipherCloud, Gemalto, Thales.

Szyfrowanie przy przechowywaniu obiektowym

Szyfrowanie po stronie klienta (client-side encryption) – szyfrowanie danych odbywa się przed ich wysłaniem do przestrzeni składowania z wykorzystaniem silnika wbudowanego w aplikację lub klienta.

Źródło: cloudarchitectmusings.com

Szyfrowanie po stronie serwera (server-side encryption) – dane są szyfrowane po stronie serwera. Dostawca może mieć dostęp do klucza i uruchamiania silnika lub tylko do uruchamiania silnika, a klucze są po stronie klienta.

Źródło: cloudarchitectmusings.com

Im bardziej lokalizacja kluczy i silnik szyfrowania jest zlokalizowany po stronie klienta i im wcześniej dane są zaszyfrowane, zanim trafią do chmury, tym większy jest poziom bezpieczeństwa.

Źródło: www.eenewseurope.com

Szyfrowanie w modelu PaaS

PaaS jest warstwą wyżej w stosie SPI (Software, Platform, Infrastructure). Modele szyfrowania różnią się w zależności od platformy i dochodzą dodatkowe warstwy wobec IaaS.

• Szyfrowanie warstwy aplikacyjnej (Application layer encryption) – dane są szyfrowane w aplikacji lub kliencie uzyskującym dostęp do platformy.
• Szyfrowanie bazy danych (Database encryption) – dane są szyfrowane z wykorzystaniem mechanizmów wbudowanych i wspieranych przez platformę bazodanową jak Transparent Database Encryption (TDE).

Szyfrowanie w modelu SaaS

 W większości przypadków dostawca dostarcza mechanizmy szyfrowania i może wykorzystywać modele i rozwiązania wspomniane przy okazji niżej umieszczonych warstw IaaS i PaaS.  Dodatkowe opcje w modelu SaaS:

• Provider-managed encryption – dane są szyfrowane w aplikacji i generalnie zarządzane przez dostawcę.
• Proxy encryption – dane przechodzą przez szyfrujące proxy zanim trafią do SaaS.

Szyfrowanie komunikacji

Oprócz szyfrowania danych w tzw. spoczynku (at rest) powinniśmy zadbać o ich bezpieczeństwo także w trakcie ich przesyłania (in transit, in motion).  Także i w tym przypadku dostawcy oferują różne rozwiązania na swoich platformach. Najczęściej są one oparte na szyfrowaniu danych przed transmisją, uwierzytelnieniu punktów końcowych, rozszyfrowaniu i weryfikacji przed dostarczeniem.  Istotne jest, aby znać wersję i siłę szyfrowania protokołów wykorzystywanych w chmurze. Kilka przykładów stosowanych rozwiązań:

End-to-end (E2E): Założeniem jest, że gdy dane są poza komunikującymi się urządzeniami, pozostają zaszyfrowane, a żadne komponenty pośredniczące w komunikacji nie posiadają dostępu do haseł użytkowników czy kluczy. Komunikacja internetowa pomiędzy użytkownikami jest chroniona poprzez aplikację, która szyfruje i odszyfrowuje wszystkie dane jedynie na urządzeniach komunikujących się użytkowników (komputerach, laptopach, smartfonach). W przypadku systemów klient-serwer takie szyfrowanie nazywane jest client-side encryption i polega na tym, że dane są szyfrowane jeszcze przed wysłaniem ich na serwer, a odszyfrowane dopiero na kliencie.

Protokół HTTPS (Hypertext Transfer Protocol Secure) służy do bezpiecznego korzystania z różnego rodzaju usług i stron internetowych. Używa SSL, który umożliwia  transmisję zaszyfrowanych danych między komputerem a serwerem i jest obecnie wypierany przez TLS (Transport Layer Security), będący standardem uznanym za rozwinięciem SSL. TLS zapewnia trójstopniową ochronę polegającą na zaszyfrowaniu, integralności danych oraz ochronie przed przekierowaniem do fałszywej strony internetowej.

IPsec to zbiór protokołów służących implementacji bezpiecznych połączeń, służy do zapewnienia autoryzacji nadawcy, integralności danych, poufności transmisji.

Protokoły IPsec i SSL/TLS mogą być wykorzystywane do tworzenia VPN (Vritual Private Network), czyli wirtualnej sieci prywatnej .

Zarządzanie kluczami

Kluczową kwestią w utrzymaniu bezpieczeństwa kluczy jest cykl ich zarządzania.

• Generowanie kluczy – tworzenie kluczy. Każdy utworzony klucz powinien być monitorowany i audytowany.
• Przechowywanie kluczy – utworzone klucze powinny być bezpiecznie przechowywane i backupowane, żeby nie zostały utracone, zmanipulowane lub dostępne przez nieautoryzowanych użytkowników. W szyfrowaniu opartym o hasło również one powinny być bezpiecznie przechowywane.
• Aktywacja kluczy – klucze mogą być aktywowane  w momencie ich utowrzenia lub później w sposób automatyczny lub manualnie. Jeśli wiele kopii klucza została utworzona i aktywowana, one również powinny być przechowywane w bezpieczny sposób i monitorowane.
• Dystrybucja kluczy – po aktywacji kluczy powinien być zdefiniowany sposób, aby autoryzowane aplikacje, systemy i użytkownicy mogły je uzyskać do szyfrowania i odszyfrowania danych.
• Rotacja kluczy – klucze powinny być rotowane co jakiś czas, najlepiej cyklicznie w ustalonym harmonogramie. Kiedy nowy klucz zostaje utworzony, aktywowany i dystrybuowany, stary powinien być deaktywowany i zachowany do celów deszyfrowania.
• Wygaśnięcie klucza – klucz powinien być tworzony z zamiarem wykorzystywania go przez określony okres.  Po upływie okresu ważności powinien być zachowany w celu deszyfracji.
• Unieważnienie klucza – w przypadku podejrzenia kompromitacji klucza lub okazaniu się, że wykorzystana technologia jest przestarzała lub podatna na ataki należy unieważnić klucz, ale zachować go w celu ewentualnej deszyfracji.
• Zniszczenie klucza – w niektórych przypadkach klucz powinien być całkowicie usunięty. Wtedy każda jego instancja także powinna być usunięta.

Źródło: cloudarchitectmusings.com

Podsumowanie

• Określ swoje potrzeby względem szyfrowania danych: czy zależy Ci bardziej na wydajności, bezpieczeństwie, łatwości w zarządzaniu czy zachowaniu zgodności z regulacjami. Szukaj u dostawców rozwiązań i modeli szyfrowania dostosowanych do swoich potrzeb, wymagań, możliwości,  zagrożeń i wymagań prawnych oraz biznesowych.
• Przy usłudze zarządzania kluczami zwróć uwagę na to, jak klucze są segregowane i izolowane pomiędzy odbiorcami usługi a administratorami. Dostawcy mają różne podejście, architekturę i rozwiązania. Powinno się zmapować swoje wymagania bezpieczeństwa i odpowiedzieć sobie na pytanie, czy odpowiada mi to, że dostawca ma techniczne możliwości dostępu do moich kluczy.
• Upewnij się, czy platforma chmurowa dostarcza lub umożliwia wykorzystanie odpowiednich dla Ciebie rozwiązań w całym cyklu zarządzania kluczami. Również tych pozwalających na monitorowanie, audytowanie i raportowanie działań związanych z tworzeniem i użyciem kluczy.
• Infrastruktura chmurowa jest bardziej dynamiczna niż tradycyjna i opiera się bardziej na API i połączeniach sieciowych. Rozwiązania do szyfrowania powinny wspierać API oraz obsługiwać dużą liczę połączeń sieciowych.
• Większość z wymienionych rozwiązań posiada jakieś słabości i luki. Sprawdź, jakie są znane podatności dla rozwiązań, które chcesz zastosować (samodzielnie czy dostarczone przez dostawcę). Oceń, na ile stanowią one zagrożenie dla danych, które chcesz chronić, abyś mógł wybrać optymalne dla siebie rozwiązanie.

Przypominamy także o możliwości zapisania się na webinary z Marcinem – najbliższe już 27 września o godzinie 20:00 i 28 września o godzinie 12:00. Tematem spotkania będzie zarządzanie incydentami w chmurze. Możecie zapisywać się już teraz.

Dla zachowania pełnej przejrzystości: za opublikowanie tego artykułu pobieramy wynagrodzenie.