Handbuch

Just-in-Time (JIT)-Zugriff auf privilegierte Azure AD-Rollen bereitstellen, der Genehmigung und Begründung erfordert.

→Microsoft Entra Privileged Identity Management (PIM) für die Rolle konfigurieren. „Genehmigung zur Aktivierung erforderlich“ festlegen, Genehmiger angeben, „Begründung bei Aktivierung erforderlich“ aktivieren und eine maximale Aktivierungsdauer festlegen.

Warum: PIM ist der native Azure-Dienst für die JIT-Rollenerhöhung. Es reicht nicht aus, einen Benutzer einfach berechtigt zu machen; die Richtlinieneinstellungen erzwingen den Genehmigungs- und Begründungs-Workflow.

Referenz↗

MFA und ein konformes Gerät für alle Benutzer erzwingen, die auf sensible Anwendungen zugreifen, aber eine bestimmte Helpdesk-Gruppe von der Gerätekonformitätsregel ausnehmen.

→Zwei Conditional Access (CA)-Richtlinien erstellen. Richtlinie 1 zielt auf „Alle Benutzer“ ab, ausgenommen die Helpdesk-Gruppe, und erfordert MFA und ein konformes Gerät. Richtlinie 2 zielt nur auf die Helpdesk-Gruppe ab und erfordert nur MFA.

Warum: Eine einzelne Richtlinie mit einer Ausnahme würde alle Anforderungen für die ausgeschlossene Gruppe entfernen. Zwei gezielte Richtlinien stellen sicher, dass jede Gruppe die richtigen, unterschiedlichen Kontrollen erhält.

Referenz↗

Automatisch auf erkannte Identitätsrisiken reagieren: Hochrisiko-Anmeldungen blockieren und Passwort-Resets für Hochrisiko-Benutzer erzwingen.

→Zwei Microsoft Entra ID Protection-Richtlinien konfigurieren. Die „Anmelderisiko-Richtlinie“ auf „Zugriff bei hohem Risikoniveau blockieren“ setzen. Die „Benutzerrisiko-Richtlinie“ auf „Passwortänderung bei hohem Risikoniveau erforderlich“ setzen.

Warum: Das Anmelderisiko bezieht sich auf einen einzelnen Authentifizierungsversuch (Echtzeit), während das Benutzerrisiko eine kumulative Bewertung der Identität selbst ist (kompromittierte Anmeldeinformationen). Sie erfordern unterschiedliche Abhilfemaßnahmen.

Benutzern in einer hybriden Identitätsumgebung ermöglichen, ihr Cloud-Passwort zurückzusetzen und es zurück mit dem lokalen Active Directory zu synchronisieren.

→In Microsoft Entra Connect die Funktion „Passwort-Writeback“ aktivieren. In Azure AD Self-Service Password Reset (SSPR) für die Zielbenutzer aktivieren und konfigurieren.

Warum: SSPR bietet die Cloud-seitige Benutzeroberfläche für das Passwort-Reset, während Password Writeback die Komponente in Entra Connect ist, die den neuen Passwort-Hash zurück zum lokalen AD synchronisiert.

Regelmäßig alle Gastbenutzerzugriffe überprüfen und Gäste, die nicht mehr genehmigt oder inaktiv sind, automatisch entfernen.

→Eine Zugriffsüberprüfung in Microsoft Entra ID Governance erstellen. Gastbenutzer in allen Gruppen ansprechen, einen wiederkehrenden Zeitplan festlegen (z. B. vierteljährlich) und „Ergebnisse automatisch auf Ressource anwenden“ aktivieren. Optional inaktive Benutzer überprüfen.

Warum: Zugriffsüberprüfungen sind das dedizierte Governance-Tool für die periodische Rezertifizierung des Zugriffs. Die Funktion „Ergebnisse automatisch anwenden“ ist entscheidend, um den Kreis zu schließen und die Entfernung zu automatisieren.

Externen Partnern eine Self-Service-Möglichkeit bieten, ein Bündel von Zugriffen (Gruppen, Apps, SharePoint-Websites) anzufordern, das nach 90 Tagen automatisch abläuft.

