Każda firma ma taką jedną: wewnętrzną aplikację webową, na której opiera się połowa działalności, której dostawca dawno zniknął z rynku albo do której kodu nikt nie odważy się już zajrzeć, a którą audytor każe teraz zabezpieczyć uwierzytelnianiem wieloskładnikowym.
Nie musisz jej modyfikować. Nie musisz nawet wiedzieć, w jakim języku ją napisano. Sztuczka polega na tym, by potraktować aplikację jak czarną skrzynkę i umieścić uwierzytelnianie przed nią: reverse proxy, który mówi w SAML i jest podłączony do usługi Notakey SSO. Każdy użytkownik musi wtedy potwierdzić logowanie dotknięciem ekranu telefonu, zanim do aplikacji dotrze choćby jedno żądanie.
Jak to działa
Browser ──▶ reverse proxy (Apache + mod_auth_mellon) ──▶ legacy app
│
└──SAML──▶ Notakey SSO (IdP) ──▶ push ──▶ user's phone- Przeglądarka żąda chronionego adresu URL. Proxy nie znajduje sesji SAML i przekierowuje do dostawcy tożsamości, czyli usługi SSO dostarczanej wraz z Notakey Appliance.
- Użytkownik podaje nazwę użytkownika, a serwer uwierzytelniania wysyła na jego telefon powiadomienie push z prośbą o potwierdzenie.
- Po potwierdzeniu przeglądarka wraca z podpisaną asercją SAML. Proxy weryfikuje podpis i dopiero wtedy przepuszcza żądania do aplikacji.
Sama aplikacja pozostaje niezmieniona. Jeśli ma własny ekran logowania, ten zostaje bez zmian. To rozwiązanie dokłada bramę z przodu, a nie zastępuje tego, co znajduje się za nią.
Jedna reguła, która czyni to bezpiecznym
Proxy chroni tylko to, czego nie da się obejść. Stara aplikacja musi być nieosiągalna inaczej niż przez proxy: wewnętrzna reguła zapory sieciowej albo, w przypadku aplikacji w kontenerze, osobna sieć Docker to stały element konfiguracji, a nie opcjonalny dodatek. Jeśli użytkownicy nadal mogą sięgnąć wprost do adresu IP aplikacji, 2FA jest jedynie ozdobą.
Co jest potrzebne
- Notakey Authentication Appliance z uruchomioną, dołączoną usługą SSO oraz użytkownicy zarejestrowani w Notakey Authenticator
- Docker na dowolnym hoście, który może połączyć się z aplikacją
- Rekordy DNS i certyfikaty TLS dla nowej, wysuniętej na front nazwy hosta
Konfiguracja w pięciu krokach
Pełny przewodnik do skopiowania i wklejenia, z plikami konfiguracyjnymi Apache i każdym poleceniem, znajdziesz w naszym repozytorium blackbox-webapp-2fa-howto. W zarysie:
- Wygeneruj certyfikaty i metadane SAML SP za pomocą
mellon_create_metadata.sh(jedno polecenie Docker). - Pobierz metadane IdP ze swojej usługi SSO.
- Dostosuj przykładową konfigurację Apache: swoją nazwę hosta, adres URL backendu, ścieżki do certyfikatów.
- Uruchom kontener proxy i sprawdź jego logi.
- Zarejestruj proxy jako dostawcę usług na stronie federacji SSO.
Urządzenie przekształca metadane SP w gotowe polecenie
ntk cfg set.
Wejdź pod nowy adres aplikacji, potwierdź powiadomienie push i patrzysz na swoją nienaruszoną starą aplikację, teraz chronioną silnym uwierzytelnianiem.
Repozytorium opisuje też opcjonalny wariant: uruchomienie proxy bezpośrednio na węzłach urządzenia, z wykorzystaniem ich istniejących certyfikatów TLS lub konfiguracji ACME. Wtedy w ogóle nie potrzebujesz osobnego hosta.
Gdzie to pasuje
To wzorzec dla wszystkiego, co mówi po HTTP. Pozostałą część starszej infrastruktury to samo urządzenie zabezpiecza od strony innych drzwi:
- VPN 2FA z RADIUS: dla koncentratorów VPN i wszystkiego, co obsługuje RADIUS
- Windows Credential Provider dla pulpitu zdalnego: dla logowania w Windows
- Linux SSH 2FA z pam_radius: dla samych serwerów