O básico que você precisa saber sobre a sua fundação em nuvem

Escrito por: Kimmy Wu e Thiago Sgobe

Introdução

Antes de migrar ou criar seus projetos em um ambiente de nuvem é importante criar uma fundação de infraestrutura. O planejamento da fundação busca criar uma base padronizada para os projetos, incluindo redes, segurança, gerenciamento de acesso, computação e armazenamento. Neste post iremos abordar alguns passos importantes para serem definidos e pensados antes de criar sua infraestrutura no ambiente da nuvem.

Gestão de Identidade

O primeiro passo é identificar como os seus usuários terão acesso ao ambiente. Parte da fundação é definir qual será o sistema provedor de identidade e modo de autenticação para que exista apenas uma única “fonte da verdade”, e então, automatizar a manutenção de identidades do Google e vincular seu ciclo de vida aos usuários existentes no serviço de diretório origem.

O Google Cloud utiliza o Google Cloud Identity ou Google Workspace para autenticação e gerenciamento de acesso, mas também é possível configurar um identity provider (IdP). Por exemplo, Usuários e Grupos podem ser sincronizados a partir do Active Directory em ambiente on-prem para o Cloud Identity através da ferramenta Google Cloud Directory Sync (GCDS). Para Azure AD existe a opção de utilizar o Enterprise Application Google Cloud / G Suite Connector by Microsoft.

No Cloud Architecture Center você pode encontrar arquiteturas de referência e vantagens e desvantagens de cada uma delas.

Após decidir a nossa única “fonte da verdade”, chegamos no estágio de gerenciar os usuários e suas permissões. Por isso é ideal ter em mente três respostas antes de conceder o acesso: 1) Quem? 2)Quais serviços? 3) Quais permissões?

É necessário pensar em um conjunto de grupos de usuários de acordo com as diversas funções, como: finanças, redes, segurança, entre outros. Isto é importante para que possamos conceder de maneira fácil e consistente as permissões apropriadas para funções específicas.

A prática recomendada no IAM é utilizar grupos como principal forma de conceder permissões, em vez de atribuir diretamente aos usuários. Os usuários são associados aos seus respectivos grupos de acordo com o papel de cada usuário. Essa atribuição deve ser feita por uma equipe específica e estritamente controlada.

Utilizando como base as três perguntas anteriores, iremos usar o usuário Thiago como exemplo. O Thiago (thiago@exemplo.com) precisa de acesso ao ambiente para validar a utilização de gastos em nuvem e gerar relatórios. Dessa forma “Quem” seria o usuário do Thiago, “Quais serviços?” serviços de billing e “ Quais permissões?” permissão de leitura. Idealmente, uma vez que identificamos permissões em comum, atribuir o usuário em um grupo irá facilitar a gestão das identidades, uma vez que o grupo pode ter mais de um usuário, e as permissões serão controladas a nível de grupo.

A tabela abaixo mostra um exemplo de grupos, você pode configurar grupos adicionais conforme necessário com base em cada workload específico.

Gestão de recursos

A base para iniciar a criação de recursos no Google Cloud é a organização, quando o Cloud Identity ou Google Workspace é configurado a organização também é criada. A organização fornece uma hierarquia de recursos, que é composta por Organização, Pastas, Projetos e Recursos.

Projetar adequadamente a hierarquia de recursos permite implementar facilmente a gestão de acesso com privilégios mínimos e aplicar políticas organizacionais de forma simples e consistente. Apesar de o único componente necessário para a criação de recursos no Google Cloud ser o projeto, é altamente recomendado a criação de uma organização.

O componente Organização representa o nó raiz da hierarquia de recursos quando presente, e está diretamente associada a uma conta Google Workspace ou Cloud Identity. Permissões atribuídas no nível da organização serão herdadas para todas as Pastas e Projetos abaixo.

A Pasta é outro componente importante da hierarquia de recursos, seu principal propósito é agrupar projetos similares, do ponto de vista de acesso e políticas. Assim como na organização, as permissões atribuídas na Pasta são herdadas por todas as Pastas e Projetos filhos.

O Projeto é onde efetivamente estão os recursos dentro da Google Cloud, e é mandatório que exista para que se possa criar recursos dentro do Google Cloud.

