6 Dicas de Prevenção contra Ataques em sua Nuvem

A explosão de serviços na nuvem, amparadas por uma inicial facilidade na sua adoção e administração, por vezes faz entender dos provedores desses serviços lidarem com toda a segurança do ambiente. Esta sensação nada mais é do que uma concepção herdada dos provedores de hospedagem das décadas passadas.

Esses provedores de serviços em nuvem na prática utilizam um modelo de responsabilidade compartilhada, nele o cliente também tem responsabilidades com a segurança do seu ambiente virtual contratado.

Numa rápida pesquisa sobre ataques a serviços na nuvem é possível encontrar inúmeros incidentes, por exemplo, relacionados aos serviços da Amazon Web Services (AWS), com as consequências das investidas desses invasores custando cifras volumosas em danos.

Sendo um possível motivador, a Central para Segurança da Internet (CIS) criou a política de avaliação CIS Amazon Web Services Foundations, no intuito de melhorar a compreensão das configurações no ambiente de segurança, guiada por práticas sugeridas na utilização do ambiente de gerenciamento do AWS.

Este artigo descreve algumas das ameaças mais utilizadas no ataque a serviços em nuvem e, o que as políticas do CIS em conjungo com práticas comuns de segurança podem colaborar em mitigá-las. Embora muito do conteúdo cite os serviços da AWS é de suma importância considerar que outros provedores possam estar sujeitos a essas intempéries e por conta disso permitam ter aplicados os mesmos preceitos apresentados aqui.

Uma das práticas mais difundidas, o phishing figurou como um dos elementos mais encontrados em estudos de segurança digital num resultado informando sobre 30% dos e-mails recebidos serem abertos sem qualquer avaliação do seu conteúdo, desses hábitos resultaram em 91% dos ataques provenientes dessa prática. Na prevenção é recomendado pelo CIS em seu manual de boas práticas a adoção da autenticação multifator (MFA) descrita na seção 1.2.

Em especial no serviço AWS, é indispensável a proteção da pasta raiz com o método de autenticação multifator (MFA) uma vez que ele garante acesso a tudo no ambiente. Recomentado é também pelo CIS o uso de alarmes para avisarem de acessos nesta conta ( descrita na seção 1.1), a separação de funções dever ser utilizada então resultando em tarefas diferentes para contas diferentes (conforme seção 1.18).

Outra medida a ser adotada consiste no treinamento de todos os usuários, com alguma regular revisão, instruindo como identificar e evitar esse tipo de araque dirimindo as chances de sucesso quando houver investidas desse tipo. A definição de uma conta AWS raiz pertencendo a um grupo de usuários internos ao invés de um usuário específico é sugerida. Jamais utilize a conta padrão de compras como a conta principal nem mesmo use a conta principal continuamente. Considere a estratégia de utilizar diversas contas, no caso do comprometimento em uma delas não afetar as demais pondo em risco todos os ativos do serviço.

Ataque por força bruta é outra prática aplicada em sites de terceiros corriqueiramente, o objetivo é encontrar nestes sites informações relevantes, para concretizar com sucesso a invasão no site pretendido, método comum na busca por exposição de credenciais de acesso, aqui comentando sobre a AWS mas em praticamente qualquer produto voltado para nuvem ou não, que desperte o interesse dos criminosos digitais.

Motivos para estas investidas e sucesso nas violações costumam ser senhas fracas ou previsíveis, por essa razão as seções 1.4 – 1.10 da política do CIS aconselham sobre as opções de senha visando reduzir esses riscos atendam requisitos de complexidade contemplando combinações com letras maiúsculas, quantidade de caracteres, números além de símbolos e as tradicionais letras minúsculas, evitar a utilização de mesma senha para diversos acessos também é recomendado.

Sugestões como senhas extensas ou frases por exemplo são bem-vindas, evite manter a mesma senha ou com pouca variação para os mesmos acessos, tentando individualizar as permissões, sempre que possível utilize os reforços de autenticação, oriente os usuários dessas práticas e esclareça as consequências ao ignorar essas sugestões.

Descobertas ou obtidas através de documentações ou códigos-fonte públicos é outra origem de incidentes, aqui relatadas pelos serviços AWS. Não somente a Amazon, utiliza para muitos dos seus serviços as chamadas chaves de acesso, são combinações hexadecimais que funcionam exatamente como as credenciais convencionais, ou senhas, criadas manualmente pelos usuários. É muito provável que os utilizadores de recursos por API não lidem adequadamente com essas chaves ou API´s de acesso da mesma maneira que deveriam tratar como nas senhas regulares.

