Azure Management & Governance Azure Management & Governance

Technische Referenz zu Azure Monitor, Log Analytics, Application Insights, Advisor, Cost Management + Billing, ARM/Bicep, Resource Graph, Azure Policy, Automation, Arc, Lighthouse, Service Health und Managed Grafana. Technical reference for Azure Monitor, Log Analytics, Application Insights, Advisor, Cost Management + Billing, ARM/Bicep, Resource Graph, Azure Policy, Automation, Arc, Lighthouse, Service Health, and Managed Grafana.

Governance-Basis: Management Groups, Subscriptions, Resource Groups, Tags und Locks Governance foundation: management groups, subscriptions, resource groups, tags, and locks

Azure trennt Management Plane und Data Plane. Governance-Mittel wie RBAC, Azure Policy, Locks, Tags und Deployments wirken auf der Management Plane und müssen deshalb vor Workload-spezifischen Designentscheidungen geplant werden. Azure separates the management plane from the data plane. Governance tools such as RBAC, Azure Policy, locks, tags, and deployments act on the management plane and therefore must be planned before workload-specific design decisions.

Bewährte Landing-Zone-Modelle gruppieren Subscriptions nach Verantwortung und Lebenszyklus: Plattform, Konnektivität, Identität, Shared Services, Sandbox, Produktion und Nicht-Produktion. Resource Groups bleiben die operative Einheit für Ressourcen mit gemeinsamem Lebenszyklus. Proven landing-zone models group subscriptions by responsibility and lifecycle: platform, connectivity, identity, shared services, sandbox, production, and non-production. Resource groups remain the operational unit for resources with a shared lifecycle.

• Management Groups dienen Vererbung und Governance, nicht fachlicher Navigation. Management groups serve inheritance and governance, not business navigation.
• Resource Groups sind Ownership-, Deploy- und Löschgrenzen. Resource groups are ownership, deployment, and deletion boundaries.
• Pflicht-Tags sollten per Policy oder IaC erzwungen werden. Mandatory tags should be enforced through policy or IaC.
• Delete Locks gehören auf gemeinsam genutzte oder kritische Ressourcen. Delete locks belong on shared or critical resources.
• Namensstandards müssen Resource-Graph- und KQL-Abfragen unterstützen. Naming standards must support Resource Graph and KQL queries.

Scopes und Hierarchie praktisch umsetzen Implementing scopes and hierarchy in practice

Management Groups sind die höchste wiederverwendbare Governance-Schicht unterhalb des Tenants. Sie eignen sich für Baseline-Policies, zentrale RBAC-Zuweisungen, Subscription-Moves und die Trennung zwischen Plattform- und Applikationsverantwortung. Management groups are the highest reusable governance layer below the tenant. They are suited for baseline policy, centralized RBAC assignments, subscription moves, and separation between platform and application responsibility.

az account management-group create
  --name corp-platform
  --display-name "Corp Platform"

az account management-group subscription add
  --name corp-platform
  --subscription 00000000-0000-0000-0000-000000000000
        

Tags und Locks automatisieren Automating tags and locks

Tags funktionieren operativ nur dann, wenn sie nicht auf freiwilliger Pflege beruhen. Kombinieren Sie Bicep-Defaults mit Azure Policy und vermeiden Sie freie Vokabulare für Kostenstelle, Umgebung oder Datenklassifikation. Tags work operationally only when they do not depend on voluntary maintenance. Combine Bicep defaults with Azure Policy and avoid free-form vocabularies for cost center, environment, or data classification.

targetScope = 'resourceGroup'

resource protectRg 'Microsoft.Authorization/locks@2020-05-01' = {
  name: 'can-not-delete'
  properties: {
    level: 'CanNotDelete'
    notes: 'Protect shared monitoring assets'
  }
}
        

Observability mit Azure Monitor, Log Analytics, Application Insights und Managed Grafana Observability with Azure Monitor, Log Analytics, Application Insights, and Managed Grafana

