次の方法で共有

PSPF に対するオーストラリア政府のコンプライアンスに対する秘密度ラベル分類

  • [アーティクル]

この記事では、データ セキュリティ分類に合わせて必要な秘密度ラベルに関するオーストラリア政府機関向けのガイダンスを提供します。 その目的は、組織が Microsoft 365 環境に展開するための適切な秘密度ラベル分類を決定するのを支援することです。 この記事のアドバイスは、保護セキュリティ ポリシー フレームワーク (PSPF) ポリシー 8: 機密情報と機密情報に合わせて記述されています。

オーストラリア政府機関は、機能を展開する前に、適切な秘密度ラベル分類を決定する必要があります。 必要なラベルは、使用する情報の種類によって組織によって異なります。

標準構成

一般的なラベル要件には、セキュリティ分類の組み合わせが含まれます。多くの場合、情報管理マーカー (IMM) や注意事項と組み合わされます。 コンプライアンスの成熟度が高い組織には、さまざまなデータ セキュリティ要件に対応するラベルも含まれる可能性があります。 たとえば、Azure Rights Management 暗号化を適用して、承認されたユーザーのみがアイテムにアクセスできるようにするラベルなどです。

次の例では、オーストラリア政府のorganizationの基本的なマーキングを示します。

マーキングまたは分類 情報管理マーカー 警告
非公式の
公式
OFFICIAL: Sensitive
保護		 個人のプライバシー
法的特権
立法の秘密		 内閣
ナショナル キャビネット

ラベルは単数形であり、1 つの項目または場所に適用できるラベルは 1 つだけです。 これら 3 つの項目の必要な組み合わせは、要件を満たすために単一のラベルに組み立てる必要があります。 たとえば、アイテムを PROTECTED として分類する必要があり、キャビネット情報も含まれている場合は、これらの要素を含む 1 つのラベルを指定する必要があります。保護されたキャビネット。

次の例では、オーストラリア政府機関の基本的なラベルを示します。 このリストでは、親ラベル (カテゴリ) とサブラベルの組み合わせを使用します。

  • 非公式の
  • 公式
  • OFFICIAL Sensitive (カテゴリ)
    • OFFICIAL Sensitive
    • 公式の機密性の高い個人のプライバシー
    • OFFICIAL 機密の法的特権
    • OFFICIAL Sensitive Legislative Secrecy
    • 機密性の高い国家キャビネット
  • PROTECTED (カテゴリ)
    • 保護
    • 保護された個人のプライバシー
    • PROTECTED 法的特権
    • PROTECTED 立法の秘密
    • 保護キャビネット

より複雑な要件を持つ政府機関には、追加のラベルが必要です。 organizationがデプロイするラベルの最大数は、技術的な制限よりも使いやすさの制約に関連しています。 ただし、organizationごとに作成できるラベルは 500 個に制限されています。

前の一覧でサブラベルを使用することは、ユーザー エクスペリエンスを向上させることを目的としていますが、ラベルの動作にもいくつかの有益な影響があります。 たとえば、ユーザーがサブラベル間で変更した場合、ラベルの変更 の理由 はトリガーされません。 これにより、ユーザーはさまざまな IM、警告、またはセキュリティ制御を適用し、ラベル カテゴリの外部に移動して適用されたセキュリティ分類を下げようとした場合にのみ正当な理由をトリガーできます。

OFFICIAL で働く組織

オーストラリア政府機関は、情報を PROTECTED まで格納するように Microsoft 365 環境を構成できます。

Microsoft Infosec Registered Assessors Program (IRAP) のドキュメントについては、 Microsoft Service Trust Portal を参照してください。

オーストラリア政府機関の多くは、テナント内に格納できるデータの最大感度レベルを意図的に制限しているため、他の要件が減ります。 たとえば、スタッフのクリアランスは、保持されるデータに対して十分な低いレベルで維持できます。

複数の IM の使用

