Sichere Bereitstellung von Azure Policy-Zuweisungen

  • Artikel

Mit der Erweiterung Ihrer Umgebung wird auch eine kontrollierte Continuous Deployment (CD)-Pipeline mit progressiver Belichtungssteuerung gefordert. Entsprechend empfiehlt Microsoft, dass DevOps-Teams das SDP-Framework befolgen. Die sichere Bereitstellung von Azure Policy-Definitionen und -Zuweisungen hilft dabei, die Auswirkungen unbeabsichtigter Verhaltensweisen von Richtlinienressourcen zu begrenzen.

Der allgemeine Ansatz des Implementierens von SDP mit Azure Policy besteht darin, ein nach Ringen gestaffeltes Rollout von Richtlinienzuweisungen durchzuführen, um frühzeitig Richtlinienänderungen zu erkennen, die die Umgebung beeinträchtigen, bevor sie die kritische Cloudinfrastruktur beeinträchtigen.

Bereitstellungsringe können auf unterschiedliche Weise organisiert werden. In diesem Tutorial werden Ringe in verschiedene Azure-Regionen unterteilt, wobei Ring 0 nicht kritische Standorte mit geringem Datenverkehr darstellt und Ring 5 die kritischsten Standorte mit dem höchsten Datenverkehr.

Schritte zur sicheren Bereitstellung von Azure Policy-Zuweisungen mit den Effekten „deny“ oder „append“

Verwenden Sie das folgende Flussdiagramm als Referenz, während Sie das SDP-Framework auf Azure Policy-Zuweisungen anwenden, die die Richtlinieneffekte deny oder append verwenden.

Hinweis

Weitere Informationen zu Azure Policy-Effekten finden Sie unter Grundlegendes zur Funktionsweise von Effekten.

Flussdiagramm mit den Schritten 1 bis 8, das die sicheren Bereitstellungsmethoden für die Bereitstellung einer neuen Azure Policy-Definition zeigt.

Flussdiagramm-Schrittnummern:

  1. Weisen Sie die Richtlinie nach der Wahl Ihrer Richtliniendefinition im höchsten Bereich zu, der alle Bereitstellungsringe umfasst. Wenden Sie Ressourcenselektoren an, um die Anwendbarkeit auf den am wenigsten kritischen Ring einzugrenzen, indem Sie die "kind": "resource location"-Eigenschaft verwenden. Konfigurieren Sie den Effekttyp „audit“ mithilfe von Zuweisungsüberschreibungen. Beispielauswahl mit eastUS als Ort und audit als Effekt:

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Audit" 
}]

  2. Nachdem die Zuweisung bereitgestellt und die erste Konformitätsüberprüfung abgeschlossen wurde, überprüfen Sie, ob das Konformitätsergebnis wie erwartet ist.

    Sie sollten auch automatisierte Tests konfigurieren, die Konformitätsprüfungen ausführen. Eine Konformitätsprüfung sollte die folgende Logik umfassen:

    • Sammeln von Konformitätsergebnissen
    • Wenn die Konformitätsergebnisse wie erwartet ausfallen, sollte die Pipeline fortgesetzt werden.
    • Wenn die Konformitätsergebnisse nicht wie erwartet ausfallen, sollte die Pipeline fehlschlagen, und Sie sollten mit dem Debuggen beginnen.

    Beispielsweise können Sie die Konformitätsprüfung konfigurieren, indem Sie andere Tools innerhalb Ihrer bestimmten Continuous Integration/Continuous Deployment (CI/CD)-Pipeline verwenden.

    In jeder Rolloutphase sollten die Integritätsprüfungen der Anwendung die Stabilität des Diensts und die Auswirkungen der Richtlinie bestätigen. Wenn die Ergebnisse aufgrund der Anwendungskonfiguration nicht wie erwartet ausfallen, gestalten Sie die Anwendung entsprechend um.

  3. Wiederholen Sie den Vorgang, indem Sie die Eigenschaftswerte des Ressourcenselektors um die Standorte der nächsten Ringe erweitern und die erwarteten Complianceergebnisse und die Integrität der Anwendung überprüfen. Beispielselektor mit einem zusätzlichen Standortwert:

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]

  4. Nachdem Sie die Richtlinie erfolgreich allen Ringen im audit-Modus zugewiesen haben, sollte die Pipeline eine Aufgabe auslösen, die den Richtlinieneffekt auf „deny“ ändert, und die Ressourcenselektoren auf den Standort zurücksetzen, der Ring 0 zugeordnet ist. Beispielselektor mit einer Region und einem Effekt, der auf „deny“ festgelegt ist:

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Deny" 
}]

  5. Sobald der Effekt geändert wurde, sollten automatisierte Tests überprüfen, ob die Erzwingung wie erwartet erfolgt.

  6. Wiederholen Sie dies, indem Sie weitere Ringe in die Ressourcenselektorkonfiguration einschließen.

  7. Wiederholen Sie diesen Vorgang für alle Produktionsringe.

