コードかコンソールか
テナントが 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.
サンプルデータ。
並べて比較
管理センターとコードで同じ変更を行う場合
条件付きアクセスポリシー、コンプライアンスルール、2つ目のテナント。それぞれをクリック操作で行う場合と、リポジトリ内のファイルとして管理する場合とで何が変わるかを見ていきます。
| 状況 | 管理センターの場合 | TerraProvider の場合 |
|---|---|---|
| 変更が反映される前 | 条件付きアクセスの変更は、誰かが「保存」を押した瞬間に有効になります。 | 変更はプルリクエストとして扱われます。テナントに何も触れる前に、プランでどの属性がどの値からどの値へ変わるかを確認できます。 |
| 誰が、なぜ承認したか | 監査ログにはポリシーを保存したアカウント名が記録されます。チケットや変更理由は別の場所にあるか、そもそも存在しないこともあります。 | コミットメッセージ、プルリクエスト、承認記録が変更のそばにまとめて残ります。ロールバックはリバートで済みます。 |
| テストと本番 | 各テナントをそれぞれ個別に操作するため、時間が経つにつれて両者の設定が乖離していきます。 | 1つのモジュールを両方のテナントに適用します。差異がある箇所は変数で明示されます。 |
| プロセス外での変更 | ドキュメントは変更前の状態を記述し続けます。 | 次回のプランにその変更が一覧表示されます。コードに記述のない設定も含めて。採用するか元に戻すかを選択できます。 |
| 新しいテナント | 隣のタブに旧テナントを開きながら、すべてのポリシーを再度クリック操作で設定していきます。 | 既存のテナントをインポートし（クイックスタートのエクスポートが出発点になります）、同じコードを新しいテナントに適用するだけです。 |
| パイプラインからの変更 | 誰かがブラウザにサインインして手動で変更を加えます。 | GitHub Actions と Azure DevOps は OpenID Connect でサインインするため、シークレットを保存する必要がありません。 |
| 構成の保存場所 | テナント自体の中に保存されます。 | 自分の Git リポジトリに HCL として保存されます。Terraform と OpenTofu のどちらでも実行できます。プロバイダーのソースコードは Business Source License 1.1 のもとで公開されています。 |
どちらが適しているか
コードは、プルリクエストで変更をレビューしているチームに適しています
どちらが合っているかは、テナントよりもチームによって決まります。誰が変更を加え、どこでレビューされるかが重要です。
TerraProvider が適しているケース
- チームがすでに Azure 向けに Terraform を書いており、プルリクエストでレビューしている。
- 条件付きアクセスの変更を本番に反映する前に、第三者によるレビューが必要である。
- テストと本番の設定を揃えておく必要があり、差異は可読な形で管理したい。
- 変更は誰かのブラウザからではなく、GitHub Actions または Azure DevOps のパイプラインから実行したい。
管理コンソールの方が適しているケース
- チームの誰も HCL を書かず、今後も書く予定がない。
- 変更はブラウザ上で行われており、チームもそのやり方を続けたいと考えている。
テナントチームと MSP
自社テナントにも顧客テナントにも、1つのプロバイダーで対応
自社テナントを運用するチームであれば、テストと本番を1つのモジュールにまとめられます。マネージドサービスプロバイダーであれば、顧客テナントごとに独自のプロバイダーブロックを設け、全テナントに同じベースラインモジュールを適用できます。テナント間の差異は、レビュアーが読める変数として明示されます。
- 自社テナント：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 から始めてください。