次の方法で共有

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

  • [アーティクル]

この Power Platform Well-Architected Securityチェックリストの推奨事項に適用されます:

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

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

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

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

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

定義

条件 Definition
認証 (AuthN) アイデンティティが、それが示す人物または物であることを確認するプロセス。
認可 (AuthZ) 要求されたアクションを実行する権限が ID にあるかどうかを確認するプロセス。
条件付きアクセス 指定された基準に基づいてアクションを許可する一連のルール。
IdP ID プロバイダー (Microsoft Entra ID) など。
ペルソナ 一連の責任と行動を伴う職務または役職。
事前共有キー プロバイダーとコンシューマー間で共有され、安全で合意されたメカニズムを通じて使用されるシークレットの一種。
リソース ID プラットフォームによって管理されるクラウド リソースに対して定義された ID。
役割 ユーザーまたはグループが実行できる内容を定義する一連の権限。
範囲 役割の実行が許可される組織階層のさまざまなレベル。 システム内の機能のグループでもあります。
セキュリティ プリンシパル 権限を提供する ID。 ユーザー、グループ、またはサービス プリンシパルのいずれかにすることができます。 すべてのグループ メンバーは同じレベルのアクセス権を取得します。
ユーザー ID 従業員や外部ユーザーなどの個人の ID。
ワークロード ID 他のサービスやリソースに対して自身を認証するために使用される、ワークロードのアプリケーション、サービス、スクリプト、コンテナー、またはその他のコンポーネントのシステム ID。

注意

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

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 業界標準の Microsoft Entra 2.0プロトコルを使用したすべてのAPI呼び出しの承認に、 Microsoft ID Identity Platform OAuth を使用します。

主要な設計戦略

ワークロードの 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、役割、範囲を組み合わせた選択につながります。

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

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

ロールの割り当て

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

次のような質問です:

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

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

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

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

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

条件付きアクセスの選択

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

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

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

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

Just Enough Access (JEA) は必要な権限のみを提供します。

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

ユーザーIDと場所、デバイスの健全性、ワークロード コンテキスト、データ分類、異状などのパラメータを含む、不正アクセスをフィルタリング、検出、ブロックする強力な制御を使用します。

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

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

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

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

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

  • 既存のIDの権限を昇格する代わりに、別のロール を使用します。

  • IdPのJIT機能を使用して、永続的または継続的なアクセスを回避します。 緊急時には、緊急アクセス手順に従ってください。

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

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

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

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

ID へのアクセスは、その 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 の条件付きアクセスを構成します。

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

継続的アクセス

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

現在、Power Platform では、Dataverse のみが継続的アクセス評価をサポートしています。 Microsoft 他の 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) を使用すると、疑わしいアクティビティを簡単に検出できます。 詳細については、「 SentinelのUEBAによる高度な脅威の識別 Microsoft 」 を参照してください。

ID ログ

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

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

サービス管理のロール

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

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

Dataverse データのセキュア化

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

Copilot Studio でユーザー認証の構成

Copilot Studio は、いくつかの認証オプションをサポートしています。 ニーズに合ったものを選択してください。 認証により、ユーザーはログインできるようになり、副操縦士に制限されたリソースや情報へのアクセスが許可されます。 ユーザーは、 Microsoft Entra IDまたはGoogleなどの任意の OAuth 2.0 IDプロバイダーを使用してログインできます Facebook。 詳細については、 「ユーザー認証を構成する」を参照してください Copilot Studio。

Direct Lineベースのセキュリティを使用すると、 Direct Line シークレットまたはトークンを使用したセキュリティ保護されたアクセスを有効にすることで、制御する場所へのアクセスを制限できます。

Copilot Studio シングル サインオン (SSO) をサポートしているため、副操縦士がユーザーをサインインさせることができます。 SSOはWebページとモバイル アプリケーションに実装する必要があります。 Microsoft Teamsの場合、「Teams内のみ」の認証オプションを選択すると、SSOはシームレスになります。 Azure AD v2を使用して手動で構成することもできますが、この場合、Teamsアプリは、 Copilot Studio からの1クリックTeams展開ではなく、zipファイルとして展開する必要があります。

詳細情報:

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

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

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

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

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