Considerações de segurança para cargas de trabalho de missão crítica no Azure

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

Dado que o foco principal de um design de missão crítica é maximizar a confiabilidade para que o aplicativo permaneça eficiente 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 prejudicar a confiabilidade geral. Por exemplo, ataques de negação de serviço (DDoS) bem-sucedidos são conhecidos por terem um impacto catastrófico na disponibilidade e no desempenho. Como um aplicativo mitiga esses vetores de ataque, como o SlowLoris afetará a confiabilidade geral. Portanto, o aplicativo deve ser totalmente protegido contra ameaças destinadas a comprometer direta ou indiretamente a confiabilidade do aplicativo para ser realmente de missão crítica por natureza.

Também é importante notar que muitas vezes há compensações significativas associadas a uma postura de segurança reforçada, particularmente no que diz respeito ao desempenho, agilidade operacional e, em alguns casos, confiabilidade. Por exemplo, a inclusão de dispositivos virtuais de rede em linha (NVA) para recursos de Firewall de Próxima Geração (NGFW), 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 as do aplicativo. Portanto, é essencial que componentes e práticas de segurança adicionais destinados a mitigar vetores de ameaças importantes também sejam projetados para oferecer suporte ao alvo de confiabilidade de um aplicativo, o que constituirá um aspecto fundamental das recomendações e considerações apresentadas nesta seção.

Importante

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

Projeto de código aberto de missão crítica

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 Zero Trust para estruturar e orientar a abordagem de design e implementação de segurança.

Alinhamento com o modelo Zero Trust

O modelo Microsoft Zero Trust fornece uma abordagem proativa e integrada para aplicar a segurança em todas as camadas de um aplicativo. Os princípios orientadores da Zero Trust se esforçam para verificar explícita 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, centra-se 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.

• Testes de segurança contínuos para validar mitigações para as principais vulnerabilidades de segurança.

  • Os testes de segurança são realizados como parte de processos automatizados de CI/CD?
  • Em caso negativo, com que frequência são realizados testes de segurança específicos?
  • Os resultados dos testes são medidos em relação a uma postura de segurança e a um modelo de ameaça desejados?

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

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

• Varredura secreta para detectar segredos antes que o código seja confirmado para evitar vazamentos secretos através de repositórios de código-fonte.

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

• Proteger a cadeia de fornecimento de software.

  • É possível rastrear CVEs (Common Vulnerabilities and Exposures) dentro das dependências do pacote utilizado?
  • Existe um processo automatizado para atualizar as dependências do pacote?

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

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

• As ferramentas de CI/CD devem exigir entidades de serviço do Microsoft Entra com acesso de nível de assinatura suficiente para facilitar o acesso do plano 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 do 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 compilação 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 Microsoft Entra Privileged Identity Management (PIM) em assinaturas de produção para revogar o acesso de plano de controle sustentado a ambientes de produção. Isso reduzirá significativamente o risco representado por cenários de "administradores mal-intencionados" por meio de "freios e contrapesos" adicionais.

• Use as Identidades Gerenciadas do Azure para todos os serviços que oferecem suporte ao recurso, pois 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 para serviço.

• Use o controle de acesso baseado em função (RBAC) 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 no código do aplicativo para integrar com o 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 de 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.
  • Normalmente, o cache de token é manipulado automaticamente por bibliotecas de autenticação (como MSAL).

• Use IaC (Infraestrutura como código) e pipelines automatizados de CI/CD para gerar atualizações para todos os componentes do aplicativo, inclusive 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 portas de aprovação manuais nos pipelines de implantação de produção para reduzir ainda mais os riscos de "administração mal-intencionada" e fornecer garantia técnica adicional para todas as alterações de produção.
    • Portões de segurança adicionais podem ser compensados 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, especialmente no que diz respeito à exfiltração de dados, a menos que os requisitos regulamentares estipulem 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 a Política do Azure para impor a conformidade.
  • Habilite o Azure Defender para todos os serviços que oferecem suporte ao recurso.

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

  • Os resultados dos testes devem ser medidos em relação a uma postura de segurança compatível para informar as aprovações de liberaçã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, garanta que uma cadência de teste de segurança adequada seja aplicada.

• Habilite a varredura secreta e a varredura 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. Existem 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 é o motivo pelo qual as abordagens tradicionais de segurança baseadas em requisitos de tecnologia são em grande parte inadequadas para aplicativos de nuvem de missão crítica. Espere que o processo de modelagem de ameaças para um aplicativo de missão crítica seja complexo e inflexível.

Para ajudar a enfrentar esses desafios, uma abordagem de defesa em profundidade em camadas deve ser aplicada para definir e implementar mitigações compensatórias para ameaças modeladas, considerando as seguintes camadas defensivas.

