Como proteger dados confidenciais em notebooks gerenciados pelo usuário do Vertex AI Workbench

Este documento sugere controles e camadas de segurança que podem ser usados para ajudar a proteger dados confidenciais em notebooks gerenciados pelo usuário do Vertex AI Workbench. Este documento faz parte de uma solução de blueprints composta de:

• um guia dos controles que você implementa (este documento);
• um repositório do GitHub (em inglês).

Neste documento, os dados confidenciais referem-se a informações confidenciais que exigem níveis de privilégio mais altos para serem acessados por alguém da sua empresa. Este documento destina-se a equipes que administram os notebooks gerenciados pelo usuário.

Pressupomos que você já tenha configurado um conjunto das bases de controles de segurança para proteger a implantação da infraestrutura em nuvem. O blueprint ajuda a incluir mais controles nesses controles de segurança para proteger dados confidenciais nos notebooks gerenciados pelo usuário. Para mais informações sobre as práticas recomendadas para manter as implantações do Google Cloud seguras, consulte o Guia do enterprise foundations do Google Cloud.

Introdução

A aplicação de políticas de segurança e governança de dados para proteção dos notebooks gerenciados pelo usuário com dados confidenciais geralmente exige que você equilibre os seguintes objetivos:

• Fazer a proteção dos dados usados por instâncias de notebook usando as mesmas práticas e controles de segurança e governança de dados aplicados em toda a empresa.
• Garantir que os cientistas de dados da empresa tenham acesso aos dados necessários para fornecer insights significativos.

Antes de dar aos cientistas de dados acesso empresarial aos dados nos notebooks gerenciados pelo usuário, é necessário conhecer os seguintes conceitos:

• Como os dados fluem pelo ambiente.
• Quem está acessando os dados.

Considere o seguinte para entender melhor:

• Como implantar a hierarquia de recursos do Google Cloud para isolar os dados.
• Quais grupos do IAM têm autorização para usar dados do BigQuery.
• Como a política de governança de dados influencia o ambiente.

Os scripts (em inglês) do Terraform no repositório do GitHub associados ao blueprint implementam os controles de segurança descritos neste documento. O repositório também contém dados de amostra que ilustram as práticas de governança de dados. Para mais informações sobre a governança de dados no Google Cloud, consulte O que é governança de dados?

Arquitetura

O diagrama de arquitetura a seguir mostra a hierarquia e os recursos do projeto, como notebooks gerenciados pelo usuário e chaves de criptografia.

O perímetro nessa arquitetura é chamado de limite de confiança mais alto. Ele ajuda a proteger dados confidenciais usados na nuvem privada virtual (VPC, na sigla em inglês). Os cientistas de dados precisam acessar os dados pelo limite de confiança mais alto. Para mais informações, consulte VPC Service Controls.

O limite de confiança mais alto contém todos os recursos de nuvem que interagem com dados confidenciais, o que pode ajudar no gerenciamento dos controles da governança de dados. Serviços como notebooks gerenciados pelo usuário, BigQuery e Cloud Storage têm o mesmo nível de confiança dentro do limite.

A arquitetura também cria controles de segurança que ajudam você a:

• reduzir o risco de exfiltração de dados em um dispositivo usado por cientistas de dados na empresa;
• proteger as instâncias de notebooks do tráfego de rede externo;
• limitar o acesso à VM que hospeda as instâncias do notebook.

Estrutura da organização

O Resource Manager permite agrupar logicamente recursos por projeto, pasta e organização. O diagrama a seguir mostra uma hierarquia de recursos com pastas que representam ambientes diferentes, como produção ou desenvolvimento.

Na pasta de produção, crie uma nova pasta que representa o ambiente confiável.

Adicione políticas da organização à pasta confiável que você criou. Nas seções a seguir, você verá como as informações são organizadas na pasta, subpastas e projetos.

Pasta confiável

O blueprint ajuda a isolar dados introduzindo uma nova subpasta dentro da pasta de produção para os notebooks gerenciados pelo usuário e todos os dados que as instâncias de notebook usam do BigQuery. A tabela a seguir descreve as relações das pastas dentro da organização e lista as pastas usadas por esse blueprint.

Pasta	Descrição
production	Contém projetos que têm recursos de nuvem testados e prontos para uso.
trusted	Contém projetos e recursos para instâncias de notebook com dados confidenciais. Essa pasta é uma subpasta filha da pasta production.

