Glossário de segurança do Azure Cosmos DB para NoSQL

APLICA-SE A: NoSQL

Diagrama da sequência do guia de implantação, incluindo esses locais, na ordem: Visão geral, Conceitos, Preparar, Controle de acesso baseado em função, Rede e Referência. A localização 'Conceitos' está atualmente em destaque.

Este artigo inclui um glossário de terminologia comum usada neste guia de segurança do Azure Cosmos DB para NoSQL.

Controlo de acesso baseado em funções

O controle de acesso baseado em função refere-se a um método para gerenciar o acesso a recursos no Azure. Esse método é baseado em identidades específicas que recebem funções que gerenciam o nível de acesso que elas têm a um ou mais recursos. O controle de acesso baseado em função fornece um sistema flexível de gerenciamento de acesso refinado que garante que as identidades tenham apenas o nível menos privilegiado de acesso de que precisam para executar suas tarefas.

Para obter mais informações, consulte Visão geral do controle de acesso baseado em função.

Identidade/Principal

Identidades referem-se a objetos dentro do Microsoft Entra que representam alguma entidade que pode precisar de um nível de acesso ao seu sistema. No contexto do Azure e do Microsoft Entra, as identidades podem referir-se a um dos seguintes tipos de entidades:

	Description
Identidades de carga de trabalho	Uma identidade de carga de trabalho representa uma carga de trabalho de software que precisa acessar outros serviços ou recursos
Identidades humanas	Uma identidade humana representa um usuário que pode ser nativo do seu locatário ou adicionado como convidado
Identidades geridas	As identidades gerenciadas são recursos distintos no Azure que representam a identidade de um serviço do Azure
Principais de serviço	Uma entidade de serviço é uma conta de serviço que pode ser usada em um número flexível de cenários de autenticação
Identidades de dispositivos	Uma identidade de dispositivo é um objeto no Microsoft Entra que é mapeado para um dispositivo
Grupos	Os grupos são objetos usados para gerenciar o acesso a uma ou mais identidades como uma única operação

Para obter mais informações, consulte Fundamentos de identidade.

Role

As funções são as principais unidades de imposição de acesso e permissões. Você atribui uma função a uma identidade e a definição da função dita o nível de acesso que essa identidade pode ter. O escopo da atribuição dita a que exatamente a identidade tem acesso.

O Azure tem um grande conjunto de funções internas que você pode usar para conceder acesso a vários recursos. Considere este exemplo:

	Value
Função	CosmosBackupOperator
Definição	Microsoft.DocumentDB/databaseAccounts/backup/action & Microsoft.DocumentDB/databaseAccounts/restore/action
Scope	Um grupo de recursos

Neste exemplo, você recebe a CosmosBackupOperator função para um grupo de recursos específico. Esta atribuição dá-lhe acesso para executar as backup ou restore ações em qualquer conta do Azure Cosmos DB dentro desse grupo de recursos.

Importante

Alguns serviços do Azure, como o Azure Cosmos DB, têm sua própria implementação de controle de acesso nativa baseada em função que usa diferentes propriedades do Azure Resource Manager, comandos da CLI do Azure e cmdLets do Azure PowerShell. Os comandos que você normalmente usa para gerenciar o controle de acesso baseado em função não funcionarão com o acesso ao plano de dados do Azure Cosmos DB. Alguns dos comandos para o controle de acesso baseado em função do Azure podem funcionar com o acesso ao plano de controle do Azure Cosmos DB.

Para obter mais informações, consulte Funções internas do Azure

Definição da função

Uma definição de função é um objeto JSON que contém a lista de ações do plano de controle e do plano de dados que são permitidas e não são permitidas. Considere este exemplo truncado da CosmosRestoreOperator função interna:

{
  "roleName": "CosmosRestoreOperator",
  "type": "Microsoft.Authorization/roleDefinitions",
  ...
  "permissions": [
    {
      "actions": [
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/restore/action",
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/*/read",
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  ...
}

Nessa definição, uma identidade atribuída a essa função pode executar uma restore ação. Quando a operação de restauração estiver concluída, a identidade poderá ler vários recursos para validar que a restauração foi bem-sucedida. Podemos determinar que ele pode ler esses recursos por causa do operador (curinga * ) para read.

Para obter mais informações, consulte conceitos de definição de função.

Atribuição de função

Uma atribuição de função concede acesso de identidade a um recurso específico do Azure. As atribuições de função consistem nos seguintes componentes:

	Description
Mandante	Que identidade é atribuída a esta função
Função	A função atribuída à identidade
Scope	O recurso ou grupo do Azure de destino da atribuição
Nome/Descrição	Metadados que facilitam o gerenciamento de atribuições em escala

Gorjeta

No controle de acesso baseado em função, você pode ver os termos identidade e principal usados de forma intercalada.

Para obter mais informações, consulte Conceitos de atribuição de função.

Ações

As ações definem quais permissões específicas uma função tem para um recurso de destino. As ações são cadeias de caracteres que normalmente incluem o tipo de recurso e um nome descritivo detalhando quais permissões a ação concede. Aqui estão alguns exemplos comuns:

	Description	Avião
Microsoft.DocumentDB/databaseAccounts/listKeys/action	Ler apenas chaves de conta	Plano de controlo
Microsoft.DocumentDB/databaseAccounts/backup/action	Fazer cópias de segurança	Plano de controlo
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/replace	Substitua totalmente um item existente	Plano de dados
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeQuery	Executar uma consulta NoSQL	Plano de dados

As ações também podem conter * caracteres (curinga) para que você não precise detalhar manualmente cada subpermissão específica. Aqui estão alguns exemplos de ações com curingas:

	Description
Microsoft.DocumentDb/databaseAccounts/*	Criar e gerenciar contas do Azure Cosmos DB
Microsoft.DocumentDB/*/read	Leia qualquer contêiner ou banco de dados

As ações são separadas em plano de controle e plano de dados. Você deve definir separadamente ações em recursos do plano de controle e ações que podem influenciar os dados. Em uma definição de função, as ações do plano de controle usam a propriedade e as actions ações do plano de dados estão dentro da dataActions propriedade. Você também pode definir ações que uma identidade não pode executar usando as respetivas notActions propriedades e notDataActions .

Nota

A separação de ações em controle e plano de dados é uma medida de segurança para evitar que ações curinga de definições de função herdadas tenham acesso irrestrito e não intencional aos dados.

Para obter mais informações, consulte ações de controle e dados.

Privilégio mínimo

O conceito de "privilégio mínimo" refere-se a uma prática operacional recomendada para garantir que todos os usuários tenham apenas o nível mínimo de acesso de que precisam para executar sua tarefa ou trabalho. Por exemplo, um aplicativo que lê dados de um banco de dados só precisaria de acesso de leitura ao armazenamento de dados. Se esse aplicativo tivesse acesso de leitura e gravação ao armazenamento de dados, algumas coisas poderiam acontecer, incluindo, mas não limitado a:

• O aplicativo pode destruir dados de forma errônea
• Um usuário não autorizado pode ter acesso às credenciais do aplicativo e modificar dados

Seguir a prática do menor privilégio garante que quaisquer violações de dados potenciais sejam limitadas no escopo. Esta prática maximiza a segurança operacional e permite que os utilizadores permaneçam eficazes.

Para obter mais informações, consulte Funções menos privilegiadas recomendadas por tarefa.

Plano de controlo

O acesso ao plano de controle refere-se à capacidade de gerenciar recursos para um serviço do Azure sem gerenciar dados. Por exemplo, o acesso ao plano de controle do Azure Cosmos DB pode incluir a capacidade de:

• Ler todos os metadados da conta e do recurso
• Ler e regenerar chaves de conta e cadeias de conexão
• Executar backups e restaurações de contas
• Iniciar e rastrear trabalhos de transferência de dados
• Gerenciar bancos de dados e contêineres
• Modificar propriedades da conta

Importante

No Azure Cosmos DB, você precisa de acesso ao plano de controle para gerenciar definições e atribuições de controle de acesso baseadas em função do plano de dados nativo. Como o mecanismo de controle de acesso baseado em função do plano de dados do Azure Cosmos DB é nativo, você precisará de acesso ao plano de controle para criar definições e atribuições e armazená-las como recursos em uma conta do Azure Cosmos DB.

Plano de dados

O acesso ao plano de dados refere-se à capacidade de ler e gravar dados em um serviço do Azure sem a capacidade de gerenciar recursos na conta. Por exemplo, o acesso ao plano de dados do Azure Cosmos DB pode incluir a capacidade de:

• Leia alguns metadados de contas e recursos
• Criar, ler, atualizar, corrigir e excluir itens
• Executar consultas NoSQL
• Ler a partir do feed de alterações de um contentor
• Executar procedimentos armazenados
• Gerenciar conflitos no feed de conflitos

Autenticação portátil

No desenvolvimento, é comum escrever dois conjuntos de lógicas de autenticação distintas para instâncias de desenvolvimento local e produção. Com o SDK do Azure, você pode escrever sua lógica usando uma única técnica e esperar que o código de autenticação funcione perfeitamente no desenvolvimento e na produção.

A biblioteca de cliente do Azure Identity está disponível em várias linguagens de programação como parte do SDK do Azure. Usando essa biblioteca, você pode criar um DefaultAzureCredential objeto que percorre de forma inteligente várias opções, em ordem, para encontrar a credencial certa com base em seu ambiente. Essas opções de autenticação incluem (na ordem):

1. Segredo do cliente ou certificado armazenado como uma variável de ambiente
2. ID da carga de trabalho do Microsoft Entra
3. Identidade gerenciada atribuída pelo usuário ou pelo sistema
4. Credenciais do Azure derivadas das configurações do Visual Studio
5. Credenciais usadas na extensão de Conta do Azure do Visual Studio Code
6. Credenciais atuais da CLI do Azure
7. Credenciais atuais do Azure PowerShell
8. Credenciais atuais da CLI do Desenvolvedor do Azure
9. Uma sessão interativa que inicia o navegador do sistema para iniciar sessão

Cada biblioteca moderna do SDK do Azure dá suporte a um construtor para seus respetivos objetos de cliente ou classes que aceitam uma DefaultAzureCredential instância ou seu tipo base.

Gorjeta

Para tornar seu código de produção mais fácil de depurar e mais previsível, você pode optar por usar DefaultAzureCredential no desenvolvimento e trocar para uma credencial mais específica, como WorkloadIdentityCredential ou ManagedIdentityCredential depois que o aplicativo for implantado. Todas essas classes são baseadas na TokenCredential classe que muitos SDKs do Azure esperam como parte de sua lógica de inicialização do cliente, tornando simples a troca para frente e para trás.

Identificador exclusivo

Cada identidade no Microsoft Entra tem um identificador exclusivo. Às vezes, você vê esse identificador exclusivo conhecido como id, objectIdou principalId. Ao criar atribuições de função, você precisa do identificador exclusivo para a identidade que você usa com a atribuição.

Âmbito

Ao atribuir uma função, você deve decidir a quais recursos ou grupos do Azure conceder acesso. O escopo de uma atribuição de função define o nível em que uma atribuição é feita.

Por exemplo:

• Um único escopo de recurso aplica permissões apenas a esse recurso singular
• Um escopo definido no nível do grupo de recursos aplica as permissões a todos os recursos relevantes dentro do grupo
• Os escopos no grupo de gerenciamento ou nos níveis de assinatura aplicam-se a todos os grupos e recursos filhos

Quando você atribui uma função no controle de acesso baseado em função do Azure, é ideal definir o escopo dessa atribuição para incluir o mínimo de recursos necessário para sua carga de trabalho. Por exemplo, você pode definir o escopo de uma atribuição para um grupo de recursos. Esse escopo do grupo de recursos inclui todos os recursos do Azure Cosmos DB dentro do grupo de recursos:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>

Como alternativa, você pode definir o escopo para um único recurso do Azure e tornar sua atribuição de permissões mais granular e estreita. Neste exemplo, o provedor e o nome do recurso do Azure Cosmos DB são usados para restringir o escopo:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>

Para obter mais informações, consulte Escopo do controle de acesso baseado em função do Azure.

Escopo (nativo do Azure Cosmos DB)

Na implementação nativa do controle de acesso baseado em função do Azure Cosmos DB, escopo refere-se à granularidade de recursos dentro de uma conta para a qual você deseja que a permissão seja aplicada.

No nível mais alto, você pode definir o escopo de uma atribuição de controle de acesso baseada em função do plano de dados para toda a conta usando o escopo maior. Esse escopo inclui todos os bancos de dados e contêineres dentro da conta:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/

Ou, você pode definir o escopo de sua atribuição de função de plano de dados para um banco de dados específico:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>

Finalmente, você pode definir o escopo da atribuição para um único contêiner, o escopo mais granular:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>/colls/<container-name>

Próximo passo

Obter login na identidade da conta