Práticas recomendadas para multilocação empresarial

A multilocação no Google Kubernetes Engine (GKE) se refere a um ou mais clusters compartilhados entre locatários. No Kubernetes, um locatário pode ser definido como:

  • uma equipe responsável por desenvolver e operar uma ou mais cargas de trabalho;
  • um conjunto de cargas de trabalho relacionadas, operadas por uma ou mais equipes;
  • uma única carga de trabalho, como uma implantação.

A multilocação de clusters geralmente é implementada para reduzir custos ou aplicar consistentemente políticas de administração a locatários. No entanto, configurar incorretamente um cluster do GKE ou os recursos associados do GKE pode resultar na diminuição da economia de custos, aplicação incorreta de políticas ou interações destrutivas entre cargas de trabalho de diferentes locatários.

Neste guia, apresentamos as práticas recomendadas para configurar com segurança e eficiência vários clusters de multilocação para uma organização empresarial.

Pressuposições e requisitos

As práticas recomendadas neste guia são baseadas em um caso de uso de multilocação para um ambiente empresarial com as pressuposições e os requisitos a seguir:

  • A organização é uma empresa com vários locatários (dois ou mais equipes de aplicativos/serviços) que usam o Kubernetes e gostariam de compartilhar recursos administrativos e de computação.
  • Cada locatário é uma equipe que desenvolve uma carga de trabalho.
  • Além das equipes de aplicativos/serviços, há outros grupos que também usam e gerenciam clusters, incluindo membros da equipe de plataforma, administradores de cluster, auditores etc.
  • A equipe da plataforma é proprietária dos clusters e define a quantidade de recursos que cada equipe de locatário pode usar. Cada locatário pode solicitar mais.
  • Cada equipe de locatário deve ser capaz de implantar o aplicativo com a API Kubernetes sem precisar se comunicar com a equipe da plataforma.
  • Locatários não podem afetar outros locatários no cluster compartilhado, exceto por meio de decisões de design explícitas, como chamadas de API, fontes de dados compartilhadas etc.

Essa configuração servirá como um modelo na demonstração das práticas recomendadas para multilocatários. Embora essa configuração não descreva perfeitamente todas as organizações empresariais, ela pode ser facilmente estendida para abranger cenários semelhantes.

Como configurar pastas, projetos e clusters

Práticas recomendadas:

Estabeleça uma hierarquia de pastas e projetos.
Atribua papéis por meio do IAM.
Centralizar o controle de rede com VPCs compartilhadas.
Criar um projeto de administração de cluster por cluster.
Tornar os grupos particulares.
Verificar se o plano de controle do cluster é regional.
Verificar se os nós no cluster abrangem pelo menos três zonas.
Realizar o escalonamento automático de nós e recursos do cluster.
Programar janelas de manutenção para horários de pico.
Configure um balanceador de carga de aplicativo externo com o Ingress.

Para organizações empresariais que implantam clusters multilocatários no GKE, é necessária uma configuração extra em outros sistemas do Google Cloud para gerenciar a complexidade que não existe em implantações mais simples, com um aplicativo e uma equipe. Isso inclui configurar o projeto para isolar questões administrativas e mapear a estrutura organizacional para identidades e contas na nuvem, assim como gerenciar outros recursos do Google Cloud, como bancos de dados, monitoramento e geração de registros, armazenamento e rede.

Estabelecer uma hierarquia de pastas e projetos

Use pastas e projetos para entender como sua organização gerencia recursos do Google Cloud e separar os interesses. As pastas permitem que diferentes equipes definam políticas em cascata em vários projetos, enquanto os projetos podem ser usados para separar ambientes (por exemplo, produção e preparação) e equipes. Por exemplo, a maioria das organizações tem uma equipe para gerenciar a infraestrutura de rede e uma equipe diferente para gerenciar clusters. Cada tecnologia é considerada uma peça separada da pilha, que exige níveis de especialidade, solução de problemas e acesso próprios.

Uma pasta mãe pode conter até 300 pastas, e essas pastas podem ser aninhadas com até 10 níveis de profundidade. Se você tiver mais de 300 locatários, organize os locatários em hierarquias aninhadas para permanecer dentro do limite. Para mais informações sobre pastas, consulte Como criar e gerenciar pastas.

