Compartilhar via

Arquitetura de referência do Azure Spring Apps

  • Artigo

Observação

Azure Spring Apps é o novo nome do serviço Azure Spring Cloud. Embora o serviço tenha um novo nome, você verá o nome antigo em alguns locais por um tempo enquanto trabalhamos para atualizar ativos como capturas de tela, vídeos e diagramas.

Este artigo se aplica aos níveis: ✔️ Standard ✔️ Enterprise

Essa arquitetura de referência é uma base que usa um design típico de hub e spoke corporativo para o uso do Azure Spring Apps. No design, o Azure Spring Apps é implantado em um único spoke que é dependente de serviços compartilhados hospedados no hub. A arquitetura é criada com componentes para alcançar os princípios da Estrutura Bem Projetada do Microsoft Azure.

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

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

O plano enterprise do Azure Spring Apps é composto pelo Serviço de Build do VMware Tanzu®, pelo Serviço de Configuração de Aplicativos para VMware Tanzu®, pelo Registro de Serviço do VMware Tanzu®, pelo Spring Cloud Gateway para VMware Tanzu® e pelo portal de API do VMware Tanzu®.™

Para obter uma implementação dessa arquitetura, consulte a Arquitetura de Referência do Azure Spring Apps no GitHub.

As opções de implantação dessa arquitetura incluem o ARM (Azure Resource Manager), o Terraform, a CLI do Azure e o Bicep. Os artefatos neste repositório fornecem uma base que você pode personalizar para seu ambiente. Você pode agrupar recursos como o Firewall do Azure ou o Gateway de Aplicativo em diferentes grupos de recursos ou assinaturas. Esse agrupamento ajuda a manter diferentes funções separadas, como infraestrutura de TI, segurança, equipes de aplicativos de negócios e assim por diante.

Planejar o espaço de endereço

O Azure Spring Apps requer duas sub-redes dedicadas:

  • Runtime de serviço
  • Aplicativos do Spring Boot

Cada uma dessas sub-redes exige um cluster dedicado do Azure Spring Apps. Vários clusters não podem compartilhar as mesmas sub-redes. O tamanho mínimo de cada sub-rede é /28. O número de instâncias de aplicativo para as quais o Azure Spring Apps pode dar suporte varia de acordo com o tamanho da sub-rede. É possível encontrar os requisitos de rede virtual detalhados na seção Requisitos da Rede Virtual de Implantar Aplicativos Spring do Azure em uma rede virtual.

Aviso

O tamanho de sub-rede selecionado não poderá se sobrepor ao espaço de endereço de rede virtual existente e não deverá se sobrepor a nenhum intervalo de endereços de sub-rede local ou emparelhado.

Casos de uso

Alguns usos típicos dessa arquitetura:

  • Aplicativos privados: aplicativos internos implantados em ambientes de nuvem híbrida
  • Aplicativos públicos: aplicativos voltados para o público

Esses casos de uso são semelhantes, exceto nas suas regras de segurança e de tráfego de rede. Essa arquitetura foi projetada para dar suporte às nuances de cada uma.

Aplicativos privados

A lista a seguir descreve os requisitos de infraestrutura para aplicativos privados. Esses requisitos são típicos de ambientes altamente regulamentados.

  • Uma sub-rede deve ter apenas uma instância do Azure Spring Apps.
  • A adesão a pelo menos um Parâmetro de Comparação de Segurança deve ser imposta.
  • Os registros DNS (Serviço de Nomes de Domínio) do host de aplicativo devem ser armazenados no DNS Privado do Azure.
  • As dependências de serviço do Azure devem se comunicar por meio de Pontos de Extremidade de Serviço ou de Link Privado.
  • Os dados inativos devem ser criptografados.
  • Os dados em trânsito devem ser criptografados.
  • Os pipelines de implantação de DevOps podem ser usados (por exemplo, o Azure DevOps) e exigem conectividade de rede para o Azure Spring Apps.
  • O tráfego de saída deve viajar por meio de uma NVA (solução de virtualização de rede) central (por exemplo, o Firewall do Azure).
  • Se o Servidor de Configuração do Azure Spring Apps for usado para carregar as propriedades de configuração de um repositório, o repositório deverá ser particular.
  • A abordagem de segurança de Confiança Zero da Microsoft exige que segredos, certificados e credenciais sejam armazenados em um cofre seguro. O serviço recomendado é o Azure Key Vault.
  • A resolução de nomes de hosts locais e na nuvem deve ser bidirecional.
  • Nenhuma saída direta para a Internet pública, exceto para o tráfego do plano de controle.
  • Os Grupos de Recursos gerenciados pela implantação do Azure Spring Apps não devem ser modificados.
  • As sub-redes gerenciadas pela implantação do Azure Spring Apps não devem ser modificadas.

