方向性データ ガバナンス フローの使用
ビジネスの状況によっては、外部のソースからコネクタを介して取得したデータが、重要な業務情報を保持しているサービスに転送される場合があります。 通常、データ損失防止 (RF) ポリシーでは、これらのコネクタが相互に通信することが求めらます。 難しいのは、コネクタが一方向でのみ通信し、重要なビジネス データを誤ってサード パーティに流出しないようにすることです。 このデータのフローの管理 (データの行き先を所定の場所のみに限定すること) を方向性データ ガバナンスと呼びます。
現在、DLP ポリシーでは方向性データ ガバナンスは自動的に処理されません。 しかし、心配はいりません。Power Automate を使用すると、ビジネス データを外部の場所に送信しようとするフローを検出して阻止することができます。
以下に例を示します。所属している組織が、SharePoint を使用して Twitter のデータを追跡したいとします。 ここで懸念されるのは、SharePoint から Twitter に機密情報が流出する可能性があることです。
データを正しい方向にのみ移動させるには、まず Power Platform 管理センターで DLP ポリシーを作成します。 このポリシーでは、SharePoint コネクタと Twitter コネクタをビジネス データとしてグループ化します。こうすることで、ユーザーがこれらのコネクタの両方を使用してフローを作成できるだけでなく、データの安全性を確保し、データが誤って不正に使用されるのを防ぐこともできます。
方向性データ ガバナンスを実現するための最初の手順は、Power Platform 管理センターで、ビジネス データ グループ内の SharePoint コネクタと Twitter コネクタを含む DLP ポリシーを作成することです。 この構成を使用することで、作成者はこれらのコネクタの両方を含むフローを作成できます。
次に、Power Automate Maker Portal に移動し、ガバナンス フローを作成できるように管理者アカウントを使用してサインインします。 目的は、1 時間ごとに実行される予定フローを作成することです。
繰り返しトリガーがフローに自動的に追加されます。 ここで、変数を初期化するアクションをフローに追加します。 この変数に previousTimestamp という名前を指定し、
ticks(addMinutes(utcNow(),-60))の式を含めます。 この式では、60 分前の時点でのティックの数が計算されます。 この式を含める理由は、フローが最後に実行された時点 (60 分前) から作成または変更されたフローがあるかどうかを確認することです。
isFlowAction という名前の別の変数を追加します。この変数はブール型であり、既定値は false です。 この変数は、フローに Twitter アクションが含まれていることを検出した場合に、その後のフローで使用します。
次に、Power Platform for Admins コネクタと管理者として環境を一覧表示するアクションを使用します。このアクションにより、テナントの環境の一覧がフローに提供されます。 その上で、Twitter アクションを含むフローを検索できるように各環境をループします。
すべての環境の一覧を取得した後には、フロー管理コネクタを追加し、管理者としてフローを一覧表示アクションを使用します。このアクションにより、特定の環境のすべてのフローが一覧表示されます。
管理者としてフローを一覧表示アクションでは、入力パラメーターとして環境の名前が必要です。 管理者として環境を一覧表示呼び出しから返される名前の列を使用します。 この入力を指定すると、すべての環境を反復処理できるように、Apply to each アクションが自動的に追加されます。
最近変更されたフローのみを確認の対象にするため、フローに条件を追加して、フローの最後に変更されたタイムスタンプのティックをフローの前のステップで定義された変数のティックと比較します。 このタスクを実行するには、最後に変更されたタイムスタンプのティックを計算する式を使用します。 全体のステートメントは、
ticks(items('Apply_to_each_2')?['properties']?['lastModifiedTime']) is greater than previousTimestampです。
過去 60 分以内にフローが変更されたことを検出した場合は、それが管理者の所有するものではないことを確認する必要があります。 この確認を行うと、後の手順で管理者をフローの共同所有者として追加しようとするときに、エラーを回避するのに役立ちます。 現在のフローが管理者に属しているかどうかを検出するには、[Office 365 ユーザー] コネクタとマイ プロフィールの取得 (V2) アクションを使用します。 このステップにより、コネクタへの接続を確立したユーザーに関する情報が返されます。この場合は、管理者に関する情報です。 次に、はいの場合の分岐に Office 365 ユーザー アクションを追加します。
ここで、管理者としてフローを一覧表示アクションの作成者のオブジェクト ID がマイ プロフィールの取得 (V2) アクションの ID と等しくないかどうかを確認する別の条件を追加します。 はいの場合ブランチに、Microsoft Flow for Admins コネクタに属するフロー所有者ロールを管理者として編集するアクションを追加します。 このアクションにより、管理者ユーザーがフローの共同所有者として追加され、フロー定義を抽出できるようになります。そのためには、フローの共同所有者である必要があります。 フローの定義は、後の手順で取得します。ここでは、現在の環境名、現在のフロー名、および管理者ユーザーのメール アドレス、表示名、ID などの詳細を指定します。 これらの値には、マイ プロフィールの取得 (V2) アクションからアクセスできます。
管理者アカウントをフローの共同所有者として追加したら、[フロー管理] コネクタからフローを管理者として取得アクションを呼び出すことができます。
フローを管理者として取得アクションの入力には、現在の環境名やフロー名が含まれます。 このアクションの出力には、Twitter アクションが存在するかどうかを確認できるフロー定義が含まれます。
Twitter アクションが使用されているかどうかを確認するには、フローに条件を追加して、フローを管理者として取得アクションのアクション API の名前が shared_twitter と等しいかどうかを確認します。 この条件を追加すると、Apply to each ループが適用されます。これは、各フローには多くのアクションが含まれる可能性があり、アクション API の名前属性が配列の一部であるためです。
Twitter アクションを含むフローが検出されるようになったため、はいの場合ブランチで、isFlowAction 変数を更新して、true に設定します。 後でこの変数をフローで使用して、フローを無効にしてフローの所有者にメールを送る必要があるかどうかを判断します。
フローのすべてのアクションを繰り返すことができる Apply to each 変数の外で別の条件を追加します。 この条件は、isFlowAction 変数の値が true であるかどうかを確認します。
はいの場合の分岐で、Microsoft Flow for Admins コネクタを追加し、管理者としてフローを無効にするアクションを選択します。 このアクションを使用すると、フローを無効にして、情報を Twitter に送信できなくすることができます。 このアクションを呼び出すには、現在の環境名とフロー名を含めます。
他のユーザーのフローを無効にする場合は、そのユーザーにメールを送って、そのユーザーのフローが実行されなくなっていることを知らせる必要があります。 フロー所有者のメール アドレスを取得するには、Office 365 ユーザー コネクタを使用して、所有者のメール アドレスを返すユーザー プロフィールの取得 (V2) アクションを使用します。 所有者のメール アドレスを取得するには、作成者のオブジェクト ID を追加する必要があります。これは、管理者としてフローを一覧表示アクションで取得できます。
Office 365 Outlook コネクタとメールの送信 (V2) アクションを使用して、フローの所有者にメールを送ります。 このメールを送信するには、ユーザー プロフィールの取得 (V2) アクションから返された情報 (メール属性、名前属性など) を使用します。 また、管理者としてフローを一覧表示の出力に含まれるフローの表示名属性を追加して、フロー名を含めることもできます。
テナントのすべてのフローをループするため、isFlowAction変数を false に設定し直して、Twitter アクションを含む可能性のある他のフローを検索できるようにします。 これで、管理フローを保存することができます。
フローをテストするには、別のアカウントを使用して、Power Automate Maker Portal にサインインします。 次に、SharePoint トリガーと Twitter アクションを含むフローを作成します。 このシナリオは、DLP ポリシーによってブロックされませんが、作成した管理フローによって検出されます。
これで、先ほど作成した Twitter アクションの検出フローを管理者として実行することができます。 このフローを実行すると、最近変更されたフローで Twitter アクションが含まれているものが検出されます。 結果として、フローの所有者にメールが送信されます。
SharePoint から Twitter へのフローを確認すると、管理者によってフローが無効にされていることがわかります。
ただし、Twitter から情報を取得して、それを SharePoint に送信することは、ガバナンス ルールには違反しません。 そのため、フロー作成者のアカウントを使用して、Twitter トリガーと SharePoint アクションを含む別のフローを作成することができます。 Twitter アクションの検出ガバナンス フローを実行すると、これは許可されているユース ケースであるため、引き続き機能し、無効にはなりません。
