Partilhar via

Informações gerais e diretrizes de segurança corporativa no Azure HDInsight

  • Artigo

Ao implantar um cluster HDInsight seguro, há algumas práticas recomendadas que devem facilitar a implantação e o gerenciamento do cluster. Algumas informações gerais e diretrizes são discutidas aqui.

Uso de cluster seguro

  • O cluster será usado por vários usuários ao mesmo tempo.
  • Os usuários têm diferentes níveis de acesso aos mesmos dados.

Não é necessário

  • Você vai executar apenas trabalhos automatizados (como uma conta de usuário único), um cluster padrão é bom o suficiente.
  • Você pode fazer a importação de dados usando um cluster padrão e usar a mesma conta de armazenamento em um cluster seguro diferente, onde os usuários podem executar trabalhos de análise.

Utilização de conta local

  • Se você usar uma conta de usuário compartilhada ou uma conta local, será difícil identificar quem usou a conta para alterar a configuração ou o serviço.
  • O uso de contas locais é problemático quando os usuários não fazem mais parte da organização.

Ranger

Políticas

  • Por padrão, a Ranger usa Negar como política.

  • Quando o acesso aos dados é feito através de um serviço onde a autorização está habilitada:

    • O plug-in de autorização Ranger é invocado e dado o contexto da solicitação.
    • A Ranger aplica as políticas configuradas para o serviço. Se as políticas do Ranger falharem, a verificação de acesso será adiada para o sistema de arquivos. Alguns serviços como MapReduce apenas verificam se o arquivo / pasta é de propriedade do mesmo usuário que está enviando a solicitação. Serviços como o Hive, verifique a correspondência de propriedade ou as permissões apropriadas do sistema de arquivos (rwx).

  • Para o Hive, além de ter as permissões para fazer as permissões Create / Update / Delete, o usuário deve ter rwxpermissões no diretório no armazenamento e em todos os subdiretórios.

  • As políticas podem ser aplicadas a grupos (preferíveis) em vez de indivíduos.

  • O autorizador Ranger avaliará todas as políticas da Ranger para esse serviço para cada solicitação. Esta avaliação pode ter um impacto no tempo necessário para aceitar o trabalho ou consulta.

Acesso ao armazenamento

  • Se o tipo de armazenamento for WASB, nenhum token OAuth estará envolvido.
  • Se a Ranger tiver realizado a autorização, o acesso ao armazenamento acontecerá usando a Identidade Gerenciada.
  • Se a Ranger não executou nenhuma autorização, o acesso ao armazenamento acontece usando o token OAuth do usuário.

Espaço de nome hierárquico

Quando o espaço de nome hierárquico não está ativado:

  • Não há permissões herdadas.
  • A única permissão do sistema de arquivos que funciona é a função do Azure Data XXXX de Armazenamento, a ser atribuída ao usuário diretamente no portal do Azure.

Permissões padrão do HDFS

  • Por padrão, os / usuários não têm acesso à pasta no HDFS (eles precisam estar na função de proprietário do blob de armazenamento para que o acesso seja bem-sucedido).
  • Para o diretório de preparo para mapreduce e outros, um diretório específico do usuário é criado e permissões fornecidas sticky _wx . Os usuários podem criar arquivos e pastas embaixo, mas não podem olhar para outros itens.

Autenticação de URL

