Welche PowerShell-Cmdlets sind read-only – und welche ändern produktiv Daten oder Konfigurationen?

Read-only vs. Write in PowerShell: Begriffe, Verb-Nomen-Konventionen und warum Namen allein nicht reichen

In PowerShell wirkt die Trennung zwischen „Read-only“ (Abfrage) und „Write“ (Änderung) auf den ersten Blick durch die Verb-Nomen-Konvention eindeutig. In der Praxis greifen Cmdlets jedoch auf sehr unterschiedliche API-Ebenen zu, lösen serverseitige Nebenwirkungen aus oder verändern Zustand indirekt. Der Name eines Cmdlets liefert daher nur eine erste Heuristik, aber keine belastbare Sicherheitszusage.

Was „Read-only“ in PowerShell tatsächlich bedeutet

„Read-only“ beschreibt im Administrationskontext idealerweise Cmdlets, die ausschließlich Daten abrufen und weder Konfiguration noch Betriebszustand verändern. Dazu zählen typische Get--Cmdlets, aber auch reine Test- und Diagnoseaufrufe. Entscheidend ist die Wirkung auf das Zielsystem, nicht die lokale Wirkung in der Shell: Eine Abfrage kann lokal Ressourcen verbrauchen, aber sollte serverseitig keinen Zustand persistieren.

Grauzonen entstehen dort, wo Abfragen serverseitig dynamische Metadaten erzeugen, Caches befüllen oder Diagnosedaten triggern. Beispielsweise können manche „Test“-Operationen Remote-Requests auslösen, die in Protokollen sichtbar werden, Sperren kurzzeitig anfordern oder API-Limits belasten. Solche Effekte sind nicht per se „Write“, beeinflussen aber die Umgebung und gehören in eine Risikoabwägung, bevor sie in wiederkehrende Jobs wandern.

Verb-Nomen-Konventionen: nützlich, aber nicht hinreichend

PowerShell fördert konsistente Verben: Get- für Abfragen, Set- für Anpassungen, New- für Anlage, Remove- für Löschung. Zusätzlich existieren Enable-/Disable-, Grant-/Revoke-, Start-/Stop- oder Clear-. Diese Semantik hilft beim schnellen Einordnen, scheitert aber dort, wo Module die Richtlinien nicht strikt umsetzen oder wo das „Ändern“ nicht im Namen sichtbar wird.

Typische Stolperstellen sind Cmdlets, die auf den ersten Blick wie Abfragen wirken, aber konfigurationsrelevante Artefakte erzeugen, sowie Cmdlets, die „nur“ eine Sitzung oder ein Token verändern und dadurch Folgewirkungen haben. Umgekehrt kann ein Set--Cmdlet im No-Op enden, wenn der Zielwert bereits gesetzt ist; die potentielle Wirkung bleibt jedoch identisch riskant. Für eine sichere Trennung in einer Mastertabelle genügt daher keine Namensprüfung, sondern eine Bewertung der realen Scope-Wirkung (lokal, Sitzung, Ressource, Mandant).

Warum Namen täuschen: konkrete Muster aus der Praxis

Vier Muster erklären, warum die Einordnung nach Verb häufig scheitert: indirekte Serveraktionen, Standardparameter mit weitreichender Wirkung, objektübergreifende Operationen und semantisch unpräzise Verben wie Update- oder Sync-. Besonders riskant sind Cmdlets, die ohne explizite Zielangabe in einen „globalen“ Default fallen oder durch Pipeline-Input unerwartet viele Objekte erfassen.

