Share via

Considerações de segurança para cargas de trabalho críticas no Azure

  • Artigo

A segurança é um dos princípios fundamentais de design e também uma área de design fundamental que deve ser tratada como uma preocupação de primeira classe dentro do processo arquitetônico crítico.

Considerando que o foco principal de um design crítico é maximizar a confiabilidade para que o aplicativo permaneça com desempenho e disponível, as considerações e recomendações de segurança aplicadas nessa área de design se concentrarão na mitigação de ameaças com a capacidade de afetar a disponibilidade e dificultar a confiabilidade geral. Por exemplo, ataques de DDoS (negação de serviço) bem-sucedidos são conhecidos por ter um impacto catastrófico na disponibilidade e no desempenho. Como um aplicativo atenua esses vetores de ataque, como o SlowLoris, afetará a confiabilidade geral. Portanto, o aplicativo deve estar totalmente protegido contra ameaças destinadas a comprometer direta ou indiretamente a confiabilidade do aplicativo para ser verdadeiramente crítico por natureza.

Também é importante observar que muitas vezes há compensações significativas associadas a uma postura de segurança protegida, especialmente no que diz respeito ao desempenho, à agilidade operacional e, em alguns casos, à confiabilidade. Por exemplo, a inclusão de NVA (Soluções de Virtualização de Rede) embutidas para recursos de NGFW (Firewall de Próxima Geração), como inspeção profunda de pacotes, introduzirá uma penalidade de desempenho significativa, complexidade operacional adicional e um risco de confiabilidade se as operações de escalabilidade e recuperação não estiverem estreitamente alinhadas com a do aplicativo. Portanto, é essencial que componentes e práticas de segurança adicionais destinados a mitigar os principais vetores de ameaça também sejam projetados para dar suporte ao destino de confiabilidade de um aplicativo, o que formará um aspecto fundamental das recomendações e considerações apresentadas nesta seção.

Importante

Este artigo faz parte da série de cargas de trabalho críticas do Azure Well-Architected . Se você não estiver familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho crítica?

Projeto de código aberto crítico do logotipo do GitHub

As implementações de referência fazem parte de um projeto de código aberto disponível no GitHub. Os ativos de código adotam um modelo Confiança Zero para estruturar e orientar a abordagem de design e implementação de segurança.

Alinhamento com o modelo de Confiança Zero

O modelo de Confiança Zero da Microsoft fornece uma abordagem proativa e integrada para aplicar a segurança em todas as camadas de um aplicativo. Os princípios orientadores de Confiança Zero se esforçam para verificar explicitamente e continuamente cada transação, declarar privilégios mínimos, usar inteligência e detecção avançada para responder a ameaças quase em tempo real. Em última análise, ele é centralizado na eliminação da confiança dentro e fora dos perímetros do aplicativo, impondo a verificação para qualquer coisa que tente se conectar ao sistema.

Considerações sobre o design

Conforme você avalia a postura de segurança do aplicativo, comece com essas perguntas como base para cada consideração.

  • Teste de segurança contínuo para validar mitigações para vulnerabilidades de segurança de chave.

    • Os testes de segurança são executados como parte dos processos automatizados de CI/CD?
    • Caso contrário, com que frequência os testes de segurança específicos são executados?
    • Os resultados do teste são medidos em relação a um modelo de ameaça e postura de segurança desejado?

  • Nível de segurança em todos os ambientes inferiores.

    • Todos os ambientes dentro do ciclo de vida de desenvolvimento têm a mesma postura de segurança que o ambiente de produção?

  • Continuidade da autenticação e autorização em caso de falha.

    • Se os serviços de autenticação ou autorização estiverem temporariamente indisponíveis, o aplicativo poderá continuar operando?

  • Conformidade e correção de segurança automatizadas.

    • As alterações nas principais configurações de segurança podem ser detectadas?
    • As respostas para corrigir alterações não compatíveis são automatizadas?

  • Verificação de segredo para detectar segredos antes que o código seja confirmado para evitar vazamentos de segredo por meio de repositórios de código-fonte.

    • A autenticação para serviços é possível sem ter credenciais como parte do código?

  • Proteja a cadeia de fornecimento de software.

    • É possível rastrear CVEs (Vulnerabilidades e Exposições Comuns) em dependências de pacote utilizadas?
    • Há um processo automatizado para atualizar dependências de pacote?

  • Ciclos de vida da chave de proteção de dados.

    • As chaves gerenciadas pelo serviço podem ser usadas para proteção de integridade de dados?
    • Se as chaves gerenciadas pelo cliente forem necessárias, como é o ciclo de vida de chave segura e confiável?

  • As ferramentas de CI/CD devem exigir Microsoft Entra entidades de serviço com acesso de nível de assinatura suficiente para facilitar o acesso do painel de controle para implantações de recursos do Azure a todas as assinaturas de ambiente consideradas.

    • Quando os recursos do aplicativo são bloqueados em redes privadas, há um caminho de conectividade de plano de dados privado para que as ferramentas de CI/CD possam executar implantações e manutenção no nível do aplicativo.
      • Isso introduz complexidade adicional e requer uma sequência dentro do processo de implantação por meio de agentes de build privados necessários.