Se a autenticação url estiver ativada:

  • A configuração conterá quais prefixos são cobertos na autenticação url (como adl://).
  • Se o acesso for para este url, então Ranger irá verificar se o usuário está na lista de permissões.
  • A Ranger não verificará nenhuma das políticas de grão fino.

Gerenciar logs de auditoria da Ranger

Para evitar que os logs de auditoria da Ranger consumam muito espaço em disco no headnode, você pode alterar o número de dias para reter os logs.

  1. Faça login na interface do usuário do Ambari.
  2. Navegue até Services>Ranger>Configs>Advanced Advanced>ranger-solr-configuration.
  3. Altere os 'Dias de retenção máximos' para 7 dias ou menos.
  4. Selecione Salvar e reiniciar os componentes afetados para que a alteração entre em vigor.

Use um Ranger DB personalizado

Recomendamos a implantação de um banco de dados Ranger externo para usar com seu cluster ESP para alta disponibilidade de metadados Ranger, o que garante que as políticas estejam disponíveis mesmo se o cluster não estiver disponível. Como um banco de dados externo é gerenciado pelo cliente, você também terá a capacidade de ajustar o tamanho do banco de dados e compartilhar o banco de dados em vários clusters ESP. Você pode especificar seu banco de dados Ranger externo durante o processo de criação do cluster ESP usando o portal do Azure, o Gerenciador de Recursos do Azure, a CLI do Azure, etc.

Definir a sincronização do usuário do Ranger para ser executada diariamente

Os clusters ESP do HDInsight são configurados para que a Ranger sincronize os usuários do AD automaticamente a cada hora. A sincronização do Ranger é uma sincronização do usuário e pode causar carga extra na instância do AD. Por esse motivo, recomendamos que você altere o intervalo de sincronização do usuário Ranger para 24 horas.

  1. Faça login na interface do usuário do Ambari.
  2. Navegue até Services>Ranger>Configs>Advanced>ranger-ugsync-site
  3. Defina a propriedade ranger.usersync.sleeptimeinmillisbetweensynccycle como 86400000 (24h em milissegundos).
  4. Selecione Salvar e reiniciar os componentes afetados para que a alteração entre em vigor.

Grupos de recursos

Use um novo grupo de recursos para cada cluster para que você possa distinguir entre os recursos do cluster.

NSGs, firewalls e gateway interno

  • Use grupos de segurança de rede (NSGs) para bloquear redes virtuais.
  • Use o firewall para lidar com políticas de acesso de saída.
  • Use o gateway interno que não está aberto para a Internet pública.

Microsoft Entra ID

O Microsoft Entra ID (Microsoft Entra ID ) é o serviço de gerenciamento de identidade e acesso baseado em nuvem da Microsoft.

Políticas

  • Desative a política de acesso condicional usando a política baseada em endereço IP. Isso requer que os pontos de extremidade de serviço sejam habilitados nas VNETs onde os clusters são implantados. Se você usar um serviço externo para MFA (algo diferente do Microsoft Entra ID), a política baseada em endereço IP não funcionará

  • AllowCloudPasswordValidation é necessária para usuários federados. Como o HDInsight usa o nome de usuário/senha diretamente para obter tokens da ID do Microsoft Entra, essa política deve ser habilitada para todos os usuários federados.

  • Habilite pontos de extremidade de serviço se precisar de bypass de acesso condicional usando IPs confiáveis.

Grupos

  • Sempre implante clusters com um grupo.
  • Use o Microsoft Entra ID para gerenciar associações de grupo (mais fácil do que tentar gerenciar os serviços individuais no cluster).

Contas de utilizador

  • Use uma conta de usuário exclusiva para cada cenário. Por exemplo, use uma conta para importação, use outra para consulta ou outros trabalhos de processamento.
  • Use políticas Ranger baseadas em grupo em vez de políticas individuais.
  • Tenha um plano sobre como gerenciar usuários que não devem mais ter acesso a clusters.

Microsoft Entra Domain Services

Os Serviços de Domínio Microsoft Entra fornecem serviços de domínio gerenciados, como ingresso no domínio, política de grupo, protocolo LDAP (lightweight directory access protocol) e autenticação Kerberos/NTLM que é totalmente compatível com o Ative Directory do Windows Server.

Os Serviços de Domínio Microsoft Entra são necessários para clusters seguros ingressarem em um domínio. O HDInsight não pode depender de controladores de domínio locais ou controladores de domínio personalizados, pois introduz muitos pontos de falha, compartilhamento de credenciais, permissões de DNS e assim por diante. Para obter mais informações, consulte Perguntas frequentes sobre os Serviços de Domínio do Microsoft Entra.

Escolha o Microsoft Entra Domain Services SKU correto

Ao criar seu domínio gerenciado, você pode escolher entre diferentes SKUs que oferecem níveis variados de desempenho e recursos. A quantidade de clusters ESP e outros aplicativos que usarão a instância dos Serviços de Domínio Microsoft Entra para solicitações de autenticação determina qual SKU é apropriada para sua organização. Se você notar alta CPU em seu domínio gerenciado ou seus requisitos de negócios mudarem, você pode atualizar seu SKU.

Instância dos Serviços de Domínio do Microsoft Entra

  • Crie a instância com o .onmicrosoft.com domain. Desta forma, não haverá vários servidores DNS a servir o domínio.
  • Crie um certificado autoassinado para o LDAPS e carregue-o para os Serviços de Domínio do Microsoft Entra.
  • Use uma rede virtual emparelhada para implantar clusters (quando você tiver várias equipes implantando clusters ESP do HDInsight, isso será útil). Isso garante que você não precise abrir portas (NSGs) na rede virtual com o controlador de domínio.
  • Configure o DNS para a rede virtual corretamente (o nome de domínio dos Serviços de Domínio Microsoft Entra deve ser resolvido sem entradas de arquivo hosts).
  • Se estiver a restringir o tráfego de saída, certifique-se de que leu o suporte de firewall no HDInsight

Considere os conjuntos de réplicas dos Serviços de Domínio Microsoft Entra

Ao criar um domínio gerenciado dos Serviços de Domínio Microsoft Entra, você define um namespace exclusivo e dois controladores de domínio (DCs) são implantados na região do Azure selecionada. Essa implantação de DCs é conhecida como um conjunto de réplicas. Adicionar conjuntos de réplicas adicionais fornecerá resiliência e garantirá a disponibilidade dos serviços de autenticação, o que é crítico para clusters do Azure HDInsight.

Configurar a sincronização de usuário/grupo com escopo

Ao habilitar os Serviços de Domínio do Microsoft Entra para seu cluster ESP, você pode optar por sincronizar todos os usuários e grupos da ID do Microsoft Entra ou grupos com escopo e seus membros. Recomendamos que você escolha a sincronização "Com escopo" para obter o melhor desempenho.

A sincronização com escopo pode ser modificada com diferentes seleções de grupo ou convertida em "Todos" usuários e grupos, se necessário. Não é possível alterar o tipo de sincronização de "Todos" para "Com escopo", a menos que exclua e recrie a instância dos Serviços de Domínio Microsoft Entra.

Propriedades sincronizadas do ID do Microsoft Entra para os Serviços de Domínio do Microsoft Entra

  • O Microsoft Entra Connect sincroniza do local com o Microsoft Entra ID.
  • Os Serviços de Domínio do Microsoft Entra sincronizam a partir da ID do Microsoft Entra.

Os Serviços de Domínio do Microsoft Entra sincronizam objetos do Microsoft Entra ID periodicamente. A folha Serviços de Domínio Microsoft Entra no portal do Azure exibe o status de sincronização. Durante cada estágio de sincronização, propriedades exclusivas podem entrar em conflito e renomeadas. Preste atenção ao mapeamento de propriedades do ID do Microsoft Entra para os Serviços de Domínio do Microsoft Entra.

Para obter mais informações, consulte População UserPrincipalName do Microsoft Entra e Como funciona a sincronização dos Serviços de Domínio do Microsoft Entra.

Sincronização do hash de palavras-passe

  • As senhas são sincronizadas de forma diferente de outros tipos de objeto. Somente hashes de senha não reversíveis são sincronizados no Microsoft Entra ID e nos Serviços de Domínio do Microsoft Entra
  • O ID do Microsoft Entra no local tem de ser ativado através do AD Connect
  • A sincronização do ID do Microsoft Entra com os Serviços de Domínio do Microsoft Entra é automática (as latências são inferiores a 20 minutos).
  • Os hashes de palavras-passe só são sincronizados quando uma palavra-passe é alterada. Quando ativar a sincronização do hash de palavras-passe, todas as palavras-passe existentes não serão sincronizadas automaticamente, uma vez que são armazenadas de forma irreversível. Quando altera a palavra-passe, os hashes de palavras-passe são sincronizados.

Definir a sincronização LDAP do Ambari para ser executada diariamente

O processo de sincronização de novos usuários LDAP com o Ambari é configurado automaticamente para ser executado a cada hora. Executar isso a cada hora pode causar excesso de carga nos nós principais do cluster e na instância do AD. Para melhorar o desempenho, recomendamos alterar o script /opt/startup_scripts/start_ambari_ldap_sync.py que executa a sincronização LDAP do Ambari para ser executado uma vez por dia. Este script é executado através de um trabalho crontab e é armazenado no diretório "/etc/cron.hourly/" nos headnodes do cluster.

Para executá-lo uma vez por dia, execute as seguintes etapas:

  1. ssh para hn0
  2. Mova o script para a pasta cron daily: sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
  3. Aplique a alteração no trabalho crontab: sudo service cron reload
  4. SSH para HN1 e repetir Stepts 1 - 3

Se necessário, você pode usar a API REST do Ambari para sincronizar manualmente novos usuários e grupos imediatamente.

Localização de objetos de computador

Cada cluster está associado a uma única UO. Um usuário interno é provisionado na UO. Todos os nós são domínios unidos na mesma UO.

Ferramentas administrativas do Ative Directory

Para obter etapas sobre como instalar as ferramentas administrativas do Ative Directory em uma VM do Windows Server, consulte Instalar ferramentas de gerenciamento.

Resolução de Problemas

A criação de cluster falha repetidamente

Razões mais comuns:

  • A configuração de DNS não está correta, a associação de domínio de nós de cluster falha.
  • Os NSGs são muito restritivos, impedindo a entrada no domínio.
  • A Identidade Gerenciada não tem permissões suficientes.
  • O nome do cluster não é exclusivo nos primeiros seis caracteres (com outro cluster dinâmico ou com um cluster excluído).

Instalação e configuração da autenticação

Nome Principal do Usuário (UPN)

  • Use letras minúsculas para todos os serviços - UPNs não diferenciam maiúsculas de minúsculas em clusters ESP, mas
  • O prefixo UPN deve corresponder a SAMAccountName nos Serviços de Domínio do Microsoft Entra. Não é necessário fazer a correspondência com o campo de correio.

Propriedades LDAP na configuração do Ambari

Para obter uma lista completa das propriedades do Ambari que afetam a configuração do cluster HDInsight, consulte Configuração da autenticação LDAP do Ambari.

Gerar chave(s) de usuário de domínio

Todas as teclas de serviço são geradas automaticamente para você durante o processo de criação do cluster ESP. Para habilitar a comunicação segura entre o cluster e outros serviços e/ou trabalhos que exigem autenticação, você pode gerar um keytab para seu nome de usuário de domínio.

Use o ktutil em uma das VMs de cluster para criar uma keytab Kerberos:


ktutil
ktutil: addent -password -p <username>@<DOMAIN.COM> -k 1 -e aes256-cts-hmac-sha1-96
Password for <username>@<DOMAIN.COM>: <password>
ktutil: wkt <username>.keytab
ktutil: q

Se seu TenantName & DomainName forem diferentes, você precisará adicionar um valor SALT usando a opção -s. Verifique a página de perguntas frequentes do HDInsight para determinar o valor SALT adequado ao criar uma keytab Kerberos.

Renovação do certificado LDAP

O HDInsight renovará automaticamente os certificados para as identidades gerenciadas usadas para clusters com o Enterprise Security Package (ESP). No entanto, há uma limitação quando diferentes identidades gerenciadas são usadas para os Serviços de Domínio Microsoft Entra e ADLS Gen2 que podem causar falha no processo de renovação. Siga as 2 recomendações abaixo para garantir que somos capazes de renovar seus certificados com sucesso:

  • Se você usar identidades gerenciadas diferentes para clusters de Serviços de Domínio ADLS Gen2 e Microsoft Entra, ambos deverão ter as funções de Proprietário de dados de blob de armazenamento e Colaborador dos Serviços de Domínio HDInsight atribuídas a eles.
  • Os clusters HDInsight exigem IPs públicos para atualizações de certificados e outras manutenções, portanto, quaisquer políticas que neguem IP público no cluster devem ser removidas.

Próximos passos