Empfehlungen für die Identitäts- und Zugriffsverwaltung

  • Artikel

Gilt für die folgende Empfehlung der Sicherheitsprüfliste für Azure Well-Architected Framework:

SE:05 Implementieren Sie eine strenge, bedingte und überprüfbare Identitäts- und Zugriffsverwaltung (IAM) für alle Workloadbenutzer, Teammitglieder und Systemkomponenten. Beschränken Sie den Zugriff nach Bedarf ausschließlich auf. Verwenden Sie moderne Industriestandards für alle Authentifizierungs- und Autorisierungsimplementierungen. Beschränken und überwachen Sie den Zugriff, der nicht auf der Identität basiert, und überwachen Sie sie streng.

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

Aus sicht der technischen Steuerung ist Identität immer der primäre Umkreis. Dieser Bereich umfasst nicht nur die Kanten Ihrer Workload. Es enthält 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 

Begriffe Definition
Authentifizierung (AuthN) Ein Prozess, der überprüft, ob eine Identität ist, wer 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 Ein Satz von Regeln, der Aktionen basierend auf angegebenen Kriterien zulässt.
IdP Ein Identitätsanbieter, z. B. Microsoft Entra ID.
Persona Eine Auftragsfunktion oder ein Titel, der über eine Reihe von Zuständigkeiten und Aktionen verfügt.
Vorab freigegebene Schlüssel Eine Art von Geheimnis, das zwischen einem Anbieter und einem Verbraucher gemeinsam genutzt 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 wird.
Rolle Ein Satz von Berechtigungen, die definieren, was ein Benutzer oder eine Gruppe tun kann.
`Scope` Verschiedene Ebenen der Organisationshierarchie, in denen eine Rolle verwendet 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 die gleiche Zugriffsebene.
Benutzeridentität Eine Identität für eine Person, z. B. ein Mitarbeiter oder ein externer Benutzer.
Workload-Identität Eine Systemidentität für eine Anwendung, einen Dienst, ein Skript, einen Container oder eine andere Komponente einer Workload, die zur Authentifizierung bei anderen Diensten und Ressourcen verwendet wird.

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, verringert sich auch die Wahrscheinlichkeit von Fehlern. In diesem Artikel ist der Begriff Identität einschließlich sicherheitsprinzipaler.

Die Rolle eines Identitätsanbieters

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

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

Authentifizierung

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

  • Ein Benutzername und ein Kennwort.

  • Ein vorab freigegebenes Geheimnis, 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.

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

Authorization

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, was Sie mithilfe der von Ihrem Identitätsanbieter bereitgestellten Funktionen tun müssen.

Wichtige Entwurfsstrategien

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

Jeder Anwendungsfall verfügt wahrscheinlich über einen eigenen Satz von Steuerelementen, die Sie mit einer Annahme- und Sicherheitsverletzungsmentalität 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 Konformitätsü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 durch Aufrufen von APIs auf die Anwendung zugreift.

    Auf einer präzisen Ebene benötigen Komponenten der Workload möglicherweise auch Zugriff von außen. Beispielsweise ein Operator, der Zugriff über das Portal oder Zugriff auf die Compute-Instanz benötigt, um Befehle auszuführen.

    Beides sind Beispiele für Benutzeridentitäten mit unterschiedlichen Personas.

  • Zugriff von innen: Ihre Anwendung muss auf andere Ressourcen zugreifen. Beispiel: Lesen oder Schreiben in die Datenplattform, Abrufen von Geheimnissen aus dem Geheimnisspeicher und Protokollieren von Telemetriedaten für Überwachungsdienste. Möglicherweise muss sie sogar auf Drittanbieterdienste zugreifen. Diese Zugriffsanforderungen erfordern eine Workloadidentität, 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 zu erhalten. Diese Zugriffsanforderungen erfordern eine Ressourcenidentität.

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

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

