Empfehlungen für das Identity & Access Management

Gilt für diese Empfehlung für die Sicherheit von Azure Well-Architected Framework:

SE:05

Implementieren Sie strenge, bedingte und auditierbare Identitäts- und Zugriffsverwaltung (IAM) für alle Arbeitsauslastungsbenutzer, Teammitglieder und Systemkomponenten. Beschränken Sie den Zugriff ausschließlich auf die erforderlichen Daten. Verwenden Sie moderne Branchenstandards für alle Authentifizierungs- und Autorisierungsimplementierungen. Einschränken und strenges Überwachen des Zugriffs, der nicht auf Identität basiert.

In diesem Leitfaden werden die Empfehlungen für die Authentifizierung und Autorisierung von Identitäten beschrieben, die versuchen, auf Ihre Workloadressourcen zuzugreifen.

Aus technischer Sicht ist Identität immer der primäre Umkreis. Dieser Bereich enthält nicht nur die Ränder Ihrer Workload. Sie umfasst auch einzelne Komponenten, die sich innerhalb Ihrer Workload befinden. Typische Identitäten sind:

• Menschen. Anwendungsbenutzer, Administratoren, Operatoren, Auditoren und schlechte Akteure.

• Systeme. Workloadidentitäten, verwaltete Identitäten, API-Schlüssel, Dienstprinzipale und Azure-Ressourcen.

• Anonym. Entitäten, die keine Beweise dafür bereitgestellt haben, wer sie sind.

Definitionen 

Bedingungen	Definition
Authentifizierung (AuthN)	Ein Prozess, der überprüft, ob eine Identität der Person ist oder was sie sagt.
Autorisierung (AuthZ)	Ein Prozess, der überprüft, ob eine Identität über die Berechtigung zum Ausführen einer angeforderten Aktion verfügt.
Bedingter Zugriff	Eine Reihe von Regeln, die Aktionen basierend auf angegebenen Kriterien zulässt.
IdP	Ein Identitätsanbieter, z. B. Microsoft Entra-ID.
Persona	Eine Stellenfunktion oder ein Titel, der über eine Reihe von Zuständigkeiten und Aktionen verfügt.
Vorabfreigabeschlüssel	Eine Art geheimer Schlüssel, der zwischen einem Anbieter und Verbraucher geteilt wird und über einen sicheren und vereinbarten Mechanismus verwendet wird.
Ressourcenidentität	Eine Identität, die für Cloudressourcen definiert ist, die von der Plattform verwaltet werden.
Role	Eine Gruppe von Berechtigungen, die definieren, was ein Benutzer oder eine Gruppe tun kann.
`Scope`	Unterschiedliche Ebenen der Organisationshierarchie, in denen eine Rolle ausgeführt werden darf. Außerdem eine Gruppe von Features in einem System.
Sicherheitsprinzipal	Eine Identität, die Berechtigungen bereitstellt. Dabei kann es sich um einen Benutzer, eine Gruppe oder einen Dienstprinzipal handeln. Alle Gruppenmitglieder erhalten dieselbe Zugriffsebene.
Benutzeridentität	Eine Identität für eine Person, z. B. ein Mitarbeiter oder ein externer Benutzer.
Workloadidentität	Eine Systemidentität für eine Anwendung, einen Dienst, ein Skript, einen Container oder eine andere Komponente einer Workload, die verwendet wird, um sich bei anderen Diensten und Ressourcen zu authentifizieren.

Hinweis

Eine Identität kann mit anderen, ähnlichen Identitäten unter einem übergeordneten Element gruppiert werden, das als Sicherheitsprinzipal bezeichnet wird. Eine Sicherheitsgruppe ist ein Beispiel für einen Sicherheitsprinzipal. Diese hierarchische Beziehung vereinfacht die Wartung und verbessert die Konsistenz. Da Identitätsattribute nicht auf der individuellen Ebene behandelt werden, werden die Fehlerchancen ebenfalls reduziert. In diesem Artikel ist der Begriff "Identität " von Sicherheitsprinzipalen enthalten.

Die Rolle eines Identitätsanbieters

Ein Identitätsanbieter (IdP) ist ein in der Cloud gehosteter Dienst, der Benutzer als digitale Identitäten speichert und verwaltet.

Nutzen Sie die Von einem vertrauenswürdigen IdP für Ihre Identitäts- und Zugriffsverwaltung bereitgestellten Funktionen. Implementieren Sie keine benutzerdefinierten Systeme, um einen IdP zu ersetzen. IdP-Systeme werden häufig basierend auf den neuesten Angriffsvektoren verbessert, indem sie jeden Tag Milliarden von Signalen über mehrere Mandanten hinweg erfassen. Microsoft Entra ID ist der IdP für Azure-Cloudplattform.

