Demistyfikacja operacji kluczy KMS, Bring Your Own Key (BYOK), niestandardowy magazyn kluczy i przenoszalność kryptogramu

Podczas gdy przygotowujesz się do tworzenia lub migracji obciążenia w Amazon Web Services (AWS), projektowanie schematu szyfrowania może być stawiającym wyzwania, a czasami także dezorientującym staraniem.

Ten post przedstawia strukturę wyboru odpowiednich usług kryptograficznych i narzędzi AWS dla Twojej aplikacji, które będą pomocne w Twojej podróży. W artykule autor dzieli się powtarzalnymi wzorcami kryptograficznymi, identyfikuje częste błędne przekonania i tłumaczy zabezpieczenia, które zawiera AWS Key Management Service (AWS KMS). Skupia się na tym, w jaki sposób powinno się zwiększyć obciążenie pracą, aby skorzystać z tych zabezpieczeń, dzięki czemu będziesz w stanie uniknąć popularnych błędów, dokonywać świadomych wyborów projektowych na wczesnym etapie procesu i upraszczać oprogramowanie.

Szyfrowanie stanowi podstawowy mechanizm, który pozwala uniknąć nieupoważnionego dostępu do danych. Jednakże jest on tylko tak dobry, jak zabezpieczenia, które egzekwujesz przy dostępie i korzystaniu z kluczy szyfrowania danych. Korzystanie ze sprawdzonej kryptografii i najlepszych praktyk branżowych w celu ograniczenia dostępu do Twoich danych, zarządzanie kluczami dostępu i monitorowanie ich użycia są niezbędne w przypadku długoterminowego bezpieczeństwa. To ważne, aby zdać sobie sprawę także z tego, że dostępność i niezawodność obciążeń są równie ważne jak ich bezpieczeństwo. Kiedy tworzysz i zarządzasz swoimi aplikacjami w chmurze, powinieneś wziąć pod uwagę zarówno operacyjne, jak i poufne aspekty KMS.

Wybory oparte na zaufaniu

Jedną z pierwszych rzeczy, jaką należy rozważyć, jest to, czy wybrać usługę lub sprzętowe źródło zaufania w celu zabezpieczenia kluczy, które sprawi, że wybór, jaki posiadasz, zbalansuje kompatybilność i obciążenie związane z opóźnieniami, dostępnością i niezawodnością.   

W przypadku klientów, którzy szyfrują dane lokalnie (on-premises), korzystanie z lokalnego modułu bezpieczeństwa sprzętowego (HSM) pozwala Ci na przenoszenie istniejących, zaszyfrowanych danych bezpośrednio do chmury przy niewielkim wysiłku, a także dalsze korzystanie z istniejących procesów zgodności. Jednakże dostępność i opóźnienie takiego rozwiązania w czasie jest nieoptymalne. Największe ryzyko polega na tym, że jeśli Twój HMS stanie się niedostępny, możesz doświadczyć krytycznych dla firmy przerw w obciążeniach. Jeśli Twój sprzęt ulegnie awarii lub klucze szyfrowania zostaną utracone, możesz całkowicie utracić dostęp do swoich danych. Stąd obciążenie związane z konserwacją, monitorowaniem i trwałością w tym scenariuszu staje się nieproporcjonalnie wysokie.

W przypadku klientów, którzy chcą zoptymalizować szyfrowanie pod kątem obciążeń w chmurze, powinni oni rozważyć przejście na podejście natywne w chmurze z pełni zarządzaną usługą, jak AWS KMS. Korzystając z niego, uzyskasz wydajny system zarządzania kluczami z modelem „pay as you go”, który obniża koszty i zmniejsza obciążenie administracyjne w porównaniu z samodzielnie zarządzanymi modelami HSM. Jednakże metoda ta może wiązać się z pewnym znaczącym wysiłkiem, aby ponownie zaszyfrować dane i możliwie zmienić sposób demonstrowania zgodności z przepisami. Przykładowo może zajść potrzeba zmiany tego, w jaki sposób przedstawiana jest zgodność w zakresie usuwania danych i kontroli klucza. AWS może pomóc Ci osiągnąć ten cel poprzez narzędzia, raporty zgodności audytów, wskazówki dotyczące zgodności (takie jak NIST blueprints), wsparcie ze strony zespołu AWS Professional Services i AWS Support.