オーストラリア政府の一部の組織では、各項目に複数の情報管理マーカー (IMM) を適用できる分類分類を利用しています。 たとえば、"OFFICIAL: Sensitive Legislative Secrecy Personal Privacy"です。 この種類の構成は実現できますが、特に次の要件を考慮する必要があります。

  • IMM は、 1 つの IMM 値を適用できることを指定するオーストラリア政府レコードキーピング メタデータ 標準 (AGRkMS) から派生します。
  • 保護セキュリティ ポリシー フレームワーク (PSPF) ポリシー 8 は、IMM が 省略可能であることを示します。

Microsoft の推奨事項は、可能な限りシンプルにしておくことです。 organizationが実際に必要とするラベルをデプロイするだけで、ユーザーが移動するラベルが少なくなり、ユーザー エクスペリエンスが向上します。 分類を小さくすると、特に DLP ポリシーと自動ラベル付けポリシー全体で、維持する構成が少なくなり、管理が容易になります。

複数の IMM 組み合わせの使用を検討している組織では、次の潜在的な合併症を考慮する必要があります。

  • 自動ラベル付けの複雑さ: 複数の IM が適用された項目は、サブジェクト マーキングを解釈する式として自動ラベル付けを使用して照合するのが難しくなります。または、 サービスベースの自動ラベル付けの推奨事項で説明されているポリシーを通じて x ヘッダーを対応させる必要があります。
  • 件名の長さ: Emailクライアントは、多くの場合、切り捨てられたり、長いメールの件名を表示することが困難になります。 1 つのメールに複数のマーキングが適用されている状況では、ユーザーは表示されないため、IMM または警告マークを認識できない可能性があります。
  • X ヘッダーの長さ: X-Protection-Marking x-headers。 マーキング戦略 で説明されている X ヘッダーは、分類メタデータを電子メールに適用するために使用されます。 電子メールに適用されるメタデータの量は、使用されている電子メール クライアントなど、いくつかの要因によって異なります。 複数の IM を電子メールに適用する組織は、許可されている x ヘッダーの長さを超える可能性があり、分類メタデータの一部が切り捨てられます。

複数のラベルが必要な場合は、要素が最も重要なものからorganizationに順序付けられていることを確認します。 以下に例を示します。

  1. セキュリティ分類
  2. 注意 (必要な場合)
  3. 最も機密性の高い IMM
  4. 機密性の低い IMM

PROTECTED で働く組織

Microsoft 365 は、PROTECTED までのデータを保持できると評価されています。

Microsoft Infosec Registered Assessors Program (IRAP) のドキュメントについては、 Microsoft Service Trust Portal を参照してください。

PROTECTED レベルを超える情報のラベル

SECRET 以上のデータを保持する組織は、オンプレミスのエンクレーブを利用する必要があります。 organizationでは、この情報がエンクレーブから離れるのを阻止するために、ネットワーク分離やその他のさまざまな手段を実装する必要があります。 SECRET マーキングを含む項目が Microsoft 365 の場所に表示された場合は、組織の IT セキュリティ アドバイザー (ITSA) がデータスピル管理を実行する必要があります。 ASD は、修復アクティビティを管理する方法に関するガイダンスを提供します。ASD データ スピル管理ガイドを参照してください

政府機関は、Microsoft 365 サービスに存在してはならない情報のラベルを実装する必要があります。 ただし、これらのラベルはユーザーによって直接適用されるのではなく、プラットフォーム上にないアイテムの自動識別を支援するために使用されます。 これにより、セキュリティ チームが識別と修復のアクティビティを行うことができます。

ラベルはこの種類の用途によって異なりますが、組織によって異なりますが、次を含める必要があります。

  • PROTECTED (テナント内で最も高いデータが OFFICIAL である組織向け)
  • 秘密
  • トップ シークレット

ISM-0272 に従って、これらのラベルはユーザーに公開しないでください。サービスがそのような情報をホストする権限を持っていない場合、ユーザーはアイテムにラベルを適用できません。