→Microsoft Entra Entitlement Management verwenden. Eine Connected Organization für den Partner erstellen. Ein Access Package erstellen, das die Ressourcen enthält. Eine Richtlinie für das Paket definieren, die Benutzern der verbundenen Organisation erlaubt, es anzufordern, mit einem Ablauf nach 90 Tagen.

Warum: Entitlement Management ist für die Verwaltung des Zugriffs in großem Umfang konzipiert, insbesondere für externe Benutzer. Es bündelt Ressourcen und automatisiert den gesamten Zugriffslebenszyklus von Anfrage und Genehmigung bis hin zu Ablauf und Entfernung.

Eine hochsichere Anwendung erfordert, dass Benutzer sich mit einer Methode authentifizieren, die resistent gegen Phishing- und Man-in-the-Middle-Angriffe ist.

→Authentifizierungsmethoden wie FIDO2-Sicherheitsschlüssel oder Windows Hello for Business erzwingen. Diese Methoden verwenden Public-Key-Kryptographie und sind an das Gerät gebunden, wodurch Anmeldeinformationen-Diebstahl verhindert wird.

Warum: Methoden wie SMS, Sprachanrufe oder einfache Push-Benachrichtigungen sind anfällig für Phishing. FIDO2 und WHfB verwenden kryptografische Herausforderungen, die an den Ursprung der Anfrage gebunden sind, wodurch sie resistent gegen Phishing sind.

Ein auf einer VM laufender Hintergrunddienst muss alle Benutzerprofile aus Microsoft Graph ohne Benutzerinteraktion lesen.

→Die Anwendung in Microsoft Entra ID registrieren. Unter API-Berechtigungen Microsoft Graph „Anwendungs“-Berechtigungen (nicht „Delegiert“) für `User.Read.All` gewähren. Ein Administrator muss die Administratorzustimmung erteilen.

Warum: Anwendungsberechtigungen ermöglichen der App, als sie selbst zu agieren, unter Verwendung ihrer eigenen Identität (Client-ID/Secret oder Zertifikat). Delegierte Berechtigungen erfordern einen angemeldeten Benutzerkontext, der in einer nicht-interaktiven Daemon-App nicht verfügbar ist.

Einem Pod in einem AKS-Cluster ermöglichen, sicher auf Azure Key Vault zuzugreifen, ohne gespeicherte Anmeldeinformationen wie Client-Secrets oder Zertifikate zu verwenden.

→Azure AD Workload Identity verwenden. Eine benutzerseitig zugewiesene verwaltete Identität erstellen, eine föderierte Identitätsanmeldeinformation zwischen dem K8s-Dienstkonto und der verwalteten Identität einrichten und der verwalteten Identität Zugriff auf Key Vault gewähren.

Warum: Workload Identity verwendet OIDC-Föderation, um ein Kubernetes-Token gegen ein Azure AD-Token auszutauschen, wodurch die Notwendigkeit, Secrets im Cluster zu speichern, zu verwalten oder zu rotieren, vollständig entfällt.

Referenz↗

Ein Azure Key Vault sichern, um nur den Zugriff von bestimmten VNets zu erlauben, alle Operationen zu protokollieren und vor versehentlichem Löschen kritischer Schlüssel zu schützen.

→Die Key Vault-Firewall so konfigurieren, dass der Zugriff von „Privater Endpunkt und ausgewählte Netzwerke“ erlaubt ist. Diagnoselogging an einen Log Analytics-Arbeitsbereich aktivieren. Sowohl Soft Delete als auch Purge Protection aktivieren.

Warum: Soft Delete ermöglicht die Wiederherstellung nach versehentlichem Löschen, aber Purge Protection verhindert, dass selbst ein privilegierter Benutzer den Tresor oder dessen Inhalt während der Aufbewahrungsfrist dauerhaft löscht. Diese Kombination ist entscheidend für den Schutz von TDE-Schlüsseln.