• Indirekte Side-Effects trotz Abfrage-Verb: Test-Connection -ComputerName <Host> -Count 2 erzeugt Netzwerkverkehr und kann Security-Events, IDS-Alarme oder Rate-Limits auslösen, obwohl keine Konfiguration persistiert wird.
• „Harmloses“ Auslesen mit hohem Scope: Get-ADUser -Filter * ist read-only, kann aber Domänencontroller durch teure LDAP-Queries belasten; das Risiko liegt in Last, nicht in Änderung.
• Schreibende Cmdlets mit implizitem Zielbereich: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned ändert ohne -Scope die lokale Maschine; mit -Scope CurrentUser bleibt die Wirkung auf das Benutzerprofil beschränkt.
• Pipeline-Falle bei Massenänderungen: Get-Service | Stop-Service sieht kompakt aus, wirkt aber potenziell systemweit; fehlendes Filtern und fehlendes -WhatIf erhöht das Risiko.
• „Update“/„Sync“ als unpräzise Verben: Update-Module verändert den lokalen Modulbestand; Update-Help ändert lokale Hilfedateien. Beides ist nicht tenantweit, kann aber Build- und Compliance-Annahmen brechen.

Parameter als Risikoindikatoren: Was besonders aufmerksam macht

Für die sichere Kategorisierung sind Parameter oft aussagekräftiger als das Verb. Bestimmte Schalter signalisieren Massenwirkung, irreversible Aktionen oder das Überspringen von Sicherheitsabfragen. Gleichzeitig gilt: Das Vorhandensein eines Sicherheitsmechanismus beweist nicht, dass er standardmäßig aktiv ist.

Einordnung in Tabellen: Kriterien, die über den Namen hinausgehen

Für eine belastbare Trennung in „Diagnose“ und „Änderung“ müssen Cmdlets nach Wirkung klassifiziert werden: Welche Objekte sind betroffen, welche Ebene wird verändert, und welche Seiteneffekte sind plausibel? Bei Cloud- und Verzeichnis-Modulen ist zusätzlich zu prüfen, ob eine Operation tenantweit greift oder nur auf eine Ressource. Tenantweite Wirkung entsteht häufig durch fehlende Objektbindung (kein -Identity), globale Policies oder Batch-Operationen, die eine gesamte Sammlung aktualisieren.

Auch bei read-only Einträgen gehört eine Last- und Sichtbarkeitsbewertung in die Dokumentation: Abfragen können Audit-Logs füllen, API-Throttling auslösen oder in sensiblen Netzen als „aktiver Scan“ interpretiert werden. In einer Mastertabelle sollte daher neben „Read/Write“ mindestens die Dimension „Scope“ (Prozess, Sitzung, Host, Domäne, Mandant) und „Nebenwirkungen“ geführt werden. Erst diese zusätzliche Struktur verhindert, dass eine scheinbar harmlose Zeile als unkritisch eingeordnet wird.

Mastertabelle: Paarweise Cmdlets für Abfrage und Änderung mit Zweck, Parametern, Scope, betroffenen Objekten und Seiteneffekten

Die Mastertabelle trennt strikt zwischen Cmdlets, die ausschließlich Zustände lesen, und funktionsgleichen Gegenstücken, die Konfigurationen ändern oder Objekte erstellen/löschen. Die Paarung folgt dem Prinzip „gleiches Zielobjekt, gleiche Domäne, unterschiedliche Wirkung“: Eine Abfrage liefert den Ist-Zustand; das passende Änderungs-Cmdlet setzt denselben Parameterraum in einen neuen Soll-Zustand um. Damit lassen sich Diagnose, Change-Planung, Risikoabschätzung und Review in einer einzigen Referenzstruktur abbilden.

Für jede Zeile werden Zweck, typische Parameter, Scope-Wirkung (lokal, hostweit, tenantweit), betroffene Objekte (z. b. Dienst, Benutzer, Policy, Ressource) und erwartbare Seiteneffekte dokumentiert. Zusätzlich markieren Warnhinweise Befehle mit besonders großem Blast Radius (tenantweit oder flächige Rekonfiguration). Empfohlene Testschritte sind bewusst operativ formuliert: Vorher-/Nachher-Abfragen, WhatIf/Confirm-Nutzung und eng begrenzte Scopes, wo verfügbar.

Spaltenlogik und Entscheidungsregeln für die Paarbildung

