코드 또는 콘솔
테넌트가 Git에 살면 무엇이 달라지나.
TerraProvider는 Intune와 Entra ID를 Terraform 코드로 리포지토리에 보관합니다. 모든 변경은 테넌트에 반영되기 전에 팀이 검토할 수 있는 플랜이 됩니다. Microsoft Intune 및 Microsoft Entra 관리 센터에서 클릭하는 방식과 어떻게 다른지, 그리고 관리 콘솔이 팀에 더 잘 맞는 경우는 언제인지 살펴봅니다.
- terraprovider/microsoft365wp
- Terraform and OpenTofu
- Business Source License 1.1
# microsoft365wp_conditional_access_policy.require_mfa_admins will be updated in-place ~ resource "microsoft365wp_conditional_access_policy" "require_mfa_admins" { ~ conditions = { ~ users = { ~ exclude_users = [ - "7c1e4a90-3f2b-4d8e-9a61-0b5c2e8f1d47", ] # (8 unchanged attributes hidden) } # (6 unchanged attributes hidden) } id = "2b7f9c3e-8d41-4f6a-b0e2-5c9a1d7e3f80" # (3 unchanged attributes hidden) }Plan: 0 to add, 1 to change, 0 to destroy.
예시 데이터.
나란히 비교
관리 센터와 코드에서 동일한 변경을 처리하는 방식
조건부 액세스 정책, 규정 준수 규칙, 두 번째 테넌트. 각각을 클릭으로 처리할 때와 리포지토리의 파일로 관리할 때 무슨 일이 일어나는지 비교합니다.
| 상황 | 관리 센터에서 | TerraProvider 사용 시 |
|---|---|---|
| 변경이 적용되기 전 | 조건부 액세스 변경은 누군가 저장을 누르는 순간 즉시 적용됩니다. | 변경은 풀 리퀘스트로 표현됩니다. 플랜은 테넌트에 아무것도 반영되기 전에 어떤 속성이 무엇에서 무엇으로 바뀌는지 보여줍니다. |
| 누가 승인했고, 이유는 무엇인가 | 감사 로그에는 정책을 저장한 계정이 기록됩니다. 티켓과 변경 이유는 어딘가에 따로 있거나 아예 없습니다. | 커밋 메시지, 풀 리퀘스트, 승인 내역이 변경 사항 옆에 함께 있습니다. 롤백은 revert 하나로 끝납니다. |
| 테스트와 프로덕션 | 테넌트마다 별도로 클릭해 설정하다 보면 시간이 지나면서 두 환경이 조금씩 달라집니다. | 하나의 모듈을 두 테넌트 모두에 적용합니다. 차이가 있는 부분은 변수로 명시됩니다. |
| 프로세스 외부에서 발생한 변경 | 문서는 변경 전 테넌트 상태를 계속 기술합니다. | 다음 플랜에 해당 변경이 표시됩니다. 파일에서 한 번도 언급하지 않은 설정도 포함됩니다. 그대로 채택하거나 원래대로 되돌리면 됩니다. |
| 새 테넌트 | 옆 탭에 기존 테넌트를 열어 놓고 모든 정책을 다시 클릭해서 설정합니다. | 현재 테넌트를 임포트하고(빠른 시작의 익스포트를 출발점으로 활용), 같은 코드를 새 테넌트에 적용합니다. |
| 파이프라인을 통한 변경 | 누군가 브라우저에 로그인해서 직접 변경합니다. | GitHub Actions와 Azure DevOps가 OpenID Connect로 로그인하며, 저장된 시크릿이 필요 없습니다. |
| 구성이 저장되는 위치 | 테넌트 자체 내에 있습니다. | Terraform과 OpenTofu가 모두 실행할 수 있는 HCL 형식으로 자체 Git 리포지토리에 저장됩니다. 프로바이더 소스는 Business Source License 1.1 하에 공개되어 있습니다. |
무엇이 맞나
코드는 풀 리퀘스트로 변경을 검토하는 팀에 맞습니다
어느 쪽이 맞는지는 테넌트보다 팀에 달려 있습니다. 누가 변경을 만들고, 어디서 검토하느냐가 핵심입니다.
TerraProvider가 맞는 경우
- 팀이 이미 Azure용 Terraform을 작성하고 풀 리퀘스트로 검토하고 있습니다.
- 조건부 액세스 변경이 적용되기 전에 두 번째 검토자가 필요합니다.
- 테스트와 프로덕션이 일치해야 하고, 차이가 있는 경우 그 내용을 읽을 수 있어야 합니다.
- 변경은 누군가의 브라우저가 아닌 GitHub Actions 또는 Azure DevOps에서 실행되어야 합니다.
관리 콘솔이 더 맞는 경우
- 팀원 중 HCL을 작성하는 사람이 없고, 앞으로도 그럴 계획이 없습니다.
- 변경을 브라우저에서 직접 처리하고 있으며, 팀도 그 방식을 유지하길 원합니다.
테넌트 팀과 MSP
자체 테넌트와 고객 테넌트를 하나의 프로바이더로 관리
자체 테넌트를 운영하는 팀은 테스트와 프로덕션을 하나의 모듈 아래에 둡니다. 매니지드 서비스 프로바이더는 고객 테넌트마다 별도의 프로바이더 블록을 지정하고, 동일한 베이스라인 모듈을 모든 테넌트에 적용합니다. 예외 사항은 검토자가 읽을 수 있는 변수로 명시됩니다.
- 자체 테넌트: Community Edition은 최대 99명 규모의 조직에 무료로 제공되며, Enterprise는 100명부터 지원이 추가됩니다.
- 고객 테넌트: Community Edition은 고객 테넌트를 지원하지 않으므로 별도 플랜이 필요합니다. 영업팀에 문의하기
provider "microsoft365wp" { alias = "contoso" tenant_id = "8a1f3c2e-5b7d-4e90-a6c4-2d9e7f1b0c35"}provider "microsoft365wp" { alias = "fabrikam" tenant_id = "e4c27b91-0d3a-4f86-b5e2-7a1c9d0f6b48"}module "baseline_contoso" { source = "./baseline" providers = { microsoft365wp = microsoft365wp.contoso }}module "baseline_fabrikam" { source = "./baseline" providers = { microsoft365wp = microsoft365wp.fabrikam } allow_byod = true}
예시 데이터.
자체 테넌트를 플랜으로 확인하세요.
Enterprise 트라이얼을 신청하거나, 최대 99명 규모 조직에 무료로 제공되는 Community Edition으로 시작하세요.