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-chave do projeto 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 projeto 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, os ataques de negação de serviço (DDoS) bem-sucedidos são conhecidos por terem um impacto catastrófico na disponibilidade e no desempenho. A forma como um aplicativo atenua 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 verdadeiramente 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 (NVA) em linha 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 os principais vetores de ameaças também sejam projetados para dar suporte ao alvo de confiabilidade de um aplicativo, o que formará um aspeto 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 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 o design de segurança e a abordagem de implementação.

Alinhamento com o modelo Zero Trust

O modelo Microsoft Zero Trust fornece uma abordagem proativa e integrada para aplicar segurança em todas as camadas de um aplicativo. Os princípios orientadores do Zero Trust se esforçam para verificar explícita e continuamente cada transação, afirmar o menor privilégio, usar inteligência e deteçã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 de 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 atenuaçõ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 desejada e a um modelo de ameaça?

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

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

  • É possível detetar alterações nas principais configurações de segurança?
  • As respostas para corrigir alterações não conformes são automatizadas?

• Varredura secreta para detetar segredos antes que o código seja confirmado para evitar vazamentos secretos por meio de repositórios de código-fonte.

  • A autenticação em 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) dentro das dependências de pacotes utilizadas?
  • Existe um processo automatizado para atualizar as dependências do pacote?

• Ciclos de vida das chaves de proteção de dados.

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

• As ferramentas de CI/CD devem exigir entidades de serviço do Microsoft Entra com acesso suficiente ao nível da subscrição para facilitar o acesso do plano de controlo para implementações de recursos do Azure a todas as subscrições de ambiente consideradas.

  • Quando os recursos do aplicativo são bloqueados em redes privadas, existe 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 dos agentes de compilação privados necessários.

Recomendações de design

• Use a Política do Azure 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 no momento da configuração, ajudando a mitigar 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 sustentado do plano de controle aos ambientes de produção. Isso reduzirá significativamente o risco representado por cenários de "administração mal-intencionada" por meio de "freios e contrapesos" adicionais.

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

• Use bibliotecas de autenticação de plataforma de identidade Microsoft de primeira parte dentro do 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 conseguir 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 é manipulado automaticamente por bibliotecas de autenticação (como MSAL).

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

  • Certifique-se de que as conexões de serviço de ferramentas de CI/CD estejam protegidas como informações confidenciais críticas e não estejam disponíveis diretamente para nenhuma equipe de serviço.
  • Aplique RBAC granular aos pipelines de CD de produção para mitigar os riscos de "administração mal-intencionada".
  • Considere o uso de portas de aprovação manuais nos pipelines de implantação de produção para mitigar 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 vir em um compromisso em termos de agilidade e devem ser cuidadosamente avaliados, com consideração de 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 mitigadas.

  • Não aplique a mesma postura de segurança que a produção, particularmente 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 for Cloud (anteriormente conhecido como Central de Segurança do Azure) para todas as assinaturas que contêm os recursos para uma carga de trabalho de missão 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 ensaios devem ser medidos em função de uma postura de segurança conforme para fundamentar as aprovações de libertaçã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 os testes de segurança de cada versão comprometerem a agilidade operacional, certifique-se de que uma cadência de teste de segurança adequada seja aplicada.

• Habilite a varredura secreta e a verificação de dependência dentro do repositório de código-fonte.

Modelação 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-se de formas inesperadas, imprevisíveis e até caóticas. Essa complexidade e incerteza é o motivo pelo qual as abordagens de segurança tradicionais 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 navegar nesses desafios, uma abordagem de defesa em camadas profunda 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 fundamentais.
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 de aplicação e lógica de segurança.
5. Processos operacionais e DevSecOps.

Nota

Ao implantar em uma zona de aterrissagem 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 aterrissagem.

Considerações de design

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

• Identidade Falsificada: Personificação de indivíduos com autoridade. Por exemplo, um invasor se passando por outro usuário usando seus -
  • Identidade
  • Autenticação
• Entrada de violação: modificação da entrada enviada para o aplicativo ou a quebra de 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 dos dados
  • Validação
  • Lista de bloqueio/lista de permissões
• Repúdio à Ação: Capacidade de refutar ações já tomadas e a capacidade do aplicativo de reunir provas e impulsionar a responsabilização. Por exemplo, a exclusão de dados críticos sem a capacidade de rastrear um administrador mal-intencionado.
  • Auditoria/registo
  • Assinatura de
• Divulgação de informações: Obter acesso a informações restritas. Um exemplo seria um invasor obtendo acesso a um arquivo restrito.
  • Encriptação
  • Transferência de dados não autorizada
  • 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: obter 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 dentro de cada sprint para avaliar novas ameaças potenciais 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 gerar 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ões na rede

Impedir o acesso não autorizado a um aplicativo de missão crítica e a dados englobados é vital para manter a disponibilidade e proteger a integridade dos dados.

Considerações de design

• O Zero Trust assume um estado violado e verifica cada solicitação como se fosse originária de uma rede não controlada.

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

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

  • Os Pontos de Extremidade Privados do Azure Private Link fornecem acesso dedicado a um recurso 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 para serviços PaaS selecionados.
  • A Injeção de Rede Virtual fornece implantações privadas dedicadas para serviços suportados, 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 através de endereços IP públicos.