Die Tabelle bleibt belastbar, wenn Paarregeln konsequent eingehalten werden. Ein „Write“-Cmdlet gilt nur dann als Gegenstück, wenn es dasselbe Objektmodell adressiert und der Effekt klar abgegrenzt ist (Update/Set, Enable/Disable, New/Remove). Reine Ausführungsbefehle ohne dauerhafte Änderung (z. b. Neustart eines Dienstes) werden als „Write“ geführt, sofern sie den Betriebszustand ändern. Cmdlets, die indirekt Änderungen auslösen (z. b. Policy-Apply, Sync, Invoke mit Remotewirkung), erhalten eine explizite Seiteneffekt-Notiz, auch wenn kein „Set-“ im Namen steht.

• Paar-Kriterium (Objektgleichheit): Abfrage und Änderung müssen dasselbe Zielobjekt adressieren, z. b. Get-Service -Name wuauserv zu Set-Service -Name wuauserv -StartupType Automatic.
• Paar-Kriterium (Scope-Transparenz): Cmdlets mit potentiell flächiger Wirkung werden als solche markiert, z. b. Get-ExecutionPolicy -List zu Set-ExecutionPolicy -Scope LocalMachine bzw. Set-ExecutionPolicy -Scope CurrentUser.
• Paar-Kriterium (Seiteneffekt-Disziplin): Wenn das Write-Cmdlet weitere Komponenten beeinflussen kann, wird der häufigste Nebeneffekt genannt, z. b. Enable-PSRemoting -Force (Firewall-Regeln/WinRM) als Gegenstück zu Test-WSMan (nur Prüfung).
• Testschritt-Minimum je Zeile: Vorher-Abfrage (Get-*), begrenzter Change (Parameter/Filter), Nachher-Abfrage sowie – falls unterstützt – Simulation via -WhatIf und Absicherung via -Confirm.

Mastertabelle (Auszug): Read-only vs. Write pro Domäne

Der folgende Auszug zeigt die gewünschte Detailtiefe und die Art der Warnmarkierungen. Die Auswahl umfasst typische Windows-/PowerShell-Betriebsszenarien (Dienste, Netzwerk, Remoting, Features, Registry). Tenantweite Beispiele werden in dieser Referenz nur aufgenommen, wenn der jeweilige Verwaltungs-Stack in der Umgebung tatsächlich genutzt wird; die Warnlogik bleibt identisch (großer Scope, schwer rückgängig zu machen, massenhafte Wirkung).

Warnmarkierungen und Scope-Fallen (tenantweit, hostweit, sitzungsbezogen)

Warnmarkierungen werden nicht über den Cmdlet-Namen, sondern über Wirkung und Rückroll-Komplexität definiert. Tenantweite Änderungen (z. b. cloudbasierte Policies) gelten grundsätzlich als Hochrisiko, weil sie viele Identitäten oder Workloads gleichzeitig betreffen und Nebenwirkungen oft zeitversetzt sichtbar werden. Auf Host-Ebene entstehen Risiken vor allem durch Remotezugang, Authentifizierungs- und Firewall-Konfiguration sowie durch Feature-Aktivierungen, die einen Neustart oder Treiber-/Kernel-Komponenten nachziehen können. Sitzungsbezogene Änderungen (z. b. Variablen, temporäre Kontexte) sind dagegen typischerweise niedrig riskant, sollten aber klar gekennzeichnet bleiben, um falsche Erwartungen an Persistenz zu vermeiden.

• Tenantweit (Hochrisiko): Jede Zeile erhält ein klares Signal, wenn ein Cmdlet voraussichtlich flächig wirkt; typische Indikatoren sind administrative „Set/Update/New/Remove“-Operationen ohne Objektfilter oder mit sehr breiten Scopes wie -All bzw. flächige Policy-Zuweisungen.
• Hostweit (Mittel bis hoch): Änderungen an Remotezugang und Sicherheit werden hervorgehoben, z. b. Enable-PSRemoting -Force, Enable-NetFirewallRule, Set-ItemProperty unter HKLM:\, oder Dienst-/Treiber-Konfiguration über Set-Service.
• Scope-Parameter als Risikotreiber: Dieselbe Operation kann durch -Scope, -PolicyStore, -ComputerName oder Remoting (Invoke-Command -ComputerName) vom Einzelziel zur Fläche werden; diese Parameter werden in der Tabelle explizit als „Scope-Hebel“ benannt.

