☰

Dr.

tag-icon • tag-icon active-directory azure domain-controller
Dr.

No momento, estamos migrando nossos servidores para o Azure. A partir de agora, migramos com sucesso nosso servidor web (IIS) e nosso servidor de banco de dados (SQL Server). No próximo ano, nossa empresa estenderá o controlador de domínio para a nuvem com sincronização entre o local e o Azure.

No entanto, é possível associar as 2 VMs ao diretório ativo posteriormente sem enfrentar alguns conflitos? Eu sei que pode ser um incômodo em desktops normais porque você precisa trocar de perfil e outras coisas. Vocês veriam algum problema que poderíamos enfrentar ou deveríamos tentar entrar nos servidores o mais rápido possível?

Desde já, obrigado!

Responder1

Dr.

Portanto, isso é mais uma resposta de segurança do que de compatibilidade.

O resumo rápido da compatibilidade é que, se você confiar na autenticação do usuário AD, isso será interrompido, mas se você usar usuários SQL e anônimos/algum tipo de autenticação da Web local especial para o site, poderá ingressar sempre que quiser.

Do lado da segurança; a centralização reduz erros humanos, dívida técnica, área de superfície para ataque e aumenta a visibilidade, facilidade de uso e segurança.

Segurança

Se você possui servidores, juntá-los a um sistema de gerenciamento central é muito importante para facilitar o gerenciamento, centralizar a identidade e audibilidade.

Identidade Central

Ter ilhas de identidade é um risco de segurança, pois quando um funcionário sai, você precisará alternar/desativar as credenciais manualmente em cada ilha, isso aumenta os riscos de interrupções (rotação acidental de credenciais não direcionadas), rotação esquecida (perda de uma ilha) e mais.

Se você for hackeado, o bandido pode ficar em uma única ilha e montar ataques a partir daí. Depois que o bandido consegue controlar mais ilhas, fica muito mais difícil expulsar o invasor dos vários provedores de identidade. Basicamente, você teria que ir a cada máquina e investigar cada uma separadamente como um sistema separado. Este é um processo muito difícil e os bandidos podem aproveitar o tempo que leva para investigar e remediar para recuperar o controle dos sistemas dos quais foram ejetados.

A centralização da identidade é crítica para as organizações.

Auditoria

A capacidade de auditar (reunir logs do sistema) seus sistemas também é um fator de segurança extremamente importante. Sem um sistema de gestão central, esta etapa crítica de segurança é muito difícil.
Sem a capacidade de ver o que está acontecendo em seu sistema, você não consegue protegê-lo de maneira eficaz, pois não consegue ver o que os bandidos estão fazendo nele. Você não pode ejetá-los, você pode até vê-los em seus computadores. Na verdade, isso é tão ruim no setor que leva em média 1 ano antes que uma organização descubra que foi comprometida E ordenou aoLista dos 10 melhores do OWASP.

Gerenciamento

Do lado da capacidade de gerenciamento, configurações incorretas são um enorme risco de segurança. Eles são tão ruins que fizeram oLista dos 10 melhores do OWASP. Para reduzir o risco de configurações incorretas, a centralização do gerenciamento de configuração é fundamental. Isso reduz a chance de um ser humano cometer um erro ao definir as configurações necessárias ou de que a configuração nunca seja definida. Um sistema central de gerenciamento de configuração também facilita o envio de comandos aos endpoints para remediar comprometimentos. Um bom mecanismo de gerenciamento também pode produzir dados de auditoria (logging) para dar mais visibilidade sobre o que está acontecendo no seu ambiente.

Compatibilidade

o principal aspecto a ser observado é o sistema de autenticação. Se você usar o Windows Server AD para autenticar, poderá ter problemas; se usar usuários SQL locais (inseguros), você deverá estar bem no lado da compatibilidade.

Contanto que os namespaces aos quais você ingressará nas máquinas estejam disponíveis e seus GPOs não entrem em conflito com o servidor web necessário e as configurações de banco de dados, você deve estar bem. Com conhecimento limitado do ambiente, não é fácil encontrar casos extremos. De modo geral, você deve estar pronto para ir.

Caso extremo potencial:
se você tiver um FQDN sofisticado em seu aplicativo da web, o domínio que ingressa em sua máquina pode alterar seu FQDN.

Ligações

informação relacionada