1. A plataforma Azure com recursos e controles de segurança básicos.
2. A arquitetura do aplicativo e o design de segurança.
3. Recursos de segurança internos, habilitados e implantáveis aplicados para proteger os recursos do Azure.
4. Código da aplicação e lógica de segurança.
5. Processos operacionais e DevSecOps.

Observação

Ao implantar em uma zona de aterrissagem do Azure, esteja ciente 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 aterrissagem.

Considerações sobre o design

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

• Identidade Falsificada: Personificação de indivíduos com autoridade. Por exemplo, um invasor se passando por outro usuário usando seu -
  • Identidade
  • Autenticação
• Entrada de violação: modificação da entrada enviada ao aplicativo ou a quebra 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 bloqueio/permissão
• Repúdio à Ação: Capacidade de refutar ações já tomadas e a capacidade do aplicativo de reunir provas e conduzir a responsabilização. Por exemplo, a exclusão de dados críticos sem a capacidade de rastrear para um administrador mal-intencionado.
  • Auditoria/registro em log
  • Assinando
• Divulgação de Informações: Obtenção de acesso a informações restritas. Um exemplo seria um invasor obtendo acesso a um arquivo restrito.
  • Criptografia
  • Exfiltração dos dados
  • Ataques man-in-the-middle
• Negação de Serviço: interrupção de aplicativos mal-intencionados para degradar a experiência do usuário. Por exemplo, um ataque de botnet DDoS como o Slowloris.
  • DDoS
  • Botnets
  • Recursos 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 sobre design

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

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

• Comece com um serviço por modelagem de ameaça de 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

• O Zero Trust assume um estado violado e verifica cada solicitação como se ela se originasse de uma rede não controlada.

  • 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.
  • Os Pontos de Extremidade de Serviço de Rede Virtual fornecem acesso de nível de serviço de sub-redes selecionadas a serviços de PaaS selecionados.
  • A Injeção de Rede Virtual fornece implantações privadas dedicadas para serviços com suporte, como o 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, 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 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 compilação privados auto-hospedados implantados em uma rede privada como 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 compilação.
    • A conectividade com os agentes de compilação privados a partir de 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 de DevOps do Azure, com o firewall posteriormente removido 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 no serviço do aplicativo, caixas de salto podem ser usadas.

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

• As Conexões de Serviço com uma entidade de serviço correspondente do Microsoft Entra podem ser usadas no Azure DevOps para aplicar o RBAC por meio da ID do Microsoft Entra.

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

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

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

Recomendações sobre design

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

  • Use o Link Privado do Azure para estabelecer pontos de extremidade privados para recursos do Azure que exigem integração de rede segura.
  • Use agentes de compilação privados hospedados para ferramentas de CI/CD para implantar e configurar recursos do Azure protegidos pelo Link Privado do Azure.
    • Os agentes hospedados pela Microsoft não poderão se conectar diretamente aos recursos integrados à rede.

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

  • Use o Bastião do Azure para fornecer acesso seguro às Máquinas Virtuais do Azure e para executar tarefas administrativas na PaaS do Azure pela Internet.

• Use um plano de proteção padrão contra 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 profunda de pacotes ou inspeção TLS, exigirem o uso do Azure Firewall Premium ou do Network Virtual Appliance (NVA), verifique se ele está configurado para máxima alta disponibilidade e redundância.

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

• Use Grupos de Segurança de Rede e Grupos de Segurança de Aplicativo para microsegmentar o tráfego de aplicativos.

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

• 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 Pontos de Extremidade do Serviço de Rede Virtual 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 aterrissagem do Azure, esteja ciente de que a conectividade de rede com data centers locais é fornecida pela implementação da zona de aterrissagem. Uma abordagem é usar a Rota Expressa configurada com emparelhamento privado.

Proteção da integridade dos 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. Esta seção fornecerá, portanto, as principais considerações e recomendações 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 Cofre de Chaves do Azure 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.
    • Permissões granulares no nível de objeto para uma chave, segredo ou certificado específico agora são possíveis.

• 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 Cofre de Chaves do Azure têm validação FIPS 140.

  • Um HSM gerenciado pelo Cofre de Chaves do Azure dedicado está disponível para cenários que exigem conformidade com FIPS 140-2 Nível 3.

• O Cofre de Chaves 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 Cofre de Chaves faça failover.

  • Durante um failover, o Cofre de Chaves 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 Cofre de Chaves do Azure, pode levar até 20 minutos para que a conexão seja restabelecida durante um failover regional.

• Um backup cria um instantâneo point-in-time 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 Cofre de Chaves dentro da mesma assinatura do Azure e da mesma geografia do Azure.

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

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

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

• Quando o tráfego se move entre os data centers do Azure, a criptografia de camada de link de dados MACsec é usada no hardware de rede subjacente para proteger os 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 chaves gerenciadas pelo cliente somente quando houver um requisito normativo claro para fazê-lo.

