Jak odpowiadać na pytania o szyfrowanie i zarządzanie kluczami prostym językiem

Co oznaczają te pytania

Większość pytań o szyfrowanie sprowadza się do dwóch pojęć, plus trzeciego o kluczach.

Szyfrowanie w tranzycie. Chroni dane, gdy przemieszczają się w sieci: między przeglądarką użytkownika a twoją aplikacją, między twoimi usługami oraz między tobą a podprzetwarzającymi. Standardowym mechanizmem jest TLS (Transport Layer Security), protokół stojący za HTTPS. Kwestionariusz pyta, czy dane w tranzycie są szyfrowane, i często, jaką wersję TLS wymuszasz. Konkretna odpowiedź podaje minimalną wersję, na przykład TLS 1.2 lub wyższy, we wszystkich twoich połączeniach zewnętrznych.

Szyfrowanie w spoczynku. Chroni dane, gdy są przechowywane: na dyskach z bazą danych, kopiami zapasowymi, magazynem plików i logami. Standardowym mechanizmem jest szyfr symetryczny, zwykle AES (Advanced Encryption Standard), często AES-256. Kwestionariusz pyta, czy dane w spoczynku są szyfrowane, a czasem jakim algorytmem. Konkretna odpowiedź nazywa algorytm i potwierdza, że obejmuje wszystkie miejsca, w których dane faktycznie spoczywają, w tym kopie zapasowe, o których zespoły czasem zapominają.

Zarządzanie kluczami. Szyfrowanie zamienia czytelne dane w szyfrogram za pomocą klucza. Kto kontroluje klucz, ten może odszyfrować dane, więc bezpieczeństwo szyfrowania zależy od kontroli nad jego kluczami. Kwestionariusze pytają, gdzie klucze są przechowywane, kto ma do nich dostęp i jak często są rotowane. Za tym stoi jedna obawa: że twojego szyfrowania nie podważają klucze leżące gdzieś pod luźną kontrolą. Odpowiedź opisuje, gdzie żyją klucze (zwykle w zarządzanej usłudze kluczy), kto może do nich sięgnąć, i podejście do rotacji.

Osoba weryfikująca, czytając te pytania, sprawdza, czy dane są chronione zarówno w ruchu, jak i w spoczynku, oraz czy klucze są trzymane w miejscu pod kontrolą. Przewodnik zarządzanie kluczami API i sekretami obejmuje pokrewne pytanie o to, jak obchodzisz się z sekretami i poświadczeniami aplikacji, które kwestionariusze często grupują w pobliżu.

Jaki dowód akceptują kupujący

Szyfrowanie to jeden z niewielu obszarów, gdzie dowód jest prosty, bo jest kwestią konfiguracji.

Dla szyfrowania w tranzycie kupujący akceptują deklarację wersji TLS, którą wymuszasz, a czasem sami to sprawdzą wobec twoich publicznych endpointów, co jest dla nich łatwe. Odpowiedź musi więc być prawdziwa, bo da się ją zweryfikować z zewnątrz.

Dla szyfrowania w spoczynku kupujący akceptują deklarację algorytmu i usługi, która go dostarcza, poparte, gdy o to poproszą, dokumentacją twojego dostawcy chmury. Gdy korzystasz z zarządzanego szyfrowania dużego dostawcy chmury, jego opublikowana dokumentacja tej usługi jest dowodem, który osoba weryfikująca rozpoznaje, a wskazanie na nią to mocniejsze posunięcie niż opisywanie wnętrzności samodzielnie.

Dla zarządzania kluczami kupujący akceptują opis usługi kluczy, z której korzystasz, kontroli dostępu na niej i podejścia do rotacji. Jeśli korzystasz z zarządzanej usługi kluczy, jej dokumentacja i twoja konfiguracja są dowodem.

We wszystkich trzech przypadkach wzorzec jest ten sam co w reszcie kwestionariusza: odpowiadaj na podstawie tego, co faktycznie mówi konfiguracja, i trzymaj dokumentację dostawcy albo eksport konfiguracji tam, gdzie możesz go szybko pokazać. Odpowiedź o szyfrowaniu, którą możesz czymś poprzeć, przetrwa dopytanie; ta, którą stwierdzasz z pamięci, może nie przetrwać.

