Taxonomie von Vertraulichkeitsbezeichnungen für die australische Regierung

Dieser Artikel enthält Anleitungen für Organisationen der australischen Regierung zu den erforderlichen Vertraulichkeitsbezeichnungen, um die Datensicherheitsklassifizierungen zu erfüllen. Ihr Zweck besteht darin, Organisationen bei der Entscheidung über eine geeignete Vertraulichkeitsbezeichnungtaxonomie für die Bereitstellung in ihren Microsoft 365-Umgebungen zu unterstützen. Die Anleitung in diesem Artikel entspricht pspf Release 2024 (Protective Security Policy Framework).

Organisationen der australischen Regierung müssen eine geeignete Vertraulichkeitsbezeichnungstaxonomie ermitteln, bevor sie die Funktion bereitstellen. Erforderliche Bezeichnungen variieren je nach Art der Informationen, mit denen sie arbeiten.

Standard-Konfiguration

Typische Bezeichnungsanforderungen umfassen eine Kombination aus Sicherheitsklassifizierungen, die häufig mit einem Information Management Marker (IMM) und/oder Einschränkungen kombiniert werden. Organisationen mit hoher Compliancereife enthalten wahrscheinlich auch Bezeichnungen, um verschiedene Datensicherheitsanforderungen zu erfüllen. Beispielsweise Bezeichnungen, die die Azure Rights Management-Verschlüsselung anwenden, um sicherzustellen, dass nur autorisierte Benutzer auf Elemente zugreifen können.

Im folgenden Beispiel werden grundlegende Kennzeichnungen für australische organization veranschaulicht:

Bezeichnungen sind singular, und nur eine Bezeichnung kann auf ein Element oder eine Position angewendet werden. Jede erforderliche Kombination dieser drei Elemente muss zu einem einzelnen Etikett zusammengefügt werden, um die Anforderungen zu erfüllen. Wenn ein Element beispielsweise als GESCHÜTZT klassifiziert werden muss und auch CABINET-Informationen enthält, muss ein einziges Etikett mit diesen Elementen bereitgestellt werden. GESCHÜTZTER SCHRANK.

Im folgenden Beispiel werden grundlegende Bezeichnungen für Organisationen der australischen Regierung veranschaulicht. Diese Liste verwendet eine Kombination aus übergeordneten Bezeichnungen (Kategorien) und Untergeordneten Bezeichnungen:

• INOFFIZIELL
• AMTLICH
• OFFICIAL Sensitive (Kategorie)
  • OFFICIAL Vertraulich
  • OFFICIAL Sensible Privatsphäre
  • OFFICIAL Sensible rechtliche Rechte
  • OFFICIAL Sensibles Gesetzesgeheimnis
  • OFFIZIELLEs sensibleS NATIONALES KABINETT
• PROTECTED (Kategorie)
  • GESCHÜTZT
  • GESCHÜTZTer Datenschutz
  • PROTECTED Legal Privilege
  • GESCHÜTZTEs Gesetzesgeheimnis
  • GESCHÜTZTER SCHRANK

Behördenorganisationen mit komplexeren Anforderungen benötigen zusätzliche Bezeichnungen. Die maximale Anzahl von Bezeichnungen, die ein organization bereitstellen möchte, ist für Benutzerfreundlichkeitseinschränkungen relevanter als technische Einschränkungen. Es gibt jedoch ein Limit von 500 Bezeichnungen, die pro organization erstellt werden können.

Die Verwendung von Untergeordneten Bezeichnungen in der vorherigen Liste soll die Benutzererfahrung verbessern, hat aber auch einige positive Auswirkungen auf das Bezeichnen des Verhaltens. Beispielsweise wird die Bezeichnungsänderungsbegründung nicht ausgelöst, wenn ein Benutzer zwischen untergeordneten Bezeichnungen wechselt. Dadurch können Benutzer unterschiedliche IMMs, Einschränkungen oder Sicherheitskontrollen anwenden und nur dann eine Begründung auslösen, wenn sie versuchen, die angewendete Sicherheitsklassifizierung durch Verschieben außerhalb einer Bezeichnungskategorie zu verringern.

