Nos últimos anos a migração para a nuvem tem sido uma estratégia frequente entre as empresas, principalmente para as que buscam impulsionar a transformação digital nos seus negócios. Neste sentido, é comum encontrarmos diversos materiais sobre como manter a segurança da sua conta e serviços na Amazon Web Services (AWS), Microsoft Azure ou no Google Cloud Platform (GCP), mas infelizmente o mesmo não acontece com outros provedores de cloud públicas como a Oracle Cloud Infrastructure (OCI).
Entendendo a importância deste tema, publicaremos uma série de posts, usando exemplos práticos e didáticos, sobre os cuidados mínimos que devem ser tomados ao configurar recursos e serviços na infraestrutura de nuvem da Oracle.
Proteção de instâncias de computação
A maioria das empresas que migram para a nuvem, fazem o chamado Lift and Shift, também conhecido como rehosting, ou seja, é realizada a realocação da infraestrutura on-premises para instâncias na nuvem, sem modificar significativamente a arquitetura.
Vale lembrar que este modelo de Infrastructure as a Service (IaaS) é de responsabilidade compartilhada entre o cliente e o provedor de serviços de nuvem (Figura 1: Shared Reponsability Security Model). Rotinas de atualização do sistema operacional, backups e criptografia do mesmo, gestão de acesso, identidade, vulnerabilidades de aplicações, por exemplo, são responsabilidades do cliente.
Neste sentido, é importante falarmos sobre o processo de setup de Instâncias Oracle, um recurso que “permite provisionar e gerenciar hosts de computação, conhecidos como instâncias. Você pode criar instâncias conforme necessário para atender aos seus requisitos de computação e aplicação. Depois de criar uma instância, você pode acessá-la com segurança em seu computador, reiniciá-la, anexar e desanexar volumes e encerrá-la quando terminar.”
Durante a criação da sua instância computacional, alguns pontos relacionados à sua segurança serão sugeridos pela própria console da Oracle, sendo necessário mantê-los selecionados:
- Secure Boot:
- É um recurso Unified Extensible Firmware Interface (UEFI) que impede a inicialização de carregadores de inicialização e sistemas operacionais não autorizados. O Secure Boot usa somas de verificação e assinaturas criptográficas para evitar que códigos maliciosos sejam carregados e executados no início do processo de inicialização, antes que o sistema operacional seja realmente carregado.
- Cada programa carregado pelo firmware inclui uma assinatura e uma soma de verificação que é validada pelo firmware, antes da execução do programa. Quando ativado, o Secure Boot interrompe todas as tentativas de executar um programa não confiável, impedindo efetivamente que qualquer código inesperado ou não autorizado seja executado no ambiente baseado em UEFI.
- Measured Boot:
- Measured Boot é complementar ao Secure Boot. Aprimora a segurança de inicialização fazendo e armazenando medições de componentes de inicialização, como carregadores de inicialização, drivers e sistemas operacionais. Instâncias bare metal não são compatíveis com Measured Boot.
- Trusted Platform Module (TPM):
- É usado para armazenar com segurança as medições de inicialização. Trata-se de um chip de segurança baseado em hardware que fornece atestado e autenticação de dados e segurança através do uso de locais protegidos e blindados.
Networking
Após a etapa de setup, é necessário definir um Security Group. Ele tem como objetivo fazer o controle do tráfego de entrada e saída da instância, onde você pode configurar portas e recursos específicos a serem permitidos.
O ideal é que você crie ou use um Security Group específico para atender às suas necessidades – exemplo: se você tem um grupo específico de instâncias que executam o serviço de RDP (Remote Desktop Protocol), o ideal é que seja criado um Security Group e limite a conexão a um endereço IP e protocolos que serão utilizados.
O Serviço de Networking, tem inúmeras outras configurações e por conta disso iremos dedicar outra publicação exclusivamente para este assunto.
Autenticação
Um outro ponto de atenção diz respeito à configuração do mecanismo de autenticação de sua instância. Você deve usar pares de chaves SSH (Secure Shell), geradas especificamente para a instância em questão. Jamais deverá ser usada a autenticação por login e senha. Apesar de existir esta possibilidade, trata-se de um método frágil, passível de sofrer ataques como o de força bruta – e isso pode comprometer a segurança da sua empresa.
Management
Nesta etapa, precisamos ter atenção aos seguintes pontos:
- O recurso de Instance Metadata (IMDS) na versão 1 não suporta quaisquer recursos de autenticação, desta forma, é recomendado o uso da versão 2, que já tem este suporte;
- A Oracle dispõe de recursos para a execução de scanning de vulnerabilidades, podendo ser configurados através do Oracle Cloud Agent, essa sem dúvidas é outra funcionalidade interessante de se ter habilitada, afinal, como falamos anteriormente (Shared Responsibility Security Model), a gestão de vulnerabilidades nesse caso é de responsabilidade do cliente final.
Boot volume
Iremos dedicar um blog post específico para falarmos sobre diversos recursos na seção de Block Storage, mas por enquanto, gostaríamos de ressaltar que é fundamental que o recurso de “Use in-transit encryption” seja habilitado por você, ele é responsável por criptografar dados em trânsito entre a instância, o volume de inicialização e os volumes em bloco.
Zanshin
Não é razoável esperar que seus funcionários ou terceiros, conheçam e lembrem de todas as práticas recomendadas ou opções de configuração relevantes para a segurança na OCI ou em qualquer outro provedor de nuvem. E foi pensando nisso que criamos o Zanshin, uma plataforma SaaS que permite às empresas compartilhar facilmente informações e cooperar com suas equipes internas e unidades de negócios e terceiros para gerenciar riscos de segurança. O Zanshin conecta empresas e suas cadeias de valor, promovendo transparência e tratamento responsável dos riscos associados à cibersegurança e privacidade.
Entre em contato conosco se quiser saber mais sobre o Zanshin e como ele está revolucionando o gerenciamento de riscos de terceiros.
Artigo escrito por Heitor Gouvea