要件 詳細
ISM-0272 (2024 年 6 月) 保護マーキング ツールでは、システムが処理、保存、または通信を許可されていない保護マーキングをユーザーが選択することはできません。

注:

発行されていないラベル は、エンド ユーザーに発行されないラベルを指します。 自動ラベル付けサービスでラベルを考慮するには、 管理アカウントなどの 1 人のユーザーに発行する必要があります。

Microsoft 365 プラットフォームで機密性の高いデータの高度な DLP を必要とする組織 (メールや共有など) では、次のような追加のセキュリティ対策を "発行されていないラベル" で重ねることができます。

ラベル分類が異なる組織のラベル

ニューサウスウェールズ州やクイーンズランド州などの一部のオーストラリア州政府は、PSPF Policy 8と完全には一致しない分類分類を利用しています。 これにより、連邦政府組織が州政府から受け取る情報の機密性を解釈する方法に関するいくつかの課題が生じます。 同様の課題は、外国政府に対応する連邦政府組織にも存在します。分類が一致する可能性は高くありません。

organizationが通信する外部organizationによって適用されるデータ セキュリティ フレームワークと標準は、ラベル分類に非常に関連します。 外部マーキングは、次の方法で利用できます。

  • 外部組織によって適用されるマーキングは、テナントと同等のものに変換できます

    たとえば、"QLD Government SENSITIVE" マーキングが適用されたアイテムが連邦政府のorganizationによって受信された場合、そのマーキングはアイテムの機密性に関する有用な情報を提供します。 ユーザーは、アイテムに "OFFICIAL Sensitive" のラベルを適用して、テナントのラベルベースの保護のスコープに入れることができました。 または、自動ラベル付けを構成して、この QLD マーキングを OFFICIAL Sensitive ラベルに自動的にマップすることもできます。

  • 組織は、外部分類を維持し、情報の管理担当者である間に情報を適切に保護できます

    Microsoft Purview は、環境の秘密度ラベル付けに合わない項目を再分類するのではなく、外部分類と一致する一連の "発行されていないラベル" で構成できます。 これらのラベルは、ラベル対応クライアント内のユーザーが選択できる必要はありません。 代わりに、サービス ベースの自動ラベル付けを適用できます。 受信したアイテムにラベルが付くと、ユーザーはラベルの適用を求められません。 ラベルは、DLP やその他のコントロールのセットと連携して、含まれる情報が不適切に開示されないようにすることもできます。

ラベルの構成は組織で行う必要があります。これにより、より簡単な構成が可能になり、分類用語での配置の目標と対話します。 これが達成できない場合は、分類の等価性に関する合意によって、次に最適な結果が得られます。 避けるべき状況は、外部マーキングが完全に無視されることです。これは、データ流出などのデータ セキュリティ インシデントにつながる可能性があります。

  1. 分類の配置 (推奨、ベスト プラクティス)
  2. 分類の等価性 (オプション 1 が不可能な場合に推奨)
  3. 分類の無視 (推奨されない、データスピルのリスクを高める)

注:

政府機関が外国政府と対話する場合、 PSPFポリシー7 - 国際共有のためのセキュリティガバナンス は詳細なガイダンスを提供します。

次の表は、外部組織によって適用されるマーキングを維持するために、自動ラベル付けを使用して発行されていないラベルを実装する方法の例です。 この例では、PSPF ラベルのセットを示します。その大部分は OFFICIAL Sensitive 親ラベルのサブラベルとして表示されます。 この親ラベルの下に、NSW と QLD の同等の情報管理マーカー (IMM) と一致するラベルを含めることができます。

