O Microsoft Azure Well-Architected Framework é um conjunto de princípios orientadores que podem ser usados para avaliar uma solução por meio dos pilares de qualidade da excelência da arquitetura:
Este artigo encerra esta série. Leia a introdução.
Esta orientação fornecida nesta série incorpora os princípios do Well-Architected em todas as opções de projeto. Este artigo resume essas opções. A implementação do Cluster de Linha de Base do GitHub: AKS (Azure Kubernetes Service) para carga de trabalho regulamentadas demonstra esses princípios, conforme aplicável.
As cargas de trabalho PCI DSS 3.2.1 exigem o rigor de ser uma solução bem arquitetada. Embora o alinhamento da infraestrutura com os requisitos do PCI seja fundamental, a conformidade não para na infraestrutura de hospedagem. Não abordar os pilares de qualidade, especificamente a segurança, pode comprometer a conformidade. Soluções bem arquitetadas combinam as perspectivas de infraestrutura e carga de trabalho para chegar ao rigor necessário para alcançar resultados em conformidade.
Confiabilidade
A confiabilidade dos ambientes regulamentados precisa ser previsível para que possam ser explicadas de forma consistente para fins de auditoria. Siga as orientações fundamentais fornecidas nos princípios de confiabilidade. As melhores práticas para um ambiente regulamentado são resumidas nestas seções.
Destinos de recuperação e recuperação de desastre
Devido à natureza sensível dos dados tratados em cargas de trabalho regulamentadas, é essencial definir metas de recuperação e objetivos de ponto de recuperação (RPOs). O que é uma perda aceitável de CHD? Os esforços de recuperação dentro do CDE ainda estão sujeitos aos requisitos padrão. Espere falhas e tenha um plano de recuperação claro para essas falhas que se alinhem às funções, responsabilidades e acesso justificado aos dados. Os problemas do site ao vivo não são justificados por se desviarem de quaisquer regulamentos. Essa ação é particularmente importante em uma situação de recuperação de desastre completa. Tenha uma documentação clara de recuperação de desastres que atenda aos requisitos e minimize o acesso inesperado de CDE ou CHD. Após a recuperação, sempre revise as etapas do processo de recuperação para garantir que não ocorreu nenhum acesso inesperado. Documente as justificativas de negócios para essas instâncias.
Recuperação
Adicionar estratégias de resiliência e recuperação à sua arquitetura pode evitar a necessidade de acesso ad hoc ao CDE. O sistema deve ser capaz de se auto-recuperar no RPO definido sem a necessidade de intervenção humana direta. Dessa forma, você pode eliminar a exposição desnecessária de CHD, mesmo para aqueles indivíduos que estão autorizados a ter acesso de emergência. O processo de recuperação deve ser auditável.
Lidando com riscos relacionados à segurança
Analise os riscos de segurança porque eles podem ser uma fonte de tempo de inatividade da carga de trabalho e perda de dados. Os investimentos em segurança também têm impacto na confiabilidade da carga de trabalho.
Processos operacionais
A confiabilidade se estende a todos os processos operacionais dentro e adjacentes ao CDE. Processos bem definidos, automatizados e testados para questões como construção de imagem e fator de gerenciamento de jumpbox em uma solução bem arquitetada.
Segurança
Siga as orientações fundamentais fornecidas nos Princípios e design de segurança. As melhores práticas para um ambiente regulamentado são resumidas nestas seções.
Governança
A implementação de governança é orientada pelos requisitos de conformidade no PCI-DSS 3.2.1. Isso influencia os controles técnicos para manter a segmentação, acessar recursos, detectar vulnerabilidades e, o mais importante, proteger os dados do cliente.
Estratégia de segmentação corporativa
Para manter o isolamento completo, recomendamos implantar a infraestrutura regulamentada em uma assinatura autônoma. Se você tiver várias assinaturas necessárias para conformidade, considere agrupá-las em uma hierarquia de grupo de gerenciamento que aplique as políticas relevantes do Azure uniformemente em suas assinaturas no escopo. Dentro da assinatura, aplique as políticas relacionadas do Azure em um nível de assinatura para capturar as políticas amplas que devem ser aplicadas a todos os clusters no ambiente de dados do titular do cartão (CDE). Aplique políticas relacionadas do Azure no nível do grupo de recursos para capturar políticas que se aplicam a uma instância de cluster específica. Essas políticas constroem as principais proteções de uma zona de destino.
Isole a carga de trabalho PCI (no escopo) de outras cargas de trabalho (fora do escopo) em termos de operações e conectividade. Você pode criar isolamento implantando clusters separados. Ou use estratégias de segmentação para manter a separação. Por exemplo, os clusters usam pools de nós separados para que as cargas de trabalho nunca compartilhem uma VM (máquina virtual) de nó.
Imposição de política
Impor controles de segurança habilitando as políticas do Azure. Por exemplo, nessa arquitetura regulamentada, você pode evitar a configuração incorreta do ambiente de dados do titular do cartão. Você pode aplicar uma política do Azure que não permite alocações de IP público nos nós de VM. Essas alocações são detectadas e relatadas ou bloqueadas.
Para obter informações sobre as políticas que você pode habilitar para o AKS, confira Definições internas do Azure Policy para o Serviço de Kubernetes do Azure.
O Azure fornece várias políticas internas para a maioria dos serviços. Revise essas definições de política interna do Azure Policy e aplique-as conforme apropriado.
Monitoramento de conformidade
A conformidade deve ser monitorada e mantida sistematicamente. Os atestados de conformidade regulares são executados. Saber se seus recursos de nuvem estão em conformidade ajudará a se preparar para atestados e auditorias.
Aproveite o painel de conformidade regulatória no Microsoft Defender para Nuvem. Ao monitorar continuamente o painel, você pode acompanhar o status de conformidade de sua carga de trabalho.
Segurança de rede
Em uma topologia hub-spoke, ter redes virtuais separadas para cada entidade fornece segmentação básica na área de cobertura da rede. Cada rede é segmentada ainda mais em sub-redes.
O cluster do AKS forma o núcleo do CDE. Ele não deve ser acessível a partir de endereços IP públicos e a conectividade deve ser protegida. Os fluxos típicos de entrada e saída do CDE podem ser categorizados como:
- Tráfego de entrada para o cluster.
- Tráfego de saída do cluster.
- Tráfego no cluster entre pods.
Para atender aos requisitos de um ambiente regulamentado, o cluster é implementado como um cluster privado. Nesse modo, o tráfego de e para a Internet pública é restrito. Até a comunicação com o servidor da API Kubernetes gerenciado pelo AKS é privada. A segurança é aprimorada ainda mais com controles de rede rígidos e regras de firewall de IP.
- Os NSGs (Grupos de Segurança de Rede) para ajudar a proteger a comunicação entre recursos dentro de uma rede.
- Use o Firewall do Azure para filtrar qualquer tráfego de saída entre recursos de nuvem, a Internet e o local.
- O Gateway de Aplicativo do Azure integrado ao Azure Web Application Framework para filtrar todo o tráfego de entrada da Internet que o Gateway de Aplicativo do Azure intercepta.
- Use o Kubernetes NetworkPolicy para permitir apenas determinados caminhos entre os pods no cluster.
- Use o Link Privado do Azure para se conectar a outros serviços de PaaS (plataforma como serviço) do Azure, como Azure Key Vault e Registro de Contêiner do Azure para tarefas operacionais.
Os processos de monitoramento estão em vigor para garantir que o tráfego flua conforme o esperado e que qualquer anomalia seja detectada e relatada.
Para obter detalhes sobre segurança de rede, consulte Segmentação de rede.
Segurança de dados
O PCI-DSS 3.2.1 exige que todos os dados do titular do cartão (CHD) nunca estejam em evidência, seja em trânsito ou em armazenamento.
Como essa arquitetura e a implementação são focadas na infraestrutura e não na carga de trabalho, o gerenciamento de dados não é demonstrado. Veja aqui algumas recomendações bem arquitetadas.
Dados em repouso
Os dados devem ser criptografados por meio de algoritmos de criptografia padrão do setor.
- Não armazene dados no ambiente do titular do cartão.
- Criptografe fora da camada de armazenamento.
- Grave apenas dados criptografados no meio de armazenamento.
- Não armazene as chaves na camada de armazenamento.
Todos os dados no Armazenamento do Azure são criptografados e descriptografados usando criptografia forte. As chaves de criptografia autogerenciadas são preferidas.
Se você precisar armazenar dados temporariamente, aplique as mesmas considerações a esses dados. É altamente recomendável habilitar o recurso de criptografia de host do AKS. Você pode impor a criptografia de dados temporários com políticas internas do Azure.
Ao escolher uma tecnologia de armazenamento, explore os recursos de retenção. Garanta que todos os dados sejam removidos com segurança quando o tempo configurado expirar.
O padrão também exige que os SAD (dados de autenticação confidenciais) não sejam armazenados. Verifique se os dados não estão expostos em logs, nomes de arquivos, cache e outros dados.
Dados em trânsito
Toda comunicação com entidades que interagem com o CDE deve ser por canais criptografados.
- Somente o tráfego HTTPS deve ter permissão para fluir para o CDE. Nessa arquitetura, o Gateway de Aplicativo do Azure nega todo o tráfego na porta 80.
- De preferência, não criptografe e descriptografe dados fora do CDE. Se o fizer, considere essa entidade como parte do CDE.
- Dentro do CDE, forneça comunicação segura entre pods com mTLS. Você pode optar por implementar uma malha de serviço para essa finalidade.
- Permita apenas cifras seguras e TLS 1.2 ou posterior.
Identidade
Siga estes princípios de segurança ao elaborar políticas de acesso:
- Comece com as políticas de Confiança Zero. Faça exceções conforme necessário.
- Conceda o mínimo de privilégios – o suficiente para concluir uma tarefa.
- Minimize o acesso permanente.
O RBAC (controle de acesso baseado em função) do Kubernetes gerencia permissões para a API do Kubernetes. O AKS dá suporte a essas funções do Kubernetes. O AKS é totalmente integrado ao Microsoft Entra ID. Você pode atribuir identidades do Microsoft Entra às funções e também aproveitar outros recursos.
Acesso de Confiança Zero
Os serviços de RBAC do Kubernetes, o Azure RBAC e o Azure implementam negar tudo por padrão. Substitua essa configuração com cuidado, permitindo o acesso apenas às entidades que precisam. Outra área para implementar a Confiança Zero é desabilitar o acesso SSH aos nós do cluster.
Privilégios mínimos
Você pode usar identidades gerenciadas para recursos e pods do Azure e defini-los para as tarefas esperadas. Por exemplo, o Gateway de Aplicativo do Azure precisa ter permissões para obter segredos (certificados TLS) do Azure Key Vault. Ele não pode ter permissões para modificar segredos.
Minimizando o acesso permanente
Minimize o acesso permanente usando a associação de grupo do Microsoft Entra just-in-time. Reforce o controle com Políticas de Acesso condicional no Microsoft Entra ID. Essa opção dá suporte a muitos casos de uso, como autenticação multifator, restrição de autenticação a dispositivos gerenciados por seu locatário do Microsoft Entra ou bloqueio de tentativas de entrada atípicas.
Gerenciamento de segredos
Armazene segredos, certificados, chaves e senhas fora do CDE. Você pode usar objetos secretos nativos do Kubernetes ou um repositório de chaves gerenciado, como o Azure Key Vault. O uso de um repositório gerenciado ajudará nas tarefas de gerenciamento de segredos, como rotação de chaves e renovação de certificados.
Certifique-se de que o acesso ao armazenamento de chaves tenha uma combinação de controles de rede e acesso. Quando você habilita identidades gerenciadas, o cluster precisa se autenticar no Key Vault para obter acesso. Adicionalmente, a conectividade com o armazenamento de chaves não deve ser feita pela Internet pública. Use uma rede privada, como Link Privado.
Otimização de custos
Siga as orientações fundamentais fornecidas nos Princípios de Otimização de Custos.
Devido aos requisitos de conformidade e controles de segurança rigorosos, uma compensação clara é o custo. Recomendamos que você estabeleça estimativas iniciais usando a Calculadora de Preços.
Veja aqui uma representação de alto nível do impacto de custo dos principais recursos que essa arquitetura usa.
Os principais drivers são os conjuntos de dimensionamento de máquinas virtuais que compõem os pools de nós e o Firewall do Azure. Outro colaborador é a Análise de logs. Há também custos incrementais associados ao Microsoft Defender para Nuvem, dependendo da sua escolha de planos.
Ter uma compreensão clara do que constitui o preço de um serviço. O Azure rastreia o uso medido. Veja aqui um detalhamento do Firewall do Azure para essa arquitetura.
O custo associado a alguns recursos, como o Firewall do Azure, pode ser distribuído por várias unidades de negócios ou aplicativos. Outra maneira de otimizar o custo pode ser hospedar um cluster multilocatário em uma organização, maximizando a densidade com a diversidade da carga de trabalho. No entanto, não recomendamos essa abordagem para cargas de trabalho regulamentadas. Sempre priorize a conformidade e a segmentação sobre os benefícios de custo.
Para manter as restrições orçamentárias, algumas maneiras de controlar o custo são ajustando a infraestrutura do Gateway de Aplicativo do Azure, definindo a contagem de instâncias para dimensionamento automático e reduzindo a saída de log, desde que ainda atendam à trilha de auditoria exigida pelo PCI-DSS 3.2.1. Sempre avalie essas escolhas em relação às compensações em outros aspectos do design que permitem que você atenda ao seu SLA. Por exemplo, você ainda consegue dimensionar adequadamente para atender aos picos de tráfego?
À medida que você cria grupos de recursos do Azure, aplique marcas para que possam ser rastreadas quanto ao custo. Use ferramentas de gerenciamento de custos como Assistente do Azure e Gerenciamento de Custos da Microsoft para rastrear e analisar custos.
Habilite a análise de custo do AKS para alocação de custos de infraestrutura de cluster granular por construções específicas do Kubernetes.
Excelência operacional
Siga as orientações fundamentais fornecidas nos Princípios de Excelência Operacional. As melhores práticas para um ambiente regulamentado são resumidas nestas seções.
Separação de funções
Impor a segregação clara de direitos para ambientes regulamentados é fundamental. Ter definições de papéis e responsabilidades com base nas necessidades da carga de trabalho e interação com o CDE. Por exemplo, você pode precisar de uma função de operador de infraestrutura ou engenheiro de confiabilidade do site (SRE) para operações relacionadas ao cluster e serviços dependentes. A função é responsável por manter a segurança, isolamento, implantação e observabilidade. Formalize essas definições e decida as permissões de que essas funções precisam. Por exemplo, os SREs são altamente privilegiados para acesso ao cluster, mas precisam de acesso de leitura aos namespaces de carga de trabalho.
Isolamento de carga de trabalho
O PCI-DSS 3.2.1 requer o isolamento da carga de trabalho PCI de outras cargas de trabalho em termos de operações. Nesta implementação, as cargas de trabalho dentro e fora do escopo são segmentadas em dois pools de nós de usuário separados. Os desenvolvedores de aplicativos para cargas de trabalho dentro do escopo e fora do escopo podem ter diferentes conjuntos de permissões. Além disso, haverá portões de qualidade separados. Por exemplo, o código dentro do escopo está sujeito a manter a conformidade e atestado, enquanto o código fora do escopo não está. Também é necessário ter pipelines de build separados e processos de gerenciamento de versão.
Metadados operacionais
O requisito 12 do padrão PCI DSS 3.2.1 exige que você mantenha informações sobre inventário de carga de trabalho e documentação de acesso de pessoal. É altamente recomendável usar as marcas do Azure porque você pode reunir informações do ambiente com recursos, grupos de recursos e assinaturas do Azure.
Mantenha informações sobre soluções aprovadas que fazem parte da infraestrutura e da carga de trabalho. Isso inclui uma lista de imagens de VM, bancos de dados e soluções de terceiros de sua escolha que você traz para o CDE. Você pode até automatizar esse processo criando um catálogo de serviços Ele fornece implantação de autoatendimento usando essas soluções aprovadas em uma configuração específica, que adere às operações contínuas da plataforma.
Observabilidade
Para cumprir o Requisito 10, a observabilidade no CDE é fundamental para a conformidade. Os logs de atividades fornecem informações sobre operações relacionadas ao gerenciamento de contas e segredos, gerenciamento de configurações de diagnóstico, gerenciamento de servidores e outras operações de acesso a recursos. Todos os logs são registrados com data, hora, identidade e outras informações detalhadas. Retenha logs por até um ano configurando políticas de retenção e arquivamento de dados nos Logs do Azure Monitor.
Lembre-se de que os logs sejam acessados apenas por funções que precisam deles. O Log Analytics e o Microsoft Sentinel oferecem suporte a vários controles de acesso baseados em função para gerenciar o acesso à trilha de auditoria.
Resposta e correção
Os serviços de monitoramento do Azure, Azure Monitor e Microsoft Defender para Nuvem, podem gerar notificações ou alertas quando detectam atividades anormais. Esses alertas incluem informações de contexto, como gravidade, status e tempo de atividade. À medida que os alertas são gerados, tenha uma estratégia de correção e revise o progresso. Recomendamos centralizar os dados em uma solução de gerenciamento de informações e eventos de segurança (SIEM), pois a integração de dados pode fornecer um contexto de alerta rico.
Na exibição de Alertas de segurança no Microsoft Defender para Nuvem, você tem acesso a todos os alertas que o Microsoft Defender for Cloud detecta em seus recursos. Tenha um processo de triagem para resolver o problema. Trabalhe com sua equipe de segurança para entender como os alertas relevantes serão disponibilizados para os proprietários da carga de trabalho.
Eficiência de desempenho
Siga as orientações fundamentais fornecidas nos Princípios de Eficiência de Desempenho. As melhores práticas para um ambiente regulamentado são resumidas nestas seções.
Dimensionamento
Observar como o ambiente se ajusta às demandas em mudança indicará o comportamento de tempo de execução esperado do ambiente sob alta carga. Os recursos de dimensionamento automático na carga de trabalho minimizarão a interação humana no CDE. Um benefício de segurança adicional é reduzir a superfície de ataque o tempo todo. Você pode maximizar o benefício aproveitando os recursos que suportam a abordagem de escala para zero. Por exemplo, o AKS dá suporte à redução dos pools de nós do usuário para 0. Para obter mais informações, confira Dimensionar pools de nós de usuário para 0.
Particionamento
O particionamento é um fator chave para a eficiência do desempenho em cargas de trabalho regulamentadas. Ter componentes discretos permite uma definição nítida de responsabilidade e ajuda em controles precisos, como políticas de rede. Semelhante a qualquer estratégia de segmentação, o particionamento isola os componentes e controla o impacto do raio de explosão em falhas inesperadas ou comprometimento do sistema.
Arquitetura sem compartilhamento
A arquitetura compartilhada de dados inexistentes foi projetada para remover a contenção entre cargas de trabalho colocadas. Além disso, esta é uma estratégia para remover pontos únicos de falha. Em um ambiente regulamentado, os componentes precisam ser isolados por limites lógicos ou físicos. Isso se alinha com a arquitetura compartilhada de dados inexistentes, resultando em benefícios de escalabilidade. Além disso, permite o direcionamento de controles de segurança relevantes e recursos de auditoria mais rígidos dos vários componentes.
Cargas de trabalho leves
A complexidade das cargas de trabalho é difícil de documentar e auditar. Prime pela simplicidade devido aos benefícios de desempenho e à facilidade de auditoria dos requisitos regulamentares. Reconsidere escolhas que tenham mais amplitude do que o necessário, porque isso aumenta a área de superfície de ataque e o potencial de uso indevido ou configuração incorreta.