データ損失防止ポリシーを設計する
実装する前にポリシーを設計する時間を取ると、意図しない問題を少なくして、目的の結果にすばやく到達できます。作成してから、試行錯誤だけでチューニングするよりも短くなります。 ポリシー設計を文書化すると、コミュニケーション、ポリシー レビュー、トラブルシューティング、さらにチューニングにも役立ちます。
Microsoft Purview DLP を初めて使用する場合は、ポリシーの設計を開始する前に、次の記事を確認することをお勧めします。
ヒント
E5 のお客様でない場合は、90 日間の Microsoft Purview ソリューション試用版を使用して、Purview の追加機能が組織のデータ セキュリティとコンプライアンスのニーズの管理にどのように役立つかを確認してください。 Microsoft Purview コンプライアンス ポータルのトライアル ハブで今すぐ開始してください。 サインアップと試用期間の詳細については、こちらをご覧ください。
開始する前に
Microsoft Purview DLP を初めて使用する場合は、DLP を実装するときに必要となるコア記事の一覧を次に示します。
- 管理単位
- Microsoft Purview データ損失防止の詳細 - この記事では、データ損失防止規範と Microsoft による DLP の実装について説明します
- データ損失防止 (DLP) の計画 - この記事を使用して、次の作業を行います。
- データ損失防止ポリシーリファレンス - この記事では、DLP ポリシーのすべてのコンポーネントと、それぞれがポリシーの動作にどのように影響するかを紹介します
- DLP ポリシーの設計 - この記事 (現在読んでいる記事) では、ポリシー意図ステートメントを作成し、それを特定のポリシー構成にマッピングする手順について説明します。
- データ損失防止ポリシーの作成と展開 - この記事では、構成オプションにマップする一般的なポリシー意図シナリオについて説明します。その後、これらのオプションの構成について説明します。
- データ損失防止アラートの調査について説明します -この記事では、最終的な修復とポリシーの調整を通じて、作成からのアラートのライフサイクルについて説明します。 また、アラートの調査に使用するツールについても説明します。
ポリシー設計の概要
ポリシーの設計 は、主に ビジネス ニーズを明確に定義し、ポリシー意図ステートメントに文書化し、 それらのニーズをポリシー構成にマッピングすることです。 計画フェーズで行った決定を使用して、ポリシー設計の決定の一部を通知します。
ポリシーの意図を定義する
1 つのステートメントで、持っているすべてのポリシーのビジネス意図を要約できる必要があります。 このステートメントを開発すると、organizationでの会話が促進され、完全に具体化されると、このステートメントはポリシーをビジネス目的に直接リンクし、ポリシー設計のロードマップを提供します。 データ 損失防止の計画 (DLP) に関する 記事の手順は、ポリシーの意図に関する声明を開始するのに役立ちます。
DLP ポリシー構成の概要で説明されているように、すべての DLP ポリシーでは次のことを行う必要があります。
- 監視する内容を選択する
- ポリシー スコープ (プレビュー) を選択する
- 監視する場所を選択する
- ポリシーを項目に適用するために一致する必要がある条件を選択する
- ポリシー条件が満たされたときに実行するアクションを選択する
たとえば、4 つの質問すべてに対する回答を提供する意図ステートメントの架空の最初のドラフトを次に示します。
"Microsoft は米国に拠点を置くorganizationであり、OneDrive/SharePoint に格納されている HIPPA の対象となる機密性の高い医療情報を含む Office ドキュメントを検出し、Teams チャットおよびチャネル メッセージで共有されるその情報から保護し、承認されていないサード パーティとの共有をすべてのユーザーに制限する必要があります。
ポリシー設計を開発する際に、ステートメントを変更して拡張する可能性があります。
ビジネス ニーズをポリシー構成にマップする
下書きステートメントの例を分解し、DLP ポリシー構成ポイントにマップしてみましょう。 この例では、無制限の DLP 管理者アカウントを使用しており、管理単位が構成されていないことを前提としています。
重要
開始する前に、「管理単位」を読んで、無制限の管理者と管理単位の制限付き管理者の違いを理解していることを確認してください。
| Statement | 構成に関する質問に回答し、構成マッピングを行う |
|---|---|
| "Microsoft は米国に拠点を置くorganizationであり、HIPAA... の対象となる機密性の高い医療情報を含む Office ドキュメントを検出する必要があります。 | - 監視対象: Office ドキュメント、米国医療保険法 (HIPAA) テンプレート- 一致の条件を使用します。(事前構成されているが編集可能) - 項目には、米国 SSN および薬物執行機関 (DEA) 番号、国際疾病分類 (ICD-9-CM)、国際疾病分類 (ICD-10-CM) が含まれており、コンテンツは自分のorganization外のユーザーと共有されます- 信頼度レベルやインスタンス数 (リークトレランスと呼ばれる) などの検出のトリガーしきい値を明確にするために会話を駆動します。 |
| ...OneDrive/SharePoint に格納され、Teams チャットおよびチャネル メッセージで共有されているその情報から保護します。 | - 監視する場所: OneDrive サイトと SharePoint サイト、Teams チャット/チャネル アカウントまたは配布グループを含めたり除外したりして 、場所のスコープ を設定します。 ポリシースコープ (プレビュー): 完全ディレクトリ |
| ...また、承認されていないサード パーティとのアイテムの共有をすべてのユーザーに制限します。 | - 実行するアクション: アクセスの制限を追加するか、Microsoft 365 の場所のコンテンツを暗号化します。共有の制限、通知やアラートなどの認識アクション、ブロックアクションのユーザーオーバーライドを許可するなどのユーザーエンパワーメントアクションなど、ポリシーがトリガーされたときに実行するアクションに関する会話を促進します |
この例では、DLP ポリシーのすべての構成ポイントについては説明しません。拡張する必要があります。 ただし、独自の DLP ポリシー意図ステートメントを開発するときに、適切な方向で考える必要があります。
重要
選択した場所は、機密情報の種類、秘密度ラベル、保持ラベルを使用できるかどうかに影響します。 選択した場所は、使用可能なアクションにも影響します。 詳細については、「 データ損失防止ポリシー リファレンス」 を参照してください。
複雑なルール設計
SharePoint と OneDrive の上記の HIPPA コンテンツは、DLP ポリシーの簡単な例です。 DLP ルール ビルダーでは、ブールロジック (AND、OR、NOT) と入れ子になったグループがサポートされています。
重要
- 既存のすべての 例外 は、条件内の入れ子になったグループ内の NOT 条件に置き換えられます。
- 複数の演算子を使用するには、グループを作成する必要があります。
重要
Office デスクトップ クライアント アプリ (Word、Outlook、Excel、PowerPoint) のアクションが複雑な条件を使用するポリシーと一致する場合、ユーザーには、コンテンツに機密情報条件が含まれているルールのポリシー ヒントのみが表示されます。
例 1 クレジット カード番号を含むすべての受信者、または "機密性の高い" 秘密度ラベルが適用されているすべての受信者へのメールをブロックする必要がありますが、財務チームの誰かから電子メールが送信された場合はブロックしません。adele.vance@contoso.com
例 2 Contoso は、パスワードで保護されたファイルまたは zip ドキュメント ファイル拡張子 ('zip' または '7z') を含むすべてのメールをブロックする必要がありますが、受信者が contoso.com ドメインまたは fabrikam.com ドメインにある場合、または送信者が Contoso HR グループのメンバーである場合は電子メールをブロックしない必要があります。
重要
- 入れ子になったグループで NOT 条件を使用すると、 例外 機能が置き換えられます。
- 複数の演算子を使用するには、グループを作成する必要があります。
重要
Office デスクトップ クライアント アプリ (Word、Outlook、Excel、PowerPoint) のアクションが複雑な条件を使用するポリシーと一致する場合、ユーザーには、コンテンツに機密情報条件が含まれているルールのポリシー ヒントのみが表示されます。
ポリシー設計プロセス
「 データ損失防止 (DLP) の計画 」の手順を完了します。この記事を使用して、次の作業を行います。
DLP ポリシーのすべてのコンポーネントと、それぞれがポリシーの動作にどのように影響するかを理解できるように、 データ損失防止ポリシーリファレンス について理解します。
DLP ポリシー テンプレートに含まれる内容について理解します。
主要な利害関係者と共にポリシー意図ステートメントを作成します。 この記事の前の例を参照してください。
このポリシーが DLP ポリシー戦略全体にどのように適合するかを決定します。
重要
ポリシーは、作成後に名前を変更することはできません。 ポリシーの名前を変更する必要がある場合は、目的の名前を持つ新しいポリシーを作成し、古いポリシーを廃止する必要があります。 そのため、最初から、すべてのポリシーで使用される名前付け構造を決定します。
ポリシー意図ステートメントの項目を構成オプションにマップします。
どのポリシー テンプレートから開始するかを決定します。定義済みまたはカスタム。
テンプレートを参照し、ポリシーを作成する前に必要なすべての情報を組み立てます。 ポリシー意図ステートメントで説明されていない構成ポイントがいくつか存在する可能性があります。 いいですよ。 不足している構成ポイントの要件をアイロンで把握するために、関係者に戻るします。
すべてのポリシー設定の構成を文書化し、関係者に確認します。 ポリシー意図ステートメントの構成ポイントへのマッピングを再利用できます。これで、完全に具体化されています。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示