Klienci zwykle przechodzą do chmury mniej więcej pomiędzy tymi dwoma końcami spektrum, a następnie robią w niej znaczne postępy. AWS oferuje kilka opcji, które są dostosowane do Twoich ograniczeń i potrzeb. W następnej sekcji zostaną omówione opcje, które usługi kryptograficzne AWS oferują dla Twoich potrzeb szyfrowania danych oraz to, w jaki sposób możesz dokonać właściwego wyboru dla swojego przypadku użycia. Następnie zostaną omówione powszechne wyzwania i to, jak je przezwyciężyć.

Kryptografia w AWS

Każda z usług kryptograficznych AWS jest obsługiwana przez HSM zweryfikowanym przez FIPS 140-2. Dzięki AWS KMS Twoje klucze są generowane i zarządzane w modułach HSM, obsługujących wielu dzierżawców AWS. Jeśli potrzebujesz HSM z certyfikatem FIPS 140-2 Level 3, możesz użyć AWS CloudHSM, który kontrolujesz za pomocą Amazon Virtual Private Cloud (Amazon VPC). Przy takim podejściu musisz opracować funkcjonalność aplikacji, aby uzyskać dostęp do CloudHSM.

KMS oferuje także kompletną kontrolę nad tym, gdzie generujesz i przechowujesz klucze szyfrowania.

Jeśli zgodność lub wewnętrzne zasady muszą wykazywać kontrolę nad procesem generowania klucza szyfrowania, taką jak możliwa do udowodnienia entropia klucza szyfrowania, AWS KMS oferuje opcję „bring your own key (BYOK). Jeśli chcesz mieć zarówno wygodę, jak i integrację usługi KMS, ale potrzebujesz modułu HSM z jednym dzierżawcą pod kontrolą jako źródła zaufania, KMS ma do zaoferowania niestandardowe magazyny kluczy.

Kiedy już utworzysz klucz w swoim AWS KMS, KMS stosuje kontrolę dostępu poprzez politykę tożsamości i zasobów, kontrole integralności i AWS CloudTrial. Korzystając z dostępnych technologii AWS, możesz upewnić się, że użycie klucza szyfrowania jest zgodne z określonymi przez Ciebie ograniczeniami i spójne z najlepszymi praktykami kryptograficznymi.

Kiedy korzystasz z natywnych rozwiązań AWS KMS dla chmury, skupiasz się przede wszystkim na zasadach bezpieczeństwa (uprawnieniach do wykonywania operacji kryptograficznych), operacji szyfrowania i audytach. Dzięki KMS, AWS zarządza dostępnością, niezawodnością, wydajnością oraz logowaniem.

Z drugiej strony, jeśli obecnie zarządzasz modułami HSM w sposób lokalny, wiesz, jak kosztowne i trudne może się to okazać w praktyce. Wraz z CloudHSM AWS zapewnia dostępność, synchronizację klucza szyfrowania, backup oraz wymianę uszkodzonych modułów, dzięki czemu administracja staje się łatwiejsza w zarządzaniu. W dalszym ciągu posiadasz narzut uprawnień użytkowników, skalowania i zarządzania dziennikami. W związku z tym powinieneś planować korzystanie z CloudHSM wtedy, gdy przepisy dotyczące zgodności wymagają, aby single-tenant HSM z walidacją FIPS 140-2 Level 3 (§1.3) znajdował się pod Twoją kontrolą, odkąd AWS KMS obsługuje wielu dzierżawców i tymczasowo obsługuje standard FIPS 140-2 Level 2 (§1.2). W innych przypadkach powinieneś rozważyć korzystanie z KMS. Możesz także potrzebować wykorzystania CloudHSM, jeśli musisz obsługiwać przenośny, zaszyfrowany tekst i klucze szyfrowania. Zostanie to dokładniej omówione w poniższych sekcjach.

Usługi kryptograficzne AWS KMS

Wybierając usługi kryptograficzne AWS, powiązane z AWS KMS, istnieją trzy opcje zarządzania kluczami szyfrowania:

• AWS KMS z kluczami klienta lub zarządzanymi przez AWS;
• AWS KMS z BYOK (klucz importu KMS);
• AWS KMS z niestandardowym magazynem kluczy KMS do zarządzania kluczami wspieranymi przez CloudHSM.

Rysunek nr 1 porównuje, jak różne podejścia architektoniczne wpływają na złożoność operacyjną i koszty operacyjne. Wraz z tym, jak złożoność operacyjna wzrasta, wzrastają koszty operacyjne. Poniższy rysunek obrazuje porównanie różnych architektur w miarę wzrostu złożoności:

• Natywny AWS KMS – najniższa złożoność i najniższy koszt;
• AWS KMS BYOK;
• Magazyn kluczy niestandardowych AWS KMS;
• AWS CloudHSM;
• Lokalny HSM – najwyższa złożoność i koszt.

Rysunek nr 1: Porównanie kluczowych rozwiązań zarządzania i ich względnego kosztu

„Wysiłek związany z zarządzaniem” zwiększa się wraz z ilością czasu oraz wysiłku niezbędnych do utrzymania rozwiązania w stanie operacyjnym. Na przykład powinieneś rozważyć, ile czasu Twoi administratorzy spędzą na zarządzaniu urządzeniami, kontrolowaniu uprawnień dostępu i przeprowadzaniu synchronizacji danych, backupu, przywracania i audytu.

Porównując wysiłek związany z integracją między rozwiązaniami, powinieneś rozważyć, jak łatwe jest korzystanie z rozwiązania do zarządzania kluczami szyfrowania. AWS KMS jest natywnie zintegrowany z wieloma usługami AWS w celu szyfrowania danych w spoczynku lub ułatwiania podpisywania i weryfikacji; funkcjonalność jest także dostępna za pośrednictwem zestawu SDK AWS dla programistów, którzy potrzebują zaszyfrować/odszyfrować dane lokalnie w swoich aplikacjach. W przypadku systemów HSM integracja PKCS#11 jest zazwyczaj wymaganym podejściem.

Powszechne błędne postrzeganie dotyczące BYOK

Klienci często nie rozumieją celu BYOK w AWS KMS. Niezależnie od tego, czy importujesz klucz do KMS lub natywnie generujesz go w KMS, usługa stosuje zabezpieczenia, które zapewniają, że KMS odszyfruje tylko dane wygenerowane przez KMS.

Te zabezpieczenia pozwalają AWS KMS na konsekwentne i niezawodne egzekwowanie zasad i restrykcji, dzięki czemu możesz czuć się pewnie, korzystając i kontrolując swoje klucze szyfrowania.

Jednym z efektów ubocznych tych restrykcji jest to, że nie możesz w sposób bezpośredni przesyłać tekstu zaszyfrowanego między AWS KMS a lokalnymi systemami kryptograficznymi. Aplikacje mogą szyfrować ten sam zwykły tekst w każdym środowisku – jak chociażby lokalnym centrum danych – poprzez korzystanie z właściwego klucza. Szyfrowanie AWS SDK wykorzystuje „breloki”, narzędzie, które ułatwia zarządzanie wieloma kluczami szyfrującymi równoznaczne kopie danych. Ewentualnie możesz przeprowadzić migrację poprzez ponowne szyfrowanie kluczy danych w KMS, jeśli używasz szyfrowania kopert lub poprzez ponowne całkowite szyfrowanie danych przy użyciu szyfrowania po stronie serwera z wybranymi kluczami i zasadami KMS.

Drugim z efektów ubocznych wynikających z restrykcji jest to, że nie możesz użyć BYOK do wymiany kluczy głównych pomiędzy partnerem zewnętrznym a aplikacją. Aby zapewnić bezpieczną wymianę kluczy, w której klucze te muszą znajdować się w module HSM przez cały czas, dostępne są następujące opcje:

• poproś partnera o założenie konta lub obciążenia AWS, a następnie utwórz i udostępnij mu klucz AWS KMS. Użycie jest rejestrowane na obu kontach, a szyfrogram jest kompatybilny z różnymi aplikacjami;
• korzystaj bezpośrednio z CloudHSM.

