Cloud IdP kontra tradycyjne Active Directory: czego właściwie potrzebujemy?

Czym jest tradycyjne Active Directory

Active Directory Domain Services, zwykle skracane do Active Directory albo AD, to oprogramowanie Microsoftu, które obsługuje sieci firmowe od mniej więcej roku 2000. Działa na serwerach zwanych kontrolerami domeny, które fizycznie stoją w twoim biurze, w serwerowni albo szafce, i przechowuje główną listę twoich użytkowników, komputerów oraz reguł, które nimi rządzą.

Kluczowe pojęcie to domena: zarządzana sieć lokalna, do której należą komputery i użytkownicy. Komputer z Windows jest dołączony do domeny, czyli zarejestrowany w tej sieci lokalnej i jej ufa. Gdy pracownik loguje się przy biurku, kontroler domeny w sieci biurowej sprawdza jego hasło i zwraca uprawnienia do serwerów plików, drukarek sieciowych i innych zasobów w tej samej sieci (Microsoft Learn).

Kilka terminów, które napotkasz:

• Kontroler domeny: serwer z Active Directory, który uwierzytelnia użytkowników i komputery w sieci lokalnej. Firmy zwykle utrzymują więcej niż jeden, dla odporności na awarie.
• Dołączony do domeny: (zwykle Windowsowy) komputer zarejestrowany w domenie lokalnej, dzięki czemu ufa Active Directory i jest przez nie zarządzany.
• Group Policy: mechanizm, którego AD używa do wymuszania ustawień i reguł na komputerach z Windows dołączonych do domeny, na przykład wymuszania blokady ekranu albo instalowania oprogramowania.
• LDAP i Kerberos: starsze protokoły katalogowe i uwierzytelniania, na których opiera się AD. Zostały zaprojektowane dla zaufanej sieci lokalnej, nie otwartego internetu.

Prosta wersja: tradycyjne Active Directory to mózg sieci biurowej. Działa świetnie, gdy twoi ludzie, ich komputery z Windows i twoje serwery siedzą w tej samej sieci fizycznej albo prywatnej. Zostało zaprojektowane, żeby zabezpieczać tę lokalną sieć, nie zespół rozproszony po domowych biurach i prywatnych urządzeniach (Microsoft Learn).

Czym jest cloud IdP

Cloud IdP to usługa tożsamości dostarczana przez internet, prowadzona przez dostawcę, nie przez ciebie. Najbardziej znane to Microsoft Entra ID (dawniej Azure Active Directory, dołączone do Microsoft 365), Google Workspace i Okta. Nie ma serwerów, które musiałbyś instalować, łatać czy utrzymywać. Logujesz się do konsoli administracyjnej w przeglądarce, a usługa robi resztę.

Jego zadaniem jest uwierzytelnianie ludzi do aplikacji chmurowych. Gdy ktoś otwiera aplikację służbową, cloud IdP sprawdza, kim jest, i poświadcza to tej aplikacji, używając protokołów epoki internetu, którymi mówią nowoczesne aplikacje (SAML i OpenID Connect, zbudowane na OAuth). Co kluczowe, robi to dla dowolnego urządzenia w dowolnej lokalizacji: laptopa w domu, telefonu w podróży, własnej maszyny kontraktora. Nie ma wymogu, żeby urządzenie było dołączone do sieci biurowej, bo w tym obrazie nie ma żadnej sieci biurowej (Microsoft Learn).

Ponieważ każde logowanie przepływa przez jedno miejsce, cloud IdP to miejsce, w którym wymuszasz kontrole, na których naprawdę zależy:

• Uwierzytelnianie wieloskładnikowe (MFA): drugi dowód tożsamości przy logowaniu, zwykle stuknięcie w telefonie albo kod, dzięki czemu samo skradzione hasło nie wystarczy.
• Dostęp warunkowy: reguły typu „blokuj logowania z nierozpoznanego urządzenia albo kraju", stosowane we wszystkich podłączonych aplikacjach.
• Single sign-on (SSO): jedno logowanie, które otwiera wiele aplikacji, dzięki czemu ludzie nie trzymają osobnego hasła do każdego narzędzia.
• Provisioning i deprovisioning: tworzenie dostępu dla nowej osoby i wyłączanie go dla osoby odchodzącej, najlepiej z jednego ekranu.

Prosta wersja: cloud IdP to drzwi wejściowe i lista gości dla firmy, której praca żyje w chmurze, dostępne z dowolnego miejsca, bez niczego, co musisz hostować.

Czym się różnią

To nie to samo rozwiązanie hostowane w innym miejscu. Zostały zaprojektowane dla różnych światów: Active Directory, żeby zabezpieczać lokalną sieć biurową, cloud IdP, żeby obsłużyć hybrydowy, zdalny, chmurowy zespół. Microsoft Entra ID nie używa protokołów LDAP ani Kerberos z AD i nie jest bezpośrednim zamiennikiem lokalnego Active Directory (Microsoft Learn). Tabela poniżej pokazuje, gdzie te rozwiązania się rozchodzą.

• Gdzie działa · Tradycyjne Active Directory (lokalne): Serwery (kontrolery domeny) fizycznie w twoim biurze · Cloud identity provider: Usługa dostawcy, dostarczana przez internet
• Kto to utrzymuje · Tradycyjne Active Directory (lokalne): Ty: instalujesz, łatasz, robisz backup i utrzymujesz serwery · Cloud identity provider: Dostawca, ty konfigurujesz w przeglądarce
• Co loguje · Tradycyjne Active Directory (lokalne): Głównie komputery z Windows dołączone do domeny lokalnej · Cloud identity provider: Dowolne urządzenie, wszędzie: laptop, telefon, własna maszyna kontraktora
• Gdzie muszą być użytkownicy · Tradycyjne Active Directory (lokalne): W sieci biurowej albo połączeni tunelem przez VPN · Cloud identity provider: Wszędzie, gdzie jest internet
• Protokoły · Tradycyjne Active Directory (lokalne): LDAP, Kerberos, NTLM (zbudowane dla zaufanej sieci lokalnej) · Cloud identity provider: SAML, OpenID Connect, OAuth (zbudowane dla aplikacji internetowych)
• Co zabezpiecza najlepiej · Tradycyjne Active Directory (lokalne): Serwery plików, drukarki sieciowe, zasoby Windows na miejscu · Cloud identity provider: Aplikacje chmurowe i SaaS (Microsoft 365, Google, Salesforce i inne)
• Silniejsze logowanie (MFA) · Tradycyjne Active Directory (lokalne): Nie natywnie, wymaga dodatkowych produktów · Cloud identity provider: Wbudowane, wymuszane we wszystkich podłączonych aplikacjach z jednego miejsca
• Zmiany przy przyjęciu i odejściu · Tradycyjne Active Directory (lokalne): Zarządzane w domenie lokalnej, zdalny dostęp wymaga dodatkowej infrastruktury · Cloud identity provider: Zarządzane centralnie, można wyłączyć cały dostęp chmurowy naraz
• Koszt i wysiłek początkowy · Tradycyjne Active Directory (lokalne): Sprzęt serwerowy, licencje i bieżąca administracja · Cloud identity provider: Zwykle wliczone w subskrypcję, którą możesz już opłacać
• Najlepsze dopasowanie · Tradycyjne Active Directory (lokalne): Firmy ze znaczącą infrastrukturą na miejscu i lokalnymi aplikacjami Windows · Cloud identity provider: Firmy chmurowe i zdalne działające na SaaS