Diagramm, das zeigt, 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 versucht, damit diese Aktionen autorisiert werden können. Die Aktionen können durch die Art des Zugriffs unterteilt werden, die sie benötigen:

  • Zugriff auf Datenebene. Aktionen, die auf der Datenebene stattfinden, führen zur Datenübertragung für den Zugriff von innen oder außen. Beispielsweise liest eine Anwendung Daten aus einer Datenbank und schreibt Daten in eine Datenbank, ruft Geheimnisse ab oder schreibt Protokolle in eine Überwachungssenke. Auf Komponentenebene werden Computevorgänge, die Images an oder aus einer Registrierung per Pulling oder Pushing an oder aus einer Registrierung übertragen, als Vorgänge auf Datenebene betrachtet.

  • Steuern sie den Zugriff auf ebener Ebene. Aktionen, die auf der Steuerungsebene stattfinden, führen dazu, dass eine Azure-Ressource erstellt, geändert oder gelöscht wird. Beispiel: Änderungen an Ressourceneigenschaften.

Anwendungen zielen in der Regel auf Vorgänge auf Datenebene ab, während Vorgänge häufig sowohl auf Steuerungsebenen als auch auf Datenebenen zugreifen. Beachten Sie zum Identifizieren der Autorisierungsanforderungen 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 Vorgänge des Azure-Ressourcenanbieters.

Bereitstellen einer rollenbasierten Autorisierung

Autorisieren Sie basierend auf der Verantwortung der einzelnen Identitäten 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 dafür haben, wer oder was Anforderungen stellt, was diese Rolle tun darf und in welchem Umfang sie dies tun kann. Diese Faktoren führen zu Entscheidungen, die Identität, Rolle und Bereich kombinieren.

Betrachten Sie als Beispiel eine Workloadidentität. Die Anwendung muss über Zugriff auf die Datenebene auf die Datenbank verfügen. Daher müssen Lese- und Schreibaktionen für die Datenressource zulässig sein. Benötigt die Anwendung jedoch Zugriff auf die Steuerungsebene auf den Geheimspeicher? Wenn die Workloadidentität durch einen schlechten Akteur kompromittiert wird, welche Auswirkungen hätte 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, die es der Identität nur erlauben, die Aufgabe abzuschließen, und nicht mehr. Wenn die Berechtigungen des Benutzers auf die Auftragsanforderungen beschränkt sind, ist es einfacher, verdächtiges oder nicht autorisiertes Verhalten im System zu identifizieren.

Stellen Sie Fragen wie die folgenden:

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

Durch die Einschränkung des Zugriffs von Benutzern, Anwendungen oder Diensten auf Azure-Ressourcen wird die potenzielle Angriffsfläche verringert. 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. Beispielsweise benötigen Sicherheitsteams nur schreibgeschützten Zugriff auf Sicherheitsattribute für alle technischen Umgebungen. Diese Ebene reicht aus, um Risikofaktoren zu bewerten, potenzielle Entschärfungen zu identifizieren und über die Risiken zu berichten.

Es gibt Szenarien, in denen Benutzer aufgrund der Organisationsstruktur und der Team-organization mehr Zugriff benötigen. Es kann zu einer Überschneidung zwischen verschiedenen Rollen kommen, oder einzelne Benutzer können mehrere Standardrollen ausführen. 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 die Absicht nicht an neue Ressourcen weitergeben, die ähnlich sind. Dies kann zu einer komplexen Legacykonfiguration führen, die schwer zu verwalten ist und sich negativ auf Die Sicherheit und Zuverlässigkeit auswirkt.

Kompromiss: Ein differenzierter Ansatz zur Zugriffssteuerung ermöglicht eine bessere Überwachung und Überwachung von Benutzeraktivitäten.

Eine Rolle verfügt auch über einen zugeordneten Bereich. Die Rolle kann in der zulässigen Verwaltungsgruppe, im Abonnement, in der Ressourcengruppe oder im Ressourcenbereich oder in einem anderen benutzerdefinierten Bereich ausgeführt werden. Auch wenn die Identität über einen begrenzten Berechtigungssatz verfügt, ist die Erweiterung des Bereichs auf Ressourcen, die sich außerhalb der Auftragsfunktion der Identität befinden, riskant. Beispielsweise kann der Lesezugriff auf den gesamten Quellcode und alle Daten gefährlich sein und muss gesteuert werden.

