ID とアクセス管理に関する推奨事項

[アーティクル]
11/15/2023

この Azure Well-Architected Framework セキュリティチェックリストの推奨事項に適用されます。

すべてのワークロードユーザー、チームメンバー、およびシステムコンポーネントに対して、厳密、条件付き、監査可能な ID およびアクセス管理 (IAM) を実装します。 必要に応じて、アクセスのみをに制限します。すべての認証と承認の実装に最新の業界標準を使用します。 ID に基づいていないアクセスを制限し、厳密に監査します。

このガイドでは、ワークロードリソースへのアクセスを試みる ID の認証と承認に関する推奨事項について説明します。

技術的な制御の観点から見ると、 ID は常に主要な境界です。このスコープには、ワークロードの端だけが含まれるわけではありません。また、ワークロード内にある個々のコンポーネントも含まれます。一般的な ID は次のとおりです。

人間。アプリケーションユーザー、管理者、オペレーター、監査者、および不適切なアクター。
[システム]。ワークロード ID、マネージド ID、API キー、サービスプリンシパル、Azure リソース。
匿名。自分が誰であるかに関する証拠を提供していないエンティティ。

定義

用語	定義
認証 (AuthN)	ID が誰であるか、何を言っているかを検証するプロセス。
認可 (AuthZ)	ID に要求されたアクションを実行するアクセス許可があるかどうかを確認するプロセス。
条件付きアクセス	指定した条件に基づいてアクションを許可するルールのセット。
IdP	ID プロバイダー (Microsoft Entra ID など)。
ペルソナ	一連の責任とアクションを持つジョブ関数またはタイトル。
事前共有キー	プロバイダーとコンシューマーの間で共有され、セキュリティで保護された合意されたメカニズムを通じて使用されるシークレットの種類。
リソース ID	プラットフォームによって管理されるクラウドリソース用に定義された ID。
ロール	ユーザーまたはグループが実行できる操作を定義するアクセス許可のセット。
スコープ	ロールの操作が許可されているさまざまなレベルの組織階層。また、システム内の機能のグループです。
セキュリティプリンシパル	アクセス許可を提供する ID。ユーザー、グループ、またはサービスプリンシパルを指定できます。すべてのグループメンバーは、同じレベルのアクセス権を取得します。
ユーザー ID	従業員や外部ユーザーなどの個人の ID。
ワークロード ID	他のサービスやリソースに対する認証に使用される、ワークロードのアプリケーション、サービス、スクリプト、コンテナー、またはその他のコンポーネントのシステム ID。

Note

ID は、 セキュリティプリンシパルと呼ばれる親の下にある他の同様の ID とグループ化できます。セキュリティグループは、セキュリティプリンシパルの例です。この階層関係により、メンテナンスが簡略化され、一貫性が向上します。 ID 属性は個々のレベルでは処理されないため、エラーの可能性も減ります。この記事では、 ID という用語にはセキュリティプリンシパルが含まれています。

ID プロバイダーのロール

ID プロバイダー (IdP) は、ユーザーをデジタル ID として格納および管理するクラウドでホストされるサービスです。

ID とアクセス管理のために信頼された IdP によって提供される機能を利用します。 IdP を置き換えるカスタムシステムを実装しないでください。 IdP システムは、毎日複数のテナント間で数十億のシグナルをキャプチャすることで、最新の攻撃ベクトルに基づいて頻繁に改善されます。 Microsoft Entra ID は、Azure クラウドプラットフォームの IdP です。

認証

認証は、ID を検証するプロセスです。要求する ID は、何らかの形式の検証可能な ID を提供するために必要です。例:

ユーザー名とパスワード。
アクセスを許可する API キーなどの事前共有シークレット。
アクセス共有シグネチャ (SAS) トークン。
TLS 相互認証で使用される証明書。

可能な限り、検証プロセスは IdP によって処理する必要があります。

承認