Azure Monitor ist die übergeordnete Observability-Plattform für Metriken, Logs, Traces, Alerts, Action Groups und Dashboards. Log Analytics Workspaces bilden die KQL-Datensenke für Plattform- und Gasttelemetrie, während workspace-basiertes Application Insights Anwendungsdaten im gleichen Analysemodell verfügbar macht. Azure Monitor is the overarching observability platform for metrics, logs, traces, alerts, action groups, and dashboards. Log Analytics workspaces provide the KQL data store for platform and guest telemetry, while workspace-based Application Insights makes application data available in the same analytics model.

Architektonisch entscheidend sind Workspace-Topologie, Region, Datenresidenz, Aufbewahrung, Private Link, Diagnostic Settings und Data Collection Rules. Wenn diese Themen erst nach dem Go-Live besprochen werden, leiden Datenqualität und Kosten fast immer gleichzeitig. Architecturally, workspace topology, region, data residency, retention, private link, diagnostic settings, and data collection rules are decisive. When these topics are discussed only after go-live, both data quality and cost almost always suffer together.

• Zentrale Operations-Workspaces nur bei echtem Compliance-Bedarf aufspalten. Split central operations workspaces only when there is a true compliance need.
• Data Collection Rules standardisieren Agent-basierte Datenerfassung auf VMs und Arc-Servern. Data collection rules standardize agent-based data collection on VMs and Arc-enabled servers.
• Workspace-basiertes Application Insights erleichtert Korrelation mit Plattformlogs. Workspace-based Application Insights simplifies correlation with platform logs.
• Basic Logs nur für Daten mit klarer Kostenbegründung verwenden. Use Basic Logs only for data with a clear cost rationale.
• Dashboards und Alerts als Code verwalten. Manage dashboards and alerts as code.

Workspace-Topologie und Datensammlung Workspace topology and data collection

Zentrale Workspaces funktionieren gut für tenantweite Korrelation und einheitliche Berechtigungen. Mehrere Workspaces sind sinnvoll bei rechtlicher Trennung, extremen Volumenunterschieden oder klar getrennten Betriebsdomänen. Central workspaces work well for tenant-wide correlation and consistent permissions. Multiple workspaces make sense for legal separation, extreme volume differences, or clearly separated operating domains.

az monitor log-analytics workspace create
  --resource-group rg-monitoring-prod
  --workspace-name law-platform-prod
  --location westeurope
  --sku PerGB2018
        

Workspace-basiertes Application Insights Workspace-based Application Insights

Für moderne Azure-Anwendungen ist workspace-basiertes Application Insights der Standard, weil Requests, Dependencies und Exceptions direkt mit Plattformlogs korreliert werden können. Dadurch entstehen Incident-Zeitleisten statt isolierter Tool-Sichten. For modern Azure applications, workspace-based Application Insights is the standard because requests, dependencies, and exceptions can be correlated directly with platform logs. That creates incident timelines instead of isolated tool views.

resource appi 'Microsoft.Insights/components@2020-02-02' = {
  name: 'appi-orders-prod'
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: law.id
  }
}
        

Managed Grafana als Operations-Cockpit Managed Grafana as the operations cockpit

Managed Grafana ergänzt Azure Monitor dort, wo mehrere Datenquellen, SLO-Dashboards oder Prometheus-Daten zusammengeführt werden müssen. Die Plattformverantwortung bleibt jedoch bei Azure Monitor und nicht bei der Dashboard-Schicht. Managed Grafana complements Azure Monitor where multiple data sources, SLO dashboards, or Prometheus data must be combined. Platform responsibility, however, remains with Azure Monitor rather than the dashboard layer.

az grafana create
  --name grafana-platform-prod
  --resource-group rg-monitoring-prod
  --location westeurope
  --zone-redundancy Enabled
        

KQL Playbook für Betrieb, Fehleranalyse und Governance KQL playbook for operations, troubleshooting, and governance

KQL ist die gemeinsame Abfragesprache für Log Analytics und Application Insights; Azure Resource Graph verwendet einen ähnlichen Dialekt für tenantweite Inventur. Reife Plattformteams standardisieren deshalb Query-Bibliotheken für Incident Triage, Kapazitätsplanung, Kostenprüfung und Governance-Audits. KQL is the shared query language for Log Analytics and Application Insights; Azure Resource Graph uses a similar dialect for tenant-wide inventory. Mature platform teams therefore standardize query libraries for incident triage, capacity planning, cost review, and governance audits.

