次の方法で共有

セキュリティの運用方法

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

特にAzure DevOps Servicesなどのクラウドベースのソリューションで情報とデータを操作する場合は、常にセキュリティの優先順位を付ける必要があります。 Microsoft は基になるクラウド インフラストラクチャのセキュリティを維持しますが、Azure DevOps でセキュリティを構成するのはお客様の責任です。

必須ではありませんが、Azure DevOps を使用しながらベスト プラクティスを組み込むことで、エクスペリエンスを向上させ、より安全にすることができます。 次のベスト プラクティスは、Azure DevOps 環境のセキュリティを維持することを目的としています。

Azure DevOps 環境をセキュリティで保護する

ユーザーの削除

  • organizationで MSA アカウントを使用している場合は、アクセスを防ぐ他の方法がないため、非アクティブなユーザーをorganizationから直接削除します。 その場合、削除されたユーザー アカウントに割り当てられた作業項目のクエリを作成することはできません。 詳細については、「 Azure DevOps からユーザーを削除する」を参照してください。
  • 組織が Microsoft Entra ID に接続されている場合は、Microsoft Entra ユーザー アカウントを無効または削除し、Azure DevOps ユーザー アカウントをアクティブのままにすることができます。 この方法では、Azure DevOps ユーザー ID を使用して作業項目履歴のクエリを続行できます。
  • ユーザーの PAT を取り消します。
  • 個々のユーザー アカウントに付与された特別なアクセス許可を取り消します。
  • 削除するユーザーから現在のチーム メンバーに作業を再割り当てします。

Microsoft Entra ID を使用する

Azure DevOps を Microsoft Entra ID と統合して、ID 用の単一のプレーンを持つ。 整合性と単一の権限のあるソースにより、わかりやすさが向上し、人的エラーや構成の複雑さによるセキュリティ リスクが軽減されます。 ガバナンスを終了するための鍵は、複数のロールの割り当て (異なるロール定義と、同じ Microsoft Entra グループに対する異なるリソース スコープ) を持つことです。 Microsoft Entra ID がない場合、お客様は組織のアクセスを制御する責任を負います。

Microsoft Entra ID を使用すると、多要素認証やその他の条件付きアクセス ポリシーなどの他のセキュリティ機能にもアクセスできます。

詳細については、次の記事をご覧ください。

監査イベントを確認する

Microsoft Entra をサポートする組織を作成したら、セキュリティ ポリシーで監査を有効にすることができます。 監査イベントを定期的に確認して、管理者や他のユーザーによる予期しない使用パターンを監視し、対応します。

ネットワークをセキュリティで保護する

これを行うには、次のような方法があります。

  • 許可 リスト を設定して、特定の IP を制限します。
  • 常に暗号化を使用します。
  • 証明書を検証します。
  • Web アプリケーション ファイアウォール (WAF) を実装して、Azure DevOps との間の悪意のある Web ベースのトラフィックをフィルター処理、監視、ブロックできるようにします。
  • 詳細については、アプリケーション管理のベスト プラクティスに関するこちらのガイダンスを参照してください

スコープ付きアクセス許可

システムは、個々、コレクション、プロジェクト、およびオブジェクトというさまざまなレベルでアクセス許可を管理し、既定で 1 つ以上の組み込みグループに割り当てます。

プロジェクト レベルのアクセス許可

  • プロジェクトとリポジトリへのアクセスを制限して、機密情報を漏洩させ、安全でないコードを運用環境にデプロイするリスクを軽減します。
  • 組み込みのセキュリティ グループまたはカスタム セキュリティ グループを使用してアクセス許可を管理します。 詳細については、「 タスクを選択するためのアクセス許可を付与または制限するを参照してください。
  • organizationのポリシー設定で [パブリック プロジェクトを許可する] を無効にして、すべてのorganization ユーザーがパブリック プロジェクトを作成できないようにします。 Azure DevOps Servicesを使用すると、プロジェクトの可視性をパブリックからプライベートに、またはその逆に変更できます。 ユーザーがorganizationにサインインしていない場合は、パブリック プロジェクトへの読み取り専用アクセス権を持ちます。 ユーザーがサインインしている場合は、プライベート プロジェクトへのアクセスを許可し、許可された変更を加えることができます。
  • ユーザーが新しいプロジェクトを作成できないようにします。