Recomendações sobre design

  • Use o Azure Policy para impor configurações de segurança e confiabilidade a todos os serviços, garantindo que qualquer desvio seja corrigido ou proibido pelo painel de controle no momento da configuração, ajudando a atenuar as ameaças associadas a cenários de 'administrador mal-intencionado'.

  • Use o PIM (Microsoft Entra Privileged Identity Management) em assinaturas de produção para revogar o acesso sustentado do painel de controle a ambientes de produção. Isso reduzirá significativamente o risco representado de cenários de "administrador mal-intencionado" por meio de "verificações e saldos" adicionais.

  • Use identidades gerenciadas do Azure para todos os serviços que dão suporte à funcionalidade, pois ela facilita a remoção de credenciais do código do aplicativo e remove a carga operacional do gerenciamento de identidades para comunicação de serviço a serviço.

  • Use Microsoft Entra RBAC (controle de acesso baseado em função) para autorização do plano de dados com todos os serviços que dão suporte à funcionalidade.

  • Use bibliotecas de autenticação plataforma de identidade da Microsoft internas no código do aplicativo para se integrar ao Microsoft Entra ID.

  • Considere o cache de token seguro para permitir uma experiência degradada, mas disponível, se a plataforma de identidade escolhida não estiver disponível ou estiver apenas parcialmente disponível para autorização do aplicativo.

    • Se o provedor não puder emitir novos tokens de acesso, mas ainda validar os existentes, o aplicativo e os serviços dependentes poderão operar sem problemas até que seus tokens expirem.
    • O cache de token normalmente é tratado automaticamente por bibliotecas de autenticação (como MSAL).

  • Use iac (infraestrutura como código) e pipelines de CI/CD automatizados para direcionar atualizações para todos os componentes do aplicativo, incluindo em circunstâncias de falha.

    • Verifique se as conexões do serviço de ferramentas de CI/CD são protegidas como informações confidenciais críticas, pois não devem estar diretamente disponíveis para nenhuma equipe de serviço.
    • Aplique o RBAC granular aos pipelines de CD de produção para atenuar os riscos de 'administrador mal-intencionado'.
    • Considere o uso de portões de aprovação manual em pipelines de implantação de produção para atenuar ainda mais os riscos de "administrador mal-intencionado" e fornecer garantia técnica adicional para todas as alterações de produção.
      • Portões de segurança adicionais podem vir em uma compensação em termos de agilidade e devem ser cuidadosamente avaliados, com consideração sobre como a agilidade pode ser mantida mesmo com portões manuais.

  • Defina uma postura de segurança apropriada para todos os ambientes inferiores para garantir que as principais vulnerabilidades sejam atenuadas.

    • Não aplique a mesma postura de segurança que a produção, especialmente no que diz respeito à exfiltração de dados, a menos que os requisitos regulatórios estipulam a necessidade de fazê-lo, pois isso comprometerá significativamente a agilidade do desenvolvedor.

  • Habilite o Microsoft Defender para Nuvem (anteriormente conhecido como Central de Segurança do Azure) para todas as assinaturas que contêm os recursos de uma carga de trabalho crítica.

    • Use Azure Policy para impor a conformidade.
    • Habilite o Azure Defender para todos os serviços que dão suporte à funcionalidade.

  • Adote o DevSecOps e implemente testes de segurança em pipelines de CI/CD.

    • Os resultados do teste devem ser medidos em relação a uma postura de segurança em conformidade para informar as aprovações de versão, sejam elas automatizadas ou manuais.
    • Aplique testes de segurança como parte do processo de produção de CD para cada versão.
      • Se o teste de segurança de cada versão comprometer a agilidade operacional, verifique se uma cadência de teste de segurança adequada é aplicada.

  • Habilite a verificação de segredo e a verificação de dependência no repositório de código-fonte.