Authentifizierung

Die Authentifizierung ist ein Prozess, der Identitäten überprüft. Die anfordernde Identität ist erforderlich, um eine Form der nachweisbaren Identifizierung bereitzustellen. Zum Beispiel:

• Ein Benutzername und ein Kennwort.

• Ein geheimer Schlüssel vor der Freigabe, z. B. ein API-Schlüssel, der Zugriff gewährt.

• Ein SAS-Token (Shared Access Signature).

• Ein Zertifikat, das in der gegenseitigen TLS-Authentifizierung verwendet wird.

So weit wie möglich sollte der Überprüfungsprozess von Ihrem IdP verarbeitet werden.

Autorisierung

Die Autorisierung ist ein Prozess, der Aktionen zulässt oder verweigert, die von der überprüften Identität angefordert werden. Die Aktion kann sich auf den Betrieb oder die Ressourcenverwaltung beziehen.

Die Autorisierung erfordert, dass Sie den Identitäten Berechtigungen zuweisen, die Sie mithilfe der von Ihrem IdP bereitgestellten Funktionen ausführen müssen.

Wichtige Entwurfsstrategien

Um einen ganzheitlichen Überblick über die Identitätsanforderungen für eine Workload zu erhalten, müssen Sie die Flüsse, Workloadressourcen und Personas katalogisieren und die Aktionen, die die Objekte und Personas ausführen. Ihre Strategie muss alle Anwendungsfälle abdecken, die die Flüsse behandeln , die die Workload oder ihre Komponenten (außerhalb des Zugriffs) erreichen, und Flüsse, die von der Workload zu anderen Quellen (inside-out-Zugriff) reichen.

Jeder Anwendungsfall wird wahrscheinlich über einen eigenen Satz von Steuerelementen verfügen, die Sie mit einer Annahmeverletzungs-Denkweise entwerfen müssen. Identifizieren Sie basierend auf den Identitätsanforderungen des Anwendungsfalls oder der Personas die bedingten Auswahlmöglichkeiten. Vermeiden Sie die Verwendung einer Lösung für alle Anwendungsfälle. Umgekehrt sollten die Steuerelemente nicht so präzise sein, dass sie unnötigen Verwaltungsaufwand verursachen.

Sie müssen den Identitätszugriffspfad protokollieren. Auf diese Weise können Sie die Steuerelemente überprüfen, und Sie können die Protokolle für Complianceüberwachungen verwenden.

Ermitteln aller Identitäten für die Authentifizierung

• Zugriff von außen: Ihr Identitätsentwurf muss alle Benutzer authentifizieren, die für verschiedene Zwecke auf die Workload zugreifen. Beispielsweise ein Endbenutzer, der auf die Anwendung zugreift, indem APIs aufgerufen werden.

  Auf granularer Ebene benötigen Komponenten der Workload möglicherweise auch Zugriff von außen. Beispielsweise ein Operator, der Zugriff über das Portal benötigt, oder Zugriff auf die Berechnung zum Ausführen von Befehlen.

  Beide sind Beispiele für Benutzeridentitäten , die unterschiedliche Personas aufweisen.

• Zugriff von innen: Ihre Anwendung muss auf andere Ressourcen zugreifen. Beispielsweise lesen oder schreiben sie in die Datenplattform, abrufen geheime Schlüssel aus dem geheimen Speicher und Protokollieren von Telemetrie an Überwachungsdienste. Es kann sogar erforderlich sein, auf Dienste von Drittanbietern zuzugreifen. Für diesen Zugriff ist eine Workloadidentität erforderlich, die es der Anwendung ermöglicht, sich bei den anderen Ressourcen zu authentifizieren.

  Das Konzept gilt auf Komponentenebene. Im folgenden Beispiel benötigt der Container möglicherweise Zugriff auf Bereitstellungspipelines, um seine Konfiguration abzurufen. Für diese Zugriffsanforderungen ist eine Ressourcenidentität erforderlich.

Alle diese Identitäten sollten von Ihrem IdP authentifiziert werden.

Hier ist ein Beispiel dafür, wie Identität in einer Architektur implementiert werden kann:

Bestimmen von Aktionen für die Autorisierung

Als Nächstes müssen Sie wissen, was jede authentifizierte Identität zu tun versucht, damit diese Aktionen autorisiert werden können. Die Aktionen können durch den Typ des Zugriffs geteilt werden, den sie benötigen:

