O 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 princípios Well-Architected em todas as escolhas de projeto. Este artigo resume essas escolhas. A implementação do GitHub: Azure Kubernetes Service (AKS) Baseline Cluster for Regulated Workloads demonstra esses princípios, conforme aplicável.
As cargas de trabalho do PCI DSS 3.2.1 exigem o rigor de ser uma solução bem arquitetada. Embora o alinhamento da infraestrutura com os requisitos PCI seja fundamental, a conformidade não para na infraestrutura de hospedagem. Não abordar os pilares da qualidade, especificamente a segurança, pode comprometer a conformidade. Soluções bem arquitetadas combinam as perspetivas de infraestrutura e carga de trabalho para chegar ao rigor necessário para alcançar resultados compatíveis.
Segurança
Siga as orientações fundamentais fornecidas nos princípios de design de segurança. As práticas recomendadas para um ambiente regulamentado são resumidas nestas seções.
Governação
A implementação da governança é orientada pelos requisitos de conformidade do PCI-DSS 3.2.1. Isso influencia os controles técnicos para manter a segmentação, acessar recursos, detetar vulnerabilidades e, mais importante, proteger os dados dos clientes.
Estratégia de segmentação empresarial
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 políticas relacionadas do Azure em um nível de assinatura para capturar as políticas gerais 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. Estas políticas constroem os guarda-corpos centrais de uma zona de aterragem.
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 máquina virtual (VM) de nó.
Imposição de políticas
Imponha 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 permita alocações de IP público nos nós da VM. Essas alocações são detetadas e comunicadas ou bloqueadas.
Para obter informações sobre as políticas que você pode habilitar para o AKS, consulte Definições internas da Política do Azure para o Serviço Kubernetes do Azure.
O Azure fornece várias políticas internas para a maioria dos serviços. Reveja estas definições de política incorporadas da Política do Azure e aplique-as conforme apropriado.
Controlo da conformidade
O cumprimento deve ser sistematicamente controlado e mantido. São realizados atestados de conformidade regulares. Saber se seus recursos de nuvem estão em conformidade ajudará a se preparar para atestados e auditoria.
Aproveite o painel de conformidade regulatória no Microsoft Defender for Cloud. Ao monitorar continuamente o painel, você pode acompanhar o status de conformidade de sua carga de trabalho.
Segurança da 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 é ainda segmentada em sub-redes.
O cluster 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 de 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 é implantado como um cluster privado. Neste modo, o tráfego de e para a Internet pública é restrito. Até mesmo a comunicação com o servidor de API Kubernetes gerenciado pelo AKS é privada. A segurança é reforçada com controlos de rede rigorosos e regras de firewall IP.
- Grupos de Segurança de Rede (NSGs) para ajudar a proteger a comunicação entre recursos dentro de uma rede.
- Firewall do Azure para filtrar qualquer tráfego de saída entre recursos de nuvem, a Internet e no local.
- O Gateway de Aplicativo do Azure foi integrado à Estrutura de Aplicativo Web do Azure para filtrar todo o tráfego de entrada da Internet intercetado pelo Gateway de Aplicativo do Azure.
- Kubernetes NetworkPolicy para permitir apenas determinados caminhos entre os pods no cluster.
- Azure Private Link para se conectar a outros serviços de plataforma como serviço (PaaS) da plataforma Azure, como o Azure Key Vault e o Azure Container Registry para tarefas operacionais.
Estão em vigor processos de monitorização para garantir que o tráfego flui conforme esperado e que qualquer anomalia é detetada e comunicada.
Para obter detalhes sobre segurança de rede, consulte Segmentação de rede.
Segurança de dados
O PC-DSS 3.2.1 requer que todos os dados do titular do cartão (CHD) nunca sejam claros, 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. Aqui estão algumas recomendações bem arquitetadas.
Dados inativos
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.
- Escreva apenas dados encriptados no suporte 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 ativar 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. Certifique-se de que todos os dados são removidos com segurança quando o tempo configurado expirar.
O padrão também exige que os dados de autenticação confidenciais (SAD) não sejam armazenados. Certifique-se de que os dados não estão expostos em logs, nomes de arquivo, cache e outros dados.
Dados em trânsito
Toda a comunicação com entidades que interagem com o CDE deve ser feita através de canais encriptados.
- 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 pela 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 projetar políticas de acesso:
- Comece com políticas de confiança zero. Faça exceções conforme necessário.
- Conceda o mínimo de privilégios - apenas o suficiente para concluir uma tarefa.
- Minimize o acesso em pé.
O controle de acesso baseado em função (RBAC) do Kubernetes gerencia permissões para a API do Kubernetes. O AKS suporta essas funções do Kubernetes. O AKS está totalmente integrado com o Microsoft Entra ID. Você pode atribuir identidades do Microsoft Entra às funções e também aproveitar outros recursos.
Acesso Zero-Trust
Os serviços Kubernetes RBAC, Azure RBAC e Azure implementam negar tudo por padrão. Substitua essa configuração com cuidado, permitindo o acesso apenas às entidades que precisam dela. Outra área para implementar o Zero-Trust é 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 definir o escopo delas para as tarefas esperadas. Por exemplo, o Gateway de Aplicativo do Azure deve ter permissões para obter segredos (certificados TLS) do Cofre de Chaves do Azure. Ele não deve ter permissões para modificar segredos.
Minimização do acesso em pé
Minimize o acesso permanente usando a associação de grupo just-in-time do Microsoft Entra. Proteja o controle com Políticas de Acesso Condicional na ID do Microsoft Entra. Esta opção suporta muitos casos de uso, como autenticação multifator, restrição da autenticação a dispositivos gerenciados pelo locatário do Microsoft Entra ou bloqueio de tentativas de entrada atípicas.
Gestão de segredos
Armazene segredos, certificados, chaves e senhas fora do CDE. Você pode usar os segredos nativos do Kubernetes ou um armazenamento de chaves gerenciado, como o Azure Key Vault. O uso de um repositório gerenciado ajudará em tarefas secretas de gerenciamento, como rotação de chaves e renovação de certificados.
Certifique-se de que o acesso ao armazenamento de chaves tem um equilíbrio entre controles de rede e acesso. Quando você habilita identidades gerenciadas, o cluster precisa autenticar-se no Cofre da Chave para obter acesso. Além disso, a conectividade com o armazenamento de chaves não deve ser através da Internet pública. Use uma rede privada, como o Private Link.
Excelência Operacional
Siga as orientações fundamentais fornecidas nos princípios da Excelência Operacional. As práticas recomendadas para um ambiente regulamentado são resumidas nestas seções.
Separação de funções
É fundamental impor uma separação clara de funções para ambientes regulamentados. 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 SRE (engenheiro de confiabilidade do site) para operações relacionadas ao cluster e serviços dependentes. A função é responsável por manter a segurança, o isolamento, a implantação e a 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 a clusters, mas precisam de acesso de leitura a namespaces de carga de trabalho.
Isolamento de cargas de trabalho
O PC-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 os desenvolvedores para cargas de trabalho 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 à manutenção da conformidade e atestado, enquanto o código fora do escopo não está. Há também a necessidade de ter pipelines de construção separados e processos de gerenciamento de liberaçã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 pessoal. É altamente recomendável usar marcas do Azure porque você pode agrupar informações de 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é mesmo automatizar esse processo criando um catálogo de serviços. Ele fornece implantação de autosserviço 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.
Certifique-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 reparação
Os serviços de monitoramento do Azure, Azure Monitor e Microsoft Defender for Cloud, podem gerar notificações ou alertas quando detetam atividades anômalas. 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 analise o progresso. Recomendamos centralizar os dados em uma solução de gerenciamento de eventos e informações de segurança (SIEM) porque a integração de dados pode fornecer um contexto de alerta avançado.
Na visualização Alertas de segurança no Microsoft Defender for Cloud, você tem acesso a todos os alertas que o Microsoft Defender for Cloud deteta em seus recursos. Tenha um processo de triagem para resolver o problema. Trabalhe com sua equipe de segurança para entender como alertas relevantes serão disponibilizados aos 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 práticas recomendadas para um ambiente regulamentado são resumidas nestas seções.
Dimensionamento
Observar como o ambiente se ajusta às demandas em constante mudança indicará o comportamento de tempo de execução esperado do ambiente sob alta carga. O dimensionamento automático de recursos na carga de trabalho minimizará a interação humana no CDE. Um benefício adicional de segurança é reduzir a superfície de ataque em todos os momentos. Você pode maximizar o benefício aproveitando os recursos que suportam a abordagem de escala até zero. Por exemplo, o AKS suporta a redução dos pools de nós do usuário para 0. Para obter mais informações, consulte Dimensionar pools de nós de usuário para 0.
Criação de partições
O particionamento é um fator-chave para a eficiência de 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 componentes e controla o impacto do raio de jateamento em falhas inesperadas ou comprometimento do sistema.
Arquitetura de nada compartilhado
A arquitetura de nada compartilhado foi projetada para remover a contenção entre cargas de trabalho colocalizadas. Além disso, esta é uma estratégia para remover pontos únicos de falha. Em um ambiente regulamentado, os componentes devem ser isolados por limites lógicos ou físicos. Isso se alinha com a arquitetura de nada compartilhado, resultando em benefícios de escalabilidade. Além disso, permite direcionar os controles de segurança relevantes e recursos de auditoria mais rígidos dos vários componentes.
Estruturas leves
A complexidade das cargas de trabalho é difícil de documentar e auditar. Esforce-se pela simplicidade devido aos benefícios de desempenho e à facilidade de auditar os requisitos regulamentares. Avalie as escolhas que têm mais fôlego do que o necessário, porque isso aumenta a área da superfície de ataque e o potencial de mau uso ou configuração incorreta.
Fiabilidade
A fiabilidade dos ambientes regulamentados tem de ser previsível para que possa ser explicada de forma coerente para efeitos de auditoria. Siga as orientações fundamentais fornecidas nos princípios de confiabilidade. As práticas recomendadas para um ambiente regulamentado são resumidas nestas seções.
Metas de recuperação e recuperação de desastres
Devido à natureza sensível dos dados tratados em cargas de trabalho regulamentadas, as metas de recuperação e os RPOs (Recovery Point Objetives, objetivos de ponto de recuperação) são essenciais para definir. Qual é a perda aceitável de CHD? Os esforços de recuperação no âmbito 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 com funções, responsabilidades e acesso justificado a dados. As questões relacionadas com o sítio em direto não justificam o desvio de quaisquer regulamentos. Isso é especialmente importante em uma situação de recuperação de desastres completa. Tenha uma documentação clara de recuperação de desastres que atenda aos requisitos e minimize o acesso inesperado a CDE ou CHD. Após a recuperação, sempre revise as etapas do processo de recuperação para garantir que nenhum acesso inesperado tenha ocorrido. Documente justificativas comerciais 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. Desta 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.
Fazer face aos riscos relacionados com a 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 fiabilidade da carga de trabalho.
Processos operacionais
A fiabilidade estende-se a todos os processos operacionais dentro e adjacentes ao CDE. Processos bem definidos, automatizados e testados para preocupações como construção de imagens e fator de gerenciamento de caixa de salto em uma solução bem arquitetada.
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.
Aqui está 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 escala de máquina virtual que compõem os pools de nós e o Firewall do Azure. Outro contribuidor é o Log Analytics. Há também custos incrementais associados ao Microsoft Defender for Cloud, 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 monitorado. Aqui está 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 e/ou aplicativos. Outra maneira de otimizar o custo pode ser hospedar um cluster multilocatário dentro de uma organização, maximizando a densidade com a diversidade da carga de trabalho. Não recomendamos essa abordagem para cargas de trabalho regulamentadas. Sempre priorize a conformidade e a segmentação em detrimento do custo-benefício.
Para se manter dentro das restrições de orçamento, 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 eles ainda atendam à trilha de auditoria exigida pelo PCI-DSS 3.2.1. Sempre avalie essas escolhas em relação às compensações em outros aspetos do design que permitem que você cumpra seu SLA. Por exemplo, você ainda é capaz de dimensionar adequadamente para atender a picos de tráfego.
Ao criar grupos de recursos do Azure, aplique tags para que eles possam ser rastreados quanto ao custo. Use ferramentas de gerenciamento de custos como o Azure Advisor e o Microsoft Cost Management para acompanhar e analisar custos.
Considere habilitar a análise de custos do AKS para alocação granular de custos de infraestrutura de cluster por construções específicas do Kubernetes.