Dwie różnice mają największe znaczenie dla nowoczesnej firmy. Pierwsza to lokalizacja: AD zakłada, że użytkownik, jego komputer i zasoby żyją w jednej sieci, więc w pełni zdalny zespół trzeba łączyć tunelem przez VPN, co oznacza dodatkowy koszt i tarcie. Cloud IdP po prostu działa z dowolnego miejsca. Druga różnica to to, gdzie faktycznie żyją twoje aplikacje. Jeśli niemal wszystko, czego używa twój zespół, to aplikacja chmurowa, lokalny katalog zabezpiecza zasoby, których być może już nie masz, zostawiając poza swoim zasięgiem SaaS, na którym opiera się twój biznes.

Co oznacza „hybrydowy"

Hybrydowy to środek: uruchamiasz oba rozwiązania naraz. Lokalne Active Directory dalej zarządza twoimi serwerami i komputerami z Windows dołączonymi do domeny, a jednocześnie jest zsynchronizowane z cloud IdP, dzięki czemu ta sama osoba ma jedną tożsamość w obu światach. Loguje się raz i dociera zarówno do serwera plików na korytarzu, jak i do Microsoft 365 w chmurze. Ta praktyka nazywa się tożsamością hybrydową (Microsoft Learn).

Firmy dochodzą do modelu hybrydowego z powodów, które łatwo zrozumieć. Mają za sobą lata inwestycji w lokalne Active Directory albo aplikacje legacy i lokalne, które wciąż potrzebują starszych protokołów domenowych, żeby działać. Synchronizacja z chmurą pozwala im wdrożyć aplikacje chmurowe i logowania przyjazne pracy zdalnej bez wyrywania starego katalogu pierwszego dnia.

Ważnym niuansem jest kierunek. Microsoft ujmuje lokalne Active Directory w konfiguracjach hybrydowych jako funkcję przejściową i sposób na wsparcie obciążeń legacy, nie jako stałe miejsce docelowe, przy szerszym ruchu w stronę tożsamości natywnie chmurowej (Microsoft Learn). Dla większości organizacji hybrydowy to etap podróży, nie meta. Firma bez lokalnego środowiska legacy do zmostkowania zwykle nie ma powodu, żeby w ogóle wchodzić w model hybrydowy, bo nie ma nic po „starej" stronie do zsynchronizowania.

Dlaczego firma digital-first zwykle nie potrzebuje lokalnego AD

To ta część, która zaskakuje ludzi. Firma założona w erze chmury, ze zdalnym albo hybrydowym zespołem, laptopami zamiast stacjonarnych komputerów i pracą żyjącą w Microsoft 365 albo Google Workspace plus stos aplikacji SaaS, zwykle w ogóle nie potrzebuje tradycyjnego lokalnego Active Directory.

To rozumowanie wynika z tego, do czego służy AD. Jego mocne strony to zarządzanie komputerami z Windows dołączonymi do domeny w sieci lokalnej i zabezpieczanie zasobów na miejscu, jak serwery plików i drukarki sieciowe. Firma digital-first często nie ma niczego z tego: pliki żyją w chmurowym storage, nie ma biurowej serwerowni, a ludzie pracują z urządzeń, które nigdy nie dotykają sieci biurowej. Postawienie kontrolerów domeny, żeby zarządzać siecią, która nie istnieje, dodaje koszt, sprzęt i obciążenie administracyjne przy niewielu rzeczach do zabezpieczenia.

Tym, czego taka firma naprawdę potrzebuje, jest cloud IdP jako drzwi wejściowe do jej aplikacji chmurowych, i najprawdopodobniej już go posiada. Jeśli płacisz za Microsoft 365, masz w zestawie Microsoft Entra ID. Jeśli działasz na Google Workspace, masz jego platformę tożsamości. Decyzja rzadko brzmi „AD czy cloud IdP". Zwykle brzmi „już mamy cloud IdP, czy używamy go jako prawdziwych drzwi wejściowych, z każdą ważną aplikacją podłączoną i wymuszonym MFA". Tam siedzi bezpieczeństwo i wartość. Towarzyszący przewodnik po wyborze, „Przewodnik po wyborze dostawcy tożsamości i SSO", opisuje krok po kroku, jak wybrać albo skonsolidować tego dostawcę.