外部ゲスト アクセス

  • "任意のドメインへの招待の送信を許可する" ポリシーを無効にして、外部ゲスト アクセスを完全にブロックします。 ビジネス上の必要がない場合は、これを行うことをお勧めします。
  • 許可されている場合でも、個人アカウントとビジネス アカウントに別のメールまたはユーザー プリンシパル名 (UPN) を使用します。 このアクションにより、メール/UPN が同じ場合に、ビジネス アカウントと個人アカウントの間であいまいさを解消する課題がなくなります。
  • すべての外部ゲスト ユーザーを 1 つの Microsoft Entra グループに配置し、そのグループのアクセス許可を適切に管理します。 この方法で簡単に管理および監査できます。
    • グループ ルールがそれらのユーザーに適用されるように、直接割り当てを削除します。 詳細については、「 アクセス レベルを割り当てるグループ ルールを追加する」を参照してください。
    • [ユーザー] ページの [グループ ルール] タブでルールを定期的に再評価します。 Microsoft Entra ID のグループ メンバーシップの変更が組織に影響を与える可能性があるかどうかを明確にします。 Microsoft Entra ID は、動的グループ メンバーシップの更新に最大 24 時間かかることがあります。 24 時間ごと、およびグループ ルールが変更されるたびに、ルールはシステムで自動的に再評価されます。
  • 詳細については、Microsoft Entra ID B2B ゲストを参照してください。

セキュリティ グループを管理する

セキュリティ グループとユーザー グループ

セキュリティ グループとユーザー グループにアクセス許可を割り当てるには、次の推奨事項を参照してください。

Do しないでください
多数のユーザーを管理する場合は、Microsoft Entra ID、Active Directory、または Windows セキュリティ グループを使用します。 [Project Valid Users]\(プロジェクトの有効なユーザー\) グループの既定のアクセス許可は変更しないでください。 このグループは、プロジェクト情報にアクセスして表示できます。
チームを追加するときは、エリア パス、イテレーション パス、クエリを作成および変更する必要があるチーム メンバーに割り当てるアクセス許可を検討してください。 異なるアクセス許可レベルを含む複数のセキュリティ グループにユーザーを追加しないでください。 場合によっては、 拒否 アクセス許可レベルが 許可 アクセス許可レベルをオーバーライドすることがあります。
多くのチームを追加する場合は、プロジェクト管理者が使用できるアクセス許可のサブセットを割り当てる Team Administrators カスタム グループを作成することを検討 してください。 Project Valid Users グループに対して行われた既定の割り当てを変更しないでください。 [プロジェクトの有効なユーザー] グループの 1 つに対して [インスタンス レベルの情報の表示] を [拒否] に設定した場合、アクセス許可を設定したプロジェクト、コレクション、または配置にグループ内のユーザーはアクセスできません。
作業項目クエリ フォルダーに、プロジェクトの作業項目クエリを作成および共有する機能を必要とするユーザーまたはグループに 投稿 アクセス許可を付与することを検討してください。 [ サービス アカウントにのみ割り当てる ] と表示されているアクセス許可をユーザー アカウントに割り当てないでください。
グループは可能な限り小さくしてください。 アクセスを制限し、グループを頻繁に監査する必要があります。
組み込みロールを利用し、開発者向けのデフォルトの共同作成者に設定します。 管理者は、昇格された権限のためにプロジェクト管理者セキュリティ グループに割り当てられるため、セキュリティ アクセス許可を構成できます。

詳細については、「 Valid ユーザー グループ」を参照してください。

管理者グループの Just-In-Time アクセス

プロジェクト コレクション管理者および Project Administrator アクセス権を持っている場合は、組織またはプロジェクトの構成を変更できます。 これらの組み込みの管理者グループへのアクセスを保護するには、Microsoft Entra Privileged Identity Management (PIM) グループを使用して Just-In-Time アクセスを要求。

アクセスを構成する

  1. Microsoft Entra ID でロール割り当て可能なグループを作成。
  2. Microsoft Entra グループを Azure DevOps グループに追加します。

Note

PIM グループを使用して昇格されたアクセス権を持つユーザーも組織への標準アクセス権を持っていることを確認して、ページを表示してアクセス許可を更新できるようにします。

アクセスを使用する

  1. アクセス権をアクティブ化。
  2. Azure DevOps で アクセス許可を更新します。
  3. 管理者アクセスを必要とするアクションを実行します。

Note

ユーザーは、PIM グループ アクセスが非アクティブ化されてから最大 1 時間、Azure DevOps で昇格されたアクセス権を持ちます。

