次の方法で共有

既定の環境のセキュリティ保護

  • [アーティクル]

組織内のすべての従業員は、既定の Power Platform 環境にアクセスすることができます。 Power Platform 管理者は、環境を安全に保ちながら、作成者が個人的に生産性を高めるためにアクセスできるようにする方法を検討する必要があります。 この記事では、さまざまな提案をご案内します。

管理者の役割の適切な割り当て

管理者ユーザーが Power Platform の管理者ロールを持つ必要があるかどうかを検討します。 環境管理者またはシステムの 管理者 ロールの方が適切ですか？ いずれにせよ、より強力な Power Platform 管理者ロールは、少数のユーザーに限定します。 環境の管理について詳しくは、 Power Platform をご覧ください。

意図の伝達

Power Platform のセンター オブ エクセレンス (CoE) チームの重要な課題のひとつは、既定の環境の使用目的を伝えることです。 いくつかのおすすめ候補を以下に示します。

既定の環境の名前を変更する

既定の環境は、TenantName (既定) という名前で作成されます。 環境名を 個人用運用環境 などのように、より分かりやすいものに 変更 することで、その意図を明確に呼び出すことができます。

Power Platform ハブを使用する

Microsoft Power Platform ハブ は SharePoint のコミュニケーション サイトのテンプレートです。 あなたの組織の Power Platform の使用に関する作成者に向けた中心的な情報源となる出発点となります。 スターター コンテンツとページ テンプレートを使用すると、次のような情報を作成者に簡単に提供できます:

  • 個人の生産性のユースケース
  • アプリとフローの作成方法
  • アプリとフローを作成する場所
  • CoE サポート チームへの連絡の方法
  • 外部サービスとの統合に関するルール

作成者が役立つと思われるその他の内部リソースへのリンクを追加します。

全員との共有を制限する

メーカーは、他の個々のユーザーやセキュリティ グループと アプリを 共有 できます。 デフォルトでは、組織全体、つまり 全員との共有は無効になっています。 次のようなポリシーと要件を適用するには、広く使用されているアプリに対してゲート プロセスを使用することを検討してください。

  • セキュリティ レビュー ポリシー
  • ビジネス レビュー ポリシー
  • アプリケーション ライフサイクル管理 (ALM) の要件
  • ユーザー エクスペリエンスとブランド化の要件

Everyoneとの 共有 機能は、 Power Platform ではデフォルトで無効になっています。 意図しないユーザーによるキャンバス アプリの過剰な露出を制限するために、この設定を無効にしておくことをお勧めします。 組織の Everyone グループには、ゲストや内部メンバーなど、テナントにログインしたことのあるすべてのユーザーが含まれます。 テナント内のすべての社内従業員だけではありません。 さらに、 Everyone グループのメンバーシップは編集も表示もできません。 Everyone グループの詳細については、/windows-server/identity/ad-ds/manage/understand-special-identities-groups#everyoneを参照してください。

社内の全従業員または大規模なグループで 共有 を行う場合は、それらのメンバーの既存のセキュリティ グループと共有するか、セキュリティ グループを作成してそのセキュリティ グループとアプリを共有することを検討してください。

「共有with Everyone 」が無効になっている場合、少数の管理者グループだけが、環境 内のすべてのユーザーとアプリケーションを 共有 できます。 管理者 の場合、 全員との共有を有効にする必要がある場合は、次のPowerShellコマンドを実行できます。

  1. まず、管理者 としてPowerShellを開き、このコマンドを実行して自分のアカウントにログインします。 Power Apps 

    Add-PowerAppsAccount

  2. Get-TenantSettings コマンドレット を実行して、組織のテナント設定のリストをオブジェクトとして取得します。

    powerPlatform.PowerApps のオブジェクトには次の 3 つのフラグが含まれます:

    $settings.powerPlatform.PowerApps オブジェクトの 3 つのフラグを表示した画面のスクリーンショット。

  3. 次のPowerShellコマンドを実行して設定オブジェクトを取得し、変数disabledShareWithEveryoneを $falseに設定します。

    $settings=Get-TenantSettings 
$settings.powerPlatform.powerApps.disableShareWithEveryone=$false

  4. 設定オブジェクトを使用して Set-TenantSettings コマンドレットを実行すると、作成者がテナント内のすべてのユーザーに対してアプリを 共有 できるようになります。

      Set-TenantSettings $settings

    全員との共有を無効にするには、追従する 同じ手順で $settings.powerPlatform.powerApps.disableShareWithEveryone = $trueを設定します。

データ損失防止ポリシーを設定する

既定の環境を確保するもう一つの方法は、データ損失防止 (DLP) ポリシーを作成する ことです。 特に既定の環境では、組織内の全従業員がアクセスするため、DLP ポリシーを導入することは非常に重要です。 ポリシーの適用に役立つ推奨事項を次に示します。

DLP ガバナンス メッセージをカスタマイズする

作成者が組織の DLP ポリシーに違反するアプリを作成した場合に表示されるエラーメッセージをカスタマイズできます。 作成者を組織のPower Platform Hubに誘導し、CoE チームのメールアドレスを提供します。

CoE チームが時間の経過とともに DLP ポリシーを改良しているため、既存のアプリを意図せずに壊してしまう可能性があります。 DLP ポリシー違反のメッセージには、連絡先の詳細または詳細情報へのリンクが含まれていることを確認して、作成者が先に進む方法を提供してください。

次の PowerShell コマンドレットを使用して、ガバナンス ポリシーのメッセージ をカスタマイズします:

command Description
Set-PowerAppDlpErrorSettings ガバナンス メッセージを設定します
Set-PowerAppDlpErrorSettings ガバナンス メッセージを更新します

既定の環境で新しいコネクタをブロックする

デフォルトでは、すべての新しいコネクタはDLPポリシーの非ビジネス グループに配置されます。 いつでも 既定のグループをビジネスまたはブロック に変更できます。 既定の環境に適用される DLP ポリシーの場合は、ブロックされたグループを既定として構成し、管理者のいずれかが確認するまで新しいコネクタが使用できないようにすることをお勧めします。

作成者を事前構築済みのコネクタに限定する

残りの部分へのアクセスを防ぐために、作成者を基本的でブロックされないコネクタのみに制限します。

  1. ブロックできないすべてのコネクタをビジネス データ グループに移動します。

  2. ブロックできるすべてのコネクタをブロックされたデータ グループに移動します。

カスタム コネクタの制限

カスタム コネクタは、アプリまたはフローを自家製のサービスを統合します。 これらのサービスは、開発者などの技術ユーザーを対象としています。 既定の環境でアプリまたはフローから呼び出すことができる (組織によって構築された) API の占有領域を減らすことをお勧めします。 作成者が既定の環境で API 用のカスタムコネクターを作成し使用することを防ぐために、すべての URL パターンをブロックするルールを作成します。

作成者が一部の API (たとえば、会社の休日リストを返すサービス) にアクセスできるようにするには、異なる URL パターンをビジネスと非ビジネスのデータグループに分類する複数のルールを構成します。 接続で常に HTTPS プロトコルが使用されるようにします。 カスタム コネクタのDLPポリシーの詳細については、 をご覧ください。

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 ヘッダーに表示できる値を次の表に示します:

サービス 価値
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 ヘッダーに表示できる値について説明したものです:

価値 Description
Reply メールの返信操作用
Forward メールの転送操作用
Send SendEmailWithOptions や SendApprovalEmail などのメール送信操作用

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)