次の方法で共有


組織のアプリケーション接続とセキュリティ ポリシーを変更する

重要

Azure DevOps では、代替資格情報認証はサポートされていません。 代替資格情報をまだ使用している場合は、より安全な認証方法に切り替えるよう強くお勧めします。

この記事では、アプリケーションが組織内のサービスやリソースにアクセスする方法を決定する組織のセキュリティ ポリシーを管理する方法について説明します。 これらのポリシーのほとんどは、 Organization 設定でアクセスできます。

前提条件

Permissions: Project コレクション管理者グループのメンバーになる。 組織の所有者は、自動的にこのグループのメンバーになります。

ポリシーを管理する

組織のアプリケーション接続、セキュリティ、およびユーザー ポリシーを変更するには、次の手順を実行します。

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

  2. 歯車アイコン [設定の編集] を選択します。

    [組織の設定] ボタンの [プレビュー] ページのスクリーンショット。

  3. Policiesを選択し、必要に応じてポリシーを on または off に切り替えます。

[ポリシーの選択] のスクリーンショット。[オン] または [オフ] をオンにします。

アプリケーション接続ポリシーを変更する

ユーザー資格情報の入力を繰り返し求めることなく組織へのシームレスなアクセスを許可するために、アプリケーションでは多くの場合、次の認証方法が使用されます。

  • OAuth: Azure DevOps REST API にアクセスするためのトークンを生成します。 すべての REST API は OAuth トークンを受け入れるため、個人用アクセス トークン (AT) よりも優先される統合方法になります。 OrganizationsProfiles、および PAT Management API は OAuth のみをサポートします。 Microsoft Entra ID で OAuth トークンを使用して、組織内のユーザーに安全でシームレスな認証を提供することもできます。

  • SSH: Windows 用の Git を実行している Linux、macOS、および Windows で使用する暗号化キーを生成。 SSH による HTTPS 認証には、 Git 資格情報マネージャー または PAT を使用することはできません。

  • AT: 次のトークンを生成します。

    • ビルドや作業項目などの特定のリソースまたはアクティビティにアクセスする。
    • Xcode や NuGet などのクライアントは、基本的な資格情報としてユーザー名とパスワードを必要とし、多要素認証などの Microsoft アカウントと Microsoft Entra 機能をサポートしていません。
    • Azure DevOps の REST API へのアクセス

既定では、組織はすべての認証方法へのアクセスを許可します。

OAuth キーと SSH キーのアクセスを制限する場合は、次のアプリケーション接続ポリシーを無効にします。

  • OAuth 経由の Microsoft 以外のアプリケーション: Microsoft 以外のアプリケーションが OAuth を介して組織内のリソースにアクセスできるようにします。 このポリシーは、すべての新しい組織に対して既定で off に設定されます。 Microsoft 以外のアプリケーションにアクセスする場合は、このポリシーを有効にして、これらのアプリが組織内のリソースにアクセスできることを確認します。
  • SSH 認証: アプリケーションが SSH 経由で組織の Git リポジトリに接続できるようにします。

認証方法へのアクセスを拒否する場合、その方法を使用して組織にアクセスできるアプリケーションはありません。 以前にアクセスしていたすべてのアプリケーションで認証エラーが発生し、アクセスが失われます。

AT のアクセス権を削除するには、それらを削除します

条件付きアクセス ポリシーを変更する

Microsoft Entra ID を使用すると、テナントは、 Conditional Access Policy (CAP) 機能を使用して Microsoft リソースにアクセスできるユーザーを定義できます。 テナント管理者は、ユーザーがアクセスを取得するために満たす必要がある条件を設定できます。 たとえば、ユーザーは次の操作を行う必要があります。

  • 特定のセキュリティ グループのメンバーになる
  • 特定の場所やネットワークに属している
  • 特定のオペレーティング システムを使用する
  • 管理システムで有効なデバイスを使用する

ユーザーが満たす条件に応じて、多要素認証を要求したり、アクセスを取得するためのさらなるチェックを設定したり、アクセスを完全にブロックしたりできます。

Azure DevOps での CAP サポート

Microsoft Entra ID に基づく組織の Web ポータルにサインインすると、Microsoft Entra ID は、テナント管理者によって設定されたすべての条件付きアクセス ポリシー (CAP) の検証を常に実行します。

Azure DevOps では、サインインして Microsoft Entra ID に基づく組織内を移動した後に、より多くの CAP 検証を実行することもできます。

  • "IP 条件付きアクセス ポリシーの検証を有効にする"組織ポリシーが有効になっている場合は、Web フローと非対話型フローの両方で IP フェンス ポリシーを確認します。たとえば、Git 操作で PAT を使用するような Microsoft 以外のクライアント フローなどです。
  • AT にもサインイン ポリシーが適用される場合があります。 AT を使用して Microsoft Entra ID 呼び出しを行うには、設定されているサインイン ポリシーに準拠する必要があります。 たとえば、サインイン ポリシーでユーザーが 7 日ごとにサインインする必要がある場合、Microsoft Entra ID 要求に対して PAT を引き続き使用するには、7 日ごとにサインインする必要もあります。
  • AZURE DevOps に CAP を適用しない場合は、CAP のリソースとして Azure DevOps を削除します。 組織ごとに Azure DevOps に CAP を適用することはありません。

Web フローでの MFA ポリシーのみをサポートしています。 非対話型フローの場合、条件付きアクセス ポリシーを満たしていない場合、ユーザーは MFA を要求されず、代わりにブロックされます。

IP ベースの条件

IPv4 アドレスと IPv6 アドレスの両方の IP フェンス条件付きアクセス ポリシー (CAP) がサポートされています。 IPv6 アドレスがブロックされている場合は、テナント管理者が IPv6 アドレスを許可するように CAP を構成していることを確認します。 さらに、すべての CAP 条件に既定の IPv6 アドレスの IPv4 マップ アドレスを含める方法を検討してください。

ユーザーが Azure DevOps リソース (VPN トンネリングと共通) へのアクセスに使用した IP アドレスとは異なる IP アドレスを使用して Microsoft Entra サインイン ページにアクセスする場合は、VPN 構成またはネットワーク インフラストラクチャを確認します。 テナント管理者の CAP 内に、使用されているすべての IP アドレスを含めます。