Considerações de segurança para cargas de trabalho fundamentais para a missão no Azure

A segurança é um dos princípios fundamentais do design e também uma área de design fundamental que deve ser tratada como uma preocupação de primeira classe no âmbito do processo de arquitetura crítico para a missão.

Dado que o foco principal de um design crítico para a missão é maximizar a fiabilidade para que a aplicação permaneça com desempenho e disponível, as considerações e recomendações de segurança aplicadas nesta área de design irão focar-se na mitigação de ameaças com a capacidade de afetar a disponibilidade e dificultar a fiabilidade global. Por exemplo, os ataques Denial Of Service (DDoS) bem-sucedidos têm um impacto catastrófico na disponibilidade e no desempenho. A forma como uma aplicação mitiga esses vetores de ataque, como SlowLoris, afetará a fiabilidade geral. Assim, a aplicação tem de estar totalmente protegida contra ameaças destinadas a comprometer direta ou indiretamente a fiabilidade da aplicação para ser verdadeiramente fundamental para a natureza.

Também é importante ter em atenção que muitas vezes existem compromissos significativos associados a uma postura de segurança reforçada, especialmente no que diz respeito ao desempenho, à agilidade operacional e, em alguns casos, à fiabilidade. Por exemplo, a inclusão de Aplicações Virtuais de Rede (NVA) inline para capacidades de Firewall de Próxima Geração (NGFW), como a inspeção de pacotes profunda, introduzirá uma penalização de desempenho significativa, complexidade operacional adicional e um risco de fiabilidade se as operações de escalabilidade e recuperação não estiverem estreitamente alinhadas com a da aplicação. Por conseguinte, é essencial que os componentes e práticas de segurança adicionais destinados a mitigar vetores de ameaças principais também sejam concebidos para suportar o destino de fiabilidade de uma aplicação, o que constituirá um aspeto fundamental das recomendações e considerações apresentadas nesta secção.

Importante

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

Projeto de open source Crítico para a Missão do

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

Alinhamento com o modelo de Confiança Zero

O modelo microsoft Confiança Zero fornece uma abordagem proativa e integrada para aplicar segurança em todas as camadas de uma aplicação. Os princípios de orientação do Confiança Zero esforçam-se por verificar explicitamente e continuamente cada transação, afirmar o menor privilégio, utilizar 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 das aplicações, ao impor a verificação de tudo o que tentar ligar ao sistema.

Considerações de design

À medida que avalia a postura de segurança da aplicação, comece com estas perguntas como base para cada consideração.

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

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

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

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

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

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

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

  • Podem ser detetadas alterações às principais definições de segurança?
  • As respostas para remediar alterações não conformes são automatizadas?

• Análise de segredos para detetar segredos antes de o código ser consolidado para evitar fugas de segredos através de repositórios de código fonte.

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

• Proteger a cadeia de fornecimento de software.

  • É possível controlar Vulnerabilidades e Exposições Comuns (CVEs) nas 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 geridas pelo serviço podem ser utilizadas para a proteção da integridade dos dados?
  • Se forem necessárias chaves geridas pelo cliente, como é que o ciclo de vida das chaves é seguro e fiável?

• As ferramentas CI/CD devem exigir Microsoft Entra principais de serviço com acesso ao nível da subscrição suficiente 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 da aplicação são bloqueados em redes privadas, existe um caminho de conectividade de plano de dados privado para que as ferramentas CI/CD possam efetuar implementações e manutenção ao nível da aplicação.
    • Isto introduz complexidade adicional e requer uma sequência dentro do processo de implementação através de agentes de compilação privados necessários.

Recomendações de conceção

• Utilize Azure Policy para impor configurações de segurança e fiabilidade para todos os serviços, garantindo que qualquer desvio é remediado ou proibido pelo plano de controlo no momento da configuração, ajudando a mitigar ameaças associadas a cenários de "administrador malicioso".

• Utilize Microsoft Entra Privileged Identity Management (PIM) em subscrições de produção para revogar o acesso do plano de controlo sustentado a ambientes de produção. Isto reduzirá significativamente o risco colocado de cenários de "administrador malicioso" através de "verificações e saldos" adicionais.

• Utilize as Identidades Geridas do Azure para todos os serviços que suportam a capacidade, uma vez que facilita a remoção de credenciais do código da aplicação e remove a carga operacional da gestão de identidades para a comunicação serviço a serviço.