Ein Azure App Service muss sich bei einer Azure SQL-Datenbank authentifizieren, um Daten abzurufen, ohne Verbindungszeichenfolgen-Passwörter in der Konfiguration zu speichern.

→Eine systemseitig zugewiesene verwaltete Identität im App Service aktivieren. In Azure SQL einen enthaltenen Benutzer erstellen, der dem Namen der verwalteten Identität des App Service zugeordnet ist, und ihm die erforderlichen Datenbankrollen (z. B. db_datareader) gewähren.

Warum: Managed Identity stellt eine Identität für die Azure-Ressource selbst in Azure AD bereit. Azure übernimmt die automatische Erstellung und Rotation von Anmeldeinformationen, wodurch gespeicherte Secrets eliminiert werden, was eine wichtige bewährte Sicherheitspraxis ist.

Verwaltete Azure VM-Datenträger im Ruhezustand mit einem Schlüssel verschlüsseln, den Ihre Organisation im Azure Key Vault kontrolliert.

→Eine Disk Encryption Set-Ressource erstellen. Diese so konfigurieren, dass sie einen kundenverwalteten Schlüssel (CMK) aus Ihrem Azure Key Vault verwendet. Das Disk Encryption Set den verwalteten Datenträgern der VM zuweisen.

Warum: Dies ist Server-Side Encryption (SSE) mit CMK, das Daten in der Speicherinfrastruktur verschlüsselt. Es ist einfacher als Azure Disk Encryption (ADE), das BitLocker/dm-crypt verwendet, um Daten innerhalb des Gast-OS zu verschlüsseln, und wird im Allgemeinen für OS- und Daten-Datenträger zusammen verwendet.

Sicherstellen, dass in Azure Container Registry (ACR) gespeicherte Container-Images auf Schwachstellen gescannt werden, bevor sie bereitgestellt werden.

→Microsoft Defender for Containers aktivieren. Dies scannt Bilder in ACR automatisch, wenn sie gepusht, wenn sie gepullt werden, und fortlaufend nach neu entdeckten Schwachstellen.

Warum: Diese „Shift-Left“-Sicherheitspraxis identifiziert Schwachstellen frühzeitig in der CI/CD-Pipeline. Defender for Containers bietet diese Scan-Funktion nativ innerhalb des Azure-Ökosystems.

Potenzielle SQL-Injection-Angriffe und anomale Zugriffsmuster auf einer Azure SQL-Datenbank erkennen und Warnmeldungen erhalten.

→Microsoft Defender for SQL auf dem logischen SQL-Server aktivieren. Dies bietet erweiterten Bedrohungsschutz und Schwachstellenbewertung.

Warum: Defender for SQL ist der dedizierte Workload-Schutzplan, der Verhaltensanalysen und maschinelles Lernen verwendet, um Bedrohungen wie SQL-Injection, Brute-Force-Angriffe und ungewöhnlichen Datenzugriff zu erkennen, die für netzwerkbasierte Tools nicht sichtbar sind.

Ein Speicherkonto auf ein bestimmtes VNet beschränken, aber dennoch vertrauenswürdigen Microsoft-Diensten wie Azure Backup den Zugriff erlauben.

→In den Netzwerkeinstellungen des Speicherkontos „Ausgewählte virtuelle Netzwerke und IP-Adressen aktiviert“ auswählen. Das erforderliche VNet/Subnetz hinzufügen. Anschließend das Kontrollkästchen „Vertrauenswürdigen Microsoft-Diensten den Zugriff auf dieses Speicherkonto erlauben“ aktivieren.

Warum: Die Ausnahme für vertrauenswürdige Dienste schafft einen sicheren Pfad für bestimmte Microsoft-Dienste, um die VNet-Firewall-Regeln zu umgehen. Ohne sie würden Dienste, die im Auftrag des Benutzers agieren (wie Backup oder Portal), blockiert.

Spezifische sensible Datenfelder (z. B. Kreditkartennummern) in einer Azure SQL-Datenbank schützen, selbst vor privilegierten Datenbankadministratoren (DBAs).