Como atribuir papéis usando o IAM

Controle o acesso aos recursos do Google Cloud por meio de políticas do IAM. Comece identificando os grupos necessários para sua organização e o escopo das operações. Em seguida, atribua o papel apropriado do IAM ao grupo.

Use os Grupos do Google para atribuir e gerenciar com eficiência o IAM a usuários.

Centralizar o controle da rede

Use redes VPC compartilhadas para manter o controle centralizado de recursos de rede, como sub-redes, rotas e firewalls. Os recursos em uma VPC compartilhada podem se comunicar de forma segura e eficiente entre os limites do projeto usando IPs internos. Cada rede VPC compartilhada é definida e pertence a um projeto host centralizado e pode ser usada por um ou mais projetos de serviço.

Com a VPC compartilhada e o IAM, é possível separar a administração da rede da administração do projeto. Essa separação ajuda a implementar o princípio do menor privilégio. Por exemplo, uma equipe de rede centralizada pode administrar a rede sem ter nenhuma permissão nos projetos participantes. Da mesma forma, os administradores de projeto podem gerenciar os recursos deles no projeto sem nenhuma permissão para manipular a rede compartilhada.

Ao configurar uma VPC compartilhada, você precisa configurar as sub-redes e os intervalos de IP secundários na VPC. Para determinar o tamanho da sub-rede, você precisa saber o número esperado de locatários, o número de pods e Serviços que devem ser executados e o tamanho máximo e médio de pods. Calcular a capacidade total necessária do cluster permitirá compreender o tamanho de instância desejado, o que por sua vez determina a contagem total de nós. Com o número total de nós, é possível calcular o espaço total de IP consumido, o que informa o tamanho de sub-rede desejado.

Veja alguns fatores a se considerar ao configurar sua rede:

  • O número máximo de projetos de serviço que podem ser anexados a um projeto host é 1.000, e o número máximo de projetos host de VPC compartilhada em uma única organização é 100.
  • Os intervalos de IP de nó, pod e Serviços precisam ser exclusivos. Não é possível criar uma sub-rede com intervalos de endereço de IP primário e secundário que se sobreponham.
  • O número máximo de pods e serviços para um determinado cluster do GKE é limitado pelo tamanho dos intervalos secundários do cluster.
  • O número máximo de nós no cluster é limitado pelo tamanho do intervalo de endereços IP primário da sub-rede do cluster e do intervalo de endereços do pod do cluster.
  • Para ter mais flexibilidade e controle sobre o gerenciamento de endereços IP, configure o número máximo de pods que podem ser executados em um nó. Ao reduzir o número de pods por nó, você também reduz o intervalo CIDR alocado por nó, exigindo menos endereços IP.

Para calcular sub-redes para seus clusters, use a calculadora de IPAM do GKE (em inglês), uma ferramenta de código aberto. O gerenciamento de endereços IP (IPAM, na sigla em inglês) permite usar espaços/sub-redes de IP de maneira eficiente e impede sobreposições de intervalos, o que evita opções de conectividade no futuro. Para informações sobre intervalos de rede em um cluster de VPC, consulte Como criar um cluster nativo de VPC.

Os locatários que exigem mais isolamento para recursos executados fora dos clusters compartilhados (como VMs dedicadas do Compute Engine) podem usar VPCs próprias, que fazem peering para a VPC compartilhada executada pela equipe de rede. Isso proporciona mais segurança, mas também aumenta a complexidade e traz várias outras limitações. Para mais informações sobre peering, consulte Como usar peering de rede VPC. No exemplo abaixo, todos os locatários escolheram compartilhar uma única VPC de locatário (por ambiente).

Como criar clusters confiáveis e altamente disponíveis

