Udostępnij za pośrednictwem


Bezpieczne wdrażanie przypisań usługi Azure Policy

W miarę rozszerzania środowiska zapotrzebowanie na kontrolowany potok ciągłego wdrażania (CD) z progresywną kontrolą ekspozycji. W związku z tym firma Microsoft zaleca zespołom DevOps przestrzeganie struktury bezpiecznych praktyk wdrażania (SDP). Bezpieczne wdrażanie definicji i przypisań usługi Azure Policy pomaga ograniczyć wpływ niezamierzonych zachowań zasobów zasad.

Ogólne podejście do implementowania protokołu SDP za pomocą usługi Azure Policy polega na stopniowym wdrażaniu przypisań zasad według pierścieni w celu wykrywania zmian zasad wpływających na środowisko we wczesnych etapach, zanim wpłynie to na krytyczną infrastrukturę chmury.

Pierścienie wdrażania można organizować na różne sposoby. W tym samouczku z instrukcjami pierścienie są podzielone przez różne regiony platformy Azure z pierścieniem 0 reprezentującym niekrytyczne, małe lokalizacje ruchu i Pierścień 5 oznaczające najbardziej krytyczne, najwyższe lokalizacje ruchu.

Procedura bezpiecznego wdrażania przypisań usługi Azure Policy z efektami odmowy lub dołączania

Użyj poniższego schematu blokowego jako odwołania, ponieważ pracujemy nad zastosowaniem struktury SDP do przypisań usługi Azure Policy korzystających z deny efektów zasad lub append .

Uwaga

Aby dowiedzieć się więcej na temat efektów zasad platformy Azure, zobacz Omówienie działania efektów.

Schemat blokowy z krokami od 1 do ośmiu przedstawiającymi bezpieczne wdrażanie praktyk wdrażania nowej definicji usługi Azure Policy.

Numery kroków schematu blokowego:

  1. Po wybraniu definicji zasad przypisz zasady w najwyższym zakresie obejmującym wszystkie pierścienie wdrażania. Zastosuj selektory zasobów, aby zawęzić zastosowanie do najmniej krytycznego pierścienia "kind": "resource location" przy użyciu właściwości . audit Skonfiguruj typ efektu przy użyciu przesłonięć przypisania. Przykładowy selektor z lokalizacją eastUS i efektem jako audit:

    "resourceSelectors": [{ 
      "name": "SDPRegions", 
      "selectors": [{
          "kind": "resourceLocation",
          "in": [ "eastUS" ] 
      }]
    }], 
    "overrides":[{ 
      "kind": "policyEffect", 
      "value": "Audit" 
    }] 
    
  2. Po wdrożeniu przypisania i zakończeniu początkowego skanowania zgodności sprawdź, czy wynik zgodności jest zgodny z oczekiwaniami.

    Należy również skonfigurować testy automatyczne, które uruchamiają testy zgodności. Sprawdzanie zgodności powinno obejmować następującą logikę:

    • Zbieranie wyników zgodności
    • Jeśli wyniki zgodności są zgodne z oczekiwaniami, potok powinien kontynuować
    • Jeśli wyniki zgodności nie są zgodne z oczekiwaniami, potok powinien zakończyć się niepowodzeniem i należy rozpocząć debugowanie

    Na przykład można skonfigurować sprawdzanie zgodności przy użyciu innych narzędzi w ramach określonego potoku ciągłej integracji/ciągłego wdrażania (CI/CD).

    Na każdym etapie wdrażania kontrola kondycji aplikacji powinna potwierdzić stabilność usługi i wpływ zasad. Jeśli wyniki nie są zgodnie z oczekiwaniami ze względu na konfigurację aplikacji, refaktoryzuj aplikację zgodnie z potrzebami.

  3. Powtórz, rozwijając wartości właściwości selektora zasobów, aby uwzględnić następne pierścienie. lokalizacje i weryfikowanie oczekiwanych wyników zgodności i kondycji aplikacji. Przykładowy selektor z wartością lokalizacji dodanej:

    "resourceSelectors": [{ 
      "name": "SDPRegions", 
      "selectors": [{
          "kind": "resourceLocation",
          "in": [ "eastUS", "westUS"] 
      }]
    }]
    
  4. Po pomyślnym przypisaniu zasad do wszystkich pierścieni przy użyciu audit trybu potok powinien wyzwolić zadanie, które zmienia efekt deny zasad i resetuje selektory zasobów do lokalizacji skojarzonej z pierścieniem 0. Przykładowy selektor z jednym regionem i efektem ustawionym na odmowę:

    "resourceSelectors": [{ 
      "name": "SDPRegions", 
      "selectors": [{
          "kind": "resourceLocation",
          "in": [ "eastUS" ] 
      }]
    }], 
    "overrides":[{ 
      "kind": "policyEffect", 
      "value": "Deny" 
    }] 
    
  5. Po zmianie efektu zautomatyzowane testy powinny sprawdzić, czy wymuszanie odbywa się zgodnie z oczekiwaniami.

  6. Powtórz, dołączając więcej pierścieni w konfiguracji selektora zasobów.

  7. Powtórz ten proces dla wszystkich pierścieni produkcyjnych.

