Verhinderung einer Identitätskrise in Azure

Da Unternehmen immer mehr Vorgänge in die Cloud verlagern, ist es von entscheidender Bedeutung, die Sicherheit dieser Vorgänge zu gewährleisten. Wir verwenden Hardware-Tokens, komplexe Passwörter, Einmal-Passwörter und Authentifizierungs-Apps, um menschliche Konten zu authentifizieren. Bleibt die Frage: Wie können wir dies sicher mit Systemkonten tun? In diesem Artikel stelle ich Ihnen die verschiedenen Optionen vor und gebe Beispiele, wie Sie die einzelnen Optionen am besten einsetzen.

Das Prinzip der geringsten Bevorzugung

Bevor wir ins Detail gehen, sollten Sie das Prinzip der geringsten Privilegien kennen.

Das Prinzip der geringsten Privilegien ist ein wesentlicher Aspekt der Sicherheit in der Cloud. Es beinhaltet die Gewährung des minimalen Zugriffs, der für die Durchführung einer bestimmten Aufgabe erforderlich ist. Die Minimierung der Berechtigungen trägt dazu bei, das Risiko von Sicherheitsverletzungen und unbefugtem Zugriff auf sensible Daten zu verringern.

Systemkonten in Azure

Bei Systemkonten in Azure muss bei der Anwendung des Prinzips der geringsten Rechte sorgfältig geprüft werden, welche Zugriffsebene jedes Konto benötigt. So kann es beispielsweise sein, dass Sie ein Systemkonto haben, das nur Zugriff auf eine bestimmte Untergruppe von Ressourcen benötigt, z. B. nur Lesezugriff auf eine Datenbank. In diesem Fall wäre es unnötig, dem Konto vollen administrativen Zugriff zu gewähren und das Risiko von Sicherheitsverstößen zu erhöhen.

Drei Arten von Identitäten in Azure

Für die Authentifizierung von Diensten gegenüber anderen Diensten, die in Azure ausgeführt werden, können Sie zwischen verschiedenen Optionen wählen, z. B. Service Principals, Managed Identities und Federated Identities. Jede hat ihre Vor- und Nachteile.

Serviceprinzipien

Die Verwendung eines Service Principal war die früheste Methode zur Authentifizierung von Systemen bei Azure Active Directory (AAD). Ein Service Principal ist eine Identität, die für die Verwendung mit Anwendungen, Diensten und Automatisierungstools für den Zugriff auf bestimmte Azure-Ressourcen erstellt wird. Sie verwenden sie, um Anwendungen für den Zugriff auf bestimmte Azure-Ressourcen zu authentifizieren und zu autorisieren. Service Principals sind ähnlich wie Benutzerkonten, aber Sie verwenden sie für nicht-interaktive Szenarien. Um sich mit einem Service Principal zu authentifizieren, müssen Sie die Kennung des Clients und ein Client Secret oder ein Client-Zertifikat angeben. Sowohl Kennwörter als auch Zertifikate haben ein Ablaufdatum, so dass Ihr Authentifizierungssystem in der Lage sein muss, mit der Erneuerung von Geheimnissen umzugehen. Das Authentifizierungssystem muss nicht in Azure laufen, sondern kann überall laufen, solange ein Internetzugang verfügbar ist. In Abbildung 1 können Sie sehen, wie das funktioniert.

Abbildung 1: Verwendung eines Service-Prinzipals

Wann zu verwenden

Verwenden Sie diesen Ansatz, wenn Sie die vollständige Kontrolle über das System haben, das den Zugriff anfordert. Service Principals eignen sich zum Beispiel sehr gut für die Erstellung von Ressourcen in Azure mit einer GitHub Actions-Pipeline. GitHub Actions verfügt über eine integrierte Funktion zur Weitergabe des Client Secret Ihres Service Principals an die Aufgaben, die die Ressourcen erstellen. Sie haben die vollständige Kontrolle über beide Systeme, was dies zu einer praktikablen Option macht. Stellen Sie sicher, dass Sie dem Service Principal die richtigen Rechte zuweisen, z.B. indem Sie ihm die Azure Role Based Access Control (RBAC) Rolle 'Contributor' im Rahmen einer Ressourcengruppe oder (höchstens) eines Abonnements zuweisen. Mit der Rolle 'Contributor' kann der Principal zwar Ressourcen erstellen, hat aber keinen Zugriff auf die in den Ressourcen gespeicherten Daten und kann auch keine Rollen zuweisen.

Verwaltete Identitäten

Eine verwaltete Identität ist ein von Azure verwalteter Service-Prinzipal. Damit können Sie bestimmte Azure-Ressourcen für den Zugriff auf andere Azure-Ressourcen authentifizieren. Der Hauptunterschied zu regulären Service Principals besteht darin, dass Sie keine Anmeldedaten speichern müssen, um sie zu verwenden; Azure verwaltet dies und den geheimen Rollover für Sie. Der Nachteil von Managed Identity ist, dass das authentifizierende System innerhalb von Azure laufen muss, um eine Managed Identity zugewiesen zu bekommen.

