Partilhar via

Arquitetura de referência do Azure Spring Apps

  • Artigo

Nota

O Azure Spring Apps é o novo nome para o serviço Azure Spring Cloud. Embora o serviço tenha um novo nome, verá o nome antigo em alguns locais durante algum tempo enquanto trabalhamos para atualizar recursos, como capturas de ecrã, vídeos e diagramas.

Este artigo aplica-se a: ✔️ Standard ✔️ Enterprise

Esta arquitetura de referência é uma base que utiliza um design de hub e spoke empresarial típico para a utilização do Azure Spring Apps. Na estrutura, o Azure Spring Apps é implementado num único spoke que depende de serviços partilhados alojados no hub. A arquitetura é criada com componentes para alcançar os princípios no Microsoft Azure Well-Architected Framework.

Existem dois tipos de Azure Spring Apps: plano Standard e Plano Enterprise.

O plano Standard do Azure Spring Apps é composto pelo Spring Cloud Config Server, o Spring Cloud Service Registry e o serviço de compilação kpack.

O plano Azure Spring Apps Enterprise é composto pelo VMware Tanzu® Build Service™, Pelo Serviço de Configuração de Aplicações para VMware Tanzu®, pelo Registo do Serviço VMware Tanzu®, pelo Spring Cloud Gateway para VMware Tanzu® e pelo portal da API para VMware Tanzu®.

Para uma implementação desta arquitetura, veja Arquitetura de Referência do Azure Spring Apps no GitHub.

As opções de implementação para esta arquitetura incluem o Azure Resource Manager (ARM), Terraform, CLI do Azure e Bicep. Os artefactos neste repositório fornecem uma base que pode personalizar para o seu ambiente. Pode agrupar recursos como Azure Firewall ou Gateway de Aplicação em diferentes grupos de recursos ou subscrições. Este agrupamento ajuda a manter diferentes funções separadas, como a infraestrutura de TI, a segurança, as equipas de aplicações empresariais, etc.

Planear o espaço de endereços

O Azure Spring Apps necessita de duas sub-redes dedicadas:

  • Runtime do serviço
  • Aplicações Spring Boot

Cada uma destas sub-redes requer um cluster dedicado do Azure Spring Apps. Vários clusters não podem partilhar as mesmas sub-redes. O tamanho mínimo de cada sub-rede é /28. O número de instâncias de aplicações que o Azure Spring Apps pode suportar varia consoante o tamanho da sub-rede. Pode encontrar os requisitos de rede virtual detalhados na secção Requisitos de rede virtual de Implementar o Azure Spring Apps numa rede virtual.

Aviso

O tamanho da sub-rede selecionada não se pode sobrepor ao espaço de endereços de rede virtual existente e não deve sobrepor-se a intervalos de endereços de sub-rede no local ou em modo de peering.

Casos de utilização

Utilizações típicas desta arquitetura:

  • Aplicações privadas: aplicações internas implementadas em ambientes de cloud híbrida
  • Aplicações públicas: aplicações destinadas externamente

Estes casos de utilização são semelhantes, exceto as regras de segurança e de tráfego de rede. Esta arquitetura foi concebida para suportar as nuances de cada uma.

Aplicações privadas