Modelagem de ameaças

A modelagem de ameaças fornece uma abordagem baseada em risco para o design de segurança, usando possíveis ameaças identificadas para desenvolver mitigações de segurança apropriadas. Há muitas ameaças possíveis com diferentes probabilidades de ocorrência e, em muitos casos, as ameaças podem encadear de maneiras inesperadas, imprevisíveis e até caóticas. Essa complexidade e incerteza são por isso que as abordagens tradicionais de segurança baseadas em requisitos de tecnologia são amplamente inadequadas para aplicativos de nuvem críticos. Espere que o processo de modelagem de ameaças para um aplicativo crítico seja complexo e inflexível.

Para ajudar a navegar nesses desafios, uma abordagem em camadas de defesa em profundidade deve ser aplicada para definir e implementar mitigações de compensação para ameaças modeladas, considerando as camadas defensivas a seguir.

  1. A plataforma do Azure com recursos e controles de segurança fundamentais.
  2. A arquitetura do aplicativo e o design de segurança.
  3. Recursos de segurança internos, habilitados e implantáveis aplicados a recursos seguros do Azure.
  4. Código do aplicativo e lógica de segurança.
  5. Processos operacionais e DevSecOps.

Observação

Ao implantar dentro de uma zona de destino do Azure, lembre-se de que uma camada adicional de mitigação de ameaças por meio do provisionamento de recursos de segurança centralizados é fornecida pela implementação da zona de destino.

Considerações sobre o design

O STRIDE fornece uma estrutura de risco leve para avaliar ameaças de segurança entre os principais vetores de ameaça.

  • Identidade falsificada: representação de indivíduos com autoridade. Por exemplo, um invasor representando outro usuário usando -
    • Identidade
    • Autenticação
  • Entrada de adulteração: modificação da entrada enviada ao aplicativo ou a violação dos limites de confiança para modificar o código do aplicativo. Por exemplo, um invasor que usa a Injeção de SQL para excluir dados em uma tabela de banco de dados.
    • Integridade de dados
    • Validação
    • Lista de bloqueios/lista de permitidos
  • Repúdio à Ação: capacidade de refutar ações já tomadas e a capacidade do aplicativo de coletar evidências e impulsionar a responsabilidade. Por exemplo, a exclusão de dados críticos sem a capacidade de rastrear um administrador mal-intencionado.
    • Auditoria/registro em log
    • Assinando
  • Divulgação de informações: obtendo acesso a informações restritas. Um exemplo seria um invasor obtendo acesso a um arquivo restrito.
    • Criptografia
    • Exfiltração dos dados
    • Ataques de homem no meio
  • Negação de Serviço: interrupção mal-intencionada do aplicativo para degradar a experiência do usuário. Por exemplo, um ataque de botnet DDoS, como Slowloris.
    • DDoS
    • Botnets
    • Funcionalidades de CDN e WAF
  • Elevação de privilégio: obtendo acesso privilegiado ao aplicativo por meio de explorações de autorização. Por exemplo, um invasor manipulando uma cadeia de caracteres de URL para obter acesso a informações confidenciais.
    • Execução remota de código
    • Autorização
    • Isolamento

Recomendações sobre design

  • Aloque o orçamento de engenharia em cada sprint para avaliar possíveis novas ameaças e implementar mitigações.

  • O esforço consciente deve ser aplicado para garantir que as mitigações de segurança sejam capturadas dentro de um critério de engenharia comum para impulsionar a consistência em todas as equipes de serviço de aplicativo.

  • Comece com um serviço por modelagem de ameaças no nível de serviço e unifique o modelo consolidando o modelo de thread no nível do aplicativo.

Proteção contra intrusão de rede

Impedir o acesso não autorizado a um aplicativo crítico e aos dados abrangidos é essencial para manter a disponibilidade e proteger a integridade dos dados.

