アイデンティティとアクセス管理に関する推奨事項

この Power Platform Well-Architected Security チェックリストのレコメンデーションに適用されます。

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

技術的な制御の観点から見ると、アイデンティティは常に主要な境界です。 この範囲には、ワークロード末端の部分だけが含まれるわけではありません。 ワークロード内にある個々のコンポーネントも含まれます。

代表的な ID は次のとおりです:

• 人間。 アプリケーション ユーザー、管理者、オペレーター、監査人、悪意のあるユーザー。
• システム。 ワークロード ID、マネージド ID、API キー、サービス プリンシパル、Azure リソース。
• 匿名。 自分たちが何者なのか、何の証拠も示していないエンティティ。

定義

Power Platform の ID プロバイダーとしての Microsoft Entra ID

すべて Power Platform 製品の使用 Microsoft Entra ID (旧 Azure Active Directory または Azure AD) を使用します。 Entra ID を使用すると、組織はハイブリッド環境とマルチクラウド環境の ID を保護および管理できます。 Entra ID は、Power Platform リソースへのアクセスを必要とするビジネス ゲストの管理にも不可欠です。 Power Platform はまた、サービス プリンシパル機能を使用して Power Platform API と統合する必要がある他のアプリケーションを管理するために、Entra ID を使用します。 Entra ID を使用することで、Power Platform は条件付きアクセスや継続的なアクセス評価のような Entra ID のより高度なセキュリティ機能を活用することができます。

認証

認証は、ID を確認するプロセスです。 要求する ID は、何らかの形式の検証可能な ID を提供する必要があります。 例:

• ユーザー名とパスワード。
• アクセスを許可する API キーのような事前共有シークレット。
• 共有アクセス署名 (SAS) トークン。
• トランスポート層セキュリティ (TLS) 相互認証で使用される証明書。

Power Platform 認証には、ユーザーのブラウザと Power Platform または Azure サービスの間の一連の要求、応答、およびリダイレクトが含まれます。 この順序は、Microsoft Entra ID 認証コード付与フローに従います。

データソースへの接続と認証は、Power Platform サービスに対する認証とは別に実行されます。 詳細については、データソースへの接続と認証を参照してください。

認可

Power Platform は、業界標準の OAuth 2.0 プロトコルを使用して、すべての API 呼び出しの認証に Microsoft Entra ID Microsoft Identity Platform を使用します。

主要な設計戦略

ワークロードの ID ニーズを理解するには、ユーザーとシステムのフロー、ワークロード アセット、ペルソナ、それらが実行するアクションをリストする必要があります。

それぞれの使用用途には、おそらく独自のコントロールのセットがあり、それを想定して設計する必要があります。 使用用途または ID のアイデンティティ要件に基づいて、条件の選択肢を特定します。 ひとつのソリューションをすべての使用用途に使用することは避けてください。 逆に、不必要な管理オーバーヘッドを発生させるようなきめ細かい管理はすべきではありません。

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

認証のためのすべての ID の決定

アウトサイド イン アクセス。 Power Platform 認証には、ユーザーのブラウザと Power Platform または Azure サービスの間の一連の要求、応答、およびリダイレクトが含まれます。 この順序は、Microsoft Entra ID 認証コード付与フローに従います。 Power Platform は、さまざまな目的でワークロードにアクセスするすべてのユーザーを自動的に認証します。

インサイド アウト アクセス。 ワークロードは他のリソースにアクセスする必要があります。 たとえば、データプラット フォームからの読み取りやデータ プラットフォームへの書き込み、シークレット ストアからのシークレットの取得、モニタリング サービスへのテレメトリのログ記録などです。 サードパーティのサービスへのアクセスが必要になる場合もあります。 これらはすべてワークロード ID の要件です。 ただし、リソース ID の要件も考慮する必要があります。たとえば、展開パイプラインがどのように実行され、認証されるかなどです。

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

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

• データ プレーン アクセス。 データ プレーンで行われるアクションにより、データ転送が発生します。 たとえば、アプリケーションが Microsoft Dataverse からデータを読み書きしたり、Application Insights にログを書き込んだりします。

• コントロール プレーン アクセス。 制御プレーンで行われるアクションによって、Power Platform リソースが作成、変更、または削除されます。 たとえば、環境プロパティの変更やデータ ポリシーの作成などです。

アプリケーションは通常、データ プレーン操作を対象としますが、操作は多くの場合、コントロール プレーンとデータ プレーンの両方にアクセスします。

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

