次の方法で共有

認証、承認、およびセキュリティ ポリシーについて

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

Azure DevOps では、セキュリティの概念の組み合わせを使用して、承認されたユーザーのみがその機能、機能、データにアクセスできるようにします。 アクセスは、ユーザーの資格情報を検証する認証と、アカウントの権利に基づいてアクセス許可を付与する承認の 2 つの主要なプロセスによって決定されます。 これらのプロセスによって、各ユーザーが Azure DevOps 内で実行できる操作が制御されます。

この記事では 、アクセス許可、アクセス、セキュリティ グループの概要について説明し、 管理者が Azure DevOps 環境を保護するために使用できるさまざまなアカウントの種類、認証と承認方法、およびセキュリティ ポリシーを理解するのに役立ちます。

アカウントの種類

  • ユーザー
  • 組織の所有者
  • サービス アカウント
  • サービス プリンシパルまたはマネージド ID
  • ジョブ エージェント

認証

  • ユーザーの資格情報
  • [Windows 認証]
  • 2 要素認証 (2FA)
  • SSH キー認証
  • Microfost Entra トークン
  • 個人用アクセス トークン
  • Oauth の構成
  • Active Directory 認証ライブラリ

承認

  • セキュリティ グループのメンバーシップ
  • ロールベースのアクセス制御
  • アクセス レベル
  • 機能フラグ
  • セキュリティ名前空間とアクセス許可

ポリシー

  • [プライバシー ポリシーの URL]
  • アプリケーション接続とセキュリティ ポリシー
  • ユーザー ポリシー
  • Git リポジトリとブランチ ポリシー

アカウントの種類

  • ユーザー
  • サービス アカウント
  • サービス プリンシパルまたはマネージド ID
  • ジョブ エージェント

認証

  • ユーザーの資格情報
  • [Windows 認証]
  • 2 要素認証 (2FA)
  • SSH キー認証
  • 個人用アクセス トークン
  • Oauth の構成
  • Active Directory 認証ライブラリ

承認

  • セキュリティ グループのメンバーシップ
  • ロール ベース アクセス許可
  • アクセス レベル
  • 機能フラグ
  • セキュリティ名前空間とアクセス許可

ポリシー

  • Git リポジトリとブランチ ポリシー

重要

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

どちらの Azure DevOps でも、計画からデプロイまでのソフトウェア開発がサポートされています。 各プラットフォームでは、Microsoft Azure のサービスとしてのプラットフォームインフラストラクチャとサービス (Azure SQL データベースを含む) を使用して、信頼性の高いグローバルに利用可能なサービスをプロジェクトに提供します。

Microsoft がプロジェクトを安全、利用可能、安全、プライベートにするための方法の詳細については、 Azure DevOps データ保護の概要を参照してください。

取引先企業

人間のユーザー アカウントが主な焦点ですが、Azure DevOps では、さまざまな操作に対して他のさまざまな種類のアカウントもサポートされています。

  • 組織の所有者: Azure DevOps Services organizationまたは割り当てられた所有者の作成者。 組織の所有者を見つけるには、「 組織の所有者を検索するを参照してください。
  • サービス アカウント: エージェント プール サービス、PipelinesSDK などの特定のサービスをサポートするために使用される内部 Azure DevOps 組織。 サービス アカウントの説明については、「 セキュリティ グループ、サービス アカウント、およびアクセス許可」を参照してください。
  • サービス プリンシパルまたはマネージド ID: Microsoft 以外のアプリケーションに代わってアクションを実行するために組織に追加された Microsoft Entra アプリケーションまたはマネージド ID 。 一部のサービス プリンシパルは、内部操作をサポートするために内部 Azure DevOps 組織を参照します。
  • ジョブ エージェント: 定期的なスケジュールで特定のジョブを実行するために使用される内部アカウント。
  • サード パーティのアカウント: Web フック、サービス接続、またはその他の Microsoft 以外のアプリケーションをサポートするためにアクセスが必要なアカウント。

