Autenticação para análise em escala de nuvem no Azure
A autenticação é o processo de verificação da identidade do usuário ou aplicativo. É preferível um único provedor de identidade de origem, que lida com o gerenciamento e a autenticação de identidade. Este provedor é conhecido como um serviço de diretório. Ele fornece métodos para armazenar dados de diretório e disponibilizar esses dados para usuários e administradores da rede.
Qualquer solução de data lake deve usar e integrar-se com o serviço de diretório que já está em uso. Para a maioria das organizações, o Ative Directory é o serviço de diretório para todos os serviços relacionados à 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 gerenciamento de identidades. Delegar autenticação e autorização ao Microsoft Entra ID permite cenários como políticas de acesso condicional que exigem que um usuário esteja em um local específico. Ele suporta autenticação multifator para aumentar o nível de segurança de acesso. Configure serviços de armazenamento de dados de data lake com integração com o Microsoft Entra quando possível.
Para serviços de dados que não suportam o Microsoft Entra ID, use a chave de acesso ou 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 análises em escala de nuvem são:
- Autenticação do utilizador
- Autenticação de aplicativo e serviço a serviço
Autenticação do utilizador
Os usuários que se conectam a um serviço ou recurso de dados devem apresentar uma credencial. Essa credencial prova que os usuários são quem eles reivindicam. Em seguida, eles podem acessar o serviço ou recurso. A autenticação também permite que o serviço conheça a identidade dos usuários. O serviço decide o que um usuário pode ver e fazer depois que a identidade é verificada.
O Azure Data Lake Storage Gen2, o Banco de Dados SQL do Azure e o Azure Synapse oferecem suporte à integração do Microsoft Entra. O modo de autenticação de usuário interativo exige que os usuários forneçam credenciais em uma caixa de diálogo.
Importante
Não codifice credenciais de 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 estão associadas a um usuário específico ou não há nenhum usuário disponível para inserir credenciais.
Autenticação serviço a serviço
Mesmo que um serviço aceda a outro serviço sem interações humanas, o serviço deve apresentar uma identidade válida. Esta identidade prova que o serviço é real. O serviço acessado pode usar a identidade para decidir o que o serviço pode fazer.
Para autenticação de serviço a serviço, o método preferencial para autenticar os serviços do Azure são as identidades gerenciadas. As identidades gerenciadas para recursos do Azure permitem a autenticação em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra sem credenciais explícitas. Para obter mais informações, consulte O que são identidades gerenciadas para recursos do Azure.
As 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 do Azure Data Factory. Essa identidade gerenciada é um objeto registrado no Microsoft Entra ID. Ele representa essa instância do Data Factory. Essa identidade pode ser usada para autenticar em qualquer serviço, como o Data Lake Storage, sem qualquer credencial no código. O Azure cuida das credenciais usadas pela instância de serviço. A identidade pode conceder autorização aos recursos de serviço do Azure, como uma pasta no Armazenamento do Azure Data Lake. 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. Proporcionam os seguintes benefícios:
- Uma identidade gerenciada representa o serviço para o qual foi criada. Ele 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 para um usuário manter.
- Com identidades gerenciadas, os serviços do cliente não usam senhas.
- A identidade gerenciada atribuída ao sistema é excluída quando a instância de serviço é excluída.
Esses benefícios significam que a credencial está mais bem protegida e que o comprometimento da segurança é menos provável.
Autenticação de aplicativo para serviço
Outro cenário de acesso é um aplicativo, como um aplicativo Web móvel, acessando um serviço do Azure. Quem está acessando um serviço do Azure, o acessador deve fornecer sua identidade e essa identidade deve ser verificada.
Uma entidade de serviço do Azure é a alternativa para que aplicativos e serviços que não oferecem suporte a identidades gerenciadas se autentiquem nos recursos do Azure. Um principal de serviço do Azure é uma identidade criada para ser utilizada com aplicações, serviços alojados e ferramentas automatizadas para aceder aos recursos do Azure. Esse acesso é restrito pelas funções atribuídas à entidade de serviço. Por motivos de segurança, recomendamos o uso de entidades de serviço com ferramentas ou aplicativos automatizados, em vez de permitir que eles entrem com uma identidade de usuário. Para obter mais informações, consulte Objetos principais de aplicativo e serviço no Microsoft Entra ID.
Nota
As identidades gerenciadas e as entidades de serviço são criadas e mantidas somente na ID do Microsoft Entra.
Diferença entre identidade gerenciada e entidade de serviço
| Service principal (Principal de serviço) | Identidade gerida |
|---|---|
| Uma identidade de segurança criada manualmente no Microsoft Entra ID para uso por aplicativos, serviços e ferramentas para acessar recursos específicos do Azure. | Um tipo especial de entidade de serviço. É uma identidade automática que é criada quando um serviço do Azure é criado. |
| Pode ser utilizado por qualquer aplicação ou serviço. Ele não está vinculado a um serviço específico do Azure. | Representa uma instância de serviço do Azure em si. Ele não pode ser usado para representar outros serviços do Azure. |
| Tem um ciclo de vida independente. Você deve excluí-lo explicitamente. | É excluído automaticamente quando a instância de serviço do Azure é excluída. |
| Autenticação baseada em senha ou certificado. | Nenhuma 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 armazenamento poliglota. Os exemplos incluem PostgreSQL, MySQL, Banco de Dados SQL do Azure, Instância Gerenciada SQL e Azure Synapse Analytics.
- Usar o Microsoft Entra ID 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 autenticar 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 data lake, você pode usar a integração do aplicativo de dados para criar esses grupos.
Nota
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.
Segurança do Azure Data Lake em análises em escala de nuvem
Para controlar o acesso aos dados no data lake, recomendamos o uso da lista de controle de acesso (ACL) 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 tem sido adotado amplamente para compartilhamentos de arquivos de rede e computadores Unix.
Semelhante às práticas gerais do RBAC do Azure, as seguintes regras devem ser aplicadas à ACL:
Gerencie o acesso usando grupos. Atribua acesso a grupos do Microsoft Entra e gerencie a associação de grupos para gerenciamento contínuo de acesso. Consulte Controle de acesso e configurações de data lake no Armazenamento do Azure Data Lake.
Menor privilégio. Na maioria dos casos, os usuários devem ter apenas permissão de leitura para as pastas e arquivos de que precisam no data lake. Uma identidade gerenciada ou entidade de serviço, como a 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.
Alinhe-se com o esquema de particionamento de dados. O design da ACL e da partição de dados deve estar alinhado para garantir um controle de acesso aos dados eficaz. Para obter mais informações, consulte [Particionamento do data lake].