Sichern der Azure-Umgebung
Da Sie nun wissen, wie Sie Ihre Umgebungen kontrollieren und Ihre Bereitstellungspipelines sichern können, können Sie in Erwägung ziehen, den menschlichen Zugriff auf Ihre kontrollierten Umgebungen zu deaktivieren. In dieser Lerneinheit erfahren Sie, wie Sie die Berechtigungen Ihrer Benutzer*innen für Azure-Umgebungen strukturieren. Dazu zählt, wie Sie den Zugriff in Notfallsituationen erlauben, und wie Sie alle Änderungen in Ihrem Azure-Bestand überwachen können.
Blockieren des menschlichen Zugriffs
Indem Sie den menschlichen Zugriff auf Ihre kontrollierten Umgebungen blockieren, stellen Sie sicher, dass versehentliche oder absichtlich schädliche Änderungen nicht die Überprüfungs- und automatischen Bereitstellungsprozesse Ihres Teams umgehen können. Wenn Sie den menschlichen Zugriff nicht blockieren, könnte jemand versehentlich die Kontrollen umgehen, für deren Planung und Implementierung Sie in Ihrem Repository und Ihren Pipelines so viel Zeit investiert haben.
Ohne blockierende Kontrollen ist es auch leicht möglich, dass jemand versehentlich etwas beschädigt. Nehmen wir z. B. an, ein Benutzer hat zwei Kopien des Azure-Portals geöffnet. Die eine ist für eine Testumgebung, die andere für die Produktionsumgebung. Wenn der Benutzer zwischen verschiedenen Browserregisterkarten hin- und herwechselt, kann es leicht passieren, dass er versehentlich Änderungen in einer Produktionsumgebung vornimmt, die eigentlich für eine Testumgebung vorgesehen waren.
Um den menschlichen Zugriff zu blockieren, können Sie die rollenbasierte Zugriffssteuerung (RBAC) in Azure verwenden. In RBAC erstellen Sie Rollenzuweisungen, um Folgendes zu definieren:
- Welche Benutzer, Gruppen oder Dienstprinzipale auf einen definierten Satz von Azure-Ressourcen (den Umfang) zugreifen können.
- Was diese Benutzer, Gruppen oder Dienstprinzipale ausführen können, wenn sie auf die Ressourcen zugreifen (die Rolle).
Azure RBAC bietet viele integrierte Rollentypen, einschließlich:
- Leser, der schreibgeschützten Zugriff auf die Umgebung hat.
- Mitwirkender, der Ressourcen ändern kann.
- Besitzer, der Ressourcen ändern und anderen Zugriff gewähren kann.
Es ist wichtig, den Zugriff in einem angemessenen Umfang zu gewähren. Wenn Ihr Unternehmen der empfohlenen Vorgehensweise folgt, dedizierte Azure-Abonnements für jede Umgebung zu verwenden, sollten Sie die Verwendung von Azure-Verwaltungsgruppen in Betracht ziehen, um den Umfang Ihrer Rollenzuweisungen zu vereinfachen. Wenn Ihre Organisation ein einzelnes Azure-Abonnement für alle Ihre Umgebungen verwendet, vermeiden Sie es, Benutzern Zugriff auf das gesamte Abonnement zu gewähren, da alle Ressourcen, einschließlich Ihrer kontrollierten Umgebungen, diese Berechtigung erben würden.
Tipp
Rollenzuweisungen sind ARM-Ressourcen (Azure Resource Manager). Das bedeutet, dass Sie Ihre Azure RBAC-Rollenzuweisungen im Code konfigurieren können, z. B. mithilfe von Bicep.
Wenn Sie Ihre Rollenzuweisungen planen, müssen Sie entscheiden, was für Ihr Unternehmen sinnvoll ist. Nehmen wir z. B. an, Ihr Unternehmen erstellt für jede Ihrer Umgebungen ein eigenes Abonnement. Sie können Ihren Administratoren und Entwicklern Leser-Zugriff auf Ihre kontrollierten Umgebungen gewähren. Mit dieser Rolle können sie über das Azure-Portal auf die Produktionsumgebung zugreifen, um die Konfiguration Ihrer Ressourcen zu überprüfen, Metriken und Protokolle anzuzeigen und Probleme oder Fehler zu untersuchen, ohne Änderungen an der Umgebung vorzunehmen.
Im Folgenden erfahren Sie, wie Sie Ihre Rollenzuweisungen für die Umgebungen Ihres Spielwarenunternehmens konfigurieren können, und zwar sowohl für Ihre Azure-Administratoren als auch für die Entwickler, die Ihren Code und Ihre Skripts schreiben:
| Umgebungsname | Steuerungsebene | Administratorberechtigung | Entwicklerberechtigung |
|---|---|---|---|
| Entwicklung | Kontrolliert | Leser | Leser |
| Testen | Kontrolliert | Leser | Leser |
| Staging | Kontrolliert | Leser | Leser |
| Bereitstellung | Kontrolliert | Leser | Leser |
| Demo | Unkontrolliert | Besitzer | Mitwirkender |
| Leistungstests | Unkontrolliert | Besitzer | Keine |
| Penetrationstests | Unkontrolliert | Besitzer | Keine |
| PR-Überprüfungen | Unkontrolliert | Besitzer | Besitzer |
| Sandboxes für die Entwicklung | Unkontrolliert | Besitzer | Besitzer |
Wenn Sie Ihre Rollenzuweisungen planen, stellen Sie sicher, dass Sie sie gründlich testen. Manchmal sind für Verwaltungsvorgänge Berechtigungen erforderlich, die nicht offensichtlich sind. Geben Sie Ihren Teammitgliedern die Möglichkeit, ihre tägliche Arbeit mit den von Ihnen geplanten Berechtigungen zu testen. Überprüfen Sie alle Probleme, die auftreten.
Überwachen Sie Ihre Rollenzuweisungen regelmäßig. Vergewissern Sie sich, dass Sie nicht versehentlich den falschen Personen Zugriff gewährt haben oder dass der Zugriff zu weit gefasst ist.
Datenebenenzugriff
Es gibt zwei Arten von Vorgängen in Azure:
- Vorgänge auf Steuerungsebene zum Verwalten von Ressourcen in Ihrem Abonnement.
- Datenebenenvorgänge für den Zugriff auf Features, die von einer Ressource verfügbar gemacht werden.
Sie verwenden z. B. einen Vorgang auf Steuerungsebene, um ein Speicherkonto zu erstellen. Sie verwenden einen Vorgang auf Datenebene, um eine Verbindung mit dem Speicherkonto herzustellen und auf die darin enthaltenen Daten zuzugreifen.
Wenn Sie den direkten Benutzerzugriff auf Ihre Azure-Ressourcen blockieren, sollten Sie auch bedenken, wie sich diese Einschränkung auf Vorgänge auf der Datenebene auswirkt. Beispielsweise könnte Ihr Bereitstellungsprozess den Schlüssel für ein Speicherkonto an einem Ort speichern, auf den ein*e Administrator*in zugreifen kann. Diese*r Administrator*in könnte den Schlüssel theoretisch dazu verwenden, Ihre Kontrollmechanismen zu umgehen und direkt auf die Datenebene des Speicherkontos zuzugreifen.
Immer mehr Azure-Ressourcen unterstützen die Konfiguration der Zugriffssteuerung auf der Datenebene mithilfe von Microsoft Entra ID. Diese Funktion verringert die Wahrscheinlichkeit, dass Schlüssel preisgegeben werden oder versehentlich Zugriff auf Datenebenen gewährt wird. Es empfiehlt sich, Microsoft Entra ID für den Zugriff auf Datenebenen überall dort zu verwenden, wo Sie können.
Notfallzugriff
Manchmal kommt es zu Notfällen und jemand muss schnell Zugriff zu einer Produktionsumgebung erhalten, um ein Problem zu untersuchen oder zu beheben. Es ist wichtig, dass Sie Ihre Reaktion auf solche Notfallsituationen lange vor deren Eintreten planen und üben. Sie möchten nicht mitten in einem Ausfall unvorbereitet reagieren müssen.
Ein möglicher Ansatz ist ein Notfallzugriffskonto, ein spezielles Benutzerkonto, das über höhere Berechtigungen verfügt, als Benutzer normalerweise haben. Es wird als Notfallzugriffskonto bezeichnet, da es etwas Ungewöhnliches erfordert, um Zugriff auf dessen Anmeldeinformationen zu erhalten, ähnlich wie das Einschlagen des Glases bei einem Feuermelder. Sie können Ihren Operatoren eine sichere Methode bieten, um Zugriff auf die Anmeldeinformationen für das Notfallzugriffskonto zu erhalten. Diese Operatoren können sich dann als dieses Konto anmelden, um Notfalländerungen vorzunehmen.
Die Abfolge der Schritte für die Verwendung eines Notfallzugriffskontos ist wie folgt:
- Der Benutzer versucht, eine Notfalländerung über sein normales Konto vorzunehmen, aber der Vorgang wird blockiert, da das normale Benutzerkonto nicht über ausreichende Berechtigungen verfügt.
- Der Benutzer greift auf die Anmeldeinformationen für das Notfallzugriffskonto zu und meldet sich als dieser Benutzer an.
- Der Benutzer (der als Notfallzugriffskonto fungiert) darf den Vorgang durchführen.
Die Verwendung von Notfallzugriffskonten erfordert ein hohes Maß an Disziplin. Ihr Einsatz sollte echten Notfallsituationen vorbehalten sein. Verwalten und schützen Sie die Anmeldeinformationen sorgfältig, denn das Konto verfügt über hohe Berechtigungen. Es empfiehlt sich, die Anmeldeinformationen für Notfallzugriffskonten regelmäßig zu ändern, um die Chance zu minimieren, dass sie verfügbar gemacht oder kompromittiert wurden.
Notfallzugriffskonten werden oft innerhalb eines Teams gemeinsam genutzt, sodass es schwierig ist, nachzuvollziehen, wer sie genutzt hat und was diese Benutzer vorgenommen haben. Ein alternativer Ansatz für Notfallzugriffskonten ist die Einführung des PIM-Features (Privileged Identity Management) von Microsoft Entra. Es ermöglicht es, dem eigenen Benutzerkonto vorübergehend eine höhere Berechtigungsebene zuzuweisen.
Die Reihenfolge der Schritte zur Verwendung von PIM ist wie folgt:
Der Benutzer versucht, eine Notfalländerung über sein normales Konto vorzunehmen, aber der Vorgang wird blockiert, da das normale Benutzerkonto nicht über ausreichende Berechtigungen verfügt.
Der Benutzer wendet sich an PIM und fordert eine vorübergehende Rechteerweiterung an.
Je nachdem, wie es für das Unternehmen konfiguriert ist, kann PIM eine zusätzliche Überprüfung der Benutzeridentität durchführen oder eine Genehmigung von jemandem anfordern.
Wird die Anforderung autorisiert, aktualisiert PIM vorübergehend die Berechtigungen des Benutzers.
Der Benutzer darf den Vorgang ausführen.
Nach Ablauf der definierten Zeitspanne entzieht PIM dem oder der Benutzer*in die zuvor erteilten erhöhten Berechtigungen.
Sowohl PIM als auch Azure erstellen umfassende Überwachungsprotokolle, damit Sie nachvollziehen können, wer aus welchem Grund erhöhte Berechtigungen angefordert hat. Die Protokolle verfolgen auch, was sie in Ihrer Umgebung getan haben, als die Berechtigungen erteilt wurden.
Hinweis
PIM erfordert eine Premium-Lizenz für Die Microsoft Entra ID.
Nach Beendigung des Notfalls
Nach dem Ende eines Notfalls ist es wichtig, über einen Prozess für die Rückkehr zum normalen Betrieb zu verfügen. Befolgen Sie diesen Prozess, bevor zu viel Zeit verstrichen ist, da Sie sonst Gefahr laufen, wichtige Informationen zu vergessen oder die Konfiguration in einem nicht sicheren Zustand zu belassen.
Überprüfen Sie die Azure- und PIM-Überwachungsprotokolle sorgfältig, um die Änderungen zu verstehen, die in Ihren kontrollierten Umgebungen und insbesondere in Ihrer Produktionsumgebung vorgenommen wurden.
Wichtig
Jemand, der PIM oder ein Notfallzugriffskonto verwendet, könnte die Möglichkeit haben, seinem regulären Benutzerkonto einen umfassenderen Zugriff zu gewähren, als es eigentlich besitzen sollte. Sie könnten die temporären Berechtigungen auch nutzen, um Zugriff auf die Schlüssel der Datenebene zu erhalten, die sie nach dem Widerrufen ihrer Berechtigungen weiter nutzen können.
Überprüfen Sie sorgfältig die gesamte Nutzung Ihrer Notfallsicherheitskonten oder PIM. Widerrufen oder rotieren Sie alle Schlüssel, die während des Notfalls verfügbar gemacht worden sein könnten.
Synchronisieren Sie kurz nach dem Notfall Ihre Infrastructure-as-Code-Ressourcen mit allen Änderungen neu, die während des Notfalls vorgenommen wurden. Nehmen wir z. B. an, dass ein Administrator im Rahmen der Lösung eines dringenden Problems die SKU eines Azure App Service-Plans manuell erhöht hat. Aktualisieren Sie Ihre Bereitstellungsvorlagen, um die neue SKU in die Ressourcenkonfiguration aufzunehmen. Andernfalls könnte die SKU bei der nächsten regulären Bereitstellung aus Ihrer Pipeline auf den vorherigen Wert zurückgesetzt werden und einen weiteren Ausfall verursachen.
Überwachen von Änderungen an Ihrer Azure-Umgebung
Außerdem empfiehlt es sich, die Überwachung und Protokollierung für Ihre gesamte Azure-Umgebung zu konfigurieren und auf bestimmte Ereignisse oder Bedrohungen zu überwachen.
Ziehen Sie den Einsatz eines SIEM-Tools (Security Information and Event Management) wie Microsoft Sentinel in Erwägung. Sie können dieses Tool verwenden, um Protokolle aus Ihrem Azure-Bestand und sogar aus Azure DevOps, GitHub und anderen Systemen zu sammeln und zu analysieren. Mit Sentinel können Sie unerwartete oder nicht autorisierte Änderungen an Ihren Azure-Ressourcen überwachen. Sie können auch die Überwachungsprotokolle Ihrer Pipeline importieren und Warnungen auslösen, wenn Ereignisse eintreten, z. B. wenn ein Administrator eine Branchschutzrichtlinie in Ihrem Repository ändert.