• Use o Cofre de Chaves do Azure como um repositório seguro para todos os segredos, certificados e chaves se mecanismos de criptografia adicionais ou chaves gerenciadas pelo cliente precisarem ser considerados.

  • 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 Cofre de Chaves do Azure com suporte do HSM para ambientes de produção de aplicativos.

• Implante uma instância separada do Cofre de Chaves do Azure em cada carimbo de implantação regional, fornecendo isolamento de falhas e benefícios de desempenho por meio da localização, além de navegar pelos limites de escala impostos por uma única instância do Cofre de Chaves.

  • Use uma instância dedicada do Cofre de Chaves do Azure 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 personalizadas especializadas do Microsoft Entra.

• Certifique-se de que as chaves de criptografia e os certificados armazenados no Cofre de Chaves sejam copiados, fornecendo uma cópia offline no caso improvável de o Cofre de Chaves ficar indisponível.

• Use os certificados do Key Vault 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 certificados.

• 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. A Política do Azure fornece uma estrutura para impor linhas de base de segurança e confiabilidade, garantindo a conformidade contínua com critérios de engenharia comuns para um aplicativo de missão crítica. Mais especificamente, a Política do Azure constitui uma parte fundamental do plano de controle do Gerenciador de Recursos do Azure (ARM), complementando o RBAC restringindo quais ações os usuários autorizados podem executar e pode ser usada para impor convenções vitais de segurança e confiabilidade nos serviços de plataforma utilizados.

Esta seção irá, portanto, explorar as principais considerações e recomendações em torno do uso da governança orientada pela Política do Azure para um aplicativo de missão crítica, garantindo que as convenções de segurança e confiabilidade sejam aplicadas continuamente.

Considerações sobre o design

• A Política do Azure fornece um mecanismo para impulsionar a conformidade impondo 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 em uma zona de aterrissagem do Azure, esteja ciente de que a imposição de atribuições de política de linha de base centralizadas provavelmente será aplicada na implementação para grupos e assinaturas de gerenciamento de zona de aterrissagem.

• A Política do Azure pode ser usada para impulsionar 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 da Política do Azure determina a cobertura e o local das definições da Política do Azure informa a reutilização de políticas personalizadas.

• A Política do Azure 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 diretivas Implantar se não existir (DINE) 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 atribuições de Política do Azure para impor a conformidade.

  • Por exemplo, aplique uma Política do Azure para impor o uso de Zonas de Disponibilidade para todos os serviços relevantes, garantindo configurações de implantação intrarregionais confiáveis.

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

• Monitore o desvio de configuração do serviço, em relação aos critérios comuns de engenharia, usando a Política do Azure.

Para cenários de missão crítica 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 as definições de política personalizadas forem necessárias, certifique-se de que as definições sejam implantadas no escopo adequado do grupo de gerenciamento para permitir a reutilização em ambientes englobados, de modo a permitir a reutilização de políticas 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 em uma zona de aterrissagem do Azure, considere implantar Definições de Política do Azure personalizadas no escopo intermediário do grupo de gerenciamento raiz da empresa para permitir a reutilização em todos os aplicativos no estado mais amplo do Azure. Em um ambiente de zona de aterrissagem, determinadas políticas de segurança centralizadas serão aplicadas por padrão nos escopos de grupo de gerenciamento superior para impor a conformidade de segurança em todo o estado do Azure. Por exemplo, as políticas do Azure devem ser aplicadas para implantar automaticamente 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 a Política do Azure para impor um esquema de marcação consistente no 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 de Missão Crítica da Microsoft, certifique-se de que o esquema de marcação aplicado forneça 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.
  • Certifique-se de que os logs de atividade do Azure sejam arquivados na Conta de Armazenamento global, juntamente com os dados operacionais para retenção de longo prazo.

Em uma zona de aterrissagem do Azure, os logs de atividade do Microsoft Entra também serão ingeridos no espaço de trabalho centralizado do Log Analytics da plataforma. Nesse caso, ele precisa ser avaliado se a ID do Microsoft Entra ainda for necessária no espaço de trabalho 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 máquinas virtuais IaaS é necessário, algumas especificidades devem 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 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 através da Internet pública a Máquinas Virtuais, fornecendo acesso a SSH, RDP ou outros protocolos. Sempre use o Bastião do Azure 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 o uso de sub-redes diferentes e use Grupos de Segurança de Rede para restringir o acesso entre eles.
• Priorize o uso da autenticação de Chave Pública, quando possível. Armazene segredos em um local seguro como o Cofre de Chaves do Azure.
• Proteja VMs usando autenticação e controle de acesso.
• Aplique as mesmas práticas de segurança descritas para cenários de aplicativos de missão crítica.

Siga e aplique práticas de segurança para cenários de aplicativos de missão crítica, 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

Revise as práticas recomendadas para procedimentos operacionais para cenários de aplicativos de missão crítica.

Procedimentos operacionais