Kod tokena, karta inteligentna czy klucz FIDO: co akceptuje VPN

Trzy urządzenia z tym samym złączem i tym samym kółkiem na klucze biorą udział w trzech niepowiązanych wymianach. Jedno pokazuje kod sprawdzany przez serwer, drugie podpisuje kluczem, który nigdy nie opuszcza urządzenia, a trzecie zatwierdza logowanie w przeglądarce przez własny protokół. Pytanie, czy VPN powinien używać certyfikatów, czy tokenów sprzętowych, porównuje więc format z klasą urządzeń. Odpowiedź zależy od tego, który z trzech faktycznie kupiłeś.

Nazwij dowód przed urządzeniem

Jednorazowy token kodowy tworzy wartość, którą usługa uwierzytelniania weryfikuje własnym mechanizmem. VPN może dotrzeć do tej usługi przez RADIUS lub federacyjnego dostawcę tożsamości, a token nigdy nie musi przechowywać niczego, co należy do samego tunelu. Dowodzi tego, że osoba ma urządzenie generujące kod. Nie dowodzi niczego o maszynie, na której wpisano kod.

Token w stylu karty inteligentnej przechowuje klucz prywatny i wykonuje operację podpisu na żądanie, w ten sposób tożsamość certyfikatu jest dowodzona bez eksportu klucza. Certyfikat obok jest materiałem publicznym, a wydanie tego certyfikatu to zupełnie inna czynność niż wydanie klucza.

Klucz FIDO mówi znowu trzecim protokołem. Logowanie w przeglądarce może go użyć u dostawcy tożsamości, ale sukces na tej stronie nie oznacza, że ten sam klucz pojawi się przez interfejs karty inteligentnej klienta VPN.

Niektóre urządzenia implementują kilka z tych aplikacji obok siebie, i dokumentacja producenta właśnie dlatego wymienia tryby osobno. Nie jest to dowód, że każdy klucz na rynku obsługuje każdy tryb.

Sprzęt chroni klucz, a nie politykę

PIN na urządzeniu opartym na certyfikacie zwykle autoryzuje lokalne użycie klucza, i nie jest to hasło, które sprawdza system kont VPN. Wytyczne takie jak wytyczne NIST dotyczące authenticatorów nazywają to lokalne wejście sekretem aktywacji, odrębnym od samego authenticatora. Pewność pochodzi z całego projektu, a nie z liczby monitów na ekranie.

Rejestracja, odnowienie i usunięcie pozostają w każdym przypadku u właściciela tożsamości. Ktoś nadal decyduje, kto może się zarejestrować, wiąże poświadczenie z właściwą osobą i umożliwia wymianę, gdy urządzenie zostanie zgubione. Kupno nowego klucza nie unieważnia starego.

Opisz ceremonię logowania przed wyborem sprzętu: czy użytkownik wpisuje kod, odblokowuje klucz podpisu, czy zatwierdza monit przeglądarki? Każda odpowiedź oznacza innego klienta, inne ustawienie bramy i inny scenariusz pomocy technicznej.

Gdzie przepływy rozchodzą się w praktyce

Token kodowy jest najłatwiejszy do wdrożenia i najsłabszy wobec przekonującej podrobionej strony, ponieważ wpisany kod można przekazać w czasie rzeczywistym. Klucz oparty na certyfikacie opiera się tej klasie ataku i kosztuje więcej w eksploatacji, bo wydawanie i unieważnianie stają się częścią usługi. Klucz FIDO stoi przy logowaniu webowym i zależy wyłącznie od tego, czy dostawca tożsamości obsługuje go dla tej aplikacji.

Środowiska mieszane są częste i nie są automatycznie błędne: certyfikat dla tunelu plus token kodowy dla konsoli administracyjnej to spójny podział, pod warunkiem że oba są zarejestrowane wobec tej samej tożsamości. Psuje się podział, którego nikt nie udokumentował, gdy pomoc techniczna nie potrafi powiedzieć, jakiego czynnika brakuje użytkownikowi.

Uczyń decyzję konkretną

Zapisz ceremonię jako ciąg kroków wykonywanych przez prawdziwego użytkownika, a następnie sprawdź, czy klient, brama i dostawca tożsamości wszyscy obsługują ten ciąg. Niezgodność ujawnia się zwykle w ostatnim kroku, gdy klient w ogóle nie może zaadresować urządzenia.

Następnie potwierdź, co się dzieje, gdy urządzenie zostanie zgubione lub certyfikat wygaśnie. Jeśli ta odpowiedź nie jest zapisana, wdrożenie ma lukę, która zostanie odkryta w poniedziałek rano.

pkcs11-tool --list-slots
pkcs11-tool --list-objects --type cert