次の方法で共有

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

Azure DevOps Services |Azure DevOps Server 2022 および Azure DevOps Server 2019

特に Azure DevOps Services などのクラウドベースのソリューションで情報とデータを処理する場合は、セキュリティを最優先する必要があります。 Microsoft は基になるクラウド インフラストラクチャのセキュリティを確保しますが、Azure DevOps 内でセキュリティを構成するのはお客様の責任です。 この記事では、脅威や脆弱性から Azure DevOps 環境を保護するために必要なセキュリティ関連の構成の概要について説明します。

ネットワークとデータを保護する

Azure DevOps を使用して、未承認のアクセスや潜在的な脅威からデータとリソースを保護する場合、ネットワークのセキュリティ保護は非常に重要です。 信頼できるソースのみが Azure DevOps 環境にアクセスできるように、ネットワーク セキュリティとデータ保護の手段を実装します。 Azure DevOps を使用しているときにネットワークをセキュリティで保護するには、次の操作を行います。

  • IP 許可リストを設定します。 信頼できるソースからのトラフィックのみを許可するように特定の IP アドレスへのアクセスを制限し、攻撃対象領域を減らします。 組織がファイアウォールまたはプロキシ サーバーで保護されている場合は、IP と URL を許可リストに追加します。
  • データ暗号化を使用する: 暗号化、バックアップ、回復の戦略を使用してデータを保護します。 転送中および保存中のデータは常に暗号化します。 HTTPS などのプロトコルを使用して通信チャネルをセキュリティで保護する。 Azure Encryption の詳細を確認します。
  • 証明書を検証します。 接続を確立するときに、証明書が有効であり、信頼された機関によって発行されていることを確認します。
  • Web アプリケーション ファイアウォール (WAF) を実装する: WAF を使用して悪意のある Web ベースのトラフィックをフィルター処理、監視、ブロックし、一般的な攻撃に対する保護層を強化します。
  • ネットワーク セキュリティ グループ (NSG) の概要: NSG を使用して Azure リソースへの受信トラフィックと送信トラフィックを制御し、承認されたトラフィックのみが許可されるようにします。
  • Azure Firewall を使用する: Azure Firewall をデプロイして、複数の Azure サブスクリプションと仮想ネットワーク間で一元化されたネットワーク セキュリティ ポリシーを提供します。
  • Azure Network Watcher を使用してネットワーク トラフィックを監視する: Azure Network Watcher を使用してネットワークの問題を監視および診断し、ネットワークのセキュリティとパフォーマンスを確保します。
  • Azure DDoS Protection を使用して DDoS 保護を実装する: Azure DDoS Protection を有効にして、分散型サービス拒否 (DDoS) 攻撃からアプリケーションを保護します。

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

ゼロ トラストを実装する

DevOps プロセス全体で ゼロ トラスト 原則を採用して、すべてのアクセス要求が、その発生元に関係なく完全に検証されるようにします。 ゼロ トラストは、"信頼しない、常に検証する" という原則に基づいて動作します。つまり、ネットワークの内部でも外部でも、どのエンティティも既定で信頼されません。 ゼロ トラストを実装することで、セキュリティ侵害のリスクを大幅に軽減し、承認されたユーザーとデバイスのみがリソースにアクセスできるようにします。

ゼロ トラストは、ネットワーク内の横移動から保護するのに役立ちます。これにより、ネットワークの一部が侵害された場合でも、脅威が封じ込められ、拡散できなくなります。 詳細については、 ゼロ トラスト評価ガイドを参照してください。

業界標準に準拠する