Schritte zur sicheren Bereitstellung von Azure Policy-Zuweisungen mit den Effekten „modify“ oder „deployIfNotExists“

Die Schritte für Richtlinien, die die Auswirkung modify oder deployIfNotExists verwenden, ähneln den zuvor erläuterten Schritten, allerdings mit zusätzlicher Verwendung des Erzwingungsmodus und Auslösung eines Wartungstasks. Überprüfen Sie das folgende Flussdiagramm mit den geänderten Schritten 5 bis 9:

Flussdiagramm mit den Schritten 5 bis 9 des Workflows für die sichere Bereitstellung von Azure-Richtlinien.

Flussdiagramm-Schrittnummern:

  1. Weisen Sie die Richtlinie nach der Wahl Ihrer Richtliniendefinition im höchsten Bereich zu, der alle Bereitstellungsringe umfasst. Wenden Sie Ressourcenselektoren an, um die Anwendbarkeit auf den am wenigsten kritischen Ring einzugrenzen, indem Sie die "kind": "resource location"-Eigenschaft verwenden. Konfigurieren Sie den Erzwingungsmodus der Zuweisung mit DoNotEnforce. Beispielauswahl mit dem Standort eastUS und dem Wert DoNotEnforce für enforcementMode:

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "DoNotEnforce"

  2. Nachdem die Zuweisung bereitgestellt und die erste Konformitätsüberprüfung abgeschlossen wurde, überprüfen Sie, ob das Konformitätsergebnis wie erwartet ist.

    Sie sollten auch automatisierte Tests konfigurieren, die Konformitätsprüfungen ausführen. Eine Konformitätsprüfung sollte die folgende Logik umfassen:

    • Sammeln von Konformitätsergebnissen
    • Wenn die Konformitätsergebnisse wie erwartet ausfallen, sollte die Pipeline fortgesetzt werden.
    • Wenn die Konformitätsergebnisse nicht wie erwartet ausfallen, sollte die Pipeline fehlschlagen, und Sie sollten mit dem Debuggen beginnen.

    Sie können die Complianceprüfung konfigurieren, indem Sie andere Tools innerhalb Ihrer CI/CD-Pipeline (Continuous Integration/Continuous Deployment) verwenden.

    In jeder Rolloutphase sollten die Integritätsprüfungen der Anwendung die Stabilität des Diensts und die Auswirkungen der Richtlinie bestätigen. Wenn die Ergebnisse aufgrund der Anwendungskonfiguration nicht wie erwartet ausfallen, gestalten Sie die Anwendung entsprechend um.

    Sie können auch Wartungstasks auslösen, um vorhandene, nicht kompatible Ressourcen zu korrigieren. Stellen Sie sicher, dass die Wartungstasks Ressourcen wie erwartet in einen konformen Zustand bringen.

  3. Wiederholen Sie den Vorgang, indem Sie die Eigenschaftswerte des Ressourcenselektors um die Standorte der nächsten Ringe erweitern und die erwarteten Complianceergebnisse und die Integrität der Anwendung überprüfen. Beispielselektor mit einem zusätzlichen Standortwert:

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]

  4. Nachdem Sie die Richtlinie erfolgreich allen Ringen im Modus DoNotEnforce zugewiesen haben, sollte die Pipeline eine Aufgabe auslösen, die die Aktivierung der Richtlinie enforcementMode in Standard ändert, und die Ressourcenselektoren auf den Standort zurücksetzen, der dem Ring 0 zugeordnet ist. Beispielselektor mit einer Region und einem Effekt, der auf „deny“ festgelegt ist:

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "Default",

  5. Sobald der Effekt geändert wurde, sollten automatisierte Tests überprüfen, ob die Erzwingung wie erwartet erfolgt.

  6. Wiederholen Sie dies, indem Sie weitere Ringe in die Ressourcenselektorkonfiguration einschließen.

  7. Wiederholen Sie diesen Vorgang für alle Produktionsringe.