承認は、検証済み ID によって要求されたアクションを許可または拒否するプロセスです。アクションには、運用に関するものもあれば、リソース管理に関連しているものもあります。

承認では、ID にアクセス許可を割り当てる必要があります。IDP によって提供される機能を使用して行う必要があります。

主要な設計戦略

ワークロードの ID ニーズの全体像を把握するには、フロー、ワークロード資産、ペルソナ、および資産とペルソナが実行するアクションをカタログ化する必要があります。戦略では、ワークロードまたはそのコンポーネントに到達するフロー (外部アクセス) と、ワークロードから他のソース (インサイドアウトアクセス) に到達するフローを処理するすべてのユースケースをカバーする必要があります。

各ユースケースには、侵害想定型マインドセットを使用して設計する必要がある独自のコントロールセットが含まれる可能性があります。ユースケースまたはペルソナの ID 要件に基づいて、条件付き選択肢を特定します。すべてのユースケースで 1 つのソリューションを使用しないでください。逆に、不要な管理オーバーヘッドが発生するようにコントロールを細かくすることはできません。

ID アクセス証跡をログに記録する必要があります。これを行うと、コントロールの検証に役立ち、コンプライアンス監査にログを使用できます。

認証のすべての ID を決定する

"アウトサイドインアクセス"。 ID 設計では、さまざまな目的でワークロードにアクセスするすべてのユーザーを認証する必要があります。たとえば、API を呼び出してアプリケーションにアクセスするエンドユーザーなどです。

詳細レベルでは、ワークロードのコンポーネントでも外部からのアクセスが必要になる場合があります。たとえば、ポータルからアクセスする必要があるオペレーターや、コマンドを実行するためにコンピューティングにアクセスする必要があるオペレーターなどです。

どちらも、ペルソナが異なる ユーザー ID の 例です。
"インサイドアウトアクセス"。アプリケーションは他のリソースにアクセスする必要があります。たとえば、データプラットフォームからの読み取りまたはデータプラットフォームへの書き込み、シークレットストアからのシークレットの取得、監視サービスへのテレメトリのログ記録などです。サードパーティのサービスにアクセスする必要がある場合もあります。これらのアクセスには ワークロード ID が必要です。これにより、アプリケーションは他のリソースに対して自身を認証できます。

この概念は、コンポーネントレベルで適用されます。次の例では、コンテナーの構成を取得するためにデプロイパイプラインへのアクセスが必要になる場合があります。これらのアクセスには リソース ID が必要です。

これらの ID はすべて、IdP によって認証する必要があります。

アーキテクチャで ID を実装する方法の例を次に示します。

承認のためのアクションを決定する

次に、これらのアクションを承認できるように、認証された各 ID が何を行おうとしているのかを把握する必要があります。アクションは、必要なアクセスの種類で分割できます。

データプレーンへのアクセス。データプレーンで行われるアクションにより、インサイドアウトまたはアウトサイドインアクセスのデータ転送が発生します。たとえば、アプリケーションがデータベースからデータを読み取り、データをデータベースに書き込んだり、シークレットをフェッチしたり、監視シンクにログを書き込んだりします。コンポーネントレベルでは、レジストリとの間でイメージをプルまたはプッシュしているコンピューティングは、データプレーン操作と見なされます。
コントロールプレーンへのアクセス。コントロールプレーンで実行されるアクションにより、Azure リソースが作成、変更、または削除されます。たとえば、リソースプロパティに対する変更などです。

通常、アプリケーションはデータプレーン操作を対象としますが、操作は多くの場合、制御プレーンとデータプレーンの両方にアクセスします。承認のニーズを特定するには、リソースに対して実行できる操作アクションに注意してください。各リソースに対して許可されるアクションの詳細については、「 Azure リソースプロバイダーの操作」を参照してください。

ロールベースの承認を提供する