サービス アカウントのスコープを設定する

  • サービス アカウントに対話型サインイン権限がゼロであることを確認します。
  • サービス アカウントの特権を必要最小限に制限します。
  • サービス アカウントにドメイン アカウントを使用する場合は、レポート 閲覧者アカウントに別の ID を使用します。 詳細については、「 サービス アカウントと依存関係」を参照してください。
  • ワークグループにコンポーネントをインストールする場合は、ユーザー アカウントにローカル アカウントを使用します。 詳細については、「 サービス アカウントの要件」を参照してください。
  • 可能な場合 は、サービス接続 を使用します。 サービス接続は、シークレット変数をビルドに直接渡すことなく、アソートされたサービスに接続するための安全なメカニズムを提供します。 - これらの接続を使用する必要がある特定の場所に制限し、それ以上は行いません。
  • サービス アカウントのアクティビティを監視し、 監査ストリーミングを作成します。 監査を使用すると、疑わしいサインインとアクティビティを検出して対応できます。
  • 詳細については、「 一般的なサービス接続の種類」を参照してください。

サービス接続のスコープを設定する

  • Azure Resource Managerとその他のサービス接続のスコープは、アクセスが必要なリソースとグループのみに限定します。 サービス接続には、Azure サブスクリプション全体に対する広範な共同作成者権限を持つべきではありません。
  • Azure Resource Manager (ARM) サービス接続に対して id フェデレーション workload を使用します。 ワークロード ID フェデレーションを使用すると、Azure Pipelines から Azure へのシークレットのないサービス接続を作成できます。
  • Azure サブスクリプションに対する汎用的または広範な共同作成者の権限をユーザーに付与しないでください。
  • アクセス許可のスコープを設定する方法がないため、Azure クラシック サービス接続を使用しないでください。
  • リソース グループに、ビルドがアクセスする必要があるVirtual Machines (VM) またはリソースのみが含まれていることを確認します。
  • サービス接続を認証するには、目的固有のチーム サービス アカウントを使用します。
  • 詳細については、「 一般的なサービス接続の種類」を参照してください。

適切な認証方法の選択

次のソースから 認証方法 を選択します。

サービス プリンシパルを検討する

Microsoft Entra トークンを使用して Azure DevOps リソースにアクセスできるようにする、 サービス プリンシパルやマネージド ID など の代替手段について説明します。 このようなトークンは、PAT と比較して漏洩した場合のリスクが少なく、簡単な資格情報管理などの利点が含まれています。

PAT を慎重に使用する

可能であれば、アプリケーション コードを使用してキーを安全に管理することは困難であり、GitHub などの公開コード リポジトリに機密アクセス キーを誤って発行するなどの誤りが発生する可能性があるため、暗号化キーの代わりに常に ID サービスを認証に使用することをお勧めします。 ただし、個人用アクセス トークン (PAT) を使用する必要がある場合は、次のガイドラインを考慮してください。

  • PAT は常に特定のロールにスコープを設定する必要があります。

  • PAT では、複数の組織にグローバル アクセスを提供しないでください。

  • PAT では、ビルドまたはリリースに対する書き込みアクセス許可や管理アクセス許可を付与しないでください。

  • PAT はパスワードと同じくらい重要であるため、有効期限を設定し、秘密にしておく必要があります。

  • コードを簡略化する場合でも、アプリケーション コードで PAT をハードコーディングしないでください。

  • 管理者は、 REST API を使用してすべての PAT を定期的に監査し 上記の条件を満たしていないすべての PAT を取り消す必要があります。

  • PAT をシークレットのままにします。 トークンはパスワードと同じくらい重要です。

  • トークンを安全な場所に保存します。

  • アプリケーションでトークンをハード コードしないでください。 コードを簡略化して長期間トークンを取得し、アプリケーションに格納するのは魅力的ですが、それを行わないでください。

  • トークンに有効期限を指定します。

  • 詳細については、次の記事をチェックしてください。

Azure Artifacts をセキュリティで保護する

Azure Boards をセキュリティで保護する

Azure Pipelines をセキュリティで保護する

ポリシー

  • 元の要求者の外部に少なくとも 1 人のレビュー担当者が必要です。 承認者は変更の共同所有者を共有し、潜在的な影響について同様に責任を負う必要があります。
  • CI ビルドが合格することを要求します。 この要件は、コード リンティング、単体テスト、セキュリティ チェック (ウイルススキャンや資格情報スキャンなど) を通じて、ベースライン コードの品質を確立するのに役立ちます。
  • 元の pull requester が変更を承認できないことを確認します。
  • 一部のレビュー担当者が待機または拒否に投票した場合でも、PR (Pull Request) の完了を禁止します。
  • 最近の変更がプッシュされたときに、コード レビュー担当者の投票をリセットします。
  • リリース パイプラインは、特定の運用ブランチでのみ実行してロックダウンします。
  • organizationのパイプライン設定で[変数のキュー時に設定可能を適用する]を有効にします。
  • エディターで設定された変数に対して、"このパイプラインの実行時にユーザーがこの値をオーバーライドできるようにする" ことを許可しないでください。

