Taxonomie von Vertraulichkeitsbezeichnungen für die Einhaltung von PSPF durch 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. Ratschläge in diesem Artikel wurden geschrieben, um sich an die Richtlinie des Schutzsicherheitsrichtlinienframeworks (PSPF) 8: Vertrauliche und klassifizierte Informationen anzupassen.

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.

Standardkonfiguration

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.

Organisationen, die bei OFFICIAL arbeiten

Organisationen der australischen Regierung können ihre Microsoft 365-Umgebungen so konfigurieren, dass Informationen bis zu PROTECTED gespeichert werden.

Die Dokumentation zum Microsoft Infosec Registered Assessors Program (IRAP) finden Sie im Microsoft Service Trust Portal.

Viele organisationen der australischen Regierung haben die maximale Vertraulichkeitsstufe für Daten, die sie im Mandanten speichern dürfen, absichtlich eingeschränkt, was wiederum andere Anforderungen reduziert. So können z. B. Mitarbeiterfreigaben auf einer niedrigeren Ebene gehalten werden, die für die gespeicherten Daten ausreicht.

Verwenden mehrerer IMMs

Einige australische Regierungsorganisationen verwenden Klassifizierungstaxonomien, die die Anwendung von mehr als einem Information Management Marker (IMM) auf jedes Element ermöglichen. Beispiel: "OFFICIAL: Sensitive Legislative Secrecy Private 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 für DLP- und Automatische Bezeichnungsrichtlinien.

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

Organisationen, die bei PROTECTED arbeiten

Microsoft 365 wird so bewertet, dass daten bis einschließlich PROTECTED gehalten werden können.

Die Dokumentation zum Microsoft Infosec Registered Assessors Program (IRAP) finden Sie im Microsoft Service Trust Portal.

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

Organisationen, die ÜBER SECRET und höher verfügen, müssen eine lokale 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 Bezeichnungen für Informationen implementieren, die sich nicht in ihren Microsoft 365-Diensten befinden sollten. Diese Bezeichnungen werden jedoch nicht direkt von Benutzern angewendet, sondern werden verwendet, um die automatisierte Identifizierung von Elementen zu unterstützen, die nicht auf der Plattform vorhanden sein sollten. Dadurch werden Sicherheitsteams bei der Identifizierung und Behebung von Aktivitäten unterstützt.

Bezeichnungen variieren für diese Art von Verwendung je nach Organisation, sollten jedoch Folgendes umfassen:

• PROTECTED (für Organisationen, die mit den höchsten Daten arbeiten, die in ihrem Mandanten OFFICIAL sind)
• 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:

Organisationen, die erweiterte DLP für hochsensible Daten auf der Microsoft 365-Plattform benötigen, z. B. per E-Mail oder Freigabe, können zusätzliche Sicherheitsmaßnahmen mit "nicht veröffentlichten Bezeichnungen" überlappen, einschließlich:

• 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 Blockieren der Übertragung nicht ausgegebener Klassifizierungen 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 der PSPF-Richtlinie 8 ü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 Bezeichnungskonfiguration sollte mit Organisationen erfolgen, die mit dem Ziel der Ausrichtung in der Klassifizierungsterminologie interagieren, da dies eine einfachere Konfiguration ermöglicht. Wenn dies nicht erreichbar ist, bietet die Vereinbarung über Klassifizierungsäquivalenzen das nächstbeste Ergebnis. 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 missachten (nicht empfohlen, erhöht das Risiko von Datenlecks)

Die folgende Tabelle ist ein Beispiel dafür, wie nicht veröffentlichte Bezeichnungen mit automatischer Bezeichnung implementiert werden, 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 des vorherigen Ansatzes sind:

• Informationen, die mit NSW- oder QLD-Bezeichnungen gekennzeichnet sind, 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.
• NSW- oder QLD-Unterbezeichnungen sind in OFFICIAL: Vertrauliche DLP- und Defender for Cloud Apps-Richtlinien enthalten, die vor unangemessener Offenlegung über Ihre organization schützen (wie eingeführt, um eine unangemessene Verteilung von sicherheitsrelevanten Verschlusssachen zu verhindern).
• Datenidentifikationsdienste wie Content Explorer können verwendet werden, um zu identifizieren, wo sich staatliche oder generierte vertrauliche Informationen in Microsoft 365-Diensten^{befinden können 1}.

Azure Rights Management-Verschlüsselung

Azure Rights Management wird verwendet, 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.

Im Folgenden finden Sie ein Beispiel für die australische Regierung.

• 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 zusätzlichen Bezeichnungen führen zu mehr Konfigurationsanforderungen in zugeordneten Diensten, z. B. DLP, was die Komplexität erhöht.
• 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 durch verschlüsselung gebotene Vorrang haben. IMMs gelten gemäß PSPF als optional und sollten daher als niedrigere Priorität betrachtet werden. Vorbehalte wie NATIONAL CABINET sind wahrscheinlich wichtiger als IMMs und sollten nicht weggelassen werden. Dies führt wahrscheinlich zu zusätzlichen Bezeichnungsanforderungen, wenn Organisationen neuere Schutzmechanismen auf Elemente anwenden möchten.

Das Beispiel zeigt, dass die Bezeichnungsanforderungen mit der Zeit zunehmen werden. Wenn Sie mit einem großen Satz von Bezeichnungen beginnen, wird die Komplexität in Zukunft noch größer sein. 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. Indem Benutzer auf einen Kernsatz beschränkt werden, kann die Konfiguration ohne Beeinträchtigung der Benutzerfreundlichkeit oder Komplexität vergrößert werden.