PSPF ラベル
(すべてのユーザーに公開)		 NSW Government
(発行されていないラベル)		 QLD Government
(発行されていないラベル)
非公式の
公式
OFFICIAL: Sensitive
- OFFICIAL: Sensitive
- 公式: 機密性の高い個人のプライバシー
- OFFICIAL: 機密性の高い法的特権
- 公式: 機密性の高い立法の秘密
- 公式: 機密性の高い国家キャビネット		 - 公式機密NSWキャビネット
- OFFICIAL Sensitive Legal
- 公式機密法執行機関
- OFFICIAL Sensitive Health の情報
- OFFICIAL Sensitive Personal
- 公式の機密性の高い NSW 政府		 -敏感

前のアプローチの利点は次のとおりです。

  • NSW または QLD ラベルでラベル付けされた情報は、OFFICIAL: 機密データのインプレース アラート (データ のアウトオブプレース アラートで詳しく説明) の恩恵を受けます。これは、不適切に開示される可能性のある場所にデータが移動されるのを防げるアラートと支援を提供します。
  • NSW または QLD サブラベルは OFFICIAL: Sensitive DLP および Defender for Cloud Apps ポリシーに含まれており、お客様のorganizationを介した不適切な開示から保護します (セキュリティの機密情報の不適切な配布の防止に関するページで紹介されています)。
  • コンテンツ エクスプローラーなどのデータ識別サービスを使用して、Microsoft 365 サービス1 全体に状態所有または生成された機密情報が存在する可能性がある場所を特定できます。

注:

1 この構成は高度であり、Microsoft Purview に精通している組織に推奨されます。

Azure Rights Management の暗号化

Azure Rights Management は、許可されたユーザーのみがラベルが適用されたコンテンツにアクセスできるようにするために使用されます。

Azure Rights Management 暗号化の設定の詳細については、メッセージ暗号化を設定する方法に関するページを参照してください。

オーストラリア政府に適用される例を次に示します。

  • 内部専用としてマークされたサブラベルを使用すると、ユーザーが内部ユーザーのみにアイテムを制限できます。
  • [受信者のみ] のサブラベルを使用して、未承認の受信者にメールを転送できないようにすることができます。
  • Project Budgerigar Only のサブラベルを使用すると、Project Budgerigar と関連情報に関する知識が必要なユーザーのサブセットのみがアイテムにアクセスできるようになります。

OFFICIAL: Sensitive ラベルの基本セットと共に、これらのラベルと関連付けられたコントロールを使用すると、トポロジの結果は次のようになります。

  • OFFICIAL: Sensitive
    • OFFICIAL: 機密性の高い内部のみ
    • OFFICIAL: 機密性の高い受信者のみ
    • 公式: 機密プロジェクトバジェリガーのみ
    • OFFICIAL: 機密性の高い (保護なし)
    • 公式: 機密性の高い個人のプライバシー
    • 公式: 機密性の高い法的特権
    • 公式: 機密性の高い立法の秘密
    • 公式: 機密性の高い国家キャビネット

前の例では、次のような明らかな課題がいくつかあります。

  • ラベルの一覧が大幅に長くなり、使いやすさに影響する可能性があります。
  • 追加のラベルを使用すると、DLP などの関連サービスの構成要件が増え、複雑さが増します。
  • 前のラベル オプションのセットでは、ユーザーが IMM、CAVEAT、または暗号化構成を適用するかどうかを決定する必要があります。これは問題になります。

このような状況では、暗号化によって提供される保護が最優先事項である必要があります。 IMM は PSPF に従って省略可能と見なされるため、優先順位は低いと見なす必要があります。 NATIONAL CABINET などの注意事項は、IMM よりも重要である可能性が高く、省略しないでください。 これにより、組織が項目に新しい保護を適用しようとする際の追加のラベル要件が発生する可能性があります。

この例では、ラベルの要件が時間の経過と同時に増加する可能性があることを示しています。 大きなラベルセットから始めると、今後さらに複雑になります。 Microsoft では、公開されたラベルをユーザーが必要とするコア セットに制限し、organizationで必要とされない可能性がある IMM と警告の組み合わせを省略することをお勧めします。 ユーザーをコア セットに制限することで、使いやすさや複雑さに影響を与えずに構成を拡張できます。