Considerações sobre o design

  • Confiança Zero pressupõe um estado violado e verifica cada solicitação como se ela se originasse de uma rede descontrolada.

    • Uma implementação avançada de rede de confiança zero emprega a microssegmentação e os microperímetros de entrada/saída distribuídos.

  • Os serviços de PaaS do Azure normalmente são acessados por pontos de extremidade públicos. O Azure fornece funcionalidades para proteger os pontos de extremidade públicos ou até torná-los totalmente privados.

    • O Link Privado do Azure/os Pontos de Extremidade Privados fornecem acesso dedicado a um recurso de PaaS do Azure usando endereços IP privados e conectividade de rede privada.
    • Rede Virtual pontos de extremidade de serviço fornecem acesso no nível do serviço de sub-redes selecionadas para serviços de PaaS selecionados.
    • Rede Virtual Injection fornece implantações privadas dedicadas para serviços com suporte, como Serviço de Aplicativo por meio de um Ambiente do Serviço de Aplicativo.
      • O tráfego do plano de gerenciamento ainda flui por meio de endereços IP públicos.

  • Para serviços com suporte, Link Privado do Azure usar pontos de extremidade privados do Azure aborda os riscos de exfiltração de dados associados a pontos de extremidade de serviço, como um administrador mal-intencionado gravando dados em um recurso externo.

  • Ao restringir o acesso à rede aos serviços de PaaS do Azure usando pontos de extremidade privados ou pontos de extremidade de serviço, um canal de rede seguro será necessário para que os pipelines de implantação acessem o plano de controle do Azure e o plano de dados dos recursos do Azure para implantar e gerenciar o aplicativo.

    • Agentes de build auto-hospedados privados implantados em uma rede privada, pois o recurso do Azure pode ser usado como um proxy para executar funções de CI/CD em uma conexão privada. Uma rede virtual separada deve ser usada para agentes de build.
      • A conectividade com os agentes de build privados das ferramentas de CI/CD é necessária.
    • Uma abordagem alternativa é modificar as regras de firewall para o recurso em tempo real dentro do pipeline para permitir uma conexão de um endereço IP público do agente do Azure DevOps, com o firewall removido posteriormente após a conclusão da tarefa.
      • No entanto, essa abordagem só é aplicável a um subconjunto de serviços do Azure. Por exemplo, isso não é viável para clusters aks privados.
    • Para executar tarefas administrativas e de desenvolvedor nas jump boxes do serviço de aplicativo, é possível usar.

  • A conclusão das tarefas de administração e manutenção é um cenário adicional que exige conectividade com o plano de dados dos recursos do Azure.

  • A Connections de serviço com uma entidade de serviço de Microsoft Entra correspondente pode ser usada no Azure DevOps para aplicar o RBAC por meio de Microsoft Entra ID.

  • As Marcas de Serviço podem ser aplicadas aos Grupos de Segurança de Rede para facilitar a conectividade com os serviços de PaaS do Azure.

  • Os Grupos de Segurança do Aplicativo não abrangem várias redes virtuais.

  • A captura de pacotes no Azure Observador de Rede é limitada a um período máximo de cinco horas.

Recomendações sobre design

  • Limite o acesso à rede pública ao mínimo absoluto necessário para que o aplicativo atenda à sua finalidade comercial para reduzir a superfície de ataque externa.

  • Ao lidar com agentes de build privados, nunca abra uma porta RDP ou SSH diretamente para a Internet.

    • Use o Azure Bastion para fornecer acesso seguro ao Azure Máquinas Virtuais e executar tarefas administrativas no PaaS do Azure pela Internet.

  • Use um plano de proteção padrão de DDoS para proteger todos os endereços IP públicos dentro do aplicativo.

  • Use o Azure Front Door com políticas do firewall do aplicativo Web para entregar e ajudar a proteger aplicativos HTTP/S globais que abrangem várias regiões do Azure.

    • Use a validação de ID de cabeçalho para bloquear pontos de extremidade de aplicativo públicos para que eles aceitem apenas o tráfego proveniente da instância do Azure Front Door.

  • Se requisitos adicionais de segurança de rede em linha, como inspeção de pacotes profundos ou inspeção de TLS, exigir o uso de Firewall do Azure Premium ou NVA (Solução de Virtualização de Rede), verifique se ele está configurado para máxima alta disponibilidade e redundância.

  • Se houver requisitos de captura de pacotes, use Observador de Rede pacotes para capturar, apesar da janela de captura limitada.

  • Use Grupos de Segurança de Rede e Grupos de Segurança de Aplicativos para micro segmentar o tráfego de aplicativos.

    • Evite usar um dispositivo de segurança para filtrar fluxos de tráfego no aplicativo.
    • Considere o uso de Azure Policy para impor regras NSG específicas sempre associadas a sub-redes de aplicativo.

  • Habilite os logs de fluxo do NSG e alimente a Análise de Tráfego com eles para obter insights sobre fluxos de tráfego internos e externos do aplicativo.

  • Use o Link Privado do Azure/os Pontos de Extremidade Privados, quando disponível, para proteger o acesso aos serviços de PaaS do Azure no design do aplicativo. Para obter informações sobre os serviços do Azure com suporte para o Link Privado, confira Disponibilidade do Link Privado do Azure.

  • Se o Ponto de Extremidade Privado não estiver disponível e os riscos de exfiltração de dados forem aceitáveis, use Rede Virtual pontos de extremidade de serviço para proteger o acesso aos serviços de PaaS do Azure de dentro de uma rede virtual.

    • Não habilite os pontos de extremidade de serviço de rede virtual por padrão em todas as sub-redes, pois isso introduzirá canais de exfiltração dos dados significativos.

  • Para os cenários de aplicativo híbrido, acesse os serviços de PaaS do Azure no local por meio do ExpressRoute com o emparelhamento privado.