エージェント

  • 可能な最小数のアカウントにアクセス許可を付与します。
  • エージェントを使用できる最も制限の厳しいファイアウォールを用意します。
  • 悪意のあるアクターが悪用する可能性がある脆弱なコードがビルド フリートで実行されていないことを確認するために、プールを定期的に更新します。
  • 運用環境に出荷またはデプロイされるビルド成果物には、別のエージェント プールを使用します。
  • 非センシティブ プールから "機密" プールをセグメント化し、そのプールにロックされているビルド定義での資格情報の使用のみを許可します。

定義

  • YAML (さらに別のマークアップ言語) を使用してパイプライン定義を管理します。 YAML は、変更のトレーサビリティを提供し、承認ガイドラインに従うことができるため、パイプライン定義を管理するための推奨される方法です。
  • パイプライン定義の [Edit access to the minimum number of accounts]\(アカウントの最小数へのアクセスの編集\) をセキュリティで保護します。

入力

  • ビルド スクリプトに変数のサニティ チェックを含めます。 サニティ チェックは、設定可能な変数を介したコマンド インジェクション攻撃を軽減できます。
  • 可能な限り少数のビルド変数を "リリース時に設定可能" に設定します。

タスク

  • リモートでリソースをフェッチしないようにしますが、必要に応じて、バージョン管理とハッシュ チェックを使用します。
  • シークレットをログに記録しないでください。
  • パイプライン変数にシークレットを格納しないでください。 Azure Key Vault を使用します。 ビルド パイプラインを定期的にスキャンして、シークレットがビルド パイプライン変数に格納されていないことを確認します。
  • ユーザーがセキュリティクリティカルなパイプラインで任意のブランチまたはタグに対してビルドを実行できないようにします。
  • 継承されたアクセス許可は広範であり、アクセス許可のニーズを正確に反映しないため、パイプラインでの継承を無効にします。
  • すべてのケースでジョブ承認スコープを制限します。

リポジトリとブランチ

  • すべての pull request が少なくとも 2 人の承認者によってレビューされるように、"レビュー担当者の最小数を要求する" ポリシーを オンに設定します。
  • プロジェクト全体ではなく、各リポジトリまたはブランチに固有のセキュリティ ポリシーを構成します。 セキュリティ ポリシーにより、リスクが軽減され、変更管理標準が適用され、チームのコード品質が向上します。
  • 運用環境のシークレットを別の Key Vault に格納し、非運用環境のビルドを分離するために、知る必要がある場合にのみアクセス権が付与されるようにします。
  • 資格情報の使用を含め、テスト環境と運用環境を混在させる必要はありません。
  • フォークを無効にします。 フォークが多いほど、各フォークのセキュリティを追跡するのが難しくなります。 また、ユーザーはリポジトリのコピーを自分のプライベート アカウントに簡単にフォークできます。
  • フォーク ビルドにシークレットを提供しないでください。
  • フォーク ビルドを手動でトリガーすることを検討してください。
  • フォーク ビルドには Microsoft ホステッド エージェントを使用します。
  • Git の場合は、プロジェクトの git リポジトリで運用ビルド定義をチェックして、資格情報をスキャンできるようにします。
  • production ブランチのコンテキストで実行されているパイプラインのみがprod-connectionを使用できるように、ブランチ コントロール チェックを構成します。
  • 詳細については、「 その他のセキュリティに関する考慮事項」を参照してください。

Azure Repos をセキュリティで保護する

Azure Test Plans をセキュリティで保護する

GitHub 統合をセキュリティで保護する

  • 個人用アクセス トークン (PAT) ベースの認証を無効にして、OAuth フローが GitHub サービス接続で使用されるようにします。
  • リポジトリの管理者または所有者である ID として GitHub サービス接続を認証しないでください。
  • GitHub サービス接続を認証するために、完全なスコープの GitHub PAT (個人用アクセス トークン) を使用しないでください。
  • Azure DevOps とのサービス接続として個人用 GitHub アカウントを使用しないでください。