Projetos na organização

O blueprint ajuda a isolar partes do ambiente usando projetos. Como esses projetos não têm um proprietário, crie vinculações explícitas à política do IAM para os grupos corretos do IAM.

A tabela a seguir descreve onde você cria os projetos necessários na organização.

Projeto	Pasta mãe	Descrição
trusted-kms	trusted	Contém serviços que gerenciam a chave de criptografia que protege os dados (por exemplo, Cloud HSM). Este projeto está no limite de confiança mais alto.
trusted-data	trusted	Contém serviços que lidam com dados confidenciais (por exemplo, BigQuery). Este projeto está no limite de confiança mais alto.
trusted-analytics	trusted	Contém os notebooks gerenciados pelos usuários que são usados por cientistas de dados. Este projeto está no limite de confiança mais alto.

Noções básicas dos controles de segurança aplicados

Nesta seção, discutimos os controles de segurança no Google Cloud que protegem as instâncias do notebook. A abordagem discutida neste documento usa várias camadas de controle para ajudar a proteger os dados confidenciais. Recomendamos que você adapte essas camadas de controle conforme exigido pela sua empresa.

Configuração da política da organização

O serviço de política da organização é usado para configurar restrições em recursos compatíveis na organização do Google Cloud. As restrições configuradas são aplicadas à pasta trusted, conforme descrito na tabela a seguir. Para mais informações sobre as restrições da política, consulte Restrições da política da organização.

Restrição da política	Descrição	Valor recomendado
gcp.resourceLocations	(lista) define restrições sobre como os recursos são implantados em determinadas regiões. Para valores adicionais, consulte os grupos de regiões válidos.	["in:us-locations", "in:eu-locations"]
iam.disableServiceAccountCreation	(booleano) Quando o valor é true, impede a criação de uma conta de serviço.	true
iam.disableServiceAccountKeyCreation	(booleano) Quando o valor é true, impede a criação de chaves de conta de serviço.	true
iam.automaticIamGrantsForDefaultServiceAccounts	(booleano) Quando o valor for true, impede que contas de serviço padrão recebam qualquer papel do IAM no projeto quando as contas forem criadas.	true
compute.requireOsLogin	(booleano) Quando o valor for true, ativa o Login do SO. Para mais informações, consulte Login do SO.	true
constraints/compute.restrictProtocolForwardingCreationForTypes	(lista) Faz com que novas regras de encaminhamento sejam somente para uso interno.	["is:INTERNAL"]
compute.restrictSharedVpcSubnetworks	(lista) define o conjunto de sub-redes VPC compartilhadas que pode ser usado por recursos qualificados. Forneça o nome do projeto que tem a sub-rede da VPC compartilhada. Substitua a sub-rede VPC_SUBNET pelo ID do recurso da sub-rede particular que você quer que os notebooks gerenciados pelo usuário usem.	["under:projects/VPC_SUBNET"]
compute.vmExternalIpAccess	(lista) define o conjunto de instâncias de VM do Compute Engine que têm permissão para usar endereços IP externos.	deny all=true
compute.skipDefaultNetworkCreation	(booleano) Quando o valor for true, faz com que o Google Cloud ignore a criação da rede padrão e recursos relacionados durante a criação do recurso do Google Cloud.	true
compute.disableSerialPortAccess	(booleano) Quando o valor for true, impede o acesso de porta serial aos VMs do Compute Engine.	true
compute.disableSerialPortLogging	(booleano) Quando o valor for true, impede a geração de registros de porta serial no Cloud Logging a partir de VMs do Compute Engine.	true

Para mais informações sobre outros controles de política, consulte o Blueprint de bases empresariais do Google Cloud.

Autenticação e autorização

O blueprint ajuda você a estabelecer controles do IAM e padrões de acesso que podem ser aplicados a notebooks gerenciados pelo usuário. Ele também mostra como definir padrões de acesso:

• usando um grupo de cientista de dados de confiança mais alta. Identidades individuais não têm permissões atribuídas para acessar os dados;
• definindo um papel de IAM personalizado chamado restrictedDataViewer;
• usando os princípios de privilégio mínimo para limitar o acesso aos dados.

Usuários e grupos

O limite de confiança mais alto tem dois perfis, que são os seguintes:

• O proprietário de dados, que é responsável por classificar os dados no BigQuery.
• O cientista de dados confiável, que pode lidar com dados confidenciais.

Esse perfis são associados aos grupos. Adicione ao grupo uma identidade que corresponda ao perfil, em vez de conceder o papel a identidades individuais.

O blueprint ajuda a aplicar o privilégio mínimo definindo um mapeamento individual entre cientistas de dados e as instâncias de notebook deles para que apenas uma única identidade de cientista de dados possa acessar a instância do notebook. Os cientistas de dados individuais não recebem permissões de editor a uma instância de notebook.

A tabela mostra as seguintes informações:

• Os perfis que você atribui ao grupo
• Os papéis do IAM que você atribui ao grupo no nível do projeto

Grupo	Descrição	Papéis	Projeto
data-owner@example.com	Os membros são responsáveis pela classificação e pelo gerenciamento dos dados no BigQuery.	roles/bigquery.dataOwner	trusted-data
trusted-data-scientist@example.com	Os membros têm permissão para acessar os dados que estão na pasta confiável.	roles/restrictedDataViewer (personalizado)	trusted-data

Contas de serviço gerenciadas pelo usuário

Crie uma conta de serviço gerenciada pelo usuário para ser usada pelos notebooks gerenciados pelo usuário em vez da conta de serviço padrão do Compute Engine. Os papéis da conta de serviço para instâncias de notebook são definidos na tabela a seguir.

Conta de serviço	Descrição	Papéis	Projeto
sa-p-notebook-compute@trusted-analytics.iam.gserviceaccount.com	Uma conta de serviço usada pela Vertex AI para provisionar instâncias de notebook.	roles/restrictedDataViewer(personalizado) roles/bigquery.jobUser roles/cloudkms.cryptoKeyEncrypterDecrypter roles/compute.instanceAdmin roles/notebooks.viewer	trusted-analytics

O blueprint também ajuda a configurar a conta de serviço gerenciada pelo Google que representa os notebooks gerenciados pelo usuário, fornecendo à conta de serviço gerenciado pelo Google acesso às chaves de criptografia gerenciadas pelo cliente (CMEKs, na sigla em inglês) especificadas. Essa concessão específica do recurso aplica o menor privilégio à chave usada por notebooks gerenciados pelo usuário.

Como os projetos não têm um proprietário definido, os cientistas de dados não podem gerenciar as chaves.

Papéis personalizados

No blueprint, você cria um papel personalizado roles/restrictedDataViewer removendo a permissão de exportação. O papel personalizado é baseado no papel predefinido dataViewer do BigQuery, que permite aos usuários ler dados da tabela do BigQuery. Atribua esse papel ao grupo trusted-data-scientists@example.com. A tabela a seguir mostra as permissões usadas pelo papel roles/restrictedDataViewer.

Nome do papel personalizado	Descrição	Permissões
roles/restrictedDataViewer	Permite que instâncias de notebook no limite de confiança mais alto visualizem dados confidenciais do BigQuery. Com base no papel roles/bigquery.dataViewer sem a permissão de exportação (por exemplo, bigquery.models.export).	bigquery.datasets.get bigquery.datasets.getIamPolicy bigquery.models.getData bigquery.models.getMetadata bigquery.models.list bigquery.routines.get bigquery.routines.list bigquery.tables.get bigquery.tables.getData bigquery.tables.getIamPolicy bigquery.tables.list resourcemanager.projects.get resourcemanager.projects.list

Privilégio mínimo

O blueprint ajuda a conceder papéis com nível mínimo de privilégio. Por exemplo, suponhamos que você precisa configurar um mapeamento um para um entre uma única identidade de cientista de dados e uma instância de notebook, em vez de um mapeamento compartilhado com uma conta de serviço. Restringir o privilégio ajuda a evitar que os cientistas de dados façam login diretamente nas instâncias que hospedam a instância de notebook.

Acesso privilegiado

Os usuários no grupo de cientistas de dados de maior confiança chamado trusted-data-scientists@example.com têm acesso privilegiado. Esse nível de acesso significa que esses usuários têm identidades que podem acessar dados confidenciais. Trabalhe com a equipe de identidade para fornecer chaves de segurança de hardware com a verificação em duas etapas ativada para essas identidades de cientistas de dados.