Die folgenden Beispiele decken VM-, Anwendungs-, Policy- und Inventarfragen ab. In produktiven Umgebungen sollten zusätzlich Parameterisierung, gespeicherte Abfragen, Workbooks und Alert-Wiederverwendung etabliert werden. The following examples cover VM, application, policy, and inventory questions. In production environments, teams should also establish parameterization, saved queries, workbooks, and alert reuse.

KQL 01: Heartbeat-Lücken auf VMs und Arc-Servern KQL 01: heartbeat gaps on VMs and Arc-enabled servers

Diese Query identifiziert Maschinen, die länger als 15 Minuten keine Heartbeats mehr gesendet haben. Sie ist für Agent-Ausfälle, Netzwerkprobleme und Offline-Erkennung nach Wartungsfenstern nützlich. This query identifies machines that have not sent heartbeats for more than 15 minutes. It is useful for agent outages, network issues, and offline detection after maintenance windows.

Heartbeat
| summarize LastSeen=max(TimeGenerated) by Computer, _ResourceId
| extend MinutesSinceLastSeen = datetime_diff('minute', now(), LastSeen)
| where MinutesSinceLastSeen > 15
| project Computer, _ResourceId, LastSeen, MinutesSinceLastSeen
| order by MinutesSinceLastSeen desc
        

KQL 02: CPU-Hotspots über 15-Minuten-Fenster KQL 02: CPU hot spots over 15-minute windows

Perf-Daten aus AMA oder MMA bleiben für klassische VM-Kapazitätsanalysen relevant. P95-Werte sind meist aussagekräftiger als reine Durchschnittswerte. Perf data from AMA or MMA remains relevant for classic VM capacity analysis. P95 values are usually more useful than plain averages.

Perf
| where ObjectName == 'Processor'
| where CounterName == '% Processor Time'
| where InstanceName == '_Total'
| summarize AvgCpu=avg(CounterValue), P95Cpu=percentile(CounterValue, 95) by Computer, bin(TimeGenerated, 15m)
| where P95Cpu > 85
| order by P95Cpu desc
        

KQL 03: Destruktive Plattformoperationen KQL 03: destructive platform operations

AzureActivity ist das primäre Kontrollprotokoll für Änderungen auf der Management Plane. Besonders wertvoll ist die Suche nach Löschungen und kritischen Write-Operationen. AzureActivity is the primary control log for changes on the management plane. It is especially valuable for finding deletions and critical write operations.

AzureActivity
| where ActivityStatusValue == 'Success'
| where OperationNameValue has_any (
    'Microsoft.Compute/virtualMachines/delete',
    'Microsoft.Resources/subscriptions/resourcegroups/delete',
    'Microsoft.KeyVault/vaults/delete'
)
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, ResourceId, CorrelationId
| order by TimeGenerated desc
        

KQL 04: Fehlgeschlagene Requests nach Endpunkt KQL 04: failed requests by endpoint

Application Insights zeigt mit AppRequests Fehlerhäufigkeit, Latenz und Hotspots pro Operation. Die Query eignet sich auch als Basis für SLO-Reviews. Application Insights shows failure rate, latency, and hot spots per operation through AppRequests. The query is also useful as a basis for SLO reviews.

AppRequests
| where Success == false or ResultCode startswith '5'
| summarize Failures=count(), P95DurationMs=percentile(DurationMs, 95) by Name, bin(TimeGenerated, 15m)
| order by Failures desc
        

KQL 05: Langsame oder fehlerhafte Abhängigkeiten KQL 05: slow or failing dependencies

AppDependencies zeigt, ob Datenbanken, APIs oder Messaging-Backbones das eigentliche Bottleneck darstellen. P95 und Failures trennen Performance- von Verfügbarkeitsproblemen. AppDependencies shows whether databases, APIs, or messaging backbones are the real bottleneck. P95 and failure counts separate performance issues from availability issues.

AppDependencies
| summarize P50=percentile(DurationMs, 50), P95=percentile(DurationMs, 95), Failures=countif(Success == false) by Target, DependencyType, bin(TimeGenerated, 15m)
| order by P95 desc
        