• Datenebenenzugriff. Aktionen, die in der Datenebene ausgeführt werden, führen zu einer Datenübertragung innerhalb oder außerhalb des Zugriffs. Beispielsweise eine Anwendung, die Daten aus einer Datenbank liest und Daten in eine Datenbank schreibt, geheime Schlüssel abruft oder Protokolle in eine Überwachungssenke schreibt. Berechnen Sie auf Komponentenebene, dass Bilder aus einer Registrierung abgerufen oder übertragen werden, werden als Datenebenenvorgänge betrachtet.

• Steuern des Flugzeugzugriffs. Aktionen, die in der Steuerungsebene ausgeführt werden, bewirken, dass eine Azure-Ressource erstellt, geändert oder gelöscht wird. Beispielsweise änderungen an Ressourceneigenschaften.

Anwendungen zielen in der Regel auf Datenebenen ab, während Vorgänge häufig sowohl auf Kontroll- als auch auf Datenebenen zugreifen. Um Autorisierungsanforderungen zu identifizieren, notieren Sie sich die operativen Aktionen, die für die Ressource ausgeführt werden können. Informationen zu den zulässigen Aktionen für jede Ressource finden Sie unter Azure-Ressourcenanbietervorgänge.

Bereitstellen einer rollenbasierten Autorisierung

Basierend auf der Verantwortung jeder Identität autorisieren Sie Aktionen, die zulässig sein sollten. Eine Identität darf nicht mehr tun, als sie tun muss. Bevor Sie Autorisierungsregeln festlegen, müssen Sie ein klares Verständnis darüber haben, wer oder was Anforderungen stellt, was diese Rolle tun darf und in welchem Umfang dies möglich ist. Diese Faktoren führen zu Auswahlmöglichkeiten, die Identität, Rolle und Bereich kombinieren.

Betrachten Sie eine Workloadidentität als Beispiel. Die Anwendung muss über Datenebenenzugriff auf die Datenbank verfügen, sodass Lese- und Schreibaktionen für die Datenressource zulässig sein müssen. Benötigt die Anwendung jedoch den Zugriff auf den Flugzeugzugriff auf den geheimen Speicher? Wenn die Workloadidentität von einem schlechten Akteur beeinträchtigt wird, was wäre die Auswirkung auf das System in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit?

Rollenzuweisung

Eine Rolle ist eine Gruppe von Berechtigungen , die einer Identität zugewiesen sind. Weisen Sie Rollen zu, mit denen die Identität nur die Aufgabe abschließen kann und nicht mehr. Wenn die Berechtigungen des Benutzers auf ihre Auftragsanforderungen beschränkt sind, ist es einfacher, verdächtiges oder nicht autorisiertes Verhalten im System zu erkennen.

Stellen Sie Fragen wie diese:

• Ist schreibgeschützter Zugriff ausreichend?
• Benötigt die Identität Berechtigungen zum Löschen von Ressourcen?

Das Einschränken des Zugriffs, den Benutzer, Anwendungen oder Dienste auf Azure-Ressourcen haben, reduziert die potenzielle Angriffsfläche. Wenn Sie nur die Mindestberechtigungen erteilen, die zum Ausführen bestimmter Aufgaben erforderlich sind, wird das Risiko eines erfolgreichen Angriffs oder eines nicht autorisierten Zugriffs erheblich reduziert. Sicherheitsteams benötigen beispielsweise nur schreibgeschützten Zugriff auf Sicherheitsattribute für alle technischen Umgebungen. Diese Stufe reicht aus, um Risikofaktoren zu bewerten, potenzielle Risikominderungen zu identifizieren und die Risiken zu melden.

Es gibt Szenarien, in denen Benutzer aufgrund der Organisationsstruktur und der Teamorganisation mehr Zugriff benötigen. Möglicherweise gibt es eine Überlappung zwischen verschiedenen Rollen, oder einzelne Benutzer führen mehrere Standardrollen aus. Verwenden Sie in diesem Fall mehrere Rollenzuweisungen, die auf der Geschäftsfunktion basieren, anstatt eine benutzerdefinierte Rolle für jeden dieser Benutzer zu erstellen. Dies erleichtert die Verwaltung der Rollen.

Vermeiden Sie Berechtigungen, die speziell für einzelne Ressourcen oder Benutzer gelten. Granulare und benutzerdefinierte Berechtigungen schaffen Komplexität und Verwirrung, da sie nicht die Absicht an neue Ressourcen weitergeben, die ähnlich sind. Dies kann eine komplexe Legacykonfiguration erstellen, die schwierig zu verwalten und negative Auswirkungen sowohl auf Sicherheit als auch Zuverlässigkeit hat.

Tradeoff: Ein differenzierter Zugriffssteuerungsansatz ermöglicht eine bessere Überwachung und Überwachung von Benutzeraktivitäten.

