次の方法で共有


個人用アクセス トークンを使用する

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

個人用アクセス トークン (PAT) は、Azure DevOps に認証するための代替パスワードとして機能します。 この PAT は、ユーザーを識別し、アクセスのアクセシビリティとスコープを決定します。 そのため、パスワードと同じレベルの注意を払って、PAT を扱います。

重要

Microsoft Entra トークン 使用することをお勧めします。 PAT の使用量を削減するための取り組みの詳細については、ブログの参照してください。 認証ガイダンス を確認して、ニーズに適した認証メカニズムを選択します。

Microsoft ツールを使用すると、Microsoft アカウント (MSA) または Microsoft Entra ID が認識され、サポートされます。 Microsoft Entra アカウントをサポートしていないツールや、プライマリ資格情報を共有したくないツールを使用する場合は、PAT を適切な代替手段にすることができます。 ただし、可能な限り、Microsoft Entra トークン PAT 経由で使用することをお勧めします。

PAT は以下の方法で管理できます。

  • ユーザー インターフェイス (UI): この記事で詳しく説明されているように、ユーザー設定を使用します。
  • PAT ライフサイクル管理 API
  • Git 操作には Git Credential Manager を使用します。 資格情報マネージャーを使用すると、トークンの管理が容易になります。 これを使用しない場合、ユーザーは毎回資格情報を入力する必要があります。

前提条件

  • アクセス許可:
    • AT が管理されているユーザー設定にアクセスして変更するアクセス許可を持っている。
      • アクセス許可の確認: アクセス許可を確認するには、Azure DevOps で次のいずれかのプロセスを実行します。
        • プロファイルに移動しユーザー設定>選択。 ここで AT を表示および管理できる場合は、必要なアクセス許可があります。
        • プロジェクトに移動し、 プロジェクト設定>Permissions を選択します。 一覧でユーザー アカウントを見つけて、自分に割り当てられているアクセス許可を確認します。 トークンまたはユーザー設定の管理に関連するアクセス許可を探します。
    • 組織化にポリシーが設定されている場合、Azure DevOps 管理者が特定のアクセス許可を付与するか、許可リストに追加して AT を作成および管理することが必要になる場合があります。
    • PAT は、トークンを作成したユーザーアカウントに紐付けられています。 PAT で実行されるタスクによっては、追加のアクセス許可が必要になる場合があります。
  • アクセス レベル: 少なくとも Basic アクセス権を持っている。
  • セキュリティのベスト プラクティス:セキュリティのベスト プラクティス を理解して、PAT の管理に役立てましょう。 必要な場合にのみ使用し、必ず定期的にローテーションを行います。