Rysunek nr 2: Opcje AWS do zarządzania kluczami

Dlaczego AWS KMS nie obsługuje przenośnego szyfrogramu?

Podobnie jak w środowisku lokalnym, jedna z własności bezpieczeństwa AWS KMS polega na tym, że klucze nigdy nie opuszczają granicy FIPS 140-2 HSM. Właściwość ta została zaprojektowana, aby zapewnić, że nie można stracić kontroli nad kluczami szyfrowania, kiedy zarządza nimi KMS, i że tylko KMS może odszyfrować dane zaszyfrowane przez KMS. Proces ten niezawodnie i konsekwentnie wymusza zasady dostępu do kluczy i zasobów; zapewnia, że KMS weryfikuje tworzone przez Ciebie konteksty szyfrowania. Dodatkowo gwarantuje możliwość przeprowadzenia audytu Twoich operacji kryptograficznych: wszystkie operacje na kluczach szyfrowania (generowanie klucza, szyfrowanie, odszyfrowywanie, podpisywanie i weryfikowanie), które występują w KMS, zostały wyszczególnione w dziennikach CloudTrial. Wreszcie, ta właściwość bezpieczeństwa chroni przed arbitralnym szyfrowaniem lub odszyfrowywaniem ataków z zewnątrz. Wdrożenie tych ograniczeń bezpieczeństwa przez AWS wymaga ponownego zaszyfrowania danych na potrzeby natywnych implementacji KMS.

Wszystkie kryptosystemy generują zaszyfrowany tekst wyjściowy w określonym formacie wiadomości, a różne formaty nie są interoperacyjne. Format wiadomości szyfrogramu wykorzystywany przez AWS KMS zawiera metadane niezbędne do odszyfrowania danych przez KMS, takie jak wersja klucza wykorzystywanego do szyfrowania danych. Dodatkowo format wiadomości szyfrowanej KMS może od czasu do czasu podlegać zmianom. Każdy dostawca HSM i usługa szyfrowania w chmurze produkuje różne rodzaje szyfrogramu. Nawet jeśli dwóch dostawców usług kryptograficznych używa identycznego materiału klucza do tworzenia tekstu zaszyfrowanego, odszyfrowanie jednego z nich może okazać się niemożliwe. W ogólnym ujęciu powinieneś założyć, że tylko KMS może odszyfrować utworzone przez siebie i zaszyfrowane teksty.

Aby zweryfikować, czy AWS KMS działa na swoim (samodzielnie wygenerowanym) zaszyfrowanym tekście, zostanie obliczony podpis zaszyfrowanego tekstu. KMS wykorzystuje weryfikację podpisu, aby uniemożliwić próby odszyfrowania dowolnych danych, a tym samym zminimalizować potencjalną możliwość wyczerpania klucza szyfrowania (§5.6.1.1). Podczas gdy możliwe jest opracowanie systemu, który zdekompilowałby kopertę KMS, otworzyłoby to ścieżkę do odszyfrowania danych i wprowadzenia potencjalnych błędów, jeśli usługa KMS doda parametry metadanych lub rozwinie swój algorytm szyfrowania w przyszłości.

Ze względu na te zabezpieczenia klucze AWS KMS używane z innymi usługami AWS, takimi jak Amazon Simple Storage Service (Amazon S3) i Amazon Elastic Block Store (Amazon EBS), charakteryzują się niskim ryzykiem wyczerpania klucza szyfrowania, ponieważ usługi AWS nie zapewniają wglądu w zaszyfrowany tekst, a klucze szyfrowania danych są zawsze inne. Na przykład obiekty i woluminy Amazon S3 posiadają unikalne klucze szyfrowania danych.

Wybór właściwej ścieżki

Wybierając usługę kryptograficzną oferowaną przez AWS, rekomenduje się używanie natywnego szyfrowania AWS KMS kiedykolwiek jest to możliwe oraz szyfrowania danych za pomocą szyfrowania po stronie serwera. Ten wzorzec pozwala skupić się na aplikacji i polegać na AWS w zakresie wykonywania pracy, utrzymywania dostępności usług, zarządzania hierarchią kluczy, faktycznego procesu szyfrowania – wyboru algorytmu, konwersji tekstu jawnego na szyfrogram – oraz rejestrowania.

