セキュリティの運用方法

  • [アーティクル]

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

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

必須ではありませんが、ベスト プラクティスを組み込むことで、エクスペリエンスが大幅に向上し、セキュリティが強化されます。 次の推奨事項は、セキュリティで保護された Azure DevOps 環境を維持するのに役立ちます。

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

ユーザーの 削除、監査イベントの の表示、Microsoft Entra ID による 統合を行う場合は、次のベスト プラクティスを採用。

Remove users

  • Microsoft アカウント (MSA) から非アクティブなユーザーを削除する: A を使用している場合は組織から非アクティブなユーザーを間接的に削除します。 削除された MSA アカウントに割り当てられた作業項目のクエリを作成することはできません。
  • Microsoft Entra ユーザー アカウントを無効または削除する: Microsoft Entra ID に接続されている場合は、Azure DevOps ユーザー アカウントをアクティブにしたまま、Microsoft Entra ユーザー アカウントを無効または削除します。 このアクションを使用すると、Azure DevOps ユーザー ID を使用して作業項目履歴のクエリを続行できます。
  • ユーザー AT の取り消し: これらの重要な認証トークンの安全な管理を確保するために、既存のユーザー AT を定期的に確認して取り消します。
  • 個々のユーザーに付与された特別なアクセス許可を取り消す: 監査し、個々のユーザーに付与された特別なアクセス許可を取り消して、最小限の特権の原則に確実に準拠します。
  • 削除されたユーザーからの作業の再割り当て: ユーザーを削除する前に、作業項目を現在のチーム メンバーに再割り当てして、負荷を効果的に分散します。

Microsoft Entra ID を使用する

  • 統合 ID システムを確立する: Azure DevOps を Microsoft Entra ID に接続して、ID 用の単一プレーンを作成します。 この一貫性により、混乱が軽減され、手動構成エラーによるセキュリティ リスクが最小限に抑えられます。
  • きめ細かなガバナンスを実装する: Microsoft Entra ID を使用して、さまざまなリソース スコープにわたって特定のグループに異なるロールとアクセス許可を割り当てます。 このアクションにより、アクセスの制御が保証され、セキュリティのベスト プラクティスに準拠します。
  • セキュリティ機能の強化: 次のような Microsoft Entra ID を使用して他のセキュリティ機能を有効にします。
    • 多要素認証 (MFA): ユーザー認証にパスワードや電話による検証などの複数の要素が必要です。 条件付きアクセス ポリシー: 場所、デバイス、リスク レベルなどの条件に基づいてアクセス規則を定義します。

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

監査イベントを確認する

組織が Microsoft Entra に接続されている場合は、次のタスクを実行してセキュリティを強化し、使用パターンを監視します。

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

次の関数は、Azure DevOps を使用しているときにネットワークのセキュリティを強化する効果的な方法です。

  • IP 許可リストの設定: 信頼できるソースからのトラフィックのみを許可するように特定の IP アドレスへのアクセスを制限し、攻撃対象領域を減らします。
  • 暗号化を使用する: 転送中および保存中のデータを常に暗号化します。 HTTPS などのプロトコルを使用して通信チャネルをセキュリティで保護する。
  • 証明書を検証する: 接続を確立するときに、証明書が有効であり、信頼された機関によって発行されていることを確認します。
  • Web アプリケーション ファイアウォール (WAF) を実装する:WAF を使用して悪意のある Web ベースのトラフィックをフィルター処理、監視、ブロック し、一般的な攻撃に対する保護層を強化します。

詳細については、「 アプリケーション管理のベスト プラクティスを参照してください。

スコープのアクセス許可

システムは、個々、コレクション、プロジェクト、オブジェクトなどのさまざまなレベルでアクセス許可を処理し、既定で 1 つ以上の組み込みグループに割り当てます。 セキュリティを強化するには、次のアクションを実行します。

  • 最小限の特権アクセスを提供する: ビジネス機能を実行するために必要な最小限のアクセス権をユーザーとサービスに付与します。
  • 継承を無効にする: 可能な限り、継承を無効にします。 継承により、既定で許可されるため、予期しないユーザーにアクセス権またはアクセス許可が誤って付与される可能性があります。 詳細については、アクセス許可の継承に関する セクションを参照してください。