• Utilize Microsoft Entra controlo de acesso baseado em funções (RBAC) para autorização do plano de dados com todos os serviços que suportam a capacidade.

• Utilize bibliotecas de autenticação de plataforma de identidades da Microsoft originais no código da aplicação para integrar com Microsoft Entra ID.

• Considere a colocação em cache segura de tokens 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 aplicação.

  • Se o fornecedor não conseguir emitir novos tokens de acesso, mas continuar a validar os existentes, a aplicação e os serviços dependentes podem funcionar sem problemas até que os tokens expirem.
  • Normalmente, a colocação em cache de tokens é processada automaticamente por bibliotecas de autenticação (como a MSAL).

• Utilize os pipelines De Infraestrutura como Código (IaC) e CI/CD automatizados para impulsionar atualizações para todos os componentes da aplicação, incluindo em circunstâncias de falha.

  • Confirme que as ligações do serviço de ferramentas CI/CD são salvaguardadas como informações confidenciais críticas e que não devem estar diretamente disponíveis para nenhuma equipa de serviço.
  • Aplique o RBAC granular aos pipelines de CD de produção para mitigar os riscos de "administrador malicioso".
  • Considere a utilização de portas de aprovação manual nos pipelines de implementação de produção para mitigar ainda mais os riscos de "administrador malicioso" e fornecer garantia técnica adicional para todas as alterações de produção.
    • As portas de segurança adicionais podem ser trocadas em termos de agilidade e devem ser cuidadosamente avaliadas, tendo em conta a forma como a agilidade pode ser mantida mesmo com portas manuais.

• Defina uma postura de segurança adequada para todos os ambientes mais baixos para garantir que as vulnerabilidades principais são mitigadas.

  • Não aplique a mesma postura de segurança que a produção, especialmente no que diz respeito à transferência de dados não autorizada, a menos que os requisitos regulamentares estipulem a necessidade de o fazer, uma vez que isso comprometerá significativamente a agilidade do programador.

• Ative o Microsoft Defender para a Cloud (anteriormente conhecido como Centro de Segurança do Azure) para todas as subscrições que contêm os recursos para uma carga de trabalho crítica para a missão.

  • Utilize Azure Policy para impor a conformidade.
  • Ative o Azure Defender para todos os serviços que suportam a capacidade.

• Abrace 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 lançamento, 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 é aplicada uma cadência de teste de segurança adequada.

• Ative a análise de segredos e a análise de dependências no repositório de código fonte.

Modelação de ameaças

A modelação de ameaças fornece uma abordagem baseada no risco para a conceção de segurança, utilizando potenciais ameaças identificadas para desenvolver mitigações de segurança adequadas. 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. Esta complexidade e incerteza é a razão pela qual as abordagens de segurança baseadas em requisitos de tecnologia tradicionais são em grande parte inadequadas para aplicações na cloud fundamentais para a missão. Espera-se que o processo de modelação de ameaças para uma aplicação crítica para a missão seja complexo e inflexível.

Para ajudar a navegar nestes desafios, deve ser aplicada uma abordagem de defesa em camadas aprofundada para definir e implementar mitigações de compensação para ameaças modeladas, tendo em conta as seguintes camadas defensivas.

1. A plataforma do Azure com capacidades e controlos de segurança fundamentais.
2. A arquitetura da aplicação e a estrutura de segurança.
3. Funcionalidades de segurança incorporadas, ativadas e implementáveis aplicadas para proteger os recursos do Azure.
4. Código da aplicação e lógica de segurança.
5. Processos operacionais e DevSecOps.

Nota

Ao implementar dentro de uma zona de destino do Azure, tenha em atenção que uma camada adicional de mitigação de ameaças através do aprovisionamento de capacidades de segurança centralizadas é fornecida pela implementação da zona de destino.

Considerações de design

O STRIDE fornece uma arquitetura de risco simples para avaliar ameaças de segurança entre vetores de ameaças principais.

• Identidade Falsificada: representação de indivíduos com autoridade. Por exemplo, um atacante a representar outro utilizador com o respetivo -
  • Identidade
  • Autenticação
• Entrada de Adulteração: modificação da entrada enviada para a aplicação ou violação dos limites de fidedignidade para modificar o código da aplicação. Por exemplo, um atacante que utiliza a Injeção de SQL para eliminar dados numa tabela de base de dados.
  • Integridade dos dados
  • Validação
  • Lista de bloqueios/lista de permissões