Rede

Especifique um ambiente de VPC compartilhada para os notebooks, como um definido pelos scripts de rede do enterprise foundations do Google Cloud.

A rede das instâncias de notebook tem as seguintes propriedades:

• Uma VPC compartilhada que usa uma rede restrita particular sem endereço IP externo
• Regras de firewall restritivas
• Um perímetro do VPC Service Controls que engloba todos os serviços e projetos com os quais os notebooks gerenciados pelo usuário interagem.
• Uma política do Access Context Manager

VPC compartilhada restrita

Configurar notebooks gerenciados pelo usuário para usar a VPC compartilhada que você especificar. Como o Login do SO é obrigatório, a VPC compartilhada minimiza o acesso às instâncias de notebook. É possível configurar o acesso explícito dos cientistas de dados usando o Identity-Aware Proxy (IAP).

Também é possível configurar a conectividade particular com APIs e serviços do Google na VPC compartilhada usando o domínio restricted.googleapis.com. Essa configuração permite que os serviços no ambiente sejam compatíveis com o VPC Service Controls.

Para um exemplo de como configurar a VPC restrita compartilhada, consulte os scripts do Terraform de configuração de rede do blueprint das bases de segurança.

Perímetro dos VPC Service Controls

O blueprint ajuda a estabelecer um limite de confiança maior para o ambiente confiável usando o VPC Service Controls.

Perímetros de serviço são um controle no nível da organização que podem ser usado para proteger os serviços do Google Cloud nos projetos, reduzindo o risco de exfiltração de dados.

Na tabela a seguir, você vê como configurar o perímetro do VPC Service Controls.

Atributo	Consideração	Valor
projects	Inclua todos os projetos que contêm dados acessados por cientistas de dados que usam notebooks gerenciados pelo usuário, incluindo chaves.	["trusted-kms" "trusted-data" "trusted-analytics"]
services	Adicione outros serviços conforme necessário.	["compute.googleapis.com", "storage.googleapis.com", "notebooks.googleapis.com", "bigquery.googleapis.com", "datacatalog.googleapis.com", "dataflow.googleapis.com", "dlp.googleapis.com", "cloudkms.googleapis.com", "secretmanager.googleapis.com", "cloudasset.googleapis.com", "cloudfunctions.googleapis.com", "pubsub.googleapis.com", "monitoring.googleapis.com", "logging.googleapis.com"]
access_level	Adicione políticas do Access Context Manager que se alinhem aos requisitos de segurança e inclua políticas mais detalhadas da verificação de endpoints.	ACCESS_POLICIES Saiba mais em Access Context Manager .

Access Context Manager

O blueprint ajuda você a configurar o Access Context Manager com o perímetro do VPC Service Controls. Com o Access Context Manager, é possível definir o controle de acesso detalhado e com base em atributos para projetos e recursos. Use a Verificação de endpoints e configure a política de acordo com os requisitos de governança corporativa para acesso a dados. Trabalhe com o administrador para criar uma política de acesso para os cientistas de dados na empresa.

Recomendamos que você use os valores mostrados na tabela a seguir para a política de acesso.

Condição	Consideração	Valores
ip_subnetworks	Usar intervalos de IP confiáveis pela empresa.	(lista) Os intervalos CIDR permitem acesso a recursos dentro do perímetro.
members	Adicionar usuários com privilégio mais alto que possam acessar o perímetro.	(lista) Identidades privilegiadas de cientistas de dados e conta de serviço do Terraform para provisionamento.
device_policy.require_screen_lock	Os dispositivos precisam ter o bloqueio de tela ativado.	true
device_policy.require_corp_owned	Permita que dispositivos corporativos acessem apenas os notebooks gerenciados pelo usuário.	true
device_policy.allowed_encryption_statuses	Permitir que apenas cientistas de dados usem dispositivos que criptografam dados em repouso.	(lista) ENCRYPTED
regions	Manter a regionalização onde os cientistas de dados possam acessar as instâncias de notebooks. Limitar ao menor conjunto de regiões onde você espera que os cientistas de dados trabalhem.	Códigos de região válidos (lista)

Privilégio mínimo do BigQuery

O blueprint mostra como configurar o acesso a conjuntos de dados no BigQuery usados por cientistas de dados. Na configuração que você definir, os cientistas de dados precisam ter uma instância de notebook para acessar conjuntos de dados no BigQuery.

