ID およびアクセス管理に関する推奨事項

以下の Azure Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に対応します。

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

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

• 人間。 アプリケーション ユーザー、管理者、オペレーター、監査者、不正なアクター。

• [システム]。 ワークロード ID、マネージド ID、API キー、サービス プリンシパル、Azure リソース。

• 匿名。 自分が誰であるかに関する証拠を提供していないエンティティ。

定義 

ID プロバイダーのロール

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

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

認証

認証は、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 リソースに対して持つアクセス レベルを制限すると、潜在的な攻撃面が減少します。 特定のタスクを実行するために必要な最小限のアクセス許可のみを付与すると、攻撃が成功したり、承認されていないアクセスが発生したりするリスクが大幅に軽減されます。 たとえば、セキュリティ チームに必要なのは、すべての技術環境のセキュリティ属性に対する読み取り専用アクセスのみです。 リスク要因を評価し、潜在的な軽減策を特定して、リスクに関するレポートを作成するには、そのレベルで十分です。

組織構造やチーム組織上の理由から、ユーザーがそれ以上のアクセスを必要とするシナリオがあります。 さまざまなロール間に重複がある場合や、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 が組織またはチームから離れたときに、そのワークロードのアクセス許可が削除されるようにします。

ID ベースでないシークレットを保護する

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

可能な場合はシークレットの使用を避け、リソースだけでなく、アプリケーション自体へのユーザー アクセスに 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。 Customers.

• Microsoft Entra フェデレーション互換性リスト。 サード パーティのフェデレーション ソリューション。

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

最新の情報については、「Microsoft Entra ID の新機能」を参照してください。

トレードオフ: 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 条件付きアクセスを構成します。

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

グループ アクセス管理

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

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

脅威の検出

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

脅威の検出では、疑わしいアクティビティのアラートに対する対応や、アクティビティ ログ内での、異常なイベントの予防的検索という形をとる場合があります。 Microsoft Sentinel のユーザー/エンティティ行動分析 (UEBA) を使用すると、疑わしいアクティビティを簡単に検出できます。 詳細については、「UEBA を使用した高度な脅威の特定」を参照してください。

ハイブリッド システム

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

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

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 は、Key Vault などの ID コンポーネントがアクセス ポリシーではなく RBAC を使用するようにするために使用されます。 JIT と JEA は、人間のオペレーターに従来の継続的なアクセス許可を提供します。

アクセス ログは、Azure Diagnostics を介して、またはコード コンポーネントの場合はコードを介して、すべてのコンポーネントで有効化されます。

関連リンク

• チュートリアル: 2 セットの認証資格情報があるリソースを対象にシークレットのローテーションを自動化する
• チュートリアル - Key Vault における証明書の自動ローテーション頻度を更新する
• Microsoft Entra ID の新機能
• Microsoft Entra ビルトイン ロール
• Microsoft Entra ID でのロールベースのアクセス制御の概要
• ワークロード ID とは
• Azure リソースのマネージド ID とは
• 条件付きアクセス: ユーザー、グループ、ワークロード ID
• Microsoft Entra Connect Sync: フィルター処理を構成する

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

レコメンデーションの完全なセットを参照してください。