Empfohlene Testschritte je Zeile: Vorher/Nachher, Simulation, Begrenzung

Die Testschritte sind bewusst standardisiert, ohne in schematische Ritualisierung zu kippen. Sie zielen auf Reproduzierbarkeit: identische Abfragen vor und nach der Änderung, möglichst idempotente Änderungsparameter und dokumentierte Rückroll-Optionen. Wo Cmdlets -WhatIf unterstützen, wird die Simulation als Pflichtschritt geführt, ergänzt um -Confirm bei interaktiven Changes. Für Remoting- oder Massenänderungen wird ein Pilotumfang festgelegt (ein Host, ein Benutzer, ein kleines Objektset), bevor die Wirkung skaliert.

• Vorher-Abfrage (Baseline): Zustand erfassen und speichern, z. b. Get-Service -Name wuauserv | Select-Object Name,Status,StartType oder Get-NetFirewallRule -Name "WINRM-HTTP-In-TCP".
• Change-Simulation (falls verfügbar): Geplante Wirkung prüfen, z. b. Set-Service -Name wuauserv -StartupType Automatic -WhatIf oder Enable-NetFirewallRule -Name "WINRM-HTTP-In-TCP" -WhatIf.
• Nachher-Abfrage (Verifikation): Dieselbe Read-only-Abfrage erneut ausführen und Delta bewerten; zusätzlich Funktionscheck über unabhängige Tests, z. b. Test-WSMan nach Remoting-Aktivierung oder Test-NetConnection -Port 5985 nach Firewall-Änderung.
• Rückroll-Pfad (explizit): Wenn möglich, Gegenänderung notieren, z. b. Disable-NetFirewallRule -Name "WINRM-HTTP-In-TCP", Remove-LocalGroupMember -Group "Administrators" -Member "DOMAIN\User" oder Rücksetzung eines Registrywerts via Set-ItemProperty auf den vorher dokumentierten Wert.

Risikokontrolle in der Praxis: Tenantweite Warnmarker, Schutzmechanismen und Testschritte vor produktivem Einsatz

Die streng getrennte Gegenüberstellung von Read-Only- und Write-Cmdlets reduziert Irrtümer, ersetzt aber keine Risikokontrolle. In der Praxis entscheidet nicht nur der Verb (Get vs. Set/New/Remove), sondern vor allem die Reichweite: einzelne Ressource, Ressourcengruppe, Subscription, Verzeichnisobjekt oder tenantweite Einstellung. Besonders kritisch sind Cmdlets, die Standardwerte, Policies oder globale Konfigurationen verändern; sie wirken oft sofort, betreffen nicht nur ein Objekt, und ihre Rückabwicklung ist nicht immer eindeutig.

Tenantweite Warnmarker sollten deshalb nicht als generisches „Achtung“-Symbol verstanden werden, sondern als formales Kriterium: Ein Befehl erhält die Markierung, wenn Parameter oder Standardverhalten potenziell alle Benutzer, alle Gruppen, alle Geräte, alle Sites oder alle Workloads im Tenant beeinflussen können. Dazu zählen auch Cmdlets, die indirekt wirken, etwa über Rollen-/Berechtigungsmodelle, Conditional-Access-Regeln, Exchange-Transportregeln, Organisationskonfiguration oder Richtlinienzuweisung in Azure.

Tenantweite Warnmarker: Kriterien, Erkennung und Dokumentation

Ein belastbarer Warnmarker basiert auf wiederholbaren Prüfpunkten. Im operativen Alltag hilft eine kurze Vorabprüfung: Welche Identität wird adressiert, welches Objekt ändert sich tatsächlich, und welche Ebene ist implizit betroffen? Viele Write-Cmdlets nehmen eine Objekt-ID entgegen, verändern aber ein globales Verzeichnisattribut oder eine organisationsweite Policy. Umgekehrt kann ein scheinbar „kleines“ Update Massenfolgen auslösen, wenn das Objekt Referenzen trägt (z. B. Gruppenmitgliedschaften, Rollen, Policy-Zuordnungen).

