Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule opisano niektóre najlepsze rozwiązania dotyczące używania kontroli dostępu opartej na rolach (RBAC) platformy Azure. Te najlepsze praktyki są oparte na naszym doświadczeniu z kontrolą dostępu opartą na rolach (RBAC) platformy Azure oraz doświadczeniach klientów, takich jak Państwo.
Przyznawaj użytkownikom tylko niezbędny dostęp
Przy użyciu kontroli RBAC na platformie Azure można przeprowadzać segregowanie zadań w ramach zespołu i nadawać użytkownikom tylko takie uprawnienia dostępu, które są im niezbędne do wykonywania zadań. Zamiast udzielać wszystkim nieograniczonym uprawnień w ramach subskrypcji lub zasobów platformy Azure, możesz zezwolić tylko na określone akcje w określonym zakresie.
Podczas planowania strategii kontroli dostępu najlepszym rozwiązaniem jest przyznanie użytkownikom najniższych uprawnień w celu wykonania pracy. Unikaj przypisywania szerszych ról w szerszych zakresach, nawet jeśli początkowo wydaje się to bardziej wygodne. Podczas tworzenia ról niestandardowych uwzględnij tylko wymagane uprawnienia użytkowników. Ograniczając role i zakresy, ograniczasz, jakie zasoby są zagrożone, jeśli podmiot zabezpieczeń kiedykolwiek zostanie naruszony.
Na poniższym diagramie przedstawiono sugerowany schemat korzystania z kontroli dostępu opartej na rolach w Azure.
Aby uzyskać informacje na temat przypisywania ról, zobacz Przypisywanie ról platformy Azure przy użyciu witryny Azure Portal.
Ograniczanie liczby właścicieli subskrypcji
Musisz mieć maksymalnie 3 właścicieli subskrypcji, aby zmniejszyć ryzyko naruszenia zabezpieczeń przez właściciela, którego dane wyciekły. To zalecenie można monitorować w usłudze Microsoft Defender for Cloud. Aby uzyskać inne zalecenia dotyczące tożsamości i dostępu w usłudze Defender for Cloud, zobacz Zalecenia dotyczące zabezpieczeń — przewodnik referencyjny.
Ograniczanie przypisań ról administratora uprzywilejowanego
Niektóre role są identyfikowane jako role uprzywilejowanego administratora. Rozważ podjęcie następujących akcji w celu poprawy stanu zabezpieczeń:
- Usuń niepotrzebne przypisania ról uprzywilejowanych.
- Unikaj przypisywania roli uprzywilejowanego administratora, gdy zamiast tego można użyć roli funkcji pracy.
- Jeśli musisz przypisać rolę administratora uprzywilejowanego, użyj wąskiego zakresu, takiego jak grupa zasobów lub zasób, zamiast szerszego zakresu, takiego jak grupa zarządzania lub subskrypcja.
- Jeśli przypisujesz rolę z uprawnieniami do tworzenia przypisań ról, rozważ dodanie warunku w celu ograniczenia przypisania roli. Aby uzyskać więcej informacji, zobacz Delegowanie zarządzania przypisywaniem ról platformy Azure innym osobom z określonymi warunkami.
Aby uzyskać więcej informacji, zobacz Wyświetlaj lub zarządzaj przypisaniami ról administratora uprzywilejowanego.
Korzystanie z usługi Microsoft Entra Privileged Identity Management
Aby chronić uprzywilejowane konta przed złośliwymi atakami cybernetycznymi, możesz użyć usługi Microsoft Entra Privileged Identity Management (PIM), aby zmniejszyć czas ujawnienia uprawnień i zwiększyć wgląd w ich użycie za pośrednictwem raportów i alertów. Usługa PIM pomaga chronić uprzywilejowane konta, zapewniając uprzywilejowany dostęp just in time do identyfikatora Entra firmy Microsoft i zasobów platformy Azure. Dostęp może być ograniczony czasowo, po którym uprawnienia są automatycznie cofane.
Aby uzyskać więcej informacji, zobacz Co to jest microsoft Entra Privileged Identity Management?.
Przypisywanie ról do grup, a nie użytkowników
Aby ułatwić zarządzanie przypisaniami ról, unikaj przypisywania ról bezpośrednio do użytkowników. Zamiast tego przypisz role do grup. Przypisywanie ról do grup zamiast użytkowników pomaga również zminimalizować liczbę przypisań ról, co ma limit przypisań ról na subskrypcję.
Przypisywanie ról przy użyciu unikatowego identyfikatora roli zamiast nazwy roli
Istnieje kilka razy, gdy nazwa roli może ulec zmianie, na przykład:
- Używasz własnej roli niestandardowej i decydujesz się zmienić nazwę.
- Używasz roli podglądu, która ma (Preview) w nazwie. Gdy rola zostanie udostępniona, nazwa roli zostanie zmieniona.
Nawet jeśli nazwa roli zostanie zmieniona, identyfikator roli nie ulegnie zmianie. Jeśli używasz skryptów lub automatyzacji do tworzenia przypisań ról, najlepszym rozwiązaniem jest użycie unikatowego identyfikatora roli zamiast nazwy roli. W związku z tym, jeśli nazwa roli zostanie zmieniona, skrypty mają większe szanse na działanie.
Aby uzyskać więcej informacji, zobacz Przypisywanie roli przy użyciu unikatowego identyfikatora roli i programu Azure PowerShell oraz Przypisywanie roli przy użyciu unikatowego identyfikatora roli i interfejsu wiersza polecenia platformy Azure.
Unikaj korzystania z symbolu wieloznacznego podczas tworzenia ról niestandardowych
Podczas tworzenia ról niestandardowych można użyć symbolu wieloznakowego (*
) do zdefiniowania uprawnień. Zaleca się określenie Actions
i DataActions
jawnie zamiast używania symbolu wieloznakowego (*
). Dodatkowy dostęp i uprawnienia przyznane w przyszłości Actions
lub DataActions
mogą być niepożądanym zachowaniem przy użyciu symbolu wieloznacznego. Aby uzyskać więcej informacji, zobacz Niestandardowe role platformy Azure.