次の方法で共有

セキュリティの運用方法

  • [アーティクル]

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

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

Microsoft Entra ID を使用する

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

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

監査イベントを確認する

組織が Microsoft Entra によってサポートされたら、次のタスクを実行してセキュリティを強化し、使用パターンを監視します。

  • 監査を有効にする:
    • セキュリティ ポリシー内で、監査を有効にします。
    • 監査は、ユーザーのアクション、アクセス許可、変更に関連するイベントを追跡およびログに記録するのに役立ちます。
  • 監査イベントを定期的に確認します:
    • 監査ログを定期的に確認します。
    • 特に管理者やその他のユーザーが予期しない使用パターンを探します。

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

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

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

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

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

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

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

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

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

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

外部ゲスト アクセス

  • 外部ゲスト アクセスをブロックする:
  • 個人アカウントとビジネス アカウントに別の電子メールまたは 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 コレクション管理者プロジェクト管理者アクセス権持っている場合は、組織またはプロジェクトの構成を変更できます。 これらの組み込みの管理者グループのセキュリティを強化するには、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 で昇格されたアクセス権を持ちます。

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

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

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

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

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

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

適切な認証方法の選択

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

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

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

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

PAT を慎重に使用する

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

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

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

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

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

ポリシー

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

エージェント

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

定義

  • パイプライン定義には YAML を使用します。
    • YAML (さらに別のマークアップ言語) は、パイプラインを定義するための推奨されるアプローチです。
    • 変更の追跡可能性が提供されるため、時間の経過に伴う変更の追跡が容易になります。
    • さらに、YAML パイプラインは、承認ガイドラインとバージョン管理プラクティスに従うことができます。
  • パイプライン定義への 編集 アクセスを制限します。
    • パイプライン定義の編集へのアクセスを、必要な最小限のアカウントに制限します。
    • これにより、偶発的または未承認の変更のリスクを軽減できます。

入力

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

タスク

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

リポジトリとブランチ

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

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

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

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

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

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