• Warnmarker-Kriterium „Scope: Tenant“: Markierung, wenn ein Cmdlet Organisations-/Tenantobjekte ändert, z. B. Set-AzureADMSAuthorizationPolicy, Update-MgPolicyAuthorizationPolicy oder Set-OrganizationConfig.
• Warnmarker-Kriterium „Scope: global verknüpft“: Markierung, wenn Änderungen an einem Objekt systemweit referenziert werden (z. B. Rollen, CA-Policies, Transportregeln), auch wenn das Cmdlet nur ein Objekt adressiert, etwa New-MgIdentityConditionalAccessPolicy oder Set-TransportRule.
• Warnmarker-Kriterium „Defaults/Standards“: Markierung, wenn Standardverhalten verändert wird, etwa über globale Einstellungen, Baselines oder Richtlinien-Defaultzuweisungen; typische Parameter sind -Enabled, -State, -Policy, -Default.
• Warnmarker-Kriterium „Massenwirkung durch Filter“: Markierung, wenn ein Write-Cmdlet Filterausdrücke, dynamische Mitgliedschaften oder Batch-Operationen ausführt (z. B. Zuweisungen mit breiten Scopes in Azure über -Scope, -SubscriptionId oder Gruppenbasierung).
• Dokumentationspflicht bei Warnmarker: Zu jeder Markierung gehören mindestens Zielobjekt, Scope, Rollback-Ansatz und ein verifizierbarer „Pre-State“-Nachweis über ein Read-Only-Cmdlet wie Get-MgPolicyAuthorizationPolicy, Get-OrganizationConfig oder Get-AzPolicyAssignment.

Schutzmechanismen: Bestätigung, WhatIf, transkribierte Ausführung und minimale Berechtigungen

Ein wirksamer Schutz kombiniert technische Schranken und Prozessdisziplin. PowerShell bietet mit SupportsShouldProcess eine etablierte Basis: Viele Write-Cmdlets unterstützen -WhatIf und -Confirm, doch die Abdeckung ist nicht universell und das „WhatIf“-Ergebnis ist kein Zustandsbeweis. Zusätzlich sollten Befehle grundsätzlich in einer transkribierten Sitzung laufen, damit Parameter, Zeitpunkt und ausführende Identität nachvollziehbar bleiben.

• Explizite Bestätigung erzwingen: In riskanten Sessions $ConfirmPreference = "High" setzen und bei einzelnen Kommandos -Confirm angeben, statt sich auf Standardprompting zu verlassen.
• Dry-Run nutzen, wo unterstützt: Vor Änderungen -WhatIf ausführen (z. B. bei vielen Cmdlets im Exchange- oder Az-Modul). Ergebnis als Indikator interpretieren, nicht als Audit-Beleg.
• Transkription als Mindeststandard: Sitzung mit Start-Transcript -Path starten und mit Stop-Transcript beenden; Protokollpfad in einen schreibgeschützten Ablageort mit Zugriffskontrolle legen.
• Minimale Berechtigungen: Für Diagnosekonten Read-Only-Rollen verwenden; Write-Rechte zeitlich begrenzen (Privileged Identity Management) und nur für den Ziel-Workload aktivieren, statt breit angelegte Admin-Rollen dauerhaft zuzuweisen.
• Namensauflösung vermeiden: Bei Write-Operationen primär IDs verwenden (z. B. -UserId, -GroupId, -Id), um Kollisionen durch Anzeigenamen auszuschließen.

Testschritte vor produktivem Einsatz: Pre-State, Pilotierung, Rollback und Post-Checks