Jak odpowiadać, gdy polegasz na domyślnych ustawieniach dostawcy chmury

Większość małych firm SaaS nie prowadzi własnego szyfrowania. Polegają na zarządzanym szyfrowaniu, które ich dostawca chmury stosuje domyślnie: magazyn danych szyfrowany w spoczynku kluczem zarządzanym przez dostawcę, TLS terminowany na zarządzanym load balancerze, klucze trzymane w usłudze kluczy dostawcy. To uzasadniona i powszechna postawa, a właściwym sposobem odpowiedzi jest powiedzieć to wprost.

Uczciwa odpowiedź nazywa układ: którego dostawcę chmury, którą zarządzaną usługę i fakt, że klucze są zarządzane przez dostawcę, a nie przez klienta. Na przykład odpowiedź o szyfrowaniu w spoczynku może brzmieć: „Dane w spoczynku są szyfrowane za pomocą zarządzanego szyfrowania naszego dostawcy chmury z AES-256. Kluczami zarządza usługa zarządzania kluczami dostawcy, z dostępem ograniczonym do ról naszej infrastruktury". To dokładne, konkretne i nie udaje konfiguracji, której nie prowadzisz.

Liczą się tu dwa rozróżnienia, bo osoby weryfikujące o nie pytają.

Klucze zarządzane przez dostawcę a klucze zarządzane przez klienta. Przy kluczach zarządzanych przez dostawcę to dostawca chmury generuje i kontroluje klucze, a ty polegasz na jego kontrolach. Przy kluczach zarządzanych przez klienta (czasem nazywanych CMK albo BYOK, bring your own key) to ty generujesz lub kontrolujesz klucze, zwykle przez usługę kluczy dostawcy, co daje ci większą kontrolę i możliwość odwołania dostępu. Większość małych firm SaaS używa kluczy zarządzanych przez dostawcę, co jest w porządku. Błędem jest deklarowanie kluczy zarządzanych przez klienta, gdy korzystasz z ustawień domyślnych dostawcy. Powiedz, z czego faktycznie korzystasz.

Domyślne nie znaczy automatyczne wszędzie. Dostawcy chmury domyślnie szyfrują wiele usług w spoczynku, ale nie każda usługa i konfiguracja jest objęta automatycznie, a starsze lub źle skonfigurowane zasoby mogą być wyjątkiem. Zanim odpowiesz „wszystkie dane w spoczynku są szyfrowane", potwierdź, że dotyczy to twojego magazynu danych, baz danych, kopii zapasowych i wszelkiego magazynu plików, zamiast zakładać, że ustawienie domyślne dotarło wszędzie. To szybkie sprawdzenie, które zapobiega pewnej deklaracji, jaką mogłoby podważyć własne dochodzenie osoby weryfikującej.

Słabe odpowiedzi, które cię kosztują

Kilka odpowiedzi o szyfrowaniu szkodzi nieproporcjonalnie do tego, jak łatwo ich uniknąć.

Wymijające „szyfrujemy wszystko". Nie mówi to osobie weryfikującej nic i czytane jest jako niepewność. Od odpowiedzi o szyfrowaniu oczekuje się konkretu, bo są kwestią konfiguracji. Podaj minimalną wersję TLS, algorytm w spoczynku i układ kluczy. Konkretna odpowiedź zamyka pytanie; wymijająca zaprasza dopytanie.

Przecenianie kluczy zarządzanych przez klienta. Deklarowanie, że zarządzasz własnymi kluczami, gdy polegasz na ustawieniu domyślnym dostawcy, to przesada, którą osoba weryfikująca może sprawdzić, i która staje się oświadczeniem, jeśli twoje odpowiedzi są przywoływane w umowie. Zadeklaruj klucze zarządzane przez dostawcę uczciwie. To zupełnie akceptowalna postawa.