A estrutura de hierarquia de recursos depende da natureza da organização e do tipo de workload que está sendo implementado. O diagrama abaixo mostra uma arquitetura exemplo.

Existem alguns padrões diferentes para a criação de pastas, e estas geralmente estão alinhadas com a estrutura de gerenciamento da sua empresa, podendo ter pastas agregando por ambientes, ambientes compartilhados, por squads, produtos, etc. Você pode identificar algumas boas práticas neste blog desenvolvido pela comunidade.

Segurança

Com o IAM estabelecemos uma base importante para a segurança do nosso ambiente. Utilizando o conceito de menor privilégio, mitigamos o uso inadequado e permitimos apenas o acesso aos recursos necessários para o nosso usuário. O Google IAM permite que você conceda acesso a recursos específicos, em um nível granular. Isso significa que você pode dar aos usuários acesso apenas aos recursos de que precisam e nada mais.

Além do acesso granular o IAM fornece recursos de auditoria abrangentes, que permitem rastrear quem acessou seus recursos e quando. Isso pode ser útil para solucionar problemas de incidentes de segurança e para garantir que suas políticas de acesso sejam seguidas. Além disso, a Integração com Cloud Audit Logging permite que você gerencie o acesso aos seus recursos em vários serviços do Google Cloud e tenha uma visão completa de sua postura de segurança.

Outro ponto importante durante a fundação é fazer o mapeamento de requisitos que a organização deve ter de políticas de segurança, como por exemplo a restrição de localidades dos dados e projetos (por compliance), exposição de IP público ou dados abertos, entre outros. Uma vez definidos, é possível adicionar as políticas organizacionais.

As políticas organizacionais são um conjunto de regras e procedimentos que orientam a maneira como uma organização opera, garantindo consistência e conformidade. Dentro da organização é possível habilitar um conjunto de políticas já pré-definidas a nível de organização, pastas e projetos. Veja a lista completa de políticas aqui.

Existem diversos produtos e boas práticas para garantir a segurança do seu ambiente em nuvem, dentro desta seção abordamos dois pontos importantes a serem definidos a nível de organização. A página de melhores práticas aborda diversos casos e exemplos de segurança.

Redes

A definição da rede é fundamental para a criação de uma fundação no Google Cloud. A primeira etapa é identificar quantos projetos e redes VPC são necessários para seu ambiente. Diferentemente de outros provedores, no Google Cloud, VPC é um recurso global, ou seja, não está associado a nenhuma região e nem exige a definição de um CIDR.

A subnet é um recurso regional, e é durante a criação que definimos CIDR e região de cada subnet.

A VPC é criada em projetos, o que significa que por default não há comunicação cross project, porém, é possível configurá-la como uma VPC Shared, ou seja, você usa quando deseja conectar recursos de vários projetos a uma rede VPC comum para que eles possam se comunicar entre si de forma segura e eficiente usando endereços IP internos dessa rede.

Com Shared VPC, você designa um projeto como projeto host e anexa um ou mais projetos de serviço a ele. As redes VPC no projeto host são chamadas de redes VPC compartilhadas (Shared VPC). Recursos elegíveis dos projetos de serviço podem usar sub-redes na rede VPC compartilhada.

Shared VPC permite que os administradores da organização deleguem responsabilidades administrativas, como criar e gerenciar instâncias, aos administradores dos projetos de serviço, mantendo o controle centralizado sobre os recursos de rede, como sub-redes, rotas e firewalls.

Algumas das vantagens do uso de Shared VPC:

• Centralizar a administração de rede em uma única organização
• Delegar responsabilidades administrativas a usuários em projetos de serviço
• Melhorar a segurança da rede ao controlar o acesso a recursos de rede
• Simplificar a arquitetura de rede ao reduzir o número de redes VPC

Se você está procurando uma maneira de conectar recursos de vários projetos a uma rede VPC comum, com uma gestão centralizada de redes, Shared VPC é uma boa opção. Além disso, poucas VPCs com subnets maiores por região trazem mais simplicidade e facilidade de gestão, assim como uma melhor utilização de recursos, porém, é importante avaliar quotas e limites para adequar a sua necessidade.

É possível conectar sua rede VPC no Google Cloud com sua rede on premise através da conectividade híbrida. Isso permite que você mova dados e aplicativos entre as duas redes com facilidade.