各 ID の責任に基づいて、許可すべきアクションを承認します。 ID には、必要以上のことを行う権限を与えるべきではありません。 承認ルールを設定する前に、誰が、あるいは何がリクエストしているのか、そのロールに何が許されているのか、どこまでできるのかを明確に理解する必要があります。 これらの要素は、ID、役割、範囲を組み合わせた選択につながります。

次の点について検討してください。

• ワークロードは、読み取りと書き込みの両方で Dataverse へのデータプレーンアクセスが必要ですか？
• ワークロードは環境プロパティにもアクセスする必要がありますか？
• 悪意のある人物によって ID が侵害された場合、機密性、整合性、可用性の面でシステムにどのような影響があるでしょうか？
• ワークロードには永続的なアクセスが必要ですか、それとも条件付きアクセスを検討できますか？
• ワークロードは、管理者権限または昇格された権限を必要とするアクションを実行しますか？
• ワークロードはサードパーティのサービスとどのようにやり取りしますか？

ロールの割り当て

ロールとは、ID に割り当てられた 権限のセット です。 ID にタスクの完了のみを許可し、それ以上は許可しないロールを割り当てます。 ユーザーの権限が職務要件に制限されている場合、システム内での不審な動作や不正な動作を特定しやすくなります。

次のような質問です:

• 読み取り専用で十分ですか？
• ID にはリソースを削除する権限が必要ですか?
• ロールには、自分が作成したレコードへのアクセスのみが必要ですか？
• ユーザーが所属するビジネス ユニットに基づく階層アクセスは必須ですか？
• 役割には管理者権限または昇格された権限が必要ですか？
• ロールにはこれらの権限への永続的なアクセスが必要ですか？
• ユーザーが転職した場合はどうなりますか？

ユーザー、アプリケーション、またはサービスのアクセス レベルを制限すると、潜在的な攻撃対象領域が縮小されます。 特定のタスクを実行するために必要な最小限の権限のみを付与すると、攻撃が成功したり不正アクセスが発生したりするリスクが大幅に軽減されます。 たとえば、開発者が必要とするのは開発環境へのメーカー アクセスだけで、運用環境へのメーカーアクセスは必要ない、リソースを作成するアクセスだけで、環境プロパティを変更するアクセスは必要ない、Dataverse のデータを読み書きするアクセスだけで、Dataverse テーブルのデータモデルや属性を変更するアクセスは必要ない、などです。

個々のユーザーを対象とした権限は避けてください。 きめ細かくカスタム化されたアクセス許可は、複雑さと混乱を引き起こし、ユーザーの役割の変更や業務上の移動、あるいは同様の認証要件を持つ新しいユーザーのチームへの参加に伴い、維持が困難になる可能性があります。 この状況では、保守が困難な複雑なレガシー構成が作成され、セキュリティと信頼性の両方に悪影響を及ぼす可能性があります。

トレードオフ: きめ細かなアクセス コントロール アプローチにより、ユーザー活動のより良い監査と監視が可能になります。

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

条件付きアクセスの選択

すべての ID に同じレベルのアクセス権を与えないでください。 主に 2 つの要素に基づいて決定してください:

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

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

ジャスト イン タイム (JIT) アプローチでは、必要なときにのみ必要な権限が提供されます。

必要最低限のアクセス (JEA) は、必要な権限のみを提供します。

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

ユーザー ID や位置情報、デバイスの健全性、ワークロードのコンテキスト、データの分類、異常などのパラメーターを含め、不正アクセスをフィルター、検出、ブロックする強力なコントロールを使用します。

たとえば、ベンダー、パートナー、顧客などのサードパーティの ID によってワークロードにアクセスする必要がある場合があります。 フルタイム従業員に付与する既定の権限ではなく、適切なレベルのアクセスが必要です。 外部アカウントを明確に区別することで、これらのベクトルからの攻撃の防止と検出が容易になります。

重大な影響のあるアカウント

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

権限のあるアクセスを攻撃者から保護するには、これらのシステムをリスクから隔離するための完全かつ慎重なアプローチが必要です。 ここにはいくつかの戦略があります:

• 重大な影響を与えるアカウントの数を最小限に抑えます。

• 既存の ID の権限を昇格させるのではなく、別のロールを使用します。

• IdP の JIT 機能を使用することで、永続的または常時アクセスを避けることができます。 緊急時には、緊急アクセス手順に従ってください。

• パスワードレス認証や多要素認証のような最新のアクセスプロトコルを使用します。 これらのメカニズムを IdP に外部化します。

• 条件付きアクセス ポリシーを使用して、主要なセキュリティ属性を強制します。

