PSPF に対するオーストラリア政府のコンプライアンスに関するラベル ポリシーを使用した秘密度ラベルの展開

この記事では、Microsoft Purview 秘密度ラベル ポリシーの構成に関するオーストラリア政府機関向けのガイダンスを提供します。 その目的は、 保護セキュリティ ポリシー フレームワーク (PSPF) と 情報セキュリティ マニュアル (ISM) に記載されている要件に最適に合わせてラベル ポリシーを構成する方法を示します。

ユーザーが秘密度ラベルを選択して項目に適用できるようにするには、ラベル ポリシーを使用して公開する必要があります。 ラベル ポリシーは、情報保護メニューの Microsoft Purview ポータル内で構成されます。

秘密度ラベルを作成するプロセスの詳細な手順については、「秘密度ラベルの 作成」を参照してください。

より詳細な要件を持つ組織には、追加のポリシーが必要です。 たとえば、PROTECTED ラベルと関連付けられたサブラベルをユーザーのサブセットに公開する必要がある組織では、これを実現するために別のポリシーが必要です。 保護されたラベル ポリシーという名前のポリシーを作成できます。このポリシーでは、PROTECTED ラベルのみが選択されています。 その後、ポリシーを 保護されたユーザー グループに 発行できます。

ラベル ポリシー設定

秘密度ラベル ポリシーには、秘密度ラベル対応クライアントの動作を制御するさまざまなポリシー設定が含まれています。 これらの設定は、オーストラリア政府機関がいくつかの重要な要件を満たすことを許可するために重要です。

既定のラベル

[既定のラベル] オプションは、選択したラベルを既定でアイテムに自動的に適用するように Microsoft 365 に指示します。 オーストラリア政府 PSPF と ISM の要件を満たすために、既定のラベル設定は none に設定されます。

ラベル変更の正当な理由

オーストラリア政府機関の場合、Microsoft では、すべてのラベル ポリシーでラベル変更の正当な理由を 有効 にすることをお勧めします。

ほとんどの組織では、情報の機密性は時間の経過とともに変化する可能性があります。例としては、禁輸情報、メディア リリース、および行の保持などがあります。 ラベル変更の正当な理由は、ユーザーが適用されたラベルを削除または下げようとしたときにトリガーされます。 このポリシー設定では、ユーザーが変更の理由を指定する必要があります。

すべてのラベルの変更とその正当な理由の応答は監査ログに記録され、 Microsoft Purview アクティビティ エクスプローラーの管理者が表示できます。

ラベル変更アラート

ラベルの変更は、 Microsoft Sentinel やその 他 のセキュリティ情報とイベント管理 (SIEM) で警告するように簡単に構成できます。

すべての変更に対する政府のラベル アラートは、不要な "ノイズ" を引き起こす可能性があります。これにより、さらなる調査を必要とするアラートが難読化される可能性があります。 次の例では、Government 設定でこの構成を示します。

ラベル変更の理由は、サブラベル間の変更に対して自動的にトリガーされることはありません。 この記事で提供されている構成と同様のラベル分類を使用している場合、ユーザーはアクションを正当化することなく、情報管理マーカー (IMM) を追加または削除できます。 ただし、これらのラベルの変更は監査ログに記録されます。

政府機関は、ラベル変更の正当な保持要件を検討し、これらに従って監査ログ保持ポリシーを構成する必要があります。 監査ログとログ保持のオプションの詳細については、 監査ログに関するページを参照してください。

再分類に関する考慮事項

ラベル変更の正当な理由は、使用可能なオプションが政府機関の要件の意図とは異なる機能です。 PSPF は、 発信者 が最初に情報を生成または受信したエンティティを定義し、その分類解除または再分類を制御する責任を引き続き負う必要があることを示します。

さらに、ISM-1089 は次のように述べています。

Microsoft Purview で使用されるアプローチは、アイテムを編集し、それらのアイテムに適用されるラベルを調整するアクセス許可を持つユーザーを許可する "信頼が検証" の 1 つです。 ラベル変更の正当な理由により、変更の監視と説明責任が提供されます。

MICROSOFT の "信頼が検証" アプローチに沿った PSPF 再分類要件を検討しているユーザーは、次の使用可能なオプションを認識する必要があります。

ポリシーベースのアプローチ

Microsoft では、分類解除要件を満たす主要な方法として、オーストラリア政府機関が独自の組織ポリシー ベースの制御を主導することを推奨しています。 さらに、不適切なパターンを検出するために、監視とアラートを使用してポリシー ベースのコントロールを強化することをお勧めします。 これは、構成によって項目の変更が妨げるためです。 "ロック" ラベルの結果は、特に変更がある場合に、ユーザーと管理者に影響します。 たとえば、組織が共有するアイテムのラベルの "ロック" には暗号化の使用が必要な場合があり、レコード管理システムなどの他のサービスに影響を与える可能性があります。 これらのアクセス許可は、ユーザーのドメインに関連付ける必要もあります。これは、Government (MoG) の変更の影響を受ける可能性があります。