Überlegungen zur PROTECTED-Bezeichnung

Organisationen der australischen Regierung können ihre Microsoft 365-Umgebungen so konfigurieren, dass Informationen bis zur PROTECTED-Ebene gespeichert werden. Die Fähigkeit von Microsoft, Informationen auf dieser Ebene zu speichern, wird unabhängig im Rahmen des Infosec Registered Assessors Program (IRAP) bewertet. Die Microsoft 365 Cloud Security Assessment ist über das Microsoft Service Trust Portal öffentlich verfügbar.

Das Australian Signals Directorate (ASD) verwaltet das Information Security Manual (ISM), ein Framework für das Cybersicherheitsrisikomanagement, das dazu beiträgt, Informationstechnologiesysteme vor Cyberbedrohungen zu schützen. Dieses Handbuch enthält zahlreiche Anforderungen sowie Anwendbarkeitsmarkierungen, die die Abstandsstufen festlegen, für die Die Kontrollen gelten.

ASD verwaltet die Blueprint for Secure Cloud von ASD, die eine hervorragende Ressource für die sichere Konfiguration von Microsoft 365-Umgebungen ist. Die Anleitung in dieser Blaupause entspricht den Anleitungen in diesem Microsoft Purview-Leitfaden und sollte befolgt werden, um das Risiko von Datensicherheitsvorfällen zu verringern.

Rechenschaftsfähiges Material

Rechenschaftsfähiges Material sind Informationen, die die strengste Kontrolle über den Zugriff und die Bewegung erfordern. Organisationen, die mit verfügbarem Material arbeiten oder dieses erhalten, sollten erwägen, eine oder mehrere Vertraulichkeitsbezeichnungen zu erstellen, um sie an den Informationen anzupassen. Diese Vertraulichkeitsbezeichnung kann in Verbindung mit Data Loss Prevention (DLP), Verschlüsselung und anderen bezeichnungsbasierten Steuerelementen verwendet werden, um die eingeschlossenen Informationen zu schützen. Vertraulichkeitsbezeichnungen für verwertbares Material können als Unterbezeichnungen der PROTECTED-Bezeichnung konfiguriert werden.

Verwenden mehrerer IMMs

Einige organisationen der australischen Regierung verwenden Klassifizierungstaxonomien, die die Anwendung von mehr als einem Information Management Marker (IMM) auf jedes Element ermöglichen. Beispiel: "OFFICIAL: Sensitive Legislative Secrecy Personal Privacy". Obwohl diese Art von Konfiguration erreicht werden kann, sollten Anforderungen berücksichtigt werden, insbesondere:

• IMMs werden vom Australian Government Recordkeeping Metadata Standard (AGRkMS) abgeleitet, in dem angegeben wird, dass ein einzelner IMM-Wert angewendet werden kann.
• PsPF (Protective Security Policy Framework) Richtlinie 8 gibt an, dass IMMs optional sind.

Microsoft empfiehlt, die Dinge so einfach wie möglich zu halten. Nur die Bereitstellung von Bezeichnungen, die Ihr organization tatsächlich benötigt, verbessert die Benutzerfreundlichkeit, da benutzer weniger Bezeichnungen zum Navigieren haben. Eine kleinere Taxonomie erleichtert auch die Verwaltung, da weniger Konfigurationen verwaltet werden müssen, insbesondere bei Richtlinien zum Schutz vor Datenverlust (Data Loss Protection, DLP) und automatischen Bezeichnungen.

Organisationen, die die Verwendung mehrerer IMM-Kombinationen in Betracht ziehen, sollten die folgenden möglichen Komplikationen berücksichtigen:

• Komplikationen bei der automatischen Bezeichnung: Elemente mit mehreren angewendeten IMMs sind schwieriger über die automatische Bezeichnung abzugleichen, da Ausdrücke zum Interpretieren von Betreffmarkierungen oder X-Headern in der Lage sein müssen, sie über die richtlinien zu berücksichtigen, die in empfehlungen für die dienstbasierte automatische Bezeichnung erläutert werden.
• Betrefflänge: Email Clients werden häufig abgeschnitten oder erschweren das Anzeigen langer E-Mail-Betreffs. In Situationen, in denen mehrere Markierungen auf eine einzelne E-Mail angewendet wurden, sind Benutzern möglicherweise IMM- oder Vorbehaltsmarkierungen nicht bekannt, da sie nicht sichtbar sind.
• Länge von X-Headern: X-Protective-Marking x-Header, die in Markierungsstrategien erläutert werden, werden verwendet, um Klassifizierungsmetadaten auf E-Mails anzuwenden. Die Menge der Metadaten, die auf eine E-Mail angewendet werden, hängt von mehreren Faktoren ab, einschließlich des verwendeten E-Mail-Clients. Organisationen, die mehrere IMMs auf E-Mails anwenden, überschreiten wahrscheinlich die zulässige X-Headerlänge, was dazu führt, dass einige Klassifizierungsmetadaten abgeschnitten werden.

Wenn mehrere Bezeichnungen erforderlich sind, stellen Sie sicher, dass Die Elemente von den am wenigsten wichtigen bis zu ihren organization sortiert werden. Zum Beispiel:

1. Sicherheitsklassifizierung
2. Vorbehalt (falls erforderlich)
3. Empfindlichste IMM
4. Weniger sensible IMM

Bezeichnungen für Informationen, die über die PROTECTED-Ebene hinausgehen

Organisationen, die über SECRET und höherer Daten verfügen, müssen eine Secure Enclave verwenden. Die organization müssen die Netzwerktrennung und eine Vielzahl anderer Maßnahmen implementieren, um zu verhindern, dass diese Informationen die Enclave verlassen. Wenn an einem Microsoft 365-Standort ein Element mit der Kennzeichnung SECRET angezeigt wird, muss der IT-Sicherheitsratgeber (ITSA) der Organisation die Verwaltung von Datenlecks durchführen. ASD bietet Anleitungen zum Verwalten von Wartungsaktivitäten. Weitere Informationen finden Sie im Leitfaden zur Verwaltung von ASD-Datenlecks.

Behörden sollten die Implementierung von Bezeichnungen für Informationen in Betracht ziehen, die sich nicht in ihren Microsoft 365-Diensten befinden sollten. Diese Bezeichnungen werden nicht direkt für Benutzer veröffentlicht, sondern stattdessen verwendet, um die automatisierte Identifizierung von Elementen zu unterstützen, die nicht auf der Plattform vorhanden sein sollten. Eine solche Konfiguration unterstützt Sicherheitsteams bei der Identifizierung und Behebung von Aktivitäten.

Bezeichnungen für diese Art von Verwendung variieren von Organisation zu Organisation, können jedoch Folgendes umfassen:

• PROTECTED (für Organisationen, die bei OFFICIAL arbeiten: Vertraulich oder niedriger)
• GEHEIM
• STRENG GEHEIM

Gemäß ISM-0272 sollten diese Bezeichnungen nicht für Benutzer veröffentlicht werden. Wenn der Dienst nicht zum Hosten solcher Informationen autorisiert ist, sollten Benutzer die Bezeichnungen nicht auf Elemente anwenden können:

Um Datenlecks zu verhindern, sollten Organisationen erwägen, die folgenden Steuerelemente über diese nicht veröffentlichten Bezeichnungen anzuwenden:

• Richtlinien für automatische Bezeichnungen, um die Elemente über eingehende E-Mail-X-Header oder Betreffmarkierungen zu identifizieren (ähnlich wie bei der Bezeichnung von E-Mails während des Transports).
• Richtlinien für die automatische Bezeichnung, um ruhende Elemente an SharePoint-, OneDrive- und Teams-Speicherorten zu identifizieren (ähnlich wie beim Bezeichnen vorhandener ruhender Elemente).
• DLP-Richtlinien, um die Freigabe oder E-Mail-Verteilung von identifizierten Inhalten zu blockieren (ähnlich wie bei der Verhinderung einer unangemessenen Verteilung von sicherheitsrelevanten Informationen).
• DLP-Richtlinien zum Blockieren des anfänglichen Empfangs und/oder einer weiteren Verteilung des Inhalts (wie unter Verhindern von Datenlecks erläutert).
• Berichterstellungsfunktionen, um zu identifizieren, wann hochsensible Elemente an Speicherorte mit niedrigerer Vertraulichkeit verschoben werden (z. B. in "Out-of-Place-Warnungen für Daten").
• Defender for Cloud Apps Funktionen, um das Hochladen identifizierter Elemente in Nicht-Microsoft-Clouddienste zu verhindern (wie unter Verhindern des Hochladens von sicherheitsgeklassierten Elementen an nicht verwaltete Speicherorte eingeführt).

Bezeichnungen für Organisationen mit unterschiedlichen Bezeichnungstaxonomien

Einige australische Staatsregierungen, z. B. New South Wales und Queensland, nutzen Klassifizierungstaxonomien, die nicht vollständig mit PSPF übereinstimmen. Dies kann einige Herausforderungen für die Interpretation der Vertraulichkeit von Informationen darstellen, die sie von staatlichen Regierungen erhalten. Ähnliche Herausforderungen bestehen für Organisationen der Bundesregierung, die ausländischen Regierungen entsprechen, da Klassifizierungen wahrscheinlich nicht übereinstimmen.

Die Datensicherheitsframeworks und -standards, die von externen organization angewendet werden, mit denen Ihr organization kommuniziert, sind für Ihre Bezeichnungstaxonomie von hoher Relevanz. Externe Markierungen können mit den folgenden Methoden verwendet werden:

• Von externen Organisationen angewendete Markierungen können in eine Mandantenäquivalente konvertiert werden.

  Wenn beispielsweise ein Element mit der Kennzeichnung "QLD Government SENSITIVE" von einem organization der Bundesregierung empfangen wird, liefert die Kennzeichnung nützliche Informationen zur Vertraulichkeit des Elements. Ein Benutzer kann die Bezeichnung "OFFICIAL Sensitive" auf das Element anwenden, um es in den Bereich der bezeichnungsbasierten Schutzmaßnahmen des Mandanten zu bringen. Alternativ kann die automatische Bezeichnung so konfiguriert werden, dass diese QLD-Kennzeichnung automatisch der Bezeichnung OFFICIAL Sensitive zugeordnet wird.

• Organisationen können externe Klassifizierungen und angemessenen Schutz für Informationen verwalten, während sie verwahren.

  Anstatt Elemente neu zu klassifizieren, die nicht mit der Vertraulichkeitsbezeichnung Ihrer Umgebung übereinstimmen, könnte Microsoft Purview mit einer Reihe von "nicht veröffentlichten Bezeichnungen" konfiguriert werden, die an externen Klassifizierungen ausgerichtet sind. Diese Bezeichnungen müssen nicht von Benutzern in bezeichnungsfähigen Clients ausgewählt werden können. Stattdessen können sie dienstbasierte automatische Bezeichnungen anwenden. Sobald empfangene Elemente bezeichnet wurden, werden Benutzer nicht aufgefordert, eine Bezeichnung auf sie anzuwenden. Die Bezeichnungen können auch an einer Reihe von DLP und anderen Steuerelementen ausgerichtet werden, um sicherzustellen, dass die enthaltenen Informationen nicht unangemessen offengelegt werden.

Die Ausrichtung von Bezeichnungsbenennungs- und Kennzeichnungsmethoden zwischen ausgerichteten Organisationen bietet die besten Ergebnisse, da sie einfachere Konfigurationen ermöglicht. Wenn eine Ausrichtung nicht möglich ist, bietet die Vereinbarung über Klassifizierungsäquivalenzen die nächstbeste Alternative. Die Situation, die vermieden werden sollte, ist, dass externe Markierungen vollständig ignoriert werden, da dies wahrscheinlich zu Datensicherheitsvorfällen wie einem Datenleck führen wird.

