PSPF に対するオーストラリア政府のコンプライアンスに関するセキュリティ機密情報の不適切な配布の防止
この記事では、Microsoft 365 サービスを介してセキュリティの機密情報が不適切に開示されるリスクを軽減するための構成に関するガイダンスをオーストラリア政府機関向けに提供します。 その目的は、組織が情報セキュリティ体制を改善するのを支援することです。 この記事のアドバイスは、 保護セキュリティ ポリシー フレームワーク (PSPF) と 情報セキュリティ マニュアル (ISM) に記載されている要件と一致します。
保護セキュリティ ポリシー フレームワーク (PSPF) は、x-保護マーキング x ヘッダーだけでなく、その他の要件と制御の範囲をカバーします。 この記事では、 PSPF ポリシー 9: 情報へのアクセスに関する情報に関する、分類されたセキュリティの開示またはその他の機密情報の開示を制限することに関連する要件について説明します。
この記事では、次に関連するアドバイスと構成について説明します。
- Exchange Online電子メール シナリオ、
- チャットとチャネル メッセージングMicrosoft Teams、
- SharePoint と OneDrive を使用したシナリオの共有、
- クラウド ストレージ サービスにアップロードし、
- マネージド デバイスにダウンロードまたは印刷する。
機密情報の電子メール配布の防止
このセクションのデータ損失防止 (DLP) ポリシーは、受信者ドメインなど、必要なポリシー条件を有効にするためにのみ Exchange サービスを対象とします。これは、他のサービスが選択されている場合は使用できません。
PSPF の要件を満たすために、DLP ポリシーでは カスタム ポリシー テンプレートの使用も必要です。 DLP ポリシーと共に、ラベルの継承で説明されているように、電子メールの添付ファイルの ラベルの継承を有効にする必要があります。 ラベルの継承により、電子メールの機密性が添付ファイルよりも低い場合は、ユーザーが添付ファイルに合わせて電子メールのラベルを昇格するよう要求する推奨事項がトリガーされます。 ユーザーの機関による推奨事項と承認により、電子メールは、より機密性の高い添付ファイルの分類に適用されるすべてのポリシーのスコープに取り込まれます。
注:
DLP ポリシーで考慮される電子メールと添付ファイルの両方の機密性を可能にするプレビュー機能があります。 これらの機能の使用をお勧めします。 詳細については、「Microsoft Purview コンプライアンス ポータル: データ損失防止 - メッセージ/添付ファイルに EXO 述語が含まれている」を参照してください。
未承認の組織への機密情報の電子メール配布の防止
PSPF ポリシー 9 要件 1 は、セキュリティの機密情報を承認された組織にのみ開示する必要があることを示しています。
要件 | 詳細 |
---|---|
PSPF ポリシー 9 要件 1 - 情報とリソースを共有するための正式な契約 (v2018.6) | セキュリティの機密情報またはリソースを政府の外部の人またはorganizationに開示する場合、エンティティは、契約や行為などの契約や取り決めを行い、情報の利用方法と保護方法を管理する必要があります。 |
注:
PSPF Policy 8 (v2018.6) に従って、OFFICIAL: Sensitive が普及制限マーカー (DLM) からセキュリティ分類に変更されました。 これは、OFFICIAL: 機密情報の共有に対するorganizationのアプローチに影響する必要があります。
PSPF 要件を満たすために、政府機関は次の要件を満たす必要があります。
- セキュリティの機密情報を共有するエンティティとの正式な契約を特定、確立、確認するためのビジネス プロセス。
- ユーザーがセキュリティの機密情報を外部組織に送信することを許可または禁止するための構成変更の技術的な変更プロセス。
組織には、セキュリティ分類またはサブセットごとに異なる情報セキュリティ要件があります (情報管理マーカー (IMM) や警告など)。 分類またはサブセットごとの要件に対応するために、個別のポリシーまたはルールを作成する必要があります。
承認されていない組織へのセキュリティの機密情報の電子メール ベースの配布を禁止する DLP ルールを作成するには:
- コンテンツの条件の作成は、Microsoft 365 から共有され、organization外のユーザーと共有されます。
- 秘密度ラベルと適切なラベルが含まれているコンテンツの 2 つ目の条件 (PROTECTED ラベルや関連するサブラベルなど) を作成します。
-
AND オペランドを使用してリンクされた 2 つ目の条件グループを作成します。
- 2 番目のグループは NOT に設定されます。
- 2 番目のグループには、選択したセキュリティ分類の受信が承認されたドメインの一覧と共に、受信者ドメインの条件が含まれています。
- 構成された受信者ドメインの 1 つではない受信者に電子メールをブロックまたはリダイレクトするアクションを作成します。
DLP ルールの例: 承認されていない組織への保護されたメールをブロックする
次の規則では、情報の受信が承認されていない組織への PROTECTED メールの送信を制限します。 ユーザーが PROTECTED ラベルが適用されたメールを下書きしている間に、ユーザーが承認されていないorganizationから受信者を追加すると、DLP ポリシーヒントが表示され、ユーザーに警告が表示されます。 ユーザーがポリシー ヒントを無視して送信しようとすると、メールはブロックされます。
条件 | アクション |
---|---|
コンテンツは Microsoft 365 から共有されます。 私のorganizationの外の人々と AND コンテンツには秘密度ラベルが含まれています。 - すべての PROTECTED ラベル AND グループ NOT 受信者ドメインは次のとおりです。 - PROTECTED メールの受信が承認されたドメインの一覧 |
アクセスを制限するか、Microsoft 365 の場所のコンテンツを暗号化します。 - ユーザーがメールまたはアクセスを受信できないようにブロックする - すべてのユーザーをブロックする 次のポリシー ヒントを構成します。 "この電子メールの受信者は、PROTECTED 情報の受信が承認されていないorganizationから送信されます。 未承認の受信者が宛先フィールドから削除されない限り、このメールはブロックされます。 これが正しくない場合は、サポートにお問い合わせください。 適切なインシデントの重大度と通知オプションを構成します。 |
ヒント
オーストラリア政府機関は、PROTECTED と OFFICIAL: 機密メールの両方について、承認されていない組織に電子メールを制限する DLP ルールの構成を検討する必要があります。
承認されたゲストへの機密情報の電子メール配布の許可
知る必要がある場合、政府機関は、ドメイン ベースのアプローチをゲスト アクセスと統合し、適用されたラベルとゲスト グループまたはドメインに応じて複数レベルのゲスト アクセスを統合する必要があります。
承認されたゲストアクセス許可は、次のいずれかによって実現されます。
手動で管理されたグループ ( 保護されたゲストなど) の作成。承認された外部組織のゲストが含まれており、クリアランスステータスがチェックされています。又は
指定したドメインからのゲスト アカウントを含むように構成された動的グループの作成。 これは、ユーザーのユーザー プリンシパル名 (UPN) を評価する動的クエリを使用することで実現できます。 以下に例を示します。
(user.userPrincipalName -match "#EXT#") and (user.userPrincipalName -match "microsoft.com")
動的グループ メンバーシップの詳細については、「Microsoft Entra IDのグループの動的メンバーシップ規則」を参照してください。
PROTECTED 情報をドメインとゲスト アカウントのサブセットに受け取る機能を制限する利点は、次のメール ベースのシナリオで示されています。
ゲスト シナリオ | ドメイン ベースのコントロールのみ | ドメインとゲスト ベースの制御 |
---|---|---|
承認されていないドメインからのゲスト |
リスク軽減 セキュリティの機密情報を受信できない1 |
リスク軽減 セキュリティの機密情報を受信できない1 |
セキュリティの機密情報が承認されたドメインからのゲスト |
リスクの存在 知る必要に関係なく、セキュリティの機密情報を受け取ることができるすべてのドメイン ユーザー |
リスク軽減 セキュリティの機密情報を受信できない2 |
承認されていないドメインからのゲスト |
リスク軽減 セキュリティの機密情報を受信できない1 |
リスク軽減 セキュリティの機密情報を受信できない2 |
承認済みドメインからのゲスト |
リスクの存在 知る必要に関係なく、セキュリティの機密情報を受け取ることができるすべてのドメイン ユーザー |
リスク軽減 セキュリティの機密情報を受信できない2 |
承認済みドメインからの ゲストと、保護されたゲスト グループの一部 |
リスクの存在 知る必要に関係なく、セキュリティの機密情報を受け取ることができるすべてのドメイン ユーザー |
リスク軽減 セキュリティの機密情報を受け取ることができるのは、 保護されたゲスト として追加されたドメイン ユーザーのみです。 |
このような構成を使用する組織では、ゲスト グループ メンバーシップのメンテナンスをサポートするビジネス プロセスが必要です。 また、organizationは、機密メールの配布を制限する DLP ルールの例外として、保護されたゲスト グループを追加する必要があります。
承認されたゲストへのセキュリティの機密情報の電子メール ベースの配布を許可する DLP ルールは次のとおりです。
- コンテンツの条件の作成は、Microsoft 365 から共有され、organization外のユーザーと共有されます。
- 秘密度ラベルと適切なラベルが含まれているコンテンツの 2 つ目の条件 (PROTECTED ラベルや関連するサブラベルなど) を作成します。
-
AND オペランドを使用してリンクされる 2 つ目の条件グループを作成します。
- 2 番目のグループは NOT に設定されます。
- これには、受信者が保護されたゲストのメンバーであるという条件が含まれています。
- 選択したグループに属していない受信者に電子メールをブロックまたはリダイレクトするアクションを作成します。
DLP 規則の例: 承認されていないゲストへの保護された電子メールをブロックする
次の規則は、前述の例に基づいて作成されています。これにより、承認済みドメインのユーザーと、保護されたゲスト グループに含まれているユーザーへの PROTECTED メールの送信が許可されます。
条件 | アクション |
---|---|
コンテンツは Microsoft 365 から共有されます。 私のorganizationの外の人々と AND コンテンツには秘密度ラベルが含まれています。 - すべての PROTECTED ラベル AND グループ NOT 受信者ドメインは次のとおりです。 - PROTECTED メールの受信が承認されたドメインの一覧 AND グループ NOT 受信者は、次のメンバーです。 - 保護されたゲスト |
アクセスを制限するか、Microsoft 365 の場所のコンテンツを暗号化します。 - ユーザーがメールまたはアクセスを受信できないようにブロックする - すべてのユーザーをブロックする 適切なポリシー ヒントを構成します。 "このメールの受信者は、PROTECTED 情報の受信を承認されていません。 未承認の受信者が宛先フィールドから削除されない限り、このメールはブロックされます。 これが正しくない場合は、サポートに問い合わせて要件について話し合ってください。 適切なインシデントの重大度と通知オプションを構成します。 |
未承認のユーザーへの機密情報の電子メール配布の防止
PSPF ポリシー 9 要件 3 は、セキュリティの機密情報へのアクセスに必要なクリアランス レベルに関係しています。
要件 | 詳細 |
---|---|
PSPF ポリシー 9 要件 3: 継続的なアクセス セキュリティの機密情報とリソース | エンティティは、セキュリティの機密情報またはリソースへの継続的なアクセスを必要とするユーザーが、セキュリティを適切なレベルにクリアするようにする必要があります。 |
セキュリティが混在したクリアされたユーザーの種類を持つ環境を持つ政府機関では、特定のユーザーは、organizationによって保持されている情報の種類にアクセスするためのクリアランスを必要としません (または知る必要はありません)。 これらの組織では、セキュリティの機密情報にアクセスできないユーザーが電子メールで受信できないようにする制御が必要です。 このような構成は、DLP を使用して実現されます。
不明なユーザーに電子メールを制限する DLP ルールでは、機密情報の受信を許可されている内部ユーザーを決定する方法が必要です。 前の例と同様に、これにはグループ ( 保護されたユーザー グループなど) が使用されます。 このグループは、各個人のセキュリティ クリアランスに合わせて属性に基づいてメンバーシップが維持される動的です。 これは、人事システムまたは ID システムから調達できます。 または、 受信者 AD 属性の一致パターン の条件を DLP ポリシーで直接構成することもできます。
新しいポリシーに含まれる DLP ルール、または前のセクションで示したポリシーに追加された DLP ルール。 ルールには次のものが含まれます。
- コンテンツの条件は Microsoft 365 から共有され、organization内のユーザーと共有されます。
- [コンテンツ] の条件には、関連するラベル (たとえば、すべての PROTECTED ラベル) が選択されている これらの秘密度ラベルのいずれかが含まれています 。
- AND オペランドを介してリンクされる 2 つ目の条件グループ。 2 番目のグループは NOT に設定されます。 これには、保護されたユーザーのメンバーである受信者の条件が含まれています。
- 選択したグループに属していない受信者に電子メールをブロックまたはリダイレクトするアクションを必要とするポリシー。
DLP ルールの例: 非クリア内部ユーザーへの保護された電子メールをブロックする
このルールは、保護されたユーザーのグループに属していない ユーザーが 、PROTECTED ラベルが適用されたメールを受信できないようにブロックします。
条件 | アクション |
---|---|
コンテンツは Microsoft 365 から共有されます 私のorganizationの中の人々とだけ AND コンテンツには秘密度ラベルが含まれています。 - すべての PROTECTED ラベル AND グループ NOT 受信者は、次のメンバーです。 - 保護されたユーザー |
アクセスを制限するか、Microsoft 365 の場所のコンテンツを暗号化します。 - ユーザーがメールまたはアクセスを受信できないようにブロックする - すべてのユーザーをブロックする 次のように、適切なポリシー ヒントを構成します。 "指定したユーザーが PROTECTED アイテムへのアクセスを承認されていません。 適切なインシデントの重大度と通知オプションを構成します。 |
その結果、 電子メール ベースの自動ラベル付け構成の例に沿って自動ラベル付けが構成されている場合、外部組織から受信したマーク付きメールは受信時にラベル付けされ、不明瞭なユーザーに対してブロックされます。 自動ラベル付けの使用には、E5 またはそれと同等のライセンスが必要です。 ただし、自動ラベル付け機能を使用しないことを選択した組織は、秘密度ラベルではなくマーキングを評価することで、PSPF Policy 9 要件 3 を満たすことができます。
注:
組織では、自動ラベル付けを使用して、マークを評価するルールを実装することをお勧めします。これは、 再分類に関する考慮事項で説明されているように、項目が不正にラベル付けされたり、ラベルが悪意を持って下げたりした場合に流出を防ぐことができるためです。
次の規則では、x-protect-marking x-headers または subject マーキングのいずれかに適用される PROTECTED マーキングをチェックし、受信者が 保護されたユーザーの グループに属していない場合は電子メールをブロックします。
条件 | アクション |
---|---|
コンテンツは Microsoft 365 から共有されます。 私のorganizationの中の人々とだけ AND グループ NOT 受信者は、次のメンバーです。 - 保護されたユーザー AND GROUP ヘッダーはパターンと一致します。 X-Protective-Marking : SEC=PROTECTED または サブジェクトがパターンと一致する: \[SEC=PROTECTED |
アクセスを制限するか、Microsoft 365 の場所のコンテンツを暗号化します。 - ユーザーがメールまたはアクセスを受信できないようにブロックする - すべてのユーザーをブロックする 次のように、適切なポリシー ヒントを構成します。 "指定したユーザーが PROTECTED アイテムへのアクセスを承認されていません。 適切なインシデントの重大度と通知オプションを構成します。 |
未承認のユーザーによる機密情報の電子メールの防止
未承認のユーザーがテナント内で既に機密情報を受信できないようにすることが重要です。 ただし、ローカル ストレージ、USB、またはその他の nonemail ベースのメソッドを使用して、ユーザーが PROTECTED ファイルにアクセスする状況を検討してください。 その後、ユーザーはアイテムをメールに添付して送信します。 ユーザーがセキュリティの機密情報を 送信 する権限を持っていることを確認すると、データ侵害のリスクが軽減されます。
ユーザーが機密情報を送信する前に、機密情報へのアクセスが承認されているかどうかをチェックする DLP ルールは次のとおりです。
- [コンテンツ] の条件の作成には、関連するラベル (たとえば、すべての PROTECTED ラベル) が選択された 、これらの秘密度ラベルのいずれかが含まれます 。
-
AND オペランドを使用してリンクされる 2 つ目の条件グループを作成します。
- 2 番目のグループは NOT に設定されます。
- 送信者が、保護されたユーザーのメンバーであるという条件が含まれています。
- ポリシーには、選択したグループに属していない受信者に電子メールをブロックまたはリダイレクトするアクションが必要です。
承認されていないユーザーによるセキュリティで分類された電子メールの配布を制限する DLP 規則の例
次の DLP ルールを使用すると、PROTECTED 情報へのアクセスが承認されたユーザーのみが送信できるようになります。 これらのルールにより、セキュリティ イベント (偶発的または悪意のあるオーバーシェア、不適切なアクセス許可、セキュリティ構成など) で、分類されたアイテムへのアクセス権を取得する不明なユーザーは、セキュリティの機密情報をさらに配布することでデータ侵害を悪化させないようにします。
Rule | 条件 | アクション |
---|---|---|
PROTECTED メールの内部送信を制限する | コンテンツは Microsoft 365 から共有されます。 私のorganizationの中の人々とだけ AND コンテンツには秘密度ラベルが含まれています。 - すべての PROTECTED ラベル AND グループ NOT Sender は、次のメンバーです。 - 保護されたユーザー |
アクセスを制限するか、Microsoft 365 の場所のコンテンツを暗号化します。 - ユーザーがメールまたはアクセスを受信できないようにブロックする - すべてのユーザーをブロックする 必要に応じてポリシーヒントを構成します。 適切なインシデントの重大度とアラートを構成する |
PROTECTED メールの外部送信を制限する | コンテンツは Microsoft 365 から共有されます。 organization外の人とだけ AND コンテンツには秘密度ラベルが含まれています。 - すべての PROTECTED ラベル AND グループ NOT Sender は、次のメンバーです。 保護されたユーザー |
アクセスを制限するか、Microsoft 365 の場所のコンテンツを暗号化します。 - ユーザーがメールまたはアクセスを受信できないようにブロックする - すべてのユーザーをブロックする 必要に応じてポリシーヒントを構成します。 適切なインシデントの重大度とアラートを構成する |
Teams チャットを使用してセキュリティで分類されたアイテムの配布を防止する
Microsoft Purview DLP を使用してMicrosoft Teamsを保護する方法については、「 損失防止とMicrosoft Teams」を参照してください。
Teams のファイル共有アクティビティは、共有リンクを介して機能するため、 セキュリティの機密情報の共有を防止する方法で説明されている DLP ポリシー設定を使用して、ラベル付けされたアイテムを保護できます。
Teams チャットに秘密度ラベルを適用することはできません。 そのため、分類ベースの DLP ポリシーは直接適用されません。 ただし、機密情報とセキュリティ マーキングを検出するポリシーについては、「 DLP による外部チャットの制限」で説明します。
セキュリティの機密情報の共有の防止
注:
ASD の Secure Cloud のブループリント には、 SharePoint 共有構成のガイダンスが含まれています。 ASD のアドバイスでは、すべての共有リンクをorganizationのユーザーのみに制限することをお勧めします。 すべての共有を内部のみに設定することは、PROTECTED レベルで動作する組織にとって適切な既定の状態です。
一部の組織では、他の組織との安全なコラボレーションなどの高度なユース ケースに対応するために、共有構成を調整する必要があります。 高い外部コラボレーション制御や ASD の Blueprint for Secure Cloud のその他の関連セクションに含まれるようなアドバイスが提供されています。これにより、低レベルのリスクで実行でき、添付ファイルを電子メールで送信する従来のアプローチよりも情報セキュリティに対応する構成が簡単になります。
各organizationには既定の共有構成があり、SharePoint 共有構成が構成されています。 これにより、共有リンクの受信が承認されたドメインの一覧を構成できます。 このような構成は、PSPF ポリシー 9 要件 1 - 情報とリソースを共有するための正式な契約と一致しています。
ラベルグループとサイト設定では、ラベル共有 の構成で説明されているように、ラベル付き場所からのアイテムの共有をさらに制限できます。 設定を構成すると、PROTECTED ドキュメントなどのセキュリティで分類されたアイテムには、PROTECTED の場所からの共有オプションが制限されます。 グループとサイトの構成例の構成では、そのような場所から内部受信者にのみ共有を制限します。
組織は、場所ベースの共有制限に加えて、DLP ポリシーを実装して、外部配布に適していないアイテムの外部共有をブロックしたり、警告したり、ユーザーを警告したり、除外したりする必要があります。 次のポリシー例は、PROTECTED ドキュメントに適用され、外部ユーザーと共有されないようにします。
条件 | アクション |
---|---|
コンテンツは Microsoft 365 から共有されます。 organization外の人とだけ AND コンテンツには秘密度ラベルが含まれています。 - すべての PROTECTED ラベル |
アクセスを制限するか、Microsoft 365 の場所のコンテンツを暗号化します。 - ユーザーがメールまたはアクセスを受信できないようにブロックする - organization外のユーザーのみをブロックする 次のように、適切なポリシー ヒントを構成します。 "保護されたアイテムは、外部の受信者との共有には適していません。 適切なインシデントの重大度とアラートを構成する |
ヒント
SharePoint ベースの DLP ポリシーはユーザーベースではなく場所なので、例外はユーザーごとまたはグループごとに適用されません。 ただし、OneDrive に適用するポリシーは、特定のユーザーにスコープを設定できます。
DLP ポリシーのヒントは、ユーザーに役立つフィードバックを提供するように構成できます。 SharePoint ベースの場所に格納されているポリシー ヒントに一致するファイルは、ドキュメント ライブラリ内のアイコン マーキングの恩恵を受けます。 DLP ポリシーの例にはポリシー ヒントが含まれており、ポリシーによってアクセス制限が適用されるため、ドキュメント ライブラリにハイフンが含まれる円を示すアイコンが表示され、アイテムが制限の対象であることをユーザーに通知します。
ユーザーがポリシー ヒントを無視し、PROTECTED アイテムを外部で共有しようとすると、ポリシー ヒントが共有ダイアログに表示されます。
たとえば、 すべてのリンクなど、より許容されるリンクの種類を外部ユーザーに電子メールで送信するなどして、ユーザーが DLP ポリシーをバイパスしようとすると、DLP ポリシーは引き続きトリガーされ、レポートを生成し、構成されている場合は、ユーザーに DLP 通知を送信します。
その他の共有シナリオ
政府機関が該当するその他の共有シナリオについては、このセクションで説明します。
保護されたチームなど、セキュリティで保護された場所のメンバーが不適切にアイテムを共有した場合はどうでしょうか。
Microsoft の 信頼と検証 のアプローチにより、チーム内のすべてのユーザーが場所の共有ポリシーに沿ってコンテンツを共有できます。 さらに制限が必要な場合、オプションには次のものが含まれます。
秘密度ラベル グループとサイトの構成 は、ラベル付き場所に 条件付きアクセス ポリシーを適用するために使用されます。 認証コンテキスト では、ラベル付けされた場所のコンテンツへのアクセスを許可する前に、ユーザーが承認されたユーザーのグループの一部であることを確認します。
ラベル付きの場所は、さらに制限できます。 PowerShell を使用してラベルの構成を設定
MemberShareNone
、サイトまたはチームの所有者は、ラベルが適用された場所からの情報の配布を制御できます。 メンバー共有の制限の詳細については、「メンバーの 共有」を参照してください。情報バリア暗黙的な Microsoft 365 グループ コントロールを使用して、非チーム メンバーとのアイテムの共有をブロックできます。 この機能は、ユーザーのグループ間で通信とコラボレーションを防止する必要がある状況に適しています。
ユーザーが PROTECTED アイテムを、共有がより許容される別の場所に移動した場合はどうなりますか?
ユーザーが、保護された項目をより低い秘密度の場所 (共有がより許容される別のチームなど) に移動して、共有とアクセス制御をバイパスしようとすると、次のようになります。
- データの配置外 アラートがトリガーされ、ユーザーにアクションの警告が表示されます。
- 監視データの構成に従ってセキュリティ チームに アラートを送信するアラート。
SharePoint 共有構成は、ユーザーが共有できるドメインの一覧を構成するために使用されます。 構成後、ユーザーは承認された組織の外部でアイテムを共有できません。
OneDrive の場所には、ラベル付き場所に適用される共有ポリシーよりも、より許容される共有ポリシーが含まれる場合があります。 場所ベースのコントロールをバイパスするために OneDrive からのユーザー共有に関連するリスクを軽減するために、OneDrive の特定のラベルとのアイテムの共有を制限するように DLP ポリシーが構成されています。 ポリシーは、信頼されたユーザーのみが OneDrive の場所のラベル付きアイテムをゲストと共有できるように、ユーザーのグループにも適用されます。
重要
PROTECTED アイテムへのアクセスが承認されているユーザーは、organizationのグローバル OneDrive 共有構成と、アカウントに適用された OneDrive 共有構成の両方に沿って、OneDrive からそのようなアイテムを共有できます。
悪意のある内部関係者が、セキュリティの機密情報を流出させるためにアクティビティを繰り返し共有しようとするとどうなるでしょうか。
動機付けられた悪意のあるインサイダーは、この記事で示されているデータ セキュリティ制御を回避するために多数の試行を実行する可能性があります。 Microsoft の Insider Risk Management (IRM) 機能は、ユーザーのアクティビティに基づいてユーザーのリスク プロファイルを決定するために使用されます。 IRM を使用すると、セキュリティ チームは、次のような疑わしい一連のユーザーを監視できます。
- 特定のラベルが適用された Microsoft 365 の場所から情報をダウンロードし、USB にコピーします。
- ラベルを下げるか削除してから、外部ユーザーと共有します。
- 機密性の高い情報として識別され、クラウド サービスを介して情報を流出させる難読化。
IRM は、 アダプティブ保護と呼ばれる機能を介して Microsoft Purview DLP ポリシーと統合されます。 これにより、構成されたポリシーが継続的にトリガーされるために危険と見なされるユーザーが識別され、セキュリティ チームが調査できるようになるまでリスクを軽減するために、自動的に追加の制限が適用されます。
ヒント
機密データには、暗号化コントロールの使用 ( 秘密度ラベルの暗号化で説明されているように) を使用する必要があります。 ラベル暗号化は、内部と外部の両方の承認されたユーザーのみが、アイテムの場所に関係なくセキュリティで分類されたアイテムにアクセスできるようにするために役立ちます。
セキュリティで分類されたアイテムが管理されていない場所にアップロードされないようにする
Defender for Cloud Appsは、クラウド サービスのorganizationの使用のセキュリティ体制を支援します。 これは、ユーザーアクティビティと機密情報をきめ細かく可視化し、制御することで実現します。
Defender for Cloud Appsポリシーは、Microsoft 365 Defender コンソールの [Cloud apps>Policies] メニューで構成されます。 管理者は、PROTECTED ラベルを持つファイルを対象とするポリシーを作成し、承認されていないドメインと共有できないようにすることができます。 この構成は、PSPF Policy 9 要件 1 に準拠しており、セキュリティで分類されたアイテムは正式に承認された組織とのみ共有する必要があることを示しています。
Defender for Cloud AppsとMicrosoft Purview Information Protectionの統合の詳細については、「Microsoft Purview Information Protection統合」を参照してください。
セキュリティで分類されたアイテムのダウンロードまたは印刷を禁止する
このセクションでは、セキュリティで分類されたアイテムまたは情報が、Microsoft 365 テナントの管理外の場所にコピーされるリスクに対処します。 以下に例を示します。
- ユーザーが保護された項目を暗号化されていない USB ドライブにコピーすると、紛失または盗難が発生します。
- PROTECTED 項目は、オンプレミスのネットワーク共有または場所にコピーされます。これは、PROTECTED アイテムのストレージに適していません。
- PROTECTED アイテムに含まれる情報は、同じコントロールを適用せずに新しい項目にコピーして貼り付け、情報を流出させます。
エンドポイント データ損失防止 (エンドポイント DLP) は、これらのリスクに対処するために使用されます。 エンドポイント DLP のオンボード手順については、「エンドポイント DLP の概要」を参照してください 。
政府機関は、Microsoft 365 DLP 対応ブラウザーのみを使用するための制限を必要とします。 Chromiumは DLP 対応であり、Google Chrome はブラウザー アドインを介して DLP 対応にすることができます。 Microsoft Purview Chrome 拡張機能の詳細については、「 Microsoft Purview Chrome 拡張機能の概要」を参照してください。
エンドポイント DLP を使用してデバイスをターゲットにするには、 デバイス の場所をスコープとする DLP ポリシーを作成します。
他の DLP の例と同様に、ポリシーは、条件として秘密度ラベルを含むコンテンツを使用して構成できます。 [ポリシー アクション] で、[ 監査]、[ オーバーライドでブロック]、または [次のアクションを ブロックする] を選択できます。
- 制限付きクラウド サービス ドメイン (Google ドライブなど) にアイテムをアップロードする (政府機関の ブロック に共通)
- アイテムからクリップボードにコピーする
- アイテムを削除可能な USB にコピーする (政府機関で オーバーライドを使用してブロック するのと一般的)
- ネットワーク共有にコピーする
- 印刷
- 許可されていないBluetooth アプリを使用してコピーまたは移動する (政府機関で ブロック するのと共通)
- リモート デスクトップ プロトコルを使用してコピーまたは移動する (政府機関の ブロック に共通)
注:
EndPoint DLP を使用すると、組織は、アプリケーション、パスの除外、許可されたブラウザー、許可されたプリンター、許可された USB デバイスなど、さまざまなオプションを構成できます。 これらの設定は、ポリシーと共に使用して、ラベル付けされた項目の使用が許可される状況を定義できます。