• Rejeição da Ação: capacidade de refutar ações já tomadas e a capacidade da aplicação de reunir provas e impulsionar a responsabilidade. Por exemplo, a eliminação de dados críticos sem a capacidade de rastrear um administrador malicioso.
  • Auditoria/registo
  • Assinatura de
• Divulgação de Informações: obter acesso a informações restritas. Um exemplo seria um atacante a obter acesso a um ficheiro restrito.
  • Encriptação
  • Transferência de dados não autorizada
  • Ataques man-in-the-middle
• Denial of Service: interrupção de aplicações maliciosas para degradar a experiência do utilizador. Por exemplo, um ataque de botnet DDoS, como Slowloris.
  • DDoS
  • Botnets
  • Capacidades de CDN e WAF
• Elevação do Privilégio: obter acesso privilegiado à aplicação através de exploits de autorização. Por exemplo, um atacante a manipular uma cadeia de URL para obter acesso a informações confidenciais.
  • Execução remota de código
  • Autorização
  • Isolamento

Recomendações de conceção

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

• Deve ser aplicado um esforço consciente para garantir que as mitigações de segurança são capturadas dentro de critérios de engenharia comuns para impulsionar a consistência em todas as equipas do serviço de aplicações.

• Comece com um serviço por modelação de ameaças ao nível do serviço e unifique o modelo ao consolidar o modelo de thread ao nível da aplicação.

Proteção contra intrusões de rede

Impedir o acesso não autorizado a uma aplicação crítica para a missão e dados englobados é vital para manter a disponibilidade e salvaguardar a integridade dos dados.

Considerações de design

• Confiança Zero assume um estado violado e verifica cada pedido como se fosse proveniente de uma rede não controlada.

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

• Normalmente, os serviços PaaS do Azure são acedidos através de pontos finais públicos. O Azure fornece capacidades para proteger pontos finais públicos ou até mesmo torná-los totalmente privados.

  • Azure Private Link/Pontos Finais Privados fornecem acesso dedicado a um recurso PaaS do Azure com endereços IP privados e conectividade de rede privada.
  • Rede Virtual Pontos Finais de Serviço fornecem acesso ao nível do serviço a partir de sub-redes selecionadas a serviços PaaS selecionados.
  • Rede Virtual Injeção fornece implementações privadas dedicadas para serviços suportados, como Serviço de Aplicações através de um Ambiente do Serviço de Aplicações.
    • O tráfego do plano de gestão continua a fluir através de endereços IP públicos.

• Para serviços suportados, Azure Private Link que utilizam Pontos Finais Privados do Azure resolvem os riscos de exfiltração de dados associados aos Pontos Finais de Serviço, como um administrador malicioso que escreve dados a um recurso externo.

• Ao restringir o acesso de rede aos serviços PaaS do Azure com Pontos Finais Privados ou Pontos Finais de Serviço, será necessário um canal de rede seguro para que os pipelines de implementação acedam ao plano de controlo do Azure e ao plano de dados dos recursos do Azure para implementar e gerir a aplicação.

  • Os agentes de compilação autoalojados privados implementados numa rede privada, uma vez que o recurso do Azure pode ser utilizado como proxy para executar funções CI/CD através de uma ligação privada. Deve ser utilizada uma rede virtual separada para agentes de compilação.
    • É necessária conectividade aos agentes de compilação privados a partir de ferramentas CI/CD.
  • Uma abordagem alternativa consiste em modificar as regras de firewall do recurso no pipeline para permitir uma ligação a partir de um endereço IP público do agente do Azure DevOps, com a firewall subsequentemente removida após a conclusão da tarefa.
    • No entanto, esta abordagem só é aplicável a um subconjunto de serviços do Azure. Por exemplo, isto não é viável para clusters privados do AKS.
  • Para realizar tarefas administrativas e de programador nas caixas de salto do serviço de aplicação, pode ser utilizado.

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

• Os Connections de serviço com um principal de serviço Microsoft Entra correspondente podem ser utilizados no Azure DevOps para aplicar o RBAC através de Microsoft Entra ID.

• 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 Aplicações não abrangem várias redes virtuais.

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

Recomendações de conceção