Korzystając z AWS KMS z kluczami zarządzanymi przez klienta, możesz włączyć rotację kluczy. Z włączoną rotacją kluczy KMS zmienia klucze automatycznie i śledzi wersje kluczy szyfrowania używanych do szyfrowania danych, aby wybrać ten właściwy do operacji odszyfrowania.

Jeśli musisz wygenerować materiał klucza szyfrowania i posiadać możliwą do udowodnienia entropię klucza szyfrowania, możesz skorzystać z funkcji importu klucza AWS KMS. Dzięki importowanym kluczom rotacja kluczy szyfrujących i bezpieczeństwo przenoszą się do Twojej części modelu współodpowiedzialności. AWS nie utrwala Twojego zaimportowanego materiału klucza szyfrującego na żadnym nośniku pamięci, przez co musisz się upewnić, że posiadasz kopię zapasową do odzyskania, jeśli dojdzie do całkowitej utraty zasilania.

Jeśli posiadasz upoważnienie na zgodność ze standardem FIPS 140-2 Level 3 lub musisz wykazać, że Twój system kryptograficzny jest środowiskiem z jednym dzierżawcą, możesz użyć niestandardowego magazynu kluczy AWS KMS obsługiwanego przez CloudHSM. W tym wzorcu projektowym możesz wykorzystywać wszystkie usługi AWS zaprojektowane do współpracy z KMS i zlecić CloudHSM wykonywanie operacji kryptograficznych.

CloudHSM to właściwy wybór, jeśli chodzi o całkowitą przenośność zaszyfrowanego tekstu, wymagania zgodności ze standardem FIPS 140-2 Level 3 i rozwiązania, które wymagają interfejsu PKCS #11. CloudHSM to usługa zatwierdzona przez FIPS 140-2 Level 3, która posiada natywną obsługę interfejsu PKCS #11. W celu umożliwienia przenoszenia tekstu szyfrowanego pomiędzy CloudHSM a innym systemem należy zsynchronizować klucze szyfrowania między wieloma modułami HSM za pomocą procesu zwijania i rozwijania, używając niestandardowego kodu PKCS #11.

Wraz z AWS KMS zyskujesz także dodatkową warstwę autoryzacji AWS Identity and Access Management (IAM), w której dostęp do odczytu danych i uprawnienia do odszyfrowania są potrzebne, aby uzyskać dostęp do zwykłego tekstu. Jeśli oprócz dostępu do danych zarządzasz uprawnieniami dostępu do klucza poprzez IAM, łatwiejsze dla Ciebie może okazać się wdrożenie rozdzielenia obowiązków i planów powstrzymywania.

Przykładowo jako dodatkowy element sterujący, stosując zasady zasobów IAM i AWS KMS, możesz zapobiec odczytywaniu ich przez tożsamość, która zapisuje dane.

Ta strategia dogłębnej ochrony umożliwia również odłączenie lub odmowę dostępu do klucza szyfrującego w ramach strategii powstrzymywania podczas zdarzenia związanego z bezpieczeństwem. Odmowa dostępu lub wyłączenie kluczy szyfrowania AWS KMS będzie skutkować tym, że dane w postaci zwykłego tekstu staną się niedostępne, nawet jeśli strona trzecia uzyska dostęp do tekstu zaszyfrowanego.

Przejrzyj hierarchię, szyfrowanie i odszyfrowywanie

Aby to zademonstrować, przyjrzyj się, jak AWS KMS szyfruje dane klienta oraz niektórym zilustrowanym elementom jego operacji kryptograficznych. Więcej szczegółów znajduje się w oficjalnym dokumencie AWS Key Management Service.

Hierarchia kluczy AWS KMS

Podstawowym celem KMS jest bezpieczne tworzenie, udostępnianie i ochrona kluczy danych. AWS KMS wykorzystuje hierarchię kluczy szyfrowania do ochrony danych. Typy kluczy mogą być kluczem szyfrowania klucza lub kluczem szyfrowania danych.