KQL 06: Top Exceptions nach Operation KQL 06: top exceptions by operation

ProblemId und OperationName reichen oft aus, um Hotspots im Anwendungscode oder in Transaktionspfaden zu identifizieren. Bei Bedarf können Joins auf AppRequests ergänzt werden. ProblemId and OperationName are often enough to identify hot spots in application code or transaction paths. Joins to AppRequests can be added when needed.

AppExceptions
| summarize Exceptions=count() by ProblemId, OperationName, bin(TimeGenerated, 1h)
| order by Exceptions desc
        

KQL 07: Verfügbarkeit aus Synthetic Tests KQL 07: availability from synthetic tests

Availability-Tests sind wertvoll, wenn externe Erreichbarkeit und Response-Zeiten unabhängig vom Anwendungsprozess bewertet werden sollen. Daraus lassen sich belastbare SLI-Zeitreihen ableiten. Availability tests are valuable when external reachability and response times must be assessed independently of the application process. They provide reliable SLI time series.

AppAvailabilityResults
| summarize SuccessRate=100.0 * avg(todouble(Success)), AvgDurationMs=avg(DurationMs) by Name, bin(TimeGenerated, 30m)
| order by TimeGenerated desc
        

KQL 08: Ingestion-Kosten nach Datentyp KQL 08: ingestion cost by data type

Die Usage-Tabelle ist essenziell für FinOps im Monitoring. Sie zeigt, welche Tabellen die größten Volumina verursachen und wo DCR-Filter, Sampling oder Basic Logs sinnvoll sein könnten. The Usage table is essential for monitoring FinOps. It shows which tables create the biggest volumes and where DCR filtering, sampling, or Basic Logs could help.

Usage
| summarize IngestedGB=sum(Quantity) / 1024.0 by DataType, bin(TimeGenerated, 1d)
| order by IngestedGB desc
        

KQL 09: Dead-Letter-Trends für Service Bus KQL 09: dead-letter trends for Service Bus

Wenn Service-Bus-Diagnosen in Log Analytics landen, lassen sich Dead-Letter- und Fehlertrends schnell sichtbar machen. Für Integrationsteams ist das oft wertvoller als reine Metrikalarme. When Service Bus diagnostics land in Log Analytics, dead-letter and error trends become visible quickly. For integration teams this is often more useful than metric alerts alone.

AzureDiagnostics
| where ResourceProvider == 'MICROSOFT.SERVICEBUS'
| where OperationName has 'DeadLetter' or EntityName_s contains '$DeadLetterQueue'
| summarize DeadLetters=count() by NamespaceName_s, EntityName_s, bin(TimeGenerated, 1h)
| order by TimeGenerated desc
        

KQL 10: Ungetaggte Ressourcen in Resource Graph KQL 10: untagged resources in Resource Graph

Resource Graph eignet sich für tenantweite Inventur ohne Log-Ingestion. Diese Query findet Ressourcen ohne Tags außerhalb der Microsoft.Resources-Steuerobjekte. Resource Graph is ideal for tenant-wide inventory without log ingestion. This query finds resources without tags outside Microsoft.Resources control objects.

resources
| where type !startswith 'microsoft.resources/'
| extend TagCount = array_length(bag_keys(tags))
| where isnull(tags) or TagCount == 0
| project subscriptionId, resourceGroup, name, type, location
| order by subscriptionId asc
        

KQL 11: Public-IP-Inventar KQL 11: public IP inventory

Public IPs sind ein klassischer Governance- und Security-Indikator. Die Query gibt Überblick über SKU, Zuweisungsart und tatsächliche Adressierung. Public IPs are a classic governance and security indicator. The query gives an overview of SKU, allocation method, and actual addressing.

resources
| where type =~ 'microsoft.network/publicipaddresses'
| project subscriptionId, resourceGroup, name,
          sku=tostring(sku.name),
          allocation=tostring(properties.publicIPAllocationMethod),
          ip=tostring(properties.ipAddress)
| order by resourceGroup asc
        

KQL 12: Nicht konforme Policy-Ergebnisse KQL 12: non-compliant policy results

