重要
Azure DevOps では、代替資格情報認証はサポートされていません。 代替資格情報をまだ使用している場合は、より安全な認証方法に切り替えるよう強くお勧めします。
この記事では、ユーザーとアプリケーションが組織内のサービスやリソースにアクセスする方法を決定する組織のセキュリティ ポリシーを管理する方法について説明します。 これらのポリシーのほとんどは、 Organization 設定でアクセスできます。
前提条件
| カテゴリ | 要件 |
|---|---|
| アクセス許可 |
|
ポリシーを管理する
組織のアプリケーション接続、セキュリティ、またはユーザー ポリシーを更新するには、次の手順に従います。
https://dev.azure.com/{Your_Organization}で組織にサインインします。
[設定の編集] を選択します。![[組織の設定] ボタンの [プレビュー] ページのスクリーンショット。](../../media/settings/open-admin-settings-vert.png?view=azure-devops)
[ ポリシー] を選択し、目的のポリシーの オン と オフを切り替えます。
認証方法を制限する
ユーザー資格情報の入力を繰り返し求めることなく組織へのシームレスなアクセスを許可するために、アプリケーションは OAuth、 SSH、 個人用アクセス トークン (AT) などの認証方法を使用できます。 既定では、すべての既存の組織ですべての認証方法へのアクセスが許可されます。
これらの認証方法へのアクセスを制限するには、次のアプリケーション接続ポリシーを無効にします。
- OAuth を使用したサードパーティ アプリケーション アクセス: Azure DevOps OAuth アプリが OAuth を介して組織内のリソースにアクセスできるようにします。 このポリシーは、すべての新しい組織に対して既定で off に設定されます。 Azure DevOps OAuth アプリにアクセスする場合は、このポリシーを有効にして、これらのアプリが組織内のリソースにアクセスできることを確認します。 このポリシーは、 Microsoft Entra ID OAuth アプリのアクセスには影響しません。
- SSH 認証: アプリケーションが SSH 経由で組織の Git リポジトリに接続できるようにします。
- テナント管理者は、グローバルな個人用アクセス トークンの作成を制限し、フル スコープの個人用アクセス トークンの作成を制限し、Microsoft Entra 設定ページのテナント レベルのポリシーを使用して最大の個人用アクセス トークンの有効期間を適用できます。 Microsoft Entra ユーザーまたはグループを追加して、これらのポリシーから除外します。
- 組織の管理者は、それぞれの組織での 個人用アクセス トークンの作成を制限 できます。 サブポリシーを使用すると、管理者はパッケージ化専用の PAT の作成または任意のスコープの PAT の作成を許可して、許可リストに登録された Microsoft Entra ユーザーまたはグループを許可できます。
認証方法へのアクセスを拒否する場合、その方法を使用して組織にアクセスできるアプリケーションはありません。 以前にアクセスしていたすべてのアプリケーションで認証エラーが発生し、アクセスが失われます。
条件付きアクセス ポリシーを適用する
Microsoft Entra ID を使用すると、テナント管理者は 条件付きアクセス ポリシーを使用して Microsoft リソースにアクセスできるユーザーを制御できます。 管理者は、次のようなアクセス権を取得するためにユーザーが満たす必要がある特定の条件を設定します。
- 特定の Microsoft Entra セキュリティ グループのメンバーシップ
- 場所またはネットワークの要件
- 特定のオペレーティング システムの使用
- 管理されており有効化されたデバイスの使用
これらの条件に基づいて、アクセス権を付与したり、多要素認証などのより多くのチェックを要求したり、アクセスを完全にブロックすることができます。 条件付きアクセス ポリシーの詳細と、Azure DevOps 用に設定する方法については、Microsoft Entra のドキュメントを参照してください。
Azure DevOps での条件付きアクセス ポリシーのサポート
Microsoft Entra ID に基づく組織の Web ポータルにサインインすると、Microsoft Entra ID はテナント管理者によって設定されたすべての条件付きアクセス ポリシーを検証します。 Microsoft Entra トークンを使用するように Web 認証スタックを最新化した後、Azure DevOps では、すべての対話型 (Web) フローで条件付きアクセス ポリシー検証が適用されるようになりました。
- Microsoft Entra に依存する REST API 呼び出しでパーソナルアクセストークン (PAT) を使用する場合には、サインイン ポリシーを満たしてください。
- 条件付きアクセス ポリシーからリソースとしての Azure DevOps を削除します。これにより、条件付きアクセス ポリシーが適用されなくなります。
- Web フローにのみ MFA ポリシーを適用する。ユーザーが条件付きアクセス ポリシーを満たしていない場合は、非対話型フローのアクセスをブロックします。
IP ベースの条件
非対話型フロー ポリシーで IP 条件付きアクセス ポリシーの検証を有効にした場合、AZURE DevOps は、PAT を使用して REST API 呼び出しを行う場合など、非対話型フローで IP フェンス ポリシーをチェックします。
Azure DevOps では、IPv4 アドレスと IPv6 アドレスの両方に対して IP フェンス条件付きアクセス ポリシーがサポートされています。 条件付きアクセス ポリシーによって IPv6 アドレスがブロックされる場合は、IPv6 アドレスを許可するようにポリシーを更新するようにテナント管理者に依頼してください。 また、すべての条件付きアクセス ポリシー条件に、既定の IPv6 アドレスの IPv4 マップ アドレスを含めることもできます。
ユーザーが Azure DevOps リソースへのアクセスに使用した IP アドレスとは異なる IP アドレス (VPN トンネリングで発生する可能性があります) から Microsoft Entra サインイン ページにアクセスする場合は、VPN 構成またはネットワークの設定を確認します。 テナント管理者が条件付きアクセス ポリシーに関連するすべての IP アドレスを含めるようにします。
Azure Resource Manager の対象ユーザーと条件付きアクセス ポリシー
Azure DevOps は、Microsoft Entra アクセス トークンにサインインまたは更新するときに、Azure Resource Manager (ARM) リソース (https://management.azure.com) に依存しません。 以前は、Azure DevOps では、サインインフローとトークン更新フロー中に ARM 対象ユーザーが必要になりました。 この要件は、すべての Azure DevOps ユーザーがアクセスを確保するために ARM 条件付きアクセス ポリシーをバイパスすることを管理者が許可する必要があることを意味しました。
Azure DevOps のトークンでは、ARM 対象ユーザーは必要なくなりました。 そのため、ARM の特定の対象ユーザー設定を構成しなくても、条件付きアクセス ポリシーをより効果的に管理できます。 この方法により、認証が効率化され、トークン管理の複雑さが軽減され、Azure 環境全体でセキュリティ ポリシーをより一貫して適用できます。 組織は、より広範なアクセス制御に重点を置き、対象ユーザー固有の構成によって制限されることなく、コンプライアンスとセキュリティ体制を向上させることができます。
注
ARM への継続的なアクセスが必要な場合は、次の例外があります。
- 課金管理者は、 請求とアクセスのサブスクリプションを設定するために ARM にアクセスする必要があります。
- サービス接続作成者は、 ARM ロールの割り当てとマネージド サービス ID (MSI) の更新のために ARM にアクセスする必要があります。