• Limitar o acesso à rede pública ao mínimo absoluto necessário para que a aplicação cumpra o seu objetivo comercial para reduzir a superfície de ataque externa.

  • Utilize Azure Private Link para estabelecer pontos finais privados para recursos do Azure que exijam uma integração de rede segura.
  • Utilize agentes de compilação privada alojadas para ferramentas CI/CD para implementar e configurar recursos do Azure protegidos por Azure Private Link.
    • Os agentes alojados na Microsoft não poderão ligar-se diretamente aos recursos integrados de rede.

• Ao lidar com agentes de compilação privados, nunca abra uma porta RDP ou SSH diretamente na Internet.

  • Utilize o Azure Bastion para fornecer acesso seguro ao Azure Máquinas Virtuais e realizar tarefas administrativas no PaaS do Azure através da Internet.

• Utilize um plano de proteção padrão DDoS para proteger todos os endereços IP públicos na aplicação.

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

  • Utilize a validação do ID de Cabeçalho para bloquear pontos finais de aplicações públicas para que apenas aceitem tráfego proveniente da instância do Azure Front Door.

• Se requisitos adicionais de segurança de rede na linha, tais como inspeção de pacotes profundas ou inspeção TLS, ordenar a utilização de Azure Firewall Aplicação Virtual de Rede (NVA) ou Premium, certifique-se de que está configurado para elevada disponibilidade e redundância.

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

• Utilize Grupos de Segurança de Rede e Grupos de Segurança de Aplicações para segmentar o tráfego de aplicações de micro-segmentos.

  • Evite utilizar uma aplicação de segurança para filtrar fluxos de tráfego intra-aplicação.
  • Considere a utilização de Azure Policy para impor regras NSG específicas estão sempre associadas a sub-redes de aplicações.

• Ative os registos de fluxo do NSG e alimente-os na Análise de Tráfego para obter informações sobre fluxos de tráfego internos e externos.

• Utilize Azure Private Link/Pontos Finais Privados, sempre que disponíveis, para proteger o acesso aos serviços PaaS do Azure na estrutura da aplicação. Para obter informações sobre os serviços do Azure que suportam Private Link, veja Azure Private Link disponibilidade.

• Se o Ponto Final Privado não estiver disponível e os riscos de exfiltração de dados forem aceitáveis, utilize Rede Virtual Pontos Finais de Serviço para proteger o acesso aos serviços PaaS do Azure a partir de uma rede virtual.

  • Não ative os pontos finais de serviço de rede virtual por predefinição em todas as sub-redes, uma vez que esta ação irá introduzir canais de exfiltração de dados significativos.

• Para cenários de aplicações híbridas, aceda aos serviços PaaS do Azure a partir do local através do ExpressRoute com peering privado.

Nota

Ao implementar numa zona de destino do Azure, tenha em atenção que a conectividade de rede a datacenters no local é fornecida pela implementação da zona de destino. Uma abordagem é utilizar o ExpressRoute configurado com peering privado.

Proteção da integridade dos dados

A encriptação é 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 mitigar uma vasta gama de ameaças. Por conseguinte, esta secção fornecerá considerações e recomendações fundamentais relacionadas com a encriptação e a gestão de chaves para salvaguardar os dados sem comprometer a fiabilidade da aplicação.

Considerações de design

• O Azure Key Vault tem limites de transação para chaves e segredos, com limitação aplicada por cofre num 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 ao nível do cofre.

  • Key Vault atribuições de políticas de acesso concedem permissões separadamente a chaves, segredos ou certificados.
    • As permissões granulares ao nível do objeto para uma chave, segredo ou certificado específico são agora possíveis.

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

  • Existe um limite de 2000 atribuições de funções do Azure por subscrição.

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

  • Está disponível um HSM gerido do Azure Key Vault dedicado para cenários que exijam a conformidade com o FIPS 140-2 Nível 3.

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

• Durante uma ativação pós-falha de região, o serviço de Key Vault pode demorar alguns minutos a efetuar a ativação pós-falha.

  • Durante uma ativação pós-falha, Key Vault estará num modo só de leitura, pelo que não será possível alterar as propriedades do cofre de chaves, como configurações e definições da firewall.

• Se a ligação privada for utilizada para ligar ao Azure Key Vault, poderá demorar até 20 minutos para que a ligação seja restabelecida durante uma ativação pós-falha regional.