Sie weisen Identitäten Mithilfe der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) Rollen zu. Verwenden Sie immer die von IdP bereitgestellte RBAC , um Features zu nutzen, mit denen Sie die Zugriffssteuerung konsistent anwenden und sie rigoros widerrufen können.

Verwenden Sie integrierte Rollen. Sie sind so konzipiert, dass sie die meisten Anwendungsfälle abdecken. Benutzerdefinierte Rollen sind leistungsstark 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.

Erteilen Sie Rollen, die mit den geringsten Berechtigungen beginnen, und fügen Sie basierend auf Ihren betrieblichen oder Datenzugriffsanforderungen weitere hinzu. Ihre technischen Teams benötigen eine klare Anleitung zum Implementieren von Berechtigungen.

Wenn Sie eine differenzierte Steuerung für RBAC wünschen, fügen Sie Bedingungen für die Rollenzuweisung basierend auf dem Kontext hinzu, z. B. Aktionen und Attribute.

Treffen von Optionen für bedingten Zugriff

Weisen Sie nicht allen Identitäten die gleiche Zugriffsebene zu. Stützen Sie Ihre Entscheidungen auf zwei Standard Faktoren:

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

  • Berechtigung. Die Berechtigungsebene.

Diese Faktoren schließen sich nicht gegenseitig aus. Eine kompromittierte Identität, die über mehr Berechtigungen und unbegrenzte Zugriffsdauer verfügt, 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 vorbeugende Maßnahme als auch, um den Strahlradius zu steuern.

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

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

Obwohl Zeit und Berechtigungen die Hauptfaktoren sind, gelten andere Bedingungen. Sie können beispielsweise auch das Gerät, das Netzwerk und den Speicherort verwenden, von dem aus der Zugriff stammt, um Richtlinien festzulegen.

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.

Beispielsweise muss auf Ihre Workload möglicherweise von Identitäten von Drittanbietern wie Anbietern, Partnern und Kunden zugegriffen werden. Sie benötigen die entsprechende Zugriffsebene und nicht die Standardberechtigungen, die Sie Vollzeitmitarbeitern zur Verfügung stellen. Eine klare Unterscheidung von externen Konten erleichtert die Verhinderung und Erkennung von Angriffen, die von diesen Vektoren ausgehen.

Ihre Wahl des IdP muss in der Lage sein, diese Differenzierung bereitzustellen, integrierte Features bereitzustellen, die Berechtigungen basierend auf den geringsten Berechtigungen erteilen, und integrierte Threat Intelligence bereitstellen. Dies umfasst die Überwachung von Zugriffsanforderungen und Anmeldungen. Der Azure IdP ist Microsoft Entra ID. Weitere Informationen finden Sie im Abschnitt Azure-Erleichterung dieses Artikels.

Konten mit kritischen Auswirkungen

Administrative Identitäten führen zu den größten Sicherheitsrisiken, da die von ihnen ausgeführten Aufgaben privilegierten Zugriff auf eine breite Palette dieser Systeme und Anwendungen erfordern. Kompromittierung oder Missbrauch kann sich nachteilig auf Ihr Unternehmen und seine Informationssysteme auswirken. Die Sicherheit der Verwaltung ist einer der wichtigsten 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 von Konten mit kritischen Auswirkungen.

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

  • Vermeiden Sie permanenten oder dauerhaften Zugriff , indem Sie die JIT-Features Ihres IdP verwenden. Führen Sie bei Bruchglassituationen einen Notfallzugriffsprozess aus.

  • 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 von nicht verwendeten Verwaltungskonten .

Verwenden Sie eine einzelne Identität in allen Umgebungen, 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, die Ressourcen verwalten, benötigen eine konsistente, autoritative Quelle, um Sicherheitsgarantien zu erfüllen. Arbeiten Sie mit Ihrem zentralen Identitätsteam zusammen, um sicherzustellen, dass Identitäten in Hybridumgebungen synchronisiert werden.

