0Pricing
Azure Fundamentals · Lekcja

Projektowanie tożsamości i dostępu w przedsiębiorstwie

Proszę zaprojektować wielkoskalowy model RBAC z użyciem grup zarządzania, ról niestandardowych i usługi Privileged Identity Management, aby wymuszać dostęp just-in-time do operacji wrażliwych.

Projektowanie tożsamości i dostępu w przedsiębiorstwie to bezpłatna lekcja Azure Fundamentals na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Azure Fundamentals, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Tożsamość w skali przedsiębiorstwa

W środowiskach Azure dla przedsiębiorstw zarządzanie tożsamością i dostępem musi skalować się do setek subskrypcji, tysięcy użytkowników i dziesiątek zespołów — z których każdy ma inne potrzeby w zakresie dostępu do zasobów. Dobrze zaprojektowany model tożsamości zapobiega zarówno nadawaniu zbyt szerokich uprawnień, jak i nadawaniu uprawnień niewystarczających do wykonywania obowiązków. Jego podstawę stanowi Microsoft Entra ID w połączeniu z Azure RBAC oraz narzędziami do zarządzania, takimi jak Privileged Identity Management (PIM).

Podstawy RBAC — powtórzenie

Kontrola dostępu oparta na rolach Azure (RBAC) przyznaje dostęp za pomocą trzech składników:

  • Podmiot zabezpieczeń — kto (użytkownik, grupa, jednostka usługi lub tożsamość zarządzana)
  • Definicja roli — co (zestaw dozwolonych działań, np. „Contributor”)
  • Zakres — gdzie (grupa zarządzania, subskrypcja, grupa zasobów lub pojedynczy zasób)

Połączenie tych trzech elementów tworzy przypisanie roli. Role są dziedziczone w dół hierarchii — rola przypisana na poziomie grupy zarządzania obowiązuje we wszystkich znajdujących się poniżej subskrypcjach.

# Assign the Reader role at a management group level:
az role assignment create \
  --assignee 'user@company.com' \
  --role 'Reader' \
  --scope '/providers/Microsoft.Management/managementGroups/LandingZones'

Role wbudowane a niestandardowe

Azure udostępnia ponad 100 ról wbudowanych obejmujących typowe scenariusze (Owner, Contributor, Reader oraz role związane z konkretnymi usługami). W większości zastosowań korporacyjnych role wbudowane są wystarczające. Jeśli jednak potrzebują Państwo uprawnień, które nie odpowiadają żadnej roli wbudowanej — na przykład roli umożliwiającej odczytywanie maszyn wirtualnych, ale nie ich usuwanie — można utworzyć rolę niestandardową z dokładnie określonymi uprawnieniami, zgodnie z zasadą najmniejszych uprawnień.

# Create a custom role:
az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can start and stop VMs but cannot create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}'

Przypisywanie dostępu na podstawie grup

W miarę możliwości należy przypisywać role do grup Entra ID, a nie do poszczególnych użytkowników. Po przypisaniu roli do grupy wszyscy jej członkowie dziedziczą tę rolę. Dodawanie lub odbieranie dostępu sprowadza się wtedy do dodania użytkownika do grupy lub usunięcia go z grupy, bez modyfikowania przypisań ról w wielu zakresach. Znacznie ogranicza to nakład pracy administracyjnej i zapewnia spójny dostęp członkom zespołu wykonującym tę samą funkcję.

# Create a group and assign a role to the group:
az ad group create \
  --display-name 'ProductionContributors' \
  --mail-nickname 'prod-contributors'

az role assignment create \
  --assignee '<group-object-id>' \
  --role 'Contributor' \
  --scope '/subscriptions/prod-subscription-id'

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) to usługa Entra ID zapewniająca uprzywilejowany dostęp just-in-time (JIT) do zasobów Azure i ról Entra ID. Zamiast stałego dostępu Owner lub Global Administrator użytkownicy mają status eligible dla uprzywilejowanych ról i muszą poprosić o ich aktywację, gdy potrzebują podwyższonych uprawnień. Aktywacja może wymagać uwierzytelniania wieloskładnikowego, uzasadnienia oraz zatwierdzenia przez wyznaczoną osobę zatwierdzającą.

# Workflow with PIM:
# 1. Security team makes 'alice@company.com' eligible for 'Owner' on prod subscription
# 2. Alice requests activation via PIM portal or myaccess.microsoft.com
# 3. Alice provides justification: 'Emergency patching for CVE-2026-1234'
# 4. Manager approves the request (optional step)
# 5. Alice receives Owner access for 4 hours, then access expires automatically
# 6. All activation events are logged in Entra ID audit logs

Korzyści z PIM w przedsiębiorstwie

PIM zapewnia szereg korzyści w zakresie bezpieczeństwa w środowiskach korporacyjnych:

  • Zmniejszona powierzchnia ataku — brak stałych kont administratorów, które mogłyby zostać przejęte
  • Ścieżka audytu — każda aktywacja jest rejestrowana wraz ze znacznikiem czasu, uzasadnieniem i osobą zatwierdzającą
  • Przeglądy dostępu — PIM obsługuje okresowe przeglądy, podczas których menedżerowie potwierdzają, którzy użytkownicy powinni zachować status eligible
  • Ograniczenie czasowe dostępu — nawet zatwierdzony dostęp wygasa automatycznie, co zapobiega pozostawaniu zapomnianych podwyższonych uprawnień

