Ataki i Obrona

W Microsoft Entra ID tenant to odizolowana instancja usługi IAM dla organizacji, obejmująca użytkowników, grupy, aplikacje, service principals oraz konfigurację zabezpieczeń. Jest powiązany z jednym katalogiem, identyfikowany przez tenant ID (GUID) i główną domenę (np. contoso.onmicrosoft.com).

Tenant określa, kto może się uwierzytelnić i jakie ma uprawnienia w Azure, Microsoft 365 i aplikacjach. Wszystkie subskrypcje i grupy zasobów muszą być przypisane do jednego tenanta; współdzielenie między tenantami wymaga konfiguracji cross‑tenant (np. B2B, guest access).

Zalecenie: Traktuj tenanta jako główną granicę bezpieczeństwa. Wymuś MFA, stosuj Conditional Access, PIM i Identity Protection, ograniczaj globalnych administratorów, regularnie audytuj ustawienia i monitoruj dostęp zewnętrzny.

W skrócie zapamiętaj:

• Tenant Oddzielna instancja Entra ID dla każdej organizacji.
• Zawiera użytkowników, grupy, aplikacje, konfiguracje.
• Jeden tenant = jedno środowisko zaufania.
• Zalecenie: traktuj tenant jako granicę bezpieczeństwa, chroń go MFA, PIM, Identity Protection.

W Microsoft Entra ID user to obiekt katalogu powiązany z konkretną osobą, zawierający jej dane (nazwa, stanowisko, kontakt) i unikalny, niezmienny Object ID (GUID). Ten identyfikator jest podstawą uwierzytelniania i nadawania uprawnień w Azure, Microsoft 365 i aplikacjach zaufanych dla danego katalogu.

Uwierzytelnienie odbywa się najczęściej przez User Principal Name (UPN) oraz poświadczenia takie jak hasło, klucz FIDO2, Windows Hello czy Microsoft Authenticator. Konto istnieje w jednym home tenant, ale może być dodane jako guest do innych tenantów w celu współpracy między organizacjami bez udostępniania haseł.

Uprawnienia użytkownika wynikają z ról Azure RBAC, ról Microsoft 365 i ról aplikacji przypisanych do jego Object ID. Ten sam identyfikator jest używany w logach inspekcji, Conditional Access i Identity Protection, co zapewnia spójne podejście do bezpieczeństwa.

Zalecenie: Wymuszaj MFA lub logowanie bezhasłowe, stosuj Conditional Access dla ryzykownych logowań, używaj PIM do czasowego nadawania ról administracyjnych, szybko usuwaj nieużywane konta i monitoruj logi logowania w poszukiwaniu anomalii.

W skrócie zapamiętaj:

• Użytkownik reprezentuje osobę w systemie (np. Teams, Outlook, Azure).
• Uwierzytelnianie przez UPN + hasło/biometria/klucz.
• Może być gościem w innych tenantach.
• Zalecenie: MFA, hasła bezpieczne lub bezhasłowe, monitorowanie logowań i ryzyk.

W Microsoft Entra ID group to pojedynczy obiekt reprezentujący wiele tożsamości, umożliwiający nadanie uprawnień raz i automatyczne przekazanie ich wszystkim członkom. Występują dwa główne typy grup:

• Security group – służy wyłącznie do kontroli dostępu i jest rozpoznawana przez mechanizmy Azure role‑based access control (RBAC), udziały plików, aplikacje biznesowe i inne systemy korzystające z tokenów bezpieczeństwa katalogu.
• Microsoft 365 group – oprócz kontroli dostępu oferuje narzędzia współpracy: wspólną skrzynkę pocztową, kalendarz, tablicę Planner, OneDrive oraz witrynę zespołu SharePoint. Ta sama lista członków zarządza więc zarówno dostępem, jak i narzędziami pracy zespołowej.

Członkostwo w grupach w Entra ID również występuje w dwóch wariantach:

• Assigned – członkowie są dodawani lub usuwani ręcznie.
• Dynamic – członkowie są przypisywani automatycznie na podstawie reguł bazujących na atrybutach; katalog dodaje lub usuwa użytkowników, gdy ich atrybuty spełniają lub przestają spełniać określone warunki.

