組織のガバナンス モデルを開発する場合は、Azure Resource Manager がリソースを管理する唯一の方法である点に注意することが重要です。 Azure DevOps および継続的インテグレーションと継続的デリバリー (CI/CD) の自動化は、適切に保護しないと、意図せずしてセキュリティのバックドアになる可能性があります。 これらのリソースは、Resource Manager に使用するロールベースのアクセス制御 (RBAC) モデルをミラー化して保護する必要があります。
End-to-end ガバナンスの概念は、ベンダーに依存しません。 ここで説明する実装では、Azure DevOps が使用されますが、代替方法も簡単に説明します。
考えられるユース ケース
このリファレンス実装とデモはオープン ソースであり、DevOps を初めて習得し、Azure にデプロイするためにガバナンス モデルを作成する必要がある組織の教育ツールとして使用されることを意図したものです。 このサンプル リポジトリで使用されるモデルの背後にある決定を理解するには、このシナリオをよくお読みください。
すべてのガバナンス モデルは、組織のビジネス ルールに結び付けられる必要があります。このルールは、アクセス制御の技術的な実装に反映されます。 このモデル例では、(ビジネス要件を含む) 次の一般的なシナリオを持つ架空の会社を使用します。
ビジネス ドメインおよびアクセス許可モデルに合わせて調整された Microsoft Entra グループ
この組織には、主に独立して機能する "果物" や "植物" など、多くの垂直ビジネス ドメインがあります。 各ビジネス ドメインには、2 つのレベル、または個別の*-adminsまたは*-devsMicrosoft Entra グループにマップされるアクセス許可があります。 これにより、クラウドでアクセス許可を構成するときに、開発者を対象にできます。デプロイ環境
すべてのチームに、次の 2 つの環境があります。- 運用。 管理者だけが昇格された特権を持っています。
- 実稼働環境ではない環境です。 すべての開発者は、(実験とイノベーションを促進するために) 昇格された特権を持っています。
オートメーションの目標
すべてのアプリケーションは、継続的インテグレーション (CI) だけでなく、継続的配置 (CD) 用にも Azure DevOps を実装する必要があります。 たとえば、Git リポジトリへの変更によってデプロイを自動的にトリガーできます。これまでのクラウド導入過程
この組織は、クラウドへの移行を加速するために、分離されたプロジェクト モデルから始めました。 しかし、現在、"コラボレーション" プロジェクトと "スーパーマーケット" プロジェクトを作成することで、サイロを打破してコラボレーションを促進する選択肢を探っています。
この簡略化された図は、Git リポジトリ内のブランチが開発、ステージング、および運用環境にマップされる方法を示しています。
このダイアグラムの SVG をダウンロードします。
アーキテクチャ
この図は、Resource Manager と CI/CD から Microsoft Entra ID へのリンクが、エンドツーエンドのガバナンス モデルを設ける鍵となる方法を示しています。
注意
概念を理解しやすくするために、この図は "veggies" ドメインのみを示しています。 "fruits" ドメインの外観は似ており、同じ名前付け規則を使用します。
ワークフロー
この番号は、IT 管理者とエンタープライズ アーキテクトがクラウド リソースについて考え、構成する順序を反映しています。
Microsoft Entra ID
ID 用の単一のプレーンを設けるために、Azure DevOps を Microsoft Entra ID に統合します。 つまり、開発者は、Azure DevOps と Resource Manager に同じ Microsoft Entra アカウントを使います。 ユーザーは個別には追加されません。 代わりに、Microsoft Entra グループによってメンバーシップが割り当てられるので、開発者の Microsoft Entra グループ メンバーシップを削除することで、1 つの手順で開発者のリソースへのアクセス権を削除できます。 ドメインごとに、次を作成します。
- Microsoft Entra グループ。 ドメインごとに 2 つのグループ (この記事の後半の手順 4 と 5 でさらに説明します)。
- サービス プリンシパル。 環境ごとに 1 つの明示的なサービス プリンシパル。
運用環境
デプロイを簡略化するために、この参照実装では、リソース グループを使用して、運用環境を表します。 実際には、別のサブスクリプションを使用する必要があります。
この環境への特権アクセスは、管理者のみに制限されます。
開発環境
デプロイを簡略化するために、この参照実装では、リソース グループを使用して、開発環境を表します。 実際には、別のサブスクリプションを使用する必要があります。
Resource Manager でのロールの割り当て
Microsoft Entra グループ名は、ロールを示しますが、ロールの割り当てが構成されるまでは、アクセスの制御は適用されません。 これにより、特定のスコープの Microsoft Entra プリンシパルにロールが割り当てられます。 たとえば、開発者は、運用環境で共同作成者ロールを持っています。
Microsoft Entra プリンシパル 開発環境 (Resource Manager) 運用環境 (Resource Manager) veggies-devs-group[所有者] Reader veggies-admins-group所有者 所有者 veggies-ci-dev-sp"カスタム ロール" * — veggies-ci-prod-sp— "カスタム ロール" * * デプロイを簡略化するために、この参照実装では、"所有者"
Ownerロールをサービス プリンシパルに割り当てています。 ただし、運用環境では、リソースに対して設定する管理ロックをサービス プリンシパルが削除するのを防ぐカスタム ロールを作成する必要があります。 これにより、データベースの削除など、偶発的な破損からリソースを保護できます。個々のロールの割り当ての背後にある理由を理解するには、この記事の後半の「考慮事項」の項を参照してください。
Azure DevOps でのセキュリティ グループの割り当て
セキュリティ グループは、Resource Manager のロールと同様に機能します。 組み込みロールを利用し、開発者向けのデフォルトの共同作成者に設定します。 管理者は、昇格された権限のためにプロジェクト管理者セキュリティ グループに割り当てられるため、セキュリティ アクセス許可を構成できます。
Azure DevOps と Resource Manager に異なるアクセス許可モデルがある点に注意してください。
- Azure Resource Manager は、追加のアクセス許可モデルを使用します。
- Azure DevOps は、権限モデル最も少ないアクセス許可モデルを使用します。
このため、
-adminsグループと-devsグループのメンバーシップは相互に排他的である必要があります。 それ以外の場合、影響を受けるユーザーのアクセス権は、Azure DevOps で予期される数よりも、少ないアクセス権を持ちます。グループ名 Resource Manager ロール Azure DevOps ロール fruits-all— — fruits-devsContributor Contributor fruits-admins所有者 プロジェクト管理者 veggies-all— — veggies-devsContributor Contributor veggies-admins所有者 プロジェクト管理者 infra-all— — infra-devsContributor Contributor infra-admins所有者 プロジェクト管理者 制限されたコラボレーションのシナリオでは、fruits チームは単一のリポジトリで共同作業するために veggies チームを招待し、このチームは
veggies-allグループを使用します。個々のロールの割り当ての背後にある理由を理解するには、この記事の後半の「考慮事項」の項を参照してください。
サービス接続
Azure DevOps では、サービス接続は資格情報をラップする汎用ラッパーです。 サービス プリンシパルのクライアント ID とクライアント シークレットを保持するサービス接続を作成します。 プロジェクト管理者は、必要に応じて、この保護されたリソースへのアクセスを構成できます。デプロイ前にユーザーの承認を要求する場合です。 この参照アーキテクチャには、サービス接続に対する次の 2 つの最小限の保護があります。
- 管理者は、どのパイプラインが資格情報にアクセスできるかを制御するためのパイプライン アクセス許可を構成する必要があります。
- 管理者は、ブランチ コントロール チェックも構成し、
productionブランチのコンテキストで実行されているパイプラインのみが、prod-connectionを使用できるようにする必要があります。
Git リポジトリ
サービス接続はブランチ コントロールを介してブランチに関連付けられるため、Git リポジトリへのアクセス許可を構成し、ブランチ ポリシーを適用することが重要です。 また、CI ビルドが合格することを要求するだけでなく、pull request が少なくとも 2 人の承認者を持つことを要求します。
Components
代替
End-to-end ガバナンスの概念は、ベンダーに依存しません。 この記事では Azure DevOps に焦点を当てていますが、Azure DevOps Server をオンプレミスでの代替として使用できます。 または、Jenkins と GitLab などのオプションを使用するオープンソース CI/CD 開発パイプライン用の一連のテクノロジを使用することもできます。
Azure Repos と GitHub はどちらも、オープンソースの Git バージョン管理システムを使用するように構築されたプラットフォームです。 機能セットは多少異なりますが、どちらも CI/CD のグローバル ガバナンス モデルに統合できます。 GitLab は、堅牢な CI/CD 機能を提供するもう 1 つの Git ベースのプラットフォームです。
このシナリオでは、Terraform をコードとしてのインフラストラクチャ (IaC) ツールとして使用します。 代替手段として、Jenkins、Ansible、Chef などがあります。
考慮事項
Azure でのエンドツーエンドのガバナンスを実現するには、開発者のコンピューターから運用環境へのパスのセキュリティとアクセス許可のプロファイルについて理解しておくことが重要です。 次の図は、Azure DevOps を持つベースライン CI/CD ワークフローを示しています。 赤いロック アイコン 
は、ユーザーが構成する必要があるセキュリティ アクセス許可を示します。 アクセス許可を構成しない場合、または構成を誤った場合は、ワークロードが脆弱になります。
このワークフローの SVG をダウンロードします。
ワークロードを正常にセキュリティで保護するには、ワークフローでセキュリティ アクセス許可の構成と人的な確認を組み合わせて使用する必要があります。 すべての RBAC モデルは、パイプラインとコードの両方にも拡張する必要があることが重要です。 多くの場合、これらは特権 ID で実行され、命じられた場合はワークロードを破棄します。 これが行われないようにするには、リポジトリでブランチ ポリシーを構成して、オートメーション パイプラインをトリガーする変更を受け入れる前に、人的な承認を要求するように設定する必要があります。
| デプロイ ステージ | 担当 | 説明 |
|---|---|---|
| Pull requests | User | エンジニアは、パイプライン コード自体を含めて、自分達の作業内容をピア レビューする必要があります。 |
| ブランチ保護 | Shared | CI チェックやピア レビュー (pull request による) など、特定の標準を満たしていない変更を拒否するように、Azure DevOps を構成します。 |
| コードとしてのパイプライン | User | ビルド サーバーは、パイプライン コードによって指示された場合、運用環境全体を削除します。 これを回避するには、pull request とブランチ保護ルール (人的な承認など) を組み合わせて使用します。 |
| サービス接続 | Shared | これらの資格情報へのアクセスを制限するように Azure DevOps を構成します。 |
| [Azure リソース] | Shared | Azure Resource Manager で RBAC を構成します。 |
ガバナンス モデルを設計する際は、次の概念と質問を考慮することが重要です。 この例の組織で考えられるユース ケースを念頭に置いてください。
1. ブランチ ポリシーを使用した環境の保護
ソース コードはデプロイを定義してトリガーするため、最初の防御策は、ソース コード管理 (SCM) リポジトリをセキュリティで保護することです。 具体的には、pull request ワークフローをブランチ ポリシーと組み合わせて使用し、これらによってコードを受け入れる前にチェックと要件を定義します。
エンドツーエンドのガバナンス モデルを計画するときは、特権ユーザー (veggies-admins) が、ブランチ保護の構成の責任を持ちます。 デプロイをセキュリティで保護するために使用される一般的なブランチ保護チェックには、次のようなものがあります。
CI ビルドが合格することを要求します。 コード リンティング、単体テスト、さらにはウイルスや資格情報のスキャンのようなセキュリティ チェックなど、ベースライン コードの品質を確立するために役立ちます。
ピア レビューを要求します。 コードが意図したとおりに動作することを、別の人がダブル チェックします。 パイプライン コードに変更が加えられた場合は、特別に注意を払う必要があります。 CI ビルドと組み合わせることにより、ピア レビューの手間を減らします。
開発者が運用環境に直接プッシュしようとしたらどうなるでしょうか。
Git は、分散 SCM システムであることに注意してください。 開発者は、自分のローカル production ブランチに直接コミットできます。 ただし、Git が適切に構成されている場合、このようなプッシュは Git サーバーによって自動的に拒否されます。 次に例を示します。
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'
この例のワークフローはベンダーに依存しないことに注意してください。 pull request とブランチ保護機能は、Azure Repos、GitHub、GitLab など、複数の SCM プロバイダーから入手できます。
コードが保護されたブランチに受け入れられると、ビルド サーバー (Azure Pipelines など) によって次のアクセス制御レイヤーが適用されます。
2. セキュリティ プリンシパルに必要なアクセス権
Azure では、セキュリティ プリンシパルは、"ユーザー プリンシパル" または "ヘッドレス プリンシパル" (サービス プリンシパルまたはマネージド ID など) のいずれかになります。 すべての環境では、セキュリティ プリンシパルは最小の特権のプリンシパルに従う必要があります。 セキュリティ プリンシパルには、運用前環境での拡張アクセスが与えられる場合がありますが、運用 Azure 環境では、Just-In-Time (JIT) アクセスと Microsoft Entra 条件付きアクセスを与えることで、継続的なアクセス許可を最小限に抑える必要があります。 ユーザー プリンシパルに対する Azure RBAC ロールの割り当てを作成して、これらの最小の特権のプリンシパルと整合させることができます。
また、Azure RBAC を Azure DevOps RBAC とは区別してモデル化することも重要です。 パイプラインの目的は、Azure への直接アクセスを最小限に抑えることです。 イノベーション、学習、問題解決などの特別なケースを除き、Azure とのほとんどのやり取りは、目的別のゲート付きパイプラインを使用して行う必要があります。
Azure パイプライン サービス プリンシパルについては、カスタム ロールを使用することを検討してください。これにより、リソースのロックが削除や、目的外の重大な操作の実行から保護できます。
3. 運用環境へのアクセスに使用されるサービス プリンシパルのためのカスタム ロールの作成
CI/CD ビルド エージェントに所有者ロールとアクセス許可を付与するのは、よくある間違いです。 パイプラインで ID ロールの割り当てや、Azure Key Vault ポリシー管理などの他の特権操作を実行する必要がある場合は、共同作成者のアクセス許可では不十分です。
ただし、CI/CD ビルド エージェントは、そのように指示された場合、運用環境全体を削除します。 元に戻せない重大変更が実行されるのを回避するために、次のようなカスタム ロールを作成します。
- Key Vault アクセス ポリシーの削除
- リソースが削除されないように設計された (規制対象業界で一般的な要件) 管理ロックを削除します。
これを行うには、カスタム ロールを作成し、Microsoft.Authorization/*/Delete アクションを削除します。
{
"Name": "Headless Owner",
"Description": "Can manage infrastructure.",
"actions": [
"*"
],
"notActions": [
"Microsoft.Authorization/*/Delete"
],
"AssignableScopes": [
"/subscriptions/{subscriptionId1}",
"/subscriptions/{subscriptionId2}",
"/providers/Microsoft.Management/managementGroups/{groupId1}"
]
}
こうすることで、自分の用途に必要なアクセス許可が削除されすぎる場合は、Azure リソース プロバイダー操作に関する公式ドキュメントの完全な一覧を参照し、必要に応じてロールの定義を調整してください。
このシナリオのデプロイ
このシナリオは、Resource Manager の範囲以外に及びます。 これが、Terraform を使う理由です。これにより、コード ツールとして単一のインフラストラクチャを使って Microsoft Entra ID とブートストラップ Azure DevOps にもプリンシパルを作成できます。
ソース コードと詳細な手順については、GitHub リポジトリの Azure でのガバナンス デモ - DevOps から ARM へに関する記事を参照してください。
価格
Azure DevOps のコストは、アクセスを必要とする組織内のユーザーの数だけでなく、必要な同時実行ビルド/リリースの数やユーザーの数など、他の要因にも依存します。 Azure Repos と Azure Pipelines は、Azure DevOps サービスの機能です。 詳しくは、「Azure DevOps の料金」をご覧ください。
Microsoft Entra ID では、このシナリオに必要なグループ アクセス管理の種類は、Premium P1 および Premium P2 の各エディションで提供されています。 これらのサービス レベルの価格は、ユーザーごとに計算されます。 詳細については、Microsoft Entra の価格に関する記事を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Julie Ng |シニア サービス エンジニア
次のステップ
- このシナリオのコード リポジトリについては、Azure でのガバナンス デモ - DevOps から ARM へに関する記事を参照してください。
- クラウド導入フレームワークのクラウド ガバナンス ガイドを参照してください。
- Azure ロールベースのアクセス制御 (Azure RBAC) とは
- クラウド導入フレームワーク:Azure でのリソース アクセス管理
- Azure Resource Manager のロール
- Azure DevOps セキュリティ グループ