→Always Encrypted verwenden. Der Treiber der Clientanwendung verschlüsselt die Daten transparent, bevor sie an die Datenbank gesendet werden, und die Verschlüsselungsschlüssel werden dem Datenbank-Engine niemals preisgegeben.

Warum: Transparent Data Encryption (TDE) verschlüsselt die gesamte Datenbank im Ruhezustand (auf der Festplatte), aber ein DBA mit Zugriff kann die Daten immer noch sehen. Always Encrypted bietet clientseitige Verschlüsselung, die diejenigen, die die Daten verwalten (DBAs), von denen trennt, die sie sehen können.

Hochsensible Daten auf einer Azure VM verarbeiten und sicherstellen, dass sie auch im Speicher vor dem Hypervisor und Cloud-Betreibern verschlüsselt und geschützt bleiben.

→Eine Azure Confidential VM bereitstellen. Diese VMs verwenden hardwarebasierte Trusted Execution Environments (TEEs) wie AMD SEV-SNP, um einen isolierten, verschlüsselten Speicherbereich zu erstellen.

Warum: Standard-VM-Verschlüsselung (wie ADE oder SSE) schützt Daten im Ruhezustand. Confidential Computing ist die einzige Technologie, die Daten *während der Nutzung* im Speicher schützt und das höchste Maß an Datenprivatsphäre und Isolation in der Cloud bietet.

Ein App Service muss ein Secret aus Key Vault als Anwendungseinstellung verwenden, ohne den Anwendungscode zur Nutzung des Key Vault SDK zu ändern.

→Verwaltete Identität im App Service aktivieren und ihr „Get“-Berechtigungen für Secrets in Key Vault gewähren. In der App Service-Konfiguration eine Anwendungseinstellung mit dem Wert im Format einer Key Vault-Referenz erstellen: `@Microsoft.KeyVault(SecretUri=...)`.

Warum: Diese Funktion ermöglicht der App Service-Plattform, den Secret-Wert zur Laufzeit unter Verwendung der verwalteten Identität aufzulösen. Der Anwendungscode liest einfach eine Standard-Umgebungsvariable, wodurch die Key Vault-Interaktion abstrahiert wird.

Compliance-bezogene Daten in Azure Blob Storage in einem WORM (Write-Once, Read-Many)-Zustand für eine Aufbewahrungsfrist von 7 Jahren speichern.

→Auf dem Speichercontainer eine Unveränderlichkeitsrichtlinie konfigurieren. Eine zeitbasierte Aufbewahrungsrichtlinie auf 7 Jahre einstellen und die Richtlinie sperren. Sobald gesperrt, können die Daten von niemandem mehr geändert oder gelöscht werden, bis die Aufbewahrungsfrist abläuft.

Warum: Diese Funktion wurde speziell entwickelt, um regulatorische Compliance-Anforderungen (z. B. SEC 17a-4) zu erfüllen. Das Sperren der Richtlinie ist der entscheidende Schritt, der sie wirklich unveränderlich macht.

In einer Multi-Tenant-Anwendung, die eine einzige Azure SQL-Datenbank verwendet, sicherstellen, dass Benutzer eines Tenants nur Daten sehen können, die ihrem eigenen Tenant gehören.

→Row-Level Security (RLS) implementieren. Eine Sicherheitsrichtlinie mit einer Prädikatfunktion erstellen, die Zeilen basierend auf der Tenant-ID des Benutzers filtert, die im Sitzungskontext oder in einer Benutzer-Lookup-Tabelle gespeichert ist.

Warum: RLS erzwingt Zugriffslogik direkt im Datenbank-Engine. Dies ist sicherer und zuverlässiger als die Implementierung von Filterung in der Anwendungsebene, da es nicht umgangen werden kann und für den Anwendungscode transparent ist.

Generation 2 VMs vor Bootkits und Rootkits schützen, indem die Integrität der gesamten Bootkette von UEFI bis zum OS-Kernel sichergestellt wird.

→Die VM mit aktiviertem Trusted Launch bereitstellen. Dies aktiviert Secure Boot, das die Signatur aller Boot-Komponenten validiert, und ein virtuelles Trusted Platform Module (vTPM) für gemessenes Booten und Attestierung.