Eine Rolle verfügt auch über einen zugeordneten Bereich. Die Rolle kann für die zulässige Verwaltungsgruppe, das Abonnement, die Ressourcengruppe oder den Ressourcenbereich oder einen anderen benutzerdefinierten Bereich verwendet werden. Selbst wenn die Identität über einen begrenzten Satz von Berechtigungen verfügt, ist die Erweiterung des Bereichs, um Ressourcen einzuschließen, die sich außerhalb der Auftragsfunktion der Identität befinden, riskant. Beispielsweise kann der Lesezugriff auf den gesamten Quellcode und die Daten gefährlich sein und kontrolliert werden.

Sie weisen Identitäten Rollen mithilfe der rollenbasierten Zugriffssteuerung (RBAC) zu. Verwenden Sie idP-bereitgestelltes RBAC immer, um Die Vorteile von Features zu nutzen, mit denen Sie die Zugriffssteuerung konsistent anwenden und sie strikt widerrufen können.

Verwenden Sie integrierte Rollen. Sie sind so konzipiert, dass sie die meisten Anwendungsfälle abdecken. Benutzerdefinierte Rollen sind leistungsfähig und manchmal nützlich, aber Sie sollten sie für Szenarien reservieren, in denen integrierte Rollen nicht funktionieren. Anpassungen erhöhen die Komplexität und können zu Verwirrungen führen. Außerdem machen sie die Automatisierung komplizierter und störanfälliger. Alle diese Faktoren wirken sich negativ auf die Sicherheit aus.

Gewähren Sie Rollen, die mit den geringsten Berechtigungen beginnen, und fügen Sie basierend auf Ihren betrieblichen oder Datenzugriffsanforderungen mehr hinzu. Ihre technischen Teams müssen klare Anleitungen zum Implementieren von Berechtigungen haben.

Wenn Sie ein differenziertes Steuerelement für RBAC wünschen, fügen Sie bedingungen für die Rollenzuweisung basierend auf dem Kontext hinzu, z. B. Aktionen und Attribute.

Auswahlmöglichkeiten für bedingten Zugriff

Geben Sie nicht allen Identitäten dieselbe Zugriffsebene. Stützen Sie Ihre Entscheidungen auf zwei Hauptfaktoren:

• Uhrzeit. Wie lange die Identität auf Ihre Umgebung zugreifen kann.

• Berechtigungen. Die Berechtigungsstufe.

Diese Faktoren schließen sich nicht gegenseitig aus. Eine kompromittierte Identität mit mehr Berechtigungen und unbegrenzter Zugriffsdauer kann mehr Kontrolle über das System und die Daten erlangen oder diesen Zugriff verwenden, um die Umgebung weiterhin zu ändern. Beschränken Sie diese Zugriffsfaktoren sowohl als präventive Maßnahme als auch um den Strahlradius zu steuern.

• Just in Time (JIT)- Ansätze bieten nur die erforderlichen Berechtigungen, wenn sie benötigt werden.

• Just Enough Access (JEA) bietet nur die erforderlichen Berechtigungen.

Obwohl Zeit und Berechtigungen die hauptfaktoren sind, gibt es andere Bedingungen, die gelten. Sie können z. B. auch das Gerät, das Netzwerk und den Standort verwenden, von dem der Zugriff zum Festlegen von Richtlinien stammt.

Verwenden Sie starke Steuerelemente, die nicht autorisierten Zugriff filtern, erkennen und blockieren, einschließlich Parametern wie Benutzeridentität und Standort, Geräteintegrität, Workloadkontext, Datenklassifizierung und Anomalien.

Ihre Workload muss z. B. von Drittanbieteridentitäten wie Lieferanten, Partnern und Kunden aufgerufen werden. Sie benötigen die entsprechende Zugriffsebene anstelle der Standardberechtigungen, die Sie Vollzeitmitarbeitern zur Verfügung stellen. Eine klare Differenzierung externer Konten erleichtert das Verhindern und Erkennen von Angriffen, die aus diesen Vektoren stammen.

Ihre Wahl des IdP muss in der Lage sein, diese Differenzierung bereitzustellen, integrierte Features bereitzustellen, die Berechtigungen basierend auf den geringsten Berechtigungen gewähren und integrierte Bedrohungserkennung bereitstellen. Dazu gehört auch die Überwachung von Zugriffsanforderungen und Anmeldungen. Der Azure IdP ist die Microsoft Entra-ID. Weitere Informationen finden Sie im Abschnitt "Azure-Erleichterung" in diesem Artikel.

Schützen kritischer Auswirkungen von Konten