Risiko: Bei der Synchronisierung von Identitäten mit hohen Berechtigungen besteht ein Risiko. Ein Angreifer kann die volle Kontrolle über lokale Ressourcen erhalten, was zu einer erfolgreichen Kompromittierung eines Cloudkontos führen kann. Bewerten Sie Ihre Synchronisierungsstrategie, indem Sie Konten herausfiltern, 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 in der Teamstruktur oder in Softwarekomponenten vorgenommen werden.

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

Richten Sie einen Identitätsgovernanceprozess ein, um den Lebenszyklus von digitalen Identitäten, Benutzern mit hohen Berechtigungen, externen/Gastbenutzern und Workloadbenutzern zu verwalten. Implementieren Sie Zugriffsüberprüfungen, um sicherzustellen, dass ihre Workloadberechtigungen entfernt werden, wenn Identitäten die organization oder das Team verlassen.

Schützen nichtidentitätsbasierter Geheimnisse

Anwendungsgeheimnisse wie vorab freigegebene Schlüssel sollten als anfällige Punkte im System betrachtet werden. In der bidirektionalen Kommunikation können erhebliche Sicherheitsrisiken entstehen, wenn der Anbieter oder Verbraucher kompromittiert wird. Diese Schlüssel können auch belastend sein, da sie betriebliche Prozesse einführen.

Wenn möglich, vermeiden Sie die Verwendung von Geheimnissen , und erwägen Sie die Verwendung der identitätsbasierten Authentifizierung für den Benutzerzugriff auf die Anwendung selbst, nicht nur auf ihre Ressourcen.

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

  • Behandeln Sie diese Geheimnisse als Entitäten, die dynamisch aus einem geheimen Speicher abgerufen werden können. Sie sollten nicht in Ihrem Anwendungscode, IaC-Skripts, Bereitstellungspipelines oder in einem anderen Artefakt hart codiert sein.

  • Stellen Sie sicher, dass Sie geheimnisse widerrufen können.

  • Wenden Sie Betriebspraktiken an, die Aufgaben wie Schlüsselrotation und Ablauf behandeln.

Informationen zu Rotationsrichtlinien finden Sie unter Automatisieren der Rotation eines Geheimnisses für Ressourcen mit zwei Authentifizierungsanmeldeinformationen und Tutorial: Aktualisieren der Häufigkeit der automatischen Zertifikatrotation in 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 Automatisierung und Peer Review abgegrenzt werden. Der Lesezugriff auf Quellcode sollte auf Rollen beschränkt sein , die benötigt werden müssen. Coderepositorys müssen über eine Versionsverwaltung verfügen, und Sicherheitscodeüberprüfungen durch Peers müssen eine reguläre Methode 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 besteht darin, sicherzustellen, dass das System überprüfbar ist. Überprüfungen überprüfen, ob Strategien zur Annahme von Sicherheitsverletzungen wirksam sind. Das Verwalten eines Überwachungspfads hilft Ihnen dabei:

  • Überprüfen Sie, ob die Identität mit einer starken Authentifizierung authentifiziert ist. Jede Aktion muss nachverfolgbar sein , um Ablehnungsangriffe zu verhindern.

  • Erkennen Sie schwache oder fehlende Authentifizierungsprotokolle und erhalten Sie Einblick 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, die gerätebasierte status und andere von Ihnen festgelegte Kriterien und Richtlinien.

  • Verfolgen Sie den Fortschritt oder die Abweichung von Den Complianceanforderungen.

