Im Rahmen des Security Engineering wird eine Anforderung an eine Workload in eine Sicherheitsmaßnahme (Control) überführt, die getestet, überwacht und sicher entfernt werden kann. In Azure erstreckt sich dieser Prozess über den Microsoft Entra-Mandanten, den Azure Resource Manager innerhalb eines Abonnements und die Datenebene (Data Plane) der jeweiligen Dienste; daher kann eine scheinbar korrekte Einstellung unter Umständen den falschen Bereich schützen.
Wir verwenden eine abgegrenzte Entwicklungs-Workload in der fiktiven Ressourcengruppe rg-orders-dev. Ziel ist es, die Entscheidungen, Nachweise (Evidence) und Grenzen aufzuzeigen, die ein Cloud-Sicherheitsingenieur festlegen muss, bevor eine Konfiguration als Sicherheitsmaßnahme betrachtet werden kann.
Beginnen Sie mit einer Anforderung, die mit einem Asset und einer Bedrohung verknüpft ist. Beispiel: Eine API zur Auftragsabwicklung muss ein Geheimnis (Secret) abrufen, ohne dieses über das öffentliche Internet preiszugeben. Eine Sicherheitsmaßnahme (Control) ist der konfigurierte Mechanismus zur Erfüllung dieser Anforderung, während ein Nachweis (Evidence) ein beobachtbarer Datensatz ist, der eine spezifische Aussage über die Konfiguration oder Aktivität stützt.
Unser Workflow ist konsistent. Wir identifizieren das Asset, die Datengrenze, die Identität und die Bedrohung; wählen die kleinste geeignete Sicherheitsmaßnahme aus; definieren das erwartete Fehlerverhalten für den Fall, dass der Zugriff verweigert wird oder der Datenverkehr einen unbeabsichtigten Pfad nimmt; und verifizieren anschließend das gewünschte Ergebnis anhand von Konfigurations- und Laufzeitnachweisen. Durch Bereinigungsmaßnahmen werden temporäre Berechtigungen, Testgeheimnisse oder Diagnoseeinstellungen entfernt, sobald sie nicht mehr benötigt werden, um zu verhindern, dass Testartefakte zu dauerhaften Sicherheitsrisiken werden.
Konfigurationsnachweise und Laufzeitnachweise beantworten unterschiedliche Fragen. Eine Rollenzuweisung oder die Konfiguration eines privaten Endpunkts belegt den beabsichtigten Zustand der Steuerungsebene (Control Plane). Ein Audit-Ereignis im Key Vault, ein Diagnoseprotokoll des Speichers oder ein Anwendungsfehler dokumentieren einen beobachteten Vorgang auf der Datenebene innerhalb eines bestimmten Zeitfensters. Keiner dieser Nachweise für sich allein belegt, dass jeder Pfad sicher ist oder dass ein Vorfall keine andere Ursache hat.
Empfehlungen decken Sicherheitslücken auf, doch die Durchsetzung muss über eine „Deny“-Richtlinie (Verweigerungsrichtlinie) oder die Sicherheitsmaßnahme selbst erfolgen.
Microsoft sichert die zugrunde liegende physische Azure-Infrastruktur ab, während der Kunde für Workload-Daten, das Anwendungsverhalten, Identitäten und Zugriffsentscheidungen verantwortlich bleibt. Diese Grenze der gemeinsamen Verantwortung bedeutet nicht, dass ein von der Plattform verwalteter Dienst keinerlei Sicherheitsmaßnahmen seitens des Kunden erfordert. Vielmehr muss ermittelt werden, welche Partei für die jeweilige Ebene zuständig ist, bevor Nachweise erbracht oder Abhilfemaßnahmen ergriffen werden.
Das Microsoft Entra-Verzeichnis authentifiziert Benutzer, Anwendungen und verwaltete Identitäten. Azure Resource Manager (häufig als ARM bezeichnet) ist die Steuerungsebene (Control Plane) von Azure für das Erstellen und Konfigurieren von Ressourcen in einem Abonnement oder einer Ressourcengruppe. Azure RBAC-Rollenzuweisungen in diesen Bereichen autorisieren Aktionen auf der Steuerungsebene, wie etwa das Ändern der Netzwerkkonfiguration eines Speicherkontos.
Die Datenebene (Data Plane) eines Dienstes ist die dienstspezifische Schnittstelle, über die geschützte Daten gelesen, geschrieben oder verwendet werden. Der Abruf von Geheimnissen aus einem Key Vault und der Zugriff auf Blob-Daten erfolgen auf den jeweiligen Datenebenen; dort gelten Autorisierungs- und Netzwerkregeln für die Datenebene unabhängig von der ARM-Autorisierung. Ein Benutzer mit der Rolle „Mitwirkender“ (Contributor), der einen Tresor konfigurieren kann, ist dadurch nicht automatisch berechtigt, dessen Geheimnisse zu lesen.
Eine bewährte Regel besagt, dass Sicherheitsprinzipal, Aktion, Bereich (Scope) und Ebene benannt werden müssen, bevor beurteilt wird, ob ein Zugriff erfolgreich sein sollte.
Unser fiktiver Workload ist app-orders-api, eine Azure App Service-Anwendung in der Ressourcengruppe rg-orders-dev innerhalb eines fiktiven Abonnements <subscription-id>. Sie wird in einer ausgewählten Azure-Region ausgeführt und nutzt vnet-orders-dev für die Integration in ein virtuelles Netzwerk (für ausgehenden Datenverkehr). Die Anwendung benötigt Bestelldaten aus stordersdev und ein Geheimnis aus kv-orders-dev, während law-sec-01 als Log Analytics-Arbeitsbereich für Microsoft Sentinel dient.
Das virtuelle Netzwerk bildet die Netzwerkgrenze der Anwendung, ist jedoch nicht zwangsläufig der Standort jeder einzelnen Azure-Dienstressource. stordersdev und kv-orders-dev bleiben Azure-Plattformdienste außerhalb von vnet-orders-dev; Private Endpoints stellen private Netzwerkschnittstellen für diese Dienste im virtuellen Netzwerk bereit. Private DNS-Konfigurationen und die Netzwerkeinstellungen der Dienste müssen ausgehende API-Anfragen an diese Endpoint-Adressen leiten, anstatt an einen öffentlichen Endpunkt.
Die verwaltete Identität der App benötigt später separate Berechtigungen auf der Datenebene für die geplanten Aktionen mit Key Vault und Storage. Sentinel wird auf law-sec-01 ausgeführt; dort legen Connectors und Diagnoseeinstellungen fest, welche Datensätze zur Analyse erfasst werden. Ein Arbeitsbereich kann Untersuchungen nur für Daten unterstützen, die tatsächlich in ihm gesammelt wurden.
Verfolgen Sie die Workload-Grenze von der API bis zu ihren privaten Endpunkten und dem Überwachungsarbeitsbereich.