여러 테넌트에서 Azure 랜딩 존 자동화
조직에 각각 ALZ(Azure 랜딩 존)가 있는 여러 Microsoft Entra 테넌트가 있는 경우 자동화가 핵심입니다. 자동화를 사용하면 모든 테넌트에서 대규모로 ALZ 배포를 성공적으로 작동하고 기본 수 있습니다. 여러 테넌트에서 ALZ 배포를 자동화하는 방법에는 여러 가지가 있습니다. 이 방법은 조직에 여러 Microsoft Entra 테넌트가 있는 이유에 따라 달라집니다.
예를 들어 독립 소프트웨어 공급업체인 경우 여러 Microsoft Entra 테넌트가 있을 수 있습니다. 회사 및 SaaS 솔루션 Microsoft Entra 테넌트는 별도로 유지하려고 할 수 있습니다. 의도되었든 실수로든 다른 테넌트에 영향을 주는 작업 또는 배포의 위험이 줄어듭니다.
다음 섹션에서는 수행할 수 있는 방법에 대한 다이어그램과 지침을 제공합니다. 여러 Microsoft Entra 테넌트 처리 시 Azure 랜딩 존 배포를 자동화하기 위한 요구 사항, 고려 사항 및 권장 사항에 따라 가장 적합한 방법을 선택합니다.
참고 항목
먼저 다음 문서를 검토하여 Microsoft Entra 테넌트에 대한 개요를 확인합니다.
접근 방식
여러 Microsoft Entra 테넌트에서 Azure 랜딩 존의 배포를 자동화하는 두 가지 방법이 있습니다.
접근 방식 1 – 완전 격리 는 다중 테넌트 시나리오에서 가장 일반적인 방법입니다. 이 방법은 다중 테넌트 접근 방식을 사용할 때 가장 일반적인 요구 사항인 Microsoft Entra 테넌트 간에 필요한 분리 및 격리를 유지합니다.
접근 방식 2 – 여러 서비스 주체 를 사용하는 공유 애플리케이션 등록(다중 테넌트)은 일반적으로 MSP(관리 서비스 공급자) 시나리오에서 사용됩니다. 이 방법 에서는 배포 스탬프 패턴을 사용하여 대규모로 여러 테넌트에서 거의 동일한 아키텍처의 배포를 자동화할 수 있습니다.
이러한 두 가지 방법은 모두 예제와 영감으로 제공됩니다. 조직의 요구 사항에 따라 배포의 접근 방식을 혼합하고 일치시킬 수 있습니다.
Important
이 문서에서는 조직이 가지고 있는 각 Microsoft Entra 테넌트에서 플랫폼으로 Azure 랜딩 존의 배포 및 운영을 자동화하는 방법을 설명합니다. 이 문서의 접근 방식, 권장 사항 및 고려 사항은 해당 서비스 및 애플리케이션을 랜딩 존(구독)에 배포하고 운영하는 애플리케이션 팀에서 사용할 수 없습니다 . 다양한 유형의 랜딩 존에 대한 자세한 내용은 플랫폼 및 애플리케이션 랜딩 존을 참조 하세요.
접근 방식 1 – 완전한 격리
이 방법에서 기본 목표는 다음과 같은 모든 자동화 구성 요소에서 각 Microsoft Entra 테넌트를 서로 격리하는 것입니다.
- Git 리포지토리입니다.
- GitHub Actions 또는 Azure Pipelines(사용 중인 경우 자체 호스팅 실행기 포함).
- 자체 호스팅 실행기, SPN(서비스 사용자 이름), 사용자 또는 관리자에 할당된 관리 ID와 같이 자동화에서 작업을 수행하는 데 사용되는 ID입니다.
이 방법에서는 Microsoft Entra 테넌트별로 중복되는 더 많은 구성 요소를 관리할 수 있습니다. 일부 조직에서는 이러한 유형의 분리 및 격리를 의무화하는 규정 준수 제어를 적용할 수 있습니다.
참고 항목
조직에서 플랫폼 자동화에 관리 ID만 사용하도록 허용하는 경우 이 방법이나 각 테넌트에 개별적으로 로그인하는 방법을 사용해야 합니다. 관리 ID는 테넌트 간 시나리오를 지원하지 않습니다. 자세한 내용은 이 FAQ를 참조하세요.
플랫폼 관리자 및 개발자를 위한 ID - 접근 방식 1
이 방법에서는 각 Microsoft Entra 테넌트에서도 ID를 격리해야 합니다. 즉, 각 플랫폼 관리자 또는 개발자는 해당 테넌트 내에서 작업을 수행하기 위해 각 테넌트 내에서 별도의 사용자 계정이 필요합니다. 이러한 계정은 각 테넌트에 대해 GitHub 또는 Azure DevOps와 같은 개발자 도구에 액세스하는 데도 사용됩니다. 이 접근 방식에 따른 관리자 및 개발자 생산성의 영향을 신중하게 고려합니다.
Microsoft Entra B2B 및/또는 Azure Lighthouse를 사용할 수 있지만 이 옵션은 별도의 Microsoft Entra 테넌트가 있는 이유에 의문을 제기합니다.
접근 방식 2 – 여러 서비스 주체를 사용한 공유 애플리케이션 등록(다중 테넌트)
이 방법에서는 Microsoft Entra 테넌트 관리에서 애플리케이션 등록을 만듭니다. 관리하려는 모든 Microsoft Entra 테넌트에서 애플리케이션 등록에 따라 해당 테넌트에 SPN(서비스 사용자 이름)이 만들어집니다. 이 작업을 통해 파이프라인 작업 및 단계를 실행하는 작업자가 단일 자격 증명 집합으로 Microsoft Entra 테넌트에 로그인할 수 있습니다.
팁
애플리케이션 등록과 엔터프라이즈 애플리케이션(서비스 원칙) 간의 관계에 대한 자세한 내용은 Microsoft Entra ID의 애플리케이션 및 서비스 주체 개체를 참조하세요.
Important
이 방법에서는 높은 권한의 계정이므로 단일 애플리케이션 등록 및 관련 엔터프라이즈 애플리케이션(서비스 주체)이 SIEM(보안 정보 및 이벤트 관리) 도구에서 비정상적인 활동을 모니터링해야 합니다. 경고를 보내고 경고 심각도에 따라 자동으로 조치를 취해야 합니다.
이전 예제에서는 단일 앱 등록이 contoso.onmicrosoft.com Microsoft Entra 테넌트에 있고 엔터프라이즈 애플리케이션은 앱 등록에 연결된 각 Microsoft Entra 테넌트에 있습니다. 이 설정을 통해 파이프라인은 단일 앱 등록을 사용하여 모든 Microsoft Entra 테넌트에 인증하고 권한을 부여할 수 있습니다. 자세한 내용은 애플리케이션 다중 테넌트 만들기를 참조하세요.
중앙 집중식 파이프라인을 사용하는 경우 Microsoft Entra 테넌트와 환경, 연결된 구독, 조직 이름 및 인증 및 권한 부여에 사용되는 ID 개체 ID와 같은 기타 메타데이터와 상관 관계가 있는 데이터가 포함된 작은 매핑 테이블을 빌드해야 할 수 있습니다. 이 데이터는 파이프라인을 실행하는 동안 몇 가지 논리 및 조건을 사용하여 배포되는 Microsoft Entra 테넌트 및 ID를 제어하는 단계에서 호출할 수 있습니다. 데이터는 Azure Cosmos DB 또는 Azure Table Storage와 같은 서비스에 저장할 수 있습니다.
개발, 테스트 또는 프로덕션과 같은 여러 환경을 처리하는 경우 동일한 방식으로 또는 별도의 애플리케이션 등록 및 엔터프라이즈 애플리케이션을 파이프라인과 함께 사용하여 제어할 수 있습니다.
각 Microsoft Entra 테넌트에 대해 별도의 파이프라인을 포함하거나 단일 파이프라인을 사용하도록 결정할 수 있습니다. 선택은 요구 사항에 따라 사용자입니다.
참고 항목
Azure Lighthouse는 이 접근 방식과 유사하지만 Azure Lighthouse는 DATAActions 권한이 있는 RBAC 소유자, 사용자 액세스 관리자 및 역할의 할당을 허용하지 않습니다. 자세한 내용은 Azure Lighthouse에 대한 역할 지원을 참조 하세요.
소유자 및 사용자 액세스 역할은 일반적으로 모든 Azure 랜딩 존 배포 시나리오에서 필요합니다. 이 요구 사항은 Azure 랜딩 존의 전체 플랫폼 자동화 배포 측면에 대한 옵션으로 Azure Lighthouse를 제거하지만 일부 시나리오에서는 여전히 유용합니다. 자세한 내용은 ALZ 다중 테넌트에서 Azure Lighthouse 사용을 참조 하세요.
플랫폼 관리자 및 개발자를 위한 ID - 접근 방식 2
이 접근 방식에서 플랫폼 관리자와 개발자는 일반적으로 Microsoft Entra 테넌트 관리에만 액세스해야 합니다. 이 액세스 권한은 모든 테넌트가 배포되고 운영되는 개발자 도구(예: GitHub 또는 Azure DevOps)에 대한 액세스 권한을 부여합니다.
Microsoft Entra B2B 또는 Azure Lighthouse를 통해 다른 Microsoft Entra 테넌트에 액세스할 수 있습니다. 관리 테넌트에서 동일한 계정을 사용하거나 첫 번째 방법의 예제와 같이 별도의 계정이 있을 수 있습니다.