Procedura bezpiecznego wdrażania przypisań usługi Azure Policy z modyfikacją lub wdrożeniem efektówIfNotExists

Kroki dotyczące zasad korzystających z modify efektów lub deployIfNotExists są podobne do kroków opisanych wcześniej przy użyciu dodatkowej akcji korzystania z trybu wymuszania i wyzwalania zadania korygowania. Przejrzyj następujący schemat blokowy z zmodyfikowanymi krokami 5–9:

Schemat blokowy przedstawiający kroki od 5 do 9 w przepływie pracy praktyk bezpiecznego wdrażania usługi Azure Policy.

Numery kroków schematu blokowego:

  1. Po wybraniu definicji zasad przypisz zasady w najwyższym zakresie obejmującym wszystkie pierścienie wdrażania. Zastosuj selektory zasobów, aby zawęzić zastosowanie do najmniej krytycznego pierścienia "kind": "resource location" przy użyciu właściwości . Skonfiguruj tryb wymuszania przypisania do DoNotEnforce. Przykładowy selektor z lokalizacją eastUS i wymuszanieMode jako DoNotEnforce:

    "resourceSelectors": [{ 
      "name": "SDPRegions", 
      "selectors": [{
          "kind": "resourceLocation",
          "in": [ "eastUS" ] 
      }]
    }], 
    "enforcementMode": "DoNotEnforce"
    
  2. Po wdrożeniu przypisania i zakończeniu początkowego skanowania zgodności sprawdź, czy wynik zgodności jest zgodny z oczekiwaniami.

    Należy również skonfigurować testy automatyczne, które uruchamiają testy zgodności. Sprawdzanie zgodności powinno obejmować następującą logikę:

    • Zbieranie wyników zgodności
    • Jeśli wyniki zgodności są zgodne z oczekiwaniami, potok powinien kontynuować
    • Jeśli wyniki zgodności nie są zgodne z oczekiwaniami, potok powinien zakończyć się niepowodzeniem i należy rozpocząć debugowanie

    Sprawdzanie zgodności można skonfigurować przy użyciu innych narzędzi w potoku ciągłej integracji/ciągłego wdrażania (CI/CD).

    Na każdym etapie wdrażania kontrola kondycji aplikacji powinna potwierdzić stabilność usługi i wpływ zasad. Jeśli wyniki nie są zgodnie z oczekiwaniami ze względu na konfigurację aplikacji, refaktoryzuj aplikację zgodnie z potrzebami.

    Możesz również wyzwolić zadania korygowania w celu skorygowania istniejących niezgodnych zasobów. Upewnij się, że zadania korygowania przenoszą zasoby do zgodności zgodnie z oczekiwaniami.

  3. Powtórz to przez rozwinięcie wartości właściwości selektora zasobów, aby uwzględnić lokalizacje następnego pierścienia i sprawdzić poprawną oczekiwaną zgodność wyników i kondycję aplikacji. Przykładowy selektor z wartością lokalizacji dodanej:

    "resourceSelectors": [{ 
      "name": "SDPRegions", 
      "selectors": [{
          "kind": "resourceLocation",
          "in": [ "eastUS", "westUS"] 
      }]
    }]
    
  4. Po pomyślnym przypisaniu zasad do wszystkich pierścieni przy użyciu trybu DoNotEnforce potok powinien wyzwolić zadanie, które zmieni zasady enforcementMode na Domyślne włączenie i zresetuj selektory zasobów do lokalizacji skojarzonej z pierścieniem 0. Przykładowy selektor z jednym regionem i efektem ustawionym na odmowę:

    "resourceSelectors": [{ 
      "name": "SDPRegions", 
      "selectors": [{
          "kind": "resourceLocation",
          "in": [ "eastUS" ] 
      }]
    }], 
    "enforcementMode": "Default",
    
  5. Po zmianie efektu zautomatyzowane testy powinny sprawdzić, czy wymuszanie odbywa się zgodnie z oczekiwaniami.

  6. Powtórz, dołączając więcej pierścieni w konfiguracji selektora zasobów.

  7. Powtórz ten proces dla wszystkich pierścieni produkcyjnych.