Observação

Ao implantar em uma zona de destino do Azure, lembre-se de que a conectividade de rede com data centers locais é fornecida pela implementação da zona de destino. Uma abordagem é usar o ExpressRoute configurado com emparelhamento privado.

Proteção de integridade de dados

A criptografia é uma etapa vital para garantir a integridade dos dados e, em última análise, uma das funcionalidades de segurança mais importantes que podem ser aplicadas para atenuar uma ampla gama de ameaças. Portanto, esta seção fornecerá as principais considerações e recomendações relacionadas à criptografia e ao gerenciamento de chaves para proteger os dados sem comprometer a confiabilidade do aplicativo.

Considerações sobre o design

  • O Azure Key Vault tem limites de transação para chaves e segredos, com limitação aplicada por cofre dentro de um determinado período.

  • O Azure Key Vault fornece um limite de segurança, pois as permissões de acesso para chaves, segredos e certificados estão no nível do cofre.

    • As atribuições de política de acesso do Key Vault concedem separadamente as permissões a chaves, segredos ou certificados.

  • Depois que uma atribuição de função é alterada, há uma latência de até 10 minutos (600 segundos) para a função a ser aplicada.

    • Há um limite de 2.000 atribuições de função do Azure por assinatura.

  • Os HSMs (módulos de segurança de hardware) subjacentes do Azure Key Vault têm validação FIPS 140.

  • O Key Vault do Azure fornece alta disponibilidade e redundância para ajudar a manter a disponibilidade e evitar a perda de dados.

  • Durante um failover de região, pode levar alguns minutos para que o serviço Key Vault faça failover.

    • Durante um failover Key Vault estará em um modo somente leitura, portanto, não será possível alterar as propriedades do cofre de chaves, como configurações e configurações de firewall.

  • Se o link privado for usado para se conectar ao Azure Key Vault, pode levar até 20 minutos para que a conexão seja restabelecida durante um failover regional.

  • Um backup cria uma instantâneo pontual de um segredo, chave ou certificado, como um blob criptografado que não pode ser descriptografado fora do Azure. Para obter dados utilizáveis do blob, ele deve ser restaurado em um Key Vault na mesma assinatura do Azure e na geografia do Azure.

    • Os segredos podem ser renovados durante um backup, causando uma incompatibilidade.

  • Com chaves gerenciadas pelo serviço, o Azure executará funções de gerenciamento de chaves, como rotação, reduzindo assim o escopo das operações de aplicativo.

  • Os controles regulatórios podem estipular o uso de chaves gerenciadas pelo cliente para a funcionalidade de criptografia de serviço.

  • Quando o tráfego se move entre data centers do Azure, a criptografia de camada de link de dados DO MACsec é usada no hardware de rede subjacente para proteger dados em trânsito fora dos limites físicos não controlados pela Microsoft ou em nome da Microsoft.