• 使用していない管理アカウントを廃止します。

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

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

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

デジタル アイデンティティ、高特権ユーザー、外部/ゲスト・ユーザー、ワークロード ユーザーのライフサイクルをマネージド アイデンティティで管理するためのアイデンティティ ガバナンス プロセスを確立します。 アクセス レビューを実装して、ID が組織またはチームを離れるときに、そのワークロード権限が削除されるようにします。

非 ID ベースの秘密を保護する

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

これらのシークレットを、シークレット ストアから動的に取得できるエンティティとして扱います。 これらは、アプリ、フロー、デプロイメント パイプライン、またはその他のアーティファクトにハードコーディングされるべきではありません。

秘密を取り消す能力があることを確認してください。

キーのローテーションや期限切れなどのタスクを処理する運用慣行を適用します。

ローテーション ポリシーの詳細については、2 組の認証情報を持つリソースの秘密のローテーションを自動化するおよびチュートリアル: キーボールトでの証明書の自動ローテーション頻度の更新を参照してください。

開発環境はキーボールトに安全な頻度で保管してください

開発者環境への書き込みアクセスは制限する必要があり、ソース コードへの読み取りアクセスは、必要に応じてロールに制限する必要があります。 リソースを定期的にスキャンし、最新の脆弱性を特定するプロセスを導入する必要があります。

監査証跡を維持する

ID 管理の 1 つの側面は、システムが監査可能であることを保証することです。 監査では、違反を想定した戦略が効果的かどうかを検証します。 監査証跡を維持すると、次のことが可能になります:

• 強力な認証で ID が認証されていることを確認します。 否認攻撃を防ぐためには、どのような行動も追跡可能でなければなりません。

• 認証プロトコルの脆弱性や欠落を検出し、ユーザーとアプリケーションのサインインに関する可視性と分析情報を取得します。

• セキュリティと コンプライアンス要件 に基づいて ID からワークロードへのアクセスを評価し、ユーザー アカウントのリスク、デバイスのステータス、設定したその他の基準とポリシーを考慮します。

• コンプライアンス要件に対する進捗状況や逸脱の追跡

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

Power Platform の促進

Power Platform アクセス制御は、その全体的なセキュリティ アーキテクチャの重要な部分です。 アクセス コントロール ポイントにより、適切なユーザーが Power Platform リソースにアクセスできるようになります。 このセクションでは、構成できるさまざまなアクセス ポイントと、それらが全体的なセキュリティ戦略で果たす役割について説明します。

Microsoft Entra ID

すべて Power Platform 製品の使用 Microsoft Entra ID (旧 Azure Active Directory または Azure AD) を使用します。 Entra ID を使用すると、組織はハイブリッド環境とマルチクラウド環境の ID を保護および管理できます。 Entra ID は、Power Platform リソースへのアクセスを必要とするビジネス ゲストの管理にも不可欠です。 Power Platform はまた、サービス プリンシパル機能を使用して Power Platform API と統合する必要がある他のアプリケーションを管理するために、Entra ID を使用します。 Entra ID を使用することで、Power Platform は条件付きアクセスや継続的なアクセス評価のような Entra ID のさらに高度なセキュリティ機能を活用することができます。

ライセンスの割り当て

Power Apps にアクセスして、Power Automate はライセンスを持つことから始まります。 ユーザーがアクセスできる資産やデータは、ライセンスの種類によって決まります。 次の表は、プランの種類によってユーザーが利用できるリソースに違いがあることを概略的に示したものです。 ライセンスの詳細は、ライセンスの概要 に表示されます。

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

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

詳細については、以下を参照してください。

• Microsoft Entra の条件付きアクセスを設定する
• Power Automate における条件付きアクセスと多要素認証

継続的アクセス

継続的なアクセスは、アクセスを取り消すべきかどうかを判断するために特定のイベントが評価されたときに高速化されます。 従来、OAuth 2.0 認証では、トークンの更新中にチェックが行われると、アクセス トークン の有効期限が切れます。 継続的アクセスでは、ユーザーの重要なイベントとネットワークの場所の変更が継続的に評価され、ユーザーが引き続きアクセスを維持する必要があるかどうかが判断されます。 これらの評価により、アクティブなセッションが早期に終了したり、再認証が必要になったりする可能性があります。 たとえば、ユーザー アカウントが無効になっている場合、そのユーザーはアプリにアクセスできなくなります。 場所も重要です。たとえば、トークンは信頼できる場所から認可されたかもしれませんが、ユーザーは信頼できないネットワークに接続を変更したかもしれません。 継続的なアクセスにより条件付きアクセス ポリシーの評価が呼び出され、ユーザーは承認された場所から接続しなくなったためアクセスを失います。

