はじめに
気ままに勉強会 #10 での発表内容です。
Power Platform 便利ですよね。
指定の日時がくると自動でメールが送られたり
Twitterに投稿したり
ただ・・
自由度が高すぎてユーザーに権限を開放しにくい・・！
そのままの設定だと売上情報などの機密情報をTwitterに毎日自動投稿する・・のも可能っちゃ可能です。
データの損失防止ポリシー （Data loss prevention policies）
Microsoft 及び Power Platform には様々なセキュリティの機能がありますが、そのなかの一つ、データの損失防止ポリシーを紹介します。
コネクタごとに分類をする
データの消失防止ポリシーの考え方は、コネクタを3つのカテゴリに分けることです。
分類をすると、各カテゴリごとのデータのやりとりが制限されます。
設定するために必要な権限
DLPポリシーを作成するには、
- テナント管理者
- 環境管理者
の権限をもっている必要があります。
そのうえで、Power Platform管理センターで設定することができます。
データポリシー をクリックすると設定の開始です。
データの損失防止ポリシー （Data loss prevention policies）の作成
利用可能な3つのデータグループは下記になります。
- ビジネス データグループ
- 非ビジネス データグループ
- ブロック済み データグループ
ビジネスグループと非ビジネスグループ間
ビジネスグループと非ビジネスグループに配置されたコネクタは、別のグループのコネクタを同じフローの中で使用することができなくなります。
ビジネスグループにSharePoint および Salesforce コネクタを配置し、非ビジネスグループで Gmail を配置すると、フローやアプリの制作者は SharePoint と Gmail コネクタ両方を使用するアプリまたはフローを作成できません。これにより、Microsoft Power Platform のこれら2つのサービス間のデータフローが制限されます。
ブロック済み データグループ
ブロック済みデータグループに分類されたコネクタは、Power AutomateやPower Appsで使用することができなくなります。
| Microsoft Enterprise Plan 標準コネクタ | コア Power Platform コネクタ |
|---|---|
| クラウド アプリ用 Defender | 承認 |
| Dynamics 365 Customer Voice | Notifications |
| Excel Online (Business) | Dataverse |
| Kaizala | Dataverse (current environment) |
| Microsoft 365 Groups | Power Apps 通知 (v1 および v2) |
| Microsoft 365 Groups Mail (Preview) | |
| Microsoft 365 Outlook | |
| Microsoft 365 Users | |
| Microsoft Teams | |
| Microsoft To-Do (仕事) | |
| OneDrive for Business | |
| OneNote (Business) | |
| プランナー | |
| Power BI | |
| SharePoint | |
| Shifts | |
| Skype for Business Online | |
| Yammer |
細かいカスタマイズ
コネクタすべてをブロックするほどではないが、特定のアクションだけを禁止したい・・というのも可能です。
各コネクタのトグルをON/OFFでコントロールできます。
Gmailのメール送信はブロックしたいなぁ・・とか、
メールの削除はさせたくない・・とか。
ポリシーのスコープ
データ損失防止 (DLP) ポリシーは、
- テナント レベル
- 環境レベル
の両方で作成できます。 テナント管理者には、テナントレベルのポリシーを作成する権限があり、環境管理者には、環境レベルのポリシーを作成する権限があります。
テナントレベルポリシー
テナント管理者は、テナント レベルのデータ ポリシーの 3 種類のスコープを定義できます。
- オプション1: すべての環境に適用する。
- オプション2: 複数の環境に適用する (すべてではない)。
- オプション3: 特定の除外された環境を除くすべての環境に適用する。
環境に適用可能なすべてのポリシーが一緒に評価されるときに、最終的に最も制限の厳しいグループポリシーが適用されることに注意してください。
実際に適用してみる
コネクタの分類といっても、自分の環境を覗いてみると、すでに600個以上のコネクタが確認でき、どれをどう分類すればいいのかわかりません。Microsoft ドキュメントに例が載っていたのでご紹介します。
例: Contoso の DLP 戦略
-
Contoso 管理者は、ユーザーがユーザーとチームの生産性のユースケース向けのアプリを作成するための別の共有環境を作成しました。 この環境には、既定のポリシーほどリスク回避的ではないテナント レベルの DLP ポリシーが関連付けられており、作成者は、Office 365 サービスに加えて Azure サービスなどのコネクタを使用できます。 これは既定の環境ではないため、管理者はその環境作成者リストをアクティブにコントロールできます。 これは、共有ユーザーとチームの生産性環境および関連する DLP 設定への階層的なアプローチです。
-
さらに、部署が基幹業務アプリケーションを作成するために、さまざまな国の税務および監査子会社の開発、テスト、および運用環境を作成しました。 これらの環境への環境作成者のアクセスは慎重に管理され、部署の利害関係者と協議してテナント レベルの DLP ポリシーを使用し、適切なファーストパーティおよびサードパーティのコネクタが利用可能になります。
-
同様に、開発/テスト/運用環境は、関連するもしくは適切なアプリケーションを開発および展開するために、中央 IT が使用するために作成されます。 これらのビジネス アプリケーション シナリオには通常、これらの環境の作成者、テスター、およびユーザーが利用できるようにする必要がある、明確に定義されたコネクタのセットがあります。 これらのコネクタへのアクセスは、専用のテナント レベルのポリシーを使用して管理されます。
-
Contoso には、センター オブ エクセレンス活動専用の、特別な目的の環境もあります。 Contoso では、理論チームの本の実験的な性質を考えると、特別な目的の環境に対する DLP ポリシーは引き続きハイ タッチになります。 この場合、テナント管理者は、この環境の DLP 管理を CoE チームの信頼できる環境管理者に直接委任し、すべてのテナント レベルのポリシーの学校から除外しました。 この環境は、環境レベルの DLP ポリシーによってのみ管理されます。これは、Contoso のルールではなく例外です。
コネクタを絞り込む
たくさんのコネクタがあるので、絞り込みます。
公開元がMicrosoftかどうかの列で絞り込みを行うと、Microsoft以外のServiceも多数含まれます。
Contosoと同じような構成にまずはしてみる場合は、ブロック可能な列で絞り込みをかけたほうが良いです。
私の環境では24個のコネクタを一括で選択してビジネスデータグループに含めることができました。
実験
実際にフローを作成し、動作確認
Flowボタンを押すとSharePointリストの一覧を読み込み、メール本文に書き込んでを発信するという（意味のない）Flowを作成してみます。
両方のコネクターはビジネスグループの中なので、フローの作成は成功します。
同じように、Flowボタンを押すとSharePointリストの一覧を読み込み、TweetするというFlowを作ろうとすると、フローチェッカーにエラーメッセージが表示されます。
- SharePointはビジネスデータグループ
- Twitterは非ビジネスデータグループ
なので、グループをまたいだフローは作成することができません。
Twitterコネクタをブロックしてみる
Twitterのコネクタをブロック済みに変更してみます。
するとTwitterを含めたフローは、フローチェッカーにエラーメッセージが表示され、保存することができません。
まとめ
ユーザーに自由に使ってもらうためにも最低限のセキュリティは必要ですよね