HSM w chmurze z przejrzystą kontrolą nad kluczami.

Prywatne podłączenie, rozwiązywanie nazw, uwierzytelnianie i opóźnienia wpływają na każde wywołanie kryptograficzne. Testujemy tę ścieżkę z rzeczywistym profilem obciążenia i planujemy zachowanie w przypadku przerwanego połączenia. Drugi punkt końcowy pomaga tylko wtedy, gdy klucze i uprawnienia są tam odpowiednio dostępne. Zewnętrzne usługi kluczy lub klucze zarządzane po stronie klienta różnią się ponadto tym, jakie dane i usługi rzeczywiście kontrolują. Dokumentujemy te granice tak, aby osoby odpowiedzialne merytorycznie rozumiały pozostały zakres wpływu dostawcy.

Koncepcja wyjścia określa, które klucze można wyeksportować, które dane trzeba by ponownie zaszyfrować i które usługi należy zastąpić. Obejmuje to również terminy, potwierdzenia usunięcia oraz zależności od kopii zapasowych. W ramach projektu uzgadniamy osiągalne cele eksploatacyjne oraz sprawdzamy ponowne uruchomienie i odebranie uprawnień. Ogólna deklaracja pełnej przenośności bez takiej weryfikacji nie byłaby wiarygodna.

AWS CloudHSM i Azure Key Vault Managed HSM reprezentują różne modele integracji i eksploatacji. AWS CloudHSM oferuje podłączenia klienckie HSM dla odpowiednio przystosowanych aplikacji, natomiast Azure Managed HSM udostępnia zarządzaną usługę kluczy z integracją z Azure. Sprawdzamy API, typy kluczy, tożsamości i model odtwarzania dla każdego obciążenia (workload) z osobna. Przejście na inną usługę nie sprowadza się więc do wymiany adresu serwera. Decydujące jest to, czy konkretna aplikacja i wymagany zakres kontroli pasują do danej usługi.

Bring Your Own Key (BYOK) oznacza przede wszystkim wprowadzenie własnego materiału kluczowego do obsługiwanej usługi. Samo to nie odpowiada na pytanie, kto może inicjować operacje na kluczach ani gdzie przetwarzane są dane w postaci jawnej. Przy zewnętrznym zarządzaniu kluczami dochodzą dodatkowe zależności techniczne, na przykład zewnętrzna usługa realizująca określone operacje udostępniania lub rozpakowywania kluczy. Dokumentujemy te granice zaufania i testujemy również celowe odebranie uprawnień. Funkcje i ograniczenia są sprawdzane dla konkretnej usługi chmurowej.

Istniejąca aplikacja ma zostać przeniesiona, a obsługa jej kluczy ma pozostać pod kontrolą. OTOKO® sprawdza najpierw, czy można nadal wykorzystywać istniejący interfejs, czy konieczne jest jego dostosowanie. W ramach pilotażu mierzymy czasy odpowiedzi z sieci docelowej, sprawdzamy rozdzielone role administratorów i testujemy odtwarzanie. Koncepcja wyjścia opisuje zarówno klucze możliwe do wyeksportowania, jak i przypadki, w których konieczne byłoby wygenerowanie nowych kluczy i konwersja danych. W ten sposób powstaje model eksploatacji z określonymi zakresami odpowiedzialności.