A lista a seguir mostra os componentes que compõem o design:

  • Rede local
    • DNS (Sistema de Nomes de Domínio)
    • Gateway
  • Assinatura do hub
    • Sub-rede de Gateway de Aplicativo
    • Sub-rede do Firewall do Azure
    • Sub-rede de Serviços Compartilhados
  • Assinatura conectada
    • Sub-rede do Azure Bastion
    • Par de Rede Virtual

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

  • Azure Key Vault: um serviço de gerenciamento de credenciais com suporte de hardware que tem integração total com os recursos de computação e serviços de identidade da Microsoft.

  • Azure Monitor: um pacote completo de serviços de monitoramento para aplicativos que são implantados no Azure e no local.

  • Azure Pipelines: um serviço completo de CI/CD (integração contínua/desenvolvimento contínuo) que pode implantar automaticamente os aplicativos Spring Boot atualizados no Azure Spring Apps.

  • Microsoft Defender para Nuvem: um sistema unificado de proteção contra ameaças e gerenciamento de segurança para cargas de trabalho entre locais, várias nuvens e o Azure.

  • Azure Spring Apps: um serviço gerenciado que foi projetado e otimizado especificamente para aplicativos Spring Boot baseados em Java e aplicativos Steeltoe baseados em .NET.

Os diagramas a seguir representam um design de hub e spoke bem arquitetado que inclui os requisitos acima:

Aplicativos públicos

A lista a seguir descreve os requisitos de infraestrutura para aplicativos públicos. Esses requisitos são típicos de ambientes altamente regulamentados.

  • Uma sub-rede deve ter apenas uma instância do Azure Spring Apps.
  • A adesão a pelo menos um Parâmetro de Comparação de Segurança deve ser imposta.
  • Os registros DNS (Serviço de Nomes de Domínio) do host de aplicativo devem ser armazenados no DNS Privado do Azure.
  • A Proteção contra DDoS do Azure deve ser habilitada.
  • As dependências de serviço do Azure devem se comunicar por meio de Pontos de Extremidade de Serviço ou de Link Privado.
  • Os dados inativos devem ser criptografados.
  • Os dados em trânsito devem ser criptografados.
  • Os pipelines de implantação de DevOps podem ser usados (por exemplo, o Azure DevOps) e exigem conectividade de rede para o Azure Spring Apps.
  • O tráfego de saída deve viajar por meio de uma NVA (solução de virtualização de rede) central (por exemplo, o Firewall do Azure).
  • O tráfego de entrada deve ser gerenciado por pelo menos o Gateway de Aplicativo ou o Azure Front Door.
  • Endereços roteáveis da Internet devem ser armazenados no DNS Público do Azure.
  • A abordagem de segurança de Confiança Zero da Microsoft exige que segredos, certificados e credenciais sejam armazenados em um cofre seguro. O serviço recomendado é o Azure Key Vault.
  • A resolução de nomes de hosts locais e na nuvem deve ser bidirecional.
  • Nenhuma saída direta para a Internet pública, exceto para o tráfego do plano de controle.
  • Os Grupos de Recursos gerenciados pela implantação do Azure Spring Apps não devem ser modificados.
  • As sub-redes gerenciadas pela implantação do Azure Spring Apps não devem ser modificadas.

A lista a seguir mostra os componentes que compõem o design:

  • Rede local
    • DNS (Sistema de Nomes de Domínio)
    • Gateway
  • Assinatura do hub
    • Sub-rede de Gateway de Aplicativo
    • Sub-rede do Firewall do Azure
    • Sub-rede de Serviços Compartilhados
  • Assinatura conectada
    • Sub-rede do Azure Bastion
    • Par de Rede Virtual

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

  • Firewall do Aplicativo Azure: é um recurso do Gateway de Aplicativo do Azure que fornece proteção centralizada de seus aplicativos contra vulnerabilidades e explorações comuns.

  • Gateway de Aplicativo do Azure: um balanceador de carga responsável pelo tráfego do aplicativo com a operação de descarregamento de TLS (segurança da camada de transporte) na camada 7.

  • Azure Key Vault: um serviço de gerenciamento de credenciais com suporte de hardware que tem integração total com os recursos de computação e serviços de identidade da Microsoft.

  • Azure Monitor: um pacote completo de serviços de monitoramento para aplicativos que são implantados no Azure e no local.

  • Azure Pipelines: um serviço completo de CI/CD (integração contínua/desenvolvimento contínuo) que pode implantar automaticamente os aplicativos Spring Boot atualizados no Azure Spring Apps.

  • Microsoft Defender para Nuvem: um sistema unificado de proteção contra ameaças e gerenciamento de segurança para cargas de trabalho entre locais, várias nuvens e o Azure.

  • Azure Spring Apps: um serviço gerenciado que foi projetado e otimizado especificamente para aplicativos Spring Boot baseados em Java e aplicativos Steeltoe baseados em .NET.

