Arquitetura de referência do Azure Spring Apps

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 a: ✔️ Standard ✔️ Enterprise

Essa arquitetura de referência é uma base usando um modelo típico de hub-and-spoke empresarial para o uso do Azure Spring Apps. No design, o Azure Spring Apps é implantado em um único spoke que depende dos serviços compartilhados hospedados no hub. A arquitetura é criada com componentes para obter os princípios no Microsoft Azure Well-Architected Framework.

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

O plano do Azure Spring Apps Standard é composto pelo Servidor de Configuração do Spring Cloud, o Registro do Serviço de Nuvem do Spring e o serviço de build do kpack.

O plano do Azure Spring Apps Enterprise é composto pelo Serviço de Build do VMware Tanzu®, pelo Serviço de Configuração de Aplicativos do 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 para essa 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.

Planejando o espaço de endereço

O Azure Spring Apps requer duas sub-redes dedicadas:

• Tempo de execução do serviço
• Aplicações Spring Boot

Cada uma dessas sub-redes requer 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 com suporte do Azure Spring Apps varia de acordo com o tamanho da sub-rede. Você pode encontrar os requisitos detalhados de rede virtual na seção de requisitos de rede virtual de Implantar o Azure Spring Apps em uma rede virtual.

Aviso

O tamanho da sub-rede selecionado não pode se sobrepor ao espaço de endereço de rede virtual existente e não deve se sobrepor a nenhum intervalo de endereços de sub-rede local ou emparelhada.

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 externo

Esses casos de uso são semelhantes, exceto por suas regras de segurança e 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 em ambientes altamente regulamentados.

• Uma sub-rede deve ter apenas uma instância do Azure Spring Apps.
• A adesão a pelo menos um Security Benchmark deve ser imposta.
• Os registros DNS (Serviço de Nome de Domínio) do host do 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 link privado.
• Os dados em repouso devem ser criptografados.
• Os dados em trânsito devem ser criptografados.
• Os pipelines de implantação do DevOps podem ser usados (por exemplo, Azure DevOps) e exigem conectividade de rede com o Azure Spring Apps.
• O tráfego de saída deve percorrer uma NVA (Solução de Virtualização de Rede) central (por exemplo, Firewall do Azure).
• Se o Servidor de Configuração do Azure Spring Apps for usado para carregar propriedades de configuração de um repositório, o repositório deverá ser privado.
• A abordagem de segurança de Confiança Zero da Microsoft requer 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 no local e na nuvem deve ser bidirecional.
• Nenhuma saída direta para a Internet pública, exceto para o tráfego do painel 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 (Serviço de Nome de Domínio)
  • Porta de entrada
• 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 uma integração apertada com os serviços de identidade da Microsoft e recursos de computação.

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

• Azure Pipelines: um serviço de Integração Contínua / Entrega Contínua (CI/CD) com recursos completos que pode implantar automaticamente aplicativos atualizados do Spring Boot no Azure Spring Apps.

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

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

Os diagramas a seguir representam um projeto de "hub and spoke" bem arquitetado que atende aos requisitos acima.

Plano padrão

Plano empresarial

Aplicativos públicos

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

• Uma sub-rede deve ter apenas uma instância do Azure Spring Apps.
• A adesão a pelo menos um Security Benchmark deve ser imposta.
• Os registros DNS (Serviço de Nome de Domínio) do host do 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 link privado.
• Os dados em repouso devem ser criptografados.
• Os dados em trânsito devem ser criptografados.
• Os pipelines de implantação do DevOps podem ser usados (por exemplo, Azure DevOps) e exigem conectividade de rede com o Azure Spring Apps.
• O tráfego de saída deve percorrer uma NVA (Solução de Virtualização de Rede) central (por exemplo, Firewall do Azure).
• O tráfego de entrada deve ser gerenciado pelo menos por meio do Gateway de Aplicativo ou do Azure Front Door.
• Os 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 requer 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 no local e na nuvem deve ser bidirecional.
• Nenhuma saída direta para a Internet pública, exceto para o tráfego do painel 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 (Serviço de Nome de Domínio)
  • Porta de entrada
• 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 de Aplicativo do Azure: um recurso do Gateway de Aplicativo do Azure que fornece proteção centralizada de aplicativos contra explorações e vulnerabilidades comuns.

• Gateway de Aplicações do Azure: um balanceador de carga responsável pelo tráfego de aplicações com descarregamento de TLS (Segurança da Camada de Transporte) operando na camada 7.

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

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

• Azure Pipelines: um serviço de Integração Contínua/Entrega Contínua (CI/CD) totalmente funcional que pode implantar automaticamente aplicativos Spring Boot atualizados no Azure Spring Apps.

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

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

Os diagramas seguintes representam um design de hub e spoke bem projetado que atende aos requisitos acima. Somente a rede virtual do hub se comunica com a Internet:

Plano padrão

Plano empresarial

Conectividade local do Azure Spring Apps