Zalecenie: Traktuj grupy jako narzędzie egzekwowania zasady najmniejszych uprawnień (least privilege). Nadawaj dostęp grupom zamiast pojedynczym użytkownikom, utrzymuj małe i odpowiednio chronione grupy o wysokim wpływie (MFA, Privileged Identity Management), regularnie przeglądaj członkostwo oraz tam, gdzie to możliwe, stosuj reguły dynamiczne, aby dostęp był powiązany z rolą użytkownika, a nie pozostawał po zmianie stanowiska.

W skrócie zapamiętaj:

• Grupuj użytkowników w celu przydzielania ról.
• Grupy: statyczne (ręcznie) lub dynamiczne (na podstawie reguł).
• Zalecenie: używaj grup do kontroli dostępu, szczególnie dynamicznych, regularnie przeglądaj członkostwa.

W Microsoft Entra ID service principal to tożsamość w formie aplikacji, nadawana kodowi lub procesom automatyzacji, a nie ludziom. Tworzona jest automatycznie podczas rejestracji aplikacji lub wyrażenia zgody na aplikację w ramach organizacji (enterprise consent). Istnieje jako osobny obiekt w jednym tenancie, z niezmiennym Object ID, na który mogą wskazywać reguły autoryzacji. Ponieważ service principal można przypisać do ról Azure, ról Azure AD lub niestandardowych ról aplikacji, pełni on funkcję „bramy”, przez którą aplikacja wykonuje operacje, takie jak wdrażanie zasobów, odpytywanie danych czy wysyłanie wiadomości e‑mail.

Service principal obsługuje trzy bezpośrednie metody logowania:

• Client secret – najprostsza, czyli długie hasło zapisane w katalogu i przekazywane przez aplikację w momencie żądania tokena.
• Para kluczy asymetrycznych – prywatny klucz w certyfikacie potwierdza tożsamość aplikacji, a klucz publiczny jest przechowywany w katalogu.
• Federated credential – nowoczesne, pozbawione sekretów podejście, w którym Entra ID ufa zewnętrznemu dostawcy tokenów (np. GitHub Actions, Kubernetes lub innej platformie zgodnej z OpenID Connect), dzięki czemu uruchamiane zadanie nigdy nie przechowuje poświadczeń.

Żadna z tych metod logowania nie może wymusić uwierzytelniania wieloskładnikowego (MFA), dlatego kluczowe jest zabezpieczenie samych poświadczeń i ograniczenie uprawnień service principal do absolutnego minimum. Każdy użytkownik mający rolę owner na obiekcie aplikacji może tworzyć lub odnawiać sekrety i certyfikaty, czyli de facto zmieniać hasło aplikacji w dowolnym momencie.

Zalecenie: Preferuj certyfikaty lub federated credentials zamiast zwykłych sekretów, rotuj je zgodnie z ustalonym harmonogramem, przypisuj service principal tylko minimalne wymagane role i w miarę możliwości przechodź na managed identities, aby platforma zarządzała tokenami automatycznie. Monitoruj logi logowania pod kątem nietypowych lokalizacji lub nagłych wzrostów użycia, a przypisania ról kontroluj tak samo rygorystycznie jak w przypadku administratorów‑użytkowników — ponieważ po przejęciu service principal może on działać z prędkością maszyny, bez ograniczeń MFA.

W skrócie zapamiętaj:

• Obiekt reprezentujący aplikację lub automatyzację.
• Uwierzytelnianie: sekret, certyfikat lub federacja (np. GitHub).
• Zalecenie: preferuj certyfikaty/federację, ogranicz role, rotuj dane uwierzytelniające, monitoruj użycie.

Managed identity to wbudowany mechanizm Azure, który pozwala kodowi logować się jako service principal bez konieczności zarządzania hasłami czy certyfikatami. W momencie włączenia tej funkcji Entra ID automatycznie tworzy lub przypisuje service principal w Twoim tenancie i rejestruje go w sekcji Enterprise Applications, nie ujawniając żadnych materiałów uwierzytelniających. Aplikacja lub usługa pobiera token bezpośrednio z lokalnego metadata endpoint, a Entra ID ufa temu żądaniu, ponieważ jest ono wykonywane przez samą platformę.
Występują dwa rodzaje managed identity:

• System-assigned identity – powiązana z pojedynczym zasobem; znika wraz z jego usunięciem.
• User-assigned identity – tworzona niezależnie, może być przypisana do wielu zasobów, co pozwala na spójne przypisania RBAC.