Policy-States aus Resource Graph sind für Governance-Reviews meist schneller als manuelle Portalansichten. Damit lassen sich Initiativen, Ressourcenbereiche und Problemhäufungen gezielt auswerten. Policy states from Resource Graph are often faster for governance reviews than manual portal views. They help analyze initiatives, resource scopes, and concentrations of non-compliance.

policyresources
| where type =~ 'microsoft.policyinsights/policystates'
| where tostring(properties.complianceState) == 'NonCompliant'
| summarize NonCompliant=count() by PolicyDefinition=tostring(properties.policyDefinitionName), SubscriptionId=subscriptionId
| order by NonCompliant desc
        

KQL 13: Aktive Service-Health-Ereignisse KQL 13: active service health events

Service Health kann per Resource Graph in tenantweite Übersichten einfließen. Das hilft zentralen NOCs oder MSPs, mehrere Subscriptions und Regionen übergreifend zu bewerten. Service Health can flow into tenant-wide views through Resource Graph. That helps central NOCs or MSPs assess multiple subscriptions and regions together.

servicehealthresources
| where tostring(properties.Status) !in ('Resolved', 'Closed')
| project trackingId=name,
          title=tostring(properties.Title),
          eventType=tostring(properties.EventType),
          status=tostring(properties.Status),
          impactedService=tostring(properties.Impact[0].Service)
| order by title asc
        

Azure Advisor sowie Cost Management + Billing Azure Advisor and Cost Management + Billing

Azure Advisor verdichtet technische Empfehlungen zu Reliability, Security, Performance, Operational Excellence und Cost. Er ersetzt keine Architektur- oder Security-Reviews, ist aber ein wertvoller Trigger für Backlog-Pflege und standardisierte Plattform-Checks. Azure Advisor consolidates technical recommendations across reliability, security, performance, operational excellence, and cost. It does not replace architecture or security reviews, but it is a valuable trigger for backlog grooming and standardized platform checks.

Cost Management + Billing deckt den finanziellen Steuerungsraum ab: Budgets, Kostenanalyse, Tag-basierte Zuordnung, Exporte, Reservierungen, Savings Plans und Chargeback-/Showback-Modelle. Gute FinOps verbindet beide Welten statt sie getrennt zu behandeln. Cost Management + Billing covers the financial control plane: budgets, cost analysis, tag-based allocation, exports, reservations, savings plans, and chargeback or showback models. Strong FinOps connects those worlds instead of treating them separately.

• Owner-, CostCenter- und Environment-Tags als harte Pflichtfelder definieren. Define owner, cost center, and environment tags as mandatory fields.
• Budgets mit Action Groups, Teams oder Ticketing verbinden. Connect budgets to action groups, Teams, or ticketing.
• Advisor-Empfehlungen regelmäßig bewerten, aber nur kontextuell sinnvoll umsetzen. Review Advisor recommendations regularly, but implement only what is contextually sound.
• Kostenexports in BI oder Data Warehouse überführen, wenn Business Units verrechnet werden. Feed cost exports into BI or a data warehouse when business units are charged back.
• Monitoring- und Retention-Kosten früh in Architekturentscheidungen einpreisen. Factor monitoring and retention cost into architecture decisions early.

Advisor-Empfehlungen operationalisieren Operationalizing Advisor recommendations

Advisor entfaltet Wirkung erst dann, wenn Empfehlungen mit Owner, Frist, Risiko und erwartetem Nutzen versehen werden. Besonders effektiv ist ein wiederkehrender Review-Termin zwischen Plattformbetrieb, Security und FinOps. Advisor becomes effective only when recommendations are assigned owners, due dates, risk, and expected benefit. A recurring review between platform operations, security, and FinOps is especially effective.

az advisor recommendation list
  --category Cost
  --query "[].{Resource:resourceMetadata.resourceId,Impact:impact,ShortDescription:shortDescription.solution}"
  --output table
        

Budgets und Benachrichtigungen Budgets and notifications

Budgets sind Signalgeber, keine automatischen Schutzschalter. Hinterlegen Sie deshalb klare Eskalations- und Bearbeitungspfade, damit Budgetüberschreitungen nachvollziehbar bearbeitet werden. Budgets are signals, not automatic circuit breakers. Attach clear escalation and handling paths so budget overruns are processed transparently.