Azure DevOps 環境が、環境を保護し、ユーザーとの信頼を維持する業界標準と規制に準拠していることを確認します。

  • 業界標準に準拠していることを確認します。 Azure DevOps は、ISO/IEC 27001、SOC 1/2/3、GDPR などのさまざまな業界標準と規制に準拠しています。 環境がこれらの標準に準拠していることを確認します。
  • コンプライアンス ポリシーを適用する: パイプライン のブランチ ポリシー と コンプライアンス ポリシーを実装します。
  • CI/CD のコンポーネント ガバナンスへのオンボードには、次の利点があります。
    • セキュリティの脆弱性検出: オープンソース コンポーネントの既知の脆弱性にアラートを送信します。
    • ライセンス コンプライアンス: コンポーネントが組織のライセンス ポリシーに準拠していることを確認します。
    • ポリシーの適用: 承認されたバージョンのみが使用されるようにします。
    • 追跡による可視性: 管理を容易にするために、リポジトリ全体のコンポーネントを可視化します。

アクセスの制御と制限

管理者が使用できるすべてのセキュリティ ポリシーを確認して、組織にアクセスできるユーザーを制限および制御します。 不要なプロジェクトの作成を防ぐことで、組織の制御を維持します。

外部ゲストを管理する

外部ゲスト アクセスでは、適切に管理されていない場合、潜在的なセキュリティ リスクが発生する可能性があります。 これらのリスクを最小限に抑え、外部ゲストが環境のセキュリティを損なうことなく適切なレベルのアクセス権を持っていることを確認します。

  • 外部ゲスト アクセスをブロックする: ビジネス上の必要がない場合に外部ゲスト アクセス を禁止するには、[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 ゲストを参照してください。

不要なユーザーを削除する

組織から非アクティブまたは承認されていないユーザーを削除すると 、セキュリティで保護された環境を維持し、潜在的なセキュリティ侵害のリスクを軽減できます。

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

スコープのアクセス許可

必要最小限の アクセス許可 と アクセス レベル を指定して、承認された個人とサービスのみが機密情報にアクセスし、重要なアクションを実行できるようにします。 このプラクティスは、不正アクセスや潜在的なデータ侵害のリスクを最小限に抑えるのに役立ちます。

これらの設定を定期的に確認して更新し、ロールの変更、新入社員、出国など、組織内の変更に合わせて調整します。 アクセス許可とアクセス レベルの定期的な 監査 を実装すると、不一致を特定して修正し、セキュリティ体制が堅牢でベスト プラクティスに準拠していることを確認できます。

アクセス許可の詳細については、以下をご覧ください。

アクセス許可を安全かつ効率的に管理するには、Azure DevOps 環境内で アクセス許可 を適切にスコープ指定します。 スコープのアクセス許可には、ロールと責任に基づいて、ユーザーとグループに適切なレベルのアクセス権を定義して割り当てる必要があります。 このプラクティスは、承認された個人のみが機密情報や重要なアクションにアクセスできるようにすることで、不正アクセスや潜在的なデータ侵害のリスクを最小限に抑えるのに役立ちます。

アクセス許可のスコープを効果的に設定するには、次のアクションを実行します。

  • 継承を無効にします。アクセス許可の継承を回避し、意図しないアクセスを防ぎます。 継承は、既定で許可されるため、アクセス許可を持つべきではないユーザーに誤ってアクセス許可を付与する可能性があります。 目的のユーザーのみがアクセスできるように、アクセス許可を慎重に管理し、明示的に設定します。
  • セグメント環境: 開発、テスト、運用など、さまざまな環境に個別の Azure アカウントを使用して、セキュリティを強化し、競合を防ぎます。 このアプローチにより、リソースの競合や環境間のデータ汚染のリスクが最小限に抑えられます。これにより、リソースの管理と分離が向上します。 詳細については、「 Azure ランディング ゾーン」を参照してください。
  • アクセスを制御し、コンプライアンスを確保します。Azure Policy を使用して、未使用の Azure リージョンとサービスへのアクセスを制限し、組織の標準に確実に準拠します。 このアクションは、承認されていないアクセスと使用を防ぐことで、ベスト プラクティスを適用し、セキュリティで保護された環境を維持するのに役立ちます。
  • Azure ロールベースの制御 (ABAC) を実装します。 適切にタグ付けされたリソースで ABAC を使用して、未承認のアクセスを制限します。 このアクションにより、特定の属性に基づいてアクセス許可が付与され、承認されていないリソースの作成とアクセスを防ぐことでセキュリティが強化されます。
  • セキュリティ グループを使用する:セキュリティ グループを使用して、複数のユーザーのアクセス許可を効率的に管理します。 この方法では、アクセス許可を個別に割り当てるのと比較して、アクセス許可の付与と取り消しが簡単になり、組織全体の一貫性と管理が容易になります。
    • 多数のユーザーを管理する場合は、 Microsoft Entra ID、Active Directory、または Windows セキュリティ グループを使用します。
    • プロジェクトやリポジトリへのアクセスを組み込みまたはカスタムのセキュリティ グループに制限することで、機密情報が漏えいしたり、安全でないコードがデプロイされたりするリスクを軽減できます。
    • 組み込みのロールを利用し、開発者には「共同作成者」を既定のロールとして設定します。 管理者は、管理者特権のアクセス許可のために Project Administrator セキュリティ グループに割り当てられ、セキュリティ アクセス許可を構成できます。
    • グループをできるだけ小さくし、アクセスを制限します。
    • Microsoft Entra Privileged Identity Management (PIM) グループを使用して、ジャストインタイム アクセスを実装します。 必要な場合にのみ昇格されたアクセス許可を付与し、永続的なアクセスに関連するリスクを軽減します。

サービスアカウントを廃止する

これまで、サービス アカウントは 個人用アクセス トークン (AT) と共に使用され、自動化されたプロセスとサービスを実行するツールを構築していました。 その結果、しばしば権限が強化されます。 サービス アカウントを使用して構築を続ける前に、それがまだ適切な認証方法であるかどうかを確認してください。

  • PAT を Microsoft Entra トークンに置き換えます。Microsoft Entra トークンは、ほとんどの AT の代わりに使用できる有効期間が短い (1 時間) トークンです。 PATはその使いやすさから人気がありますが、漏洩のしやすさから攻撃の一般的な手段にもなっています。
  • 1 つを選択する前に 、使用可能なすべての認証メカニズム を確認してください。
  • 代わりにサービス プリンシパルを使用する:サービス プリンシパル は Microsoft Entra アプリケーションの ID を表し、特定のテナントでアプリケーションが実行できることを定義する独自のアクセス許可を持ちます。 サービス プリンシパルは、アプリに必要なアクセス許可を管理するために推奨される選択肢です。 サービス アカウントの PAT を、サービス プリンシパル用に取得した Microsoft Entra トークンに置き換えます。
    • Azure リソースを基に構築している場合は、マネージド ID を使用して認証することで、さらに 1 つの手順を実行します。 マネージド ID は、すべての資格情報管理を自動的に行います。
  • サービス接続を使用する: サービス接続を使用すると、パイプライン内でサービス プリンシパルを使用できます。 可能な限りサービス接続を使用して、シークレット変数をビルドに直接渡すことなく、サービスに安全に接続します。 接続を特定のユース ケースに制限します。 詳細については、この記事の 「サービス接続のスコープ」 セクションを参照してください。

サービス アカウントが引き続き使用されている間:

  • 単一目的のサービス アカウントを作成します。 各サービスには、リスクを最小限に抑えるために専用のアカウントが必要です。 通常のユーザー アカウントを サービス アカウントとして使用しないでください。
  • 未使用のサービス アカウントを特定して無効にします。 使用されなくなったアカウントを定期的に確認して特定します。 削除を検討する前に、未使用のアカウントを無効にします。
  • 特権を制限する: サービス アカウントの特権を必要最小限に制限します。 サービス アカウントの対話型サインイン権限は避けてください。
  • レポート閲覧者には個別の ID を使用します。 サービス アカウントにドメイン アカウントを使用する場合は、レポート閲覧者に別の ID を使用して アクセス許可を分離し、不要なアクセスを防ぎます。
  • ワークグループのインストールにローカル アカウントを使用する: ワークグループにコンポーネントをインストールする場合は、ユーザー アカウントにローカル アカウントを使用します。 このシナリオではドメイン アカウントを使用しないでください。
  • サービス アカウントのアクティビティを監視する: 監査を実装し、 監査ストリーム を作成してサービス アカウントのアクティビティを監視します。

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

Azure リソースへの安全で効率的なアクセスを確保するために、サービス接続のスコープを適切に設定します。 サービス接続を使用すると、Azure DevOps は外部のサービスとリソースに接続でき、これらの接続のスコープを設定することで、必要なリソースのみにアクセスを制限し、不正アクセスのリスクを軽減できます。

  • アクセスを制限する:Azure Resource Manager サービス接続を特定のリソースとグループにスコープすることで、アクセスを制限します。 Azure サブスクリプション全体で広範な共同作成者権限を付与しないでください。
  • Azure Resource Manager を使用する: シークレットでアプリ登録を使用する代わりに、アプリ登録またはマネージド ID を使用してワークロード ID フェデレーションを使用して Azure リソースで認証します。 詳細については、「 ワークロード ID フェデレーションを使用する Azure Resource Manager サービス接続を作成する」を参照してください。
  • リソース グループのスコープ: リソース グループに、ビルド プロセスに必要な仮想マシン (VM) またはリソースのみが含まれていることを確認します。
  • 従来のサービス接続を回避する: スコープ オプションがない従来の接続ではなく、最新の Azure Resource Manager サービス接続を選択します。
  • 目的固有のチーム サービス アカウントを使用します。 セキュリティと制御を維持するために、目的固有のチーム サービス アカウントを使用してサービス接続を認証します。

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

監査イベントを確認する

監査を使用して、組織内のユーザー アクション、アクセス許可の変更、および使用パターンを追跡できます。 これらのツールを使用して、潜在的なセキュリティ インシデントを迅速に特定して対処します。

  • 監査を有効にする: ユーザーのアクション、アクセス許可、変更、セキュリティ インシデントに関連するイベントを追跡および表示します。
  • 監査ログとストリームを定期的に確認します。 監査ログを定期的に確認して、ユーザーアクティビティを監視し、疑わしい動作を検出します。 特に管理者やその他のユーザーが予期しない使用パターンを探します。 このアクションは、潜在的なセキュリティ侵害を特定し、是正措置を講じるのに役立ちます。 追跡する監査イベントの詳細を確認します。
  • セキュリティ アラートを構成します。 セキュリティ インシデントまたはポリシー違反を通知するようにアラートを構成します。 このアクションにより、潜在的な脅威に対するタイムリーな対応が保証されます。

サービスをセキュリティで保護する

Azure DevOps でサービスのセキュリティと整合性を確保するには、サービスごとにセキュリティ対策を実装します。 これらの対策には、アクセス許可の設定、アクセスの管理、および各サービスに固有のセキュリティ機能の使用が含まれます。

セキュリティ スキャンを自動化する

パートナー チームによって構築された次の自動化されたセキュリティ ツールを使用して、コードとシークレットの脆弱性を監視します。

  • コード スキャンと分析を使用する:Microsoft Defender などのツールを使用して、コードで脆弱性、シークレット、構成の誤りをスキャンします。 このアクションは、開発プロセスの早い段階でセキュリティの問題を特定して修復するのに役立ちます。
  • GitHub 用の Azure DevOps 資格情報スキャナー (CredScan) を使用する: マネージド ID を使用するオプションではない場合は、資格情報をコードファイルや構成ファイルに埋め込むのではなく、Azure Key Vault などのセキュリティで保護された場所に格納してください。 Azure DevOps Credential Scanner を実装して、コード内の資格情報を識別します。 詳細については、 CredScan の概要を参照してください。
  • GitHub のネイティブ シークレット スキャンを使用する: マネージド ID が利用できない場合は、シークレットをコードや構成ファイルに埋め込むのではなく、Azure Key Vault などの安全な場所に格納してください。 ネイティブ シークレット スキャン機能を使用して、コード内のシークレットを識別します。 詳細については、「 シークレット スキャンについて」を参照してください。

詳細については、 GitHub の高度なセキュリティの概要を参照してください。