Implemente as recomendações a seguir para que a arquitetura do cluster tenha alta disponibilidade e confiabilidade:

  • Crie um projeto de administração de cluster por cluster para reduzir o risco de configurações no nível do projeto (por exemplo, vinculações do IAM) afetarem negativamente muitos clusters e para ajudar a fornecer separação de cotas e faturamento. Os projetos de administração de clusters são separados dos projetos de locatário, que locatários individuais usam para gerenciar, por exemplo, recursos do Google Cloud.
  • Torne o cluster de produção particular para desativar o acesso aos nós e gerenciar o acesso ao plano de controle. Também recomendamos usar clusters particulares para ambientes de desenvolvimento e preparação.
  • Confira se o plano de controle do cluster é regional para fornecer alta disponibilidade para multilocação. Qualquer interrupção no plano de controle afetará os locatários. Executar clusters regionais tem implicações no custo. Os clusters do Autopilot são pré-configurados como clusters regionais.
  • Verifique se os nós do cluster abrangem pelo menos três zonas para atingir a confiabilidade zonal. Para informações sobre o custo de saída entre zonas na mesma região, consulte a documentação de preços de rede.
Um cluster regional particular com um plano de controle regional em execução em três zonas
Figura 3: um cluster regional particular com um plano de controle regional em execução em três zonas.

Escalonamento automático de nós e recursos do cluster

Para acomodar as demandas dos seus locatários, ative o escalonamento automático para escalonar automaticamente os nós no cluster.

O escalonamento automático ajuda os sistemas a parecerem responsivos e íntegros quando cargas de trabalho pesadas são implantadas por vários locatários nos namespaces ou para responder a interrupções zonais.

Com os clusters do Autopilot, os pools de nós são escalonados automaticamente para atender aos requisitos das cargas de trabalho.

Ao ativar o escalonamento automático, você especifica o número mínimo e máximo de nós em um cluster com base nos tamanhos de carga de trabalho esperados. Ao especificar o número máximo de nós, você garante que haja espaço suficiente para todos os pods no cluster, independentemente do namespace em que eles são executados. O escalonamento automático de clusters redefine os pools de nós com base nos limites mínimo e máximo, ajudando a reduzir custos operacionais quando a carga do sistema diminui e evitando que pods fiquem pendentes quando não há recursos suficientes disponíveis. Para determinar o número máximo de nós, identifique a quantidade máxima de CPU e a memória exigida por cada locatário e adicione esses valores à capacidade total que o cluster poderá manipular caso todos os locatários estejam no limite. Usando o número máximo de nós, é possível escolher tamanhos e contagens de instâncias, considerando o espaço de sub-rede IP disponibilizado para o cluster.

Use o escalonamento automático de pods para escalonar automaticamente pods com base nas demandas de recursos. O escalonador automático de pod horizontal (HPA, na sigla em inglês) escalona o número de réplicas de pod com base na utilização da CPU/memória ou nas métricas personalizadas. O escalonamento automático do pod vertical (VPA, na sigla em inglês) pode ser usado para escalonar automaticamente as demandas de recursos de pods. Ele não deve ser usado com o HPA, a menos que métricas personalizadas estejam disponíveis, porque os dois escalonadores automáticos podem competir entre si. Por isso, comece com o HPA e use o VPA somente quando necessário.

Determinar o tamanho do cluster

Aqui estão alguns fatores importantes a serem considerados quando você for determinar o tamanho do cluster:

  • O dimensionamento do cluster depende do tipo de cargas de trabalho que você planeja executar. Se as cargas de trabalho tiverem maior densidade, o gasto será mais eficiente, mas também haverá uma chance maior de contenção de recursos.
  • O tamanho mínimo de um cluster é definido pelo número de zonas que ele engloba: um nó para um cluster zonal e três nós para um cluster regional.
  • Por projeto, há um máximo de 50 clusters por zona, além de 50 clusters regionais por região.
  • Por cluster, há no máximo 15.000 nós por cluster (5.000 para versões do GKE até 1.17), 1.000 nós por pool de nós, 1.000 nós por cluster (se você usar o controlador de entrada do GKE), 256 pods por nó (110 para versões do GKE anteriores à 1.23.5-gke.1300), 150.000 pods por cluster e 300.000 contêineres por cluster. Consulte a página Cotas e limites para mais informações.

Programar janelas de manutenção

Para reduzir a inatividade durante upgrades e manutenção de clusters/nós, programe janelas de manutenção fora do horário de pico. Durante os upgrades, pode haver interrupções temporárias quando cargas de trabalho forem movidas para recriar nós. Para garantir que essas interrupções tenha o mínimo de impacto, programe upgrades para horários de pico e projete as implantações de aplicativos para lidar com interrupções parciais sem problemas, se possível.