Também reforçado pelo CIS não somente a adoção da autenticação multifator como também a rotatividade para renovação das senhas (seção 1.11) e chaves (seção 1.4) de acesso, num período compreendendo 90 dias ou menos.

Administrar cautelosamente todas as chaves de acesso da mesma maneira que as senhas e nunca disfarçá-las nas documentações ou códigos-fonte, muito menos deixar armazenados em e-mails ou vazar para fora da organização.

Embora abstrato por não poder visualizar cabos, conectores e outros equipamentos o ambiente na nuvem não é nada diferente de um ambiente local, para propiciar os ambientes a que tem-se acessos são necessários esses objetos físicos além dos computadores, links de dados através de cabos e demais componentes, por esta razão estão sujeitos aos mesmos riscos que qualquer ambiente de rede compartilhada por internet.

Outro tópico descrito no CIS recomenda através das seções 4.1 e 4.2 sobre limitar os ataques provenientes de técnicas por força bruta (brute force), bloqueando algumas portas de comunicação muito conhecidas, tais como a porta 22 (SSH e SFTP) e 3389 (RDP do Windows) a partir da internet aberta. Por fim é recomendado garantir que os logs de fluxo de rede estejam funcionais (seção 4.3).

Consequentemente a segurança básica de rede não deve ser ignorada e todas as práticas triviais devem ser aplicadas também no ambiente AWS como a ativação do firewall no sistema operacional utilizado e no caso do AWS, em conjunto com as regras de ingresso do AWS Network Security Group.

Reforçar a segurança do firewall com regras mais rígidas bloqueando o que não for essencial ou criando uma lista de permissões pode limitar a exposição a diversos tipos de ataques, complementar com soluções antivirus e softwares de monitoramento como acesso a páginas, requisições e origens de acesso além do gerenciamento das próprias máquinas virtuais também deve ser considerado.

Considere também efetuar varreduras e verificações, através de softwares específicos para isso, procurando e inibindo vulnerabilidades exploráveis antes que os criminosos venham a fazê-lo. No caso da AWS devem ser previamente aprovados por ela para não serem interpretados como ataques reais e possivelmente indisponibilizar seus serviços.

Quando disponível é produtivo executar produtos preventivos contra invasão na busca e bloqueio de possíveis ataques em execução. No caso da AWS você pode executar o recém-criado Amazon Web Applications Firewall na proteção contra alguns tipos de ataques, incluindo os listados no OWASP Top 10.

Nas boas práticas do CIS também existem seções sobre monitoramento e registro. Na seção 2 consta sobre garantia do monitoramento por tempo real possuir um log ativo, o backup e criptografia deles também devem em atividade.

Sobre a necessidade de uma generosa diversidade de alertas de monitoramento estarem em atividade são descritos na seção 3, emitindo avisos e notificações decorrentes de atividades desses inúmeros monitoramentos. Esses monitores podem colaborar na localização de ameaças internas e o escalonamento de privilégios através de avisos em chamadas não autorizadas de API´s (seção 3.1) como também modificações nas políticas IAM (seção 3.4). No caso do AWS existe um numeroso conjunto de avisos comportamentais em suas configurações, todos voltados para colaborar na segurança e prevenções dos serviços em execução.

Estar ininterruptamente disponível na internet é similar a ter um comércio físico mas diferente deste ele não possui horário de funcionamento, fica continuamente disponível. Por este comportamento as ameaças circulantes, ou premeditadas tem grandes oportunidades e tempo disponível para suas investidas.

Ciente destas disponibilidades, o CIS recomenda estabelecer um contato de segurança (seção 1.20) e os termos de segurança estejam devidamente registrados (seção 1.15). Agindo assim uma comunicação segura é estabelecida, sendo acionada na ocorrência de incidentes de segurança.

Por exemplo para ataques de negação de serviço (DDNS) existe na plataforma da Amazon o AWS Shield como uma proteção contra esse tipo de investida. Na incidência efetiva desses ataques é preciso efetuar uma minuciosa investigação, como reação no caso de uma real investida maciça.

Internamente é fundamental revisar as políticas de backup e restauração de desastres agregando modelos de backup offline, na iminência de uma invasão o criminoso tendo acesso ao seu painel de controle poderá facilmente eliminar todo o seu histórico de cópias de segurança.

No ambiente virtualizado uma das vantagens deste modelo é o que pode-se chamar de “atacar pelas órbitas” quando detectar invasões em seu ambiente. Garantindo que sua equipe de DevOps seja hábil em restaurar seus servidores instantaneamente após a interrupção dos ataques, num cenário mais trabalhoso é melhor a indisponibilidade de um ou dois dias à perda permanente dos dados.