Kiedy tworzysz klucz symetryczny AWS KMS:

1. AWS KMS generuje metadane klucza – identyfikator klucza, wersję klucza, ARN i alias. Podczas gdy ID klucza jest unikalny dla regionu AWS, w którym tworzysz klucz KMS, możesz używać tego samego aliasu w wielu regionach.
2. AWS KMS tworzy klucz zapasowy HSM (HBK) – 256 bitowy klucz Advanced Encryption Standard (AES)

Z AWS KMS możesz wybrać jeden z trzech sposobów tworzenia HBK:

• Klucze zarządzane przez AWS KMS: moduły HSM zarządzane przez KMS tworzą HBK;
• BYOK: generujesz klucz HBK i importujesz go do AWS KMS HSM przez API;
• Niestandardowy magazyn kluczy: klucz jest generowany w kontrolowanym przez klienta klastrze CloudHSM poprzez AWS KMS podczas udostępniania niestandardowego magazynu kluczy.

Wynikiem ustanowienia klucza AWS KMS jest 265-bitowy klucz HBK AES, który w połączeniu z jednorazową liczbą losową służy do generowania klucza szyfrowania danych używanego w danych klientów.

Proces szyfrowania I deszyfrowania dla AWS KMS

Wiedza na temat tego, w jaki sposób AWS KMS wykorzystuje HBK i klucze danych, zapewni Ci możliwość skutecznego wykorzystania tej technologii w Twoich wdrożeniach. Poniższa sekwencja przedstawia operacje szyfrowania i deszyfrowania.

Podczas operacji szyfrowania AWS KMS:

1. Lokalizuje HBK z określonym identyfikatorem i numerem wersji w modułach HSM zarządzanych przez usługę.
2. Generuje losową wartość.
3. Używa HBK z wartością losową do tworzenia klucza szyfrowania danych przy użyciu funkcji wyprowadzania klucza NIST 800-108.
4. Szyfruje dane klientów za pomocą wyprowadzonego klucza danych.
5. Łączy:
1. Identyfikator klucza
2. Wersję klucza
3. Losową wartość używaną do generowania klucza
4. Szyfrogram
5. Inne metadane usługi
6. Podpisuje połączone dane kluczem KMS AWS.

Wynik ostatniego kroku to wartość zwracana przez wywołanie API szyfrowania AWS KMS.

W trakcie odszyfrowywania AWS KMS:

1. Otwiera wiadomość.
2. Weryfikuje podpis wiadomości. Jeśli weryfikacja się nie powiedzie, operacja się nie odbędzie.
3. Wyodrębnia identyfikator klucza, wersję, wartość losową i tekst zaszyfrowany przechowywany w kopercie metadanych podczas operacji szyfrowania.
4. Lokalizuje HBK w swoim module HSM zarządzanym przez usługę przy użyciu identyfikatora klucza i wersji klucza.
5. Używa HBK i wartości losowej, aby odtworzyć klucz szyfrowania danych przy użyciu funkcji odwrotnej funkcji wyprowadzania klucza NIST 800-108.
6. Odszyfrowuje dane.

Wynik ostatniego kroku to wartość zwracana przez wywołanie API odszyfrowania usługi AWS KMS.

Proces szyfrowania i deszyfrowania kluczy zarządzanych przez AWS KMS z niestandardowym magazynem kluczy

W przypadku niestandardowego magazynu kluczy AWS KMS proces przebiega podobnie do opisanego w poprzednim akapicie, z jednym wyjątkiem.

Generowanie i przechowywanie HBK, a także szyfrowanie i deszyfrowanie danych, odbywa się w CloudHSM zamiast w modułach HSM zarządzanych przez usługę AWS KMS, więc musisz zapewnić odpowiednią wydajność, jak i dostępność. Oprócz tego integracja KMS i CloudHSM posiada inną charakterystykę wydajności niż usługi KMS i wymaga minimum dwóch urządzeń CloudHSM w oddzielnych strefach dostępności.

Wnioski