Warum: Trusted Launch bekämpft hochentwickelte, Low-Level-Malware, die traditionelle Sicherheitskontrollen auf OS-Ebene untergraben kann. Es etabliert eine Hardware-Vertrauensbasis für die VM.

Datenverkehr zwischen Anwendungsebenen (Web, Anwendung, Daten), die in separaten Subnetzen gehostet werden, isolieren.

→Eine dedizierte Netzwerksicherheitsgruppe (NSG) für jedes Subnetz erstellen. In jeder NSG eingehende Regeln erstellen, die nur Datenverkehr vom Quell-IP-Bereich der vorhergehenden Ebene auf dem erforderlichen Port zulassen. (z. B. App-Ebene NSG erlaubt TCP/8080 vom Web-Ebene Subnetz).

Warum: Die Anwendung einer eindeutigen NSG mit geringsten Privilegien auf jedes Subnetz bietet Defense-in-Depth und granulare Kontrolle über den Ost-West-Datenverkehr, was sicherer ist als eine einzelne, komplexe NSG für das VNet.

In einer Hub-Spoke-Topologie allen Datenverkehr zwischen Spoke-VNets erzwingen, von einer NVA oder Azure Firewall im Hub inspiziert zu werden.

→Auf jedem Spoke-Subnetz eine benutzerdefinierte Route (UDR) für die Adressbereiche der anderen Spokes erstellen, wobei der Next-Hop-Typ auf „VirtualAppliance“ und die IP der NVA/Firewall gesetzt wird. IP-Weiterleitung auf der NIC der NVA aktivieren.

Warum: Standardmäßig erlaubt VNet-Peering den Spokes, direkt zu kommunizieren. UDRs überschreiben dieses Standard-Routingverhalten und zwingen den Datenverkehr zum zentralen Inspektionspunkt.

Einem PaaS-Dienst (z. B. Azure SQL, Storage) eine private IP-Adresse innerhalb Ihres VNet bereitstellen und sicherstellen, dass der Datenverkehr niemals das öffentliche Internet durchquert.

→Einen Private Endpoint für den PaaS-Dienst in Ihrem VNet erstellen. Entscheidend ist, in den Netzwerkeinstellungen des PaaS-Dienstes den öffentlichen Netzwerkzugriff zu deaktivieren, um den öffentlichen Endpunkt zu blockieren.

Warum: Ein Private Endpoint bringt den Dienst mit einer privaten IP *in* Ihr VNet. Ein Service Endpoint optimiert lediglich die Route über das Azure-Backbone zu einer öffentlichen IP. Das Deaktivieren des öffentlichen Zugriffs ist erforderlich, um eine rein private Kommunikation zu erzwingen.

Ausgehenden Datenverkehr von VMs zu einem dynamischen Satz von Microsoft-Dienstendpunkten, wie Windows Update, zulassen, ohne IP-Listen manuell zu pflegen.

→In Azure Firewall eine Anwendungsregelsammlung erstellen. Eine Regel hinzufügen, bei der der Ziel-FQDN-Typ auf „FQDN Tag“ gesetzt und der Tag „WindowsUpdate“ ausgewählt ist.

Warum: FQDN Tags sind kuratierte Sammlungen von FQDNs, die Microsoft verwaltet. Dies ist der richtige Weg, um den Zugriff auf PaaS-Dienste zu ermöglichen, deren zugrunde liegende IPs sich häufig ändern. Service Tags sind für IP-basierte Regeln.

Eine Web Application Firewall (WAF) blockiert legitimen Datenverkehr zu Ihrer Anwendung aufgrund eines False Positives in einer verwalteten Regel (z. B. SQL-Injection).

→In der WAF-Richtlinie die WAF im Präventionsmodus belassen. Die verwaltete Regel finden, die den Datenverkehr blockiert, und eine Ausnahme für den spezifischen Anforderungsheader, Cookie oder Body-Parameter konfigurieren, der den False Positive verursacht.