• Para serviços suportados, o Azure Private Link usando os 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 de rede aos serviços 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.

  • Os agentes de compilação privados auto-hospedados implantados em uma rede privada como o recurso do Azure podem ser usados 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.
    • É necessária conectividade com os agentes de compilação privados a partir de ferramentas de CI/CD.
  • 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 subsequentemente 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 de aplicativo, caixas de salto podem ser usadas.

• A conclusão de 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 Etiquetas de Serviço podem ser aplicadas a Grupos de Segurança de Rede para facilitar a conectividade com os serviços PaaS do Azure.

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

• A captura de pacotes no Azure Network Watcher é 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 cumpra seu objetivo comercial de reduzir a superfície de ataque externo.

  • Use o Azure Private Link 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 Azure Private Link.
    • Os agentes hospedados pela Microsoft não poderão se conectar diretamente aos recursos integrados à rede.

• Ao lidar com agentes de compilação 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 para executar tarefas administrativas no Azure PaaS 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 de firewall de aplicativos Web para fornecer 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 aplicativos públicos para que eles só aceitem tráfego originado 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 Firewall do Azure Premium ou do Network Virtual Appliance (NVA), certifique-se de que ele esteja configurado para máxima alta disponibilidade e redundância.

• Se existirem requisitos de captura de pacotes, use os 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 Aplicativos para microsegmentar o tráfego de aplicativos.

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

• Habilite os logs de fluxo do NSG e alimente-os no Traffic Analytics para obter informações sobre os fluxos de tráfego internos e externos.

• Use o Azure Private Link/Private Endpoints, 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 que dão suporte ao Link Privado, consulte 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 os Pontos de Extremidade do Serviço de Rede Virtual para proteger o acesso aos serviços PaaS do Azure de 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 aplicativos híbridos, acesse os serviços PaaS do Azure no local por meio da Rota Expressa com emparelhamento privado.

Nota

Ao implantar em uma zona de aterrissagem do Azure, lembre-se 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 é um passo vital para garantir a integridade dos dados e, em última análise, é um dos recursos de segurança mais importantes que podem ser aplicados para mitigar 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 de 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, uma vez que as permissões de acesso para chaves, segredos e certificados são aplicadas em um nível de cofre.

  • As atribuições da política de acesso ao Cofre da Chave concedem permissões separadamente para chaves, segredos ou certificados.
    • Permissões granulares no nível do 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 que a função seja aplicada.

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

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

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

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

  • Durante um failover, o Cofre de Chaves estará em 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, eles devem ser restaurados em um Cofre da Chave 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 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 centros de dados do Azure, a encriptação de camada de ligação de dados MACsec é utilizada 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 de design

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

  • Use chaves gerenciadas pelo cliente somente quando houver um requisito regulatório claro para fazê-lo.

• Use o Azure Key Vault 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 e limpeza suaves habilitadas para permitir a proteção de retenção para objetos excluídos.
  • Use o Azure Key Vault SKU apoiado 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, fornecendo isolamento de falhas e benefícios de desempenho por meio da localização, bem como navegando pelos 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égios mínimos, limitando a autorização para excluir permanentemente segredos, chaves e certificados a funções personalizadas especializadas do Microsoft Entra.

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

• Use certificados do Cofre de Chaves para gerenciar a aquisição e assinatura de certificados.

• Estabeleça um processo automatizado para rotação de chaves e certificados.

  • 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 o uso de chaves, certificados e segredos.

  • Defina alertas para uso inesperado no Azure Monitor.

Governação orientada por políticas

Em última análise, as convenções de segurança só são eficazes se forem aplicadas de forma consistente e holística em todos os serviços e equipes de aplicativos. A Política do Azure 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 de missão crítica. Mais especificamente, a Política do Azure constitui uma parte fundamental do plano de controle do Azure Resource Manager (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 de design

• A Política do Azure 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.

Nota

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.

  • Registo do Fornecedor 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 dita a cobertura e o local das definições da Política do Azure informa a reutilização de 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 diretivas Deploy If Not Exist (DINE) ocorra.

• A Política do Azure 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 da Política do Azure.

  • Por exemplo, se houver requisitos de residência de dados, uma política deve 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 esse critério seja mapeado 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 confiáveis de implantação dentro da 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 aplicar um exemplo de critérios comuns de engenharia.

• Monitore o desvio de configuração do serviço, relativo 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 de manter definições de políticas 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 assinaturas de ambiente englobadas, permitindo 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.

Nota

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 habilitar a reutilização em todos os aplicativos dentro do conjunto 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 patrimônio 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 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 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 profundo conhecimento do aplicativo.

• Exporte os logs de atividade do Microsoft Entra para o espaço de trabalho 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 atividades do Microsoft Entra também serão ingeridos no espaço de trabalho centralizado do Log Analytics da plataforma. Neste caso, ele precisa ser avaliado se o Microsoft Entra ID ainda for necessário no espaço de trabalho global do Log Analytics.

• Integre informações de segurança e gerenciamento de eventos com o Microsoft Defender for Cloud (anteriormente conhecido como Central de Segurança do Azure).

Considerações específicas de IaaS ao usar máquinas virtuais

Em cenários onde o uso de máquinas virtuais IaaS é necessário, algumas especificidades devem ser levadas em consideração.

Considerações de design

• As imagens não são atualizadas automaticamente após a implantação.
• As atualizações não são instaladas automaticamente em VMs em execução.
• Imagens e VMs individuais normalmente não são reforçadas prontamente.

Recomendações de 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. Use sempre 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 Aplicativos (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 Azure Key Vault.
• 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 IaaS no Azure.

Próximo passo

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

Procedimentos operacionais