政府機関が利用可能なオプションを検討している場合、PSPF には成熟度のスケールとコア要件とサポート要件のカテゴリの両方が含まれていることを覚えておく必要があります。 組織は、PSPF の目標を満たすために、このサポート要件の重要性に関して独自の決定を行い、要件を次に照らして検討する必要があります。

• ユーザビリティ
• 潜在的なユーザーへの影響
• PSPF の成熟度全体への影響
• MoG の可能性

DLP ベースのアプローチ

このアプローチでは、Microsoft Purview と階層化された追加の Microsoft 365 機能を使用して、情報の流出に関連するリスクを軽減します。 たとえば、DLP を使用して機密情報が組織から離れることをブロックします。 項目は、主に適用されたラベルに基づいて機密性の高いものとして識別できますが、含まれている情報にも基づいて識別できます。 ラベルだけでなくコンテンツに焦点を当てた 2 番目の DLP レイヤーを実装すると、ラベルを下げたり削除したりした後に悪意のあるユーザーが情報を流出させる能力が低下します。 この階層化された方法の詳細については、 セキュリティの機密情報の不適切な配布の防止 と 機密情報の配布の制限に関するページを参照してください。 これらの機能は、エンドポイント DLP を介してデバイスに拡張したり、Defender for Cloud Apps を介して他のクラウド アプリケーションに拡張したりすることもできます。

組織は DLP を使用して、分類解除を識別して対処できます。 たとえば、件名マーキングで "SEC=OFFICIAL:Sensitive" を識別するために機密情報の種類 (SIT) が使用されますが、メールの会話には OFFICIAL というラベルが付けられます。 会話本文では、DLP によってより高い感度のマーキングが識別されるため、会話をブロックしたり、セキュリティ チームに指示したりして、さらなるアクションを行うことができます。 秘密度ラベルではなく項目に適用されるマーキングを評価するアプローチの例については、「 DLP を介したマーク付き情報の電子メールの制御」を参照してください。

ユーザー リスク ベースのアプローチ

組織は、DLP 情報を、悪意のある動作のパターンを示す可能性のあるさまざまなユーザー信号と関連付けることで、DLP コントロールを拡張できます。 この機能は、 Microsoft Purview Insider Risk Management (IRM) を通じて利用できます。

IRM は、情報を "危険" として繰り返し流出させ、セキュリティ チームが介入できるようにするユーザーに警告します。 このツールでは、HR データ フィードを取り込み、データ流出アクティビティを、保留中の契約終了日などの HR シグナルと関連付けることができます。 この機能により、悪意のあるユーザーを特定して迅速に対処できるため、悪意のある分類解除と流出のリスクを排除できます。

これをさらに構築するために、 IRM で Adaptive Protection 機能 を有効にできます。これにより、リスクのあるユーザーのアクセスを自動的に制限し、リスク イベントの後にラベル付き情報を流出させることができます。 これにより、セキュリティ チームがアラートに対処するのを待つのではなく、コントロールをすぐに実装することで、情報をセキュリティで保護するのに役立ちます。

階層化されたアプローチによって情報が保護されている場合、アーカイブ法で指定されたレコードに対してのみ、特定のアーカイブ法コモンウェルス レコードの ラベル ロックを使用して 、厳格な再分類制限が必要になります。

再分類の変更の防止

異なるユース ケース要件に役立つ再分類を防ぐには、2 つのオプションがあります。

暗号化ベースのアプローチ

ラベルの変更を防ぐためのもう 1 つのオプションは、ラベルベースの暗号化と、ユーザーが項目のプロパティを変更する権限を制限するアクセス許可を使用することです。 共同所有者のアクセス許可では、適用されたラベルを含むプロパティの変更が許可されますが、共同作成者のアクセス許可では、アイテムの編集は許可されますが、そのプロパティは許可されません。 このような構成は、このようなアクセス許可を必要とするアクセス許可の割り当てをサポートするために、グループ構造によってサポートされる必要があります。 この構成では、 秘密度ラベル暗号化で説明されているラベル暗号化の他の側面も考慮する必要があります。

これをサポートするために必要な Azure Rights Management アクセス許可の詳細については、「 Azure Information Protection (AIP) の使用権限を構成する」を参照してください。

ラベル 'lock' アプローチ