Recomendações sobre design

  • Use as chaves gerenciadas pelo serviço para a proteção dos dados sempre que possível, removendo a necessidade de gerenciar chaves de criptografia e lidar com tarefas operacionais, como a rotação de chaves.

    • Use apenas chaves gerenciadas pelo cliente quando houver um requisito regulatório claro para fazer isso.

  • Use o Azure Key Vault como um repositório seguro para todos os segredos, certificados e chaves se forem considerados mecanismos de criptografia adicionais ou chaves gerenciadas pelo cliente.

    • Provisione o Azure Key Vault com as políticas de exclusão temporária e de limpeza habilitadas para permitir a proteção de retenção para objetos excluídos.
    • Use o SKU do Azure Key Vault com backup de HSM para ambientes de produção de aplicativos.

  • Implante uma instância separada do Azure Key Vault em cada selo de implantação regional, fornecendo benefícios de isolamento de falhas e desempenho por meio da localização, bem como navegando nos limites de escala impostos por uma única instância de Key Vault.

    • Use uma instância dedicada do Azure Key Vault para recursos globais do aplicativo.

  • Siga um modelo de privilégios mínimos limitando a autorização para excluir permanentemente segredos, chaves e certificados para funções de Microsoft Entra personalizadas especializadas.

  • Verifique se as chaves de criptografia e os certificados armazenados em Key Vault são copiados em backup, fornecendo uma cópia offline no evento improvável Key Vault ficar indisponível.

  • Use Key Vault certificados para gerenciar a aquisição e a assinatura de certificados.

  • Estabeleça um processo automatizado para o revezamento de chave e certificado.

    • Automatize o processo de gerenciamento e renovação de certificados com autoridades de certificação públicas para facilitar a administração.
      • Defina alertas e notificações para complementar as renovações automatizadas de certificado.

  • Monitore a chave, o certificado e o uso do segredo.

    • Defina alertas para uso inesperado no Azure Monitor.

Governança controlada por políticas

As convenções de segurança só serão efetivas se forem aplicadas de maneira consistente e holística em todos os serviços de aplicativos e equipes. Azure Policy fornece uma estrutura para impor linhas de base de segurança e confiabilidade, garantindo a conformidade contínua com um critério de engenharia comum para um aplicativo crítico. Mais especificamente, Azure Policy forma uma parte fundamental do plano de controle do ARM (Azure Resource Manager), complementando o RBAC restringindo quais ações os usuários autorizados podem executar e podem ser usadas para impor convenções vitais de segurança e confiabilidade em serviços de plataforma utilizados.

Esta seção explorará, portanto, as principais considerações e recomendações em torno do uso de Azure Policy governança orientada para um aplicativo crítico, garantindo que as convenções de segurança e confiabilidade sejam continuamente impostas.

Considerações sobre o design

  • Azure Policy fornece um mecanismo para impulsionar a conformidade aplicando convenções de segurança e confiabilidade, como o uso de pontos de extremidade privados ou o uso de Zonas de Disponibilidade.

Observação

Ao implantar dentro de uma zona de destino do Azure, lembre-se de que a imposição de atribuições de política de linha de base centralizadas provavelmente será aplicada na implementação para grupos de gerenciamento de zona de destino e assinaturas.

  • Azure Policy pode ser usado para conduzir atividades de gerenciamento automatizado, como provisionamento e configuração.

    • Registro do Provedor de Recursos.
    • Validação e aprovação de configurações de recursos individuais do Azure.

  • Azure Policy escopo de atribuição determina a cobertura e o local das definições de Azure Policy informa a reutilização de políticas personalizadas.

  • Azure Policy tem vários limites, como o número de definições em qualquer escopo específico.

  • Pode levar vários minutos para que a execução de políticas DINE (Deploy If Not Exist) ocorra.

  • O Azure Policy fornece uma entrada crítica para relatórios de conformidade e auditoria de segurança.

Recomendações sobre design

  • Mapeie os requisitos regulatórios e de conformidade para as definições do Azure Policy.

    • Por exemplo, se houver requisitos de residência de dados, uma política deverá ser aplicada para restringir as regiões de implantação disponíveis.

  • Defina um critério de engenharia comum para capturar definições de configuração seguras e confiáveis para todos os serviços do Azure utilizados, garantindo que esses critérios sejam mapeados para Azure Policy atribuições para impor a conformidade.

    • Por exemplo, aplique uma Azure Policy para impor o uso de Zonas de Disponibilidade para todos os serviços relevantes, garantindo configurações confiáveis de implantação intra-região.

