Kompleksowe zarządzanie z usługi DevOps do platformy Azure

W tym artykule opisano, jak dokładnie zarządzać i implementować praktyki zapewniania ładu dla twojego zespołu, takie jak uprawnienia kontroli dostępu opartej na rolach.

Nie wystarczy zaplanować i zaimplementować model kontroli dostępu opartej na rolach (RBAC) platformy Azure dla szablonów usługi Azure Resource Manager (szablonów usługi ARM), który ogranicza dostęp za pośrednictwem witryny Azure Portal i interfejsu wiersza polecenia platformy Azure.

Jeśli ten model nie jest dublowany w przypadku automatyzacji metodyki DevOps, organizacja może pozostawić otwarte tylne drzwi zabezpieczeń. Rozważmy przykład, w którym deweloper nie ma dostępu za pośrednictwem szablonów usługi ARM, ale nadal ma wystarczające uprawnienia do zmiany kodu aplikacji lub infrastruktury jako kodu i wyzwolenia przepływu pracy automatyzacji. Deweloper, pośrednio za pośrednictwem metodyki DevOps, może uzyskiwać dostęp do szablonów usługi ARM i wprowadzać destrukcyjne zmiany.

Pojedyncza płaszczyzna zarządzania tożsamościami z grupami firmy Microsoft

Pierwszym krokiem jest zintegrowanie rozwiązania Microsoft Entra ID w celu korzystania z logowania jednokrotnego na potrzeby zarządzania tożsamościami.

Jeśli nie używasz produktu ciągłej integracji platformy Azure, takiego jak Azure DevOps, sprawdź, czy dostawca oferuje integrację z firmą Microsoft Entra.

Drugim krokiem jest użycie grup Firmy Microsoft Entra— tych samych grup, których już używasz dla modelu RBAC szablonów usługi ARM. Najlepszym rozwiązaniem jest przypisywanie ról do grup firmy Microsoft Entra, a nie do osób indywidualnych. Aby utworzyć pełny model zapewniania ładu, należy wykonać ten krok dla szablonów usługi ARM i metodyki DevOps.

Usługa Azure DevOps ma ścisłą integrację z identyfikatorem Entra firmy Microsoft, w tym członkostwem w grupach Firmy Microsoft Entra, co ułatwia stosowanie przypisań ról do tej samej grupy firmy Microsoft Entra.

Uwaga

Jeśli używasz innego dostawcy ciągłej integracji, może istnieć pośredni kontener logiczny do zarządzania członkostwem w grupach, które również należy zachować, jeśli członkostwo w grupie Entra firmy Microsoft nie jest zsynchronizowane.

Na poniższym diagramie pokazano, jak identyfikator Entra firmy Microsoft jest używany jako pojedyncza płaszczyzna zarządzania tożsamościami. W szablonach usługi ARM i w naszych narzędziach DevOps (w tym przykładzie usługi Azure DevOps) musimy zarządzać tylko przypisaniami ról, a nie członkostwem, które powinny być zarządzane w usłudze Microsoft Entra ID. Zanotuj, że nazwy zasobów są zgodne z zalecanymi konwencjami nazewnictwa i skrótami zasobów platformy Azure.

Przykładowy scenariusz: Usuwanie dostępu wykonawcy za pomocą jednego kroku, członkostwa w usłudze Microsoft Entra

Aby przedstawić konkretne kompleksowe zarządzanie, przyjrzyjmy się korzyściom z przykładowego scenariusza.

Jeśli używasz identyfikatora Entra firmy Microsoft jako płaszczyzny zarządzania tożsamościami, możesz usunąć dostęp dewelopera do zasobów platformy Azure w jednej akcji, dostosowując ich członkostwo w grupie Microsoft Entra. Jeśli na przykład po zakończeniu projektu należy odwołać dostęp wykonawcy, usunięcie członkostwa wykonawcy z odpowiednich grup firmy Microsoft Entra spowoduje usunięcie dostępu do szablonów usługi ARM i usługi Azure DevOps.

Dublowanie modelu RBAC z przypisaniami ról

Jeśli jest to dobrze planowane, model RBAC w narzędziu ciągłej integracji będzie ściśle odzwierciedlać model RBAC platformy Azure. Mimo że przykłady nazw grup Entra firmy Microsoft na powyższym diagramie oznaczają reguły zabezpieczeń, członkostwo nie wymusza zabezpieczeń. Pamiętaj, że kontrola dostępu oparta na rolach jest kombinacją podmiotów zabezpieczeń, definicji i zakresów, które nie wchodzą w życie do momentu utworzenia przypisania roli.

• Na diagramie przedstawiono przypisanie roli dla pojedynczej grupy firmy Microsoft Entra. contoso-admins-group
• Ta grupa Firmy Microsoft Entra ma przypisaną rolę właściciela szablonów usługi Azure ARM w wielu zakresach subskrypcji:
  • contoso-dev-sub Subskrypcji
  • contoso-prod-sub Subskrypcji
• Element contoso-admins-group jest dodawany do grupy Project Administracja istrators dla usługi Azure DevOps w jednym zakresie projektu.

Grupa Microsoft Entra ma podobnie uprzywilejowane role zarówno dla szablonów usługi ARM, jak i metodyki DevOps. Zgodnie z tą logiką, jeśli mamy przypisaną rolę Współautor dla szablonów usługi ARM, nie będziemy oczekiwać, że należą one do grupy deweloperów Administracja istratorów dla metodyki DevOps.

Teraz, gdy rozumiesz konieczność zabezpieczania szablonów usługi ARM i przepływów pracy devOps, należy:

• Przejrzyj model RBAC i zastanów się, jak role i obowiązki zdefiniowane dla szablonów usługi ARM są zgodne z przepływem pracy ciągłej integracji/ciągłego wdrażania.
• Przejrzyj rozwiązania do zarządzania tożsamościami platformy ciągłej integracji i zintegruj identyfikator Firmy Microsoft Entra. Najlepiej, aby uwzględnić członkostwo w grupie Microsoft Entra.
• Przejrzyj role i poziomy dostępu oferowane przez narzędzie ciągłej integracji i porównaj je z modelem RBAC platformy Azure. Role i poziomy dostępu nie będą mapować jednego na jeden. Sprawdź konfigurację. Jeśli deweloper nie ma dostępu do szablonów usługi ARM, nie powinien mieć dostępu do metodyki DevOps. W najprostszym przykładzie deweloper, który nie ma uprawnień do zapisu do zasobów produkcyjnych, nie powinien mieć bezpośredniego dostępu do wyzwalania przebiegów potoków produkcyjnych.

Aby dowiedzieć się więcej na temat projektowania i uprawnień ładu, zobacz:

• Zalecana metoda udzielania i ograniczania uprawnień
• Domyślne uprawnienia i dostęp dla usługi Azure DevOps
• Zarządzanie dostępem osób do organizacji przy użyciu ról

Następne kroki

Teraz, gdy rozumiesz konieczność zabezpieczania szablonów usługi ARM i przepływów pracy devOps, dowiedz się, jak zarządzać wpisami tajnymi w bezpieczny sposób.

Architektura zabezpieczeń programowania