Zarządzać kluczami. Ograniczać dostęp.

Nowy klucz nie oznacza, że stary można od razu usunąć. Ustalamy, które dane, podpisy lub kopie zapasowe nadal zależą od wcześniejszych wersji. Aplikacje potrzebują jednoznacznego przypisania do wersji klucza. Generowanie, aktywacja, unieważnianie, archiwizacja i usuwanie otrzymują oddzielne stany i zatwierdzenia. Błędy, takie jak wyczerpane sesje, wygasłe logowania czy przerwane połączenia, są obsługiwane w sposób widoczny. Ponowne próby nie mogą tworzyć niepożądanych duplikatów kluczy ani merytorycznie zdublowanych operacji.

W teście sprawdzamy nie tylko udane wywołania, ale też odmowę dostępu dla nieuprawnionych ról i niedozwolone operacje. Środki dostępu i sekrety nie mogą trafiać do kodu źródłowego, logów ani ogólnych kopii zapasowych. Państwa zespół otrzymuje konfigurację, przykładowe scenariusze i procedurę diagnostyczną. Na początek istotne są stosowane biblioteki, środowiska uruchomieniowe i istniejące zasoby kluczy.

PKCS #11 opisuje dostęp do tokenów kryptograficznych i ich funkcji. KMIP dotyczy zarządzania obiektami kryptograficznymi między klientem a systemem zarządzania kluczami. Usługa chmurowa może z kolei oferować własne API REST. Nie wynika z tego automatyczna zamienność. OTOKO® dokumentuje, gdzie wykonywana jest operacja, jaki materiał kluczowy faktycznie przenosi dany interfejs i które atrybuty są zachowywane. Dzięki temu z listy protokołów powstaje przejrzysta ścieżka integracji.

Przy szyfrowaniu hierarchicznym klucze danych mogą chronić właściwe dane, podczas gdy klucz nadrzędny chroni te klucze danych. Dzięki temu nie każdy duży blok danych musi być przetwarzany przez HSM. Kluczowe znaczenie ma to, gdzie klucz danych jest potrzebny w postaci jawnej i jak długo pozostaje tam dostępny. Wyjaśniamy działanie pamięci podręcznej (cache), rotację i dostęp w aplikacji. Zdanie „Klucz pozostaje w HSM” jest wiarygodne wyłącznie dla konkretnie rozpatrywanej roli klucza i jej atrybutów.

Kilka usług korzysta dotąd z własnych plików kluczy. OTOKO® w pierwszej kolejności przyporządkowuje właścicieli, cele i zależności danych. Następnie testujemy obsługiwaną integrację reprezentatywnej usługi i definiujemy uprawnienia dla każdej aplikacji. Zmiana odbywa się etapowo, z kontrolowanym odczytem istniejących danych i zapisem danych nowych. Stare klucze są usuwane dopiero po uwzględnieniu przechowywania, kopii zapasowych i odtwarzania. Wynikiem jest udokumentowany zasób kluczy z przetestowanymi procedurami użytkowania i wymiany.