Luźno używane „szyfrowanie end-to-end". Szyfrowanie end-to-end ma konkretne znaczenie: odszyfrować mogą tylko komunikujące się punkty końcowe, a usługa pośrodku nie. Większość produktów SaaS szyfruje w tranzycie i w spoczynku, ale sama może odczytać dane, żeby dostarczyć usługę, co nie jest end-to-end. Luźne użycie tego terminu wprowadza osobę weryfikującą w błąd, a ona może rozliczyć cię ze ścisłego znaczenia. Opisz, co faktycznie robisz (szyfrowanie w tranzycie i w spoczynku), zamiast sięgać po mocniej brzmiący termin.

Podawanie algorytmu, którego nie sprawdziłeś. Napisanie „AES-256" albo „TLS 1.3", bo dobrze brzmi, bez potwierdzenia, to małe przecenienie, które osoba weryfikująca może zweryfikować i które, jeśli jest błędne, podważa resztę sekcji. Sprawdź faktyczną konfigurację, zanim podasz wersję albo algorytm.

Zapominanie o kopiach zapasowych i logach. „Dane w spoczynku są szyfrowane" musi dotyczyć też kopii zapasowych i logów, nie tylko głównej bazy danych. To właśnie tam deklaracja o szyfrowaniu w spoczynku cicho przecieka. Potwierdź pokrycie, zanim złożysz taką deklarację.

Wzorzec: pytanie kupującego, wzorcowa odpowiedź, co sprawdzają

Czytanie tych pytań tak, jak robi to osoba weryfikująca, utrzymuje odpowiedź w precyzji.

Pytanie: Czy dane klientów są szyfrowane w spoczynku i w tranzycie?Wzorcowa odpowiedź: Dane w tranzycie są szyfrowane za pomocą TLS 1.2 lub wyższego we wszystkich połączeniach zewnętrznych. Dane w spoczynku, w tym bazy danych, magazyn plików i kopie zapasowe, są szyfrowane za pomocą zarządzanego szyfrowania naszego dostawcy chmury z AES-256. Szczegóły konfiguracji i dokumentacja dostawcy są dostępne na życzenie.Co sprawdzają: czy szyfrowanie jest konkretne i obejmuje oba stany oraz czy deklaracja o spoczynku obejmuje kopie zapasowe, a nie tylko główny magazyn.

Pytanie: Jak zarządzane są klucze szyfrujące?Wzorcowa odpowiedź: Klucze są trzymane w zarządzanej usłudze kluczy naszego dostawcy chmury. Dostęp jest ograniczony do zdefiniowanych ról infrastruktury, a klucze są rotowane zgodnie z zarządzaną rotacją dostawcy. Używamy kluczy zarządzanych przez dostawcę, nie kluczy zarządzanych przez klienta.Co sprawdzają: czy klucze są trzymane w miejscu pod kontrolą z ograniczonym dostępem oraz czy dokładnie podałeś, czy klucze są zarządzane przez dostawcę, czy przez klienta.

Źródła

• Cloud Security Alliance, Cloud Controls Matrix and CAIQ v4: cloudsecurityalliance.org/research/topics/caiq (obszar kontroli kryptografii i szyfrowania obejmujący dane w spoczynku, dane w tranzycie i zarządzanie kluczami jako standardowe tematy kwestionariuszy).
• NIST, Advanced Encryption Standard (AES), FIPS 197: csrc.nist.gov (AES jako standardowy szyfr symetryczny dla danych w spoczynku).
• IETF, TLS 1.3 (RFC 8446) and TLS 1.2 (RFC 5246): datatracker.ietf.org (Transport Layer Security jako standardowy mechanizm dla danych w tranzycie).
• Ogólna uwaga o zarządzanym szyfrowaniu dostawcy chmury oraz kluczach zarządzanych przez klienta kontra zarządzanych przez dostawcę: sprawdź konkretne nazwy usług, domyślne pokrycie i sposób rotacji w aktualnej dokumentacji swojego dostawcy chmury, bo różnią się one między dostawcami i zmieniają się w czasie. Z tego powodu twierdzenia w tym miejscu są sformułowane ogólnie.