• Uma cópia de segurança cria um instantâneo para um ponto anterior no tempo de um segredo, chave ou certificado, como um blob encriptado que não pode ser desencriptado fora do Azure. Para obter dados utilizáveis do blob, estes têm de ser restaurados numa Key Vault na mesma subscrição do Azure e na geografia do Azure.

  • Os segredos podem ser renovados durante uma cópia de segurança, causando um erro de correspondência.

• Com as chaves geridas pelo serviço, o Azure executará funções de gestão de chaves, como a rotação, reduzindo assim o âmbito das operações da aplicação.

• Os controlos regulamentares podem estipular a utilização de chaves geridas pelo cliente para a funcionalidade de encriptação de serviço.

• Quando o tráfego se move entre datacenters do Azure, a encriptação da camada de ligação de dados do 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 conceção

• Utilize chaves geridas pelo serviço para proteção de dados sempre que possível, removendo a necessidade de gerir chaves de encriptação e processar tarefas operacionais, como a rotação de chaves.

  • Utilize apenas chaves geridas pelo cliente quando existir um requisito regulamentar claro para o fazer.

• Utilize o Azure Key Vault como um repositório seguro para todos os segredos, certificados e chaves se forem considerados mecanismos de encriptação adicionais ou chaves geridas pelo cliente.

  • Aprovisione o Azure Key Vault com as políticas de eliminação e remoção recuperável ativadas para permitir a proteção de retenção para objetos eliminados.
  • Utilize o SKU do Azure Key Vault apoiado pelo HSM para ambientes de produção de aplicações.

• Implemente uma instância do Azure Key Vault separada em cada selo de implementação regional, proporcionando isolamento de falhas e benefícios de desempenho através da localização, bem como navegar nos limites de dimensionamento impostos por uma única instância Key Vault.

  • Utilize uma instância dedicada do Azure Key Vault para recursos globais de aplicações.

• Siga um modelo com menos privilégios ao limitar a autorização para eliminar permanentemente segredos, chaves e certificados a funções de Microsoft Entra personalizadas especializadas.

• Certifique-se de que as chaves de encriptação e os certificados armazenados no Key Vault são efetuados cópias de segurança, fornecendo uma cópia offline no evento improvável Key Vault fica indisponível.

• Utilize Key Vault certificados para gerir a aquisição e assinatura de certificados.

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

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

• Monitorizar a utilização de chaves, certificados e segredos.

  • Defina alertas para utilização inesperada 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 equipas de aplicações. Azure Policy fornece uma arquitetura para impor linhas de base de segurança e fiabilidade, garantindo a conformidade contínua com um critério de engenharia comum para uma aplicação crítica para a missão. Mais especificamente, Azure Policy constitui uma parte fundamental do plano de controlo do Azure Resource Manager (ARM), complementando o RBAC ao restringir as ações que os utilizadores autorizados podem realizar e podem ser utilizados para impor convenções vitais de segurança e fiabilidade em todos os serviços de plataforma utilizados.

Por conseguinte, esta secção irá explorar considerações e recomendações fundamentais relacionadas com a utilização de Azure Policy governação orientada para uma aplicação crítica para a missão, garantindo que as convenções de segurança e fiabilidade são continuamente aplicadas.

Considerações de design

• Azure Policy fornece um mecanismo para impulsionar a conformidade ao impor convenções de segurança e fiabilidade, como a utilização de Pontos Finais Privados ou a utilização de Zonas de Disponibilidade.

Nota

Ao implementar numa zona de destino do Azure, tenha em atenção que a imposição de atribuições de políticas de linha de base centralizadas será provavelmente aplicada na implementação para grupos de gestão de zonas de destino e subscrições.

• Azure Policy podem ser utilizadas para impulsionar atividades de gestão automatizadas, como o aprovisionamento e a configuração.

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

• Azure Policy âmbito de atribuição dita a cobertura e a localização das definições de Azure Policy informa a reutilização das políticas personalizadas.

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

• A execução de políticas Deploy If Not Exist (DINE) pode demorar vários minutos a ocorrer.

• Azure Policy fornece um contributo crítico para relatórios de conformidade e auditoria de segurança.

Recomendações de conceção

• Mapeie os requisitos regulamentares e de conformidade para Azure Policy definições.

  • Por exemplo, se existirem requisitos de residência dos dados, deve ser aplicada uma política para restringir as regiões de implementação disponíveis.

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

  • Por exemplo, aplique um Azure Policy para impor a utilização de Zonas de Disponibilidade para todos os serviços relevantes, garantindo configurações de implementação fiáveis na intra-região.

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