Configurar um balanceador de carga de aplicativo externo com a Entrada

Para ajudar no gerenciamento dos Serviços publicados pelos locatários e no gerenciamento do tráfego de entrada para esses Serviços, crie um balanceador de carga HTTP(s) para permitir uma única entrada por cluster, em que os serviços de cada locatário são registrados com o recurso de Entrada do cluster. É possível criar e configurar um balanceador de carga HTTP(S) criando um recurso de Entrada do Kubernetes, que define como o tráfego chega aos Serviços e como o tráfego é roteado para o aplicativo do locatário. Ao registrar Serviços com o recurso de Entrada, a convenção de nomenclatura dos Serviços se torna consistente, mostrando uma única entrada, como tenanta.example.com e tenantb.example.com.

Como proteger o cluster para multilocação

Práticas recomendadas:

Controle a comunicação de pods com políticas de rede.
Executar cargas de trabalho com o GKE Sandbox.
Configurar controles de admissão com base em políticas
Use a federação de identidade da carga de trabalho do GKE para conceder acesso aos serviços do Google Cloud.
Restringir o acesso de rede ao plano de controle.

Controlar a comunicação de pods com políticas de rede

Para controlar a comunicação de rede entre pods em cada um dos namespaces do cluster, crie políticas de rede com base nos requisitos dos locatários. Como recomendação inicial, bloqueie o tráfego entre namespaces que hospedam aplicativos de diferentes locatários. O administrador do cluster pode aplicar uma política de rede deny-all para negar todo o tráfego de entrada e evitar que pods de um namespace enviem tráfego acidentalmente para Serviços ou bancos de dados em outros namespaces.

Como exemplo, veja uma política de rede que restringe a entrada de todos os outros namespaces para o namespace tenant-a:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

Executar cargas de trabalho com o GKE Sandbox

Clusters que executam cargas de trabalho não confiáveis estão mais expostos a vulnerabilidades de segurança do que os outros. Com o GKE Sandbox, é possível consolidar limites de isolamento entre cargas de trabalho do ambiente multilocatário. Para o gerenciamento de segurança, recomendamos começar com o GKE Sandbox e depois usar controles de admissão com base em políticas para preencher as lacunas.

O GKE Sandbox é gVisor (em inglês), um projeto de sandbox de contêineres de código aberto, e isola cargas de trabalho multilocatárias ainda mais adicionando uma camada extra entre seus contêineres e o sistema operacional do host. Os ambientes de execução de contêiner geralmente são executados como um usuário privilegiado no nó e têm acesso à maioria das chamadas do sistema no kernel do host. Em um cluster multilocatário, um locatário mal-intencionado pode ter acesso ao kernel do host e aos dados de outro locatário. O GKE Sandbox diminui essas ameaças, mitigando a necessidade de os contêineres interagirem com o host, reduzindo a superfície de ataque do host e restringindo o movimento de agentes mal-intencionados.

O GKE Sandbox fornece dois limites de isolamento entre o contêiner e o sistema operacional do host:

  • Um kernel do espaço do usuário, escrito em Go, que processa chamadas do sistema e limita a interação com o kernel do host. Cada pod tem o próprio kernel isolado de espaço do usuário.
  • O kernel do espaço do usuário também é executado em namespaces e separa as chamadas do sistema de filtragem.

Configurar controles de admissão com base em políticas

Para evitar que pods que violam seus limites de segurança sejam executados no cluster, use um controlador de admissão. Os controladores de admissão podem verificar as especificações do pod em relação às políticas definidas por você e impedir que pods que violam essas políticas sejam executados no cluster.

O GKE aceita os seguintes tipos de controle de admissão:

Usar a federação de identidade da carga de trabalho do GKE para conceder acesso aos serviços do Google Cloud