Tworzenie aplikacji w celu korzystania z szyfrowania natywnego dla chmury zazwyczaj przyniesie korzyści w postaci łatwiejszych operacji, lepszej wydajności i prostszej, solidniejszej kontroli dostępu. Decydując, jak wdrożyć AWS KMS oraz jakich opcji użyć, pamiętaj, że:

• AWS KMS wykorzystuje materiał klucza HBK nie dla szyfrowania danych, ale do uzyskania jednorazowego klucza szyfrowania. Korzyści z procesu BYOK są ograniczone do zgodności, w przypadku której musisz udowodnić wiarygodny proces entropii klucza. Ponieważ klucze BYOK nie są wykorzystywane do szyfrowania danych w KMS, ale do szyfrowania innych kluczy, nie możesz odszyfrować tekstu zaszyfrowanego utworzonego na zewnątrz za pomocą zaimportowanego odpowiednika tego klucza w KMS i na odwrót. Analogicznie, jeśli importujesz ten sam klucz do KMS w sposób indywidualny i do różnych regionów, wynikowy zaszyfrowany tekst nie będzie identyczny lub interoperacyjny, ponieważ informacje o regionie są częścią metadanych zawartych w formacie wiadomości KMS.
• AWS KMS zawiera zabezpieczenia zaprojektowane w celu zapobiegania niewłaściwemu używaniu i nadużywaniu kluczy. KMS zawsze używa HBK i unikalnej losowości dla każdej transakcji. Nawet wielokrotne wywołania KMS w celu zaszyfrowania tego samego jawnego tekstu oraz użycie tego samego klucza skutkują różnymi szyfrogramami. Ponadto szyfrowane teksty KMS obejmują sprawdzanie integralności, więc nie będą próbować odszyfrować dowolnych danych – chroni to klucze przed atakami polegającymi na wykryciu metody „na siłę”. Te zabezpieczenia powodują, że nie można współdziałać szyfrogramu od wewnątrz ani od zewnątrz KMS. W przypadku wdrożeń hybrydowych lub międzyregionalnych wdrożeń w AWS możesz, i powinieneś, ponownie szyfrować dane przy użyciu kluczy i formatów odpowiednich do miejsca, w którym znajdują się Twoje dane.
• Korzyści płynące z niestandardowego magazynu kluczy AWS KMS są ograniczone do zgodności, gdy wymagany jest moduł HSM FIPS 140-2 Level 3 lub izolacja klucza szyfrowania. Niestandardowy magazyn kluczy KMS nieodłącznie wiąże się z karą za prowadzenie klastra CloudHSM, w którym odpowiedzialność za wydajność, monitorowanie i administrowanie użytkownikami przenosi się na Twoją stronę modelu współodpowiedzialności.

Podsumowanie

Kiedy projektujesz schemat szyfrowania, zaleca się rozważenie usługi AWS KMS jako pierwszej i korzystanie z niej, kiedy tylko możliwe. KMS pomaga Ci w integracji i zarządzaniu szyfrowaniem w bezpieczny, niezawodny i wysoce dostępny sposób. Ponadto ze względu na to, że inne usługi AWS używają KMS do szyfrowania, masz jedno miejsce do zarządzania kluczami szyfrowania, zasadami bezpieczeństwa i dziennikami dostępu. Jeśli posiadasz wyspecjalizowaną zgodność (taką jak FIPS 140-2 Level 3 lub pojedynczą dzierżawę) bądź  wymagania programistyczne (takie jak PKCS #11), dostępne są opcje BYOK, AWS CloudHSM i AWS KMS custom key store.

Aby dowiedzieć się więcej, możesz przejrzeć dodatkowe materiały, takie jak AWS KMS Cryptographic Details whitepaper, AWS Key Management Service Best Practices, AWS Key Management Service Documentation oraz AWS KMS Workshop. Rekomenduje się zaangażowanie zespołu ds. Kont AWS w celu uzyskania szczegółowych recenzji i specjalistycznych zadań.

Jeśli posiadasz uwagi do tego artykułu, zamieść komentarz w sekcji Komentarze znajdującej się poniżej. Jeśli masz pytania dotyczące tego artykułu, rozpocznij wątek na forum AWS KMS lub skontaktuj się z pomocą techniczną AWS.

źródło: AWS