各 ID の責任に基づいて、許可する必要があるアクションを承認します。 ID は、必要以上に実行することはできません。承認規則を設定する前に、要求を行うユーザーまたは要求の内容、そのロールの実行が許可される内容、および実行できる範囲を明確に理解しておく必要があります。これらの要因により、ID、ロール、スコープを組み合わせた選択肢が生まれます。

ワークロード ID を例として考えてみましょう。アプリケーションはデータベースへのデータプレーンアクセス権を持っている必要があるため、データリソースに対する読み取りおよび書き込みアクションを許可する必要があります。ただし、アプリケーションではシークレットストアへのコントロールプレーンアクセスが必要ですか? ワークロード ID が不適切なアクターによって侵害された場合、機密性、整合性、可用性の観点から、システムに与える影響は何ですか?

ロール割り当て

ロールは、ID に割り当てられる 一連のアクセス許可 です。 ID によるタスクの完了のみを許可するロールを割り当てます。それ以上は実行しません。ユーザーのアクセス許可がジョブ要件に制限されている場合は、システム内の疑わしい動作または未承認の動作を識別する方が簡単です。

次のような質問をします。

読み取り専用アクセスで十分ですか?
ID には、リソースを削除するためのアクセス許可が必要ですか?

ユーザー、アプリケーション、またはサービスが Azure リソースに対して持つアクセスレベルを制限すると、潜在的な攻撃対象領域が減ります。 特定のタスクを実行するために必要な最小限のアクセス許可のみを付与すると、攻撃が成功したり、不正アクセスが発生したりするリスクが大幅に軽減されます。たとえば、セキュリティチームは、すべての技術環境のセキュリティ属性への読み取り専用アクセスのみを必要とします。このレベルは、リスク要因を評価し、潜在的な軽減策を特定し、リスクについて報告するのに十分です。

組織の構造とチームのorganizationにより、ユーザーがより多くのアクセス権を必要とするシナリオがあります。さまざまなロール間に重複がある場合や、1 人のユーザーが複数の標準ロールを実行している可能性があります。この場合は、これらのユーザーごとにカスタムロールを作成する代わりに、ビジネス機能に基づく複数のロールの割り当てを使用します。これにより、ロールの管理が容易になります。

個々のリソースまたはユーザーを特に参照するアクセス許可を避けます。 詳細でカスタムのアクセス許可は、類似した新しいリソースに意図を伝えないので、複雑さと混乱を招きます。これにより、保守が困難で、セキュリティと信頼性の両方に悪影響を及ぼす複雑なレガシ構成が作成される可能性があります。

トレードオフ: 詳細なアクセス制御アプローチにより、ユーザーアクティビティの監査と監視が向上します。

ロールには、 関連付けられたスコープもあります。ロールは、許可された管理グループ、サブスクリプション、リソースグループ、またはリソーススコープ、または別のカスタムスコープで動作できます。 ID にアクセス許可のセットが限られている場合でも、ID のジョブ機能の外部にあるリソースを含むようにスコープを広げることは危険です。たとえば、すべてのソースコードとデータへの読み取りアクセスは危険であり、制御する必要があります。

ロールベースのアクセス制御 (RBAC) を使用して、ID にロールを割り当てます。アクセス制御を一貫して適用し、厳格に取り消すことができる機能を利用するには、常に IdP 提供の RBAC を使用します。

組み込みのロールを使用します。 ほとんどのユースケースをカバーするように設計されています。カスタムロールは強力で、場合によっては役に立ちますが、組み込みのロールが機能しないシナリオに予約する必要があります。カスタマイズは複雑さにつながり、混乱を増やし、自動化をより複雑で、困難で、脆弱なものにします。これらの要素はすべてセキュリティに悪影響を及ぼします。

最小限の特権で始まるロールを付与し、運用またはデータアクセスのニーズに基づいてさらに追加します。技術チームには、アクセス許可を実装するための明確なガイダンスが必要です。

RBAC をきめ細かく制御する場合は、アクションや属性などのコンテキストに基づいてロールの割り当てに条件を追加します。

