セキュリティ、認証、承認について
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 では、さまざまな操作に対して他のさまざまな種類のアカウントもサポートされています。 これには、次のアカウントの種類が含まれます。
- 組織の所有者: Azure DevOps Services organizationまたは割り当てられた所有者の作成者。 組織の所有者を見つけるには、「 組織の所有者を検索するを参照してください。
- サービス アカウント: エージェント プール サービス、PipelinesSDK などの特定のサービスをサポートするために使用される内部 Azure DevOps 組織。 サービス アカウントの説明については、「 セキュリティ グループ、サービス アカウント、およびアクセス許可」を参照してください。
- サービス プリンシパルまたはマネージド ID: Microsoft Entra アプリケーションまたはマネージド ID サードパーティ アプリケーションに代わってアクションを実行するために組織に追加されます。 一部のサービス プリンシパルは、内部操作をサポートするために内部 Azure DevOps 組織を参照します。
- ジョブ エージェント: 定期的なスケジュールで特定のジョブを実行するために使用される内部アカウント。
- サード パーティのアカウント: Web フック、サービス接続、またはその他のサード パーティ製アプリケーションをサポートするためにアクセス権を必要とするアカウント。
セキュリティ関連の記事全体を通じて、"ユーザー" とは 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 と統合できます。 ユーザーの資格情報を繰り返し要求せずにアカウントにアクセスするには、アプリで次の認証方法を使用できます。
ユーザーに代わってトークンを生成する個人用アクセス トークン (AT):
- 特定のリソースやアクティビティ (ビルド、作業項目など) へのアクセス
- 基本資格情報としてユーザー名とパスワードを必要とし、なおかつ Microsoft アカウントや Microsoft Entra の機能 (多要素認証など) をサポートしないクライアント (Xcode、NuGet など)
- Azure DevOps REST API へのアクセス
Azure DevOps OAuth REST API にアクセスするためのトークンをユーザーに代わって生成。 Accounts と Profiles API がサポートするのは OAuth のみです。
Ssh 認証 Windows 用の Git を実行している Linux、macOS、または Windows を使用するときに暗号化キーを生成し HTTPS 認証に Git 資格情報マネージャー または PAT を使用することはできません。
サービス プリンシパルまたはマネージド ID アプリケーションまたはサービスに代わって Microsoft Entra トークンを生成します。通常は、Azure DevOps リソースにアクセスする必要があるワークフローを自動化します。 従来、サービス アカウントと PAT によって実行されるほとんどのアクションは、サービス プリンシパルまたはマネージド ID を使用して実行できます。
既定では、アカウントまたはコレクションですべての認証方法の利用が可能となっています。 各方法を具体的に制限することで、アクセスを制限できます。 特定の認証方法の利用を拒否した場合、いずれのアプリも、その方法を使用してアカウントにアクセスすることはできません。 以前にアクセス権を持っていたアプリは認証エラーを受け取り、アカウントにアクセスできません。
詳細については、次の記事をご覧ください。
承認
認可では、接続しようとしている ID が、サービス、機能、オブジェクト、またはメソッドにアクセスするために必要なアクセス許可を持っていることが検証されます。 認可は、常に認証が成功した後でのみ行われます。 接続が認証されていない場合は、承認チェックが実行される前に失敗します。 認証が成功した場合でも、ユーザーまたはグループに承認がない場合は、特定のアクションが許可されていない可能性があります。
承認は、直接、またはセキュリティ グループまたはセキュリティ ロールのメンバーシップを介して、ユーザーに割り当てられたアクセス許可によって異なります。 アクセス レベルと機能フラグは、特定の機能へのアクセスを管理することもできます。 これらの承認方法の詳細については、「 アクセス許可、アクセス、およびセキュリティ グループの概要」を参照してください。
セキュリティ名前空間とアクセス許可
セキュリティ名前空間は、リソースに対する特定のアクションのユーザー アクセス レベルを決定します。
- 作業項目や Git リポジトリなどの各リソース ファミリには、一意の名前空間があります。
- 各名前空間には、0 個以上のアクセス制御リスト (ACL) が含まれています。
- 各 ACL には、トークン、継承フラグ、アクセス制御エントリ (ACE) が含まれます。
- 各 ACE には、ID 記述子、許可されたアクセス許可ビットマスク、および拒否されたアクセス許可ビットマスクがあります。
詳細については、「 セキュリティ名前空間とアクセス許可のリファレンス」を参照してください。
セキュリティ ポリシー
組織とコードをセキュリティで保護するために、さまざまなポリシーを設定できます。 具体的には、次のポリシーを有効または無効にすることができます。
全般
- プライバシー ポリシーの URL: 内部および外部のゲスト データプライバシーの処理方法を説明するカスタム ドキュメントにリンクする URL を指定します。 詳細については、「organizationのプライバシー ポリシー URL を追加する」を参照してください。
アプリケーション接続とセキュリティ ポリシー
Microsoft Entra テナント ポリシーを使用して、新しい組織の作成を目的のユーザーのみに制限します。 このポリシーは既定で無効になり、組織が Microsoft Entra ID に接続されている場合にのみ有効です。 詳細については、「 組織の作成」を参照してください。
次のポリシーは、組織内のユーザーとアプリケーションに付与されるアクセス権を決定します。
- OAuth を使用した Microsoft 以外のアプリケーション アクセス。
- SSH 認証アクセス。
- パブリック プロジェクトを許可する: 有効にすると、ユーザーはプロジェクトのメンバー以外のユーザーと、プロジェクトの成果物とサービスへの読み取り専用の制限付きアクセスを許可するパブリック プロジェクトを作成できます。 詳細については、「 プロジェクトをパブリックに作成する」を参照してください。
- 監査イベントのログ記録 - organizationの監査イベントとストリームを追跡する機能を有効にします。
- Microsoft Entra 条件付きアクセス ポリシー (CAP) の検証を有効にします。
ユーザー ポリシー
- 外部ゲスト アクセス (組織が Microsoft Entra ID. に接続されている場合のみ有効): 有効にすると、 Users ページを介して、テナントの Microsoft Entra ID のメンバーではないユーザーの電子メール アカウントに招待を送信できます。 詳細については、「外部ユーザーをorganizationに追加する」を参照してください。
- チーム管理者とプロジェクト管理者に新しいユーザーの招待を許可する: 組織が Microsoft Entra ID に接続されている場合にのみ有効です。 有効にすると、チーム管理者とプロジェクト管理者は Users ページを使用してユーザーを追加できます。 詳細については、「 プロジェクト管理者とチーム管理者からの新しいユーザー招待を制限する」を参照してください。
- アクセスの要求: 組織が Microsoft Entra ID に接続されている場合にのみ有効です。 有効にすると、ユーザーはリソースへのアクセスを要求できます。 要求により、必要に応じてレビューとアクセスを求める電子メール通知が管理者に送信されます。 詳細については、「外部ユーザーをorganizationに追加する」を参照してください。
- GitHub ユーザーの招待: 組織が Microsoft Entra ID に接続されていない場合にのみ有効です。 有効にすると、管理者は [ユーザー] ページから GitHub ユーザー アカウントに基づいて ユーザー を追加できます。 詳細については、「 Connect to GitHub/FAQを参照してください。
Project-Scoped Users グループ
既定では、組織に追加されたユーザーは、ユーザー リスト、プロジェクト リスト、課金の詳細、使用状況データなど、すべての組織とプロジェクトの情報と設定を表示できます。
重要
- このセクションで説明する制限付き可視性機能は、Web ポータルを介した操作にのみ適用されます。 REST API または
azure devops
CLI コマンドを使用すると、プロジェクト メンバーは制限付きデータにアクセスできます。 - Microsoft Entra ID で既定のアクセス権を持つ制限付きグループのメンバーであるゲスト ユーザーは、ユーザー 選択ウィンドウでユーザーを検索できません。 プレビュー機能がオフになった場合組織化またはゲスト ユーザーが制限付きグループのメンバーでない場合、ゲスト ユーザーは、想定どおりにすべての Microsoft Entra ユーザーを検索できます。
利害関係者、Microsoft Entra ゲスト ユーザー、特定のセキュリティ グループのメンバーなど、特定のユーザーを制限するには、組織の Limit ユーザーの可視性とコラボレーションを特定のプロジェクト プレビュー機能に対して有効にすることができます。 有効にすると、 Project-Scoped Users グループに追加されたユーザーまたはグループは、次の方法で制限されます。
- Organization 設定の Overview および Projects ページにのみアクセスできます。
- 接続して表示できるのは、 明示的に追加されたプロジェクトだけです。
- 接続されているプロジェクトに明示的に追加されたユーザー ID とグループ ID のみを選択できます。
詳細については、「 組織の管理」、プロジェクトなどのユーザーの可視性を制限する および Manage プレビュー機能を参照してください。
警告
Limit ユーザーの可視性と特定のプロジェクトへのコラボレーションを有効にするとプレビュー機能により、プロジェクト スコープのユーザーは、明示的なユーザー招待ではなく、Microsoft Entra グループ メンバーシップを通じて組織に追加されたユーザーを検索できなくなります。 これは予期しない動作であり、解決が進行中です。 この問題を解決するには、組織の Limit ユーザーの可視性と特定のプロジェクトへのコラボレーション プレビュー機能を無効にします。
Git リポジトリとブランチ ポリシー
コードをセキュリティで保護するために、さまざまな Git リポジトリとブランチ ポリシーを設定できます。 詳細については、次の記事を参照してください。
Azure Reposと Azure Pipelines のセキュリティ
リポジトリとビルドおよびリリース パイプラインには固有のセキュリティ上の課題があるため、この記事で説明する機能以外の追加機能が採用されています。 詳細については、次の記事を参照してください。
- Azure Pipelines のセキュリティ保護
- YAML パイプラインをセキュリティで保護する方法を計画する
- リポジトリの保護
- パイプライン リソース
- パイプラインでプロジェクトを安全に構造化するための推奨事項
- テンプレートによるセキュリティ
- パイプラインで変数とパラメーターを安全に使用する方法
- Azure Pipelines で共有インフラストラクチャをセキュリティで保護するための推奨事項
- その他のセキュリティに関する考慮事項