アーカイブ法第24条および第26条は、特定のコモンウェルスレコードの種類の廃棄または変更を禁止している。 ラベルの変更はレコードのメタデータであり、そのレコードの変更を構成できます。 ラベルの変更を禁止するために、組織は Microsoft Purview レコード管理機能を利用して状態のアイテムを "ロック" する保持ラベルを実装できます。 ロックされると、項目とそれに関連付けられている秘密度ラベルを変更できないため、再分類が妨げられません。 このような方法で Microsoft 365 を構成すると、組織は、これらのコモンウェルス レコードの種類の PSPF とアーカイブ法の両方の要件を満たすことができます。

レコード ラベルを使用したアイテムの変更を防ぐ方法の詳細については、「 保持ラベルを使用してレコードを宣言する」を参照してください。

必須のラベル付け

ラベル ポリシーを使用すると、ユーザーがドキュメントとメールのラベルを選択するように要求できます。 この設定により、ユーザーは次の場合にラベルを選択するように求められます。

• 新しいアイテム (ファイルまたは電子メール) を保存します。
• ラベル付けされていないメールの送信を試みる、または
• ラベルがまだ適用されていない項目を変更します。

この設定により、すべてのアイテムに保護マーキングと、その他の関連するコントロールが適用されます。

ラベルの継承

ラベルの継承設定を使用すると、電子メールが添付ファイルの機密性を継承できます。 これは、機密性の高いアイテムが、低い秘密度ラベルが適用されたメールに添付されている場合に有効になります。 この設定は、機密性の高いアイテムが機密性の低いメールを介して不適切に開示されないようにするのに役立ちます。

すべての自動ラベル付けプロセスと同様に、自動化によって手動で適用されたラベルはオーバーライドされません。 ほとんどの特典を得るために、オーストラリア政府機関は両方のオプションを選択する必要があります。 両方のオプションを選択すると、新しく作成された項目が添付ファイルの秘密度を継承できます。 ユーザーが既にラベルを適用している状況では、2 番目のオプションが有効になり、電子メールの機密性が一致するように増やすようお勧めします。

この設定は、次の要件に合わせて調整されます。

ラベルの継承は、次のことを確実に行うのに役立ちます。

• メールのラベルに関連付けられているメール フローまたは DLP 関連のコントロール (たとえば、 機密情報の電子メール配布の防止で説明されているもの) は、メールの添付ファイルに基づいて適用されます。
• 継承されたラベルにラベルの暗号化などの高度なコントロールが含まれている場合、電子メールにはこれらのコントロールが適用されます ( 秘密度ラベルの暗号化に関するページで説明します)。

カスタム ヘルプ ページ

カスタム ヘルプ ページ オプションを使用すると、組織はラベル メニューの下部に表示される [詳細情報] オプションを使用してリンクを提供できます。 ユーザーは、秘密度ラベルを正しく適用し、マーキングまたは分類義務をユーザーに通知する方法に関する情報を提供するサイトの URL に移動します。

ラベルのヒントと共に、アイテムに最も適したラベルを決定するときに、スタッフによって "詳細情報" Web サイトが使用されます。 これは、PSPF ポリシー 8 要件 2 と一致します。これは、ユーザーが機密情報とセキュリティの機密情報を評価するのを支援します。

組織は通常、スタッフ イントラネットまたは類似の場所を使用して、分類の要件とプロセスに関連するコンテンツを公開します。 この同じサイトは、この [詳細情報] リンクの適切なターゲットである可能性があります。 このようなサイトには他にも用途があります。これについては、「 データの配置外アラート」で詳しく説明します。

ポリシーの順序付け

この記事の冒頭で説明したように、複数のラベル ポリシーを構成して、さまざまなラベル セットまたは異なるポリシー オプションをユーザーのグループに展開できます。 ラベルなど、これらのシナリオでは、ポリシーの順序付けが重要です。 複数のポリシーのスコープ内のユーザーは、さまざまなポリシーを使用して割り当てられているすべてのラベルを受け取りますが、最高の順序でポリシーからの設定のみを受け取ります。

ラベル ポリシーの例

次のラベル例は、オーストラリア政府機関の一般的なポリシー構成を示しています。 以下の保護ポリシーは、一連のラベルをユーザーのサブセットにのみ発行し、すべての組織で必要とされない方法を示すことを目的としています。

これらのポリシーは、オーストラリア政府の要件に最適な次の設定で構成できます。

ラベル ポリシーの変更

ラベルまたはラベル ポリシーの構成に対する変更の管理を担当するスタッフは、変更がユーザーに展開され、クライアント デバイスと同期されるまでに最大 24 時間かかることに注意してください。 これは、テストと技術的な変更ウィンドウに組み込む必要があります。