Share via

Diretrizes e informações gerais de segurança empresarial do Azure HDInsight

  • Artigo

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

Uso do cluster seguro

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

Não é necessário

  • Você executará apenas trabalhos automatizados (como conta de usuário único), um cluster padrão já basta.
  • 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 em que os usuários podem executar trabalhos de análise.

Uso da 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, o Ranger usa Negar como a política.

  • Quando o acesso a dados é feito por meio de um serviço em que a autorização está habilitada:

    • O plug-in de autorização do Ranger é invocado e recebe o contexto da solicitação.
    • O 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 o MapReduce, verificam apenas se o arquivo/a pasta pertence ao mesmo usuário que está enviando a solicitação. Serviços como o Hive, verifique se há uma relação de propriedade ou as permissões apropriadas do sistema de arquivos (rwx).

  • Para o Hive, além de ter as permissões para criar/atualizar/excluir permissões, 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ível) em vez de indivíduos.

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

Acesso de armazenamento

  • Se o tipo de armazenamento for WASB, nenhum token OAuth estará envolvido.
  • Se o Ranger tiver realizado a autorização, o acesso de armazenamento ocorrerá usando a identidade gerenciada.
  • Se o Ranger não tiver executado nenhuma autorização, então o acesso de armazenamento acontecerá usando o token OAuth do usuário.

Espaço de nome hierárquico

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

  • Não há permissões herdadas.
  • Somente a permissão FileSystem que funciona é a função do Azure Storage Data xxxx, a ser atribuída ao usuário diretamente no portal do Azure.

Permissões de HDFS padrão

  • 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 tenha sucesso).
  • Para o diretório de preparo para o MapReduce e outros, um diretório específico do usuário é criado e recebe permissões sticky _wx. Os usuários podem criar arquivos e pastas abaixo, mas não podem ver outros itens.

Autenticação de URL

Se a autenticação de URL estiver habilitada:

  • A configuração conterá os prefixos que serão abordados na autenticação de URL (como adl://).
  • Se o acesso for para essa URL, o Ranger verificará se o usuário está na lista de permitidos.
  • O Ranger não verificará nenhuma das políticas refinadas.

Gerenciar logs de auditoria do Ranger

Para impedir que os logs de auditoria do Ranger consumam muito espaço em disco no nó de cabeçalho hn0, você pode alterar o número de dias para manter os logs.

  1. Entre na interface do usuário do Ambari.
  2. Navegue até Serviços>Ranger>Configurações>Avançado>ranger-solr-configuration.
  3. Altere o “Máximo de Dias de Retenção” para 7 dias ou menos.
  4. Selecione Salvar e reinicie os componentes afetados para que a alteração entre em vigor.

Usar um BD do Ranger personalizado

É recomendável implantar um BD do Ranger externo para usar com o cluster ESP para alta disponibilidade de metadados do Ranger, o que garante que as políticas estejam disponíveis mesmo que o cluster não esteja disponível. Como um banco de dados externo é gerenciado pelo cliente, você também poderá ajustar o tamanho do BD e compartilhá-lo em vários clusters ESP. Você pode especificar o BD do Ranger externo durante o processo de criação do cluster ESP usando o portal do Azure, o Azure Resource Manager, a CLI do Azure etc.

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

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

  1. Entre na interface do usuário do Ambari.
  2. Navegue até Serviços>Ranger>Configurações>Avançado>ranger-ugsync-site
  3. Defina a propriedade ranger.usersync.sleeptimeinmillisbetweensynccycle como 86400000 (24h em milissegundos).
  4. Selecione Salvar e reinicie 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 NSGs (grupos de segurança de rede) 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.

ID do Microsoft Entra

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

Políticas

  • Desabilite a política de acesso condicional usando a política baseada em endereço IP. Isso exige que os pontos de extremidade de serviço sejam habilitados nas VNETs em que 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á

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

  • Habilita pontos de extremidade de serviço se você 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 usuário

  • 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 do 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.

Serviços de Domínio do Microsoft Entra

O Microsoft Entra Domain Services fornece serviços de domínio gerenciado, como ingresso no domínio, política de grupo, protocolo LDAP e autenticação Kerberos/NTLM totalmente compatível com o Windows Server Active Directory.

O Microsoft Entra Domain Services é necessário para que os clusters seguros ingressem em um domínio. O HDInsight não pode depender de controladores de domínio locais nem de controladores de domínio personalizados, pois isso apresenta muitos pontos de falha, compartilhamento de credenciais, permissões de DNS e assim por diante. Para obter mais informações, confira perguntas frequentes sobre o Microsoft Entra Domain Services.

Escolha o SKU correto do Microsoft Entra Domain Services

Ao criar seu domínio gerenciado, você pode escolher entre diferentes SKUs que oferecem diferentes níveis de desempenho e recursos. A quantidade de clusters ESP e outros aplicativos que usarão a instância do Microsoft Entra Domain Services para solicitações de autenticação determina qual SKU é apropriado para a sua organização. Se você observar a alta CPU em seu domínio gerenciado ou seus requisitos de negócios forem alterados, você poderá atualizar sua SKU.

Instância do Microsoft Entra Domain Services

  • Crie a instância com o .onmicrosoft.com domain. Dessa forma, não haverá vários servidores DNS servindo ao domínio.
  • Crie um certificado autoassinado para o LDAPS e carregue-o no Microsoft Entra Domain Services.
  • Use uma rede virtual emparelhada para a implantação de 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 do Microsoft Entra Domain Services deve ser resolvido sem entradas de arquivo de hosts).
  • Se você estiver restringindo o tráfego de saída, verifique se leu o suporte de firewall no HDInsight