az consumption budget create
  --amount 15000
  --budget-name prod-monthly-budget
  --category cost
  --resource-group rg-finops
  --time-grain monthly
        

ARM/Bicep: Deployments, What-If und Deployment Stacks ARM/Bicep: deployments, what-if, and deployment stacks

Azure Resource Manager ist die Orchestrierungsschicht für idempotente Bereitstellung, Abhängigkeiten, Policy-Prüfung, Locks, Role Assignments und Deployment-Historie. Bicep reduziert Template-Aufwand, ohne die ARM-Semantik zu verlassen. Azure Resource Manager is the orchestration layer for idempotent deployment, dependencies, policy evaluation, locks, role assignments, and deployment history. Bicep reduces template overhead without leaving ARM semantics.

Für reife Plattformen sind What-If, Template Specs, modulare Bicep-Strukturen, saubere Scope-Wahl und Deployment Stacks zentral. Sie helfen beim Aufbau ebenso wie beim Drift-Management und beim kontrollierten Entfernen nicht mehr referenzierter Ressourcen. For mature platforms, what-if, template specs, modular Bicep structures, clean scope selection, and deployment stacks are central. They help with initial build-out as well as drift management and controlled removal of resources that are no longer referenced.

• Bicep-Module pro Domäne und Scope statt monolithischer Templates verwenden. Use Bicep modules per domain and scope instead of monolithic templates.
• Freigegebene Foundation-Module als Template Specs oder versionierte Repos veröffentlichen. Publish approved foundation modules as template specs or versioned repos.
• What-If in CI/CD und vor manuellen Notfall-Deployments ausführen. Run what-if in CI/CD and before manual emergency deployments.
• Deployment Stacks nutzen, wenn auch das Entfernen kontrolliert werden soll. Use deployment stacks when removal must also be controlled.
• Deployments immer mit Tags, Locks und Diagnostik zusammendenken. Think of deployments together with tags, locks, and diagnostics.

Die richtige Scope-Wahl Choosing the right scope

Viele Teams deployen zu viel auf Resource-Group-Ebene, obwohl Budgets, Policy Assignments oder Resource Groups selbst bereits Subscription- oder Management-Group-Scopes benötigen. Korrekte Scope-Wahl vereinfacht Ownership und Pipelines. Many teams deploy too much at resource-group scope even though budgets, policy assignments, or resource groups themselves require subscription or management-group scopes. Correct scope selection simplifies ownership and pipelines.

targetScope = 'subscription'

param location string = 'westeurope'
param rgName string = 'rg-orders-prod'

resource rg 'Microsoft.Resources/resourceGroups@2024-03-01' = {
  name: rgName
  location: location
  tags: {
    environment: 'prod'
    owner: 'platform-team'
  }
}
        

What-If als Pflichtschritt What-if as a mandatory step

What-If zeigt die Unterschiede zwischen gewünschtem und aktuellem Zustand vor der Anwendung. In Kombination mit Pull Requests und Peer Reviews ist das der wichtigste Schutz gegen unbeabsichtigten IaC-Drift. What-if shows the difference between desired and current state before apply. Combined with pull requests and peer review, it is the most important guard against unintended IaC drift.

az deployment group what-if
  --resource-group rg-orders-prod
  --template-file main.bicep
  --parameters @prod.parameters.json
        

Deployment Stacks für kontrolliertes Aufräumen Deployment stacks for controlled cleanup

Deployment Stacks helfen überall dort, wo Plattformpakete nicht nur erstellt, sondern später auch wieder sauber zurückgebaut werden sollen. Das ist besonders für Shared Services, Demos und Sandboxes interessant. Deployment stacks help wherever platform packages must not only be created, but later removed cleanly as well. That is especially useful for shared services, demos, and sandboxes.

az stack group create
  --name monitor-baseline
  --resource-group rg-monitoring-prod
  --template-file monitor.bicep
  --parameters @prod.parameters.json
  --action-on-unmanage detachAll
        

Azure Policy, Remediation und Verknüpfung zur Sicherheitsseite Azure Policy, remediation, and linkage to the security page

