Dostęp VPN dla konta usługi: certyfikat czy wspólne logowanie
Porównaj certyfikat komputera z zapisanym hasłem dla bezobsługowego dostępu VPN i umieść rzeczywisty limit uprawnień w polityce uruchamianej po zalogowaniu.
Dwa projekty pokrywają niemal każdą bezobsługową konfigurację VPN: wspólne konto ludzkie trzymane w skrypcie albo certyfikat komputera przypisany do hosta. Zawodzą w różnych miejscach i to ma większe znaczenie niż szybkość wdrożenia. Zapisane hasło psuje się, gdy jego właściciel je zmieni lub odejdzie; certyfikat psuje się, gdy wygaśnie albo gdy host zostanie odtworzony bez klucza. Trzy warunki decydują o tym, który koszt możesz udźwignąć, a żaden z projektów niczego nie ogranicza, dopóki nie zrobi tego polityka autoryzacji.
Zacznij od zadania, nie od konta
Zadanie wyznacza granicę: jakie cele, jakie usługi, w jakich godzinach, jak długo może trwać sesja. Trasa tunelu to tylko połowa tej granicy. Brama decyduje, czy sesja jest dozwolona; zasób za nią decyduje, co sesja może zrobić. Najpierw zapisz listę, z nazwanym właścicielem, bo oba projekty tożsamości muszą ją spełniać.
Trzymaj uwierzytelnianie i autoryzację osobno, kiedy to zapisujesz. Uwierzytelnianie odpowiada, kto się łączy; autoryzacja odpowiada, do czego sesja może dotrzeć później. RADIUS przenosi drugą część jako atrybuty, takie jak Filter-Id, Framed-IP-Address, Session-Timeout i Class, a brama dołącza je, gdy logowanie się powiedzie. Projekt, który podmienia logowanie i zostawia autoryzację bez zmian, niczego nie ograniczył.
Wspólne konto ludzkie: hasło staje się granicą
Ponowne użycie konta ludzkiego to najszybsza droga i ta, która starzeje się najgorzej. Poświadczeniem jest hasło, więc trafia do skryptu, pliku środowiskowego i konfiguracji harmonogramu, a każda kopia wymaga rotacji. Gdy właściciel zmieni je w piątek, zadanie zawodzi przy następnym uruchomieniu i nikt tego nie obserwuje.
MFA to miejsce, w którym ten projekt zwykle się rozpada. Skrypt nie potrafi odpowiedzieć na prośbę push, więc konto zostaje wyłączone z polityki, a to dokładnie to konto, które wybrałby atakujący. Wyjątki, obejścia dla zaufanych lokalizacji i zwolnienia dla poszczególnych kont się mnożą, a żadne z nich nie jest widoczne dla następnej osoby czytającej ustawienia dzierżawy.
Atrybucja to drugi koszt. Każda sesja w logu bramy niesie tę samą nazwę użytkownika, więc nocnej synchronizacji nie da się odróżnić od pracy osoby, która ją napisała, a odwołanie zadania oznacza odwołanie tej osoby.
Certyfikat komputera: tożsamość przypisana do hosta
Certyfikat zmienia pytanie z tego, co wie konto, na to, czym jest host. W EAP-TLS klient przedstawia certyfikat i dowodzi posiadania pasującego klucza prywatnego; serwer polityk mapuje podmiot lub konto komputera na grupę i stosuje politykę dla tej grupy. Bez monitu, bez wspólnego sekretu leżącego w pliku tekstowym.
Granica, którą tworzy, jest węższa, niż ludzie oczekują. Certyfikat uwierzytelnia hosta, nie zadanie, a każdy z uprawnieniami roota lub lokalnego administratora może użyć tego klucza na tym hoście. Trzymaj klucz tam, gdzie platforma go chroni: nieeksportowalny w magazynie certyfikatów Windows, oparty na TPM tam, gdzie profil na to pozwala, albo plik 0600 należący do roota w Linuksie. Przejęcie hosta to przejęcie poświadczenia.
Wygaśnięcie to powracająca awaria. Certyfikat, który wygasa w niedzielę, zatrzymuje zadanie w niedzielę, a brama zwykle zgłasza ogólny błąd uwierzytelniania zamiast podać datę. Sprawdzaj daty z hosta zadania w ramach runbooka:
openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts
Odwołanie wymaga ścieżki, którą brama sprawdza. OpenVPN czyta CRL przez opcję crl-verify, a strongSwan zależy od CRL lub OCSP w zależności od tego, jak zbudowano profil połączenia. Jeśli żadne z nich nie jest podłączone, usunięcie hosta oznacza czekanie na wygaśnięcie certyfikatu.
Trzy warunki, które rozstrzygają między nimi
Porównuj z platformą, którą masz, a nie z projektem referencyjnym.
Pierwszy warunek: czy brama potrafi autoryzować tożsamość komputera? Jeśli mapuje tylko nazwę użytkownika RADIUS na użytkownika katalogu, certyfikat uwierzytelnia hosta, a potem zatrzymuje się na autoryzacji. Drugi warunek: czy zadanie potrzebuje dostępu do zasobów, który niesie tylko konto użytkownika, takich jak mapowany udział albo licencja na stanowisko? Wtedy tożsamość komputera nie zastąpi konta, a uczciwą odpowiedzią jest dedykowane konto użytkownika z ograniczoną polityką. Trzeci warunek: kto może rotować poświadczenie bez udziału człowieka? Automatyczna rejestracja czyni certyfikaty tanimi w utrzymaniu; hasło znane jednej osobie tego nie robi.
| Constraint | Machine certificate | Dedicated user account with stored secret |
|---|---|---|
| Unattended login | Private key proof, no prompt | Only if the account is exempted from MFA |
| Resource expects a user identity | Works only when the resource accepts computer accounts | Matches the access a person would have |
| Rotation | Re-enrollment, often automated | Secret change plus redeploy of every copy |
| Revocation speed | Tied to CRL or OCSP refresh | Disable the account, immediate |
Czytaj tabelę jako listę kosztów, nie jako ranking. Kolumna z zapisanym sekretem wygrywa szybkością odwołania i zgodnością z zasobami, które rozumieją tylko konta użytkowników; kolumna z certyfikatem wygrywa rotacją i tym, że nie osłabia MFA, by skrypt działał.
Umieść limit w polityce, po uwierzytelnieniu
Niezależnie od wybranej tożsamości limit uprawnień należy do polityki uruchamianej po uwierzytelnieniu. W NPS polityki sieciowe są oceniane po kolei i pierwsza polityka pasująca do wszystkich warunków stosuje swoje ustawienia, więc szeroka polityka umieszczona nad wąską rozstrzyga wynik, niezależnie od tego, co przedstawi klient. Microsoft opisuje model warunków i ustawień w swoim przeglądzie polityk NPS.
Daj zadaniu własną grupę lub warunek polityki, oparty na czymś, co niesie tożsamość komputera: szablonie certyfikatu, identyfikatorze stacji wywołującej albo adresie z dedykowanej puli. Potem ogranicz sesję atrybutami: Filter-Id dla roli, do której mapuje go brama, krótki Session-Timeout, aby zawieszone zadanie uwierzytelniło się ponownie zamiast trzymać sesję przez dni, oraz Framed-IP-Address z puli, którą filtrujesz zaporą po drugiej stronie. Autoryzacja aplikacji pozostaje osobno: tunel do serwera bazy danych nie jest pozwoleniem na czytanie tabeli w niej.
Sprawdź odmowy, a potem zaplanuj usunięcie
Dostęp, który działa, niczego nie dowodzi w kwestii minimalnych uprawnień. Zamiast tego testuj odmowy: połącz się z tożsamością zadania i sięgnij do celu spoza listy, otwórz drugą równoczesną sesję, jeśli brama ma pozwalać tylko na jedną, i powtórz logowanie po odwołaniu poświadczenia.
Potem potwierdź tę samą sesję w dwóch miejscach. Log bramy pokazuje tożsamość, która się uwierzytelniła; log serwera polityk pokazuje, która polityka pasowała i jakie atrybuty zwróciła. W OpenVPN serwer zapisuje nazwę common name certyfikatu, a ipsec statusall w strongSwan wypisuje ustanowiony tunel z używaną tożsamością. Jeśli oba logi różnią się co do tożsamości, polityka dopasowuje coś innego, niż zakładasz.
Usuwanie należy do projektu, nie do sprintu porządkowego. Zapisz wszystko do skasowania (certyfikat lub konto, członkostwo w grupie, polityka sieciowa, wpis w puli, reguła zapory na celu) i przejdź to raz, póki zadanie łatwo odtworzyć.
Jeśli zaczynasz dzisiaj, pracuj w tej kolejności: zapisz listę zasobów, wybierz tożsamość według trzech warunków, umieść limit w polityce i przećwicz jedną odmowę, zanim zadanie ruszy na produkcję.