Autorização para análises em escala de nuvem no Azure
Autorização é o ato de conceder a uma parte autenticada permissão para executar uma ação. O princípio fundamental de de controle de acesso é dar aos usuários apenas a quantidade de acesso de que precisam para fazer seu trabalho e permitir apenas certas ações em um escopo específico. A segurança baseada em função corresponde ao controle de acesso e é usada por muitas organizações para controlar o acesso com base em funções definidas ou funções de trabalho versus usuários individuais. Os usuários recebem uma ou mais funções de segurança, cada uma das quais recebe permissões autorizadas para executar tarefas específicas.
Quando você usa o Microsoft Entra ID como o provedor de identidade centralizado, a autorização para acessar serviços de dados e armazenamento pode ser concedida por usuário ou por aplicativo e é baseada em uma identidade do Microsoft Entra.
Autorização de serviço de dados
de Controle de Acesso Role-Based (RBAC) do Azure e Listas de Controle de Acesso (ACLs) desempenham funções cruciais no gerenciamento de acesso e na garantia de segurança. O RBAC do Azure e as ACLs exigem que o usuário (ou aplicativo) tenha uma identidade na ID do Microsoft Entra. Na análise em escala de nuvem, o RBAC é eficaz para bancos de dados e Armazenamento Azure Data Lake, enquanto as ACLs são usadas principalmente no Armazenamento do Azure Data Lake para fornecer controle de acesso refinado nos níveis de arquivo e diretório. As ACLs complementam o RBAC oferecendo permissões mais detalhadas dentro da hierarquia de armazenamento.
O RBAC do Azure oferece funções internas como "Proprietário", "Colaborador" e "Leitor", mas você também pode criar funções personalizadas adaptadas a necessidades específicas. As seguintes funções internas são fundamentais para todos os tipos de recursos do Azure, incluindo os serviços de dados do Azure:
Funções | Descrição |
---|---|
Proprietário | Essa função tem acesso total ao recurso e pode gerenciar tudo sobre o recurso, incluindo o direito de conceder acesso a ele. |
Colaborador | Essa função pode gerenciar o recurso, mas não pode conceder acesso a ele. |
Reader | Essa função pode exibir o recurso e as informações sobre ele (exceto informações confidenciais, como chaves de acesso ou segredos), mas não pode fazer alterações no recurso. |
Observação
Alguns serviços têm funções RBAC específicas, como Storage Blob Data Contributor ou Data Factory Contributor, o que significa que funções RBAC específicas devem ser usadas para esses serviços. RBAC é um modelo aditivo onde adicionar atribuições de função é uma permissão ativa. O RBAC também suporta negar atribuições que tenham precedência sobre atribuições de de função.
Dica
Ao planejar uma estratégia de controle de acesso, recomenda-se conceder aos usuários apenas a quantidade de acesso de que precisam para executar seus trabalhos e permitir apenas determinadas ações em um escopo específico.
Controle de acesso em Bancos de Dados do Azure
O RBAC nos bancos de dados do Azure gira em torno de funções, escopos e permissões. O Azure fornece várias funções internas adaptadas para o gerenciamento de banco de dados, como o Colaborador do SQL Server, que permite o gerenciamento de servidores SQL e bancos de dados, e o Colaborador do Banco de Dados SQL, que permite o gerenciamento de bancos de dados SQL, mas não o servidor em si. Além disso, funções personalizadas podem ser criadas com permissões específicas para atender a requisitos exclusivos.
As funções podem ser atribuídas em escopos diferentes, incluindo o nível de assinatura, onde as funções se aplicam a todos os recursos dentro da assinatura; o nível do grupo de recursos, onde as funções se aplicam a todos os recursos dentro do grupo de recursos especificado; e o nível de recursos, onde as funções podem ser atribuídas diretamente a bancos de dados ou servidores individuais, fornecendo controle preciso. As permissões definem as ações que uma função pode executar, como ler, gravar, excluir ou gerenciar configurações de segurança, e essas permissões são agrupadas em funções para simplificar o gerenciamento.
No Banco de Dados SQL Azure, as funções podem ser atribuídas a usuários, grupos ou aplicativos para controlar o acesso. Por exemplo, um administrador de banco de dados pode receber a função "Colaborador do SQL Server" para gerenciar o servidor e os bancos de dados. Funções como "Colaborador do Banco de Dados SQL" permitem que os usuários criem, atualizem e excluam bancos de dados, enquanto a função "Gerenciador de Segurança SQL" se concentra nas configurações de segurança.
Para do Azure Cosmos DB, as funções podem ser atribuídas para gerenciar o acesso a contas, bancos de dados e contêineres do Cosmos DB. Funções internas como "Cosmos DB Account Reader" e "Cosmos DB Account Contributor" fornecem níveis variados de acesso.
No Banco de Dados do Azure para MySQL, PostgreSQL e MariaDB, você pode atribuir funções para gerenciar servidores de banco de dados e bancos de dados individuais. Funções como "Colaborador" e "Leitor" podem ser usadas para controlar o acesso.
Para obter mais informações, consulte funções incorporadas do Azure para bancos de dados.
Controle de acesso no Armazenamento do Azure Data Lake
O RBAC do Azure permite conceder acesso "de grão grosso" aos dados da conta de armazenamento, como acesso de leitura ou gravação a todos os dados em uma conta de armazenamento. As ACLs permitem conceder acesso "refinado", como acesso de gravação a um diretório ou arquivo específico.
Em muitos cenários, RBAC e ACLs são usados juntos para fornecer controle de acesso abrangente no ADLS. O RBAC pode ser usado para gerenciar o acesso de alto nível aos dados, garantindo que apenas usuários autorizados possam acessar o próprio serviço. As ACLs podem ser aplicadas na conta de armazenamento para controlar o acesso a arquivos e diretórios específicos, fornecendo uma camada extra de segurança.
O controle de acesso baseado em atributos (ABAC) do Azure se baseia no RBAC do Azure adicionando condições de atribuição de função com base em atributos no contexto de ações específicas. Ele essencialmente permite que você refine as atribuições de função RBAC adicionando condições. Por exemplo, você pode conceder acesso de leitura ou gravação a todos os objetos de dados em uma conta de armazenamento que tenham uma marca específica.
As funções a seguir permitem que uma principal de segurança aceda aos dados numa conta de armazenamento.
Funções | Descrição |
---|---|
Proprietário de Dados do Blob de Armazenamento | Acesso total a contêineres e dados de armazenamento de Blob. Esse acesso permite que a entidade de segurança defina o proprietário de um item e modifique as ACLs de todos os itens. |
do Contribuidor de Dados de Blob de Armazenamento | Leia, escreva e elimine acesso a contentores e blobs de armazenamento. Esse acesso não permite que a entidade de segurança defina a propriedade de um item, mas pode modificar a ACL de itens de propriedade da entidade de segurança. |
Leitor de dados de Blob de armazenamento | Leia e liste contentores e blobs do armazenamento Blob. |
Funções como Proprietário, Colaborador, Leitor e Colaborador da Conta de Armazenamento permitem que uma entidade de segurança gerencie uma conta de armazenamento, mas não fornecem acesso aos dados dessa conta. No entanto, essas funções (excluindo o Reader) podem obter acesso às chaves de armazenamento, que podem ser usadas em várias ferramentas de cliente para acessar os dados. Para obter mais informações, consulte Modelo de controle de acesso no Azure Data Lake Storage.
Controle de acesso no Azure Databricks
O Azure Databricks vem com sistemas de controle de acesso projetados para gerenciar o acesso dentro do ambiente Databricks, com foco em objetos protegíveis e governança de dados. Os três principais sistemas de controle de acesso no Azure Databricks são:
- Listas de controle de acesso: usado para configurar a permissão para acessar objetos de espaço de trabalho, como blocos de anotações. Para obter mais informações, consulte Listas de controle de acesso.
- Controle de acesso baseado em função de conta: usado para configurar a permissão para utilizar objetos ao nível da conta, como principais de serviço e grupos.
- Unity Catalog: usado para proteger e governar objetos de dados.
Além do controle de acesso em objetos, há funções internas na plataforma Azure Databricks. Utilizadores, principais de serviço e grupos podem ser atribuídos funções. Para obter mais informações, consulte funções de administrador do Databricks.
Práticas recomendadas para autorização em análises em escala de nuvem
Este guia fornece práticas recomendadas para implementar o controle de acesso baseado em função (RBAC) em ambientes de análise em escala de nuvem. Ele abrange princípios gerais do RBAC, controle de acesso ao banco de dados e práticas recomendadas de controle de acesso ao data lake para garantir o gerenciamento seguro e eficiente dos recursos.
Práticas recomendadas gerais do RBAC para análise em escala de nuvem
As seguintes práticas recomendadas podem ajudá-lo a começar a usar o RBAC:
Use funções RBAC para gerenciamento e operações de serviço e use funções específicas de serviço para acesso a dados e tarefas específicas de carga de trabalho: Use funções RBAC nos recursos do Azure para conceder permissão a entidades de segurança que precisam executar tarefas de gerenciamento de recursos e operações. As entidades de segurança que precisam acessar dados no armazenamento não exigem uma função RBAC no recurso porque não precisam gerenciá-lo. Em vez disso, conceda permissão a objetos de dados diretamente. Por exemplo, conceda acesso de leitura a uma pasta no Azure Data Lake Storage Gen2 ou a um usuário de banco de dados contido e permissão de tabela em um banco de dados no Banco de Dados SQL do Azure.
Use funções RBAC integradas: Primeiro, use as funções de recurso RBAC do Azure integradas para gerir serviços e atribuir funções de operações para controlar o acesso. Crie e use funções personalizadas para recursos do Azure somente quando as funções internas não atenderem a necessidades específicas.
Usar grupos para gerenciarde acesso: atribua acesso a grupos do Microsoft Entra e gerencie associações de grupo para gerenciamento contínuo de acesso.
Escopos de assinatura e grupo de recursos: Em ambientes não produtivos, é frequentemente lógico conceder acesso ao nível do grupo de recursos para separar as necessidades de acesso de gestão de serviços e operações em comparação com a concessão de acesso a recursos individuais. O motivo é que, em ambientes que não são de produção, os desenvolvedores e testadores precisam gerenciar recursos como a criação de um pipeline de ingestão do Azure Data Factory ou a criação de um contêiner no Data Lake Storage Gen2. No entanto, em ambientes de produção, você pode conceder acesso a recursos individuais para tarefas específicas da carga de trabalho, como suporte e operações do sistema de arquivos data lake. O motivo é que, durante a produção, os usuários só precisam usar recursos como visualizar o status de um pipeline de ingestão agendada do Data Factory ou ler arquivos de dados no Data Lake Storage Gen2.
Não conceda acesso desnecessário no escopo da assinatura: O escopo da assinatura abrange todos os recursos dentro da assinatura.
Opte por acesso com privilégios mínimos: Selecione a função certa e única para o trabalho.
Práticas recomendadas de controle de acesso ao banco de dados
A implementação de um controle de acesso baseado em função (RBAC) eficaz é crucial para manter a segurança e a capacidade de gerenciamento em seu ambiente de análise. Esta seção fornece práticas recomendadas para usar grupos do Microsoft Entra, funções internas e evitar permissões diretas de usuário para garantir um processo de gerenciamento de acesso simplificado e seguro.
As análises em escala de nuvem provavelmente contêm armazenamento poliglota. Os exemplos incluem PostgreSQL, MySQL, Banco de Dados SQL do Azure, Instância Gerenciada do SQL e Azure Synapse Analytics.
- Use grupos do Microsoft Entra em vez de contas de usuário individuais: Recomendamos que você use grupos do Microsoft Entra para proteger objetos de banco de dados em vez de contas de usuário individuais do Microsoft Entra. Use esses grupos do Microsoft Entra para autenticar usuários e proteger objetos de banco de dados. Semelhante ao padrão data lake, você pode usar a integração do aplicativo de dados para criar esses grupos.
- Use funções internas para gerenciar o acesso: crie funções personalizadas somente se necessário para atender a requisitos específicos ou quando as funções internas concederem muitas permissões.
- Abster-se de atribuir permissões a usuários individuais: Use funções (funções de banco de dados ou de servidor) de forma consistente. As funções ajudam muito na elaboração de relatórios e na solução de problemas relacionados a permissões. (O RBAC do Azure só dá suporte à atribuição de permissões por meio de funções.)
Observação
Os aplicativos de dados podem armazenar produtos de dados confidenciais no Banco de Dados SQL do Azure, na Instância Gerenciada do SQL ou nos pools do Azure Synapse Analytics. Para obter mais informações, consulte Dados confidenciais.
Práticas recomendadas de controle de acesso ao Data Lake
Em ambientes de dados modernos, garantir um controle de acesso seguro e eficiente é fundamental. O Azure Data Lake Storage (ADLS) Gen2 fornece mecanismos robustos para gerenciar o acesso por meio de ACLs (Listas de Controle de Acesso). Esta seção descreve as práticas recomendadas para implementar o controle de acesso baseado em função no ADLS Gen2, aplicando ACLs, grupos de segurança do Microsoft Entra e o princípio do menor privilégio para manter um ambiente de data lake seguro e gerenciável. Além disso, destaca-se a importância de alinhar as ACLs com os esquemas de particionamento de dados e usar o Unity Catalog para utilizadores do Azure Databricks para garantir uma segurança e governança abrangentes.
- Usar listas de controle de acesso (ACLs) para controle de acesso refinado: As ACLs desempenham um papel importante na definição de acesso em um nível granular. No Azure Data Lake Storage (ADLS) Gen2, as ACLs trabalham com entidades de segurança para gerenciar o acesso refinado a arquivos e diretórios.
- Aplicar ACLs no nível de arquivo e pasta: Para controlar o acesso aos dados no data lake, recomendamos o uso de listas de controle de acesso (ACLs) no nível de arquivos e pastas. O Azure Data Lake também adota um modelo de lista de controle de acesso semelhante ao POSIX. POSIX (portable operating system interface) é uma família de padrões para sistemas operacionais. Um padrão define uma estrutura de permissão simples, mas poderosa, para acessar arquivos e pastas. POSIX é adotado amplamente para compartilhamentos de arquivos de rede e computadores Unix.
- Usar grupos de segurança do Microsoft Entra como a entidade atribuída numa entrada de ACL: Evite atribuir diretamente usuários individuais ou entidades de serviço. O uso dessa estrutura permite adicionar e remover usuários ou entidades de serviço sem a necessidade de reaplicar ACLs a uma estrutura de diretórios inteira. Em vez disso, você pode simplesmente adicionar ou remover usuários e entidades de serviço do grupo de segurança apropriado do Microsoft Entra.
- Atribua acesso a grupos do Microsoft Entra e gere os membros dos grupos para gestão contínua de acesso. Consulte Controle de acesso e configurações de data lake no Azure Data Lake Storage.
- Aplicar o princípio do menor privilégio às ACLs: Na maioria dos casos, os utilizadores devem ter apenas permissão de leitura para os arquivos e pastas de que precisam no data lake. Os usuários de dados não devem ter acesso ao contêiner da conta de armazenamento.
- Alinhar ACLs com esquemas de particionamento de dados: ACLs e design de partição de dados devem ser alinhados para garantir um controle de acesso aos dados eficaz. Para obter mais informações, consulte a divisão do Data Lake em .
- Para usuários do Azure Databricks, controle exclusivamente o acesso a objetos de dados com o Unity Catalog: Conceder acesso direto no nível de armazenamento ao armazenamento de local externo no Azure Data Lake Storage Gen2 não honra nenhuma permissão concedida ou auditorias mantidas pelo Unity Catalog. O acesso direto ao Unity Catalog contorna a auditoria, a rastreabilidade e outros recursos de segurança e monitorização, incluindo: controlo de acesso e permissões. Portanto, os usuários finais do Azure Databricks não devem ter acesso direto no nível de armazenamento às tabelas e volumes gerenciados pelo Unity Catalog.
Próximos passos
Provisionar segurança para análises em escala de nuvem no Azure