Autenticação para análise de escala de nuvem no Azure
Autenticação é o processo de verificação da identidade do usuário ou aplicativo. É preferível um provedor único de identidade de origem, que lide com o gerenciamento de identidades e a autenticação. Esse provedor é conhecido como serviço de diretório. Ele fornece métodos para armazenar dados de diretório e disponibilizá-los para usuários e administradores de rede.
Qualquer solução de data lake deve usar e integrar-se com o serviço de diretório já em uso. Para a maioria das organizações, o Active Directory é o serviço de diretório para todos os serviços relacionados com identidade. É o banco de dados primário e centralizado para todas as contas de serviço e de usuário.
Na nuvem, o Microsoft Entra ID é um provedor de identidade centralizado e a fonte preferida para o gerenciamento de identidades. Delegar autenticação e autorização à ID do Microsoft Entra permite cenários como políticas de acesso condicional que exigem que um usuário esteja em um local específico. Ele oferece suporte à autenticação multifator, para aumentar o nível de segurança de acesso. Configure serviços de armazenamento de dados de data lake com a integração do Microsoft Entra quando possível.
Para serviços de dados que não oferecem suporte à ID do Microsoft Entra, use a chave de acesso ou o token para autenticação. O cliente deve armazenar a chave de acesso em um repositório de gerenciamento de chaves, como o Azure Key Vault.
Os cenários de autenticação para a análise em escala de nuvem são:
- Autenticação de usuário
- Autenticação de aplicativo e serviço a serviço
Autenticação de usuário
Os usuários que se conectam a um recurso ou serviço de dados devem apresentar uma credencial. Essa credencial comprova que eles são quem alegam ser. Em seguida, podem acessar o serviço ou recurso. A autenticação também permite que o serviço detecte a identidade dos usuários. O serviço decide o que um usuário pode ver e fazer após a identidade ser verificada.
O Azure Data Lake Storage Gen2, o Banco de Dados SQL do Azure e o Azure Synapse dão suporte à integração do Microsoft Entra. O modo interativo de autenticação de usuário exige que os usuários forneçam credenciais em uma caixa de diálogo.
Importante
Não codifique as credenciais do usuário em um aplicativo para fins de autenticação.
Autenticação de aplicativo e serviço a serviço
Essas solicitações não se associam a um usuário específico ou não há usuário disponível para inserir credenciais.
Autenticação serviço a serviço
Mesmo que um serviço acesse outro sem interações humanas, deve apresentar uma identidade válida. Essa identidade comprova que o serviço é real. O serviço acessado pode usar a identidade para decidir o que o solicitante pode fazer.
Na autenticação serviço a serviço, o método preferencial para autenticar serviços do Azure são as identidades gerenciadas. As identidades gerenciadas para recursos do Azure permitem a autenticação de qualquer serviço que ofereça suporte à autenticação do Microsoft Entra sem credenciais explícitas. Para obter mais informações, confira O que são as identidades gerenciadas para recursos do Azure.
Identidades gerenciadas são entidades de serviço, que só podem ser usadas com recursos do Azure. Por exemplo, uma identidade gerenciada pode ser criada diretamente para uma instância de Azure Data Factory. Essa identidade gerenciada é um objeto registrado no Microsoft Entra ID. Ela representa essa instância do Data Factory. Em seguida, pode ser usada para autenticação em qualquer serviço, como Data Lake Storage, sem credencial no código. O Azure cuida das credenciais usadas pela instância de serviço. A identidade pode conceder autorização a recursos de serviço do Azure, como uma pasta no Azure Data Lake Storage. Quando você exclui essa instância do Data Factory, o Azure limpa a identidade na ID do Microsoft Entra.
Benefícios do uso de identidades gerenciadas
As identidades gerenciadas devem ser usadas para autenticar um serviço do Azure em outro serviço ou recurso do Azure. Elas oferecem os seguintes benefícios:
- Uma identidade gerenciada representa o serviço para o qual ela é criada. Ela não representa um usuário interativo.
- As credenciais de identidade gerenciadas são mantidas, gerenciadas e armazenadas no Microsoft Entra ID. Não há senha a ser mantida pelo usuário.
- Com identidades gerenciadas, os serviços do cliente não usam senhas.
- A identidade gerenciada atribuída pelo sistema é excluída com a instância do serviço.
Esses benefícios significam que a credencial é mais protegida e o comprometimento da segurança é menos provável.
Autenticação de aplicativo para serviço
Outro cenário é o acesso de um aplicativo, como um aplicativo Web móvel, a um serviço do Azure. Quem quer que esteja acessando um serviço do Azure, deve fornecer sua identidade, que precisa ser verificada.
Uma entidade de serviço do Azure é a alternativa para aplicativos e serviços que não oferecem suporte a identidades gerenciadas para autenticação em recursos do Azure. Uma entidade de serviço do Azure é uma identidade criada para uso com aplicativos, serviços hospedados e ferramentas automatizadas para acessar os recursos do Azure. Esse acesso é restrito pelas funções atribuídas à entidade de serviço. Por motivos de segurança, é recomendável usar entidades de serviço com ferramentas ou aplicativos automatizados em vez de permitir sua entrada com identidade de usuário. Para obter mais informações, consulte Objetos de entidade de aplicativo e serviço no Microsoft Entra ID.
Observação
As identidades gerenciadas e as entidades de serviço são criadas e mantidas somente no Microsoft Entra ID.
Diferença entre identidade gerenciada e entidade de serviço
| Entidade de serviço | Identidade gerenciada |
|---|---|
| Uma identidade de segurança criada manualmente na ID do Microsoft Entra para uso por aplicativos, serviços e ferramentas para acessar recursos específicos do Azure. | É um tipo especial de entidade de serviço. Trata-se de uma identidade automática, criada quando um serviço do Azure é criado. |
| Pode ser usada por qualquer aplicativo ou serviço. Não está vinculada a um serviço específico do Azure. | Representa uma instância de serviço do Azure em si. Não pode ser usada para representar outros serviços do Azure. |
| Tem ciclo de vida independente. Você deve excluí-la explicitamente. | É excluída automaticamente quando a instância de serviço do Azure é excluída. |
| Autenticação baseada em senha ou em certificado. | Não há senha explícita a ser fornecida para autenticação. |
Autenticação e permissões de banco de dados
A análise em escala de nuvem provavelmente contém um armazenamento poliglota. Alguns exemplos são: PostgreSQL, MySQL, Banco de Dados SQL do Azure, Instância Gerenciada de SQL e Azure Synapse Analytics.
- Use o ID do Microsoft Entra para autenticação com PostgreSQL
- Usar a autenticação do Microsoft Entra com o Banco de Dados SQL do Azure, a Instância Gerenciada do SQL e o Azure Synapse Analytics
- Use o Microsoft Entra ID para autenticação com o MySQL
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 de data lake, você pode usar sua integração de aplicativo de dados para criar esses grupos.
Observação
Os aplicativos de dados podem armazenar produtos de dados confidenciais em pools do Banco de Dados SQL do Azure, da Instância Gerenciada de SQL ou do Azure Synapse Analytics. Para obter mais informações, consulte Dados confidenciais.
Segurança do Azure Data Lake na análise em escala de nuvem
Para controlar o acesso a dados no data lake, é recomendável usar ACL (lista de controle de acesso) no nível de arquivos e pastas. O Azure Data Lake também adota um modelo de lista de controle de acesso do tipo 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 avançada, para acessar arquivos e pastas. O POSIX vem sendo amplamente adotado para compartilhamentos de arquivos de rede e computadores UNIX.
Semelhante às práticas gerais de RBAC do Azure, as seguintes regras devem ser aplicadas à ACL:
Gerenciamento do acesso com o uso de grupos. Atribua acesso a grupos do Microsoft Entra e gerencie a associação de grupos para gerenciamento de acesso contínuo. Confira Configurações de controle de acesso e de data lake no Azure Data Lake Storage.
Privilégios mínimos. Na maioria dos casos, os usuários devem ter apenas permissão de leitura nas pastas e nos arquivos de que precisam no data lake. Uma identidade gerenciada ou entidade de serviço, como aquela usada pelo Azure Data Factory, tem permissões de leitura, gravação e execução. Os usuários de dados não devem ter acesso ao contêiner da conta de armazenamento.
Alinhamento com o esquema de particionamento de dados. A ACL e o design da partição de dados devem ser alinhados para garantir o controle efetivo do acesso aos dados. Para saber mais, confira [Particionamento de data lake].