Warum: Ausnahmen sind die präziseste Methode zur Behandlung von False Positives. Sie ermöglichen es, den Schutz der Regel für den gesamten anderen Datenverkehr aufrechtzuerhalten, während eine spezifische Ausnahme gemacht wird, was sicherer ist als die gesamte Regel zu deaktivieren.

Sicheren RDP/SSH-Zugriff auf Azure VMs bereitstellen, ohne Verwaltungsports dem Internet auszusetzen oder öffentliche IPs auf den VMs zu benötigen.

→Azure Bastion (Standard SKU für erweiterte Funktionen) in einem dedizierten Subnetz im VNet bereitstellen. VMs über das Azure-Portal zugreifen, das sich über den Bastion-Dienst verbindet.

Warum: Bastion fungiert als sichere Jump Box, die die RDP/SSH-Verbindung vermittelt. Die einzige öffentliche IP befindet sich auf dem Bastion-Dienst selbst, der gehärtet und von Microsoft verwaltet wird, wodurch die Angriffsfläche Ihrer VMs drastisch reduziert wird.

Entwicklern zeitlich begrenzten, überprüften Zugriff auf Verwaltungsports (RDP/SSH) auf Entwicklungs-VMs ermöglichen.

→Microsoft Defender for Cloud aktivieren und Just-in-Time (JIT) VM-Zugriff für die VMs konfigurieren. Benutzer fordern den Zugriff über Defender for Cloud an, das dynamisch NSG-Regeln ändert, um den Zugriff für eine begrenzte Zeit von einer bestimmten IP aus zu ermöglichen.

Warum: JIT ist eine Kernfunktion von Defender for Cloud, die die Netzwerkhaltung von VMs durch standardmäßig geschlossene Verwaltungsports härtet und diese nur bei Bedarf öffnet.

Sicherheits-Best Practices, wie das Verhindern privilegierter Container, auf einem Azure Kubernetes Service (AKS)-Cluster zum Zeitpunkt der Bereitstellung erzwingen.

→Das Azure Policy-Add-on für AKS aktivieren. Die integrierte Richtlinieninitiative mit dem Namen „Kubernetes cluster pod security restricted standards for Linux-based workloads“ zuweisen.

Warum: Dies nutzt Azure Policy als zentralisierten, skalierbaren Admission Controller für Kubernetes, der Sicherheits- und Compliance-Leitplanken durchsetzt, bevor Workloads überhaupt im Cluster erstellt werden.

Den gesamten internetgebundenen Datenverkehr von einem Azure VNet zurück zu einer lokalen Sicherheitsappliance leiten, um ihn zu inspizieren, bevor er das Internet erreicht.

→Ein Site-to-Site VPN oder ExpressRoute konfigurieren. Eine benutzerdefinierte Route (UDR) für das Adresspräfix 0.0.0.0/0 erstellen und den nächsten Hop auf das Virtual Network Gateway setzen.

Warum: Dieses Muster, bekannt als erzwungenes Tunneling, überschreibt die Standardroute von Azure ins Internet und zwingt den gesamten ausgehenden Datenverkehr über das Gateway zum lokalen Netzwerk, wodurch sichergestellt wird, dass keine VM die Unternehmenssicherheitskontrollen umgehen kann.

Ausgehenden TLS-verschlüsselten Datenverkehr von VMs auf Bedrohungen mit Azure Firewall inspizieren.

→Azure Firewall Premium bereitstellen. TLS-Inspektion und Intrusion Detection (IDPS) aktivieren. Ein untergeordnetes CA-Zertifikat auf der Firewall konfigurieren und dessen öffentlichen Schlüssel als vertrauenswürdige Stamm-CA auf den Client-VMs bereitstellen.

Warum: Um verschlüsselten Datenverkehr zu inspizieren, muss die Firewall einen Man-in-the-Middle-Vorgang durchführen. Dies erfordert die Premium SKU, IDPS für die Bedrohungserkennung und eine geeignete Zertifikatinfrastruktur, um TLS-Fehler auf Client-Maschinen zu vermeiden.

