Uwierzytelnianie dwuskładnikowe (MFA – Azure)

MFA w Azure wymaga drugiego składnika uwierzytelnienia przy logowaniu do usług chmurowych powiązanych z SQL Server.

Drugi składnik w logowaniu do usług Azure

Uwierzytelnianie dwuskładnikowe, określane skrótem MFA od angielskiego multifactor authentication, wymaga potwierdzenia tożsamości za pomocą co najmniej dwóch niezależnych elementów. Pierwszym elementem jest zwykle nazwa użytkownika wraz z hasłem, a drugim potwierdzenie wykonane inną metodą, na przykład w aplikacji Microsoft Authenticator, za pomocą klucza bezpieczeństwa FIDO2 albo kodu jednorazowego. Samo podanie hasła nie wystarcza wtedy do zakończenia logowania.

W środowisku Azure obsługę tożsamości zapewnia Microsoft Entra ID, wcześniej nazywany Azure Active Directory. MFA jest realizowane na poziomie tego dostawcy tożsamości, a nie przez pojedynczą tabelę lub procedurę w SQL Server. Po pomyślnym przejściu logowania i dodatkowego wyzwania usługa Azure wydaje token potwierdzający uwierzytelnienie. Aplikacja lub usługa chmurowa sprawdza ten token i na jego podstawie podejmuje decyzję, czy przyznać dostęp.

Powiązanie MFA z dostępem do SQL Server

W przypadku usług Azure współpracujących z SQL Server znaczenie ma sposób skonfigurowania uwierzytelniania. Azure SQL Database i Azure SQL Managed Instance mogą korzystać z uwierzytelniania Microsoft Entra ID, dzięki czemu tożsamość użytkownika jest sprawdzana przez Entra ID, a nie wyłącznie przez klasyczny mechanizm nazwy użytkownika i hasła zapisany w samej bazie. MFA może być wtedy wymagane przed uzyskaniem tokenu używanego do połączenia z usługą bazodanową.

Nie oznacza to jednak, że każde połączenie z dowolnym SQL Server automatycznie obsługuje MFA. Tradycyjne uwierzytelnianie SQL Server, oparte na loginie SQL i haśle, jest odrębnym mechanizmem. Również połączenie z lokalną instancją SQL Server przy użyciu klasycznego uwierzytelniania Windows nie staje się samo przez się logowaniem MFA tylko dlatego, że organizacja używa Azure. Aby drugi składnik był faktycznie sprawdzany, klient, sterownik, usługa bazodanowa i konfiguracja tożsamości muszą obsługiwać wybrany przepływ Microsoft Entra ID.

Przebieg uwierzytelniania i kontrola dostępu

Podczas logowania aplikacja kliencka kieruje użytkownika do mechanizmu uwierzytelniania Microsoft Entra ID. Po wpisaniu identyfikatora i hasła Entra ID ocenia zasady dostępu warunkowego. Reguła może wymagać MFA między innymi dla określonej aplikacji, grupy użytkowników, lokalizacji sieciowej, poziomu ryzyka lub typu urządzenia. Jeżeli zasada tego wymaga, użytkownik musi zatwierdzić żądanie w skonfigurowany sposób. Dopiero potem aplikacja otrzymuje token zawierający informacje potrzebne do dalszego dostępu.

Token nie zastępuje uprawnień wewnątrz bazy danych. Potwierdza tożsamość, ale dostęp do konkretnej bazy, schematu, tabeli lub operacji zależy od autoryzacji skonfigurowanej dla tej tożsamości. W środowisku Azure SQL administrator Microsoft Entra ID może utworzyć odpowiedni użytkownik lub podmiot zabezpieczeń w bazie, a następnie nadać mu role i uprawnienia. Zasada najmniejszych uprawnień oznacza, że konto powinno otrzymać tylko zakres dostępu wymagany do wykonywania określonych zadań.

Problemy z logowaniem mogą wynikać z różnych warstw konfiguracji. Błąd może oznaczać nieprawidłowe hasło, brak zarejestrowanej metody MFA, odrzucone żądanie w aplikacji Authenticator, niespełnienie reguły dostępu warunkowego, wygaśnięcie tokenu, niepoprawny wybór metody uwierzytelniania w kliencie albo brak uprawnień użytkownika w bazie. Dlatego sam komunikat o odmowie dostępu nie dowodzi awarii SQL Server. W diagnostyce należy rozdzielić etap uwierzytelnienia w Entra ID od późniejszej autoryzacji w usłudze bazodanowej.

Diagnostyka konfiguracji MFA dla połączeń bazodanowych

Analizę należy rozpocząć od ustalenia, z jaką usługą użytkownik próbuje się połączyć, jakiego klienta używa oraz jaki typ uwierzytelniania został wybrany. Istotne są między innymi wersja aplikacji klienckiej, obsługa logowania interaktywnego, używany sterownik oraz sposób przekazania tokenu do połączenia. Niektóre scenariusze wymagają otwarcia interaktywnego okna logowania, ponieważ użytkownik musi zatwierdzić MFA. Połączenie działające wcześniej z zapisanym hasłem może przestać działać po włączeniu reguły wymagającej drugiego składnika.

Warto sprawdzić dzienniki logowania Microsoft Entra ID, aby ustalić, czy żądanie zostało zaakceptowane, odrzucone przez zasady dostępu warunkowego, przerwane podczas weryfikacji lub zakończone błędem metody uwierzytelniania. Następnie należy zweryfikować, czy token został użyty do właściwej usługi i czy odpowiadająca mu tożsamość ma uprawnienia w bazie. Trzeba także odróżnić problemy z MFA od problemów sieciowych, takich jak niedostępny punkt końcowy, błędny adres serwera, blokada portu lub przerwane połączenie po uzyskaniu tokenu.

Przy wdrażaniu MFA trzeba uwzględnić również konta techniczne i automatyzację. Proces działający bez udziału człowieka może nie być zgodny z interaktywnym żądaniem drugiego składnika. W takim przypadku rozwiązanie wymaga zaprojektowania odpowiedniego modelu tożsamości i bezpiecznego przepływu tokenów zgodnego z obsługiwaną usługą, zamiast wyłączania MFA dla całego środowiska. Każdą zmianę należy sprawdzić na koncie testowym, potwierdzając osobno możliwość logowania, zakres uprawnień i poprawne działanie aplikacji korzystającej z SQL Server.