条件付きアクセスの選択

すべての ID に同じレベルのアクセス権を付与しないでください。次の 2 つのメイン要因に基づいて決定します。

時間。 ID が環境にアクセスできる期間。
特権。アクセス許可のレベル。

これらの要因は相互に排他的なわけではありません。より多くの特権と無制限のアクセス期間を持つ侵害された ID は、システムとデータをより細かく制御したり、そのアクセスを使用して環境を変更したりすることができます。これらのアクセス要因を予防措置として制約し、爆発半径を制御します。

Just-In Time (JIT) アプローチでは、必要な場合にのみ必要な特権が提供されます。
Just Enough Access (JEA) では、必要な特権のみが提供されます。

時間と特権が主な要因ですが、他にも適用される条件があります。たとえば、アクセス元のデバイス、ネットワーク、場所を使用してポリシーを設定することもできます。

ユーザー ID と場所、デバイスの正常性、ワークロードコンテキスト、データ分類、異常などのパラメーターを含む、承認されていないアクセスをフィルター処理、検出、ブロックする強力な制御を使用します。

たとえば、ワークロードには、ベンダー、パートナー、顧客などのサードパーティ ID からアクセスする必要がある場合があります。正社員に提供する既定のアクセス許可ではなく、適切なレベルのアクセス権が必要です。外部アカウントを明確に区別すると、これらのベクトルから発生する攻撃の防止と検出が容易になります。

IdP の選択は、その差別化を提供し、最小限の特権に基づいてアクセス許可を付与する組み込み機能を提供し、組み込みの脅威インテリジェンスを提供できる必要があります。これには、アクセス要求とサインインの監視が含まれます。Azure IdP は Microsoft Entra ID です。詳細については、この記事の「Azure ファシリテーション」セクションを参照してください。

重大な影響アカウント

管理 ID を実行するタスクには、これらのシステムとアプリケーションの広範なセットへの特権アクセスが必要であるため、影響が最も大きいセキュリティリスクの一部が導入されます。侵害や誤用は、ビジネスとその情報システムに悪影響を及ぼす可能性があります。管理のセキュリティは、最も重要なセキュリティ領域の 1 つです。

断固とした敵対者に対して特権アクセス権を保護するには、これらのシステムからリスクを切り離すための完全で十分に考慮されたアプローチを採用する必要があります。いくつかの戦略を次に示します。

重大な影響を与えるアカウントの数を最小限に抑えます。
既存の ID の特権を昇格する代わりに、個別のロールを使用します。
IdP の JIT 機能を使用して、永続的または永続的なアクセスを避けます。ガラス割れ目の状況では、緊急アクセスプロセスに従ってください。
パスワードレス認証や多要素認証などの最新のアクセスプロトコルを使用します。これらのメカニズムを IdP に外部化します。
条件付きアクセスポリシーを使用して、主要なセキュリティ属性を適用します。
使用されていない管理アカウントの使用を停止します。

複数の環境で 1 つの ID を使用し、1 つの ID をユーザーまたはプリンシパルに関連付けます。クラウド環境とオンプレミス環境全体の ID の一貫性により、人的エラーとその結果として生じるセキュリティリスクが軽減されます。リソースを管理する両方の環境のチームは、セキュリティ保証を満たすために、一貫性のある信頼できるソースが必要です。中央の ID チームと連携して、ハイブリッド環境の ID が確実に同期されるようにします。

リスク: 高い特権 ID の同期に関連するリスクがあります。攻撃者はオンプレミスの資産を完全に制御でき、これによりクラウドアカウントの侵害が成功する可能性があります。攻撃対象領域に追加できるアカウントを除外して、同期戦略を評価します。

ID ライフサイクルを管理するプロセスを確立する

ID へのアクセスは、ID がアクセスするリソースよりも長く続く必要があります。 チーム構造またはソフトウェアコンポーネントに変更がある場合に ID を無効または削除するプロセスがあることを確認します。

