Compartilhar via

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

A segurança é um dos princípios fundamentais de design e também uma área de design chave 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 DDoS (negação-Of-Service) 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 essencial por natureza.

Também é importante observar que muitas vezes há compensações significativas associadas a uma postura de segurança protegida, particularmente no que diz respeito ao desempenho, à agilidade operacional e, em alguns casos, à confiabilidade. Por exemplo, a inclusão de NVA (Dispositivos Virtuais de Rede) embutidos para funcionalidades 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 intimamente 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 de missão crítica do Azure Well-Architected . Se você não estiver familiarizado com esta série, recomendamos começar com o que é uma carga de trabalho crítica?

Logotipo do GitHub Mission-Critical projeto de software livre

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 da Confiança Zero se esforçam para verificar explicitamente e continuamente cada transação, afirmar 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 é centrado na eliminação da confiança dentro e fora dos perímetros do aplicativo, impondo a verificação de qualquer coisa que tente se conectar ao sistema.

Considerações sobre o design

Ao avaliar a postura de segurança do aplicativo, comece com essas perguntas como base para cada consideração.

  • Teste de segurança contínua para validar mitigações das principais vulnerabilidades de segurança.

    • O teste de segurança é executado como parte de 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 uma postura de segurança desejada e ao modelo de ameaça?

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

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

  • Autenticação e continuidade da 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?

  • Escaneamento de segredos para detectar segredos antes que o código seja commitado, a fim de evitar vazamentos de segredos em 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 Vulnerabilidades e Exposições Comuns (CVEs) entre as dependências de pacotes utilizadas?
    • Há um processo automatizado para atualizar dependências de pacote?

  • Ciclos de vida de 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 seguro e confiável?

  • As ferramentas de CI/CD devem exigir que os principais de serviço do Microsoft Entra tenham acesso de nível de assinatura suficiente para facilitar o acesso ao plano de controle para implantações de recursos do Azure para 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 de design

  • Use o Azure Policy para impor configurações de segurança e confiabilidade para todos os serviços, garantindo que qualquer desvio seja corrigido ou proibido pelo plano de controle em tempo de configuração, ajudando a reduzir as ameaças associadas a cenários de "administrador mal-intencionado".

  • Utilize o Microsoft Entra Privileged Identity Management (PIM) em assinaturas de produção para revogar o acesso contínuo ao plano de controle em ambientes de produção. Isso reduzirá significativamente o risco de situações de "administrador mal-intencionado" por meio de adicionais "controles e equilíbrios".

  • Use as 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 o RBAC (controle de acesso baseado em função) do Microsoft Entra para autorização do plano de dados com todos os serviços que dão suporte à funcionalidade.

  • Use bibliotecas de autenticação de plataforma de identidade da Microsoft de primeira parte dentro do código do aplicativo para se integrar à ID do Microsoft Entra.

  • 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 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 automatizados de CI/CD para direcionar atualizações para todos os componentes da aplicação, mesmo em caso de falhas.

    • Verifique se as conexões de serviço de ferramentas de CI/CD são protegidas como informações confidenciais críticas e 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 manuais nos 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 implicar em um compromisso em termos de agilidade e devem ser cuidadosamente avaliados, considerando 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 da produção, particularmente no que diz respeito à exfiltração de dados, a menos que os requisitos regulatórios estipulem a necessidade de fazê-lo, pois isso compromete significativamente a agilidade do desenvolvedor.

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

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

  • Abrace 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 compatível para informar as aprovações de versão, sejam elas automatizadas ou manuais.
    • Aplique o teste 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 secreta 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 ameaças potenciais 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é mesmo caóticas. Essa complexidade e incerteza são por isso que as abordagens de segurança baseadas em requisitos de tecnologia tradicionais são em grande parte 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 compensatórias para ameaças modeladas, considerando as seguintes camadas defensivas.

  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ças.

  • Identidade falsificada: representação de indivíduos com autoridade. Por exemplo, um invasor se passando por outro usuário ao usar os dados do usuário –
    • Identidade
    • Autenticação
  • Entrada de adulteração: modificação da entrada enviada ao aplicativo ou violação dos limites de confiança para modificar o código do aplicativo. Por exemplo, um invasor usando 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 permissões
  • Repúdio à Ação: capacidade de refutar ações já tomadas e a capacidade do aplicativo de coletar evidências e impulsionar a responsabilização. Por exemplo, a exclusão de dados críticos sem a capacidade de rastrear até um administrador malicioso.
    • Auditoria/registro
    • Assinando
  • Divulgação de informações: obtendo acesso a informações restritas. Um exemplo seria um invasor obtendo acesso a um arquivo restrito.
    • Encriptação
    • Exfiltração dos dados
    • Ataques de intermediário
  • 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 o Slowloris.
    • DDoS
    • Botnets (redes de bots)
    • Funcionalidades de CDN e WAF
  • Elevação de privilégio: obtendo acesso privilegiado a aplicativos 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 de 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 gerar consistência em todas as equipes de serviço de aplicativo.

  • Comece com um serviço por modelagem de ameaças no nível do 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 dados englobados é vital para manter a disponibilidade e proteger a integridade dos dados.