Azure Policy ist das verbindliche Regelwerk für Ressourcen-Konfigurationen, Tagging, Allowed Locations, SKU-Grenzen, Network Exposure, Backup- und Monitoring-Baselines sowie regulatorische Vorgaben. Initiativen bündeln diese Regeln zu handhabbaren Governance-Paketen. Azure Policy is the mandatory rule system for resource configuration, tagging, allowed locations, SKU boundaries, network exposure, backup and monitoring baselines, and regulatory requirements. Initiatives bundle those rules into manageable governance packages.

Für die technische Vertiefung zu Security-Baselines, Defender for Cloud und Identitätshärtung sollte diese Seite immer zusammen mit der Referenz Azure Security gelesen werden. Policy ist dabei das Governance-Band zwischen Architekturvorgabe und technischem Enforcement. For a deeper look at security baselines, Defender for Cloud, and identity hardening, this page should always be read together with the Azure Security reference. Policy is the governance bridge between architectural intent and technical enforcement.

• Policies pro Domäne in Initiativen bündeln statt hunderte Einzelzuweisungen direkt zu verteilen. Bundle policies by domain into initiatives instead of distributing hundreds of individual assignments directly.
• Ausnahmen mit Ablaufdatum und Begründung versehen. Attach expiration dates and justification to exemptions.
• Policy mit Landing-Zone-Modulen und CI/CD-Prüfungen kombinieren. Combine policy with landing-zone modules and CI/CD validation.
• Remediation Tasks regelmäßig für Altbestände einplanen. Plan remediation tasks regularly for existing inventory.
• Azure Security als ergänzende Vertiefung nutzen. Use Azure Security as the complementary deep dive.

Initiativen und Parameter sauber modellieren Model initiatives and parameters cleanly

Wiederverwendbare Initiativen arbeiten mit Parametern für Allowed Locations, Tag-Werte, Ausnahmelisten oder Workspace-IDs. Dadurch bleiben sie zwischen Plattformen, Regionen und Umgebungen portierbar. Reusable initiatives rely on parameters for allowed locations, tag values, exception lists, or workspace IDs. That keeps them portable across platforms, regions, and environments.

resource assignment 'Microsoft.Authorization/policyAssignments@2024-04-01' = {
  name: 'pa-monitoring-baseline'
  properties: {
    displayName: 'Monitoring baseline'
    policyDefinitionId: initiativeId
    parameters: {
      logAnalyticsWorkspaceId: {
        value: law.id
      }
    }
  }
}
        

Ausnahmen und Remediation steuern Control exemptions and remediation

Ausnahmen sollten wie Architekturentscheidungen behandelt werden: begründet, genehmigt, befristet und nachvollziehbar. Für Modify- und DeployIfNotExists-Policies gehören regelmäßige Remediation-Runs in den Betriebsplan. Exemptions should be treated like architecture decisions: justified, approved, time-bound, and traceable. For modify and deployIfNotExists policies, regular remediation runs belong in the operating plan.

az policy remediation create
  --name rem-monitoring-baseline
  --policy-assignment pa-monitoring-baseline
  --resource-group rg-orders-prod
        

Automation, Azure Arc, Lighthouse, Service Health und Resource Graph Automation, Azure Arc, Lighthouse, service health, and Resource Graph

Azure Automation bleibt relevant für Runbooks, wiederkehrende Plattformaufgaben und die Ausführung mit Managed Identities. Azure Arc erweitert dieses Betriebsmodell auf Server, Kubernetes-Cluster und weitere Ressourcen außerhalb nativer Azure-Compute-Dienste. Azure Automation remains relevant for runbooks, recurring platform tasks, and execution with managed identities. Azure Arc extends that operating model to servers, Kubernetes clusters, and other resources outside native Azure compute services.

Azure Lighthouse ergänzt die technische Steuerung um sichere Delegation über Tenant-Grenzen hinweg. Service Health liefert die Provider-Sicht auf Incidents, während Resource Graph tenantweite Betroffenheitsanalysen und Inventur ohne Log-Ingestion ermöglicht. Azure Lighthouse complements technical control with secure delegation across tenant boundaries. Service Health provides the provider view of incidents, while Resource Graph enables tenant-wide impact analysis and inventory without log ingestion.

