Freigeben über

Sichere Bereitstellung von Azure Policy-Zuweisungen

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 der Implementierung von SDP mit Azure Policy besteht darin, Richtlinienzuweisungen schrittweise nach Ebenen bereitzustellen, um Richtlinienänderungen zu erkennen, die sich auf die Umgebung in frühen Phasen auswirken, bevor sie sich auf die kritische Cloudinfrastruktur auswirken.

Bereitstellungsebenen können auf vielfältige Weise organisiert werden. In diesem Lernprogramm zur Vorgehensweise werden Die Ebenen durch verschiedene Azure-Regionen mit Stufe 5 geteilt, die nicht kritische, niedrige Verkehrsstandorte und Stufe 0 mit den wichtigsten, höchsten Datenverkehrsstandorten kennzeichnen.

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. Nachdem Sie Ihre Richtliniendefinition ausgewählt haben, weisen Sie die Richtlinie auf oberster Ebene einschließlich aller Bereitstellungsebenen zu. Wenden Sie Ressourcenselektoren an, um die Anwendbarkeit mithilfe der "kind": "resource location" Eigenschaft auf die am wenigsten kritische Ebene einzugrenzen. 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 diesen Vorgang, indem Sie die Werte der Ressourcenauswahleigenschaft erweitern, um die nächsten Ebenen einzuschließen. 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 allen Ebenen mithilfe des audit Modus erfolgreich zugewiesen haben, sollte die Pipeline einen Vorgang auslösen, der den Richtlinieneffekt deny ändert und die Ressourcenselektoren auf den Speicherort zurücksetzt, der der Ebene 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 diesen Vorgang, indem Sie weitere Ebenen in die Ressourcenauswahlkonfiguration einschließen.

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

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. Nachdem Sie Ihre Richtliniendefinition ausgewählt haben, weisen Sie die Richtlinie auf oberster Ebene einschließlich aller Bereitstellungsebenen zu. Wenden Sie Ressourcenselektoren an, um die Anwendbarkeit mithilfe der "kind": "resource location" Eigenschaft auf die am wenigsten kritische Ebene einzugrenzen. 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 diesen Vorgang, indem Sie die Werte der Ressourcenauswahleigenschaft erweitern, um die Speicherorte der nächsten Ebene einzuschließen und die erwarteten Complianceergebnisse und den Anwendungsstatus zu validieren. Beispielselektor mit einem zusätzlichen Standortwert:

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

  4. Nachdem Sie die Richtlinie erfolgreich allen Ebenen mithilfe des DoNotEnforce-Modus zugewiesen haben, sollte die Pipeline einen Vorgang auslösen, der die Richtlinie enforcementMode in die Standardaktivierung ändert und die Ressourcenselektoren auf den Speicherort zurücksetzt, der der Ebene 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 diesen Vorgang, indem Sie weitere Ebenen in die Ressourcenauswahlkonfiguration einschließen.

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

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

  1. Wenden Sie innerhalb der vorhandenen Zuordnung Außerkraftsetzungen an, um die Version der Definition für die am wenigsten kritische Ebene 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 diesen Vorgang, indem Sie die Werte der Ressourcenauswahleigenschaft erweitern, um die nächsten Ebenen einzuschließen. 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

  • Last updated on