1. Klassifizierungsausrichtung (empfohlen, bewährte Methode)
2. Klassifizierungsäquivalenz (empfohlen, wenn Option 1 nicht möglich ist)
3. Klassifizierung ignoriert (nicht empfohlen, erhöht das Risiko von Datenlecks)

Ansatz für die Klassifizierungsausrichtung

Wenn ein organization entscheiden würde, eine externe Klassifizierung in eine Mandantenäquivalente zu konvertieren, müssten sie Folgendes ausführen:

1. Bestimmen Sie, wie die Klassifizierung identifiziert werden soll. Beispielsweise über E-Mail-Betreffmarkierung, E-Mail-X-Header, Schlüsselwörter oder Dokumenteigenschaft.
2. Konfigurieren Sie die dienstbasierte automatische Bezeichnung, um die relevante interne Vertraulichkeitsbezeichnung anzuwenden, wenn Elemente identifiziert werden, wie unter Empfehlungen zur dienstbasierten automatischen Bezeichnung untersucht.

Der Vorteil dieses Ansatzes ist, dass alle Datensicherheitskontrollen, die zum Schutz interner Sicherheitsklassifizierungen konfiguriert wurden, auch für die ausrichtenden externen Informationen gelten.

Ansatz für Klassifizierungsäquivalenz

Wenn ein organization beschließt, eine externe Klassifizierung innerhalb seiner Umgebung beizubehalten, muss er Folgendes ausführen:

1. Konfigurieren Sie eine Vertraulichkeitsbezeichnung für die externe Klassifizierung.
2. Veröffentlichen Sie die Bezeichnung in einem Nichtbenutzerkonto, um sie in den Bereich des Diensts für automatische Bezeichnungen zu bringen.
3. Bestimmen Sie, wie die externe Klassifizierung für Elemente identifiziert werden soll. Beispielsweise über E-Mail-Betreffmarkierung, E-Mail-X-Header, Schlüsselwörter oder Dokumenteigenschaft.
4. Konfigurieren Sie die dienstbasierte automatische Bezeichnung, um die ausgeblendete Vertraulichkeitsbezeichnung anzuwenden, wenn Elemente identifiziert werden, wie unter Empfehlungen zur dienstbasierten automatischen Bezeichnung untersucht.
5. Konfigurieren Sie eine Reihe von DLP-Richtlinien, um Elemente mit der angewendeten Vertraulichkeitsbezeichnung zu schützen, wie unter Verhindern einer unangemessenen Verteilung von sicherheitsrelevanten Informationen beschrieben.

Die folgende Tabelle ist ein Beispiel dafür, wie nicht veröffentlichte Bezeichnungen mit automatischer Bezeichnung implementiert werden können, um markierungen beizubehalten, die von externen Organisationen angewendet werden. Das Beispiel zeigt eine Reihe von PSPF-Bezeichnungen, von denen der Großteil als Unterbezeichnungen der übergeordneten Bezeichnung OFFICIAL Sensitive angezeigt wird. Unter dieser übergeordneten Bezeichnung kann der Benutzer Bezeichnungen einschließen, die mit NSW- und QLD-äquivalenten Information Management Markern (IMMs) übereinstimmen:

Die Vorteile dieses Ansatzes sind die folgenden:

• Informationen, die in einem Microsoft 365-Mandanten der Bundesregierung landen, der mit NSW- oder QLD-Bezeichnungen gekennzeichnet wurde, profitieren von OFFICIAL: Out-of-Place-Warnungen für sensible Daten (weiter erläutert in Out-of-Place-Warnungen für Daten), die warnungen und verhindern, dass Daten an Speicherorte verschoben werden, an denen sie unangemessen offengelegt werden könnten.
• Datenidentifikationsdienste wie Content Explorer können verwendet werden, um zu identifizieren, wo sich staatseigene oder generierte vertrauliche Informationen in Microsoft 365-Diensten befinden könnten.

Azure Rights Management-Verschlüsselung

