DevOps ツールのロールベースのアクセス制御
インフラストラクチャのデプロイ用にクラウドベースのソリューションをデプロイする場合、セキュリティは常に最も重要な懸念事項です。 Microsoft では、基になるクラウド インフラストラクチャのセキュリティを保護します。 ユーザーは Azure DevOps または GitHub でセキュリティを構成します。
前提条件
デプロイする Azure ランディング ゾーン テンプレートを決定したら、それらを独自のリポジトリに複製します。 CI/CD パイプラインを設定します。 個人用アクセス トークン (PAT)、ID プロバイダー (Microsoft Entra ID など) との統合のように、GitHub と Azure DevOps の両方に使用できる認証方法はいくつかあります。 詳細については、「個人用アクセス トークンの使用」を参照してください。
すべての機能を使用するには、Microsoft Entra ID と統合することをお勧めします。 統合は、ロールの割り当てプロセスと ID ライフサイクル管理を効率化するのに役立ちます。 詳細については、「Microsoft Entra ID に組織を接続する」を参照してください。 GitHub を使用している場合は、GitHub Enterprise と Microsoft Entra ID の統合を検討してください。
設計に関する一般的な考慮事項
Microsoft Entra ID と DevOps ツール全体で管理者とサービス アカウント グループを厳密に制御することをお勧めします。 すべてのロールの割り当てに対して最小特権の原則を実装することを検討してください。
たとえば、組織には、Azure ランディング ゾーン用の Azure Resource Manager テンプレートを維持するプラットフォームまたはクラウド エクセレンス チームが存在する場合があります。 これを ID プロバイダーとして使用していることを前提として、そのチームのユーザーを Microsoft Entra ID のセキュリティ グループに割り当てます。 DevOps ツールでそのセキュリティ グループにロールを割り当てて、それらのユーザーが自分のジョブを実行できるようにします。
Active Directory の管理者アカウントまたは高い特権を持つアカウントの場合は、Microsoft Entra ID への資格情報の同期や、その逆を行わないことをお勧めします。 このアプローチにより、侵入の拡大の脅威が軽減されます。 Microsoft Entra ID の管理者が侵害された場合に、攻撃者は Azure DevOps などのクラウド資産に簡単にアクセスできなくなります。 そのアカウントは、CI/CD パイプラインに悪意のあるタスクを挿入できません。 この手順は、DevOps 環境内で昇格されたアクセス許可で割り当てられたユーザー (ビルド管理者またはプロジェクト コレクション管理者など) にとって特に重要です。 詳細については、Microsoft Entra ID のセキュリティのベスト プラクティスに関する記事を参照してください。
Azure DevOps のロールベースのアクセスに関する考慮事項
組織/コレクション、プロジェクト、またはオブジェクト レベルでセキュリティ グループ、ポリシー、設定を使用して、Azure DevOps のセキュリティを管理します。 Microsoft Entra ID などの ID プロバイダーと統合するには、条件付きアクセス ポリシーを作成して、すべてのユーザーに多要素認証を適用することを検討してください。 これらのポリシーにより、Azure DevOps 組織へのアクセスと、IP アドレス、アクセスに使用されるデバイスの種類、デバイスのコンプライアンスに基づくより細かい制限が可能になります。
Azure ランディング ゾーンを管理するプラットフォーム チームのほとんどのチーム メンバーの場合、Basic アクセス レベルと "共同作成者" の既定のセキュリティ グループで、十分なアクセス権限が提供されます。 共同作成者セキュリティ グループを使用すると、リポジトリ内の Azure ランディング ゾーン テンプレートと、それらを検証してデプロイする CI/CD パイプラインを編集できます。
Azure DevOps のプロジェクト レベルで共同作成者セキュリティ グループにプラットフォーム チームを割り当てることをお勧めします。 このアプローチは最小限の特権の原則に従ったものです。 これらの割り当ては、次に示す [プロジェクトの設定] ページで実行できます。
Azure DevOps Projects と組織のためのもう 1 つのベスト プラクティスは、可能な限り継承を無効にすることです。 ユーザーは、セキュリティ グループの割り当てによって許可されるアクセス許可を継承します。 既定で許可される継承の性質上、予期しないユーザーがアクセス権限またはアクセス許可を取得できます。
たとえば、プラットフォーム チームの共同作成者のセキュリティ グループ メンバーシップを割り当てる場合は、Azure ランディング ゾーン リポジトリに対するアクセス許可を確認します。 セキュリティ グループではプル要求中にこれらのポリシーをバイパスできないことを確認するには、ブランチ ポリシーを用意する必要があります。 [プロジェクトの設定]>[リポジトリ] でこの設定を確認します。
ユーザーにアクセス許可を割り当てた後、監査イベントを定期的に確認して、管理者や他のユーザーによる予期しない使用パターンを監視し、対応します。 まず、Log Analytics ワークスペースへの監査ストリームを作成します。 ワークスペースで Microsoft Sentinel を使用している場合は、分析ルールを作成して、アクセス許可の不適切な使用など、注目すべきイベントについてアラートを生成します。
詳細については、次のリソースを参照してください。
GitHub のロールベースのアクセスに関する考慮事項
プライマリ DevOps ツールが GitHub の場合は、リポジトリ レベル、チーム レベル、または組織レベルでロールを付与することで、リソースへのアクセス権をユーザーに割り当てることができます。 Azure ランディング ゾーン リポジトリをフォークし、Microsoft Entra ID などの ID プロバイダーと統合したら、GitHub でチームを作成することを検討してください。 そのチームに、新しい Azure ランディング ゾーン リポジトリへの "書き込み" アクセス権を割り当てます。 ランディング ゾーンを変更してデプロイするプラットフォーム チーム メンバーのほとんどは、書き込みアクセスで十分です。 チームのプロジェクト マネージャーまたはスクラム マネージャーの場合は、そのリポジトリの "保守" ロールを割り当てる必要がある場合もあります。
これらのロールの割り当てはすべて、統合 ID プロバイダーを使用して管理することをお勧めします。 たとえば、GitHub で作成した Azure ランディング ゾーン リポジトリのプラットフォーム チームを、Microsoft Entra ID の対応するプラットフォーム チーム セキュリティ グループと同期できます。 その後、Microsoft Entra セキュリティ グループにメンバーを追加または削除すると、それらの変更が GitHub Enterprise Cloud のロールの割り当てに反映されます。
Note
特定の GitHub チームを統合 ID プロバイダーに接続すると、それを介したチーム メンバーシップの管理に制限されます。
次の手順
GitHub でのロールとチームの管理の詳細については、次のリソースを参照してください。