このガイダンスは、ソース管理、データ、コントロールプレーン、ワークロードユーザー、インフラストラクチャ、ツール、データ、ログ、メトリック、およびその他のエンティティの監視に適用されます。

デジタル ID、高い特権を持つユーザー、外部/ゲストユーザー、ワークロードユーザーのライフサイクルを管理するための ID ガバナンスプロセスを確立します。アクセスレビューを実装して、ID がorganizationまたはチームから離れると、ワークロードのアクセス許可が削除されるようにします。

非識別子ベースのシークレットを保護する

事前共有キーなどのアプリケーションシークレットは、システム内の脆弱なポイントと見なす必要があります。双方向通信では、プロバイダーまたはコンシューマーが侵害された場合、重大なセキュリティリスクが発生する可能性があります。これらのキーは、運用プロセスを導入するため、負担になる可能性もあります。

可能な場合は、シークレットの使用を避け、 リソースだけでなく、アプリケーション自体へのユーザーアクセスに ID ベースの認証を使用することを検討してください。

次の一覧では、ガイダンスの概要を示します。詳細については、「アプリケーションシークレットの推奨事項」を参照してください。

これらのシークレットは、シークレットストアから動的にプルできるエンティティとして扱います。アプリケーションコード、IaC スクリプト、デプロイパイプライン、またはその他の成果物でハードコーディングしないでください。
シークレットを取り消す機能があることを確認します。
キーのローテーションや有効期限などのタスクを処理する運用プラクティスを適用します。

ローテーションポリシーの詳細については、「2 つの認証資格情報セットを持つリソースのシークレットのローテーションを自動化する」と「チュートリアル: Key Vaultでの証明書の自動ローテーション頻度の更新」を参照してください。

開発環境を安全に保つ

すべてのコードとスクリプト、パイプラインツール、ソース管理システムは、ワークロード資産と見なす必要があります。 書き込みへのアクセスは、 自動化とピアレビューを使用してゲートする必要があります。 ソースコードへの読み取りアクセスは、 必要に応じてロールに制限する必要があります。コードリポジトリにはバージョン管理が必要であり、ピアによる セキュリティコードレビュー は、開発ライフサイクルと統合された通常のプラクティスである必要があります。 リソースを定期的にスキャンし、最新の脆弱性を特定するプロセスが必要です。

ワークロード ID を使用して、GitHub などのデプロイ環境からリソースへのアクセスを許可します。

監査証跡を維持する

ID 管理の 1 つの側面は、システムを監査可能にすることです。監査では、侵害想定戦略が有効かどうかを検証します。監査証跡を維持すると、次のことが役立ちます。

ID が強力な認証で認証されていることを確認します。否認攻撃を防ぐために、すべてのアクションを追跡可能にする必要があります。
弱い認証プロトコルまたは不足している認証プロトコルを検出 し、ユーザーとアプリケーションのサインインに関する可視性と分析情報を取得します。
セキュリティと コンプライアンスの要件 に基づいて ID からワークロードへのアクセスを評価し、ユーザーアカウントのリスク、デバイスの状態、設定したその他の条件とポリシーを考慮します。
コンプライアンス要件からの進行状況または逸脱を追跡します。

ほとんどのリソースにはデータプレーンアクセス権があります。リソースにアクセスする ID と、リソースが実行するアクションを把握する必要があります。この情報は、セキュリティ診断に使用できます。

詳細については、「セキュリティ監視と脅威分析に関する推奨事項」を参照してください。

Azure ファシリテーション

使用可能なすべてのデータポイントを考慮し、条件付きアクセスを使用する最新の認証プロトコルを常に使用することをお勧めします。 Microsoft Entra ID は、Azure での ID とアクセス管理を提供します。 Azure の管理プレーンをカバーし、ほとんどの Azure サービスのデータプレーンと統合されています。 Microsoft Entra ID は、ワークロードサブスクリプションに関連付けられているテナントです。 ID とその許可されたアクセス許可を追跡および管理し、全体的な管理を簡素化して、監視や人的エラーのリスクを最小限に抑えます。

