組織内のすべての従業員は、既定の Power Platform 環境にアクセスできます。 Power Platform 管理者は、環境を安全に保ちながら、作成者が個人的に生産性を高めるためにアクセスできるようにする方法を検討する必要があります。
管理者の役割の適切な割り当て
管理者が Power Platform 管理者ロールを持つ必要があるかどうかを検討します。 環境管理者またはシステムの 管理者 ロールの方が適切ですか？ より強力な Power Platform 管理者ロールを一部のユーザーに限定します。 詳細については、Power Platform 環境の管理を参照してください。
ID プロバイダのジャスト イン タイム (JIT) 機能を使用することで、永続的なアクセスや常時アクセスを回避できます。 緊急時には、緊急アクセス手順に従ってください。 Microsoft Entra ID の機能である Privileged Identity Management (PIM) を使用して、これらの高い特権ロールの使用を管理、制御、監視します。
推奨事項については、ID の構成とアクセス管理を参照してください。
意図の伝達
Power Platform のセンター オブ エクセレンス (CoE) チームの重要な課題のひとつは、既定の環境の使用目的を伝えることです。 いくつかのおすすめ候補を以下に示します。
既定の環境の名前を変更する
既定の環境は、TenantName (既定) という名前で作成されます。 環境の意図を明確に示すため、個人的生産性環境のような、より分かりやすい名称に変更します。
作成者のウェルカム コンテンツの構成
作成者が Power Apps と Copilot Studio を使い始められるように、カスタマイズされたウェルカム メッセージを構成します。 ウェルカム メッセージは、作成者にとって既定の Power Apps の初回ヘルプ エクスペリエンスに置き換わります。 既定の環境に到達したすべての作成者に対し、その意図を共有する機会を活用します。
Power Platform ハブを使用する
Microsoft Power Platform ハブ は SharePoint のコミュニケーション サイトのテンプレートです。 組織の Power Platform の使用に関する作成者に向けた中心的な情報源となる出発点となります。 スターター コンテンツとページ テンプレートを使用すると、次のような情報を作成者に簡単に提供できます:
- 個人の生産性のユースケース
- 次の情報:
- アプリとフローの作成方法
- アプリとフローを作成する場所
- CoE サポート チームへの連絡の方法
- 外部サービスとの統合に関するルール
作成者が役立つと思われるその他の内部リソースへのリンクを追加します。
マネージド環境を有効にする
既定の環境でマネージド環境機能を利用して、堅牢なセキュリティとガバナンスを維持します。 マネージド環境機能は、監視、コンプライアンス、セキュリティ制御など、データ保護に重要な高度な機能を提供します。 この機能を有効にすると、 共有の制限を構成したり、 使用状況の分析情報を増やしたり、許可された IP の場所からのみ Microsoft Dataverse へのユーザー アクセスを制限 したり、 アクション ページ を使用してカスタマイズされた推奨事項を取得して環境を最適化したりできます。 現在のマネージド環境の機能を評価し、製品ロードマップを最新の状態に保ち、安全でコンプライアンスに準拠し、適切に管理された既定の環境を維持します。
過剰共有を防ぐ
Power Platform は、ユーザーが素早くアプリやフローを作成できるローコード プラットフォームとして設計されています。 しかし、この使いやすさはアプリやフローの過剰な共有につながり、セキュリティ リスクを引き起こす可能性があります。
共有制限を構成する
セキュリティを強化し、Power Platform の既定環境内での過剰共有を防止するには、ユーザーがキャンバス アプリ、フロー、エージェントを共有できる範囲を制限します。 共有の制限を構成して、アクセスを厳しく管理することを検討してください。 このような制限により、必要なガバナンス管理を必要とせずに、不正使用、過剰な情報共有、過剰使用のリスクが低減されます。 共有制限を導入することで、重要な情報を保護すると同時に、Power Platform 内でより安全で管理しやすい共有の枠組みを促進できます。
全員との共有を制限する
作成者はアプリを他のユーザーやセキュリティ グループと共有することができます。 デフォルトでは、組織全体、つまり 全員 との共有は無効になっています。 広く使用されているアプリにゲート プロセスを使用して、ポリシーと要件を適用することを検討してください。 例:
- セキュリティ レビュー ポリシー
- ビジネス レビュー ポリシー
- アプリケーション ライフサイクル管理 (ALM) の要件
- ユーザー エクスペリエンスとブランド化の要件
全員と共有する機能は、Power Platform では既定で無効になっています。 意図しないユーザーによるキャンバス アプリの過剰な露出を制限するために、この設定を無効にしておくことをお勧めします。 組織の全員グループには、ゲストや内部メンバーを含む、テナントにログインしたことのあるすべてのユーザーが含まれます。 テナント内の内部従業員だけが含まれるわけではありません。 さらに、Everyone グループのメンバーシップは編集も表示もできません。 詳細については、特別な ID グループを参照してください。
社内の全従業員や大規模なグループと共有する場合は、既存のセキュリティ グループを使用するか、アプリを共有するセキュリティ グループを作成することを検討してください。
全員と共有するがオフの場合、Dynamics 365 管理者、Power Platform 管理者、グローバル管理者のみが環境内のすべてのユーザーとアプリケーションを共有できます。 管理者は、次の PowerShell コマンドを実行して、全員 との共有を許可できます。
まず、理者として PowerShell を管開き、次のコマンドを実行して Power Apps のアカウントにサインインします:
Add-PowerAppsAccountGet-TenantSettings コマンドレット を実行して、組織のテナント設定のリストをオブジェクトとして取得します。
powerPlatform.PowerAppsのオブジェクトには次の 3 つのフラグが含まれます:
以下の PowerShell コマンドを実行して、設定オブジェクトを取得し、変数
disableShareWithEveryoneを$falseに設定します:$settings=Get-TenantSettings $settings.powerPlatform.powerApps.disableShareWithEveryone=$falseSet-TenantSettingscmdlet を設定オブジェクトと共に実行して、作成者がテナント内のすべてのユーザーとアプリを共有できるようにします。Set-TenantSettings $settings全員 との共有を無効にするには、同じ手順に従いますが、設定
$settings.powerPlatform.powerApps.disableShareWithEveryone = $trueは異なります。
データ ポリシーを確立する
既定の環境をセキュリティで保護するもう 1 つの方法は 、その環境のデータ ポリシーを作成 することです。 データ ポリシーを設定することは、組織内のすべての従業員が既定の環境にアクセスできるため、特に重要です。 ポリシーの適用に役立つ推奨事項を次に示します。
データ ポリシー ガバナンス メッセージをカスタマイズする
作成者が組織のデータ ポリシーに違反するアプリを作成した場合に表示されるエラー メッセージをカスタマイズします。 作成者を組織の Power Platform ハブに誘導し、CoE チームのメールアドレスを提供します。
CoE チームが時間の経過と共にデータ ポリシーを調整すると、一部のアプリが誤って中断される可能性があります。 データ ポリシー違反メッセージに連絡先の詳細または詳細情報へのリンクが含まれていることを確認して、作成者に進む方法を提供します。
次の PowerShell コマンドレットを使用して、ガバナンス ポリシーのメッセージ をカスタマイズします:
| command | Description |
|---|---|
| Set-PowerAppDlpErrorSettings | ガバナンス メッセージを設定します |
| Set-PowerAppDlpErrorSettings | ガバナンス メッセージを更新します |
既定の環境で新しいコネクタをブロックする
既定では、すべての新しいコネクタは、データ ポリシーの非ビジネス グループに配置されます。 既定のグループはいつでも変更できるため、「ビジネス」または「ブロック」に変更できます。 既定の環境に適用されるデータ ポリシーの場合は、管理者の 1 人によってレビューされるまで新しいコネクタが使用できないように、ブロックされたグループを既定として構成することをお勧めします。
作成者を事前構築済みのコネクタに限定する
作成者を基本的でブロック不可能なコネクタに制限し、他のコネクタへのアクセスをブロックします。
- ブロックできないすべてのコネクタをビジネス データ グループに移動します。
- ブロックされたデータ グループへとブロックできるすべてのコンポーネントを移動します。
カスタム コネクタの制限
カスタム コネクタは、アプリまたはフローを自家製のサービスを統合します。 これらのサービスは、開発者などの技術ユーザーを対象としています。 既定の環境でアプリまたはフローから呼び出すことができる (組織によって構築された) API の占有領域を減らすことをお勧めします。 作成者が既定の環境で API 用のカスタムコネクターを作成し使用することを防ぐために、すべての URL パターンをブロックするルールを作成します。
作成者が一部の API (たとえば、会社の休日リストを返すサービス) にアクセスできるようにするには、異なる URL パターンをビジネスと非ビジネスのデータグループに分類する複数のルールを構成します。 接続で常に HTTPS プロトコルが使用されるようにします。 カスタム コネクタのデータ ポリシーの詳細について説明します。
Exchange との統合をセキュア化する
Office 365 Outlook コネクタ は、ブロックすることができない標準コネクタの一つです。 作成者がアクセスできるメールボックス内の電子メールメッセージの送信、削除、返信を行うことができます。 このコネクタのリスクは、最も強力な機能のひとつでもある、メールを送信する機能です。 たとえば、作成者は一斉メールを送信するフローを作成する場合があります。
組織の Exchange 管理者は、Exchange server にルールを設定し、アプリからのメール送信を防止することができます。 送信メールをブロックするように設定されたルールから特定のフローまたはアプリを除外することもできます。 これらのルールとメール アドレスの許可リストを組み合わせることで、アプリやフローからのメールが少数のメールボックスからしか送信できないようにできます。
アプリやフローが Office 365 Outlookコネクタを使用して電子メールを送信すると、メッセージに特定の SMTP ヘッダが挿入されます。 ヘッダーの予約語句を利用して、メールの発信元がフローかアプリかを識別することができます。
フローから送信される電子メールに挿入される SMTP ヘッダーは、次のようになります:
x-ms-mail-application: Microsoft Power Automate;
User-Agent: azure-logic-apps/1.0 (workflow 2321aaccfeaf4d7a8fb792e29c056b03;version 08585414259577874539) microsoft-flow/1.0
x-ms-mail-operation-type: Send
x-ms-mail-environment-id: 0c5781e0-65ec-ecd7-b964-fd94b2c8e71b
ヘッダーの詳細
x-ms-mail-application
使用するサービスに応じて、x-ms-mail-application ヘッダーに表示できる値を次の表に示します。
| サービス | 価値 |
|---|---|
| Power Automate | Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow <GUID>; version <バージョン番号>) microsoft-flow/1.0 |
| Power Apps | Microsoft Power Apps; User-Agent: PowerApps/ (; AppName= <アプリ名>) |
x-ms-mail-operation-type
次の表は、実行されるアクションに応じて x-ms-mail-operation-type ヘッダーに表示される可能性のある値を説明します。
| 価値 | Description |
|---|---|
| Reply | メールの返信操作用 |
| Forward | メールの転送操作用 |
| Send | SendEmailWithOptions や SendApprovalEmail などのメール送信操作用 |
x-ms-mail-environment-id
x-ms-mail-environment-id ヘッダーには、環境 ID の値が含まれています。 このヘッダーの存在は、使用している製品によって異なります。
- Power Apps では、常に存在しています。
- Power Automate では、2020 年 7 月以降に作成された接続にのみ存在します。
- Logic Apps では存在しません。
既定の環境の潜在的な Exchange ルール
Exchange ルールを使用してブロックできるメール アクションを次に示します。
外部受信者への送信メールをブロックする: Power Automate と Power Apps から外部の受信者に送信されるすべてのアウトバウンドメールをブロックします。 このルールは、作成者がアプリまたはフローからパートナー、ベンダー、またはクライアントにメールを送信できないようにします。
外部送信をブロックする: 送信者がメールボックスの許可リストに含まれていない場合、Power Automate および Power Apps からの外部受信者に転送されたすべての送信メールをブロックします。 このルールは、作成者が受信メールを自動的に外部の受信者に転送するフローを作成することを防止します。
メール ブロック ルールで考慮すべき例外
柔軟性を付加するために、メールをブロックするための Exchange ルールに対する潜在的な例外を次に示します。
特定のアプリやフローを除外する: 承認されたアプリやフローが外部の受信者にメールを送信できるように、先に提案したルールに除外リストを追加します。
組織レベルの許可リスト: このシナリオでは、ソリューションを専用の環境に移動することが合理的です。 環境内の複数のフローで送信メールを送信する必要がある場合は、ブランケット例外ルールを作成して、その環境からの送信メールを許可できます。 その環境に対する作成者と管理者のアクセス許可は、厳密に管理および制限する必要があります。
詳細については、Power Platform に関するメール トラフィックに対する適切な流出ルールの設定方法を参照してください。
テナント間分離の適用
Power Platform は Microsoft Entra をベースとしたコネクタ システムを持っており、認可された Microsoft Entra のユーザーがアプリやフローをデータストアに接続できます。 テナント分離は、Microsoft Entra 認可のデータソースからそのテナントへのデータの移動を管理します。
テナント分離はテナント レベルで適用され、既定の環境を含む、テナント内のすべての環境に影響を与えます。 既定の環境ではすべての従業員が作成者であるため、環境を保護するには、堅牢なテナント分離ポリシーを構成することが極めて重要です。 従業員が接続できるテナントを明示的に構成することをお勧めします。 他のすべてのテナントは、受信と送信の両方のデータ フローをブロックする既定のルールでカバーする必要があります。
Power Platform テナント分離は、Microsoft Entra ID 全体のテナント制限とは異なります。 Power Platform 以外の Microsoft Entra ID ベースのアクセスには影響しません。 これは、Office 365 Outlook や SharePoint コネクタなどのように、Microsoft Entra ID ベースの認証を使用するコネクタにのみ適用されます。
詳細情報:
- テナント間のインバウンドとアウトバウンドのアクセス制限
- Get-PowerAppTenantIsolationPolicy (Microsoft.PowerApps.Administration.PowerShell)
次の手順
このシリーズの詳細な記事を確認して、セキュリティ体制をさらに強化してください。
記事を確認したら、セキュリティ チェックリストを確認し、Power Platform の展開が安定して回復力があり、ベスト プラクティスに沿っていることを確認します。