Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält Anleitungen für australische Regierungsorganisationen zur Verwendung von Microsoft Purview für die Kennzeichnung von E-Mails. Der Zweck besteht darin, zu zeigen, dass Microsoft Purview in Microsoft Exchange integriert werden kann, um Schutzkennzeichnungen in Übereinstimmung mit PSPF, dem Schutzrichtlinien-Framework (PSPF), einschließlich der australischen Regierung Email Protective Marking Standard aufzuweisen. Dieser Leitfaden soll australischen Behörden dabei helfen, Informationen zu schützen und ihre Informationssicherheitsreife zu erhöhen.
Pspf Abschnitt 9 Anforderung 61 besagt, dass Informationen eindeutig mit geeigneten Schutzkennzeichnungen gekennzeichnet werden müssen:
| Anforderung | Detail |
|---|---|
| PSPF Abschnitt 9: Klassifizierungen & Einschränkungen – Anforderung 61 | Sicherheitsreklassifizierungsinformationen werden eindeutig mit der geltenden Sicherheitsklassifizierung und gegebenenfalls mit Sicherheitshinweisen gekennzeichnet, indem textbasierte Kennzeichnungen verwendet werden, sofern dies aus betrieblichen Gründen nicht praktikabel ist. |
Schutzkennzeichnungen können auf vielfältige Weise angewendet werden, z. B. über Kennzeichnungen von Inhalten, die unter Vertraulichkeitsbezeichnungen behandelt werden. Es ist jedoch möglich, dass Empfänger textbasierte Schutzmarkierungen in ihren Antwort-E-Mails ändern, z. B. durch Ändern der Markierung, die auf eine E-Mail-Unterhaltung angewendet wird. Die australische Regierung Email Protective Marking Standard bietet zusätzliche Anleitungen zum Markieren von E-Mails, einschließlich der Kennzeichnungssyntax, die auf E-Mail-Betreff oder E-Mail-Metadaten in Form von X-Headern angewendet werden kann.
Die folgende Grafik veranschaulicht die verschiedenen Kennzeichnungsmethoden, die in diesem Artikel verfügbar und erläutert werden:
X-Protective-Marking x-Header
Standardmäßig wird eine Vertraulichkeitsbezeichnung, die innerhalb einer Umgebung konfiguriert ist und für die ein Satz von Steuerelementen konfiguriert ist, um zugeordnete Informationen zu schützen, nicht automatisch in externen Umgebungen angewendet. Für Elemente, die an eine externe organization gesendet werden, wurden Metadaten und visuelle Markierungen angewendet. Es liegt dann an der empfangenden organization sicherzustellen, dass die enthaltenen Informationen angemessen geschützt sind.
Um sicherzustellen, dass Informationen von empfangenden Organisationen angemessen behandelt werden, ist es wichtig, Elemente mit Indikatoren zu markieren, um die Interpretation der Sicherheitsklassifizierung zu unterstützen. Nach der Interpretation wird das Element in den Bereich der zweiten Sicherheitskontrollen der Organisation gebracht. Die Übersetzung von Klassifizierungen zwischen Organisationen wird für E-Mails mithilfe von Microsoft Purview Data Loss Prevention (DLP) und dienstbasierter automatischer Bezeichnung erreicht. DLP stempelt E-Mails mit Markierungen, die von der dienstbasierten automatischen Bezeichnung (oder einem gleichwertigen Dienst) am empfangenden Ende interpretiert werden:
Internetnachrichtenheadererweiterungen oder X-Header bieten eine Markierungsmethode, bei der es weniger um die Sichtbarkeit des Benutzers geht, als um sicherzustellen, dass Systeme auf E-Mails angewendete Markierungen interpretieren können. Aus sicht der E-Mail-Plattformen sind X-Header die zuverlässigste Informationsquelle zur Klassifizierung eines Elements, da sie von Benutzern nicht einfach bearbeitet werden können.
Um sicherzustellen, dass E-Mail-basierte Informationen angemessen kontrolliert und geschützt werden, während sie zwischen Behördenorganisationen verschoben werden, wird der X-Header "PSPF x-protective-Marking" verwendet. Dieser X-Header wird von E-Mail-Plattformen für alle E-Mails gelesen und interpretiert, die in eine Government-Umgebung gelangen, und verwendet, um Kontrollen anzuwenden, die der Vertraulichkeit der enthaltenen Informationen entsprechen.
Wichtig
Die konsistente Verwendung von x-Headern ist der Schlüssel für den Erfolg dieses Prozesses, da empfangende Organisationen X-Header verwenden, um Markierungen zu interpretieren und relevante Steuerelemente anzuwenden.
Um sicherzustellen, dass X-Header zwischen Organisationen konsistent sind, definiert die australische Regierung Email Protective Marking Standard die folgende x-Header-Syntax:
| Anforderung | Detail |
|---|---|
| Schutzkennzeichnungs-Standard der australischen Regierung Email | X-Protective-Marking:VER=[version], NS=gov.au, SEC=[SecurityClassification], CAVEAT=[CaveatType]:[CaveatValue], EXPIRES=[genDate]\ | [event], DOWNTO=[SecurityClassification], ACCESS=[InformationManagementMarker], NOTE=[comment], ORIGIN=[authorEmail] |
Häufig konfigurierte Komponenten sind:
-
VER, der die Version des Standards auflistet, für den das System konfiguriert ist (derzeit v2018.6). -
NS, wobei es sich um die Domänen handelt, für die die Markierung relevant ist. -
SECentspricht entweder einer Kennzeichnung oder Klassifizierung (INOFFIZELL, OFFICIAL, OFFICIAL Sensitive oder PROTECTED). -
CAVEATwird aufgefüllt, wenn ein Vorbehalt wie CABINET auf den Inhalt angewendet wird. -
ACCESSwird aufgefüllt, wenn ein Information Management Marker (IMM) auf den Inhalt angewendet wird.
Hinweis
Die obige Konfiguration unterscheidet sich wahrscheinlich für Staatliche Behördenorganisationen, die diesen Leitfaden verwenden. Das Victorian Protective Data Security Framework (VPDSF) besagt beispielsweise, dass eine Domäne von vic.gov.au im NS-Wert für victorianische Behörden verwendet werden sollte.
Ursprungsheader
Die australische Regierung Email schützende Kennzeichnung Standard besagt, dass das ORIGIN Feld die E-Mail-Adresse des Autors erfasst, sodass die Person, die die E-Mail-Nachricht ursprünglich klassifiziert hat, immer bekannt ist. Dies ist nicht unbedingt dasselbe wie in der RFC5322 aus dem Feld."
Wichtig
Ein häufiger Fehler besteht darin, das ORIGIN Feld über eine Nachrichtenflussregel zu konfigurieren, die die Adresse des Absenders in das Ursprungsfeld der ausgehenden E-Mail stempelt. Diese Konfiguration führt dazu, dass sich das Feld jedes Mal ändert, wenn eine Antwort- oder Weiterleitungsaktivität auftritt. Diese Konfiguration erfüllt die PSPF-Anforderung nicht, da sich das Feld nach dem ORIGIN Festlegen nicht ändern sollte.
Microsoft Purview bietet derzeit keine Methode zum Anwenden und Verwalten eines X-Headerwerts, der für einen einzelnen Benutzer spezifisch ist. Es sind jedoch alternative Risikominderungen verfügbar.
Das wichtigste Element des ORIGIN Felds ist die Ursprungsentität. PSPF definiert Ursprung als "die Entität, die die Informationen ursprünglich generiert oder von außerhalb der australischen Regierung empfangen hat". Zum Erfassen von Informationen zur Ursprungsentität im ORIGIN Feld könnten wir eine generische E-Mail-Adresse verwenden. Beispiel: info@entity.gov.au. Diese E-Mail-Adresse wird im Ursprungsfeld aller E-Mails gestempelt, die von einem organization generiert werden, sodass die Absicht der Anforderungen erfüllt werden kann, da Informationen auf die generierende Entität zurückverfolgt werden können.
Wenn weitere Informationen zu den Besonderheiten einer E-Mail erforderlich sind, z. B. zum ursprünglichen Absender, Empfänger oder zur Person, die eine E-Mail weitergeleitet hat, können Dienste wie Nachrichtenablaufverfolgung in Exchange Online und eDiscovery-Inhaltssuche verwendet werden, um solche Informationen anzuzeigen.
Risiko des Entfernens von X-Headern
Wenn Organisationen der australischen Regierung mit E-Mail-Plattformen und -Clients außerhalb von Unternehmen arbeiten, können externe E-Mail-Systeme X-Header aus E-Mail-Antworten entfernen. Unternehmens-E-Mail-Plattformen wie Exchange Online und Clients wie Outlook stellen sicher, dass wichtige E-Mail-Metadaten, einschließlich X-Headern, verwaltet werden, wenn Benutzer auf E-Mails antworten. Andere Clients, einschließlich anonymer E-Mail-Plattformen und nativer E-Mail-Clients auf mobilen Geräten, entfernen wahrscheinlich alle E-Mail-Metadaten, die sie nicht verstehen. Dies wirkt sich sowohl auf die E-Mail-Sicherheit als auch auf die Benutzerfreundlichkeit aus, sofern sie nicht in den Entwurf einfräglich ist.
Eine E-Mail, die von einer typischen australischen organization an einen Nicht-Microsoft 365-Benutzer gesendet wird, enthält X-Schutzmarkierungsheader und andere Microsoft-spezifische Bezeichnungsmetadaten (z. B. msip_labels Header). Diese Metadaten können verwendet werden, um sicherzustellen, dass jede E-Mail in einer Unterhaltung die Bezeichnung erbt, die auf die vorherige Nachricht angewendet wurde. Wenn ein Nicht-Microsoft 365-Benutzer auf eine markierte E-Mail antwortet, kann seine Antwort nur auf wichtige E-Mail-Metadaten zurückgesendet werden. Dies führt dazu, dass die Antwort-E-Mail, wenn sie von der E-Mail-Plattform Ihres organization empfangen wird, nicht gekennzeichnet wird. Der Benutzer muss dann eine neue Bezeichnung auswählen und auf seine Antwort anwenden, die manuell an der Markierung des ursprünglichen Elements ausgerichtet ist. Dieser Ansatz birgt das Risiko, dass ein Benutzer versehentlich die falsche Klassifizierung auswählt, sodass Informationen außerhalb des Bereichs der Sicherheitskontrollen Ihrer Organisation fallen.
Obwohl X-Header die ideale Methode zum Markieren von E-Mails sind, da sie von Empfängern nicht einfach geändert werden können, empfiehlt Microsoft, dass mehrere Markierungsmethoden konfiguriert und in Richtlinien für die automatische Bezeichnung für die australische Regierung verwendet werden:
- X-Protective-Marking x-Header (primäre Methode)
- Fachbasierte Kennzeichnung (Hilfsmethode 1)
- Beschriftung visueller Markierungen, die von sensiblen Informationstypen (SENSITIVE Information Types, SITs) interpretiert werden sollen (Hilfsmethode 2)
Beim Anwenden mehrerer Markierungs- und automatischer Bezeichnungsansätze wird die höchste Vertraulichkeitsbezeichnung erkannt, die in einem Element erkannt wurde, das auf das Element angewendet und/oder dem Benutzer empfohlen wird. Dies verringert die Wahrscheinlichkeit, dass Inhalte aufgrund von Empfängermanipulation oder X-Header-Stripping falsch bezeichnet werden.
Ansätze zur automatischen Bezeichnung zur Minimierung von Risiken im Zusammenhang mit Header-Stripping werden unter Empfehlungen zur clientbasierten automatischen Bezeichnung für australische Behörden und dienstbasierte automatische Bezeichnungen für australische Regierungsbehörden weiter erläutert.
Anwenden von X-Protective-Marking-Headern über DLP-Richtlinie
Eine DLP-Richtlinie kann verwendet werden, um X-Schutzmarkierungsheader auf E-Mails anzuwenden.
Neue DLP-Richtlinien können im Microsoft Purview-Portal erstellt werden. Solche Richtlinien sollten aus einer benutzerdefinierten Richtlinienvorlage erstellt werden und sollten nur für den Exchange-Dienst gelten. Wenn Sie nur diesen Dienst auswählen, können alle austauschspezifischen Bedingungen sichtbar sein. Wenn andere Dienste ausgewählt sind, werden in der Liste nur Bedingungen angezeigt, die allen ausgewählten Diensten gemeinsam sind.
Die Richtlinie sollte eine Regel für jede Vertraulichkeitsbezeichnung enthalten, die für Benutzer veröffentlicht wird.
Wichtig
Anstelle mehrerer DLP-Richtlinien wird eine einzelne DLP-Richtlinie mit mehreren Regeln empfohlen, die X-Header- und Betreffmarkierungen anwenden. Eine Richtlinie, die diese Aktionen für alle erforderlichen Bezeichnungen erreicht, wurde in die DLP-Beispielrichtlinie aufgenommen, die x-Header und Betreffmarkierungen anwendet.
Jede Regel sollte basierend auf ihrem Zweck benannt werden. Beispiel: Der Regelname EXO - Apply UNOFFICIAL x-Header. Bei Regeln, die Kombinationen von Markierungen enthalten, können Bezeichnungsnamen die für DLP-Regelnamen zulässige Länge überschreiten. Aus diesem Grund ist eine Abschneidung von Regelnamen erforderlich. In Beispiel-DLP-Richtlinien zum Anwenden von X-Headern und Betreffmarkierungen wurden Einschränkungen und IMMs gekürzt, um dies zu berücksichtigen.
Regeln sollten eine Bedingung aufweisen, dass inhaltvertraulichkeitsbezeichnungenthält> und dann die für die Regel relevante Bezeichnung ausgewählt wird.
Es sollten Optionen zum Auswerten des Prädikats für Nachrichten oder Anlagen ausgewählt werden, da dadurch sichergestellt wird, dass die auf E-Mails angewendeten X-Header für Anlagen mit höherer Vertraulichkeit sorgen, wodurch die in der Bezeichnungsvererbung erläuterten Funktionen erweitert werden.
Administratoren sollten darauf achten, dass x-schützende X-Header andere Daten enthalten können, z. B. Werte für EXPIRES oder DOWNTO. Das Vorhandensein dieser Informationen ist für viele Organisationen aufgrund ihrer begrenzten Verwendung unwahrscheinlich, aber wenn die Daten vorhanden sind, sollten sie beibehalten werden. Um dies zu erreichen, erstellen Sie eine Bedingungsgruppe mithilfe des NOT-Operanden . Dadurch wird sichergestellt, dass, wenn ein Header bereits für ein Element vorhanden ist, nicht überschrieben wird:
Regelaktionen werden zum Festlegen von Headern konfiguriert. Der Headerwert sollte dann am X-Schutzmarkierungswert für die angewendete Bezeichnung ausgerichtet werden.
Tipp
Beim Kopieren von X-Headerwerten aus einer formatierten Datei wie einem Word Dokument könnten einige Sonderzeichen, z. B. Kommas oder Bindestriche, durch Office-Formatierung ersetzt werden. Die Microsoft Purview-Schnittstelle stellt die Konfigurationshygiene durch Formularvalidierung sicher. Dies kann dazu führen, dass Formulare bestimmte eingefügte Textwerte nicht akzeptieren. Wenn Probleme auftreten, geben Sie die Sonderzeichen mithilfe der Tastatur neu ein, anstatt von eingefügten Werten abhängig zu sein.
Testen von X-Protective-Marking-Headern
Die in diesem Artikel beschriebenen DLP-Richtlinien sollten getestet werden, um die Richtigkeit und Übereinstimmung mit dem PSPF-Framework sicherzustellen. Email X-Header können über die meisten E-Mail-Clients angezeigt werden. In Outlook können Kopfzeilen je nach Clientversion entweder durch Öffnen einer E-Mail und Auswählen von Dateieigenschaften> oder Öffnen einer Nachricht und Auswählen vonNachrichteneigenschaften anzeigen> angezeigt werden.
Microsoft Message Header Analyzer kann auch zum Anzeigen von Headerinformationen verwendet werden, die sich unter https://mha.azurewebsites.net/befinden.
Australische Regierung Email Schutzkennzeichnung Standard bietet Beispiele, die Sie mit Ihrer eigenen Konfiguration vergleichen können.
Themenbasierte Kennzeichnungen
Ein alternativer Ansatz für die E-Mail-Kennzeichnung basiert auf E-Mail-Betrefffeldern, die geändert werden können, um eine Markierung am Ende eines E-Mail-Betreffs einzufügen. Beispiel: "Test-E-Mail-Betreff [SEC=PROTECTED]".
Wie in der australischen Regierung Email Schutzkennzeichnung Standard erläutert, können betreffbasierte Markierungen während der E-Mail-Generierung oder des Transports leicht bearbeitet werden. Um jedoch das Risiko des Entfernens von X-Headern zu minimieren, helfen betreffbasierte Markierungen bei Situationen, in denen E-Mail-Plattformen oder Clients E-Mail-Metadaten entfernt haben. Daher sollte die betreffbasierte Kennzeichnung als Hilfsmethode für x-Header verwendet werden.
| Anforderung | Detail |
|---|---|
| Schutzkennzeichnungs-Standard der australischen Regierung Email Syntax der Schutzmarkierung |
Die Kennzeichnung der Internetnachrichtenheadererweiterung ist der bevorzugte Ansatz für Australische Behörden. Eine Erweiterung für Internetnachrichtenheader ist für die Erstellung und Analyse durch E-Mail-Agents (Gateways und Server) konzipiert, die die Verarbeitung basierend auf der Schutzmarkierung ermöglicht. Wenn eine Internetnachrichtenkopferweiterung nicht möglich ist, werden Schutzmarkierungen im Betrefffeld einer E-Mail platziert. Beim Drucken wird eine E-Mail als physisches Dokument betrachtet, da auch eine visuelle Darstellung der Schutzkennzeichnung (z. B. eine separate Zeile in der E-Mail) wichtig ist. Beide Techniken können in einer einzelnen E-Mail-Nachricht verwendet werden, solange die Schutzmarkierung in beiden Nachrichten konsistent ist. Wenn eine Nachricht beide Formen der Schutzmarkierung enthält, haben Informationen in der Internet Message Header Extension Vorrang vor der Betrefffeldmarkierung. |
Hinweis
Obwohl die betreffbasierte Kennzeichnung weniger technisch ist als auf X-Headern basierende Ansätze, ist es immer noch eine völlig gültige Methode zum Anwenden von Markierungen auf E-Mails.
Anwenden von betreffbasierten E-Mail-Markierungen
Wie bei X-Headern werden themenbasierte Marker über DLP-Richtlinien angewendet. Richtlinien sollten aus der benutzerdefinierten Richtlinienvorlage erstellt werden und nur für den Exchange-Dienst gelten.
Stellen Sie sicher, dass die Richtlinie eine Regel für jede Vertraulichkeitsbezeichnung enthält. Ein geeignetes Beispiel für den Regelnamen ist EXO – Inoffizielle Antragstellermarkierung anwenden. Wie bei X-Header-basierten Regeln überschreiten Regelnamen wahrscheinlich die zulässigen Werte, wenn Kombinationen von Markierungen verwendet werden. Aus diesem Grund wenden die Beispiele in Beispiel-DLP-Richtlinien zum Anwenden von X-Headern und Betreffmarkierungen abgeschnittene Zeichen auf Vorbehalts- oder IMMs-Namen an.
Diese Regeln benötigen eine Bedingung von Inhalt enthält und dann die relevante Vertraulichkeitsbezeichnung für die Regel. Es ist nicht erforderlich, Ausnahmen für Regeln anzuwenden, die Antragstellermarkierungen anwenden.
Die Regelaktion sollte so konfiguriert werden, dass der Betreff geändert wird.
Die Aktion betreff ändern sollte mit einem regulären Ausdruck (RegEx) von \s*?\[SEC=.*?\]konfiguriert werden. Dieser RegEx überprüft und entfernt Werte innerhalb von Daten in eckigen Klammern, die mit [SEC=beginnen. Außerdem werden Leerzeichen vor markierungen entfernt.
Die Verwendung dieser RegEx-basierten Methode zum erneuten Anwenden von Antragstellermarkierungen stellt sicher, dass keine Duplizierung von Markierungen auftritt (z. B. [SEC=UNOFFICIAL] [SEC=UNOFFICIAL]). DLP-Richtlinien können dies erreichen, indem die Betreffmarkierung entfernt und durch den Wert aus der Quelle der Wahrheit ersetzt wird, der in diesem Fall die Bezeichnung der E-Mail ist.
Geben Sie im Feld Diesen Ersatztext einfügen Text ein, der als betreffbasierte Markierung verwendet wird. Es ist wünschenswert, der über Ersatztext angewendeten Markierung ein Leerzeichen (z. B. " [SEC=UNOFFICIAL]") voranzustellen, da dadurch sichergestellt wird, dass nach dem Ende des E-Mail-Betreffs und vor der Markierung ein Leerzeichen vorhanden ist. Stellen Sie sicher, dass Ihre RegEx-Funktion Leerzeichen (\s*?) im Muster zum Ändern des Betreffs enthält, um die Erfahrung konsistent zu halten. Ohne regEx könnten Leerzeichen leicht vor der Markierung gestapelt werden.
Die Position des Ersetzungstexts sollte so festgelegt werden, dass Übereinstimmungen entfernt und Ersetzungstext an den Betreff angefügt wird.
Wichtig
Anstelle mehrerer DLP-Richtlinien wird eine einzelne DLP-Richtlinie mit mehreren Regeln empfohlen, die X-Header- und Betreffmarkierungen anwenden. Eine Richtlinie, die diese Aktionen für alle erforderlichen Bezeichnungen erreicht, wurde in die DLP-Beispielrichtlinie aufgenommen, die x-Header und Betreffmarkierungen anwendet.
Dlp-Beispielrichtlinie zum Anwenden von X-Headern und Betreffmarkierungen
Die folgende DLP-Richtlinie soll X-Schutzmarkierungen und Betreffmarkierungen auf E-Mails anwenden.
Richtlinienname: EXO: Hinzufügen von PSPF-X-Header und Betreffmarkierung
Anwendbare Dienste: Umtausch
| Regel | Bedingungen | Actions |
|---|---|---|
UNOFFICIAL append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: UNOFFICIAL | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=UNOFFICIAL]
Position: Übereinstimmungen entfernen und anfügen |
UNOFFICIAL add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: UNOFFICIAL | Header festlegen:X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=UNOFFICIAL Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=UNOFFICIAL |
OFFICIAL append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=OFFICIAL]
Position: Übereinstimmungen entfernen und anfügen |
OFFICIAL add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=OFFICIAL Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=OFFICIAL |
OFFICIAL Sensitive append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Vertraulich | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=OFFICIAL:Sensitive]
Position: Übereinstimmungen entfernen und anfügen |
OFFICIAL Sensitive add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Vertraulich | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=OFFICIAL:Sensitive Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive |
OFFICIAL Sensitive PP append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Vertraulicher Datenschutz | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy]
Position: Übereinstimmungen entfernen und anfügen |
OFFICIAL Sensitive PP add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Vertraulicher Datenschutz | Header festlegen:X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive, ACCESS=Personal-Privacy |
OFFICIAL Sensitive LP append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Sensitive Legal Privilege | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=OFFICIAL:Sensitive, ACCESS=Legal-Privilege]
Position: Übereinstimmungen entfernen und anfügen |
OFFICIAL Sensitive LP add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Sensitive Legal Privilege | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Legal-Privilege Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legal-Privilege |
OFFICIAL Sensitive LS append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Sensitive Legislative Secrecy | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy]
Position: Übereinstimmungen entfernen und anfügen |
OFFICIAL Sensitive LS adds x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Sensitive Legislative Secrecy | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Legislative-Secrecy Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking: SEC=OFFICIAL[-: ]Sensitive, ACCESS=Legislative-Secrecy |
OFFICIAL Sensitive NC append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Sensitive NATIONAL CABINET | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=OFFICIAL:Sensitive, CAVEAT=SH:NATIONAL-CABINET]
Position: Übereinstimmungen entfernen und anfügen |
OFFICIAL Sensitive NC add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: OFFICIAL Sensitive NATIONAL CABINET | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=OFFICIAL:Sensitive, CAVEAT=SH:NATIONAL-CABINET Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=OFFICIAL[-: ]Sensitive, CAVEAT=SH[-: ]NATIONAL-CABINET |
PROTECTED append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=PROTECTED]
Position: Übereinstimmungen entfernen und anfügen |
PROTECTED add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=PROTECTED Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=PROTECTED |
PROTECTED PP append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED Persönlicher Datenschutz | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=PROTECTED, ACCESS=Personal-Privacy]
Position: Übereinstimmungen entfernen und anfügen |
PROTECTED PP add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED Persönlicher Datenschutz | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=PROTECTED, ACCESS=Personal-Privacy Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=PROTECTED, ACCESS=Personal-Privacy |
PROTECTED LP append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED Legal Privilege | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=PROTECTED, ACCESS=Legal-Privilege]
Position: Übereinstimmungen entfernen und anfügen |
PROTECTED LP add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED Legal Privilege | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=PROTECTED, ACCESS=Legal-Privilege Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=PROTECTED, ACCESS=Legal-Privilege |
PROTECTED LS append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED Legislative Secrecy | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=PROTECTED, ACCESS=Legislative-Secrecy]
Position: Übereinstimmungen entfernen und anfügen |
PROTECTED LS add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED Legislative Secrecy | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=PROTECTED, ACCESS=Legislative-Secrecy Es sei denn, der Header stimmt mit Mustern überein: X-Schutzmarkierung: SEC=PROTECTED, ACCESS=Legislative-Secrecy |
PROTECTED CABINET append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED CABINET | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=PROTECTED, CAVEAT=SH:CABINET]
Position: Übereinstimmungen entfernen und anfügen |
PROTECTED CABINET add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED CABINET | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=PROTECTED, CAVEAT=SH:CABINET Es sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=PROTECTED, CAVEAT=SH[-: ]CABINET |
PROTECTED NC append subject |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED NATIONAL CABINET | Betreff ändern, Text entfernen, der mit folgendem übereinstimmt: \s*?\[SEC=.*?\] Fügen Sie diesen Ersetzungstext ein:
[SEC=PROTECTED, CAVEAT=SH:NATIONAL-CABINET]
Position: Übereinstimmungen entfernen und anfügen |
PROTECTED NC add x-header |
Inhalt enthält Vertraulichkeitsbezeichnung: PROTECTED NATIONAL CABINET | Kopfzeile setzen: X-Protective-Marking:VER=2024.1, NS=gov.au, SEC=PROTECTED, CAVEAT=SH:NATIONAL-CABINETEs sei denn, der Header stimmt mit Mustern überein: X-Protective-Marking:SEC=PROTECTED, CAVEAT=SH[-: ]NATIONAL-CABINET |