Wann zu verwenden

Verwaltete Identitäten können nur Azure-Ressourcen zugewiesen werden, was ihre Verwendung auf Cloud-Dienste beschränkt, die innerhalb von Azure laufen. Meiner Meinung nach sollten Sie sich bei der Authentifizierung zwischen Azure-Diensten so weit wie möglich auf Managed Identities verlassen. Sie können zum Beispiel eine Managed Identity mit einer Azure Web App konfigurieren und ihr den Zugriff auf eine Azure SQL-Datenbank erlauben, wie in Abbildung 2 dargestellt.

Abbildung 2: Beispiel für Managed Identity

In ähnlicher Weise können Sie Managed Identity verwenden, um Ihrer Web-App den Zugriff auf Dienste wie Speicherkonten, Key Vaults, Service Bus usw. zu ermöglichen. Die meisten gängigen Azure-Dienste unterstützen heutzutage Managed Identity.

Die mit der Web App verbundene Managed Identity muss auf die Azure SQL-Datenbank zugreifen dürfen. Wie bei den Dienstprinzipalen können Sie dies mit Azure RBAC tun. In diesem Fall muss der Principal auf die Daten zugreifen dürfen, aber nicht die Ressource selbst verändern dürfen. Dies können Sie erreichen, indem Sie einen SQL-Benutzer in der Datenbank anlegen, der sich mit der verwalteten Identität anmeldet. Als nächstes müssen Sie ihm datenbankspezifische Rollen zuweisen. Auf diese Weise kann die Managed Identity nur für einen einzigen Zweck mit minimalen Privilegien verwendet werden.

Föderierte Identitäten

Eine föderierte Identität in Azure wird mit Hilfe eines externen Identitätsanbieters (IDP) bei AAD authentifiziert, dem Sie vertrauen. Sie authentifizieren zunächst ein System mit dem externen IDP und erhalten über Identity Federation Zugriff auf Azure-Ressourcen. Wenn zwei IDPs föderiert sind, vertraut ein IDP den vom anderen ausgestellten Token.

Mit einer föderierten Identität können Sie auf Azure-Ressourcen zugreifen, die außerhalb von Azure laufen, ohne dass Sie Anmeldedaten des Service Principals benötigen. Da Sie eine externe IDP verwenden, können Sie auch die Art und Weise steuern, wie diese Zugriffs- und Identitäts-Token ausstellt, was interessante Szenarien eröffnet. So können Sie beispielsweise eine lokal ausgeführte containerisierte IDP ein Token für ein Servicekonto in Kubernetes ausstellen lassen. Sie können Azure AD so konfigurieren, dass es dem containerisierten IDP vertraut und dessen Token zur Authentifizierung eines Service Principal verwendet. Es stellt sich heraus, dass dieses Szenario bereits unter dem Namen 'Workload Identity' existiert. In Abbildung 3 können Sie sehen, wie es funktioniert.

Abbildung 3: Beispiel einer föderierten Identität

Wann zu verwenden

Die Verwendung der föderierten Identität funktioniert gut, wenn Sie Arbeitslasten in Azure Kubernetes Service ausführen. Aber der Mechanismus funktioniert auch außerhalb von Azure. Es spielt keine Rolle, wo Ihr Code ausgeführt wird, solange Sie Azure Active Directory richtig konfiguriert haben und AAD den Metadaten-Endpunkt Ihrer lokalen IDP über das öffentliche Internet erreichen kann.

Federated Identity kann auch funktionieren, wenn Sie Systemen, die Ihnen nicht gehören, den Zugriff auf Ihre AAD-kontrollierten Ressourcen erlauben. Leider erlaubt Microsoft nicht, dass der entfernte IDP Azure Active Directory ist. Ansonsten können Sie Vertrauensstellungen zu jedem entfernten OAuth-kompatiblen IDP konfigurieren. Stellen Sie sich vor, Sie haben einen Geschäftspartner, der von einem seiner Systeme aus auf Ihre durch AAD geschützte Web-API zugreifen möchte. Er schützt seine Systeme mit der Identity Server-Plattform von Duende. Anstatt ihm die (ablaufenden) Anmeldeinformationen eines Service Principals zur Verfügung zu stellen, könnten Sie eine Federated Identity einrichten, wie in Abbildung 4 beschrieben.

Abbildung 4: Beispiel einer Unternehmensföderation

Fazit

Der Wechsel in die Cloud bringt eine Reihe neuer Sicherheitsherausforderungen mit sich. Wenn Sie jedoch die verschiedenen Optionen in Microsoft Azure und Azure Active Directory kennen, können Sie Ihre Workloads sichern und eine Identitätskrise verhindern. Unabhängig davon, ob Sie Service Principals, Managed Identities oder Federated & Workload Identity verwenden, ist die Anwendung des Least-Privilege-Prinzips zur Verringerung des Risikos von Sicherheitsverstößen und des unbefugten Zugriffs auf sensible Daten von entscheidender Bedeutung.

Bilder generiert mit Websequencediagrams.com/