Procedura bezpiecznego aktualizowania wbudowanej wersji definicji w ramach przypisania usługi Azure Policy

  1. W ramach istniejącego przypisania zastosuj przesłonięcia , aby zaktualizować wersję definicji dla najmniej krytycznego pierścienia. Używamy kombinacji przesłonięć, aby zmienić definicjęVersion i selektory w warunku przesłonięcia, aby zawęzić możliwość stosowania według "kind": "resource location" właściwości. Wszystkie zasoby, które znajdują się poza określonymi lokalizacjami, będą nadal oceniane względem wersji z właściwości najwyższego definitionVersion poziomu w przypisaniu. Przykład zastępuje aktualizację wersji definicji 2.0.* i stosuje ją tylko do zasobów w programie EastUs.

    "overrides":[{ 
      "kind": "definitionVersion", 
      "value": "2.0.*",
      "selectors": [{
        "kind": "resourceLocation",
        "in": [ "eastus"]
      }]
    }] 
    
  2. Po zaktualizowaniu przypisania i zakończeniu początkowego skanowania zgodności sprawdź, czy wynik zgodności jest zgodny z oczekiwaniami.

    Należy również skonfigurować testy automatyczne, które uruchamiają testy zgodności. Sprawdzanie zgodności powinno obejmować następującą logikę:

    • Zbieranie wyników zgodności
    • Jeśli wyniki zgodności są zgodne z oczekiwaniami, potok powinien kontynuować
    • Jeśli wyniki zgodności nie są zgodne z oczekiwaniami, potok powinien zakończyć się niepowodzeniem i należy rozpocząć debugowanie

    Na przykład można skonfigurować sprawdzanie zgodności przy użyciu innych narzędzi w ramach określonego potoku ciągłej integracji/ciągłego wdrażania (CI/CD).

    Na każdym etapie wdrażania kontrola kondycji aplikacji powinna potwierdzić stabilność usługi i wpływ zasad. Jeśli wyniki nie są zgodnie z oczekiwaniami ze względu na konfigurację aplikacji, refaktoryzuj aplikację zgodnie z potrzebami.

  3. Powtórz, rozwijając wartości właściwości selektora zasobów, aby uwzględnić następne pierścienie. lokalizacje i weryfikowanie oczekiwanych wyników zgodności i kondycji aplikacji. Przykład z wartością lokalizacji dodanej:

     "overrides":[{ 
      "kind": "definitionVersion", 
      "value": "2.0",
      "selectors": [{
        "kind": "resourceLocation",
        "in": [ "eastus", "westus"]
      }]
    }] 
    
  4. Po pomyślnym dołączeniu wszystkich niezbędnych lokalizacji w _selectors można usunąć przesłonięcie i zaktualizować właściwość definitionVersion w ramach przypisania:

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

Następne kroki