PAT の作成

  1. 組織にサインインします (https://dev.azure.com/{Your_Organization})。

  2. ホーム ページからユーザー設定 を開き、[個人用アクセス トークン] を選択します。

    選択した [個人用アクセス トークン] を示すスクリーンショット。

  3. [+ New Token] を選択します。

    選択した [新しいトークン] を示すスクリーンショット。

  4. トークンに名前を付け、トークンを使用する組織を選択し、設定した日数後にトークンの有効期限が自動的に切れるよう設定します。

    基本的なトークン情報のエントリを示すスクリーンショット。

  5. このトークンの スコープ を選択して、特定のタスク 承認します

    たとえば、 build およびリリース エージェントのトークンを作成 Azure DevOps に対して認証するには、トークンのスコープを Agent プール (読み取りおよび管理)に設定します。 監査ログ イベントを読み取り、ストリームを管理または削除するには、 監査ログの読み取りを選択し、 Create を選択します。

    PAT の選択されたスコープを示すスクリーンショット。

    Note

    フル スコープの AT の作成が制限される場合があります。 その場合、Microsoft Entra ID の Azure DevOps 管理者が、特定のカスタム定義のスコープ セットに制限するポリシーを有効にしました。 詳細については、「 ポリシーを使用して AT を管理する/フル スコープの AT の作成を制限するを参照してください。 カスタム定義 PAT の場合、コンポーネント ガバナンス API vso.governanceにアクセスするために必要なスコープは、UI では選択できません。

  6. 完了したら、トークンをコピーし、安全な場所に格納します。 セキュリティ上、再び表示されることはありません。

    トークンをクリップボードにコピーする方法を示すスクリーンショット。

Azure DevOps での認証にユーザー資格情報が必要な任意の場所で PAT を使用します。

重要

  • パスワードと同じ注意を払って PAT を扱い、機密性を保ちます。
  • Microsoft Entra ID によってサポートされている組織の場合、90 日以内に新しい PAT でサインインします。それ以外の場合、PAT は非アクティブになります。 詳細については、「条件付きアクセス ユーザーのサインイン頻度を参照してください。

通知

PAT の有効期間中、ユーザーは 2 つの通知を受け取ります。最初の通知は作成時と有効期限の 7 日前です。

PAT を作成すると、次の例のような通知が表示されます。 この通知は、PAT が正常に組織に追加されたことを確認する役割を果たします。

PAT で作成された通知を示すスクリーンショット。

次の図は、PAT の有効期限が切れる前の 7 日間の通知の例を示しています。

有効期限に近い PAT 通知を示すスクリーンショット。

予期しない通知

予期しない PAT 通知を受け取った場合は、管理者またはツールによって PAT が作成された可能性があります。 いくつかの例を次に示します。

  • git.exe経由で Azure DevOps Git リポジトリに接続すると、"git: yourMachine に https://dev.azure.com/{Your_Organization} " という名前のトークンが作成されます。
  • 自分または管理者が Azure App Service Web アプリのデプロイを設定すると、"Service Hooks: Azure App Service: Deploy Web app" という名前のトークンが作成されます。
  • "WebAppLoadTestCDIntToken" という名前のトークンは、ユーザーまたは管理者が Web ロード テストをパイプラインの一部として設定するときに作成されます。
  • Microsoft Teams Integration Messaging Extension が設定されると、"Microsoft Teams Integration" という名前のトークンが作成されます。

警告

  • PAT を誤って存在していると考えられる場合、取り消し (およびパスワードを変更)してください。
  • Microsoft Entra ユーザーの場合は、管理者に問い合わせて、不明なソースまたは場所が組織にアクセスしたかどうかを確認します。
  • パブリック GitHub リポジトリへの accidental PAT チェックインに関する FAQ を確認

PAT を使用する

PAT は、パスワードと同様にデジタル ID として機能します。 1 回限りの要求を実行したり、アプリケーションをローカルでプロトタイプ作成したりするための簡単な方法として、PAT を使用できます。

重要

コードが動作しているときに、基本認証から Microsoft Entra OAuth に切り替えることをお勧めします。 この記事で詳しく説明しない限り、PAT が使用される任意の場所で Microsoft Entra ID トークンを使用できます。

コード内で PAT を使用して、REST API 要求を認証し、ワークフローを自動化できます。 これを行うには、HTTP 要求の承認ヘッダーに PAT を含めます。

HTTP ヘッダーを介して PAT を提供するには、まずそれを Base64 文字列に変換します。 次の例は、C# を使用して Base64 に変換する方法を示しています。


Authorization: Basic BASE64_USERNAME_PAT_STRING

結果の文字列は、次の形式で HTTP ヘッダーとして指定できます。

次の例では、C# の HttpClient クラス を使用します。

public static async void GetBuilds()
{
    try
    {
        var personalaccesstoken = "PATFROMWEB";

        using (HttpClient client = new HttpClient())
        {
            client.DefaultRequestHeaders.Accept.Add(
                new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));

            client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic",
                Convert.ToBase64String(
                    System.Text.ASCIIEncoding.ASCII.GetBytes(
                        string.Format("{0}:{1}", "", personalaccesstoken))));

            using (HttpResponseMessage response = client.GetAsync(
                        "https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.0").Result)
            {
                response.EnsureSuccessStatusCode();
                string responseBody = await response.Content.ReadAsStringAsync();
                Console.WriteLine(responseBody);
            }
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.ToString());
    }
}

ヒント

変数を使用している場合は、次の例のように、文字列の先頭に $ を追加します。

public static async void GetBuilds()
{
   try
  {
      var personalaccesstoken = "PATFROMWEB";

      using (HttpClient client = new HttpClient())
       {
           client.DefaultRequestHeaders.Accept.Add(
              new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));

           client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic",
               Convert.ToBase64String(
                   System.Text.ASCIIEncoding.ASCII.GetBytes(
                       string.Format("{0}:{1}", "", personalaccesstoken))));

          using (HttpResponseMessage response = client.GetAsync(
                       $"https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.0").Result)
           {
               response.EnsureSuccessStatusCode();
               string responseBody = await response.Content.ReadAsStringAsync();
               Console.WriteLine(responseBody);
           }
       }
   }
   catch (Exception ex)
   {
       Console.WriteLine(ex.ToString());
   }
}

次の記事では、PAT の使用方法を示すいくつかの例を見つけることができます。

PAT を変更する

