sensitivityLabel-Ressourcentyp

Namespace: microsoft.graph.security

Beschreibt die Information Protection-Bezeichnung, die beschreibt, wie eine Vertraulichkeitsbezeichnung ordnungsgemäß auf Informationen angewendet wird. Die Ressource informationProtectionLabel beschreibt die Konfiguration von Vertraulichkeitsbezeichnungen, die für einen Benutzer oder Mandanten gelten.

Methoden

Eigenschaften

Api-Filterregeln für Vertraulichkeitsbezeichnungen

In diesem Abschnitt werden die Filterregeln und Einschränkungen beschrieben, die für verschiedene API-Aufrufe von Vertraulichkeitsbezeichnungen verfügbar sind.

Szenario 1: Zurückgeben von Vertraulichkeitsbezeichnungen (1 oder mehr)

Der Benutzer ruft die API auf und filtert nach einer oder mehreren Bezeichnungs-ID-GUIDs.

Beispiel

$filter=((id eq 'guid1') or (id eq 'guid2') or (id eq 'guid3'))

Regeln

1. OR-Einschränkung mit isScopedToUser

   • Wenn isScopedToUser der Filterparameter vorhanden ist, ist in den Filterparametern or nicht zulässig.

2. Vorfilterverhalten mit OR

   • Wenn or in den Filterparametern locale vorhanden ist, werden die Filterparameter und contentFormats (sofern vorhanden) nicht zum Vorfiltern verwendet.

3. Innere OR-Ausnahme

   • Innere or Vorgänge, die unter die Parameterstruktur fallen, sind zulässig.

Szenario 2: Zurückgeben von Ergebnissen für Vertraulichkeitsbezeichnungen mithilfe eines Filters für eine einzelne ID und ein Benutzerrecht

Der Benutzer ruft die API auf und filtert nach einer Bezeichnungs-ID-GUID und einem Benutzerrecht.

Beispiel

$filter=(id eq 'guid1' and ownerEmail eq 'ownerEmail1')

Regeln

1. OR-Einschränkung mit mehreren Parametern

   • Wenn einer der folgenden Filterparameter vorhanden ist: , idoder ownerEmail, or ist in den Filterparametern nicht zulässig. isScopedToUser

2. ownerEmail-Überprüfung

   • ownerEmail present ohne id löst eine aus ArgumentException.

3. Vorfilterverhalten mit OR

   • Wenn or in der $filter Zeichenfolge vorhanden ist, werden die locale Filterparameter und contentFormats ignoriert und nicht zum Vorabfiltern der Ergebnisse verwendet.

4. Innere OR-Ausnahme

   • Sie können innere or Vorgänge zwischen einzelnen Klauseln verwenden.

Szenario 2.5: Zurückgeben von Ergebnissen für Vertraulichkeitsbezeichnungen mithilfe eines Filters für mehrere IDs und Benutzerrechte

Der Benutzer möchte die API aufrufen und nach mehreren IDs und ownerEmail filtern. Um dieses Ergebnis zu erzielen, müssen Sie sowohl die Bezeichnungs-ID als auch ownerEmail in einer booleschen Klausel kombinieren.

Beispiel

$filter=(
   (id eq 'guid1' and ownerEmail eq 'ownerEmail1')
  or (id eq 'guid2')
  or (id eq 'guid3' and ownerEmail eq 'ownerEmail2')
)

Dieses $filter Muster ist eine Erweiterung der OData-Standardspezifikation. In Standard-OData wird das Kombinieren mehrerer Tupel mit or auf diese Weise in der Regel nicht unterstützt. Mit dieser API können Sie jedoch ein tupelbasiertes OR-Muster verwenden, bei dem jedes (id, ownerEmail) Paar unabhängig voneinander ausgewertet wird und die resultierenden Rechteinformationen zusammengeführt werden. Weitere Informationen zum OData-Standardverhalten $filter finden Sie in der OData-Spezifikation.

Es wird empfohlen, Filter zu verwenden, die einen einzelnen Aufruf mit mehreren IDs verwenden, um Rechte für mehrere Bezeichnungen abzurufen, da dadurch die Anzahl der API-Aufrufe reduziert wird, die Sie über Ihre App ausführen müssen.