Os aplicativos no Azure Spring Apps podem se comunicar com vários recursos do Azure, locais e externos. Usando o design de hub e spoke, os aplicativos podem rotear o tráfego externamente ou para a rede local usando a VPN (Rota Expressa ou Rede Virtual Privada Site a Site).

Considerações da Estrutura Bem Projetada do Azure

O Azure Well-Architected Framework é um conjunto de princípios orientadores a serem seguidos 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 custos

Devido à natureza do design do sistema distribuído, a expansão da infraestrutura é uma realidade. Essa realidade resulta em custos inesperados e incontroláveis. O Azure Spring Apps é criado usando componentes que são dimensionados 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 do Kubernetes, o que inclui eficiências no custo operacional do cluster.

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

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 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 geral e o desempenho 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 com eficiência em ambientes de produção, conforme descrito na seguinte lista:

• Você pode usar o Azure Pipelines para garantir que as implantações sejam confiáveis e consistentes, ajudando você 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 métrica coletados para garantir a integridade e o desempenho de seus aplicativos. O APM (Monitoramento de Desempenho do Aplicativo) é 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 obter mais informações, consulte a postagem no blog monitorando facilmente aplicativos e dependências 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 dá suporte a vários padrões de implantação. Para obter mais informações, consulte Configurar um ambiente de preparo no Azure Spring Apps.

Fiabilidade

O Azure Spring Apps é criado com base no AKS. Embora o AKS forneça um nível de resiliência por meio do clustering, essa arquitetura de referência vai ainda mais longe incorporando serviços e considerações arquitetônicas para aumentar a disponibilidade do aplicativo se houver falha de componente.

Ao construir sobre um projeto de hub and spoke bem definido, a base dessa arquitetura garante que você possa implantá-la em múltiplas 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, o Azure Front Door e o Gateway de Aplicativo do Azure garantem a disponibilidade.

Segurança

A segurança dessa arquitetura é tratada por sua adesão a controles e parâmetros de comparação definidos pelo setor. Nesse contexto, "controle" significa uma prática recomendada concisa e bem definida, como "Empregar o princípio de privilégio mínimo ao implementar o acesso ao sistema de informações. IAM-05" Os controles nessa arquitetura são da CCM (Cloud Control Matrix ) da Cloud Security Alliance (CSA) e do MAFB (Microsoft Azure Foundations Benchmark ) pelo Centro de Segurança da Internet (CIS). Nos controles aplicados, o foco está nos principais princípios de design de segurança de governança, rede e segurança do aplicativo. É sua responsabilidade lidar com os princípios de design de Identidade, Gerenciamento de Acesso e Armazenamento conforme eles se relacionam com sua infraestrutura de destino.

Governança

O principal aspecto da governança que essa arquitetura aborda é a segregação por meio do isolamento de recursos de rede. No CCM, o DCS-08 recomenda o controle de entrada e saída para o datacenter. Para satisfazer o controle, a arquitetura utiliza um design hub e spoke, empregando 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 dentro da arquitetura.

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

ID do controle CCM do CSA	Domínio de Controle CCM do CSA
DCS-08	Entrada de pessoas não autorizadas de segurança do datacenter

Rede

O design de rede que dá suporte a essa arquitetura é derivado do modelo tradicional de hub e spoke. Essa decisão garante que o isolamento de rede seja uma construção fundamental. 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 o Firewall do Azure para tráfego norte-sul (fora do "data center"). O controle CCM IPY-04 recomenda que a infraestrutura utilize protocolos de rede seguros para a troca de dados entre serviços. Os serviços do Azure que dão 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 do controle CCM do CSA	Domínio de Controle CCM do CSA
IPY-04	Protocolos de rede
IVS-06	Segurança de Rede

A implementação da rede é ainda mais protegida com a definição de controles do MAFB. Os controles garantem que o tráfego para o 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 do controle CIS	Descrição do controle CIS
6.2	Verifique se o acesso SSH é restrito da Internet.
6.3	Certifique-se de que nenhum Banco de Dados SQL permita acesso 0.0.0.0/0 (QUALQUER IP).
6.5	Verifique se o Observador de Rede está 'Habilitado'.
6.6	Verifique se a entrada usando UDP é restrita da Internet.

O Azure Spring Apps requer tráfego de gerenciamento para saída do Azure quando implantado em um ambiente seguro. Você deve permitir as regras de rede e de aplicativo listadas nas responsabilidades do cliente para executar o Azure Spring Apps em uma rede virtual.

Segurança do aplicativo

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

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

ID de Controle do CCM CSA	Domínio de Controle CCM do CSA
EKM-01	Direito de criptografia e gerenciamento de chaves
EKM-02	Criptografia, gerenciamento de chaves e geração de chaves
EKM-03	Criptografia e proteção de dados confidenciais de gerenciamento de chaves
EKM-04	Criptografia e gerenciamento de chaves: armazenamento e acesso

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

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

ID do 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 ou informações confidenciais.
8.4	Certifique-se de 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 repositório de chaves possa ser restaurado para garantir a continuidade dos negócios.

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

Próximas etapas

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