A implementação de referência de Missão Crítica contém uma ampla gama de políticas centradas em segurança e confiabilidade para definir e impor um exemplo de critérios comuns de engenharia.

  • Monitore o descompasso de configuração do serviço, em relação aos critérios comuns de engenharia, usando Azure Policy.

Para cenários críticos com várias assinaturas de produção em um grupo de gerenciamento dedicado, priorize as atribuições no escopo do grupo de gerenciamento.

  • Use políticas internas sempre que possível para minimizar a sobrecarga operacional da manutenção das definições de política personalizadas.

  • Quando forem necessárias definições de política personalizadas, verifique se as definições são implantadas no escopo adequado do grupo de gerenciamento para permitir a reutilização entre assinaturas de ambiente englobadas para permitir a reutilização da política em ambientes de produção e inferiores.

    • Ao alinhar o roteiro do aplicativo com os roteiros do Azure, use os recursos disponíveis da Microsoft para explorar se definições personalizadas críticas podem ser incorporadas como definições internas.

Observação

Ao implantar dentro de uma zona de destino do Azure, considere implantar definições de Azure Policy personalizadas no escopo do grupo de gerenciamento raiz da empresa intermediário para habilitar a reutilização em todos os aplicativos dentro da propriedade mais ampla do Azure. Em um ambiente de zona de destino, determinadas políticas de segurança centralizadas serão aplicadas por padrão em escopos de grupo de gerenciamento mais altos para impor a conformidade de segurança em todo o acervo do Azure. Por exemplo, as políticas do Azure devem ser aplicadas para implantar automaticamente as configurações de software por meio de extensões de VM e impor uma configuração de VM de linha de base em conformidade.

  • Use Azure Policy para impor um esquema de marcação consistente em todo o aplicativo.
    • Identifique as marcas do Azure necessárias e use o modo de política de acréscimo para impor o uso.

Se o aplicativo estiver inscrito no Suporte do Microsoft Mission-Critical, verifique se o esquema de marcação aplicado fornece um contexto significativo para enriquecer a experiência de suporte com uma compreensão profunda do aplicativo.

  • Exporte Microsoft Entra logs de atividades para o workspace global do Log Analytics usado pelo aplicativo.
    • Verifique se os logs de atividades do Azure são arquivados na Conta de Armazenamento global, juntamente com os dados operacionais para retenção de longo prazo.

Em uma zona de destino do Azure, Microsoft Entra logs de atividades também serão ingeridos no workspace centralizado do Log Analytics da plataforma. Ele precisará ser avaliado nesse caso se Microsoft Entra ID ainda forem necessários no workspace global do Log Analytics.

  • Integre as informações de segurança e gerenciamento de eventos ao Microsoft Defender para Nuvem (anteriormente conhecido como Central de Segurança do Azure).

Considerações específicas de IaaS ao usar Máquinas Virtuais

Em cenários em que o uso de IaaS Máquinas Virtuais é necessário, algumas especificidades precisam ser levadas em consideração.

Considerações sobre o design

  • As imagens não são atualizadas automaticamente uma vez implantadas.
  • Atualizações não são instalados automaticamente em VMs em execução.
  • Imagens e VMs individuais normalmente não são protegidas prontas para uso.

Recomendações sobre design

  • Não permita o acesso direto por meio da Internet pública para Máquinas Virtuais fornecendo acesso a SSH, RDP ou outros protocolos. Sempre use o Azure Bastion e jumpboxes com acesso limitado a um pequeno grupo de usuários.
  • Restrinja a conectividade direta com a Internet usando Grupos de Segurança de Rede, Firewall (Azure) ou Gateways de Aplicativo (Nível 7) para filtrar e restringir o tráfego de saída.
  • Para aplicativos de várias camadas, considere usar sub-redes diferentes e use Grupos de Segurança de Rede para restringir o acesso entre elas.
  • Priorize o uso da autenticação de Chave Pública, quando possível. Armazene segredos em um local seguro como o Key Vault do Azure.
  • Proteja as VMs usando autenticação e controle de acesso.
  • Aplique as mesmas práticas de segurança descritas para cenários de aplicativo críticos.

Siga e aplique práticas de segurança para cenários de aplicativos críticos, conforme descrito acima, quando aplicável, bem como as práticas recomendadas de segurança para cargas de trabalho de IaaS no Azure.

Próxima etapa

Examine as práticas recomendadas para procedimentos operacionais para cenários de aplicativo críticos.

Procedimentos operacionais