Alle öffentlich zugänglichen Anwendungen über mehrere VNets und Abonnements hinweg kostengünstig vor volumetrischen DDoS-Angriffen schützen.

→Einen einzigen Azure DDoS Protection Plan erstellen. Diesen einen Plan mit allen virtuellen Netzwerken verknüpfen, die öffentliche IP-Adressen enthalten, die Schutz benötigen.

Warum: Ein einziger DDoS Protection Plan kann bis zu 100 VNets abdecken, und Sie zahlen eine feste monatliche Gebühr für den Plan, nicht pro VNet oder pro IP. Dieses zentralisierte Modell ist viel kostengünstiger als die Bereitstellung mehrerer Pläne oder die Verwendung der Pro-IP-Schutz-SKU.

Wenn ein Incident mit hoher Schwere in Microsoft Sentinel erstellt wird, das beteiligte Benutzerkonto in Azure AD automatisch deaktivieren und das Sicherheitsteam in Teams benachrichtigen.

→Eine Automatisierungsregel erstellen, die bei der Erstellung eines Incidents mit hoher Schwere ausgelöst wird. Die Regel sollte ein Playbook (Logic App) aufrufen. Das Playbook verwendet den Azure AD-Konnektor, um den Benutzer zu deaktivieren, und den Teams-Konnektor, um eine Nachricht zu posten.

Warum: Dies demonstriert das SOAR (Security Orchestration, Automation, and Response)-Muster. Die Automatisierungsregel ist die Trigger-/Bedingungs-Engine, und das Playbook ist die Aktions-/Workflow-Engine.

Referenz↗

Eine konsistente Reihe von Sicherheitsrichtlinien anwenden und Defender for Cloud-Pläne über eine große Anzahl von Azure-Abonnements hinweg aktivieren.

→Alle Abonnements unter einer Management Group organisieren. Die Azure Security Benchmark-Richtlinieninitiative zuweisen und die erforderlichen Defender for Cloud-Pläne auf Ebene der Management Group aktivieren.

Warum: Management Groups sind das primäre Werkzeug für die Governance auf Unternehmensebene. Auf dieser Ebene angewandte Richtlinien und Einstellungen werden von allen untergeordneten Abonnements geerbt, was Konsistenz gewährleistet und den Verwaltungsaufwand reduziert.

Eine benutzerdefinierte Erkennung in Sentinel für einen Benutzer erstellen, der sich zum ersten Mal aus einem neuen Land anmeldet.

→Eine geplante Abfrageanalyse-Regel erstellen. Eine KQL-Abfrage verwenden, die aktuelle `SigninLogs` mit einer zusammenfassenden Historie vergangener `SigninLogs` verbindet, um noch nie zuvor gesehene UserPrincipalName/Länder-Kombinationen zu identifizieren.

Warum: Geplante Abfrageregeln mit KQL sind die Grundlage der benutzerdefinierten Bedrohungserkennung in Sentinel und ermöglichen komplexe, zustandsbehaftete Logik, die über einfaches Event-Matching hinausgeht.

Sicherheitsprotokolle in Sentinel für 2 Jahre zur Compliance aufbewahren, aber nur die letzten 90 Tage für schnelle, interaktive Abfragen verfügbar halten, um Kosten zu verwalten.

→Im Log Analytics-Arbeitsbereich die „Interaktive Aufbewahrung“ auf 90 Tage festlegen. Die „Gesamtaufbewahrung“ (Archiv) auf 730 Tage (2 Jahre) festlegen. Bei Bedarf Aufbewahrungsrichtlinien pro Tabelle konfigurieren.

Warum: Dieser gestaffelte Ansatz gleicht Kosten und Fähigkeiten aus. Die interaktive Ebene ist teuer, aber schnell. Die Archivebene ist sehr kostengünstig für die langfristige Speicherung. Archivierte Daten können weiterhin über asynchrone Suchaufträge abgefragt oder vorübergehend wiederhergestellt werden.

Während einer Incident-Untersuchung müssen Sie schnell die Beziehungen zwischen einem kompromittierten Benutzer, der IP, von der er sich angemeldet hat, und den Ressourcen, auf die er zugegriffen hat, visualisieren.

