#はじめに
Power Platform においては、適切なデータ損失防止 (DLP) ポリシーを設計することで、組織内にある重要なビジネスデータを外部サービスと接続させず、安全にPower Platform を展開することができます。
テナントの既定環境においては、どのようなアプリを作成されるかわからないため、適切なデータ損失防止 (DLP) ポリシーのビジネスデータグループには、Office 365 関連のコネクタのみとすることが望ましいと考えています。
(少なくともコンシューマ向けのコネクタなどはビジネスに入れるべきではないですよね)
この Office 365 関連のコネクタに関しては、統合済み Azure AD の認証により安全なコネクタしかないと思っていたのですが、1つだけ気を付けなければいけないものがありました。
Office 365 Outlook のメールのコネクタです。
このコネクタを使ってしまえば、メール経由で本文や添付ファイルで外部にじゃんじゃんデータを流出してしまうことが可能となります。
性善説に立ってしまえば、情報流出するような利用者はいないと想定して野放しでも良いのですが、社員数が多い組織となった場合、内部統制上そのような抜け穴は許されません。
今回の投稿は、Exchange Online のメールフロールール(いわゆるトランスポートルール)を使って、Power Platform からのメール送信を抑止する内容となっています。
#参考にしたサイト
コネクタのメール流出制御(Microsoft Docs)
#環境
- Office 365 開発者プログラム (E5)
- Power Apps for Office 365
- Power Automate for Office 365
#まずは Power Apps からメールを送信してみる
超簡単なアプリを作ってみます。(メールアドレスはダミーです)
テキストボックスに宛先、タイトル、本文を入れて、ボタン押下でメールを送付するだけのアプリです。
当たり前ですが、これでメールを送付すれば相手にメールが届くことになります。
#メールのヘッダを確認してみる
当記事の冒頭に記載した「参考にしたサイト」にある通り、Power Platform から送信されたメールは、「x-ms-mail-application:」ヘッダーに特定の文字列が挿入されます。
今回は Power Apps からメールを送信したので「Microsoft Power Apps」という文字列が挿入されます。(Power Automate の場合は Microsoft Power Automate となる)
このヘッダ情報を使ってメールをブロックしてみます。
#Exchange Online のトランスポートルールを作成する
(完成形)
(条件の指定)
-
「メッセージヘッダーに次の項目が含まれる...」を作成
[メッセージ ヘッダー...] > [これらの単語を含む]
「ヘッダー名の指定」で "x-ms-mail-application" を入力
-
「メッセージヘッダーに次の項目が含まれる...」を作成(2つ目)
2.と同じ手順で、"x-ms-mail-operation-type" ヘッダーに対して、次の2つのパターン設定する
'Send'
'Forward'
(実行する処理)
4.「説明を示してメッセージを拒否する」を作成
これでルールの作成は完了です。
※フローの反映には少し時間を要します
#組織外へメールを送付してみる。
先ほどのアプリでもう一度メールを送信します。(メールアドレスはダミーです)
#組織内にメールを送付してみる。
問題なくメールを受信できました!
#除外条件について
前述の手順を適用すれば、Power Apps に関しては一律組織外へのメール送付を制限することができます。
ただし、組織によっては「特定のドメインに関してはグループ会社となるため制限の除外にしたい」や「特定のアプリやフローは対象外とする」、「管理者ユーザからのメール自動送信は除外したい」などという例外が発生するかと思います。
今回は、特定のアプリからはメール送信を制限しない例外を作成してみます。
3."x-ms-mail-application-id" を指定
#組織外へメールを送付してみる
先ほどブロックされた条件のメールが、例外扱いで正常に送信できました!
#まとめ
Exchange Online のトランスポートルールを活用することにより、Power Platform から送信されるメールを特定することができ、且つ業務やアプリの要件に合わせて除外設定も可能であることを説明しました。この設定なら、簡単にメール送信による流出を防ぐことができますよね。
ただし、アプリやフロー単位で除外設定を行うということは、組織内で外部メールを送信する要件のアプリが増えてきた場合、運用に耐えられないということにもなりかねません。
その場合は他のヘッダー情報を活用することで対処がある程度楽になると考えられます。
例えば、"x-ms-mail-environment-id" など、環境を指定しているidが存在していますので、環境単位での制限・除外設定をルールとして組むというやり方もあります。
メールでの情報流出を制限したい場合は、この手順を活用してみてください☺