Existem duas maneiras de conectar redes VPC híbridas:

1. Cloud VPN

• Maneira mais rápida de se conectar à nuvem ou entre nuvens
• Aproveita a conectividade de rede de Internet existente
• Suporta alta disponibilidade e largura de banda agregada com 1,5 a 3 Gbps por túnel

2. Cloud Interconnect

• Conectividade privada com o Google Cloud
• Fornecido como um link dedicado para um PoP do Google ou por meio de um parceiro: a) Dedicated Interconnect (Dedicada): Maior largura de banda com Links de 10 Gbps e 100 Gbps; b)Partner Interconnect (Parceiro) oferece planos mais flexíveis, entre 50 Mbps a 50 Gbps.

O diagrama a seguir ilustra uma arquitetura para isolamento de VPC, que se baseia em nosso design de alta disponibilidade enquanto separa o produto de outros projetos. O uso do isolamento também pode introduzir a necessidade de duplicação de alguns serviços. O uso de uma rede VPC de serviços compartilhados pode ajudar a evitar essa duplicação e permitir que você compartilhe esses serviços com outras redes VPC por meio do peering de rede VPC e, ao mesmo tempo, centralizar a administração e a implantação.

Redes é um tópico muito extenso e existem vários aspectos que incluem, topologia, roteamento, segurança, acesso privado a APIs Google, entre outros. Práticas recomendadas e arquiteturas de referência para o design da VPC é uma ótima leitura para apoiar em suas definições de redes e alcançar uma arquitetura resiliente, escalável e segura.

Billing

É sempre importante explorar o fator custo dentro do seu ambiente, principalmente novos clientes utilizando a nuvem possuem algumas dúvidas em relação ao modo de cobrança, estimativa e gerenciamento do valor a ser cobrado. Quando explorado a parte financeira do ambiente em nuvem é importante lembrar que a cobrança é aplicada conforme o uso dos recursos, e cada recurso possui uma página aberta de precificação para fazer a estimativa de custo.

Quando criamos a organização criamos também a conta de billing, que será centralizador dos custos de projetos. Para ter o acesso e permissões de adicionar um projeto a conta de billing é necessário ter permissões específicas do IAM para tal. É possível também ter mais de uma billing account dentro da sua organização, porém é uma possibilidade que funciona positivamente para alguns cenários específicos.

Dentro da conta de billing conseguimos observar através dos relatórios de faturamento a utilização por projeto, serviço, SKU ou local de criação do serviço. Porém para facilitar a visualização dos custos é recomendado o uso de billing labels.

Billing Labels são um par de chave valor, que pode estar atrelado a um projeto ou recurso. Cada conjunto simples e padrão de valores que sejam úteis tanto tecnicamente quanto em termos de valor comercial podem ser utilizados como padrão para a visualização do custo, por exemplo: Labels baseados em equipe ou centro de custo, podem distinguir projetos pertencentes a equipes, pode ser usado em contabilidade de custos ou orçamento, etc.

As labels podem ser aplicadas a nível de recurso e a nível de projeto. Em projetos que terão recursos compartilhados entre diversos times a possibilidade de ter labels a nível de recursos pode facilitar na segregação de custo dentro do projeto. Uma vez que o requisito do negócio não necessite de tantos detalhes em relação ao custo as labels podem ser aplicadas à nível de projeto.

É recomendado antes de iniciar a criação de recursos no ambiente de nuvem ter definido qual é o padrão de labels, quais labels são necessárias para o controle de custo, e em qual nível será aplicado. Este post mostra como utilizar o relatório baseado nas labels.

Conclusão

Neste post abordamos os principais itens de uma fundação no Google Cloud, e a sua implementação pode aproveitar os modelos referência do Cloud Foundation Toolkit. O Cloud Foundation Toolkit é um conjunto de modelos pré-configurados que facilitam a criação e o gerenciamento de uma fundação. Ele oferece recursos para automatizar a implementação de infraestrutura, segurança e governança, seguindo as melhores práticas do Google Cloud.

Em resumo, a fundação fornece as bases para um ambiente eficiente, seguro e escalável. É um trabalho inicial que se traduz em benefícios significativos a longo prazo, simplificando a gestão da nuvem, impulsionando a inovação e garantindo o sucesso na jornada para a nuvem.