次の手順を実行します。

  • PAT を再生成して新しいトークンを作成すると、前のトークンが無効になります。
  • PAT を拡張して有効期間を延長します。
  • PAT の スコープ を変更してアクセス許可を変更します。
  1. ホーム ページでユーザー設定を開き、 Profile を選択します。

    PAT を変更するために選択するボタンのシーケンスを示すスクリーンショット。

  2. [セキュリティ] で、[個人アクセス トークン 選択します。 変更するトークンを選択し、編集します。

    PAT を変更するために強調表示された [編集] ボタンを示すスクリーンショット。

  3. トークン名、トークンの有効期限、またはトークンに関連付けられているアクセスのスコープを編集し、 保存を選択します。

    変更された PAT を示すスクリーンショット。

PAT を取り消す

PAT は、次のような理由でいつでも取り消すことができます。

  • PAT が侵害されたと思われる場合は、PAT を取り消します。
  • 不要になったら PAT を取り消します。
  • PAT を取り消して、セキュリティ ポリシーまたはコンプライアンス要件を適用します。
  1. ホーム ページでユーザー設定を開き、 Profile を選択します。

    選択するボタンのシーケンス、Team Services、プレビュー ページ、PAT の取り消しを示すスクリーンショット。

  2. [セキュリティ] で、[個人アクセス トークン 選択します。 アクセスを取り消すトークンを選択し、 Revoke を選択します。

    1 つのトークンまたはすべてのトークンを取り消す選択を示すスクリーンショット。

  3. 確認ダイアログで Revoke を選択します。

    PAT を取り消す確認画面を示すスクリーンショット。

詳細については、「 Revoke user PAT for admins」を参照してください。

書式の変更

2024 年 7 月の時点で、Azure DevOps によって発行された PAT の形式が大幅に変更されました。 これらの変更により、セキュリティ上の利点が向上し、すでに私たちの漏洩したPAT検出ツールパートナーオファリングを通じて利用可能なシークレット検出ツールを改善します。 この新しい PAT 形式は、すべての Microsoft 製品で推奨される形式に従います。 より識別可能なビットを含めることで、これらのシークレット検出ツールの誤検知率が向上し、検出されたリークをより迅速に軽減できます。

主な変更:

  • トークンの長さの増加: 新しいトークンの長さが 84 文字になり、52 文字のデータがランダム化されました。 この長さを増やすと、全体的なエントロピが向上し、トークンはブルート フォース攻撃の可能性に対してより耐性が高くなります。
  • 固定署名: サービスによって発行されたトークンには、76 から 80 桁の固定 AZDO 署名が含まれます。

アクションが必要です:

  • 既存の PAT を再生成する: これらのセキュリティ強化を利用するために、現在使用中のすべての PAT を再生成することを強くお勧めします。
  • インテグレーターのサポート: インテグレーターは、新しいトークンの長さと既存の両方の長さに対応するようにシステムを更新する必要があります。

重要

どちらの形式も、近い将来有効なままですが、新しい 84 文字の形式に移行 アクティブにすることをお勧めします。 新しい形式の採用が増えるにつれて、古い 52 文字形式とそのスタイルで発行されたすべてのトークンを廃止することを検討します。

個人アクセス トークン (PATs) を使用するための最良の方法

代替案を検討する

  • 有効期間の長い PAT を作成する代わりに、1 時間続くアドホック要求に対して、Azure CLI を使用して Microsoft Entra トークンを取得します。
  • 資格情報管理を簡素化するには、Git Credential Manager や Azure Artifacts Credential Manager などの資格情報マネージャーを使用します。 これらのツールでは、既定の認証として PAT の代わりに Microsoft Entra トークンを使用するオプションが提示される場合があります。

PAT の作成

  • PAT 名に個人データを含めないでください。 PAT トークン文字列の名前をトークンの名前に変更しないでください。
  • 複数の組織にアクセスする必要がない場合は、PAT がアクセスする必要がある組織のみを選択します。 複数の組織へのアクセスを必要とするワークフローの場合は、そのワークフロー用に個別のグローバル PAT を作成します。
  • 各 PAT に必要なスコープのみを選択します。 可能であれば、1 つの完全スコープ PAT ではなく、スコープの少ないワークフローごとに複数の PAT を作成します。 PAT に読み取りアクセス許可のみが必要な場合は、必要になるまで書き込みアクセス許可を指定しないでください。
  • PAT の有効期間は短く (毎週が理想的です。さらに短いほど良いです)、UI や PAT ライフサイクル管理 APIを使用して定期的にローテーションまたは再生成してください。

PAT の管理

  • Always Azure KeyVault などのセキュリティで保護されたキー管理ソリューションに PAT を格納してください。
  • 不要になったら、パーソナルアクセス トークン (PAT) を取り消します。 テナント管理者は、PAT が侵害された場合に組織ユーザーの PAT を取り消すことができます。
  • ファースト パーティ製ツールで、シークレット漏洩の検出と失効をより適切に行うには、PAT をローテーションして新しい PAT 形式 を使用します。

管理者向け

テナント管理者はポリシーを設定し、グローバル PAT の作成、フル スコープ PAT の作成、PAT の長い有効期間を制限できます。 また、パブリック リポジトリで、PAT の漏洩が検出された場合に、これらを自動的に取り消すポリシーを有効にすることもできます。 これらのポリシーを使用して、会社のセキュリティを向上させます。

よく寄せられる質問

Q: 1 つの組織にスコープされた PAT を編集または再生成できないのはなぜですか?

A: PAT の対象範囲が設定された組織にサインインします。 同じ Microsoft Entra ID で任意の組織にサインインしている間、すべての PAT を表示できますが、組織スコープのトークンは、特定の組織にサインインした場合にのみ編集できます。

Q: ユーザー アカウントが無効になっている場合、PAT はどうなりますか?

A: ユーザーが Azure DevOps から削除されると、PAT は 1 時間以内に無効になります。 組織が Microsoft Entra ID に接続されている場合、PAT はユーザーに属しているため、Microsoft Entra ID でも無効になります。 サービスを実行し続けるために、PAT を別のユーザーまたはサービス アカウントにローテーションすることをお勧めします。

Q: REST API を使用して PAT を更新する方法はありますか。

A: はい。PAT ライフサイクル管理 APIを使用して、PAT を更新、管理、作成できます。

Q: すべての Azure DevOps REST API で PAT を使用できますか?

A: いいえ。 ほとんどの Azure DevOps REST API ではベーシック認証を使用できますが、組織とプロファイル、および PAT 管理ライフサイクル API は、Microsoft Entra OAuthのみをサポートしています 。 このような API を呼び出す Microsoft Entra アプリを設定する方法の例については、REST APIを使用した PAT の管理に関するページを参照してください。

Q: PAT を GitHub のパブリック リポジトリに誤ってチェックインした場合はどうなりますか?

A: Azure DevOps は、GitHub 上のパブリック リポジトリにチェックインされた AT をスキャンします。 漏洩したトークンが見つかると、すぐにトークン所有者に詳細な電子メール通知が送信され、Azure DevOps 組織の audit ログにイベントが記録されます。 自動で漏洩した個人用アクセス トークンの取り消しポリシーを無効にしない限り、漏洩した PAT は直ちに取り消されます。 漏洩したトークンを 新しいトークンに置き換えることで、影響を受けるユーザーに問題を軽減することをお勧めします。 詳細については、「 リークした AT を自動的に取り出す」を参照してください。

Q: 個人用アクセス トークンを ApiKey として使用して、dotnet/nuget.exe コマンド ラインを使用して NuGet パッケージを Azure Artifacts フィードに発行することはできますか。

A: いいえ。 Azure Artifacts では、APIKey として PAT を渡すことはできません。 ローカル開発環境を使用する場合は、Azure Artifacts Credential Provider をインストールして Azure Artifacts で認証することをお勧めします。 詳細については、dotnetNuGet.exe の次の例を参照してください。 Azure Pipelines を使用してパッケージを発行する場合は、NuGet 認証 タスクを使用してフィードで認証します。 の例 参照してください。

Q: PAT が機能しなくなったのはなぜですか?

A: PAT 認証では、完全な認証フローを使用して Azure DevOps に定期的にサインインする必要があります。 多くのユーザーは 30 日に 1 回サインインするだけで十分ですが、Microsoft Entra の構成によっては、より頻繁にサインインする必要がある場合があります。 PAT が機能しなくなった場合は、最初に組織にサインインして、完全な認証プロンプトを完了してみてください。 PAT が引き続き機能しない場合は、有効期限が切れているかどうかを確認します。

IIS 基本認証を有効にすると、Azure DevOps Server での PAT の使用が無効になります。 詳細については、「Azure DevOps オンプレミスでの IIS 基本認証の使用」を参照してください。

Q: 展開目的で特定のユーザーに関連付けられていないアクセス キーを作成操作方法。

A: Azure DevOps では、サービス プリンシパルまたはマネージド ID を使用して、特定のユーザーに関連付けられていないアクセス キーを作成できます。 詳細については、「サービス接続 の管理」および「Azure Pipelinesで Azure Key Vault シークレットを使用する 」を参照してください。