Administrative Identitäten führen einige der höchsten Sicherheitsrisiken ein, da die von ihnen ausgeführten Aufgaben privilegierten Zugriff auf eine breite Palette dieser Systeme und Anwendungen erfordern. Kompromittierung oder Missbrauch kann sich negativ auf Ihr Unternehmen und seine Informationssysteme auswirken. Sicherheit der Verwaltung ist einer der kritischsten Sicherheitsbereiche.

Der Schutz des privilegierten Zugriffs vor entschlossenen Widersachern erfordert einen vollständigen und durchdachten Ansatz, um diese Systeme gegen Risiken zu isolieren. Hier sind einige Strategien aufgeführt:

• Minimieren Sie die Anzahl kritischer Auswirkungskonten.

• Verwenden Sie separate Rollen , anstatt Berechtigungen für vorhandene Identitäten zu erhöhen.

• Vermeiden Sie permanenten oder ständigen Zugriff , indem Sie die JIT-Features Ihres IdP verwenden. Für Bruchglassituationen folgen Sie einem Notfallzugriffsprozess.

• Verwenden Sie moderne Zugriffsprotokolle wie kennwortlose Authentifizierung oder mehrstufige Authentifizierung. Externalisieren Sie diese Mechanismen auf Ihren IdP.

• Erzwingen Sie wichtige Sicherheitsattribute mithilfe von Richtlinien für bedingten Zugriff.

• Außerbetriebnahme administrativer Konten , die nicht verwendet werden.

Verwenden Sie eine einzelne Identität über Umgebungen hinweg, und ordnen Sie dem Benutzer oder Prinzipal eine einzelne Identität zu. Die Konsistenz von Identitäten in cloud- und lokalen Umgebungen reduziert menschliche Fehler und die daraus resultierenden Sicherheitsrisiken. Teams in beiden Umgebungen, in denen Ressourcen verwaltet werden, benötigen eine konsistente, autoritative Quelle, um Sicherheitsüberprüfungen zu erfüllen. Arbeiten Sie mit Ihrem zentralen Identitätsteam zusammen, um sicherzustellen, dass Identitäten in Hybridumgebungen synchronisiert werden.

Risiko: Es besteht ein Risiko, das mit der Synchronisierung von Identitäten mit hohen Berechtigungen verbunden ist. Ein Angreifer kann die vollständige Kontrolle über lokale Ressourcen erhalten, und dies kann zu einer erfolgreichen Kompromittierung eines Cloudkontos führen. Bewerten Sie Ihre Synchronisierungsstrategie, indem Sie Konten filtern, die der Angriffsfläche hinzugefügt werden können.

Einrichten von Prozessen zum Verwalten des Identitätslebenszyklus

Der Zugriff auf Identitäten darf nicht länger dauern als die Ressourcen, auf die die Identitäten zugreifen. Stellen Sie sicher, dass Sie über einen Prozess zum Deaktivieren oder Löschen von Identitäten verfügen, wenn Änderungen an der Teamstruktur oder softwarekomponenten vorliegen.

Dieser Leitfaden gilt für Quellcodeverwaltung, Daten, Steuerungsebenen, Arbeitsauslastungsbenutzer, Infrastruktur, Toolerstellung, Überwachung von Daten, Protokollen, Metriken und anderen Entitäten.

Richten Sie einen Identitätsgovernanceprozess ein, um den Lebenszyklus digitaler Identitäten, privilegierter Benutzer, externer/Gastbenutzer und Workloadbenutzer zu verwalten. Implementieren Sie Zugriffsüberprüfungen, um sicherzustellen, dass die Arbeitsauslastungsberechtigungen entfernt werden, wenn Identitäten die Organisation oder das Team verlassen.

Schützen nichtidentitybasierter geheimer Schlüssel

Anwendungsgeheimnisse wie vorverschlüsselte Schlüssel sollten als anfällige Punkte im System betrachtet werden. Wenn der Anbieter oder Verbraucher kompromittiert wird, können in der bidirektionale Kommunikation erhebliche Sicherheitsrisiken eingeführt werden. Diese Schlüssel können auch belastend sein, da sie operative Prozesse einführen.

Wenn Sie können, vermeiden Sie geheime Schlüssel , und erwägen Sie die Verwendung der identitätsbasierten Authentifizierung für den Benutzerzugriff auf die Anwendung selbst, nicht nur für seine Ressourcen.

Die folgende Liste enthält eine Zusammenfassung der Anleitungen. Weitere Informationen finden Sie unter Empfehlungen für geheime Anwendungsschlüssel.

• Behandeln Sie diese geheimen Schlüssel als Entitäten, die dynamisch aus einem geheimen Speicher abgerufen werden können. Sie sollten nicht hartcodiert in Ihrem Anwendungscode, IaC-Skripts, Bereitstellungspipelinen oder in einem anderen Artefakt sein.