• Monitorize o desfasamento da configuração do serviço, em relação aos critérios de engenharia comuns, com Azure Policy.

Para cenários críticos para a missão com várias subscrições de produção num grupo de gestão dedicado, priorize as atribuições no âmbito do grupo de gestão.

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

• Quando forem necessárias definições de políticas personalizadas, confirme que as definições são implementadas no âmbito do grupo de gestão adequado para permitir a reutilização em subscrições de ambiente abrangentes, o que permite a reutilização de políticas em ambientes de produção e ambientes inferiores.

  • Ao alinhar o mapa de objetivos da aplicação com os mapas de objetivos do Azure, utilize os recursos disponíveis da Microsoft para explorar se as definições personalizadas críticas poderiam ser incorporadas como definições incorporadas.

Nota

Ao implementar numa zona de destino do Azure, considere implementar Definições de Azure Policy personalizadas no âmbito intermédio do grupo de gestão de raiz da empresa para permitir a reutilização em todas as aplicações no património do Azure mais amplo. Num ambiente de zona de destino, determinadas políticas de segurança centralizadas serão aplicadas por predefinição dentro de âmbitos de grupos de gestão mais elevados para impor a conformidade de segurança em toda a propriedade do Azure. Por exemplo, as políticas do Azure devem ser aplicadas para implementar automaticamente configurações de software através de extensões de VM e impor uma configuração de VM de linha de base compatível.

• Utilize Azure Policy para impor um esquema de identificação consistente em toda a aplicação.
  • Identifique as etiquetas do Azure necessárias e utilize o modo de política de acréscimo para impor a utilização.

Se a aplicação estiver subscrito ao Suporte do Microsoft Mission-Critical, certifique-se de que o esquema de etiquetagem aplicado fornece um contexto significativo para enriquecer a experiência de suporte com uma compreensão profunda das aplicações.

• Exporte Microsoft Entra registos de atividades para a Área de Trabalho do Log Analytics global utilizada pela aplicação.
  • Confirme que os registos de atividades do Azure são arquivados na Conta de Armazenamento global, juntamente com dados operacionais para retenção de longo prazo.

Numa zona de destino do Azure, Microsoft Entra registos de atividades também serão ingeridos na área de trabalho do Log Analytics da plataforma centralizada. Neste caso, tem de ser avaliada se Microsoft Entra ID ainda são necessárias na área de trabalho do Log Analytics global.

• Integre as informações de segurança e a gestão de eventos no Microsoft Defender para a Cloud (anteriormente conhecido como Centro de Segurança do Azure).

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

Em cenários em que a utilização de iaaS Máquinas Virtuais é necessária, algumas especificações têm de ser tidas em consideração.

Considerações de design

• As imagens não são atualizadas automaticamente uma vez implementadas.
• Atualizações não são instaladas automaticamente em VMs em execução.
• Normalmente, as imagens e as VMs individuais não são endurecidas.

Recomendações de conceção

• Não permita o acesso direto através da Internet pública para Máquinas Virtuais ao fornecer acesso a SSH, RDP ou outros protocolos. Utilize sempre o Azure Bastion e jumpboxes com acesso limitado a um pequeno grupo de utilizadores.
• Restringir a conectividade direta à Internet através de Grupos de Segurança de Rede, Firewall (Azure) ou Gateways de Aplicação (Nível 7) para filtrar e restringir o tráfego de saída.
• Para aplicações de várias camadas, considere utilizar sub-redes diferentes e utilize Grupos de Segurança de Rede para restringir o acesso entre elas.
• Priorize a utilização da autenticação de Chave Pública, sempre que possível. Armazene segredos num local seguro, como o Azure Key Vault.
• Proteja as VMs através da autenticação e do controlo de acesso.
• Aplique as mesmas práticas de segurança descritas para cenários de aplicações fundamentais para a missão.

Siga e aplique práticas de segurança para cenários de aplicações fundamentais para a missão, conforme descrito acima, quando aplicável, bem como as melhores práticas de segurança para cargas de trabalho IaaS no Azure.

Passo seguinte

Reveja as melhores práticas para procedimentos operacionais para cenários de aplicações fundamentais para a missão.

Procedimentos operacionais