A lista seguinte descreve os requisitos de infraestrutura para aplicações privadas. Estes requisitos são típicos em ambientes altamente regulados.

  • Uma sub-rede só tem de ter uma instância do Azure Spring Apps.
  • Deve ser imposta a adesão a, pelo menos, uma Referência de Segurança.
  • Os registos do Serviço de Nomes de Domínio (DNS) do anfitrião da aplicação devem ser armazenados no Azure DNS Privado.
  • As dependências do serviço do Azure devem comunicar através de Pontos Finais de Serviço ou Private Link.
  • Os dados inativos devem ser encriptados.
  • Os dados em trânsito devem ser encriptados.
  • Os pipelines de implementação do DevOps podem ser utilizados (por exemplo, o Azure DevOps) e requerem conectividade de rede ao Azure Spring Apps.
  • O tráfego de saída deve ser percorrido através de uma Aplicação Virtual de Rede (NVA) central (por exemplo, Azure Firewall).
  • Se o Servidor de Configuração do Azure Spring Apps for utilizado para carregar propriedades de configuração de um repositório, o repositório tem de ser privado.
  • A abordagem de segurança Confiança Zero da Microsoft requer que segredos, certificados e credenciais sejam armazenados num cofre seguro. O serviço recomendado é o Azure Key Vault.
  • A resolução de nomes dos anfitriões no local e na Cloud deve ser bidirecional.
  • Nenhuma saída direta para a Internet pública, exceto o tráfego do plano de controlo.
  • Os Grupos de Recursos geridos pela implementação do Azure Spring Apps não podem ser modificados.
  • As sub-redes geridas pela implementação do Azure Spring Apps não podem ser modificadas.

A lista seguinte mostra os componentes que compõem a estrutura:

  • Rede no local
    • Serviço de Nomes de Domínio (DNS)
    • Gateway
  • Subscrição do Hub
    • Sub-rede do Gateway de Aplicação
    • Sub-rede do Azure Firewall
    • Sub-rede de Serviços Partilhados
  • Subscrição ligada
    • Sub-rede do Azure Bastion
    • Rede Virtual Peer

A lista seguinte descreve os serviços do Azure nesta arquitetura de referência:

  • Azure Key Vault: um serviço de gestão de credenciais com suporte de hardware que tem uma integração sólida com os serviços de identidade da Microsoft e os recursos de computação.

  • Azure Monitor: um conjunto abrangente de serviços de monitorização para aplicações que são implementadas no Azure e no local.

  • Pipelines do Azure: um serviço de Integração Contínua/Desenvolvimento Contínuo (CI/CD) totalmente destacado que pode implementar automaticamente aplicações do Spring Boot atualizadas no Azure Spring Apps.

  • Microsoft Defender para a Cloud: um sistema unificado de gestão de segurança e proteção contra ameaças para cargas de trabalho no local, em várias clouds e no Azure.

  • Azure Spring Apps: um serviço gerido concebido e otimizado especificamente para aplicações Spring Boot baseadas em Java e . Aplicações Steeltoe baseadas em NET.

Os diagramas seguintes representam um design de hub-and-spoke bem arquitetado que aborda os requisitos acima:

Aplicações públicas

A lista seguinte descreve os requisitos de infraestrutura para aplicações públicas. Estes requisitos são típicos em ambientes altamente regulados.

  • Uma sub-rede só tem de ter uma instância do Azure Spring Apps.
  • Deve ser imposta a adesão a, pelo menos, uma Referência de Segurança.
  • Os registos do Serviço de Nomes de Domínio (DNS) do anfitrião da aplicação devem ser armazenados no Azure DNS Privado.
  • O Azure DDoS Protection deve estar ativado.
  • As dependências do serviço do Azure devem comunicar através de Pontos Finais de Serviço ou Private Link.
  • Os dados inativos devem ser encriptados.
  • Os dados em trânsito devem ser encriptados.
  • Os pipelines de implementação do DevOps podem ser utilizados (por exemplo, o Azure DevOps) e requerem conectividade de rede ao Azure Spring Apps.
  • O tráfego de saída deve ser percorrido através de uma Aplicação Virtual de Rede (NVA) central (por exemplo, Azure Firewall).
  • O tráfego de entrada deve ser gerido pelo menos Gateway de Aplicação ou pelo Azure Front Door.
  • Os endereços encaminháveis da Internet devem ser armazenados no DNS Público do Azure.
  • A abordagem de segurança Confiança Zero da Microsoft requer que segredos, certificados e credenciais sejam armazenados num cofre seguro. O serviço recomendado é o Azure Key Vault.
  • A resolução de nomes dos anfitriões no local e na Cloud deve ser bidirecional.
  • Nenhuma saída direta para a Internet pública, exceto o tráfego do plano de controlo.
  • Os Grupos de Recursos geridos pela implementação do Azure Spring Apps não podem ser modificados.
  • As sub-redes geridas pela implementação do Azure Spring Apps não podem ser modificadas.

