次の方法で共有

セキュリティ、認証、承認について

  • [アーティクル]

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

Azure DevOps では、さまざまなセキュリティの概念を採用して、承認されたユーザーのみが機能、機能、データにアクセスできるようにします。 ユーザーは、セキュリティ資格情報の認証と、特定の機能にアクセスするためのアカウント権利の承認を通じて、Azure DevOps にアクセスできます。

この記事は、「 アクセス許可、アクセス、セキュリティ グループの概要」に記載されている情報に基づいています。 管理者は、Azure DevOps のセキュリティ保護に使用されるアカウントの種類、認証方法、承認方法、ポリシーを理解することでメリットを得ることができます。

アカウントの種類

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

認証

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

承認

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

ポリシー

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

アカウントの種類

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

認証

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

承認

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

ポリシー

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

重要

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

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

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

取引先企業

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

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

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

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

Note

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

認証

認証では、Azure DevOps へのサインイン時に指定された資格情報に基づいてアカウントの ID が検証されます。 これらのシステムは、次の他のシステムのセキュリティ機能と統合され、これに依存します。

  • Microsoft Entra ID
  • Microsoft アカウント (MSA)
  • Active Directory (AD)

Microsoft Entra ID と MSA では、クラウド認証がサポートされています。 大規模なユーザー グループを管理するために Microsoft Entra ID を使用することをお勧めします。 Azure DevOps 組織にアクセスする小規模なユーザー ベースの場合は、Microsoft アカウントで十分です。 詳細については、「Microsoft Entra ID を使用した Azure DevOps へのアクセスについて」を参照してください。

オンプレミスのデプロイでは、大規模なユーザー グループを管理するために AD をお勧めします。 詳細については、「 オンプレミスのデプロイで使用するグループを設定する」を参照してください。

認証方法 (他のサービスやアプリとの統合)

他のアプリケーションやサービスは、Azure DevOps と統合できます。 ユーザーの資格情報を繰り返し要求せずにアカウントにアクセスするには、アプリで次の認証方法を使用できます。

既定では、アカウントまたはコレクションですべての認証方法の利用が可能となっています。 各方法を具体的に制限することで、アクセスを制限できます。 特定の認証方法の利用を拒否した場合、いずれのアプリも、その方法を使用してアカウントにアクセスすることはできません。 以前にアクセス権を持っていたアプリは認証エラーを受け取り、アカウントにアクセスできません。

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

承認

認可では、接続しようとしている ID が、サービス、機能、オブジェクト、またはメソッドにアクセスするために必要なアクセス許可を持っていることが検証されます。 認可は、常に認証が成功した後でのみ行われます。 接続が認証されていない場合は、承認チェックが実行される前に失敗します。 認証が成功した場合でも、ユーザーまたはグループに承認がない場合は、特定のアクションが許可されていない可能性があります。

承認は、直接、またはセキュリティ グループまたはセキュリティ ロールのメンバーシップを介して、ユーザーに割り当てられたアクセス許可によって異なります。 アクセス レベルと機能フラグは、特定の機能へのアクセスを管理することもできます。 これらの承認方法の詳細については、「 アクセス許可、アクセス、およびセキュリティ グループの概要」を参照してください。

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

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

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

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

セキュリティ ポリシー

組織とコードをセキュリティで保護するために、さまざまなポリシーを設定できます。 具体的には、次のポリシーを有効または無効にすることができます。

全般

アプリケーション接続とセキュリティ ポリシー

Microsoft Entra テナント ポリシーを使用して、新しい組織の作成を目的のユーザーのみに制限します。 このポリシーは既定で無効になり、組織が Microsoft Entra ID に接続されている場合にのみ有効です。 詳細については、「組織の作成を制限する」を参照してください。

次のポリシーは、組織内のユーザーとアプリケーションに付与されるアクセス権を決定します。

ユーザー ポリシー

  • 外部ゲスト アクセス (組織が Microsoft Entra ID に接続されている場合にのみ有効):有効にすると、[ユーザー] ページを介して、テナントの Microsoft Entra ID のメンバーではないユーザーの電子メール アカウントに招待を送信できます。 詳細については、「外部ユーザーをorganizationに追加する」を参照してください。
  • チーム管理者とプロジェクト管理者に新しいユーザーの招待を許可する: 組織が Microsoft Entra ID に接続されている場合にのみ有効です。 有効にすると、チーム管理者とプロジェクト管理者は、[ユーザー] ページを使用してユーザーを追加できます。 詳細については、「 プロジェクト管理者とチーム管理者からの新しいユーザー招待を制限する」を参照してください。
  • アクセスを要求する: 組織が Microsoft Entra ID に接続されている場合にのみ有効です。 有効にすると、ユーザーはリソースへのアクセスを要求できます。 要求により、必要に応じてレビューとアクセスを求める電子メール通知が管理者に送信されます。 詳細については、「外部ユーザーをorganizationに追加する」を参照してください。
  • GitHub ユーザーを招待する: 組織が Microsoft Entra ID に接続されていない場合にのみ有効です。 有効にすると、管理者は [ユーザー] ページから GitHub ユーザー アカウントに基づいて ユーザー を追加できます。 詳細については、「GitHub への接続/FAQ」を参照 してください。

Project-Scoped Users グループ

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

重要

  • このセクションで説明する制限付き可視性機能は、Web ポータルを介した操作にのみ適用されます。 REST API または azure devops CLI コマンドを使用すると、プロジェクト メンバーは制限付きデータにアクセスできます。
  • Microsoft Entra ID で既定のアクセス権を持つ制限付きグループのメンバーであるゲスト ユーザーは、ユーザー 選択ウィンドウでユーザーを検索できません。 組織のプレビュー機能がオフになっている場合、またはゲスト ユーザーが制限付きグループのメンバーでない場合、ゲスト ユーザーは、想定どおりにすべての Microsoft Entra ユーザーを検索できます。

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

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

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

警告

[ユーザーの 可視性とコラボレーションを特定のプロジェクト に限定する] プレビュー機能を有効にすると、プロジェクト スコープのユーザーは、明示的なユーザー招待ではなく、Microsoft Entra グループ メンバーシップを通じて組織に追加されたユーザーを検索できなくなります。 これは予期しない動作であり、解決が進行中です。 この問題を解決するには、組織の特定の プロジェクト プレビュー機能にユーザーの可視性とコラボレーションを制限する機能を無効にします。

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

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

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

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

次の手順

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