Glossário de segurança do Azure Cosmos DB for Table

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

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:

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:

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.

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:

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:

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:

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.

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

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):

1. Segredo do cliente ou certificado armazenado como uma variável de ambiente
2. Carga de trabalho do Microsoft Entra ID
3. Uma identidade gerenciada atribuída pelo sistema ou pelo usuário
4. Credenciais do Azure derivadas de 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 Azure Developer CLI
9. 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.

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 padrão:

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

Por fim, você pode delimitar a atribuição para um único contêiner (tabela), o escopo mais granular:

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

Próxima etapa