A lista seguinte mostra os componentes que compõem a estrutura:

  • Rede no local
    • Serviço de Nomes de Domínio (DNS)
    • Gateway
  • Subscrição do Hub
    • Sub-rede Gateway de Aplicação
    • Sub-rede do Azure Firewall
    • Sub-rede dos Serviços Partilhados
  • Subscrição ligada
    • Sub-rede do Azure Bastion
    • Rede Virtual Peer

A lista seguinte descreve os serviços do Azure nesta arquitetura de referência:

  • Aplicação Azure Firewall: uma funcionalidade de Gateway de Aplicação do Azure que fornece proteção centralizada de aplicações contra exploits e vulnerabilidades comuns.

  • Gateway de Aplicação do Azure: um balanceador de carga responsável pelo tráfego da aplicação com a descarga de Transport Layer Security (TLS) a funcionar na camada 7.

  • O Azure Key Vault: um serviço de gestão de credenciais com suporte para hardware que tem uma integração apertada com serviços de identidade da Microsoft e recursos de computação.

  • Azure Monitor: um conjunto abrangente de serviços de monitorização para aplicações que são implementadas no Azure e no local.

  • Pipelines do Azure: um serviço de Integração Contínua/Desenvolvimento Contínuo (CI/CD) totalmente em destaque que pode implementar automaticamente aplicações do Spring Boot atualizadas no Azure Spring Apps.

  • Microsoft Defender para a Cloud: um sistema unificado de proteção contra ameaças e gestão de segurança para cargas de trabalho no local, em várias clouds e no Azure.

  • Azure Spring Apps: um serviço gerido concebido e otimizado especificamente para aplicações Spring Boot baseadas em Java e . Aplicações Steeltoe baseadas em NET.

Os diagramas seguintes representam um design de hub e spoke bem arquitetado que aborda os requisitos acima. Apenas a rede virtual-hub comunica com a Internet:

Conectividade no local do Azure Spring Apps

As aplicações no Azure Spring Apps podem comunicar com vários recursos do Azure, no local e externos. Ao utilizar a estrutura hub-and-spoke, as aplicações podem encaminhar o tráfego externamente ou para a rede no local com a Rede Privada Virtual (VPN) ou a Via Rápida ou a Rede Privada Virtual (VPN).

Considerações do Azure Well-Architected Framework

O Azure Well-Architected Framework é um conjunto de princípios orientadores a seguir para estabelecer uma base de infraestrutura forte. A arquitetura contém as seguintes categorias: otimização de custos, excelência operacional, eficiência de desempenho, fiabilidade e segurança.

Otimização de custos

Devido à natureza do design distribuído do sistema, a expansão da infraestrutura é uma realidade. Esta realidade resulta em custos inesperados e incontroláveis. O Azure Spring Apps é criado com componentes que são dimensionados para que possa satisfazer a procura e otimizar os custos. O núcleo desta arquitetura é o Azure Kubernetes Service (AKS). O serviço foi concebido para reduzir a complexidade e a sobrecarga operacional da gestão do Kubernetes, que inclui eficiências no custo operacional do cluster.

Pode implementar diferentes aplicações e tipos de aplicações numa única instância do Azure Spring Apps. O serviço suporta o dimensionamento automático de aplicações acionadas por métricas ou agendas que podem melhorar a utilização e a eficiência dos custos.

Também pode utilizar o Application Insights e o Azure Monitor para reduzir os custos operacionais. Com a visibilidade fornecida pela solução de registo abrangente, pode implementar a automatização para dimensionar os componentes do sistema em tempo real. Também pode analisar dados de registo para revelar ineficiências no código da aplicação que pode abordar para melhorar o custo e o desempenho globais do sistema.