• Achten Sie darauf, dass Sie geheime Schlüssel widerrufen können.

• Wenden Sie betriebstechnische Methoden an, die Aufgaben wie Schlüsseldrehung und Ablauf behandeln.

Informationen zu Rotationsrichtlinien finden Sie unter Automatisieren der Drehung eines geheimen Schlüssels für Ressourcen mit zwei Authentifizierungsanmeldeinformationen und Lernprogramm: Aktualisieren der automatischen Drehungshäufigkeit des Zertifikats im Key Vault.

Schützen von Entwicklungsumgebungen

Alle Code- und Skripts, Pipelinetools und Quellcodeverwaltungssysteme sollten als Workloadressourcen betrachtet werden. Der Zugriff auf Schreibvorgänge sollte mit automatisierungs- und peer-review erfolgen . Der Lesezugriff auf Den Quellcode sollte auf rollenbezogene Basis beschränkt sein. Coderepositorys müssen Versionsverwaltung haben, und Sicherheitscodeüberprüfungen durch Peers müssen eine regelmäßige Praxis sein, die in den Entwicklungslebenszyklus integriert ist. Sie müssen über einen Prozess verfügen, der Ressourcen regelmäßig überprüft und die neuesten Sicherheitsrisiken identifiziert.

Verwenden Sie Workloadidentitäten, um Zugriff auf Ressourcen aus Bereitstellungsumgebungen wie GitHub zu gewähren.

Verwalten eines Überwachungspfads

Ein Aspekt der Identitätsverwaltung ist die Sicherstellung, dass das System überprüfbar ist. Audits überprüfen, ob Strategien gegen Sicherheitsverletzungen wirksam sind. Das Verwalten eines Überwachungspfads hilft Ihnen:

• Überprüfen Sie, ob die Identität mit starker Authentifizierung authentifiziert ist. Jede Aktion muss nachverfolgt werden können , um Abstreitungsangriffe zu verhindern.

• Erkennen Sie schwache oder fehlende Authentifizierungsprotokolle , und erhalten Sie Einblicke in Benutzer- und Anwendungsanmeldungen.

• Bewerten Sie den Zugriff von Identitäten auf die Workload basierend auf Sicherheits- und Complianceanforderungen , und berücksichtigen Sie das Benutzerkontorisiko, den Gerätestatus und andere von Ihnen festgelegte Kriterien und Richtlinien.

• Nachverfolgen des Fortschritts oder der Abweichung von Complianceanforderungen.

Die meisten Ressourcen haben Zugriff auf die Datenebene. Sie müssen die Identitäten kennen, die auf Ressourcen und die aktionen zugreifen, die sie ausführen. Sie können diese Informationen für die Sicherheitsdiagnose verwenden.

Weitere Informationen finden Sie unter Empfehlungen zur Sicherheitsüberwachung und Bedrohungsanalyse.

Azure-Erleichterung

Es wird empfohlen, immer moderne Authentifizierungsprotokolle zu verwenden, die alle verfügbaren Datenpunkte berücksichtigen und bedingten Zugriff verwenden. Die Microsoft Entra-ID stellt die Identitäts- und Zugriffsverwaltung in Azure bereit. Sie deckt die Verwaltungsebene von Azure ab und ist in die Datenebenen der meisten Azure-Dienste integriert. Die Microsoft Entra-ID ist der Mandant, der dem Workload-Abonnement zugeordnet ist. Es verfolgt und verwaltet Identitäten und deren zulässige Berechtigungen und vereinfacht das allgemeine Management, um das Risiko einer Aufsicht oder eines menschlichen Fehlers zu minimieren.

Diese Funktionen integrieren sich nativ in das gleiche Microsoft Entra-Identitäts- und Berechtigungsmodell für Benutzersegmente:

• Microsoft Entra ID. Mitarbeiter und Unternehmensressourcen.

• Externe Microsoft Entra-ID. Partner.

• Azure AD B2C. Customers.

• Microsoft Entra-Verbundkompatibilitätsliste. Partnerverbundlösungen von Drittanbietern.

Sie können Microsoft Entra-ID für die Authentifizierung und Autorisierung von benutzerdefinierten Anwendungen über Microsoft Authentication Library (MSAL) oder Plattformfeatures wie die Authentifizierung für Web-Apps verwenden. Es umfasst die Verwaltungsebene von Azure, die Datenebenen der meisten Azure-Dienste und Integrationsfunktionen für Ihre Anwendungen.

Sie können auf dem laufenden bleiben, indem Sie "Neuigkeiten" in der Microsoft Entra-ID besuchen.