A configuração definida também ajuda a adicionar camadas de segurança aos conjuntos de dados do BigQuery das seguintes maneiras:

• Concedendo acesso à conta de serviço da instância de notebook. Os cientistas de dados precisam ter uma instância de notebook para acessar diretamente conjuntos de dados no BigQuery.
• Minimizando o risco de cientistas de dados criarem cópias de dados que não atendem aos requisitos de governança de dados da empresa. Os cientistas de dados que precisarem interagir diretamente com o BigQuery precisam ser adicionados ao grupo trusted-data-scientists@example.com.

Como alternativa, para fornecer aos cientistas de dados acesso limitado ao BigQuery, use controles de acesso detalhados, como a segurança em nível de coluna. O proprietário dos dados precisa trabalhar com as equipes de governança para criar uma taxonomia correta. Os proprietários de dados podem então usar a Proteção de dados confidenciais para verificar conjuntos de dados a fim de classificar e marcar o conjunto de dados de acordo com a taxonomia.

Gerenciamento de chaves

Para proteger seus dados, os notebooks gerenciados pelo usuário usam chaves de criptografia. As chaves são respaldadas por um Cloud HSM do FIPS 140-2 nível 3. As chaves que você cria no ambiente ajudam a proteger os dados das seguintes maneiras:

• O CMEK é ativado para todos os serviços que estão dentro do limite de confiança mais alto.
• A disponibilidade da chave é configurável por região.
• A rotação de chaves é configurável.
• O acesso à chave é limitado.

CMEK

O blueprint mostra como usar CMEKs que criam um limite de criptografia para todos os dados que usam uma chave gerenciada por você. O ambiente usa a mesma chave de CMEK para todos os serviços que estão dentro do limite de confiança mais alto. Outro benefício de usar o CMEK é que ele possibilita destruir a chave usada, protegendo, assim, as instâncias de notebook quando a instância de notebook não for mais necessária.

Disponibilidade e rotação da chave

Para aumentar a disponibilidade, crie um keyring multirregional, o que aumenta a disponibilidade das chaves.

No blueprint, você cria chaves com um valor de rotação automático. Para definir o valor de rotação, siga a política de segurança definida pela empresa. É possível alterar o valor padrão para corresponder à política de segurança ou fazer a rotação das chaves com mais frequência, se necessário.

A tabela a seguir descreve os atributos que você configura para as chaves.

Atributo	Consideração	Valores
rotation	Corresponder o valor definido pela política de rotação de conformidade da empresa.	45 dias
location	Use um keyring que use locais multirregionais para promover maior disponibilidade.	Selecionado automaticamente com base na configuração de zona dos notebooks gerenciados pelo usuário.
protection level	Usar o nível de proteção especificado pela empresa.	HSM

Acesso da chave

O blueprint ajuda a proteger as chaves, colocando-as em um módulo do Cloud HSM em uma pasta separada dos recursos de dados. Use essa abordagem pelos seguintes motivos:

• As chaves de criptografia são necessárias para que os recursos possam usar a chave.
• As equipes de gerenciamento de chaves são mantidas separadas dos proprietários de dados.
• Mais controle e monitoramento de chaves são necessários. Com uma pasta separada, é possível gerenciar políticas para as chaves independentes dos dados.

Controles de segurança de notebooks gerenciados pelo usuário

Os controles descritos nesta seção protegem os dados usados em notebooks gerenciados pelo usuário. O blueprint ajuda você a configurar os controles de segurança de notebooks gerenciados pelo usuário da seguinte maneira:

• Reduzindo o risco de exfiltração de dados
• Limitando o escalonamento de privilégios

Gerenciamento de download de dados

Por padrão, as instâncias de notebook permitem que os cientistas de dados façam o download ou exportem dados para as máquinas. O script de inicialização instalado pelo blueprint ajuda você a evitar as seguintes ações:

• A exportação e o download de dados para dispositivos locais
• A capacidade de imprimir valores de saída calculados por instâncias de notebook

O script é criado no projeto trusted_kms. O blueprint ajuda você a proteger o bucket que armazena o script, limitando o acesso e configurando o CMEK. Separar os scripts do projeto para notebooks gerenciados pelo usuário também reduz o risco de código não aprovado ser adicionado aos scripts de inicialização.

