sensitivityLabel Ressourcentyp

Namespace: microsoft.graph.security

Beschreibt die Informationsschutzbezeichnung, in der erläutert wird, wie eine Vertraulichkeitsbezeichnung ordnungsgemäß auf Informationen angewendet wird. Die informationProtectionLabel-Ressource 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 für 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. ODER-Einschränkung mit isScopedToUser

   • Wenn isScopedToUser ein Filterparameter vorhanden ist, or ist er in den Filterparametern nicht zulässig

2. Vorfilterverhalten mit ODER

   • Wenn or in den Filterparametern vorhanden ist, werden locale die contentFormats Filterparameter (falls vorhanden) nicht für die Vorfilterung verwendet

3. Innere OR-Ausnahme

   • Innere or Operationen, 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. OP-Einschränkung mit mehreren Parametern

   • Wenn einer der folgenden Filterparameter vorhanden ist: isScopedToUser, id, oder ownerEmail, dann or ist er in den Filterparametern nicht zulässig

2. ownerEmail validation

   • ownerEmail Präsentieren ohne id Wirf eine ArgumentException.

3. Vorfilterverhalten mit ODER

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

4. Innere OR-Ausnahme

   • Sie können innere or Operationen zwischen einzelnen Sätzen 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 standardmäßigen OData-Spezifikation. In Standard-OData wird die Kombination mehrerer Tupel auf or diese Weise in der Regel nicht unterstützt. Mit dieser API können Sie jedoch ein tupelbasiertes ODER-Muster verwenden, bei dem jedes (id, ownerEmail) Paar unabhängig ausgewertet und die resultierenden Rechteinformationen zusammengeführt werden. Weitere Informationen zum standardmäßigen OData-Verhalten $filter finden Sie in der OData-Spezifikation.

Es wird empfohlen, Filter zu verwenden, die einen einzigen Aufruf mit mehreren IDs verwenden, um Rechte für mehrere Bezeichnungen abzurufen, da dies die Anzahl der API-Aufrufe reduziert, die Sie von Ihrer App aus tätigen müssen.

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

Regeln

1. Striktes ODER-Muster

   • Es wird nur die tupelbasierte Struktur unterstützt, die wie oben gezeigt durch OR-Operationen kombiniert wird.

   • Jede andere Kombination von ODER-Operationen oder das Mischen von nicht verwandten Filtern ist nicht zulässig und führt zu einer ArgumentException.

2. ownerEmail validation

   • ownerEmail Muss immer zusammen mit einer id. Die alleinige Verwendung ownerEmail führt zu einer ArgumentException.

3. Innere OR-Ausnahme

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

   • In diesem Beispiel gibt es drei Unterabschnitte. Wenn Sie ID und ownerEmail kombinieren, verwenden Sie AND in der Unterklausel. Verwenden Sie OR nicht, da sonst eine Ausnahme ausgelöst wird.

4. Verhalten vor der Filterung

   • Wenn or verwendet wird, werden die Parameter and contentFormats (falls angegeben) bei der locale Vorfilterung ignoriert.

Zusammenfassung des Verhaltens

Szenario 3: Rechte für Vertraulichkeitsbezeichnungen/id/rights

Regeln

1. ODER-Einschränkung mit ownerEmail

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

2. Innere OR-Ausnahme

   • Innere or Operationen, 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 APIs für Vertraulichkeitsbezeichnungen beschrieben.

Parameterverhalten

isScopedToUser = true

• Ergebnis: Nur aktivierte Bezeichnungen werden angezeigt
• Anwendungsfall: Standardfilterung für aktive/aktivierte Bezeichnungen
• Status: Empfohlene Verwendung

isScopedToUser = false

• Ergebnis: Nur deaktivierte Bezeichnungen werden angezeigt
• Anwendungsfall: Begrenzt – idealerweise nicht mit diesem Wert verwendet
• Status: Nicht empfohlen für typische Vorgänge

isScopedToUser not passed

• Ergebnis: Zeigt alle Bezeichnungen an (sowohl aktivierte als auch deaktiviert)
• Anwendungsfall: Umfassendes Abrufen von Etiketten
• Status: Standardverhalten, wenn Parameter weggelassen wird

Einschränkungen

Ausnahme bei Mandantenbezeichnungen

• Verhalten: Beim Abrufen von Mandantenbezeichnungen löst die Verwendung isScopedToUserArgumentException
• Grund: Der Parameter ist für Bezeichnungsvorgänge auf Mandantenebene nicht anwendbar
• 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"
}