Excelência operacional

O Azure Spring Apps aborda vários aspetos de excelência operacional. Pode combinar estes aspetos para garantir que o serviço é executado de forma eficiente em ambientes de produção, conforme descrito na lista seguinte:

  • Pode utilizar os Pipelines do Azure para garantir que as implementações são fiáveis e consistentes, ajudando-o a evitar erros humanos.
  • Pode utilizar o Azure Monitor e o Application Insights para armazenar dados de registo e telemetria. Pode avaliar os dados de registos e métricas recolhidos para garantir o estado de funcionamento e o desempenho das suas aplicações. A Monitorização do Desempenho de Aplicações (APM) está totalmente integrada no serviço através de um agente Java. Este agente fornece visibilidade sobre todas as aplicações e dependências implementadas sem precisar de código adicional. Para obter mais informações, consulte a publicação de blogue Monitorizar sem esforço aplicações e dependências no Azure Spring Apps.
  • Pode utilizar Microsoft Defender para a Cloud para garantir que as aplicações mantêm a segurança ao fornecer uma plataforma para analisar e avaliar os dados fornecidos.
  • O serviço suporta vários padrões de implementação. Para obter mais informações, veja Configurar um ambiente de teste no Azure Spring Apps.

Fiabilidade

O Azure Spring Apps baseia-se no AKS. Embora o AKS forneça um nível de resiliência através do clustering, esta arquitetura de referência vai ainda mais longe ao incorporar serviços e considerações arquitetónicas para aumentar a disponibilidade da aplicação se existir uma falha no componente.

Ao basear-se num design de hub e spoke bem definido, a base desta arquitetura garante que pode implementá-lo em várias regiões. Para o caso de utilização de aplicações privadas, a arquitetura utiliza o Azure DNS Privado para garantir a disponibilidade contínua durante uma falha geográfica. Para o caso de utilização da aplicação pública, o Azure Front Door e Gateway de Aplicação do Azure garantir a disponibilidade.

Segurança

A segurança desta arquitetura é abordada pela sua adesão a controlos e referências definidos pela indústria. Neste contexto, "controlo" significa uma melhor prática concisa e bem definida, como "Utilizar o princípio de menor privilégio ao implementar o acesso ao sistema de informação. IAM-05" Os controlos nesta arquitetura são da Matriz de Controlo de Cloud (CCM) da Cloud Security Alliance (CSA) e do Microsoft Azure Foundations Benchmark (MAFB) pelo Center for Internet Security (CIS). Nos controlos aplicados, o foco está nos principais princípios de design de segurança da governação, da rede e da segurança das aplicações. É da sua responsabilidade processar os princípios de conceção de Identidade, Gestão de Acesso e Armazenamento, uma vez que estão relacionados com a sua infraestrutura de destino.

Governação

O aspeto principal da governação que esta arquitetura aborda é a segregação através do isolamento dos recursos de rede. No CCM, o DCS-08 recomenda o controlo de entrada e saída do datacenter. Para satisfazer o controlo, a arquitetura utiliza um design hub-and-spoke através de Grupos de Segurança de Rede (NSGs) para filtrar o tráfego este-oeste entre recursos. A arquitetura também filtra o tráfego entre os serviços centrais no hub e os recursos no spoke. A arquitetura utiliza uma instância de Azure Firewall para gerir o tráfego entre a Internet e os recursos dentro da arquitetura.

A lista seguinte mostra o controlo que aborda a segurança do datacenter nesta referência:

ID de Controlo CCM do CSA Domínio de Controlo CCM do CSA
DCS-08 Entrada de Pessoas Não Autorizadas de Segurança do Datacenter

Rede