ownerEmail ist optional und kann weggelassen werden, um nur Rechte auf Bezeichnungsebene abzurufen.

Regeln

1. Strenges OR-Muster

   • Nur die tupelbasierte Struktur, die durch OR-Vorgänge kombiniert wird, wie oben gezeigt, wird unterstützt.

   • Jede andere Kombination von OR-Vorgängen oder das Mischen von nicht verknüpften Filtern ist nicht zulässig und führt zu einer ArgumentException.

2. ownerEmail-Überprüfung

   • ownerEmail muss immer zusammen mit einem idangezeigt werden. Die verwendung allein ownerEmail führt zu einem ArgumentException.

3. Innere OR-Ausnahme

   • Sie können Klauseln mithilfe von Unterklauseln kombinieren. Hier sehen Sie ein Beispiel für eine Unterklausel: (id eq 'guid1' und ownerEmail eq 'ownerEmail1')

   • In diesem Beispiel gibt es drei Unterklauseln. Wenn Sie die ID und ownerEmail kombinieren, verwenden Sie AND in der Unterklausel. Verwenden Sie nicht ODER, andernfalls wird eine Ausnahme ausgelöst.

4. Vorfilterverhalten

   • Wenn or verwendet wird, werden die locale Parameter und contentFormats (sofern angegeben) zum Vorfiltern ignoriert.

Verhaltenszusammenfassung

Szenario 3: Vertraulichkeitsbezeichnungsrechte /id/rights

Regeln

1. OR-Einschränkung mit ownerEmail

   • or Vorgänge mit Filterparametern ownerEmail führen zu einer Ausnahme.

2. Innere OR-Ausnahme

   • Innere or Vorgänge, die unter die Parameterstruktur fallen, sind zulässig.

isScopedToUser-Parameterregeln

In diesem Abschnitt werden das Verhalten und die Einschränkungen für den isScopedToUser Parameter in Vertraulichkeitsbezeichnungs-APIs beschrieben.

Parameterverhalten

isScopedToUser = true

• Ergebnis: Zeigt nur aktivierte Bezeichnungen an.
• Anwendungsfall: Standard Filtern nach aktiv/aktivierten Bezeichnungen
• Status: Empfohlene Verwendung

isScopedToUser = false

• Ergebnis: Zeigt nur deaktivierte Bezeichnungen an.
• Anwendungsfall: Eingeschränkt – idealerweise nicht mit diesem Wert verwendet
• Status: Nicht für typische Vorgänge empfohlen

isScopedToUser nicht übergeben

• Ergebnis: Zeigt alle Bezeichnungen an (sowohl aktiviert als auch deaktiviert)
• Anwendungsfall: Umfassendes Abrufen von Bezeichnungen
• Status: Standardverhalten, wenn parameter nicht angegeben wird

Einschränkungen

Ausnahme für Mandantenbezeichnungen

• Verhalten: Beim Abrufen von Mandantenbezeichnungen löst die Verwendung von isScopedToUserArgumentException
• Ursache: Der Parameter gilt nicht für Bezeichnungsvorgänge auf Mandantenebene.
• Lösung: Lassen Sie den isScopedToUser Parameter bei der Arbeit mit Mandantenbezeichnungen aus.

Beziehungen

JSON-Darstellung

Die folgende JSON-Darstellung veranschaulicht den Ressourcentyp.

{
  "@odata.type": "#microsoft.graph.security.sensitivityLabel",
  "actionSource": "String",
  "applicableTo": "String",
  "applicationMode": "String",
  "assignedPolicies": [{"@odata.type": "microsoft.graph.labelPolicy"}],
  "autoLabeling": {"@odata.type": "microsoft.graph.autoLabeling"},
  "autoTooltip": "String",
  "color": "String",
  "description": "String",
  "displayName": "String",
  "hasProtection": "Boolean",
  "id": "String (identifier)",
  "isDefault": "Boolean",
  "isEnabled": "Boolean",
  "isEndpointProtectionEnabled": "Boolean",
  "isScopedToUser": "Boolean",
  "labelActions": [{"@odata.type": "microsoft.graph.encryptWithUserDefinedRights"}],
  "locale": "String",
  "name": "String",
  "priority": "Int32",
  "toolTip": "String"
}