セキュリティ関連の記事全体を通じて、"ユーザー" とは Users Hub に追加されたすべての ID を指します。これには、人間のユーザーとサービス プリンシパルを含めることができます。

  • サービス アカウント: エージェント プール サービス、PipelinesSDK などの特定のサービスをサポートするために使用される内部 Azure DevOps 組織。 サービス アカウントの説明については、「 セキュリティ グループ、サービス アカウント、およびアクセス許可」を参照してください。
  • サービス プリンシパルまたはマネージド ID: Microsoft 以外のアプリケーションに代わってアクションを実行するために組織に追加された Microsoft Entra アプリケーションまたはマネージド ID。 一部のサービス プリンシパルは、内部操作をサポートするために内部 Azure DevOps 組織を参照します。
  • ジョブ エージェント: 定期的なスケジュールで特定のジョブを実行するために使用される内部アカウント。
  • サード パーティのアカウント: Web フック、サービス接続、またはその他の Microsoft 以外のアプリケーションをサポートするためにアクセスが必要なアカウント。

アカウントを管理する最も効果的な方法は、 セキュリティ グループに追加することです。

注

組織の所有者とプロジェクト コレクション管理者グループのメンバーには、ほぼすべての機能へのフル アクセス権が付与されます。

認証

認証では、Azure DevOps へのサインイン時に指定された資格情報に基づいてユーザーの ID が検証されます。 Azure DevOps は、認証を管理するために複数の ID システムと統合されています。

  • Microsoft Entra ID: 大規模なユーザー グループを管理する組織に推奨されます。 堅牢でクラウドベースの認証とユーザー管理を提供します。
  • Microsoft アカウント (MSA):Azure DevOps 組織にアクセスする小規模なユーザー ベースに適しています。 クラウド認証をサポートします。
  • Active Directory (AD): 既存の AD インフラストラクチャを使用して、多数のユーザーを含むオンプレミスのデプロイに推奨されます。

Microsoft Entra ID と Microsoft アカウントはどちらもクラウド認証をサポートしています。 詳細については、「 Microsoft Entra ID を使用した Azure DevOps へのアクセスについてを参照してください。

オンプレミス環境では、Active Directory を使用してユーザー アクセスを効率的に管理します。 詳細については、「 オンプレミスのデプロイで使用するグループを設定する」を参照してください。

プログラムによる認証

使用可能な 認証方法のいずれかを選択して、ユーザー名とパスワードを繰り返し入力することなく、プログラムで Azure DevOps 組織にアクセスします。 ワークフローの自動化、REST API との統合、またはカスタム アプリケーションの構築には、次のメソッドを使用します。

  • OAuth を使用して、ユーザーに代わってアクションを実行するアプリケーションを構築します。 ユーザーはアプリに同意する必要があります。 新しいアプリの場合は、 Microsoft Entra OAuth を使用します。
  • サービス プリンシパルまたはマネージド ID を使用して、ワークフローを自動化したり、組織のリソースに定期的にアクセスするツールを構築したりします。 アプリケーション自体に代わって Microsoft Entra トークンを発行します。
  • セキュリティで保護されたクラウドベースの認証とユーザー管理には、 Microsoft Entra ID を 使用します。
  • アドホック要求または初期プロトタイプ作成には、 個人用アクセス トークン (AT) を使用します。 PAT はリークや誤用の影響を受けやすいため、長期的なアプリ開発では避けてください。

ヒント

資格情報は常に安全に保存し、認証方法を管理するためのベスト プラクティスに従ってください。

既定では、組織はすべての認証方法へのアクセスを許可します。 組織の管理者は、 セキュリティ ポリシーを無効にすることで、これらの認証方法へのアクセスを制限できます。 テナント管理者は、作成 方法を制限することで、PAT リスクをさらに軽減できます。

承認

承認は、認証された ID に、Azure DevOps の特定のサービス、機能、関数、オブジェクト、またはメソッドにアクセスするために必要なアクセス許可を持っているかどうかを決定します。 認証チェックは、認証が成功した後に常に行われます。認証に失敗した場合、承認は評価されません。 認証後も、必要なアクセス許可がない場合、ユーザーまたはグループは特定のアクションへのアクセスを拒否される可能性があります。