• Runbooks bevorzugt mit Managed Identity statt mit gespeicherten Secrets bauen. Prefer managed identities over stored secrets in runbooks.
• Arc-Server direkt mit DCR, Defender und Update-Baselines verbinden. Connect Arc-enabled servers directly to DCR, Defender, and update baselines.
• Lighthouse-Delegationen nach Support- oder Betriebsrollen statt nach Maximalrechten modellieren. Model Lighthouse delegations by support or operations role rather than by maximum rights.
• Service-Health-Alerts für kritische Regionen und Subscriptions einrichten. Set up service health alerts for critical regions and subscriptions.
• Resource-Graph-Queries für Public IPs, Key Vaults und Produktionsdatenbanken pflegen. Maintain Resource Graph queries for public IPs, Key Vaults, and production databases.

Runbooks mit Managed Identity Runbooks with managed identity

Runbooks sollten möglichst wenig lokale Konfiguration benötigen und vollständig über Rollen, Variablen, Key Vault und Managed Identity steuerbar sein. Dadurch bleiben sie reproduzierbar und auditierbar. Runbooks should need as little local configuration as possible and be fully controlled through roles, variables, Key Vault, and managed identity. That keeps them reproducible and auditable.

Disable-AzContextAutosave -Scope Process
$null = Connect-AzAccount -Identity
$running = Get-AzVM -Status | Where-Object { $_.PowerState -eq 'VM running' -and $_.Tags['shutdown'] -eq 'true' }
$running | ForEach-Object {
    Stop-AzVM -ResourceGroupName $_.ResourceGroupName -Name $_.Name -Force
}
        

Arc-Onboarding und Hybrid-Konsistenz Arc onboarding and hybrid consistency

Arc bringt nicht nur Inventar nach Azure, sondern macht Server für Policy, Update Manager, Defender for Cloud und Log Analytics steuerbar. Ohne saubere Rollen und Outbound-Pfade bleibt der Mehrwert jedoch begrenzt. Arc brings not only inventory into Azure, but also makes servers manageable for policy, Update Manager, Defender for Cloud, and Log Analytics. Without clean role assignments and outbound paths, the value remains limited.

az connectedmachine connect
  --resource-group rg-arc-prod
  --location westeurope
  --subscription 00000000-0000-0000-0000-000000000000
  --cloud AzureCloud
        

Lighthouse und Service-Health-Alerting Lighthouse and service health alerting

Lighthouse trennt Kunden- oder Tochtertenant sauber vom Betreiber und vereinfacht Governance, SOC-Betrieb und Plattform-Support. Ergänzend sollten Service-Health-Alerts und Resource-Graph-Abfragen tenantübergreifend standardisiert werden. Lighthouse cleanly separates customer or subsidiary tenants from the operator and simplifies governance, SOC operations, and platform support. In addition, service health alerts and Resource Graph queries should be standardized across tenants.

az monitor activity-log alert create
  --name service-health-prod
  --resource-group rg-monitoring-prod
  --condition category=ServiceHealth
        

Begriffe, Merksätze und Betriebscheckliste Terms, reminders, and operating checklist

Die folgende Übersicht fasst zentrale Management-Begriffe und ihre operative Bedeutung zusammen. Sie eignet sich als kompakte Checkliste für Architektur-Reviews, Plattform-Transitions und Betriebsdokumentation. The following overview summarizes key management terms and their operational meaning. It serves as a compact checklist for architecture reviews, platform transitions, and operations documentation.

• Governance beginnt mit Hierarchie- und Scope-Design. Governance starts with hierarchy and scope design.
• Logging-Baselines gehören in IaC oder Policy. Logging baselines belong in IaC or policy.
• FinOps und Observability sind verbunden, weil Telemetrie Kosten erzeugt. FinOps and observability are linked because telemetry creates cost.
• Resource Graph ergänzt Monitor-Logs, ersetzt sie aber nicht. Resource Graph complements Monitor logs but does not replace them.
• Hybridbetrieb wird erst mit Arc und sauberem Identity-Design nachhaltig. Hybrid operations become sustainable only with Arc and clean identity design.