Para conceder às cargas de trabalho acesso aos serviços do Google Cloud com segurança, ative a federação de identidade da carga de trabalho para o GKE no cluster. A federação de identidade da carga de trabalho para GKE ajuda os administradores a gerenciar contas de serviço do Kubernetes que as cargas de trabalho do Kubernetes usam para acessar os serviços do Google Cloud. Quando você cria um cluster com a federação de identidade da carga de trabalho para GKE ativada, um namespace de identidade é estabelecido para o projeto em que o cluster está hospedado. O namespace de identidade permite que o cluster autentique automaticamente contas de serviço para aplicativos do GKE ao mapear o nome da conta de serviço do Kubernetes para um identificador de conta de serviço do Google virtual, usado para vinculação de contas de serviço de locatário do Kubernetes.

Restringir o acesso de rede ao plano de controle

Para proteger seu plano de controle, restrinja o acesso a redes autorizadas. No GKE, ao ativar as redes autorizadas, será possível autorizar até 50 intervalos CIDR e permitir que apenas os endereços IP nesses intervalos acessem seu plano de controle. O GKE já usa o Transport Layer Security (TLS) e a autenticação para fornecer acesso seguro ao endpoint do plano de controle a partir da Internet pública. Ao usar redes autorizadas, será possível restringir ainda mais o acesso a conjuntos específicos de endereços IP.

Provisionamento de locatários

Práticas recomendadas:

Crie projetos de locatário.
Usar o RBAC para refinar o acesso de locatários.
Criar namespaces para isolar locatários.

Criar projetos de locatário

Para hospedar recursos de um locatário que não são de cluster, crie um projeto de serviço para cada locatário. Esses projetos de serviço contêm recursos lógicos específicos para os aplicativos de locatário (por exemplo, registros, monitoramento, buckets de armazenamento, contas de serviço etc.). Todos os projetos de serviço de locatário estão conectados à VPC compartilhada no projeto do host do locatário.

Usar o RBAC para refinar o acesso de locatários

Use o Kubernetes RBAC (em inglês) para definir um acesso mais preciso aos recursos de cluster para seus locatários. Além do acesso somente leitura concedido inicialmente com o IAM a grupos de locatários, defina as vinculações e os papéis RBAC do Kubernetes em todo o namespace para cada grupo de locatários.

Anteriormente, identificamos dois grupos de locatários: administradores e desenvolvedores. Para esses grupos, definimos o acesso e os papéis RBAC a seguir:

Grupo Papel RBAC
do Kubernetes		 Descrição
Locatário administrador Administrador de namespace

Concede acesso para listar e monitorar implantações no namespace.

Concede acesso para adicionar e remover usuários no grupo de locatários.
Locatário desenvolvedor editor de namespace,
visualizador de namespace		 Concede acesso para criar/editar/excluir pods, implantações, Serviços e configmaps no namespace.

Além de criar papéis e vinculações do RBAC que atribuem várias permissões aos grupos do Google Workspace ou do Cloud Identity nos namespaces, os locatários administradores geralmente precisam gerenciar usuários em cada um desses grupos. Com base nos requisitos de sua organização, o locatário administrador pode receber as permissões do Google Workspace ou do Cloud Identity para gerenciar a própria assinatura do grupo ou pode interagir com uma equipe da sua organização que tenha permissões do Google Workspace ou do Cloud Identity para lidar com essas alterações.

É possível usar as permissões do IAM e do RBAC em conjunto com namespaces para restringir interações de usuários com recursos de cluster no console do Google Cloud. Saiba mais em Ativar acesso e visualização de recursos do cluster por namespace.

Usar Grupos do Google para vincular permissões

Para gerenciar com eficiência as permissões de locatário em um cluster, vincule as permissões do RBAC aos seus Grupos do Google. A associação desses grupos é mantida pelos administradores do Google Workspace, portanto, os administradores do cluster não precisam de informações detalhadas sobre os usuários.

Como exemplo, temos um Grupo do Google chamado tenant-admins@mydomain.com e um usuário chamado admin1@mydomain.com que é membro desse grupo. A vinculação a seguir concede ao usuário acesso de administrador ao namespace tenant-a:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

Criar namespaces

Para ter um isolamento lógico entre locatários do mesmo cluster, implemente namespaces (em inglês). Como parte do processo do RBAC do Kubernetes, o administrador do cluster cria namespaces para cada grupo de locatários. O locatário administrador gerencia usuários (locatários desenvolvedores) no respectivo namespace do locatário. Em seguida, os locatários desenvolvedores podem usar recursos específicos do cluster e de locatários para implantar seus aplicativos.