Azure DevOps は、ユーザーに直接割り当てられたアクセス許可、またはセキュリティ グループまたはロールを通じて継承されたアクセス許可によって承認を管理します。 アクセス レベルと機能フラグは、特定の機能へのアクセスをさらに制御できます。 これらの認可方法について詳しくは、「アクセス許可、アクセス、セキュリティ グループの概要」をご覧ください。

セキュリティ名前空間とアクセス許可

セキュリティ名前空間は、Azure DevOps リソースに対する特定のアクションのユーザー アクセス レベルを定義します。

  • 各リソース ファミリ (作業項目や Git リポジトリなど) には、独自の一意の名前空間があります。
  • 各名前空間内には、複数のアクセス制御リスト (ACL) を使用できます。
    • 各 ACL には、トークン、継承フラグ、および 1 つ以上のアクセス制御エントリ (ACE) が含まれています。
    • 各 ACE は、ID 記述子、許可されたアクセス許可のビットマスク、拒否されたアクセス許可のビットマスクを指定します。

詳細については、「 セキュリティ名前空間とアクセス許可のリファレンス」を参照してください。

セキュリティ ポリシー

組織とコードをセキュリティで保護するために、組織レベル (プロジェクト コレクション管理者) またはテナント レベル (Azure DevOps 管理者) の管理者は、ポリシースコープに応じて、さまざまなセキュリティ ポリシーを有効または無効にすることができます。 考慮すべき主なポリシーは次のとおりです。

組織が Microsoft Entra ID に接続されている場合は、次の他のセキュリティ機能にアクセスできます。

組織のセキュリティ体制を強化し、データのプライバシーとアクセスの要件に確実に準拠するように、これらのポリシーを確認して構成します。

Project-Scoped Users グループ

既定では、組織に追加されたユーザーは、ユーザー リスト、プロジェクト リスト、課金の詳細、使用状況データなど、すべての組織とプロジェクトの情報と設定を表示できます。

特定のユーザー (利害関係者、Microsoft Entra ゲスト ユーザー、特定のセキュリティ グループのメンバーなど) のアクセスを制限するには、組織の特定のプロジェクト プレビュー機能 へのユーザーの可視性とコラボレーションを制限 できます。 この機能を有効にすると、 Project-Scoped Users グループに追加されたユーザーまたはグループは、次の方法で制限されます。

  • アクセスは、組織の設定内の [概要] ページと [プロジェクト] ページに制限されます。
  • ユーザーは、 明示的に追加されたプロジェクトにのみ接続して表示できます。
  • ユーザーは、同じプロジェクトに明示的に追加されたユーザー ID とグループ ID のみを選択できます。

詳細については、「 組織の管理: プロジェクトのユーザーの可視性を制限する」および 「 プレビュー機能の管理」を参照してください。

警告

このプレビュー機能を使用する場合は、次の制限事項を考慮してください。

  • このセクションで説明する制限付き可視性機能は、Web ポータルを介した操作にのみ適用されます。 REST API または azure devops CLI コマンドを使用すると、プロジェクト メンバーは制限付きデータにアクセスできます。
  • 制限付きグループのユーザーは、Azure DevOps に明示的に追加されたユーザーのみを選択でき、Microsoft Entra グループ メンバーシップを介してアクセスできるユーザーは選択できません。
  • Microsoft Entra ID で既定のアクセス権を持つ制限付きグループのメンバーであるゲスト ユーザーは、ユーザー 選択ウィンドウでユーザーを検索できません。

Git リポジトリとブランチ ポリシー

コードをセキュリティで保護するために、さまざまな Git リポジトリとブランチ ポリシーを設定できます。 詳細については、次の記事を参照してください。

Azure Reposと Azure Pipelines のセキュリティ

リポジトリと、ビルドおよびリリース パイプラインでは、固有のセキュリティ上の課題が生じるため、この記事で説明する機能以外の他の機能も採用されています。 詳細については、次の記事を参照してください。

次の手順

アクセス許可とグループのリファレンス