Wciąż istnieją sytuacje, w których lokalne albo hybrydowe rozwiązanie ma sens: zakład produkcyjny albo biuro z dużą infrastrukturą Windows na miejscu, aplikacje biznesowe zależne od starych protokołów domenowych albo regulowane środowisko, które nakazuje lokalną kontrolę. Ale to wyjątki dla biznesu digital-first, nie domyślny scenariusz. Jeśli nie potrafisz wskazać lokalnych serwerów i komputerów dołączonych do domeny, którymi naprawdę trzeba zarządzać, prawdopodobnie nie potrzebujesz domeny.

Jak rozpoznać, którego rozwiązania faktycznie potrzebujesz

Krótki zestaw pytań zwykle rozstrzyga sprawę bez konieczności wchodzenia w szczegóły techniczne.

• Gdzie żyją twoje pliki i aplikacje? Jeśli uczciwa odpowiedź brzmi „Google Drive, SharePoint albo OneDrive i lista narzędzi SaaS", twój środek ciężkości to chmura, i cloud IdP jest właściwym dopasowaniem. Jeśli masz lokalne serwery plików i aplikacje na miejscu, to wskazuje na AD albo hybrydowy model.
• Masz serwery biurowe i komputery dołączone do domeny? Brak serwerowni i laptopy, które nigdy nie dotykają sieci biurowej, wyraźnie wskazują na chmurę. Prawdziwe lokalne środowisko Windows to główny powód, żeby zachować AD.
• Jak pracuje twój zespół? Zdalnie albo hybrydowo, na różnych urządzeniach, sprzyja cloud IdP. Wszyscy przy biurkach w jednej sieci, codziennie, to klasyczny obraz AD.
• Już płacisz za Microsoft 365 albo Google Workspace? To już masz cloud IdP. Pierwszym ruchem jest użycie go jako drzwi wejściowych, nie kupowanie ani budowanie czegokolwiek.
• Masz konkretną aplikację legacy, która potrzebuje starych protokołów domenowych? Ta jedna zależność jest często jedynym realnym argumentem za zachowaniem lokalnego AD, i zwykle oznacza to hybrydowy model, nie czyste rozwiązanie lokalne.

Jeśli odpowiedzi grupują się po stronie chmury, patrzysz na cloud IdP i prawdopodobnie już go masz. Jeśli grupują się po stronie infrastruktury lokalnej, w grę wchodzi AD albo hybrydowy model, a pytanie brzmi, ile z tego wciąż potrzebujesz.

Źródła

• Microsoft Learn, Compare Active Directory to Microsoft Entra ID (różne rozwiązania dla różnych światów, Entra ID nie używa LDAP ani Kerberos i nie jest bezpośrednim zamiennikiem AD DS) · https://learn.microsoft.com/en-us/entra/fundamentals/compare
• Microsoft Learn, Compare Microsoft directory-based services (AD DS jako lokalny katalog LDAP/Kerberos, Entra ID jako tożsamość chmurowa dla SaaS i Microsoft 365) · https://learn.microsoft.com/en-us/entra/identity/domain-services/compare-identity-solutions
• Microsoft Learn, Hybrid identity with Active Directory and Microsoft Entra ID (tożsamość hybrydowa, synchronizacja lokalnego AD z chmurą, przejściowe pozycjonowanie lokalnego AD) · https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access-active-directory-hybrid-identity
• Microsoft Learn, Overview of Microsoft Entra Domain Services (Domain Services jako przejściowe wsparcie dla uwierzytelniania legacy, nie ogólny zamiennik lokalnego AD ani tożsamości natywnie chmurowej) · https://learn.microsoft.com/en-us/entra/identity/domain-services/overview
• Verizon 2026 Data Breach Investigations Report (nadużycie danych uwierzytelniających w 39% naruszeń w pełnym łańcuchu ataku) · https://www.verizon.com/business/resources/reports/dbir/