Schritte zum sicheren Aktualisieren der integrierten Definitionsversion innerhalb der Azure Policy-Zuweisung

  1. Wenden Sie in der vorhandenen Zuweisung overrides an, um die Version der Definition für den am wenigsten kritischen Ring zu aktualisieren. Wir verwenden eine Kombination aus overrides zum Ändern der definitionVersion und selectors innerhalb der overrides-Bedingung, um die Anwendbarkeit durch die "kind": "resource location"-Eigenschaft einzuschränken. Alle Ressourcen außerhalb der angegebenen Speicherorte werden weiterhin anhand der Version der definitionVersion-Eigenschaft der obersten Ebene in der Zuweisung bewertet. Beispiel für „overrides“ der Aktualisierung der Definitionsversion auf 2.0.* und nur das Anwenden auf Ressourcen in EastUs

    "overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0.*",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus"]
  }]
}]

  2. Nachdem die Zuweisung aktualisiert und die erste Complianceüberprüfung abgeschlossen wurde, prüfen Sie, ob das Ergebnis wie erwartet ausfällt.

    Sie sollten auch automatisierte Tests konfigurieren, die Konformitätsprüfungen ausführen. Eine Konformitätsprüfung sollte die folgende Logik umfassen:

    • Sammeln von Konformitätsergebnissen
    • Wenn die Konformitätsergebnisse wie erwartet ausfallen, sollte die Pipeline fortgesetzt werden.
    • Wenn die Konformitätsergebnisse nicht wie erwartet ausfallen, sollte die Pipeline fehlschlagen, und Sie sollten mit dem Debuggen beginnen.

    Beispielsweise können Sie die Konformitätsprüfung konfigurieren, indem Sie andere Tools innerhalb Ihrer bestimmten Continuous Integration/Continuous Deployment (CI/CD)-Pipeline verwenden.

    In jeder Rolloutphase sollten die Integritätsprüfungen der Anwendung die Stabilität des Diensts und die Auswirkungen der Richtlinie bestätigen. Wenn die Ergebnisse aufgrund der Anwendungskonfiguration nicht wie erwartet ausfallen, gestalten Sie die Anwendung entsprechend um.

  3. Wiederholen Sie den Vorgang, indem Sie die Eigenschaftswerte des Ressourcenselektors um die Standorte der nächsten Ringe erweitern und die erwarteten Complianceergebnisse und die Integrität der Anwendung überprüfen. Beispiel mit einem zusätzlichen Speicherortwert:

     "overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus", "westus"]
  }]
}]

  4. Nachdem Sie alle erforderlichen Speicherorte innerhalb der _selectors eingehalten haben, können Sie „overrides“ entfernen und die definitionVersion-Eigenschaft innerhalb der Zuweisung aktualisieren:

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

Nächste Schritte