これらの機能は、ユーザーセグメントの同じMicrosoft Entra ID とアクセス許可モデルにネイティブに統合されます。

Microsoft Entra ID。従業員とエンタープライズリソース。
Microsoft Entra 外部 ID。パートナー。
Azure AD B2C。顧客。
フェデレーション互換性リストMicrosoft Entraします。サードパーティのフェデレーションソリューション。

Microsoft Authentication Library (MSAL) またはプラットフォーム機能 (Web アプリの認証など) を使用して、カスタムアプリケーションの認証と承認にMicrosoft Entra ID を使用できます。 Azure の管理プレーン、ほとんどの Azure サービスのデータプレーン、アプリケーションの統合機能について説明します。

[Microsoft Entra ID の新機能] にアクセスすると、最新の状態を維持できます。

トレードオフ: Microsof Microsoft Entra ID は、他の基本的なサービスと同様に単一障害点です。 Microsoft によって停止が修正されるまで、回避策はありません。ただし、Microsoft Entraの豊富な機能セットは、カスタムソリューションを使用するリスクよりも高くなります。

Azure では、OAuth2 や OpenID Connect などのオープンプロトコルがサポートされています。独自のフローを設計する代わりに、これらの標準的な認証と承認のメカニズムを使用することをお勧めします。

Azure RBAC

Azure RBAC は、Microsoft Entra ID のセキュリティプリンシパルを表します。すべてのロールの割り当ては、Azure RBAC を介して行われます。必要なほとんどのアクセス許可を提供する組み込みロールを利用します。詳細については、「Microsoft Entra 組み込みロール」を参照してください。

いくつかのユースケースを次に示します。

ロールにユーザーを割り当てることで、Azure リソースへのアクセスを制御できます。詳細については、「Microsoft Entra ID でのロールベースのアクセス制御の概要」を参照してください。
Privileged Identity Managementを使用すると、影響の大きい ID に関連付けられているロールに対して、時間ベースおよび承認ベースのロールのアクティブ化を提供できます。詳細については、「Privileged Identity Managementとは」を参照してください。

RBAC の詳細については、「 Azure RBAC のベストプラクティス」を参照してください。

属性ベースのコントロールの詳細については、「 Azure ABAC とは」を参照してください。

ワークロード ID

Microsoft Entra ID は、アプリケーションの ID を処理できます。 アプリケーションに関連付けられているサービスプリンシパルは、そのアクセススコープを指定できます。

詳細については、「ワークロード ID とは」を参照してください。

サービスプリンシパルは、マネージド ID を使用するときにも抽象化されます。 利点は、Azure がアプリケーションのすべての資格情報を管理することです。

すべてのサービスがマネージド ID をサポートしているわけではありません。マネージド ID を使用できない場合は、サービスプリンシパルを使用できます。ただし、サービスプリンシパルを使用すると、管理オーバーヘッドが増加します。詳細については、「Azure リソースのマネージド ID とは」を参照してください。

リソース ID

マネージド ID の概念は 、Azure リソースに拡張できます。 Azure リソースでは、マネージド ID を使用して、Microsoft Entra認証をサポートする他のサービスに対して自身を認証できます。詳細については、「マネージド ID を使用して他のサービスにアクセスできる Azure サービス」を参照してください。

条件付きアクセスポリシー

条件付きアクセスは、アクセスの 決定に関するポリシーを記述します。条件付きアクセスを使用するには、ユースケースに必要な制限事項を理解する必要があります。 Microsoft Entra条件付きアクセスを構成するには、運用上のニーズに基づいてアクセスポリシーを設定します。

詳細については、「条件付きアクセス: ユーザー、グループ、ワークロード ID」を参照してください。