Vor jeder produktiven Änderung sollten die Read-Only-Pendants der Mastertabelle den Ausgangszustand festhalten. Entscheidend ist ein Pre-State, der nicht nur „irgendwelche“ Eigenschaften ausgibt, sondern genau die Felder, die das Write-Cmdlet berührt. Bei tenantweiten oder global verknüpften Änderungen ist eine Pilotierung Pflicht: erst in einem isolierten Test-Tenant oder, falls nicht möglich, in einem eng begrenzten Scope (Pilotgruppe, dedizierte OU/Gruppe, separate Subscription/Resource Group).

Rollback ist ein eigener Arbeitsschritt, keine implizite Hoffnung. Wo kein direktes „Undo“-Cmdlet existiert, muss der Rückweg über dokumentierte Sollwerte, Exporte oder IaC-Definitionen laufen. Bei Richtlinien und Konfigurationen gilt: Zuweisung entfernen ist nicht gleichbedeutend mit Wiederherstellung des vorherigen Zustands, wenn zwischenzeitlich neue Defaults greifen oder ein anderer Mechanismus (z. B. Baseline/Policy-Initiative) übersteuert.

• Pre-State erfassen: Vor Write die relevanten Read-Only-Abfragen speichern, z. B. Get-MgUser -UserId ... -Property "accountEnabled,displayName,mail"
Get-OrganizationConfig | Select-Object *
Get-AzPolicyAssignment -Scope ...
• Änderung als kleinstmögliche Einheit: Write-Cmdlet so scopen, dass nur ein Objekt bzw. eine Pilotgruppe betroffen ist; breite Filter oder Default-Scopes vermeiden, etwa explizit mit -Identity, -Id, -Scope arbeiten.
• Rollback konkretisieren: Vorab festlegen, wie der alte Zustand wiederhergestellt wird, z. B. Export der Policy-Definition und Zuweisung (Get-AzPolicyDefinition, Get-AzPolicyAssignment) oder dokumentierte Parameterwerte für ein erneutes Set-* mit dem ursprünglichen Stand.
• Post-Checks sofort und verzögert: Unmittelbar nach Ausführung über das Read-Only-Pendant prüfen; zusätzlich einen verzögerten Check einplanen, um Replikations-/Propagationseffekte abzudecken (je nach Dienst Minuten bis länger). Beispiele: Get-MgIdentityConditionalAccessPolicy, Get-TransportRule, Get-AzRoleAssignment.
• Telemetry und Logs einbeziehen: Nach Änderungen Auditdaten gegenprüfen, etwa über Search-UnifiedAuditLog (Microsoft Purview Audit) oder Entra-Audit/Sign-in-Logs via Graph-Abfragen, um unerwartete Nebeneffekte und Folgeänderungen zu erkennen.

Fehlertoleranz bei Write-Cmdlets: Reihenfolge, Idempotenz und begrenzte Nebenwirkungen

Risikokontrolle umfasst auch die Art der Ausführung. Write-Cmdlets sollten idempotent geplant werden: Der gleiche Lauf darf den Zustand nicht schrittweise verschlechtern. Praktisch bedeutet das, vor jeder Änderung den aktuellen Wert zu lesen und nur bei Abweichung zu schreiben. Reihenfolgen sind relevant, wenn Abhängigkeiten bestehen (z. B. erst Gruppe anlegen, dann Mitglieder, dann Policy-Zuweisung). Für tenantweite Befehle gilt außerdem: Änderungen in kleinen, überprüfbaren Inkrementen durchführen und nach jedem Schritt mit dem passenden Read-Only-Cmdlet validieren, statt mehrere riskante Writes in eine Pipeline zu bündeln.

Wo Module alternative „Safe Defaults“ anbieten, sollten diese konsequent genutzt werden: beispielsweise ein Policy-Objekt zunächst deaktiviert oder im Report-Only-Modus anlegen (sofern der jeweilige Dienst das vorsieht) und erst nach verifizierten Ergebnissen aktivieren. Existiert kein solches Sicherheitsnetz, wird die Pilotierung zum primären Mechanismus, um Nebenwirkungen auf Authentifizierung, Mailflow oder Ressourcenzugriffe kontrollierbar zu halten.