Kontrole odbiorcze dla wirtualnej bramy VPN z uwierzytelnianiem dwuskładnikowym
Udowodnij bramę etap po etapie: rejestracja, logowanie, odmowa, unieważnienie i przywrócenie, każdy z artefaktem i warunkiem zaliczenia zapisanym przed testem.
Dostawcy opisują to urządzenie jako wirtualne i zdolne do dwóch składników, a żadne z tych słów nie odpowiada na pytania, które decydują o zakupie. Jaki obraz hiperwizora jest obsługiwany, którzy klienci mogą się zarejestrować, co drugi składnik naprawdę dowodzi i co się dzieje, gdy dostawca tożsamości zawiedzie, wciąż pozostaje otwarte. Zamieńcie to na etapy odbioru, które możecie wykonać na próbie, a decyzja przestanie zależeć od tego, jak przekonująca jest karta danych. Poniższy arkusz jest strukturą tych dowodów, a nie rankingiem produktów.
Co dostawca musi potwierdzić w sprawie tego wdrożenia
Zacznijcie od sprowadzenia wdrożenia do jednej strony: hiperwizor lub chmura, architektura gościa, obsługiwany obraz i interfejsy, których oczekuje urządzenie. Dodajcie użytkowników z ich systemami operacyjnymi, informację, czy urządzenia są zarządzane, i jak mają działać rejestracja oraz logowanie. Następnie dostęp prywatny: aplikacje i prefiksy, układ DNS, ścieżki powrotne i czy publiczne wyjście do internetu jest częścią oferty.
Eksploatacja należy do tej samej strony: kto utrzymuje urządzenie, skąd pochodzą aktualizacje, dokąd trafiają dzienniki, jak chroniona jest konfiguracja i jaki cel odtworzenia firma naprawdę uzgodniła. Poproście dostawcę o potwierdzenie dokładnie tej kombinacji, a nie tego, że oprogramowanie działa w maszynie wirtualnej. Utrzymujcie widoczne zależności zewnętrzne, takie jak dostawca tożsamości czy usługa licencyjna, bo są częścią wdrożenia niezależnie od tego, czy są z nim dostarczane. Strona wdrożenia bez nazwanej zależności jest zwykle stroną wdrożenia z nieznaną zależnością.
Udowodnijcie, że drugi składnik jest drugim składnikiem
Nazwijcie uwierzytelniacz i przepływ weryfikacji oraz powiedzcie, jaką tożsamość ustanawia każdy krok. Dwa kolejne monity o hasło nie są drugim składnikiem, a hasło plus kod jednorazowy to inne twierdzenie niż kryptograficzny uwierzytelniacz powiązany z usługą. Zapiszcie przepływ, który kupujecie, a nie etykietę na pudełku.
Odporność na phishing jest osobną właściwością, a wytyczne NIST dotyczące uwierzytelniaczy traktują ją właśnie tak: kod, którego użytkownika można nakłonić do przekazania, nadal spełnia uwierzytelnianie wieloskładnikowe, ale nie spełnia tego dodatkowego warunku. Zażądajcie tej właściwości wprost, jeśli jest dla was ważna. Potem zażądajcie demonstracji na typie klienta, którego wasi użytkownicy naprawdę używają, obejmującej rejestrację, odrzucone lub wygasłe wyzwanie, odzyskanie po utracie uwierzytelniacza i unieważnienie jednego użytkownika, podczas gdy inni pozostają połączeni. Utrzymujcie weryfikację tożsamości bramy w zakresie, bo klient, który ufa dowolnej bramie, przeniósł problem, zamiast go rozwiązać.
Zapiszcie warunek zaliczenia, zanim cokolwiek zepsujecie
Poniższa tabela to ta część arkusza, która przetrwa kontakt z dostawcą, bo każdy wiersz prosi o artefakt, a nie o zapewnienie. Wypełnijcie warunek zaliczenia przed próbą i traktujcie wiersz bez dowodów jako wiersz niezaliczony. Pięć etapów obejmuje to, co brama musi zrobić.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
Rejestracja jest pierwsza, bo wszystko dalsze od niej zależy: urządzenia, którego nie można zarejestrować, nie można przetestować. Logowanie to osobny etap od rejestracji, a odmowa to etap, o którym większość arkuszy zapomina, bo brama, która wpuszcza wszystkich, nie wykazała, że komukolwiek odmawia. Unieważnienie i przywrócenie niosą większość ryzyka operacyjnego, a oba są tanie do przećwiczenia na kopii.
Ćwiczcie na kopii, nie na działającej bramie
Wykonajcie etapy zakłócające na kopii platformy, zgodnie z obsługiwaną procedurą wdrożenia, i zachowajcie każdy dowód z jego datą i wersją konfiguracji. Wiersz o restarcie nie zostaje zamknięty restartem z konsoli, a wiersz o przywróceniu nie zostaje zamknięty eksportem konfiguracji. Zanotujcie, który stan wraca sam, a co musi się połączyć ponownie, bo właśnie tę różnicę dziedziczy zespół operacyjny. Próba to także jedyna okazja, by zmierzyć przywrócenie bez tłumaczenia awarii.
Zapisujcie stan dostawcy tożsamości w chwili każdego testu, bo wiersz o awarii testowany wobec zdrowego dostawcy dowodzi czegoś przeciwnego niż twierdzi arkusz. Dwaj recenzenci na tej samej próbie wychwytują różne rzeczy, a drugi zwykle znajduje wiersz, którego dowodem jest zrzut ekranu pulpitu. Trzymajcie ten dowód przypięty do wiersza, do którego należy, a nie w folderze nazwanym od projektu.
Zmierzcie obciążenie, które będzie obsługiwać wasz zespół
Uzgodnijcie obciążenie przypominające normalny tydzień, a potem zmierzcie je tam, gdzie zamierzacie wdrażać: współbieżność, mieszankę ruchu i okno serwisowe, które zespół naprawdę ma. Reklamowana liczba przepustowości opisuje warunki laboratoryjne i nic nie mówi o waszych użytkownikach. Mierzcie przywrócenie wobec celu odtworzenia, a nie wobec planu.
Arkusz jest gotowy, gdy każdy etap ma artefakt, a każdy artefakt ma datę. Urządzenie, które ktoś utrzymuje, z dowodem dla każdego wiersza, to inny zakup niż najdłuższa lista odhaczonych pól.