Considerações sobre o design

  • A 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 micro segmentação e micro-perímetros de entrada/saída distribuídos.

  • Geralmente, os serviços de PaaS do Azure são acessados por meio de pontos de extremidade públicos. O Azure oferece capacidades para proteger endpoints públicos ou torná-los totalmente privados.

    • Os pontos de extremidade privados/link privado do Azure fornecem acesso dedicado a um recurso de PaaS do Azure usando endereços IP privados e conectividade de rede privada.
    • Os Endpoints de Serviço de Rede Virtual proporcionam acesso a partir de sub-redes selecionadas a serviços PaaS específicos.
    • A injeção de rede virtual fornece implantações privadas dedicadas para serviços compatíveis, como o Serviço de Aplicativo por meio de um Ambiente de 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, o Link Privado do Azure usando Pontos de Extremidade Privados do Azure aborda os riscos de exfiltração de dados associados aos Pontos de Extremidade de Serviço, como um administrador mal-intencionado escrevendo 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 compilação auto-hospedados privados desplegados em uma rede privada, podem ser usados como um recurso do Azure para agir como proxy e executar funções de CI/CD por meio de 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 dinamicamente durante a execução 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 privados do AKS.
    • Para realizar tarefas de desenvolvimento e administração no serviço de aplicativo, podem ser usadas as jump boxes.

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

  • Conexões de Serviço com um principal de serviço correspondente do Microsoft Entra podem ser usadas no Azure DevOps para aplicar o RBAC através do Microsoft Entra ID.

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

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

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

Recomendações de 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 às Máquinas Virtuais do Azure e executar tarefas administrativas no PaaS do Azure pela Internet.

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

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

    • Utilize a validação de ID do Cabeçalho para proteger endpoints de aplicativos públicos, aceitando apenas 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, exigem o uso do Firewall do Azure Premium ou NVA (Dispositivo Virtual de Rede), verifique se ele está configurado para máxima alta disponibilidade e redundância.

  • Se houver requisitos de captura de pacotes, utilize a funcionalidade de captura do Network Watcher, mesmo com a 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 intra-aplicativo.
    • Considere o uso do Azure Policy para garantir que regras específicas de NSG sejam sempre impostas às sub-redes de aplicativos.

  • Habilite os logs de fluxo do NSG e alimente-os na Análise de Tráfego para obter insights sobre fluxos de tráfego interno e externo.

  • Use o Link Privado do Azure/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 o Ponto de Extremidade de Serviço da Rede Virtual para proteger o acesso aos serviços de PaaS do Azure dentro de uma rede virtual.

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

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

Observação