アクセス許可の詳細については、次の記事を参照してください。

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

  • プロジェクトとリポジトリへのアクセスを制限する: プロジェクトとリポジトリへのアクセスを 制限することで、機密情報を漏洩させ、安全でないコードをデプロイするリスクを軽減します。 組み込みセキュリティ グループまたはカスタム セキュリティ グループを使用してアクセス許可を管理します。
  • "パブリック プロジェクトを許可する": 組織のポリシー設定で、パブリック プロジェクトを作成するオプションを無効にします。 必要に応じて、プロジェクトの可視性をパブリックからプライベートに切り替えます。 サインインしていないユーザーはパブリック プロジェクトへの読み取り専用アクセス権を持ちますが、サインインしているユーザーにはプライベート プロジェクトへのアクセス権を付与し、許可された変更を行うことができます。
  • プロジェクトの作成を制限する: ユーザーが新しいプロジェクトを作成して環境を制御できないようにします。

外部ゲスト アクセス

  • 外部ゲスト アクセスをブロックする: "Allow invitations to be sent to any domain" (招待を任意のドメインに送信することを許可する) ポリシーを無効にします ビジネス上の必要がない場合に外部ゲスト アクセスを禁止します。
  • 個別のメールまたは 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]\(プロジェクトの有効なユーザー\) グループの既定のアクセス許可は変更しないでください。 このグループは、プロジェクト情報にアクセスして表示できます。 詳細については、「 Valid ユーザー グループ」を参照してください。
