Glossário de segurança do Azure Cosmos DB for NoSQL
APLICA-SE A: NoSQL
Diagrama da sequência do guia de implantação, incluindo esses locais, em ordem: Visão geral, Conceitos, Preparação, Controle de acesso baseado em função, Rede e Referência. O local "Conceitos" está destacado no momento.
Este artigo inclui um glossário da terminologia comum usada neste guia de segurança do Azure Cosmos DB for NoSQL.
Controle de acesso baseado em função
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 são atribuídas a 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 de acesso menos privilegiado 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/Entidade de segurança
As identidades referem-se a objetos no 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 se referir a um dos seguintes tipos de entidades:
Descrição | |
---|---|
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 ao seu locatário ou adicionado como convidado |
identidades gerenciadas | Identidades gerenciadas são recursos distintos no Azure que representam a identidade de um serviço do Azure |
Entidades 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 do dispositivo | Uma identidade de dispositivo é um objeto no Microsoft Entra que é mapeado em um dispositivo |
Grupos | 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 os Conceitos básicos de identidades.
Função
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 determina o nível de acesso que essa identidade pode ter. O escopo da atribuição determina 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:
Valor | |
---|---|
Função | CosmosBackupOperator |
Definição | Microsoft.DocumentDB/databaseAccounts/backup/action & Microsoft.DocumentDB/databaseAccounts/restore/action |
Escopo | Um grupo de recursos |
Neste exemplo, você recebe a função CosmosBackupOperator
para um grupo de recursos específico. Essa atribuição fornece acesso para executar as ações backup
ou restore
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 baseado em função nativa 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 controle de acesso baseado em função do Azure podem funcionar com o acesso ao painel de controle do Azure Cosmos DB.
Para obter mais informações, veja Funções internas do Azure
Definição de 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 que não são permitidas. Considere este exemplo truncado da função interna CosmosRestoreOperator
:
{
"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 ação restore
. Depois que a operação de restauração for concluída, a identidade poderá ler vários recursos para validar se 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 os conceitos de definição de função.
Atribuição de função
Uma atribuição de função concede a uma identidade acesso a um recurso específico do Azure. As atribuições de função consistem nos seguintes componentes:
Descrição | |
---|---|
Principal | Qual identidade é atribuída a essa função |
Função | A função que é atribuída à identidade |
Escopo | O recurso ou grupo de destino do Azure da atribuição |
Nome/Descrição | Metadados que facilitam o gerenciamento de atribuições em escala |
Dica
No controle de acesso baseado em função, você pode ver os termos identidade e entidade de segurança usados de forma intercambiável.
Para obter mais informações, consulte os 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 strings que normalmente incluem o tipo de recurso e um nome descritivo detalhando quais permissões a ação concede. Veja aqui alguns exemplos comuns:
Descrição | Plano | |
---|---|---|
Microsoft.DocumentDB/databaseAccounts/listKeys/action |
Ler apenas chaves de conta | Painel de controle |
Microsoft.DocumentDB/databaseAccounts/backup/action |
Executarem backups | Painel de controle |
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/replace |
Substituir 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:
Descrição | |
---|---|
Microsoft.DocumentDb/databaseAccounts/* |
Criar e gerenciar contas do Azure Cosmos DB |
Microsoft.DocumentDB/*/read |
Ler 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 actions
e as ações do plano de dados estão dentro da propriedade dataActions
. Você também pode definir as ações que uma identidade não pode executar usando as respectivas propriedades notActions
e notDataActions
.
Observação
A separação de ações nos planos de controle e de dados é uma medida de segurança para impedir 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égios mínimos
O conceito de "privilégio mínimo" refere-se a uma melhor prática operacional para garantir que todos os usuários tenham apenas o nível mínimo de acesso necessário 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, entre outras:
- O aplicativo poderia destruir dados erroneamente
- Um usuário não autorizado poderia obter acesso às credenciais do aplicativo e modificar dados
Seguir a prática de privilégios mínimos garante que quaisquer possíveis violações de dados sejam limitadas em escopo. Essa prática maximiza a segurança operacional e permite que os usuários permaneçam eficazes.
Para obter mais informações, consulte funções menos privilegiadas recomendadas por tarefa.
Painel de controle
O acesso ao painel de controle refere-se à capacidade de gerenciar recursos para um serviço do Azure sem gerenciar dados. Por exemplo, o acesso ao painel de controle do Azure Cosmos DB pode incluir a capacidade de:
- Ler todos os metadados de contas e recursos
- Ler e regenerar chaves de conta e strings 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 painel 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:
- Ler alguns metadados de contas e recursos
- Criar, ler, atualizar, aplicar patches e excluir itens
- Executar consultas NoSQL
- Ler o feed de alterações do contêiner
- Executar procedimentos armazenados
- Gerenciar conflitos no feed de conflitos
Autenticação portátil
Em desenvolvimento, é comum escrever dois conjuntos de lógica de autenticação distinta para instâncias locais de desenvolvimento 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 diretamente nos ambientes de desenvolvimento e de produção.
A biblioteca de clientes 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 objeto DefaultAzureCredential
que percorre de forma inteligente várias opções a fim de encontrar a credencial correta com base em seu ambiente. Essas opções de autenticação incluem (em ordem):
- Segredo do cliente ou certificado armazenado como uma variável de ambiente
- Carga de trabalho do Microsoft Entra ID
- Uma identidade gerenciada atribuída pelo sistema ou pelo usuário
- Credenciais do Azure derivadas de configurações do Visual Studio
- Credenciais usadas na extensão de conta do Azure do Visual Studio Code
- Credenciais atuais da CLI do Azure
- Credenciais atuais do Azure PowerShell
- Credenciais atuais da Azure Developer CLI
- Uma sessão interativa que inicia o navegador do sistema para iniciar sessão
Cada biblioteca moderna do SDK do Azure oferece suporte a um construtor para seus respectivos objetos ou classes de cliente que aceitam uma instância DefaultAzureCredential
ou seu tipo base.
Dica
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 classe TokenCredential
que muitos SDKs do Azure esperam como parte de sua lógica de inicialização do cliente, facilitando a troca de um lado para o outro.
Identificador exclusivo
Cada identidade no Microsoft Entra tem um identificador exclusivo. Às vezes, você verá esse identificador exclusivo chamado de id
, objectId
ou principalId
. Ao criar atribuições de função, você precisa do identificador exclusivo da identidade que utiliza com a atribuição.
Escopo
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 escopo de recurso simples 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 nos níveis de grupo de gerenciamento ou assinatura se aplicam a todos os grupos e recursos filhos
Ao atribuir uma função no controle de acesso baseado em função do Azure, o 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. O 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 restrita. Nesse 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, veja Escopo de controle de acesso baseado em função do Azure.
Escopo (Azure Cosmos DB nativo)
Na implementação nativa do controle de acesso baseado em função do Azure Cosmos DB, o escopo se refere à granularidade dos 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 maior escopo. 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 da atribuição de função do 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>
Por fim, você pode delimitar a 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>