Projektowanie modelu RBAC

Dobrze zaprojektowany model RBAC dla przedsiębiorstwa zwykle obejmuje następujące warstwy:

  • Poziom grupy zarządzania — szeroki dostęp w trybie tylko do odczytu dla zespołów ds. zarządzania; przypisania zasad
  • Poziom subskrypcji — dostęp Contributor na poziomie zespołu dla zespołów aplikacyjnych zarządzających jedną subskrypcją
  • Poziom grupy zasobów — role związane z konkretnymi usługami (np. Storage Blob Contributor dla aplikacji, która potrzebuje dostępu tylko do obiektów blob)
  • Poziom zasobu — wyłącznie w wyjątkowych przypadkach, gdy potrzebna jest szczegółowa kontrola

Jednostki usługi i tożsamości zarządzane

Aplikacje i zautomatyzowane procesy nie powinny używać kont użytkowników do uwierzytelniania w Azure. Zamiast tego używaj:

  • jednostek usługi — rejestracji aplikacji w Entra ID z identyfikatorem klienta oraz wpisem tajnym lub certyfikatem; używanych przez potoki CI/CD i automatyzację lokalną
  • tożsamości zarządzanych — poświadczeń zarządzanych automatycznie dla zasobów hostowanych w Azure (VM, App Service, AKS); bez wpisów tajnych do zarządzania ani rotowania

Przypisuj minimalne wymagane role RBAC jednostkom usługi i tożsamościom zarządzanym.

# Assign a role to a managed identity:
az role assignment create \
  --assignee-object-id '<managed-identity-object-id>' \
  --assignee-principal-type ServicePrincipal \
  --role 'Storage Blob Data Contributor' \
  --scope '/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>'

Dostęp warunkowy do zasobów

Zasady dostępu warunkowego w Entra ID zwiększają inteligencję decyzji dotyczących uwierzytelniania. W przypadku zarządzania zasobami Azure możesz wymagać, aby dostęp administracyjny (portal Azure, CLI) był dozwolony wyłącznie z:

  • zgodnych urządzeń (zarządzanych przez Intune)
  • nazwanych lokalizacji (sieć firmowa lub VPN)
  • po uwierzytelnieniu MFA (zawsze wymuszanym dla działań uprzywilejowanych)

Połączenie dostępu warunkowego z PIM zapewnia bardzo wysoki poziom bezpieczeństwa dostępu administracyjnego do Azure.

Przeglądy dostępu

Przeglądy dostępu Entra ID umożliwiają administratorom okresowe sprawdzanie, czy użytkownicy nadal potrzebują przyznanego im dostępu. Przeglądy można delegować właścicielom zasobów lub menedżerom, którzy dla każdego użytkownika odpowiadają „Tak, ta osoba nadal potrzebuje dostępu” albo „Nie, usuń ten dostęp”. Przeglądy dostępu można planować co kwartał i automatycznie usuwać dostęp, który nie jest już zatwierdzony, co zapobiega stopniowemu nadawaniu nadmiernych uprawnień.

Konta dostępu awaryjnego

Każde przedsiębiorstwo powinno utrzymywać co najmniej dwa konta dostępu awaryjnego (break-glass) — konta administratora globalnego, które nie są chronione wymaganiami dostępu warunkowego ani MFA (zamiast tego używają sprzętowych kluczy FIDO2). Konta te są używane wyłącznie wtedy, gdy systemy Entra ID lub MFA są niedostępne i nie można uzyskać dostępu do zwykłych kont administratorów. Użycie konta dostępu awaryjnego powinno natychmiast wywoływać alerty bezpieczeństwa i podlegać rygorystycznemu audytowi.

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) z tej lekcji.

Podsumowanie lekcji

W tej lekcji nauczono się, że: firmowy model RBAC używa przypisań opartych na grupach w zakresie grupy zarządzania, subskrypcji i grupy zasobów; Privileged Identity Management zapewnia dostęp just-in-time, aby wyeliminować stałe role administratora; a do uwierzytelniania aplikacji zamiast kont użytkowników należy używać tożsamości zarządzanych i jednostek usługi. Gratulacje — ukończono sekcję architektury przedsiębiorstwa i ładu w ścieżce AZ-900!

Często zadawane pytania

Czy lekcja „Projektowanie tożsamości i dostępu w przedsiębiorstwie” jest bezpłatna?

Tak — pełny tekst „Projektowanie tożsamości i dostępu w przedsiębiorstwie” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Azure Fundamentals, przejdź na CoddyKit PRO. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Co nauczysz się w „Projektowanie tożsamości i dostępu w przedsiębiorstwie”?

Proszę zaprojektować wielkoskalowy model RBAC z użyciem grup zarządzania, ról niestandardowych i usługi Privileged Identity Management, aby wymuszać dostęp just-in-time do operacji wrażliwych. Ćwiczysz Azure Fundamentals z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Azure Fundamentals?

Nie wymagamy żadnego doświadczenia. Azure Fundamentals w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Projektowanie tożsamości i dostępu w przedsiębiorstwie”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Azure Fundamentals?

Tak. Każda lekcja Azure Fundamentals zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Przegląd Cloud Adoption Framework
  2. Strefy docelowe Azure
  3. Topologia sieci hub-and-spoke
  4. Projektowanie tożsamości i dostępu w przedsiębiorstwie
← Powrót do Azure Fundamentals