Die meisten Ressourcen haben Zugriff auf Datenebene. Sie müssen die Identitäten kennen, die auf Ressourcen zugreifen, und die von ihnen ausgeführten Aktionen. Sie können diese Informationen für die Sicherheit Diagnose 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. Microsoft Entra-ID bietet Identitäts- und Zugriffsverwaltung in Azure. Es deckt die Verwaltungsebene von Azure ab und ist in die Datenebenen der meisten Azure-Dienste integriert. Microsoft Entra-ID ist der Mandant, der dem Workloadabonnement zugeordnet ist. Es verfolgt und verwaltet Identitäten und ihre zulässigen Berechtigungen und vereinfacht die gesamte Verwaltung, um das Risiko von Aufsicht oder menschlichem Fehler zu minimieren.

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

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

Sie können auf dem neuesten Stand bleiben, indem Sie Neuigkeiten in Microsoft Entra ID besuchen.

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

Azure unterstützt offene Protokolle wie OAuth2 und OpenID Connect. Es wird empfohlen, diese Standardauthentifizierungs- und Autorisierungsmechanismen zu verwenden, anstatt eigene Flows zu entwerfen.

Azure RBAC

Azure RBAC stellt Sicherheitsprinzipale in Microsoft Entra ID dar. Alle Rollenzuweisungen werden über Azure RBAC durchgeführt. Profitieren Sie von integrierten Rollen, die die meisten berechtigungen bereitstellen, die Sie benötigen. Weitere Informationen finden Sie unter Integrierte Rollen in Microsoft Entra.

Hier sind einige Anwendungsfälle:

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?.

Workload-Identität

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

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

Der Dienstprinzipal wird auch abstrahiert, wenn Sie eine verwaltete Identität verwenden. Der Vorteil ist, 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 den 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 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

Bedingter Zugriff beschreibt Ihre Richtlinie für eine Zugriffsentscheidung. Um bedingten Zugriff zu verwenden, müssen Sie die Einschränkungen verstehen, die für den Anwendungsfall erforderlich sind. Konfigurieren Sie Microsoft Entra bedingten Zugriff, indem Sie eine Zugriffsrichtlinie einrichten, die auf Ihren betrieblichen Anforderungen basiert.

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

Gruppenzugriffsverwaltung

Anstatt bestimmten Benutzern Berechtigungen zu erteilen, weisen Sie Gruppen zugriff in Microsoft Entra ID 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 die Berechtigungen aktuell sind. Sie können die Gruppe auch für andere Zwecke wie Mailinglisten verwenden.

Weitere Informationen finden Sie unter Schützen der Zugriffssteuerung mithilfe von Gruppen in Microsoft Entra ID.

Bedrohungserkennung

Microsoft Entra ID Protection können Sie identitätsbasierte Risiken erkennen, untersuchen und beheben. Weitere Informationen finden Sie unter Was ist Identitätsschutz?.

Die Bedrohungserkennung kann in Form einer Reaktion auf eine Warnung verdächtiger Aktivitäten oder der proaktiven Suche nach anomalen Ereignissen in Aktivitätsprotokollen erfolgen. Die Benutzer- und Entitätsverhaltensanalyse (User and Entity Behavior Analytics, UEBA) in Microsoft Sentinel erleichtert die Erkennung verdächtiger Aktivitäten. Weitere Informationen finden Sie unter Identifizieren von erweiterten 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 ist in der Standardkonfiguration Microsoft Entra Connect Sync blockiert, sodass Sie nur bestätigen müssen, dass Sie diese Konfiguration nicht angepasst haben.

Informationen zum Filtern in 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 zuzugreifen, und das Ergebnis dieser Versuche. Die gesammelten Protokolle werden an Azure Monitor gesendet.

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

Beispiel

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

Diagramm, das eine Identitätsimplementierung zeigt.

Identitätskomponenten

  • Vom System verwaltete Identitäten. 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 AKS-Cluster (Azure Kubernetes Service) 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 (native, B2B oder B2C) delegiert.

Die Sicherheit vorab freigegebener Geheimnisse ist für jede Anwendung von entscheidender Bedeutung. Azure Key Vault bietet einen sicheren Speichermechanismus für diese Geheimnisse, einschließlich Redis und Geheimnisse von Drittanbietern.

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

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

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

Checkliste für die Sicherheit

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Checkliste für die Sicherheit