Considere os conjuntos de réplicas do Microsoft Entra Domain Services

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

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

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

A Sincronização com escopo pode ser modificada com seleções de grupo diferentes ou convertida em "Todos" usuários e grupos, se necessário. Você não pode alterar o tipo de sincronização de "Todos" para "Escopo", a menos que exclua e recrie a instância do Microsoft Entra Domain Services.

Propriedades sincronizadas do Microsoft Entra ID para o Microsoft Entra Domain Services

  • O Microsoft Entra Connect sincroniza do local com o Microsoft Entra ID.
  • O Microsoft Entra Domain Services sincroniza com o Microsoft Entra ID.

O Microsoft Entra Domain Services sincroniza objetos do Microsoft Entra ID periodicamente. A folha Serviços de Domínio do Microsoft Entra no portal do Azure exibe o status de sincronização. Durante cada fase da sincronização, as propriedades exclusivas podem entrar em conflito e serem renomeadas. Preste atenção ao mapeamento de propriedades do Microsoft Entra ID para o Microsoft Entra Domain Services.

Para obter mais informações, confira População do UserPrincipalName do Microsoft Entra e Como funciona a sincronização do Microsoft Entra Domain Services.

Sincronização de hash de senha

  • As senhas são sincronizadas de maneira diferente de outros tipos de objeto. Somente hashes de senha não reversíveis são sincronizados no Microsoft Entra ID e no Microsoft Entra Domain Services
  • O Microsoft Entra ID local deve ser habilitado por meio do AD Connect
  • A sincronização do Microsoft Entra ID para o Microsoft Entra Domain Services é automática (as latências são inferiores a 20 minutos).
  • Os hashes de senha são sincronizados somente quando há uma senha alterada. Quando você habilita a sincronização de hash de senha, todas as senhas existentes não são sincronizadas automaticamente à medida que são armazenadas de maneira irreversível. Quando você altera a senha, os hashes de senha 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. A execução disso 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 do LDAP do Ambari para ser executado uma vez por dia. Esse script é executado por meio de um trabalho crontab e é armazenado no diretório "/etc/cron.hourly/" nos nós de cabeçalho do cluster.

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

  1. ssh para hn0
  2. Mova o script para a pasta diária cron: 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 executar em etapas 1 a 3

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

Local dos objetos de computador

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

Ferramentas administrativas do Active Directory

Para ver as etapas sobre como instalar as ferramentas administrativas do Active Directory em uma VM do Windows Server, confira Instalar ferramentas de gerenciamento.

Solução de problemas

A criação do cluster falha repetidamente

Motivos mais comuns:

  • A configuração de DNS não está correta, o ingresso no domínio de nós de cluster falha.
  • Os NSGs são muito restritivos, impedindo o ingresso 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 em tempo real ou com um cluster excluído).

Instalação e configuração de 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 no Microsoft Entra Domain Services. A correspondência com o campo de email não é obrigatória.

Propriedades LDAP na configuração do Ambari

Para ver uma lista completa das propriedades do Ambari que afetam a configuração do cluster HDInsight, confira Configuração da Autenticação LDAP do Ambari.

Gerar keytab(s) de usuário do domínio

Todos os keytabs de serviço são gerados 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 do cluster para criar um 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 for diferente, você precisará adicionar um valor SALT usando a opção -s. Verifique a página de perguntas frequentes do HDInsight para determinar o valor SAL adequado ao criar um keytab Kerberos.

Renovação de certificado LDAP

O HDInsight renovará automaticamente os certificados para as identidades gerenciadas que você usa para clusters com o ESP (Enterprise Security Package). No entanto, há uma limitação quando diferentes identidades gerenciadas são usadas para o Microsoft Entra Domain Services e o ADLS Gen2, que pode causar falha no processo de renovação. Siga as duas recomendações abaixo para garantir que possamos renovar seus certificados com êxito:

  • Se você usar diferentes identidades gerenciadas para clusters do ADLS Gen2 e do Microsoft Entra Domain Services, ambos deverão ter as funções Proprietário de dados de Blob de Armazenamento e Colaborador do HDInsight Domain Services atribuídas a eles.
  • Os clusters HDInsight exigem IPs públicos para atualizações de certificado e outras manutenções para que todas as políticas que negam IP público no cluster sejam removidas.

Próximas etapas