Dostęp partnera do HSM przez VPN: zdefiniuj operacje na kluczach

Ktoś po stronie partnera musi podpisać dokument jednym wskazanym kluczem, a prośba przychodzi sformułowana jako sprawa sieciowa: muszą dotrzeć do HSM. Traktuj to zdanie jako objaw niezdefiniowanej umowy serwisowej, a nie problem routingu, ponieważ tunel, który dociera do urządzenia, sam z siebie niczego nie daje. Za prośbą stoją trzy bramy: osiągalność, tożsamość HSM i polityka kluczy, a każdą z nich administruje się w innym miejscu przez inny zespół. Zapisz je po kolei, inaczej skończysz, przyznając trasę, bo rozmowa o certyfikacie była trudniejsza.

Miej przed oczami konkretny przypadek: partner składa zatwierdzony dokument do podpisu jednym nazwanym kluczem i nic więcej. Wszystko poniżej wynika z tego jednego zdania.

Osiągalność, tożsamość i polityka kluczy to trzy bramy

Koncentrator VPN decyduje, kto może otworzyć tunel i których adresów może dotykać. HSM sam decyduje, który rekord użytkownika mu przedstawiony może się zalogować. Polityka kluczy decyduje następnie, co ten rekord użytkownika może zrobić z jednym konkretnym kluczem. Przejście pierwszej bramy pozostawia pozostałe dwie dokładnie takie, jakie były, dlatego udany uścisk dłoni dowodzi tak niewiele i dlatego partner może dotrzeć do urządzenia, a mimo to ponieść porażkę w każdej operacji.

Przypisz każdą bramę do właściciela, zanim napiszesz wymagania. Gdy nikt nie jest właścicielem drugiej, zwykłym skutkiem jest wydanie szerokiej tożsamości administratora HSM, bo to jedyne poświadczenie, które działa.

Pierwsza brama: ścieżka sieciowa, którą otrzymuje partner

Wskaż zatwierdzonego klienta lub usługę, potrzebny jej cel oraz protokół i port, na których ta usługa nasłuchuje. Następnie ogranicz dostęp od strony VPN do tej pary w obu kierunkach, łącznie ze ścieżką powrotną, aby polityka była zdaniem, które możesz odczytać partnerowi. Administracja bramy, interfejsy zarządzania HSM i niepowiązane systemy wewnętrzne powinny znajdować się poza zwykłym dostępem partnera, a nie tylko poza trasą domyślną.

Wydzielony segment czyni te przejścia widocznymi, ale nazwa segmentu niczego nie egzekwuje. Ruch musi przechodzić przez kontrolę, przez którą, jak sądzisz, przechodzi. Dopuszczenie połączenia od partnera nie jest też stwierdzeniem, że każda maszyna u partnera jest godna zaufania.

Druga brama: co naprawdę uwierzytelnia się w HSM

Tożsamość VPN i tożsamość HSM to odrębne obiekty, chyba że obsługiwana integracja celowo je łączy. W przypadku klienta PKCS#11 aplikacja loguje się do slotu poświadczeniem przechowywanym gdzieś na hoście partnera i to właśnie to logowanie ocenia HSM.

AWS CloudHSM jest użytecznym punktem odniesienia, ponieważ jego dokumentacja trzyma oba oddzielnie: użytkownicy HSM różnią się od użytkowników IAM, a typ użytkownika określa, co konto może robić. Oficer kryptograficzny zarządza użytkownikami i kluczami, ale nie jest tożsamością wykonującą operacje kryptograficzne, natomiast użytkownik kryptograficzny może używać kluczy, nie mogąc nimi zarządzać. Ten podział to kształt, którego chcesz także na urządzeniu innego dostawcy, gdzie nazwy ról będą inne.

Niezależnie od tego, jaką tożsamość wydasz, musi być usuwalna i przypisywalna w tej szczegółowości, której później będziesz potrzebować. Jedno współdzielone poświadczenie operacyjne u kilku partnerów utrudnia ograniczanie i odpowiedzialność właśnie w incydencie, w którym oba są najważniejsze.

Trzecia brama: który klucz i która operacja

Podpisywanie, odszyfrowywanie, generowanie kluczy, pakowanie kluczy i administracja użytkownikami to odrębne uprawnienia i muszą być wymienione osobno. W terminach PKCS#11 atrybuty takie jak CKA_SENSITIVE i CKA_EXTRACTABLE opisują, czy materiał klucza może opuścić moduł w użytecznej formie, i są ustawiane na klucz, a nie na urządzenie. Przeczytaj rzeczywistą politykę na kluczu, zamiast wnioskować o nieeksportowalności ze słowa sprzęt albo z obecności tunelu.

Następnie znajdź zatwierdzenie biznesowe. Jeśli podpisywać można tylko zatwierdzone dokumenty, który komponent ustala to zatwierdzenie, zanim żądanie dotrze do HSM? Interfejs kryptograficzny, który przyjmuje autoryzowane żądanie, nie ma pojęcia, czy dokument został sprawdzony, więc ta kontrola należy do usługi przed nim.

Dozwolony klient, który zostanie przejęty, może też nadużyć operacji, do których jego poświadczenie legalnie upoważnia, nigdy nie wydobywając klucza prywatnego. Ochrona przechowywanego materiału klucza i kontrola użycia kluczy to więc dwa warunki akceptacji, a nie jeden.

Odmowy są częścią testu akceptacyjnego

Zaakceptuj dozwolone żądanie podpisu i zaakceptuj także odmowy: nieuprawnioną tożsamość, niepowiązany klucz i operację zarządzania ze ścieżki partnera. Zapisuj wywołującego, operację, identyfikator klucza, czas i wynik, a prywatny materiał klucza, poświadczenia i treść dokumentów trzymaj poza ogólnymi logami diagnostycznymi.

Wyznacz właściciela wyjścia partnera, podejrzenia naruszenia po stronie partnera oraz zmian polityki i odzyskiwania. Zmiana trasy nie przywraca zaufania do hosta, który może już być przejęty, więc cofnięcie musi dotrzeć także do tożsamości HSM.

Zakończony uścisk dłoni VPN należy do tego rejestru. Nie może zastąpić ani jednego wyniku specyficznego dla HSM.