現在、Power Platform では、Dataverse のみが継続的アクセス評価をサポートしています。 マイクロソフトは、他の Power Platform サービスやクライアントへのサポートの追加に取り組んでいます。 詳細については、継続的アクセス評価 を参照してください。

ハイブリッド ワークモデルの採用やクラウド アプリケーションの利用が進む中、Entra ID はユーザーやリソースを保護するための重要な主要なセキュリティ境界となっています。 条件付きアクセスは、その境界をネットワーク境界を越えて拡張し、ユーザーとデバイスの ID を含めます。 継続的なアクセスにより、イベントやユーザーの場所が変化すると、アクセスが再評価されます。 Power Platform は Entra ID を使用することで、アプリケーション ポートフォリオ全体に一貫して適用できる組織レベルのセキュリティ ガバナンスを実装できます。 Power Platform で Entra ID を使用するための独自のプランを構築するためのガイダンスとして、ID 管理のベストプラクティスを確認してください。

グループ アクセス管理

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

詳細については、 Microsoft Entra ID のグループを使用した安全なアクセス制御を参照してください。

脅威の検出

Microsoft Entra ID 保護は、ID ベースのリスクを検出、調査、修復する際に役立ちます。 詳細情報に関しては、ID 保護とは何か？ を参照してください。

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

ID ログ

Power Apps、Power Automate、コネクタ、およびデータ損失防止アクティビティ ログは、Microsoft Purview のコンプライアンス ポータルから追跡および表示されます。 詳細については、Microsoft Purview について説明するを参照してください。

ログは、Dataverse データベースの環境にある顧客レコードに対して加えられた変更を記録します。 Dataverse 監査は、環境のアプリまたは SDK を介したユーザー アクセスも記録します。 この監査は環境レベルで有効になっており、個々のテーブルと列ごとに追加の構成が必要です。

サービス管理のロール

Entra ID には、管理者に管理タスクを実行する権限を与えるために、あらかじめ設定されたロールのセットが含まれています。 各ロールの権限の詳細な内訳については、権限マトリックス を参照してください。

Microsoft Entra の特権 ID 管理 (PIM) を使用して、Power Platform 管理センターで高特権の管理者ロールを管理します。

Dataverse データのセキュア化

Dataverse の主要機能の 1 つに、多種多様なビジネス使用シナリオに合わせて調整できる豊富なセキュリティ モデルがあります。 このセキュリティ モデルは、Dataverse データベースが環境内にある場合にのみ利用可能です。 セキュリティの専門家として、セキュリティ モデル全体を自分で構築することはないでしょうが、セキュリティ機能の使用方法が組織のデータセキュリティ要件と一致していることを確認することには関与する可能性があります。 Dataverse では、ロール ベースのセキュリティを使用して、権限のコレクションをグループ化します。 これらのセキュリティ ロールは、ユーザーに直接関連付けることができます。または Dataverse チーム、および部署に関連付けることもできます。 詳細については、「Microsoft Dataverse のセキュリティ概念」を参照してください。

Customer Lockbox を使用したデータへの安全なアクセス

Microsoft のスタッフ (代わりの処理者を含む) が実行する操作、サポート、およびトラブルシューティングの多くは、顧客データにアクセスする必要がありません。 Power Platform カスタマー ロックボックスにより、あまりないことですが、顧客データへのデータ アクセスが必要な場合に、顧客がデータ アクセス要求を確認および承認 (または拒否) するインターフェースを提供します。 たとえば、マイクロソフトのエンジニアが、顧客主導のサポート チケットやマイクロソフトが特定した問題に対応するために、顧客データにアクセスする必要がある場合に使用されます。 詳細情報については、Power Platform と Dynamics 365 で Customer Lockbox を使用して顧客データに安全にアクセスするを参照してください。

参照

• データソースへの接続と認証
• Power Platform サービスに認証する
• Microsoft Dataverse のセキュリティ概念
• Power Platform のセキュリティに関するよくある質問
• サービス管理者アクセス許可マトリックス
• 継続的アクセス評価
• Microsoft Entra の条件付きアクセスを設定する
• Microsoft Power Automate における条件付きアクセスおよび多要素認証の推奨事項
• Microsoft ID プラットフォームと OAuth 2.0 認証コード フロー
• Microsoft Entra ID の新機能
• Microsoft Entra の組み込みロール
• Microsoft Entra ID におけるロールベースのアクセス制御の概要

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

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