Odpowiedni HSM. Zanim Państwo zainwestują.

Architektura oddziela aplikacje, administrację, kopie zapasowe i przechowywanie kluczy. Partycja to rozdzielenie logiczne, ale nie zastępuje każdej formy rozdzielenia organizacyjnego czy fizycznego. Ustalamy, które klucze mogą być replikowane, kto może rozbudować klaster i jakie zależności istnieją między lokalizacjami. Jeśli HSM ulegnie awarii, aplikacja nie może niezauważenie przejść na niezabezpieczone pliki kluczy. Status certyfikatu i Security Policy są sprawdzane dla konkretnego modułu; nie wystarczy do tego sama nazwa produktu ani potwierdzenie walidacji algorytmu.

Przed ostatecznym zatwierdzeniem testujemy typowe operacje z docelowym podłączeniem klienta. Mierzone są przepustowość, opóźnienie i obsługa błędów w uzgodnionym profilu. Wynik zawiera założenia dotyczące wzrostu, licencji i eksploatacji. Na początek potrzebujemy przeglądu aplikacji, istniejących typów kluczy, wymagań co do lokalizacji oraz dowodów zgodności, które Państwa organizacja faktycznie musi spełnić.

HSM sieciowy może udostępniać scentralizowaną funkcję kryptograficzną wielu aplikacjom. Wówczas ścieżka sieciowa, uwierzytelnianie i rozdzielenie dzierżawców stają się częścią architektury. Karta PCIe wiąże funkcję ściślej z hostem; drugi komputer wymaga własnej koncepcji dostępności. W przypadku usługi zarządzanej sprawdzamy dostępne API oraz podział administracji. Tej decyzji nie podejmujemy wyłącznie na podstawie ceny zakupu: do porównania należą także nakład eksploatacyjny, dostępne lokalizacje, okna serwisowe i możliwość późniejszej zmiany.

Na potrzeby pilotażu opisujemy pełny proces biznesowy: które wywołanie trafia do HSM, ile wywołań powstaje na operację i kiedy odpowiedź uznaje się za zbyt późną? Oprócz wartości średnich rejestrujemy wysokie percentyle opóźnień i zachowanie przy skokach obciążenia. Test z pojedynczym podpisem nie odwzorowuje ani równoległych klientów, ani nawiązywania połączenia, ani awarii węzła. Otrzymują Państwo zmierzone warunki i pozostały zapas, dzięki czemu zakup opiera się na przejrzystym profilu obciążenia.

Kilka aplikacji ma w przyszłości podpisywać dane za pośrednictwem wspólnej infrastruktury. OTOKO® przypisuje aplikacjom klucze i zakresy odpowiedzialności, sprawdza wymagane mechanizmy i porównuje wspólną platformę z rozdzielonymi instancjami. W pilotażu testujemy nie tylko udane podpisy, ale też brakujące uprawnienia, wyczerpane zasoby sesji i wyłączenie węzła. Wynikiem jest wiarygodna decyzja architektoniczna uwzględniająca nakład na integrację, zapotrzebowanie na licencje i otwarte zależności, a nie ogólne zalecenie zakupu największego urządzenia.