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

  • [アーティクル]

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 では、2020 年 3 月 2 日以降、代替資格情報認証はサポートされなくなりました。 まだ代替資格情報を使用している場合は、より安全な認証方法 (個人用アクセス トークンなど) に切り替えるよう強くお勧めします。 詳細については、こちらを参照してください。

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

Microsoft がプロジェクトを安全、利用可能、安全、プライベートAzure DevOps Services維持するために行う手順の詳細については、「Data Protection の概要」Azure DevOps Servicesホワイト ペーパーを参照してください。

アカウント

関心のあるメインの種類のアカウントは、organizationまたはプロジェクトに追加する人間のユーザー アカウントですが、Azure DevOps ではさまざまな操作を実行するための他の種類のアカウントがサポートされています。 これには、次のアカウントの種類が含まれます。

これらのドキュメント全体を通じて、ユーザーは Users Hub に追加されたすべての ID を参照できます。これには、人間のユーザーとサービス プリンシパルを含めることができます。

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

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

注意

organization所有者と Project Collection Administrators グループのメンバーには、ほとんどの機能に対するフル アクセス権が付与されます。

認証

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

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

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

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

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

Azure DevOps 内のサービスやリソースは、他のアプリケーションやサービスと統合することができます。 アプリはユーザーの資格情報を何度も要求することなくアカウントにアクセスするために、次の認証方法を使用できます。

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

資格情報の格納方法の詳細については、「 Azure DevOps の資格情報ストレージ」を参照してください。

適切な認証メカニズムを選択する方法の詳細については、「 認証のガイダンス」を参照してください。

認可

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

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

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

セキュリティ名前空間には、Azure DevOps アカウントが特定のリソースに対して特定のアクションを実行するために必要なアクセス レベルを決定するデータが格納されます。 作業項目や Git リポジトリなどのリソースの各ファミリは、一意の名前空間によって保護されます。 各セキュリティ名前空間には、0 個以上のアクセス制御リスト (ACL) が含まれています。 各 ACL には、トークン、継承フラグ、および 0 個以上のアクセス制御エントリ (ACE) のセットが含まれています。 各 ACE には、ID 記述子、許可されたアクセス許可ビットマスク、および拒否されたアクセス許可ビットマスクが含まれています。

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

セキュリティ ポリシー

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

全般

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

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

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

ユーザー ポリシー

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

Project-Scoped Users グループ

既定では、organizationに追加されたユーザーは、すべてのorganizationとプロジェクトの情報と設定を表示できます。 これには、ユーザーの一覧、プロジェクトの一覧、課金の詳細、使用状況データなど、 組織の設定からアクセスされるその他の情報が含まれます。

重要

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

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

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

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

警告

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

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

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

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

リポジトリとビルドおよびリリース パイプラインは独自のセキュリティ上の課題を引き起こすので、この記事で説明する機能を超える他の機能が採用されています。 詳細については、次の記事を参照してください。

次の手順

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