dostęp warunkowy

Dostęp warunkowy (conditional access) to zestaw zasad, które przy każdej próbie dostępu oceniają kontekst: kto się loguje, skąd, z jakiego urządzenia, do jakiej aplikacji i z jakim ryzykiem. Na tej podstawie system wpuszcza, żąda dodatkowego potwierdzenia albo blokuje. Microsoft opisuje swój mechanizm jako moduł zasad Zero Trust, który łączy sygnały z różnych źródeł, by podejmować decyzje i wymuszać zasady organizacji ^[1]. Najbardziej znaną implementacją jest Conditional Access w Microsoft Entra ID, ale tę samą logikę realizują bramy dostępu i reguły przed panelami administracyjnymi.

Jak działa

Najprostsze zasady dostępu warunkowego mają postać instrukcji „jeśli–to”: jeśli użytkownik chce uzyskać dostęp do zasobu, musi wykonać określoną akcję ^[1]. Przykładem jest wymaganie, by każdy, kto otwiera Microsoft 365, przeszedł uwierzytelnianie wieloskładnikowe (MFA) ^[1].

Model ma korzenie w architekturze Zero Trust. Publikacja NIST SP 800-207 zakłada, że dostęp do zasobów jest określany przez dynamiczną politykę, uwzględniającą obserwowalny stan tożsamości klienta, aplikacji i urządzenia, a także inne atrybuty behawioralne i środowiskowe ^[2]. NIST dzieli mechanizm na role. Silnik polityki (PE) podejmuje ostateczną decyzję o przyznaniu, odmowie albo cofnięciu dostępu. Administrator polityki (PA) ją wykonuje. Punkt egzekwowania (PEP) otwiera, monitoruje i zamyka połączenie między podmiotem a zasobem ^[2].

RYS. 1Decyzja dostępu warunkowego

W Microsoft Entra zasady są wymuszane dopiero po zakończeniu uwierzytelniania pierwszym składnikiem ^[1]. Dokumentacja zaznacza, że dostęp warunkowy nie jest pierwszą linią obrony przed atakami odmowy usługi, choć może używać sygnałów z takich zdarzeń ^[1].

Składniki

Zasada składa się z sygnałów, czyli warunków, oraz decyzji. Microsoft wymienia jako typowe sygnały użytkownika albo grupę, lokalizację adresu IP, urządzenie, aplikację oraz ryzyko wykrywane w czasie rzeczywistym ^[1]. Administratorzy mogą definiować zakresy adresów IP dla całych krajów i regionów, by blokować albo dopuszczać ruch ^[1], co odpowiada pojęciu geoblokowanie.

Najbardziej restrykcyjną decyzją jest blokada. Łagodniejsza decyzja przyznaje dostęp pod warunkiem, na przykład uwierzytelnienia wieloskładnikowego, urządzenia oznaczonego jako zgodne albo zmiany hasła ^[1]. Cloudflare Access łączy kryteria operatorami logicznymi: reguła Include działa jak „lub”, Require jak „i”, a Exclude jak „nie” ^[3]. Brama tego typu stoi przed aplikacją i przyjmuje rolę punktu egzekwowania z modelu NIST ^[2].

Dostęp warunkowy zwykle działa razem z dostawcą tożsamości, czyli identity provider (IdP), i z logowaniem jednokrotnym SSO. Decyzja zapada w jednym miejscu, a obowiązuje w wielu aplikacjach.

W WordPressie

WordPress nie ma wbudowanego dostępu warunkowego. Podobną logikę można jednak zbudować na trzech poziomach.

Przed aplikacją. Brama dostępu albo WAF może obejmować ścieżki panelu, takie jak /wp-admin/ i wp-login.php. Polityki Cloudflare Access pozwalają dopuścić ruch według kraju, zakresu IP, adresu e-mail albo stanu urządzenia ^[3]. Panel WordPressa jest tu jedną z wielu aplikacji, które można tak chronić. Prostszą odmianą jest biała lista adresów IP.

Na serwerze. Poradnik utwardzania WordPressa zaleca dodatkowe hasło po stronie serwera dla katalogu /wp-admin/, jako drugą warstwę ochrony obszaru administracyjnego, oraz używanie HTTPS przy administracji ^[5]. Zob. zabezpieczenie katalogu hasłem.

W aplikacji. Filtr authenticate decyduje, czy podane dane logowania są prawidłowe; zwraca obiekt użytkownika albo błąd ^[4]. Dokumentacja wskazuje, że aby wywołać błąd logowania, trzeba zwrócić obiekt WP_Error ^[4]. Z tego punktu korzystają wtyczki, które dodają warunki, na przykład kraj, godzinę albo rolę. Szkic ilustracyjny:

add_filter( 'authenticate', function ( $user ) {
    if ( $user instanceof WP_User && user_can( $user, 'manage_options' )
         && ! moja_siec_zaufana( $_SERVER['REMOTE_ADDR'] ) ) {
        return new WP_Error( 'odmowa', 'Logowanie administratora tylko z sieci firmowej.' );
    }
    return $user;
}, 30 );

Funkcja moja_siec_zaufana() jest tu umowna. Warunek dotyczy tylko kont z uprawnieniem administracyjnym, co odpowiada zasadzie najmniejszych uprawnień. Trzeba też pamiętać o innych wejściach, takich jak XML-RPC i hasła aplikacji, które omijają formularz logowania.

Znaczenie

Dostęp warunkowy ogranicza skutki kradzieży hasła. Samo hasło nie wystarcza, jeśli logowanie pochodzi z nieznanego kraju albo urządzenia. Microsoft wymienia wśród najczęstszych zasad wymaganie MFA dla ról administracyjnych, blokowanie starszych protokołów uwierzytelniania i blokowanie ryzykownych logowań ^[1]. To bezpośrednio utrudnia przejęcie konta.

Mechanizm ma granice. Zasady są wymuszane przy logowaniu, po pierwszym składniku ^[1], więc same nie zastępują ochrony już wydanego tokenu sesyjnego, którego dotyczy między innymi phishing AiTM (adversary-in-the-middle). Źle ustawiona zasada może też zablokować właściciela, dlatego konta awaryjne i tryb samego raportowania są częścią wdrożenia. Entra pozwala tworzyć zasady działające tylko w trybie raportu ^[1].

Dobre praktyki

• Zaczynać od kont uprzywilejowanych: MFA i ograniczenie lokalizacji dla administratorów ^[1].
• Testować zasady w trybie raportu, zanim zaczną blokować ^[1].
• Zostawić udokumentowaną ścieżkę awaryjną, żeby błędna reguła nie odcięła wszystkich.
• Łączyć warunki z innymi warstwami: limit prób logowania, silnymi hasłami i monitoringiem logowań.
• W WordPressie objąć zasadą wszystkie wejścia: formularz, XML-RPC, REST API z hasłami aplikacji.
• Traktować dostęp warunkowy jako część modelu Zero Trust, w którym lokalizacja w sieci sama nie daje zaufania ^[2].