Alert-Katalog¶
Worauf die Plattform alarmiert, nach Severity und nach Ressourcenbereich. Nutze ihn, um zu wissen, was du im Alert-Kanal erwarten kannst, und um zu entscheiden, welche Alerts ein Runbook brauchen.
Referenz, keine maßgebliche Quelle
Dieser Katalog ist aus der Alerting-Dokumentation der Plattform verdichtet. Severities und Schwellenwerte sind
Defaults der Alert-Definitionen und können sich zwischen Versionen ändern. Maßgeblich sind die Definitionen im Code-Repository
(infra/deploy/foundation/policies/policy_definitions/alerts/) und die Policy-Compliance-Ansicht im Azure portal.
Wie die Alerts deployt werden, steht unter So funktioniert Alerting.
Das Alert-Design folgt den Azure Monitor Baseline Alerts (AMBA). Die Plattform ergänzt Activity-Log-Alerts für Änderungen an sicherheitsrelevanten Ressourcen.
Nach Severity (hub)¶
Die hub-subscriptions (management, connectivity, identity). Severity 0 bis 2 gehen an die Action Group, Severity 3 und 4 werden nur protokolliert (Severity).
Severity 0: kritisch¶
Sofortige Reaktion. Die Reaktionszeit findest du in deinem Service Level.
| Alert | Ressource | Bedingung |
|---|---|---|
| Firewall-Health | Azure Firewall | Health unter 90 % |
| Durchschnittliche Bandbreite des VPN Gateways | VPN Gateway | Bandbreite unter 1 (Verbindungsproblem) |
Severity 1: Fehler¶
Hohe Priorität. Deutliche Beeinträchtigung.
| Alert | Ressource | Bedingung |
|---|---|---|
| Verfügbarkeit des Storage Accounts | Storage Account | Verfügbarkeit unter 90 % |
| Public IP unter DDoS-Angriff | Public IP | Angriff erkannt |
| VIP-Verfügbarkeit der Public IP | Public IP | VIP-Verfügbarkeit unter 1 |
| Virtuelles Netzwerk unter DDoS-Angriff | Virtuelles Netzwerk | Angriff erkannt |
| CPU-Auslastung von ExpressRoute | ExpressRoute Gateway | CPU über 80 % |
| Auslastung der SNAT-Ports | Azure Firewall | SNAT-Ports über 80 %, Gefahr erschöpfter Verbindungen |
Severity 2: Warnung¶
Schwellenwerte für Kapazität und Performance.
| Alert | Ressource | Bedingung |
|---|---|---|
| Jobs insgesamt im Automation Account | Automation Account | Mehr als 20 Jobs |
| Private-Link-Auslastung | Private Link (Kapazität der private DNS zone) | Kapazität bei oder über 80 % |
| Private-Link-Record-Sets | Private Link (Record Sets der private DNS zone) | Record Sets bei oder über 80 % |
Severity 3: informativ¶
Zur Information und Fehlersuche protokolliert. Keine Benachrichtigung.
| Alert | Ressource | Bedingung |
|---|---|---|
| Status des BGP-Peers | Network Gateway | Status unter 1 |
| Egress und Ingress des VPN-Gateway-Tunnels | VPN Gateway | Dynamischer Schwellenwert überschritten |
| Abweichung bei Egress und Ingress des VPN-Gateway-Tunnels | VPN Gateway | Abweichung beim Zeitstempel erkannt |
Severity 4: ausführlich (Audit)¶
Administrative und Sicherheitsereignisse, für Audit-Trails protokolliert. Keine Benachrichtigung.
| Gruppe | Alerts |
|---|---|
| Erstellen oder Aktualisieren | Network security group, network security group rule, Policy, Policy Assignment, firewall rule, Security Solution |
| Löschen | Policy Assignment, network security group, network security group rule, Log Analytics workspace, VPN Gateway |
| Operativ | Neugenerierung von Keys des Log Analytics workspace, fehlgeschlagene Patch-Installation einer virtuellen Maschine, Update einer Route Table (UDR) |
| Health | Resource Health nicht intakt; Service Health: Advisory, Incident, geplante Wartung und Security Advisory |
Nach Initiative¶
Die fünf Alert-Initiativen und die Ressourcenbereiche, die sie abdecken. Innerhalb eines Bereichs gibt es mehrere Alerts, meist einen pro Metrik.
| Initiative | Scope (management group) | Deckt ab |
|---|---|---|
Alerting-ServiceHealth |
Platform root | Azure-Service-Health-Ereignisse: Incident, Advisory, geplante Wartung, Security Advisory |
Alerting-Connectivity |
Platform connectivity | ExpressRoute-Circuits (BGP- und ARP-Verfügbarkeit, QoS-Drops, Bits in und out), Azure Firewall (Health, Auslastung der SNAT-Ports), VPN Gateways und Virtual Network Gateways (BGP-Peer-Status, Bandbreite, Tunnel-Ingress und -Egress, Packet Drops, CPU), private DNS zones (Kapazität, Abfragevolumen, Record Sets), DDoS und Verfügbarkeit von Public IP und virtuellem Netzwerk. Activity-Log-Alerts für das Löschen von firewall, network security group und VPN Gateway sowie für Updates von Route Tables |
Alerting-Management |
Platform management | Jobs im Automation Account, Backup-Health des Recovery Services Vaults, Verfügbarkeit von Storage Accounts, Löschen und Key-Neugenerierung des Log Analytics workspace |
Alerting-Identity |
Platform identity | Verfügbarkeit, Kapazität, Latenz, Requests und Löschen bei Key Vault |
Alerting-LandingZone |
Landing zones | Die Alerts für die workload-subscriptions unterhalb der landing-zone-management-groups. Sie enthält Alert-Definitionen für virtuelle Maschinen (siehe Monitoring-Regeln). Wird über die Processing Rule in jeder subscription geleitet |
Welche Initiativen zugewiesen sind, wird pro Plattform durch alerting_management_groups festgelegt
(Monitoring-Regeln).
Frühere Custom Alerts¶
Ältere Dokumentation führt neben den Baseline-Alerts drei Gruppen von Custom Alerts mit diesen Severities auf. Sie sind hier aufgelistet, weil sie auf Plattformen, die schrittweise aktualisiert wurden, noch auftauchen können:
| Gruppe | Beispiele |
|---|---|
| Security | Erstellen oder Aktualisieren und Löschen von Policy Assignments, Security Groups, Security Rules und Security Solutions (Severity 1 und 2) |
| Virtuelle Maschinen | Verfügbarkeit (Severity 0), CPU- und Speicherauslastung (1), Bytes und Operationen beim Lesen und Schreiben von Disks, Netzwerk in und out (2) |
| Application Gateway | Verfügbarkeit (0), Kapazität, CPU-Auslastung, Health und Durchsatz (1) |
Prüfe die Alert-Definitionen deiner Version, um zu sehen, welche davon existieren.
Was du mit einem Alert tust¶
| Severity | Typische Behandlung |
|---|---|
| 0, 1 | Starte den Incident-Prozess. Habe für jeden kritischen Alert ein Runbook |
| 2 | Plane die Arbeit ein. Wenn er sich wiederholt, behebe die Ursache oder passe den Schwellenwert an |
| 3, 4 | Lies sie im wöchentlichen Review und im monatlichen Health Check. Nutze sie, um zu erklären, was passiert ist |
Schalte einen Alert nicht stumm, weil er laut ist. Finde heraus, ob der Schwellenwert falsch ist, die Ressource nicht intakt ist oder der Alert in eine niedrigere Severity gehört, und ändere ihn über Monitoring-Regeln oder die Alert-Definition im Code.