Kompromiss: Microsoft Entra ID ist ein einziger Fehlerpunkt wie jeder andere grundlegende Dienst. Es gibt keine Problemumgehung, bis der Ausfall von Microsoft behoben ist. Der umfangreiche Featuresatz von Microsoft Entra überwiegt jedoch das Risiko, benutzerdefinierte Lösungen zu verwenden.

Azure-Support geöffnete Protokolle wie OAuth2 und OpenID Connect. Es wird empfohlen, diese Standardauthentifizierungs- und Autorisierungsmechanismen zu verwenden, anstatt Ihre eigenen Flüsse zu entwerfen.

Azure RBAC

Azure RBAC stellt Sicherheitsprinzipale in Microsoft Entra ID dar. Alle Rollenzuweisungen werden über Azure RBAC ausgeführt. Nutzen Sie integrierte Rollen, die die meisten der benötigten Berechtigungen bereitstellen. Weitere Informationen finden Sie unter Integrierte Rollen in Microsoft Entra.

Hier sind einige Anwendungsfälle:

• Durch das Zuweisen von Benutzern zu Rollen können Sie den Zugriff auf Azure-Ressourcen steuern. Weitere Informationen finden Sie unter Übersicht über die rollenbasierte Zugriffssteuerung in microsoft Entra ID.

• Sie können Privileged Identity Management verwenden, um zeitbasierte und genehmigungsbasierte Rollenaktivierung für Rollen bereitzustellen, die mit Identitäten mit hohem Einfluss verbunden sind. Weitere Informationen finden Sie unter Was ist Privileged Identity Management?.

Weitere Informationen zu RBAC finden Sie unter Bewährte Methoden für Azure RBAC.

Informationen zu attributbasierten Steuerelementen finden Sie unter Was ist Azure ABAC?.

Workloadidentität

Die Microsoft Entra-ID kann die Identität Ihrer Anwendung verarbeiten. Der Dienstprinzipal, der der Anwendung zugeordnet ist, kann den Zugriffsbereich diktieren.

Weitere Informationen finden Sie unter Was sind Workloadidentitäten?.

Der Dienstprinzipal wird auch abstrahiert, wenn Sie eine verwaltete Identität verwenden. Der Vorteil besteht darin, dass Azure alle Anmeldeinformationen für die Anwendung verwaltet.

Nicht alle Dienste unterstützen verwaltete Identitäten. Wenn Sie keine verwalteten Identitäten verwenden können, können Sie Dienstprinzipale verwenden. Die Verwendung von Dienstprinzipalen erhöht jedoch ihren Verwaltungsaufwand. Weitere Informationen finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen?.

Ressourcenidentität

Das Konzept der verwalteten Identitäten kann auf Azure-Ressourcen erweitert werden. Azure-Ressourcen können verwaltete Identitäten verwenden, um sich bei anderen Diensten zu authentifizieren, die die Microsoft Entra-Authentifizierung unterstützen. Weitere Informationen finden Sie unter Azure-Dienste, die verwaltete Identitäten für den Zugriff auf andere Dienste verwenden können.

Bedingte Zugriffsrichtlinien

Der bedingte Zugriff beschreibt Ihre Richtlinie für eine Zugriffsentscheidung. Um bedingten Zugriff zu verwenden, müssen Sie die Für den Anwendungsfall erforderlichen Einschränkungen verstehen. Konfigurieren Sie den bedingten Zugriff von Microsoft Entra, indem Sie eine Zugriffsrichtlinie für diese basierend auf Ihren betrieblichen Anforderungen einrichten.

Weitere Informationen finden Sie unter Bedingter Zugriff: Benutzer, Gruppen und Workloadidentitäten.

Gruppenzugriffsverwaltung

Anstatt bestimmten Benutzern Berechtigungen zu erteilen, weisen Sie den Zugriff in Microsoft Entra ID Gruppen zu. Wenn keine Gruppe vorhanden ist, arbeiten Sie mit Ihrem Identitätsteam zusammen, um eine gruppe zu erstellen. Anschließend können Sie Gruppenmitglieder außerhalb von Azure hinzufügen und entfernen und sicherstellen, dass Berechtigungen aktuell sind. Sie können die Gruppe auch für andere Zwecke verwenden, z. B. Mailinglisten.

Weitere Informationen finden Sie unter Sichere Zugriffssteuerung mithilfe von Gruppen in der Microsoft Entra-ID.

Bedrohungserkennung

Microsoft Entra ID Protection kann Ihnen helfen, identitätsbasierte Risiken zu erkennen, zu untersuchen und zu beheben. Weitere Informationen finden Sie unter "What is Identity Protection".

