sensitivityLabel tipo de recurso

Namespace: microsoft.graph.security

Descreve o rótulo de proteção de informações que detalha como aplicar corretamente um rótulo de confidencialidade às informações.

Métodos

Propriedades

Regras de filtragem de API de rótulo de confidencialidade

Esta seção descreve as regras de filtragem e as restrições disponíveis para serem aplicadas a várias chamadas à API do rótulo de confidencialidade.

Cenário 1: retornar rótulos de confidencialidade (1 ou mais)

O usuário chama a API e filtra por um ou mais GUIDs de ID de rótulo.

Exemplo

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

Regras

1. Restrição OR com isScopedToUser

   • Se isScopedToUser o parâmetro de filtro estiver presente, não or será permitido nos parâmetros de filtro

2. Comportamento de pré-filtragem com OR

   • Se or estiver presente nos parâmetros de filtro, então locale e contentFormats os parâmetros de filtro (se presentes) não serão usados para pré-filtragem

3. Exceção OU interna

   • São permitidas operações internas or que se enquadram na árvore de parâmetros

Cenário 2: Retornar resultados para rótulos de confidencialidade usando um filtro em uma única ID e direito de usuário

O usuário chama a API e filtra por uma ID de rótulo, GUID e um direito de usuário.

Exemplo

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

Regras

1. Restrição OR com vários parâmetros

   • Se qualquer um dos seguintes parâmetros de filtro estiver presente: isScopedToUser, idou ownerEmail, então or não é permitido nos parâmetros de filtro

2. ownerValidação de Email

   • ownerEmail presente sem id lança um ArgumentException.

3. Comportamento de pré-filtragem com OR

   • Se or estiver presente na cadeia de caracteres $filter, os locale parâmetros then and contentFormats filter serão ignorados e não serão usados para pré-filtrar os resultados.

4. Exceção OU interna

   • Você pode usar operações internas or entre cláusulas individuais.

Cenário 2.5: Retornar resultados para rótulos de confidencialidade usando um filtro para várias IDs e direitos de usuário

O usuário deseja chamar a API e filtrar por várias IDs e ownerEmail. Para obter esse resultado, você deve combinar a ID do rótulo e o ownerEmail em uma cláusula booleana.

Exemplo

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

Esse $filter padrão é uma extensão da especificação OData padrão. No OData padrão, a combinação de várias tuplas dessa or maneira normalmente não é suportada. No entanto, essa API permite que você use um padrão OR baseado em tupla, em que cada (id, ownerEmail) par é avaliado de forma independente e as informações de direitos resultantes são mescladas. Para obter mais informações sobre o comportamento padrão do OData $filter , consulte a especificação do OData.

Recomendamos o uso de filtros que usam uma única chamada com várias IDs para recuperar direitos para vários rótulos, pois isso reduz o número de chamadas de API que você precisa fazer do seu aplicativo.

ownerEmail é opcional e pode ser omitido para buscar apenas direitos no nível do rótulo.

Regras

1. Padrão OR estrito

   • Há suporte apenas para a estrutura baseada em tupla combinada por operações OR, conforme mostrado acima.

   • Qualquer outra combinação de operações OR ou mistura de filtros não relacionados não é permitida e resulta em um ArgumentException.

2. ownerValidação de Email

   • ownerEmail sempre devem aparecer acompanhados de um id. O uso ownerEmail isolado resulta em um ArgumentException.

3. Exceção OU interna

   • Você pode combinar cláusulas usando subcláusulas. Aqui está um exemplo de uma subcláusula: (id eq 'guid1' e ownerEmail eq 'ownerEmail1')

   • Neste exemplo, há três subcláusulas. Ao combinar a ID e ownerEmail, use AND na subcláusula. Não use OR, caso contrário, ele lançará uma exceção.

4. Comportamento de pré-filtragem

   • Quando or é usado, os locale parâmetros and contentFormats (se fornecidos) são ignorados para pré-filtragem.

Resumo do comportamento

Cenário 3: direitos do rótulo de confidencialidade /id/rights

Regras

1. OU restrição com ownerEmail

   • or operações com o parâmetro ownerEmail de filtro resulta em uma exceção.

2. Exceção OU interna

   • As operações internas or que se enquadram na árvore de parâmetros são permitidas.

Regras de parâmetro isScopedToUser

Esta seção descreve o comportamento e as restrições do isScopedToUser parâmetro em APIs de rótulo de confidencialidade.

Comportamento do parâmetro

isScopedToUser = true

• Resultado: Mostra apenas os rótulos ativados
• Caso de uso: filtragem Standard para rótulos ativos/habilitados
• Status: uso recomendado

isScopedToUser = false

• Resultado: Mostra apenas os rótulos desabilitados
• Caso de uso: Limitado - idealmente não usado com este valor
• Status: não recomendado para operações típicas

isScopedToUser não passado

• Resultado: Mostra todos os rótulos (ativado e desativado)
• Caso de uso: Recuperação abrangente de rótulos
• Status: comportamento padrão quando o parâmetro é omitido

Restrições

Exceção de rótulos de locatário

• Comportamento: ao obter rótulos de locatário, o uso isScopedToUser lançará ArgumentException
• Motivo: o parâmetro não é aplicável para operações de rótulo no nível do locatário
• Solução: omita o isScopedToUser parâmetro ao trabalhar com rótulos de locatário

Relações

Representação JSON

A representação JSON a seguir mostra o tipo de recurso.

{
  "@odata.type": "#microsoft.graph.security.sensitivityLabel",
  "id": "String (identifier)",
  "name": "String",
  "displayName": "String",
  "description": "String",
  "toolTip": "String",
  "isEnabled": "Boolean",
  "isEndpointProtectionEnabled": "Boolean",
  "isDefault": "Boolean",
  "applicationMode": "String",
  "priority": "Integer",
  "applicableTo": "String",
  "color": "String",
  "autoTooltip": "String",
  "locale": "String",
  "isScopedToUser": "Boolean",
  "actionSource": "String"
}