Os diagramas a seguir representam um design de hub e spoke bem arquitetado que inclui os requisitos acima. Apenas o hub-virtual-network se comunica com a Internet:

Conectividade local do Azure Spring Apps

Aplicativos no Azure Spring Apps podem se comunicar com vários recursos do Azure, locais e externos. Ao usar o design de hub e spoke, os aplicativos podem rotear o tráfego externamente ou para a rede local usando a Rota Expressa ou a VPN (rede virtual privada) site a site.

Considerações da Estrutura Bem Projetada do Azure

A Estrutura Bem Projetada do Azure é um conjunto de princípios de orientação a seguir no estabelecimento de uma base de infraestrutura forte. A estrutura contém as seguintes categorias: otimização de custos, excelência operacional, eficiência de desempenho, confiabilidade e segurança.

Otimização de custo

Devido à natureza do design do sistema distribuído, a expansão da infraestrutura é uma realidade. Essa realidade resulta em custos inesperados e não controláveis. O Azure Spring Apps é criado usando componentes que escalam para que ele possa atender à demanda e otimizar o custo. O núcleo dessa arquitetura é o AKS (Serviço de Kubernetes do Azure). O serviço foi projetado para reduzir a complexidade e a sobrecarga operacional do gerenciamento de Kubernetes, que inclui eficiências no custo operacional do cluster.

Você pode implantar diferentes aplicativos e tipos de aplicativos em uma única instância do Azure Spring Apps. O serviço oferece suporte ao dimensionamento automático de aplicativos acionados por métricas ou agendamento que podem melhorar a utilização e a eficiência de custos.

Você também pode usar o Application Insights e o Azure Monitor para reduzir o custo operacional. Com a visibilidade fornecida pela solução de registro em log abrangente, você pode implementar a automação para dimensionar os componentes do sistema em tempo real. Você também pode analisar dados de log para revelar ineficiências no código do aplicativo que você pode abordar para melhorar o custo e o desempenho geral do sistema.

Excelência operacional

O Azure Spring Apps aborda vários aspectos da excelência operacional. Você pode combinar esses aspectos para garantir que o serviço seja executado de forma eficiente em ambientes de produção, como descrito na lista a seguir:

  • Você pode usar o Azure Pipelines para garantir que as implantações sejam confiáveis e consistentes, ajudando a evitar erros humanos.
  • Você pode usar o Azure Monitor e o Application Insights para armazenar dados de log e telemetria. Você pode avaliar os dados de log e de métricas coletados para garantir a integridade e o desempenho dos seus aplicativos. O APM (Monitoramento do Desempenho de Aplicativos) está totalmente integrado ao serviço por meio de um agente Java. Esse agente fornece visibilidade de todos os aplicativos e dependências implantados sem a necessidade de código extra. Para saber mais, confira a postagem no blog Monitore aplicativos e dependências com facilidade no Azure Spring Apps.
  • Você pode usar o Microsoft Defender para Nuvem para garantir que os aplicativos mantenham a segurança fornecendo uma plataforma para analisar e avaliar os dados fornecidos.
  • O serviço oferece suporte a vários padrões de implantação. Para obter mais informações, confira Configurar um ambiente de preparo no Azure Spring Apps.

Confiabilidade

O Azure Spring Apps foi criado no AKS. Embora o AKS forneça um nível de resiliência por meio do clustering, essa arquitetura de referência vai além, incorporando serviços e considerações de arquitetura para aumentar a disponibilidade do aplicativo em caso de falha dos componentes.

Ao se basear em um design de hub e spoke bem definido, a base dessa arquitetura garante que você possa implantá-la em várias regiões. Para o caso de uso do aplicativo privado, a arquitetura usa o DNS Privado do Azure para garantir a disponibilidade contínua durante uma falha geográfica. Para o caso de uso do aplicativo público, a disponibilidade é garantida pelo Azure Front Door e pelo Gateway de Aplicativo do Azure.

Segurança

A segurança dessa arquitetura é abordada por sua adesão a controles e parâmetros de comparação definidos pelo setor. Neste contexto, "controle" significa uma melhor prática concisa e bem definida, como "Empregue o princípio de privilégio mínimo ao implementar o acesso ao sistema de informações. IAM-05". Os controles dessa arquitetura foram obtidos da CCM (Cloud Control Matrix), fornecido pela CSA (Cloud Security Alliance), e do MAFB (Microsoft Azure Foundations Benchmark), fornecido pelo CIS (Center for Internet Security). Nos controles aplicados, o foco está nos princípios primários de design de segurança de governança, rede e segurança de aplicativos. É sua responsabilidade lidar com os princípios de design de Identidade, Gerenciamento de Acesso e Armazenamento relacionados à sua infraestrutura de destino.