O design de rede que suporta esta arquitetura deriva do modelo de hub e spoke tradicional. Esta decisão garante que o isolamento de rede é uma construção fundamental. O controlo CCM IVS-06 recomenda que o tráfego entre redes e máquinas virtuais seja restrito e monitorizado entre ambientes fidedignos e não fidedignos. Esta arquitetura adota o controlo através da implementação dos NSGs para o tráfego este-oeste (no "datacenter" e do Azure Firewall para o tráfego norte-sul (fora do "datacenter"). O controlo CCM IPY-04 recomenda que a infraestrutura utilize protocolos de rede seguros para o intercâmbio de dados entre serviços. Todos os serviços do Azure que suportam esta arquitetura utilizam protocolos seguros padrão, como o TLS para HTTP e SQL.

A lista seguinte mostra os controlos CCM que abordam a segurança de rede nesta referência:

ID de Controlo CCM do CSA Domínio de Controlo CCM do CSA
IPY-04 Protocolos de Rede
IVS-06 Segurança de Rede

A implementação da rede é ainda protegida ao definir controlos do MAFB. Os controlos garantem que o tráfego para o ambiente é restringido da Internet pública.

A lista seguinte mostra os controlos CIS que abordam a segurança de rede nesta referência:

ID de Controlo CIS Descrição do controlo CIS
6.2 Certifique-se de que o acesso SSH está restrito a partir da Internet.
6.3 Certifique-se de que nenhuma Base de Dados SQL permite a entrada 0.0.0.0/0 (QUALQUER IP).
6.5 Certifique-se de que Observador de Rede está "Ativado".
6.6 Certifique-se de que a entrada com UDP está restrita a partir da Internet.

O Azure Spring Apps requer tráfego de gestão para a saída do Azure quando implementado num ambiente seguro. Tem de permitir as regras de rede e aplicações listadas nas Responsabilidades do cliente para executar o Azure Spring Apps numa rede virtual.

Segurança de aplicações

Este princípio de design abrange os componentes fundamentais da identidade, proteção de dados, gestão de chaves e configuração de aplicações. Por predefinição, uma aplicação implementada no Azure Spring Apps é executada com o menor privilégio necessário para funcionar. O conjunto de controlos de autorização está diretamente relacionado com a proteção de dados ao utilizar o serviço. A gestão de chaves reforça esta abordagem de segurança de aplicações em camadas.

A lista seguinte mostra os controlos CCM que abordam a gestão de chaves nesta referência:

ID de Controlo CCM do CSA Domínio de Controlo CCM do CSA
EKM-01 Direito de Encriptação e Gestão de Chaves
EKM-02 Geração de Chave de Gestão de Chaves e Encriptação
EKM-03 Proteção de Dados Confidenciais de Gestão de Chaves e Encriptação
EKM-04 Armazenamento e Acesso de Gestão de Chaves e Encriptação

A partir do CCM, EKM-02 e EKM-03 recomendam políticas e procedimentos para gerir chaves e utilizar protocolos de encriptação para proteger dados confidenciais. O EKM-01 recomenda que todas as chaves criptográficas tenham proprietários identificáveis para que possam ser geridas. O EKM-04 recomenda a utilização de algoritmos padrão.

A lista seguinte mostra os controlos CIS que abordam a gestão de chaves nesta referência:

ID de Controlo CIS Descrição do controlo CIS
8.1 Certifique-se de que a data de expiração está definida em todas as chaves.
8.2 Certifique-se de que a data de expiração está definida em todos os segredos.
8,4 Certifique-se de que o cofre de chaves é recuperável.

Os controlos CIS 8.1 e 8.2 recomendam que as datas de expiração estejam definidas para credenciais para garantir que a rotação é imposta. O controlo CIS 8.4 garante que os conteúdos do cofre de chaves podem ser restaurados para manter a continuidade do negócio.

Os aspetos da segurança da aplicação definem uma base para a utilização desta arquitetura de referência para suportar uma carga de trabalho spring no Azure.

Passos seguintes

Explore esta arquitetura de referência através das implementações arm, Terraform e CLI do Azure disponíveis no repositório arquitetura de referência do Azure Spring Apps .