Azure Rights Management kann verwendet werden, um sicherzustellen, dass nur autorisierte Benutzer auf Inhalte mit einer angewendeten Bezeichnung zugreifen können. Informationen zum Einrichten der Azure Rights Management-Verschlüsselung finden Sie unter Einrichten der Nachrichtenverschlüsselung.

Azure Rights Management wird in der Regel über Vertraulichkeitsbezeichnungen angewendet. Eine Bezeichnung oder eine Gruppe von Bezeichnungen kann so konfiguriert werden, dass bezeichnungen, wenn sie auf ein Element angewendet werden, mit einem Satz von Berechtigungen verschlüsselt werden, die steuern, wer auf das Element zugreifen kann und wie es verwendet werden kann.

Die folgenden Beispiele veranschaulichen, wie die Taxonomie einer Organisation erweitert werden kann, um Benutzern Verschlüsselungsoptionen zur Verfügung zu stellen:

• Eine als Nur intern gekennzeichnete Unterbezeichnung kann benutzern das Beschränken von Elementen auf interne Benutzer ermöglichen.
• Eine Unterbezeichnung von Nur Empfänger kann verwendet werden, um sicherzustellen, dass E-Mails nicht an nicht autorisierte Empfänger weitergeleitet werden können.
• Eine Unterbezeichnung von Project Budgerigar Only könnte verwendet werden, um sicherzustellen, dass nur die Teilmenge der Benutzer, die für Project Budgerigar und zugehörige Informationen wissen müssen , auf Elemente zugreifen kann.

Mit diesen Bezeichnungen und zugeordneten Steuerelementen zusammen mit dem grundlegenden Satz von OFFICIAL: Sensible Bezeichnungen lautet das Topologieergebnis:

• OFFICIAL: Vertraulich
  • OFFICIAL: Nur intern vertraulich
  • OFFICIAL: Nur sensible Empfänger
  • OFFICIAL: Nur sensibles Projekt Wellensittiche
  • OFFICIAL: Vertraulich (kein Schutz)
  • OFFICIAL: Sensible Privatsphäre
  • OFFICIAL: Sensible rechtliche Rechte
  • OFFICIAL: Sensibles Gesetzesgeheimnis
  • AMTLICH: SensibleS NATIONALES KABINETT

Im vorherigen Beispiel gibt es einige offensichtliche Herausforderungen, darunter:

• Die Liste der Bezeichnungen ist viel länger, was sich auf die Benutzerfreundlichkeit auswirken könnte.
• Die vorherigen Bezeichnungsoptionen erfordern, dass Benutzer Entscheidungen darüber treffen müssen, ob eine IMM-, CAVEAT- oder Verschlüsselungskonfiguration angewendet werden soll, was ein Problem darstellt.

In solchen Situationen sollte der Schutz von Daten als vorrangig angesehen werden. IMMs gelten als optional und sollten nicht auf Kosten von Datensicherheitsmaßnahmen wie Verschlüsselung einbezogen werden. Wenn die Bezeichnungstaxonomie gekürzt werden muss, sollten Sie zuerst IMMs löschen oder Bezeichnungsrichtlinien ändern, um sicherzustellen, dass sie nur für Benutzer veröffentlicht werden, die sie benötigen. Vorbehalte wie CABINET und NATIONAL CABINET sind wahrscheinlich wichtiger als IMMs und sollten nicht weggelassen werden.

Microsoft empfiehlt, veröffentlichte Bezeichnungen auf einen Kernsatz zu beschränken, der von Benutzern benötigt wird, und alle IMM- und Caveat-Kombinationen wegzulassen, die für Ihre organization wahrscheinlich nicht erforderlich sind. Erwägen Sie die Berichterstellung über Tools wie Content Explorer, um nicht verwendete Bezeichnungen zu identifizieren und sie aus Ihrem veröffentlichten Satz zu entfernen, um platz für die Konfiguration zu ermöglichen, ohne die Benutzerfreundlichkeit oder Komplexität zu beeinträchtigen.