Governança

O aspecto principal de governança que essa arquitetura aborda é a diferenciação por meio do isolamento dos recursos de rede. No CCM, o DCS-08 recomenda o controle de entrada e saída para o datacenter. Para atender ao controle, a arquitetura usa um design de hub e spoke usando NSGs (Grupos de Segurança de Rede) para filtrar o tráfego leste-oeste entre os recursos. A arquitetura também filtra o tráfego entre os serviços centrais no hub e os recursos no spoke. A arquitetura usa uma instância do Firewall do Azure para gerenciar o tráfego entre a Internet e os recursos da arquitetura.

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

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

Rede

O design de rede que dá suporte a essa arquitetura é derivado do modelo hub e spoke tradicional. Essa decisão garante que o isolamento de rede seja uma construção básica. O controle CCM IVS-06 recomenda que o tráfego entre redes e máquinas virtuais seja restrito e monitorado entre ambientes confiáveis e não confiáveis. Essa arquitetura adota o controle pela implementação dos NSGs para o tráfego leste-oeste (dentro do "data center") e do Firewall do Azure para o tráfego norte-sul (fora do "data center"). O controle CCM IPY-04 recomenda que a infraestrutura use protocolos de rede seguros para a troca de dados entre serviços. Todos os serviços do Azure com suporte a essa arquitetura usam protocolos seguros padrão, como TLS para HTTP e SQL.

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

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

A implementação de rede é ainda mais protegida por meio da definição de controles do MAFB. Os controles garantem que o tráfego no ambiente seja restrito da Internet pública.

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

ID de Controle CIS Descrição do controle CIS
6.2 Garantir que o acesso SSH seja restrito da Internet.
6.3 Verificar se nenhum Banco de Dados SQL permite a entrada 0.0.0.0/0 (qualquer IP).
6.5 Garantir que o Observador de Rede esteja 'Habilitado'.
6.6 Verifique se a entrada que usa UDP está restrita da Internet.

O Azure Spring Apps exige o tráfego de gerenciamento para saída do Azure quando implantado em um ambiente seguro. Será necessário permitir as regras de rede e aplicativo listadas em Responsabilidades do cliente para executar os Aplicativos Spring do Azure em uma rede virtual.

Segurança de aplicativo

Esse princípio de design abrange os componentes fundamentais de identidade, proteção de dados, gerenciamento de chaves e configuração de aplicativos. Por design, um aplicativo implantado no Azure Spring Apps é executado com os privilégios mínimos necessários para funcionar. O conjunto de controles de autorização está relacionado diretamente à proteção de dados ao usar o serviço. O gerenciamento de chaves reforça essa abordagem de segurança de aplicativos em camadas.

A lista a seguir mostra os controles CCM que abordam o gerenciamento de chaves nesta referência:

ID de Controle CSA CCM Domínio de Controle CSA CCM
EKM-01 Direito de Gerenciamento de Chaves e Criptografia
EKM-02 Geração de Chave de Gerenciamento de Chaves e Criptografia
EKM-03 Proteção de Dados Confidenciais de Gerenciamento de Chaves e Criptografia
EKM-04 Acesso e Armazenamento de Gerenciamento de Chaves e Criptografia

No CCM, o EKM-02 e o EKM-03 recomendamos políticas e procedimentos para gerenciar chaves e usar protocolos de criptografia para proteger dados confidenciais. No EKM-01 recomendamos que todas as chaves de criptografia tenham proprietários identificáveis para que possam ser gerenciadas. No EKM-04 recomendamos o uso de algoritmos padrão.

A lista a seguir mostra os controles CIS que abordam o gerenciamento de chaves nesta referência:

ID de Controle CIS Descrição do controle CIS
8.1 Verifique se a data de validade está definida em todas as chaves.
8.2 Verifique se a data de validade está definida em todos os segredos.
8.4 Garantir que o cofre de chaves seja recuperável.

Os controles CIS 8.1 e 8.2 recomendam que as datas de validade sejam definidas para as credenciais para garantir que a rotação seja imposta. O controle CIS 8.4 garante que o conteúdo do cofre de chaves possa ser restaurado para manter a continuidade dos negócios.

Os aspectos da segurança de aplicativo definem uma base para o uso dessa arquitetura de referência para dar suporte a uma carga de trabalho Spring no Azure.

Próximas etapas

Explore essa arquitetura de referência por meio das implantações do ARM, Terraform e da CLI do Azure disponíveis no repositório de Arquitetura de Referência do Azure Spring Apps.