→Von der Incident-Seite in Microsoft Sentinel aus den Untersuchungsdiagramm öffnen. Das Diagramm verwenden, um Entitäten und deren Verbindungen über verschiedene Warnungen und Protokollquellen hinweg visuell zu erkunden.

Warum: Das Untersuchungsdiagramm ist ein leistungsstarkes Visualisierungstool, das die Angriffsgeschichte abbildet und es so viel einfacher macht, den Umfang und den Zeitrahmen eines Incidents zu verstehen, als durch manuelle Korrelation von Ereignissen in Protokollabfragen.

Einen Angreifer erkennen, der ein Benutzerkonto kompromittiert hat und nun versucht, auf ungewöhnliche Ressourcen oder Hosts innerhalb des Netzwerks zuzugreifen.

→Sicherstellen, dass User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel aktiviert ist und dass relevante Datenquellen (Azure AD-Protokolle, Defender for Endpoint/Sicherheitsereignisse) verbunden sind. UEBA auf Anomalieerkennungen im Zusammenhang mit lateralen Bewegungen überwachen.

Warum: UEBA erstellt eine Basislinie für das normale Verhalten jedes Benutzers und jeder Entität. Es ist hervorragend darin, Abweichungen zu erkennen, die auf laterale Bewegungen hindeuten, wie z. B. ein Benutzer, der zum ersten Mal auf einen Server zugreift oder ungewöhnliche Protokolle verwendet, die mit statischen Regeln schwer zu erkennen sind.

Die Ingestionskosten von Microsoft Sentinel für umfangreiche, detaillierte Protokolle reduzieren, die für die Compliance benötigt werden, aber nicht für Echtzeitanalysen.

→Den Tabellenplan für diese Protokolle auf „Basic Logs“ konfigurieren. Zusätzlich Data Collection Rules (DCRs) mit XPath-Abfragen oder anderen Transformationen verwenden, um rauschige, minderwertige Ereignisse vor der Ingestion herauszufiltern.

Warum: Basic Logs bieten erheblich geringere Ingestionskosten im Austausch für eingeschränkte Abfragefunktionen und kürzere Aufbewahrung. Das Filtern an der Quelle mit DCRs ist der effektivste Weg, das Volumen zu reduzieren, indem verhindert wird, dass unerwünschte Daten überhaupt den Arbeitsbereich erreichen.

Eine Sicherheitseinstellung, wie das Aktivieren von „Sichere Übertragung erforderlich“ auf allen bestehenden und neuen Azure-Speicherkonten, automatisch erzwingen.

→Eine Azure Policy mit dem `DeployIfNotExists`- oder `Modify`-Effekt zuweisen. Für bestehende nicht konforme Ressourcen eine Korrekturaufgabe aus dem Richtlinienkonformitäts-Blade erstellen, um die Änderung anzuwenden.

Warum: Audit- und Deny-Richtlinien melden oder blockieren nur die Nichteinhaltung. `DeployIfNotExists` und `Modify` mit Korrekturaufgaben beheben Fehlkonfigurationen aktiv, wodurch Richtlinien ein mächtiges Werkzeug für automatisierte Governance und Sicherheits-Härtung sind.

Laufzeitbedrohungen in einem AKS-Cluster erkennen, wie verdächtige Prozessausführung oder ein Container, der sich mit einer bekannten bösartigen IP verbindet.

→Microsoft Defender for Containers aktivieren. Dies stellt ein DaemonSet (Defender-Agent) auf jedem Knoten im Cluster bereit, das Sicherheitssignale vom Host und den Containern sammelt, um Echtzeit-Bedrohungserkennung zu ermöglichen.

Warum: Während ACR-Scannen „Shift-Left“-Sicherheit bietet, ist der Laufzeitschutz entscheidend für die Erkennung von Bedrohungen, die nach der Bereitstellung auftreten. Defender for Containers bietet diese Sichtbarkeit auf Host- und Workload-Ebene innerhalb des Clusters.