Die Bedrohungserkennung kann in Form einer Reaktion auf eine Warnung verdächtiger Aktivitäten oder proaktiv nach anomalen Ereignissen in Aktivitätsprotokollen suchen. Die Benutzer- und Entitätsverhaltensanalyse (User and Entity Behavior Analytics, UEBA) in Microsoft Sentinel erleichtert das Erkennen verdächtiger Aktivitäten. Weitere Informationen finden Sie unter Identifizieren erweiterter Bedrohungen mit UEBA.

Hybridsysteme

Synchronisieren Sie in Azure keine Konten mit microsoft Entra-ID, die über hohe Berechtigungen in Ihrem vorhandenen Active Directory verfügen. Diese Synchronisierung wird in der Microsoft Entra Connect-Synchronisierungskonfiguration blockiert, sodass Sie nur bestätigen müssen, dass Sie diese Konfiguration nicht angepasst haben.

Informationen zum Filtern in der Microsoft Entra-ID finden Sie unter Microsoft Entra Connect Sync: Konfigurieren der Filterung.

Identitätsprotokollierung

Aktivieren Sie Diagnoseeinstellungen für Azure-Ressourcen , um Informationen auszugeben, die Sie als Überwachungspfad verwenden können. Die Diagnoseinformationen zeigen, welche Identitäten versuchen, auf welche Ressourcen und das Ergebnis dieser Versuche zuzugreifen. Die gesammelten Protokolle werden an Azure Monitor gesendet.

Kompromiss: Die Protokollierung verursacht Kosten aufgrund der Datenspeicherung, die zum Speichern der Protokolle verwendet wird. Dies kann auch zu Leistungseinbußen führen, insbesondere auf den Code und auf die Protokollierung von Lösungen, die Sie der Anwendung hinzufügen.

Beispiel

Das folgende Beispiel zeigt eine Identitätsimplementierung. Verschiedene Identitätstypen werden zusammen verwendet, um die erforderlichen Zugriffsebenen bereitzustellen.

Identitätskomponenten

• Vom System verwaltete Identitäten. Die Microsoft Entra-ID bietet Zugriff auf Dienstdatenebenen, die keine Benutzer haben, z. B. Azure Key Vault und Datenspeicher. Diese Identitäten steuern auch den Zugriff über RBAC auf die Azure-Verwaltungsebene für Workloadkomponenten, Bereitstellungs-Agents und Teammitglieder.

• Workloadidentitäten. Die Anwendungsdienste im Azure Kubernetes Service (AKS)-Cluster verwenden Workloadidentitäten, um sich bei anderen Komponenten in der Lösung zu authentifizieren.

• Verwaltete Identitäten. Systemkomponenten in der Clientrolle verwenden vom System verwaltete Identitäten, einschließlich Build-Agents.

• Menschliche Identitäten. Die Benutzer- und Operatorauthentifizierung wird an microsoft Entra ID oder Microsoft Entra ID (systemeigene, B2B oder B2C) delegiert.

Die Sicherheit von vorfreigaben geheimen Schlüsseln ist für jede Anwendung von entscheidender Bedeutung. Azure Key Vault bietet einen sicheren Speichermechanismus für diese geheimen Schlüssel, einschließlich Redis und Geheimschlüssel von Drittanbietern.

Ein Drehungsmechanismus wird verwendet, um sicherzustellen, dass geheime Schlüssel nicht kompromittiert werden. Token für die Microsoft Identity Platform-Implementierung von OAuth 2 und OpenID Connect werden verwendet, um Benutzer zu authentifizieren.

Azure-Richtlinie wird verwendet, um sicherzustellen, dass Identitätskomponenten wie Key Vault RBAC anstelle von Zugriffsrichtlinien verwenden. JIT und JEA bieten herkömmliche Stehberechtigungen für menschliche Operatoren.

Zugriffsprotokolle werden über Azure-Diagnose oder über Code für Codekomponenten über alle Komponenten hinweg aktiviert.

Verwandte Links

• Lernprogramm: Automatisieren der Drehung eines geheimen Schlüssels für Ressourcen mit zwei Gruppen von Authentifizierungsanmeldeinformationen
• Lernprogramm: Aktualisieren der automatischen Drehungshäufigkeit des Zertifikats im Key Vault
• Welche Neuerungen gibt es in Microsoft Entra ID?
• Integrierte Microsoft Entra-Rollen
• Übersicht über die rollenbasierte Zugriffssteuerung in Microsoft Entra ID
• Was sind Workloadidentitäten?
• Was sind verwaltete Identitäten für Azure-Ressourcen?
• Bedingter Zugriff: Benutzer, Gruppen und Workloadidentitäten
• Microsoft Entra Connect-Synchronisierung: Konfigurieren der Filterung

Checkliste für die Sicherheit

Lesen Sie den vollständigen Satz von Empfehlungen.

Checkliste für die Sicherheit