チームを追加するときは、エリア パス、イテレーション パス、クエリを作成および変更する必要があるチーム メンバーに割り当てるアクセス許可を検討してください。 異なるアクセス許可レベルを含む複数のセキュリティ グループにユーザーを追加しないでください。 場合によっては、 Deny アクセス許可レベルが Allow アクセス許可レベルをオーバーライドすることがあります。 たとえば、Azure DevOps プロジェクトに 2 つのセキュリティ グループ ( Developers と Testers があるとします。 Developers グループには、Allowに設定された作業項目を編集する権限があります。 ただし、特定の機密性の高い作業項目が、少数の主要な個人を除くすべてのユーザーによって編集されないようにします。 そのためには、Sensitive Items Editors という名前の新しいセキュリティ グループを作成しこのグループの作業項目を編集する権限をDenyに設定します。 ユーザーが Developers グループと Sensitive Items Editors グループの両方のメンバーである場合、Sensitive Items Editors グループの Deny アクセス許可は、Developers グループの Allow アクセス許可よりも優先されます。 その結果、このユーザーは、Developers グループに Allow アクセス許可がある場合でも、機密性の高い作業項目を編集できません。 この動作により、 Deny アクセス許可が厳密に適用され、Azure DevOps 環境内の機密性の高いアクションに対するより高いレベルのセキュリティと制御が提供されます。
多くのチームを追加する場合は、プロジェクト管理者が使用できるアクセス許可のサブセットを割り当てる Team Administrators カスタム グループを作成することを検討 してください。 Project Valid Users グループに対して行われた既定の割り当てを変更しないでください。 [プロジェクトの有効なユーザー] グループの 1 つに対して [インスタンス レベルの情報の表示] を [拒否] に設定した場合、アクセス許可を設定したプロジェクト、コレクション、または配置にグループ内のユーザーはアクセスできません。
作業項目クエリ フォルダーに、プロジェクトの作業項目クエリを作成および共有する機能を必要とするユーザーまたはグループに 投稿 アクセス許可を付与することを検討してください。 サービス アカウントにのみ割り当てとしてマークされているアクセス許可をユーザー アカウントに割り当てないでください。
グループは可能な限り小さくしてください。 アクセスを制限し、グループを頻繁に監査する必要があります。
組み込みロールを利用し、開発者向けのデフォルトの共同作成者に設定します。 管理者は、昇格された権限のためにプロジェクト管理者セキュリティ グループに割り当てられるため、セキュリティ アクセス許可を構成できます。

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

Project コレクション管理者プロジェクト管理者アクセス権持っている場合は、組織またはプロジェクトの構成を変更できます。 これらの組み込みの管理者グループのセキュリティを強化するには、Microsoft Entra Privileged Identity Management (PIM) グループを使用して Just-In-Time アクセスを実装することを検討。 この方法では、必要な場合にのみ昇格されたアクセス許可を付与できるため、永続的なアクセスに関連するリスクを軽減できます。

アクセスを構成する

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

Note

Microsoft Entra Privileged Identity Management (PIM) グループを使用して Just-In-Time アクセスを構成する場合は、昇格されたアクセス権を持つすべてのユーザーが組織への標準アクセスも保持されるようにします。 これにより、必要なページを表示し、必要に応じてアクセス許可を更新できます。

アクセスを使用する

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

Note

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

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

  • 単一目的のサービス アカウントを作成する: 各サービスには、リスクを最小限に抑えるために専用のアカウントが必要です。 サービス アカウントとして通常のユーザー アカウント 使用しないでください。
  • 名前付けとドキュメントの規則に従う: サービス アカウントのわかりやすい名前を使用し、その目的と関連するサービスを文書化します。
  • 未使用のサービス アカウントを特定して無効にする: 使用されなくなったアカウントを定期的に確認して特定します。 削除を検討する前に、未使用のアカウントを無効にします。
  • privileges: サービス アカウントの特権を必要最小限に制限します。 サービス アカウントの対話型サインイン権限は避けてください。
  • レポート 閲覧者に個別の ID を使用する: サービス アカウントにドメイン アカウントを使用する場合は、レポート閲覧者に別の ID を使用してアクセス許可を し、不要なアクセスを防ぎます。
  • ワークグループのインストールにローカル アカウントを使用する: ワークグループにコンポーネントをインストールする場合は、ユーザー アカウントにローカル アカウントを使用します。 このシナリオではドメイン アカウントを使用しないでください。
  • サービス接続: 可能な限りサービス接続を使用して、シークレット変数をビルドに直接渡すことなく、サービスに安全に接続します。 接続を特定のユース ケースに制限します。
  • サービス アカウント アクティビティの監視: 監査を実装し、 audit ストリームを作成 サービス アカウントのアクティビティを監視します。

詳細については、「 一般的なサービス接続の種類」を参照してください。

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

  • サービス接続のスコープ: Azure Resource Manager サービス接続を特定のリソースとグループにスコープすることで、アクセスを制限します。 Azure サブスクリプション全体で広範な共同作成者権限を付与することは避けてください。
  • ワークロード ID フェデレーション: シークレットなしで OpenID Connect (OIDC) を使用して Azure リソースで認証を行います。 Azure サブスクリプションの所有者ロールがあり、Azure Stack または Azure US Government 環境に接続していない場合、および使用する Marketplace 拡張機能タスクでサポートされている場合は、ワークロード ID フェデレーションを自動的または手動で作成します。
  • リソース グループのスコープ: リソース グループに、ビルド プロセスに必要な仮想マシン (VM) またはリソースのみが含まれていることを確認します。
  • 従来のサービス接続を避ける: スコープ オプションがない従来の接続ではなく、最新の Azure Resource Manager サービス接続を選択します。
  • 目的固有のチーム サービス アカウントを使用する: 目的固有のチーム サービス アカウントを使用してサービス接続を認証し、セキュリティと制御を維持します。

詳細については、「 一般的なサービス接続の種類」を参照してください。

適切な認証方法の選択

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

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

サービス プリンシパルやマネージド ID などの代替手段を確認します:

  • サービス プリンシパルを使用する: Microsoft Entra アプリケーション内のセキュリティ オブジェクトを表します。 特定のテナントでアプリケーションが実行できる操作を定義します。 Azure portal でアプリケーションの登録中に設定します。 Azure DevOps を含む Azure リソースにアクセスするように構成します。 特定のアクセスと制御を必要とするアプリに便利です。
  • マネージド ID を使用する: アプリケーションのサービス プリンシパルに似ています。 Azure リソースの ID を指定します。 Microsoft Entra 認証をサポートするサービスが資格情報を共有できるようにします。 Azure では、資格情報の管理とローテーションが自動的に処理されます。 シームレスなサインインの詳細管理に最適です。

PAT を慎重に使用する

  • 特定のロールに対して AT のスコープを設定する: 特定のタスクに必要なアクセス許可のみを PAT に割り当てます。 誤用のリスクを最小限に抑えるために、複数の組織またはリポジトリへのグローバル アクセスを許可しないようにします。
  • ビルドとリリースに対する 書き込み または 管理 アクセス許可を避ける: AT は、ビルド、リリース、またはその他の重要なリソースに対する書き込みまたは管理のアクセス許可を持つべきではありません。 これらのアクセス許可を制限すると、パイプラインまたはデプロイに影響を与える可能性のある意図しないアクションを防ぐことができます。
  • 有効期限を設定し、AT シークレットを保持する: 常に AT の有効期限を設定します。 必要に応じて定期的に確認して更新します。 AT をパスワードとして重要として扱い、機密性を保ち、アプリケーション コードでのパブリック共有やハードコーディングを回避します。
  • アプリケーション コードでの AT のハードコーディングを回避する: コードに直接 AT を埋め込む代わりに、セキュリティで保護された構成ファイルまたは環境変数を使用して、AT を動的に格納および取得します。 動的。
  • 未使用の PAT を定期的に監査および取り消す: 管理者は、 REST API を使用してすべての PAT を定期的に確認する必要があります。 不要になった、または推奨される条件を満たしていないすべての AT を取り消します。

詳細については、「 管理者向け ポリシーを使用して AT を管理する」および「 PAT を使用する」を参照してください。

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

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

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

ポリシー

  • 外部レビュー担当者を必須にする: 完全なレビュー プロセスのために、元の要求者の外部に少なくとも 1 人のレビュー担当者を確保します。 承認者は、潜在的な影響に対する変更とアカウンタビリティの共同所有権を共有します。
  • CI ビルドが pass: PR をマージする前に継続的インテグレーション (CI) ビルドに合格するように要求することで、コード品質のベースラインを確立する必要があります。 CI チェックには、コード リンティング、単体テスト、セキュリティ スキャンが含まれます。
  • 自己承認を禁止する: 元の PR 要求者が独自の変更を承認できないようにして、偏りのないレビュー プロセスを確保し、関心の競合を回避します。
  • "待機" または "拒否" の投票で PR 完了を禁止する: 一部のレビュー担当者が待機または拒否に投票した場合でも PR の完了を防止し、マージする前にすべてのフィードバックに対処するよう促します。
  • 変更に対するレビュー担当者の投票をリセットする: 最近の変更が PR にプッシュされたときにレビュー担当者の投票をリセットして、更新されたコードをレビュー担当者が再評価できるようにします。
  • リリース パイプラインをロックダウンする: リリース パイプラインを特定のブランチ (通常は運用またはメイン) に制限して、他のブランチからの偶発的なデプロイを回避します。
  • キュー時に設定可能な変数を適用する: パイプラインの実行中にユーザーが変数値をオーバーライドできないように、パイプライン変数の "キュー時に設定可能な変数を適用する" オプションを有効にします。
  • editor: パイプライン エディターで設定された変数の場合は、一貫性を維持し、意図しない変更を防ぐために、ユーザーのオーバーライドを禁止します。

エージェント

  • アクセス許可を控えめに付与する: 攻撃対象領域を減らすために必要な最小のアカウント セットにアクセス許可を制限します。
  • エージェントの制限付きファイアウォールを構成する: エージェントの機能を引き続き許可しながら、セキュリティと使いやすさのバランスを取りながら、ファイアウォールをできるだけ制限するように設定します。
  • エージェント プールを定期的に更新する: エージェントを定期的に更新して、脆弱なコードが実行されていないことを確認することで、エージェントのフリートを最新の状態に保ち、悪用のリスクを軽減します。
  • 運用成果物に別のエージェント プールを使用する: 個別のエージェント プールを使用して運用成果物を分離し、非本番ブランチからの偶発的なデプロイを防ぎます。
  • 機密性の高いプールをセグメント化する: 機密性の高いワークロードと機密性の低いワークロード用に個別のプールを作成します。 適切なプールに関連付けられているビルド定義の資格情報のみを許可します。

定義

  • パイプライン定義に YAML を使用する: YAML (Yet Another Markup Language) を使用してパイプラインを定義すると、追跡性が向上し、承認ガイドラインとバージョン管理プラクティスに準拠できます。
  • パイプライン定義への編集アクセスを制限する: パイプライン定義の編集へのアクセスを最小限の必要なアカウントに制限して、偶発的または未承認の変更のリスクを軽減します。

入力

  • ビルド スクリプトに変数のチェックを含める: 設定可能な変数を使用して潜在的なコマンドインジェクション攻撃を軽減するために、ビルド スクリプト内にチェックを実装します。 入力値を検証し、意図しないコマンドや悪意のあるコマンドを防ぎます。
  • "リリース時に設定可能" ビルド変数を制限する: 攻撃対象領域を減らし、構成管理を簡略化するために、リリース時に設定できるビルド変数の数を最小限に抑えます。

タスク

  • リモートでフェッチされたリソースを回避する: 可能な限り、ビルド プロセス中に外部 URL からリソースをフェッチしないようにします。 リモート リソースが必要な場合は、バージョン管理とハッシュ チェックを使用して整合性を確保します。
  • シークレットのログ記録を避ける: 意図しない公開やセキュリティの侵害を防ぐために、シークレットや資格情報などの機密情報をビルド ログに記録しないでください。
  • シークレットに Azure Key Vault を使用する: シークレットをパイプライン変数に直接格納する代わりに、Azure Key Vault を使用してシークレットを安全に管理および取得します。
  • 任意のブランチまたはタグに対してビルドの実行を制限する: セキュリティクリティカルなパイプラインでは、ユーザーが任意のブランチまたはタグに対してビルドを実行できないように制限します。 特定の承認されたブランチまたはタグを定義して、偶発的または未承認の実行を防ぎます。
  • パイプラインのアクセス許可の継承を無効にする: 継承されたアクセス許可は過度に広く、ニーズを正確に反映していない可能性があります。 継承を無効にし、セキュリティ要件に合わせてアクセス許可を明示的に設定します。
  • ジョブ承認スコープを制限する: 常にジョブ承認スコープを必要最小限に制限します。 各ジョブによって実行される特定のタスクに基づいてアクセス許可を微調整します。

リポジトリとブランチ

  • レビュー担当者の最小数が必要です: ポリシーを有効にして、すべてのプル要求が少なくとも 2 人の承認者からレビューを確実に受け取り、徹底的なコード レビューとアカウンタビリティを促進します。
  • リポジトリ固有のセキュリティ ポリシーを構成する: プロジェクト全体のポリシーではなく、各リポジトリまたはブランチにセキュリティ ポリシーを調整して、リスクを軽減し、変更管理標準を適用し、コード品質を強化します。
  • 運用シークレットを別のキー コンテナーに分離する: 運用シークレットを Azure Key Vault に個別に格納し、非運用環境のビルドからの分離を維持するために、知る必要があるベースへのアクセスを制限します。
  • 運用環境からテスト環境を分離する: 運用環境とテスト環境を混在させないようにして、非運用コンテキストで資格情報とシークレットが使用されないようにします。
  • フォークを無効にする: フォークを無効にすると、フォークの急増を防ぎ、すべてのコピーのセキュリティを簡単に追跡できるため、セキュリティを管理できます。
  • ビルドをフォークするためのシークレットの提供を避ける: フォークされたビルドとシークレットを共有しないようにして、シークレットを機密に保ち、フォークに公開しないようにします。
  • フォーク ビルドを手動でトリガーすることを検討してください: 自動トリガーがセキュリティ チェックをより適切に制御できるようにするのではなく、フォークのビルドを手動でトリガーします。
  • フォーク ビルドに Microsoft ホスト型エージェントを使用する: 保守およびセキュリティで保護されたビルドに対して Microsoft ホスト型エージェントを使用します。
  • Git リポジトリで実稼働ビルド定義をスキャンする: プロジェクトの Git リポジトリに格納されている運用ビルド定義で、資格情報や機密情報がないか定期的に確認します。
  • 運用コンテキストの分岐制御チェックを構成する: ブランチ制御チェックを設定して、機密性の高い接続 (prod 接続など) の使用を、本番ブランチのコンテキストで実行されているパイプラインに制限し、適切な承認を確保し、誤用を防ぎます。

詳細については、「 その他のセキュリティに関する考慮事項」を参照してください。

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

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

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

  • PAT の代わりに OAuth フローを使用する: GitHub サービス接続の PAT ベースの認証を無効にし、セキュリティと統合を強化するために OAuth フローを選択します。
  • 管理者 ID または所有者 ID を使用しないでください: リポジトリの管理者または所有者である ID を使用して GitHub サービス接続を認証しないでください。 アクセス許可を必要なレベルに制限します。
  • 完全なスコープの GitHub PAT を使用しないでください: サービス接続を認証するために、完全なスコープの GitHub PAT を使用しないようにします。 最低限必要なアクセス許可を持つトークンを使用します。
  • サービス接続として個人用 GitHub アカウントを使用しないでください: Azure DevOps のサービス接続として個人用 GitHub アカウントを使用しないでください。 代わりに、専用のサービス アカウントを作成するか、組織レベルのアカウントを使用します。