Como não atingir os limites de namespaces

Teoricamente, o número máximo de namespaces em um cluster é 10.000, mas, na prática, há muitos fatores que podem impedir que você atinja esse limite. Por exemplo, é possível alcançar o número máximo de pods (150.000) e nós (5.000) em todo o cluster antes de atingir o número máximo de namespaces. Outros fatores (como o número de secrets) podem reduzir ainda mais os limites efetivos. Como resultado, uma boa regra inicial é tentar se aproximar apenas do limite teórico de uma restrição por vez e ficar manter-se aproximadamente a uma ordem de amplitude de distância dos outros limites, a menos que a experimentação mostre que seus casos de uso funcionam bem. Se você precisar de mais recursos do que o número aceito por um cluster, crie mais clusters. Para informações sobre a escalonabilidade do Kubernetes, consulte o artigo Limites de escalonabilidade do Kubernetes (em inglês).

Padronização de nomes de namespaces

Para facilitar implantações em vários ambientes hospedados em clusters diferentes, padronize a nomenclatura de namespaces que você usa. Por exemplo, evite vincular o nome do ambiente (desenvolvimento, preparação e produção) ao nome do namespace e, em vez disso, use o mesmo nome em todos os ambientes. Ao usar o mesmo nome, você evita ter que alterar os arquivos config nos ambientes.

Criar contas de serviço para cargas de trabalho de locatários

Crie uma conta de serviço do Google específica para locatário para cada carga de trabalho distinta em um namespace de locatário. Isso dá mais segurança, garantindo que os locatários possam gerenciar contas de serviço para as cargas de trabalho que têm/implantam nos próprios namespaces. A conta de serviço do Kubernetes de cada namespace é associada a uma conta de serviço do Google usando a federação de identidade da carga de trabalho do GKE.

Aplicar cotas de recursos

Para garantir que todos os locatários que compartilham um cluster tenham acesso justo aos recursos do cluster, aplique cotas de recursos (em inglês). Crie uma cota de recursos para cada namespace de acordo com o número de pods implantados por cada locatário e a quantidade de memória e CPU necessárias para cada pod.

O exemplo a seguir define uma cota de recursos em que os pods no namespace tenant-a podem solicitar até 16 CPU e 64 GB de memória, a CPU máxima é 32 e a memória máxima é 72 GB.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Monitoramento, geração de registros e uso

Práticas recomendadas:

Rastrear métricas de uso.
Informar registros específicos do locatário.

Rastrear métricas de uso

Para detalhar os custos de namespaces e rótulos individuais em um cluster, ative a alocação de custos do GKE. A alocação de custos do GKE rastreia informações sobre solicitações e uso de recursos de cargas de trabalho de um cluster, que podem ser divididas por namespaces e rótulos. Com a alocação de custos do GKE, é possível detalhar custos de departamentos/equipes que compartilham um cluster, compreender padrões de uso de aplicativos individuais ou até mesmo componentes de um único aplicativo, ajudar administradores a clusters a testar picos de uso e melhorar a capacidade planejamento e orçamento.

Quando você ativa a alocação de custos do GKE, o nome do cluster e o namespace das cargas de trabalho do GKE aparecem no campo de rótulos da exportação de faturamento para o BigQuery:

Fornecer registros específicos do locatário

Para fornecer dados de registro específicos às cargas de trabalho do projeto aos locatários, use o Roteador de registros do Cloud Logging. Para criar registros específicos de locatário, o administrador do cluster cria um coletor para exportar entradas de registro para um bucket de registros criado no Google Cloud do locatário projeto.

Para saber mais sobre como configurar esses tipos de registros, consulte Geração de registros multilocatário no GKE.

Lista de verificação resumida

A tabela a seguir resume as recomendações para criar clusters multilocatários em uma organização empresarial:

Área Tarefas
Configuração organizacional
Gerenciamento de identidade e acesso
Rede
Alta disponibilidade e confiabilidade
Segurança
Registro e monitoramento

A seguir