Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
アクセス制御、プル要求ポリシー、および最も重要なブランチの状態チェックを組み合わせて、Azure Reposをセキュリティで保護します。 この記事では、プル要求のマージ前に、直接変更を制限し、適切なレビュー担当者を要求し、作業項目とビルドの要件を適用し、GitHub高度なセキュリティ チェックを追加する方法について説明します。
Tip
この記事の後半でAI を使用してこのタスクに役立てる方法をご説明します。または、Azure DevOps MCP Server で AI サポートを有効にする方法を参照して作業を開始できます。
脅威とコントロール
次のコントロールをまとめて使用して、最も一般的なプル要求リスクを軽減します。
| 脅威 | リスク | 推奨されるコントロール |
|---|---|---|
| 保護されたブランチへの直接プッシュ | レビューと検証を回避する変更 | ブランチのアクセス許可 と ブランチ ポリシー |
| 1 人の承認 | レビュー品質は 1 人のユーザーによって異なります | 最小限のレビュー担当者が必要です |
| 機密性の高いファイルに関する専門家によるレビューがありません | セキュリティクリティカルな変更は、適切なレビュー担当者なしでマージされます | 自動的に追加されるレビュー担当者 |
| 追跡されていないコードの変更 | 監査性の低下と変更の追跡可能性 | リンクされた作業項目を確認します |
| コードの破損または未テスト | 回帰が共有ブランチに到達する | ビルドの検証 |
| 未解決のレビュー フィードバック | 既知の問題が応答なしでマージされる | コメント解決の有無を確認する |
| 新しい高または重大な脆弱性 | プル リクエストを通じてセキュリティ リグレッションがマージされる | GitHub Advanced Security のステータス チェック |
Prerequisites
| カテゴリ | 要件 |
|---|---|
| プロジェクトへのアクセス権 | プロジェクトのメンバー。 |
| Permissions | - プライベート プロジェクトでコードを表示する: 少なくとも Basic アクセス。 - プライベート プロジェクトのコードを複製または投稿する: 共同作成者 セキュリティ グループのメンバー、またはプロジェクト内の対応するアクセス許可。 - ブランチまたはリポジトリのアクセス許可を設定する: ブランチまたはリポジトリの アクセス許可を管理 します。 - ブランチ ポリシーの設定、状態チェック、または既定のブランチの変更: リポジトリまたはブランチのポリシーアクセス許可、またはProject Administrators セキュリティ グループのメンバーシップを編集します。 - リポジトリのインポート: プロジェクト管理者 セキュリティ グループのメンバーまたは Git プロジェクト レベルでリポジトリの作成アクセス許可が許可に設定された場合。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。 |
| Services | リポジトリが有効になっています。 |
| Tools | Optional.
az reposコマンドを使用する: Azure DevOps CLI。 |
| カテゴリ | 要件 |
|---|---|
| プロジェクトへのアクセス権 | プロジェクトのメンバー。 |
| Permissions | - コードの表示: 基本 アクセスが最低限必要です。 - コードを複製または投稿する: 共同編集者のセキュリティ グループのメンバー、またはプロジェクト内の対応する権限が必要です。 |
| Services | リポジトリが有効になっています。 |
ブランチ ポリシーを構成する前に、次の手順を実行します。
- ターゲット リポジトリとブランチが既に存在することを確認します。
- アクセス許可の管理、ポリシーのバイパス、プル要求の承認を行うことができるグループを決定します。
- ビルドの検証または GitHub Advanced Security の状態チェックを必須にする予定がある場合は、先にビルド パイプラインを作成してください。
ほとんどのチームのセキュリティ ベースライン
mainなどの一般的な運用ブランチの場合は、次のベースラインから始めます。
| 制御領域 | 推奨されるベースライン | なぜでしょうか |
|---|---|---|
| リポジトリへのアクセス | リポジトリでアクティブに作業する共同作成者への書き込みアクセスを制限する | ソース コードまたはリポジトリの設定を変更できる ID の数を減らします。 |
| 分岐アクセス許可 | プル要求を完了するときにバイパス ポリシーを制限し、小規模な管理者グループにプッシュするときにポリシーをバイパスする | ユーザーが必要なレビュー、検証、およびその他のブランチ保護をスキップできないようにします。 |
| ポリシーを確認する | に少なくとも 2 人のレビュー担当者を要求する main |
レビューの品質を向上させ、単一の誤った承認または偏った承認のリスクを軽減します。 |
| 機密性の高いファイル | セキュリティ、インフラストラクチャ、またはコンプライアンスに依存するパスのレビュー担当者を自動的に含める | リスクの高い領域への変更が、適切なユーザーまたはチームからレビューを受けられるようにします。 |
| 追跡可能性 | [リンクされた作業項目の確認] をオンにする | コードの変更と、それらを正当化した作業の間に監査証跡を保持します。 |
| Validation | PR ブランチの ビルド検証 を追加する | コードが保護されたブランチにマージされる前に、ビルドとテストの失敗をキャッチします。 |
| 完了を確認する | [コメントの解決を確認する] をオンにする | 校閲者の懸念事項が完了前に対処されるようにするのに役立ちます。 |
| 脆弱性ゲート | セキュリティ強化スキャンの構成後に AdvancedSecurity/NewHighAndCritical を追加する |
重大度が高または重大な新しいセキュリティ検出結果を追加するプル リクエストをブロックします。 |
手順 1: リポジトリとブランチのアクセスを制限する
アクセス許可から始めます。 ポリシーは、少数のユーザーのみがそれらをバイパスできる場合に最も効果的です。
リポジトリのアクセス許可を確認する
リポジトリのアクセス許可を使用して、設定の読み取り、投稿、管理、またはプル要求への投稿を行うことができるユーザーを制御します。 アクセス許可の詳細なリファレンスについては、「 Git リポジトリのアクセス許可を設定する」を参照してください。
次のパターンを使用します。
- 共同作成者に、機能ブランチで作業するために必要なアクセス許可を付与します。
- 小規模な管理グループのリポジトリ管理を予約します。
- ポリシーをバイパスする権限を広範に付与することは避けてください。
ブランチのアクセス許可を制限する
保護されたブランチの場合は、これらのアクセス許可を慎重に確認して制限します。
- pull request の完了時にポリシーをバイパスする
- プッシュ時にポリシーをバイパスする
- 強制プッシュ (履歴の書き換えとブランチおよびタグの削除)
- ポリシーを編集する
- アクセス許可の管理
[ブランチのアクセス許可の設定] を使用して、これらの設定を構成します。
mainに推奨されるパターン:
| グループ | 推奨ブランチ権限 |
|---|---|
| 貢献者 | プル要求を通じて定期的な投稿を許可するが、バイパスアクセス許可は付与しない |
| プロジェクト管理者 | ポリシーの編集とアクセス許可の管理を許可する |
| 緊急リリースの担当者 | インシデント プロセスで必要な場合にのみバイパスアクセス許可を付与する |
Important
プル要求を完了するときにバイパス ポリシーを保持し、信頼できる少数の管理者に限定してプッシュする場合はバイパス ポリシーを保持します。 これらのアクセス許可は、必要なレビュー担当者、検証、および状態チェックによって作成された保護を破ります。
手順 2: 強力な pull request レビューを要求する
レビュー担当者の最少数を要求する
main やリリース ブランチなどの重要なブランチで 最小レビュアー数を必須にする を使用します。
推奨される設定:
- 最小レビュアー数:
2重要な共有ブランチ向け - 最後のイテレーションで少なくとも 1 つの承認を要求する
-
要求者が自分の変更を承認できるようにする:
Off -
直前にプッシュしたユーザーが自分の変更を承認できないようにする:
On職務分掌をより厳格にしたい場合
レビュー担当者の最小ポリシーを構成する
- Project設定>Repositories に移動します。
- リポジトリを選択し、保護されたブランチを選択します。
- [ ポリシー] で、[ レビュー担当者の最小数を要求する] をオンにします。
- ブランチの校閲者オプションを設定します。
結果を確認します。
- ブランチ ポリシーの一覧には、レビュー担当者ポリシーが有効として表示されます。
- 必要な数の承認が得られるまで、そのブランチへのプル リクエストは完了できません。
ポリシーの詳細については、「 ブランチポリシーと設定」を参照してください。
機密性の高いファイルの校閲者を自動的に含める
特定のファイルまたはフォルダーで特定のユーザーまたはチームからの承認が必要な場合は、 自動的に含まれるレビュー担当者 を使用します。
適切な候補は次のとおりです。
- デプロイメントとインフラストラクチャコード
- 認証と承認コード
- コンプライアンスに依存するフォルダー
- 共有パイプライン テンプレート
自動的に含まれるレビュー担当者ポリシーを構成する
- Project設定>Repositories に移動します。
- ブランチ ポリシーでターゲット ブランチ を開きます。
- 自動的に含まれるレビュアー ポリシーを追加します。
- 必要なユーザーまたはグループを追加します。
- ポリシーが 必須 かオプションかを選択 します。
- レビューが必要なファイルまたはフォルダーのパス フィルターを追加します。
- 要求元が自分自身の変更を承認することを許可しません。
結果を確認します。
- 一致するファイルを変更するプル要求では、構成済みのレビュー担当者が自動的に追加されます。
- pull request は、必要なレビュー担当者ポリシーが満たされるまで完了できません。
詳細については、「 コード レビュー担当者を自動的に含める」を参照してください。
手順 3: 追跡可能性と検証を適用する
リンクされた作業項目を確認する
チームがプル要求と作業追跡の間で追跡可能性を変更する必要がある場合は、[ リンクされた作業項目を確認 する] をオンにします。
リンクされた作業項目ポリシーを構成する
- Project設定>Repositories に移動します。
- ブランチ ポリシーでターゲット ブランチ を開きます。
- [ リンクされた作業項目のチェック] をオンにします。
- 完了前に pull requests にリンクされた作業項目が必要な場合は、[ 必須] を選択します。
結果を確認します。リンクされた作業項目のないプル要求では、ポリシーが満たされていないと表示されます。
詳細については、「 リンクされた作業項目のチェック」を参照してください。
ビルドの検証
ビルド検証を使用して、マージ前にプル要求に対してパイプラインの実行を成功させる必要があります。
Important
ビルド検証を構成する前に、プル要求を検証する必要があるビルド パイプラインを作成します。
保護ブランチの推奨設定:
- トリガー: 自動
-
ポリシー要件:
Required - ビルドの有効期限: 保護されたブランチが変更される頻度に一致する値を選択します
ビルド検証ポリシーを構成する
- ブランチ ポリシーでターゲット ブランチ を開きます。
- ビルド検証ポリシーを追加します。
- ビルド パイプラインを選択します。
- ポリシーが必要かどうかを選択します。
- ポリシーを保存します。
結果を確認します。
- プル要求キューを開くか更新すると、構成された検証ビルドがキューに格納されます。
- pull request は、必要なビルドが成功するまで完了できません。
詳細については、「 ビルドの検証」を参照してください。
コメント解決の有無を確認する
pull request が完了する前にレビュー スレッドが解決されていることを確認するには、 コメント解決のチェック を使用します。
コメント解決ポリシーを構成する
- ブランチ ポリシーでターゲット ブランチ を開きます。
- [ コメントの解決を確認する] をオンにします。
- 未解決のコメントが完了をブロックする必要がある場合は、[ 必須] を選択します。
結果を確認する: 未解決のコメントを含むプル要求は、レビュー担当者または作成者がスレッドを解決するまでブロックされた状態を維持します。
詳細については、「 コメント解決の確認」を参照してください。
マージの種類を制限する
マージの種類を制限をリポジトリ履歴のガバナンス設定として使用します。 このポリシーは、マージ後のプル要求コミットの表示方法を標準化するのに役立ちますが、直接セキュリティ制御ではありません。
チームが履歴をレビュー、トレース、監査する方法に基づいてマージ戦略を選択します。
使用例:
- 短期間の機能開発ではスカッシュ マージを必須にします。
- 監査プロセスでマージ コミットが想定されているブランチに対して、リベースまたはスカッシュを禁止します。
監査と追跡の考慮事項:
- スカッシュは、よりクリーンなターゲットブランチ履歴を作成しますが、マージ時に複数のソースコミットを1つのコミットに折りたたみます。
- 監査モデルが機能ブランチからの正確なコミット シーケンスを保持することに依存している場合は、スカッシュよりもマージ コミット戦略を優先します。
- ポリシーは、開発者が pull request とターゲット ブランチの履歴を検査およびデバッグする方法と一貫性を保ちます。
AZURE DEVOPS CLI の例:
az repos policy merge-strategy create \
--blocking true \
--branch main \
--enabled true \
--repository-id <repository-id> \
--allow-no-fast-forward true \
--allow-rebase false \
--allow-rebase-merge false \
--allow-squash false
詳細については、「 マージの種類を制限する」を参照してください。
手順 4: GitHub Advanced Security のステータス チェックを追加する
GitHub高度なセキュリティ状態チェックは、新しい重大な脆弱性または重大度の高い脆弱性が導入されたときにプル要求がマージされないようにするのに役立ちます。
Important
GitHub advanced Security for Azure DevOps は、Azure DevOps サービスでのみ使用でき、コード Git リポジトリでのみ使用できます。
状態チェック ポリシーを追加する前に、次の手順を実行します。
- リポジトリGitHub Advanced Security を有効にします。
- 必要な高度なセキュリティ パイプライン タスクを構成します。
- pull request ブランチの ビルド検証 ポリシーを追加します。
- 文書化された高度なセキュリティ タスクの
Wait for Processing: trueを有効にします。 - パイプラインを少なくとも 1 回正常に実行して、状態チェックが [状態] の一覧に表示されるようにします。
リポジトリに未解決のアラートが既に存在する場合は、 AdvancedSecurity/NewHighAndCritical から始めます。 バックログを減らしたら、 AdvancedSecurity/AllHighAndCriticalに移行することを検討してください。
ブラウザーのパス:
- ブランチ ポリシーでターゲット ブランチ を開きます。
- [ 状態チェック] で、[ +] を選択します。
-
確認対象ステータスを
AdvancedSecurity/NewHighAndCriticalに設定します。 - [詳細オプション] は既定値のままにします。
- ポリシーを保存します。
高度なセキュリティの状態チェックは、リポジトリの高度なセキュリティ スキャンとビルド検証を有効にした後、ブラウザーの 状態チェック から構成されます。 必要なセットアップについては、「 プル要求の状態チェックを設定する」を参照してください。
結果を確認します。
- 新しい高値または重大な結果を含むプル要求では、状態チェックが失敗として表示されます。
- 分岐ポリシーは、結果が解決されるか、ポリシーが省略可能になるまで、完了をブロックします。
セットアップの詳細については、次を参照してください。
ロールアウト 計画の例
機密性の低いリポジトリベースライン
リポジトリの感度が低く、管理しやすい開始点が必要な場合:
-
mainでブランチ バイパスのアクセス許可を制限します。 - 少なくとも 1 人または 2 人の校閲者が必要です。
- リンクされた作業項目を有効にします。
- ビルド検証を追加します。
- コメント解決を有効にします。
高感度リポジトリ
リポジトリにデプロイ、ID、またはコンプライアンスクリティカルな資産が含まれている場合:
- ポリシー バイパスのアクセス許可を管理者に制限します。
-
mainに 2 人の校閲者が必要です。 - 保護されたパスのレビュー担当者を自動的に追加します。
- リンクされた作業項目が必要です。
- ビルド検証を追加します。
- Azure DevOps Services を使用している場合は、GitHub Advanced Security のステータス チェックを追加します。
省略可能: AI アシスタンスを使用してブランチ ポリシーの構成を確認する
AI の支援は省略可能です。 ブランチのアクセス許可、ポリシー、状態チェックでは、AI を使用するかどうかに関係なく、リポジトリの保護が適用されます。
これらのプロンプトを使用して、ポリシー構成の確認、ギャップの特定、ベースラインの推奨事項の迅速な取得を行うことができます。 MCP サーバー Azure DevOps構成した場合、アシスタントはAzure DevOpsコンテキストを使用して回答を改善できます。 セットアップ ガイダンスについては、「Azure DevOps MCP Server で AI サポートを有効にする」を参照してください。
開始するには、次のようなプロンプトを使用します。
| ゴール | プロンプトの例 |
|---|---|
| ブランチ保護を確認する | Summarize the branch policies on main and explain which ones are required. |
| バイパス リスクを特定する | Find users or groups that can bypass branch policies on the main branch. |
| レビューの対象範囲を確認する | List the reviewer and comment-resolution policies configured for this repository. |
| 作業の追跡を確認する | Check whether pull requests into main require linked work items. |
| 検証ゲートを検査する | Show the build validation policy for main and explain what pipeline it uses. |
| セキュリティの状態チェックを調査する | List the status checks configured for main and tell me whether GitHub Advanced Security is one of them. |
| より安全なベースラインを計画する | Recommend a secure branch policy baseline for this repository based on its current settings. |
リポジトリのアクセス許可、ブランチ設定、および現在のAzure DevOpsドキュメントに対して生成されたコマンドと推奨事項を常に検証してから、それらを適用してください。
トラブルシューティングのヒント
| 問題 | 考えられる原因 | 推奨されるアクション |
|---|---|---|
| ブランチ ポリシー オプションが表示されない | ポリシーの編集アクセス許可がない、またはブランチが選択されていない | ブランチへのアクセス権とポリシー権限を確認する |
| ポリシーを満たしていなくても、プル リクエストはマージできます | ユーザーがバイパスアクセス許可を持っている | プル要求を完了するときにバイパス ポリシーを確認し、プッシュ時にポリシーをバイパスする |
| 必須の校閲者は追加されません | レビュー担当者ポリシー パス フィルターが変更されたファイルと一致しない | パス フィルターとレビュー担当者 ID を再確認する |
| セキュリティの状態の詳細チェックは使用できません | リポジトリは、必要なタスクでスキャンの実行が正常に完了していません | ビルド検証、パイプライン タスク、および Wait for Processing 設定を確認する |
| リンクされた作業項目のポリシーはブロックしない | ポリシーは必須ではなく省略可能です | ブランチ ポリシーをもう一度開き、要件レベルを確認します |