Ao implantar dentro de 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 é um passo 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. Esta seção fornecerá, portanto, considerações e recomendações importantes relacionadas à criptografia e ao gerenciamento de chaves, a fim de 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 restrições aplicadas para cada cofre em um período específico.

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

    • As atribuições de política de acesso do Key Vault concedem permissões separadamente 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 que a função seja 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 Azure Key Vault 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 do Key Vault faça failover.

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

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

  • Um backup cria um instantâneo de um momento específico de um segredo, chave ou certificado, como um blob criptografado que não pode ser descriptografado fora do Azure. Para obter dados que podem ser usados do blob, ele deve ser restaurado em um Key Vault dentro da mesma assinatura do Azure e da mesma região geográfica 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 é movido entre data centers do Azure, a criptografia de camada de vínculo 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 de design

  • Use chaves gerenciadas pelo serviço para proteção de dados sempre que possível, removendo a necessidade de gerenciar chaves de criptografia e lidar com tarefas operacionais, como 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.

    • Configurar o Azure Key Vault com as políticas de exclusão suave e políticas de purga habilitadas para permitir a proteção de retenção para objetos excluídos.
    • Use o SKU do Azure Key Vault suportado por HSM para ambientes de produção de aplicativos.

  • Implante uma instância separada do Azure Key Vault em cada carimbo de implantação regional, proporcionando isolamento de falhas e benefícios de desempenho por meio da localização, além de contornar os limites de escala impostos por uma única instância do Key Vault.

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

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

  • Verifique se as chaves de criptografia e os certificados armazenados no Key Vault têm backup, fornecendo uma cópia offline no caso improvável de o Key Vault ficar indisponível.

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

  • Estabeleça um processo automatizado para rotação 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 de segredo.

    • Defina alertas para uso inesperado no Azure Monitor.

Governança orientada por políticas

As convenções de segurança só serão efetivas se forem aplicadas de forma consistente e holística em todos os serviços e equipes de aplicativos. O 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, o 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 da governança orientada pelo Azure Policy para um aplicativo crítico, garantindo que as convenções de segurança e confiabilidade sejam continuamente impostas.

Considerações sobre o design

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

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

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

  • O 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 de 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 utilizados do Azure, garantindo que esses critérios sejam mapeados para atribuições do Azure Policy para impor a conformidade.

    • Por exemplo, aplique um 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 desvio da configuração do serviço em relação aos critérios comuns de engenharia usando Azure Policy.

Para cenários de missão crítica com várias assinaturas de serviços 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 de definições de política personalizadas.

  • Quando as definições de política personalizadas forem necessárias, 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 personalizadas do Azure Policy no escopo do grupo de gerenciamento raiz da empresa intermediária 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 dentro de escopos de grupo de gerenciamento mais altos para impor a conformidade de segurança em toda a propriedade 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 compatível.

  • Use o Azure Policy para impor um esquema de marcação consistente em todo o aplicativo.
    • Identifique os tags exigidos do Azure 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 compreensão profunda do aplicativo.

  • Exporte os logs de atividades do Microsoft Entra 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 dados operacionais para retenção de longo prazo.

Em uma zona de aterrissagem do Azure, os logs de atividades do Microsoft Entra também serão ingeridos no workspace centralizado da plataforma Log Analytics. É necessário avaliar nesse caso se o Microsoft Entra ID ainda é necessário no espaço de trabalho global do Log Analytics.

  • Integre 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 Máquinas Virtuais IaaS é necessário, algumas especificidades precisam ser levadas em consideração.

Considerações sobre o design

  • As imagens não são atualizadas automaticamente depois de implantadas.
  • As atualizações não são instaladas automaticamente para a execução de VMs.
  • As imagens e as VMs individuais normalmente não são endurecidas como padrão.

Recomendações de design

  • Não permita o acesso direto por meio da Internet pública às 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 usar 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 Azure Key Vault.
  • 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 aplicativo 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