グループアクセス管理

特定のユーザーにアクセス許可を付与する代わりに、Microsoft Entra ID のグループにアクセス権を割り当てます。グループが存在しない場合は、ID チームと協力して作成します。その後、Azure の外部でグループメンバーを追加および削除し、アクセス許可が最新であることを確認できます。また、メーリングリストなどの他の目的でグループを使用することもできます。

詳細については、「Microsoft Entra ID のグループを使用したアクセス制御のセキュリティ保護」を参照してください。

脅威の検出

Microsoft Entra ID 保護は、ID ベースのリスクを検出、調査、修復するのに役立ちます。詳細については、「 Identity Protection とは」を参照してください。

脅威検出は、疑わしいアクティビティのアラートに反応したり、アクティビティログ内の異常なイベントを事前に検索したりする形式になります。 Microsoft Sentinel の User and Entity Behavior Analytics (UEBA) を使用すると、疑わしいアクティビティを簡単に検出できます。詳細については、「UEBA を使用して高度な脅威を特定する」を参照してください。

ハイブリッドシステム

Azure では、既存の Active Directory で高い特権を持つMicrosoft Entra ID にアカウントを同期しないでください。この同期は、既定の Microsoft Entra Connect Sync 構成でブロックされるため、この構成をカスタマイズしていないことを確認するだけで済みます。

Microsoft Entra ID でのフィルター処理の詳細については、「Microsoft Entra接続同期: フィルター処理の構成」を参照してください。

ID ログ

Azure リソースの診断設定を有効 にして、監査証跡として使用できる情報を出力します。診断情報には、どの ID がどのリソースへのアクセスを試み、それらの試行の結果が示されます。収集されたログは Azure Monitor に送信されます。

トレードオフ: ログの格納に使用されるデータストレージが原因で、ログにコストが発生します。また、特にコードや、アプリケーションに追加するログソリューションに対して、パフォーマンスに影響を与える可能性があります。

例

次の例は、ID の実装を示しています。必要なアクセスレベルを提供するために、さまざまな種類の ID が一緒に使用されます。

ID コンポーネント

システムマネージド ID。 Microsoft Entra ID を使用すると、Azure Key Vaultやデータストアなど、ユーザーが直面しないサービスデータプレーンにアクセスできます。これらの ID は、ワークロードコンポーネント、デプロイエージェント、およびチームメンバーの Azure 管理プレーンへのアクセスも RBAC を介して制御します。
ワークロード ID。 Azure Kubernetes Service (AKS) クラスター内のアプリケーションサービスは、ワークロード ID を使用して、ソリューション内の他のコンポーネントに対して自身を認証します。
マネージド ID。クライアントロールのシステムコンポーネントでは、ビルドエージェントを含むシステムマネージド ID が使用されます。
人間の ID。ユーザーとオペレーターの認証は、Microsoft Entra ID またはMicrosoft Entra ID (ネイティブ、B2B、または B2C) に委任されます。

事前共有シークレットのセキュリティは、どのアプリケーションでも重要です。 Azure Key Vault では、Redis やサードパーティのシークレットなど、これらのシークレットのセキュリティで保護されたストレージメカニズムが提供されます。

ローテーションメカニズムは、シークレットが侵害されないようにするために使用されます。 OAuth 2 と OpenID Connect のMicrosoft ID プラットフォーム実装のトークンは、ユーザーの認証に使用されます。

Azure Policyは、アクセスポリシーの代わりに RBAC を使用Key Vaultなどの ID コンポーネントを確実に使用するために使用されます。 JIT と JEA は、人間のオペレーターに従来の永続的なアクセス許可を提供します。

アクセスログは、Azure Diagnosticsまたはコードコンポーネントのコードを介して、すべてのコンポーネントで有効になります。

セキュリティチェックリスト

推奨事項の完全なセットを参照してください。

セキュリティチェックリスト