W obu przypadkach tożsamość nie posiada długoterminowych poświadczeń do wycieku lub rotacji; tokeny są wydawane na żądanie, dzięki czemu znika typowe obciążenie związane z przechowywaniem, wygasaniem i odnawianiem sekretów. Nadając managed identity wyłącznie role Azure niezbędne do działania aplikacji, zapewniasz jej minimalny wymagany poziom uprawnień, bez zapisywania poświadczeń w kodzie lub konfiguracji.

Zalecenie: Korzystaj z managed identity zawsze, gdy to możliwe. Przydzielaj tylko niezbędne role i regularnie audytuj zarówno listę ról, jak i logi logowania pod kątem nietypowych zdarzeń.

W skrócie zapamiętaj:

• Wbudowana forma Service Principal dla zasobów Azure.
• Automatycznie zarządzana – brak sekretów.
• Zalecenie: używaj zawsze, gdy możliwe, z ograniczonymi rolami i audytem.

W Microsoft Entra ID role to wbudowane zestawy uprawnień katalogowych, które można przypisać użytkownikowi, grupie lub service principal, aby umożliwić im zarządzanie określonymi funkcjami bez nadawania pełnej kontroli nad całym tenantem. Zakres i możliwości każdej roli są z góry zdefiniowane i udokumentowane, dzięki czemu można łatwo sprawdzić, czy rola pozwala np. resetować hasła, edytować zasady Conditional Access czy przypisywać licencje.

Na samym szczycie znajduje się rola Global Administrator — posiadająca pełną kontrolę, umożliwiająca zmianę dowolnych ustawień, nadawanie wyższych uprawnień innym kontom, a nawet zablokowanie całego katalogu. Wszystkie pozostałe role, od User Administrator po Conditional Access Administrator, zapewniają węższy zakres uprawnień, co pozwala ograniczać wpływ codziennych działań administracyjnych.

Zalecenie: Utrzymuj liczbę kont z rolą Global Administrator na absolutnym minimum, stosuj Privileged Identity Management (PIM), aby wszystkie role administracyjne były nadawane tymczasowo i wymagały zatwierdzenia, oraz regularnie przeglądaj przypisania ról, aby tylko właściwe osoby — i żadni pozostawieni bez nadzoru service principal — posiadały dostęp, którego naprawdę potrzebują.

W skrócie zapamiętaj:

• Rola przypisywana użytkownikowi, grupie lub aplikacji.
• Global Administrator ma pełne uprawnienia.
• Zalecenie: minimalizuj ilość administratorów, używaj PIM i ról tymczasowych.

App registration to nadrzędny rekord aplikacji w Microsoft Entra ID. Utworzenie go powoduje przypisanie unikalnego Application ID (client ID), zapisanie redirect URI, na które Entra ID będzie wysyłać tokeny po uwierzytelnieniu, oraz określenie, które przepływy OAuth 2.0 lub OpenID Connect aplikacja akceptuje. W tym samym rekordzie definiuje się sposób potwierdzania tożsamości aplikacji: można wygenerować client secret, przesłać certyfikat lub skonfigurować federated credential, aby zaufany dostawca — np. GitHub Actions — mógł uzyskiwać tokeny w imieniu aplikacji bez przechowywania sekretów. Rejestracja zawiera również listę wszystkich interfejsów API i zakresów uprawnień (permission scopes), z których aplikacja może korzystać, tworząc tzw. consent surface, widoczny dla administratorów.

Za każdym razem, gdy tworzona jest rejestracja lub nadawana zgoda w skali całego tenanta (tenant-wide consent), Entra ID automatycznie tworzy service principal w tym tenancie. Ta tożsamość uruchomieniowa może być przypisana do ról Azure RBAC lub ról katalogowych, pojawia się w logach logowania i to ona faktycznie jest używana przez kod w momencie żądania tokenów.

Zalecenie: Chroń poświadczenia tak, jak chroni się uprzywilejowane sekrety, rotuj je zgodnie z przewidywalnym harmonogramem, preferuj federated credentials, aby wyeliminować przechowywane sekrety, ograniczaj uprawnienia API do absolutnego minimum oraz regularnie przeglądaj zarówno uprawnienia, jak i przypisania ról.

W skrócie zapamiętaj:

• Definiuje sposób logowania i uprawnienia aplikacji.
• Tworzy Service Principal.
• Zalecenie: ogranicz dostęp API, używaj federacji, rotuj dane logowania, regularnie przeglądaj role.