Como você configurou os notebooks gerenciados pelo usuário para usar a sub-rede particular VPC restrita, as instâncias de notebook não poderão acessar redes públicas. Essa configuração ajuda a impedir que os cientistas de dados instalem módulos externos, acessem fontes de dados externas e acessem repositórios de código público. Em vez de recursos externos, recomendamos configurar um repositório de artefatos particular, como o Artifact Registry para os cientistas de dados da empresa.

Gerenciamento de privilégios

O blueprint ajuda a limitar as permissões atribuídas ao grupo trusted-data-scientists@example.com. Por exemplo, o grupo não recebe o papel para criar snapshots de disco permanente porque o sistema de arquivos local do snapshot pode conter instâncias de notebook que contêm dados da empresa.

Além disso, para ajudar a impedir que cientistas de dados tenham acesso privilegiado, é possível impedir o uso dos comandos sudo da linha de comando da instância de notebook. Essa ação ajuda a impedir que os cientistas de dados alterem os controles instalados na instância de notebook, como os pacotes aprovados ou a geração de registros.

Segurança operacional

Junto dos controles de segurança que você estabelece com o blueprint, configure as seguintes políticas de segurança operacional para ajudar a garantir que os dados estejam protegidos continuamente nos notebooks usados pela empresa:

• Configuração da geração de registros e do monitoramento
• Políticas de gerenciamento de vulnerabilidades
• Visibilidade dos recursos

Como gerar registros e monitorar

Depois que uma hierarquia é criada, é necessário configurar os controles de geração de registros e de detecção usados em novos projetos. Para mais informações sobre como configurar esses controles, consulte os scripts de geração de registros do blueprint das bases de segurança.

Gerenciamento de vulnerabilidades

As Deep Learning VM Images são atualizadas regularmente. Recomendamos que você atualize as imagens nas instâncias existentes de notebook com a mesma frequência da programação de verificação de vulnerabilidades. É possível verificar o resultado da API isUpgradeable e iniciar um upgrade pela API upgrade.

Visibilidade de riscos

Recomendamos o uso do Security Command Center para proporcionar visibilidade aos recursos, vulnerabilidades, riscos e políticas. O Security Command Center verifica a implantação para avaliar o ambiente em relação a frameworks de conformidade relevantes.

Resumo geral

Para implementar a arquitetura descrita neste documento, faça o seguinte:

1. Crie a pasta e projetos confiáveis de acordo com a seção estrutura da organização.
2. Configure os controles de geração de registros e monitoramento desses projetos de acordo com a política de segurança. Por exemplo, consulte a configuração da geração de registros (em inglês) do blueprint das bases de segurança.
3. Crie os grupos do IAM e adicione as identidades de cientistas de dados confiáveis ao grupo apropriado, conforme descrito em Usuários e grupos.
4. Configure a rede com uma VPC e sub-rede restrita compartilhadas, conforme descrito em Rede.
5. Crie a política do Access Context Manager, conforme descrito em Access Context Manager.
6. Clone o repositório do GitHub (em inglês) para este tutorial:
7. Crie o arquivo de variável de ambiente do Terraform usando as entradas (em inglês) necessárias.
8. Aplique os scripts do Terraform ao ambiente para criar os controles discutidos neste blueprint.
9. Analise o ambiente confiável de acordo com os requisitos de segurança e governança de dados. É possível analisar os projetos recém-criados de acordo com os frameworks de conformidade do Security Command Center.
10. Crie um conjunto de dados no BigQuery no projeto trusted-data ou use a amostra fornecida no módulo de repositório do GitHub data (em inglês).
11. Trabalhe com um cientista de dados na empresa para testar o acesso dele à instância de notebook recém-criada.
12. No ambiente dos notebooks gerenciados pelo usuário, verifique se um cientista de dados consegue interagir com os dados do BigQuery da maneira esperada. É possível usar o comando de exemplo do BigQuery (em inglês) no repositório do GitHub associado.

Recursos

• Blueprint de bases empresariais do Google Cloud
• Repositório do Terraform de bases empresariais do Google Cloud
• Notebooks gerenciados por usuários
• Máquinas virtuais de aprendizado profundo
• Vertex AI do Google Cloud
• Central de práticas recomendadas de segurança para o Cloud