Risco em projetos cloud computing

1. Risco em Projetos Cloud Computing
Alfredo Santos

2. Alfredo Santos
• Formado em:
– Ciências da Computação
– Gestão de Empresas
– Gestão de TI
• Autor de livros de Segurança e Arquitetura de
Sistemas
• Certificado em Cobit e ISO 27002
• Email: alfredo.luiz@gmail.com
• Linkedin: http://www.linkedin.com/profile/view?id=871673
• Site: www.alfredosantos.com.br

3. Cloud Computing - Inevitável

4. Como o negócio vê Cloud
Computing

5. Risco em Projetos Cloud
Computing

6. Tipos de Cloud
IaaS
Cloud
PaaS SaaS

7. Tipos de Cloud - IaaS
• IaaS (Infraestrutura como serviço) - Onde a
infraestrutura básica é oferecida pelo
provedor e os demais componentes e
aplicativo são de responsabilidade do
contratante.

8. Tipos de Cloud - PaaS
• PaaS (Plataforma como serviço) - Onde o
contratante entra com a solução de aplicação
e os demais serviços são responsabilidades do
provedor de serviços.

9. Tipos de Cloud - SaaS
• SaaS (Software como serviço) - Onde toda
solução é responsabilidade do provedor de
serviços, o que não diminui a
responsabilidade do dono da informação.

10. Como se previnir para diminuir o risco?

11. Estabelecer em contrato os SLAs
incluindo os casos de incidentes de
segurança
É muito importante um detalhamento forte de SLA nos contratos
pois o controle sai totalmente do time interno de TI e Segurança.
Qualquer indisponibilidade de infraestrutura, ataques de
negação de serviço, vulnerabilidades e outros incidentes de
segurança, se não estiverem bem estabelecidos em contrato,
não poderão ter o devido tratamento em tempo hábil,
impedindo penalidades e multas.

12. Fornecer o desenho da arquitetura
de segurança
O fornecedor deve alinhar com você (e detalhar em contrato) a
arquitetura de segurança empregada no ambiente dele. Ele não
necessariamente deve informar o fabricante, mas deve garantir
que possui por exemplo:
● Firewall segregando ambientes (Internet, Operação, dados de
cartões, etc.).
● Antivírus
● Soluções de detecção de intrusão

13. Possuir proteções especializadas
de perímetro, como por exemplo,
IPS e Firewall de aplicação.
Segurança tecnológica não se resume a Firewall. É necessário
que seu parceiro de negócio que está disponibilizando as
soluções na nuvem, esteja preparado para proteger o perímetro
de forma mais efetiva.

14. Possuir proteções especializadas
de perímetro, como por exemplo,
IPS e Firewall de aplicação.
Se for uma solução de e-mail na nuvem:
● Antivírus
● AntiSpam
● Controle de vazamento de informação
● Possibilidade de se criar regras específicas de bloqueio,
incluindo anexos.
● Monitoração dos e-mails

15. Possuir proteções especializadas
de perímetro, como por exemplo,
IPS e Firewall de aplicação.
Se for uma solução de aplicativo na nuvem:
● Ferramenta de detecção de intrusão (IPS)
● Firewall de aplicação
● Firewall de nova geração
● Ferramenta de mitigação de ataques DDOS
● Controle de vazamento de informação
● Correlação de logs

16. Possuir firewall de rede segregando todas
as redes, separando inclusive usuários
operadores do ambiente de servidores.
Agora um ponto de atenção em relação ao tradicional firewall é
o correto posicionamento dele, sendo que é importante
posicionar segregando além do perímetro:
● Servidores de aplicação x Base de dados geral
● Bases de dados x dados de cartão de crédito
● Ambiente de operação x ambiente de servidores

17. Segregação de função dentro do provedor,
onde por exemplo, quem atua dentro do
datacenter não é a mesma pessoa que
opera o sistema.
O objetivo deste ponto é garantir que uma pessoa com acesso
direto a um equipamento não tenha acesso lógico ao mesmo,
isso minimiza problemas diversos, como por exemplo, a pessoa
conectar um HD externo e copiar informação privilegiada, ou
acessar diretamente um servidor e manipular arquivos de
configuração do mesmo.

18. Permitir Análises de Vulnerabilidade e
Ethical Hacking
O provedor de solução na nuvem deverá permitir em contrato
que sejam feitas análises de vulnerabilidade e Ethical Hacking
em cima do ambiente, devidamente agendados visando garantir
disponibilidade do ambiente.
Este tipo de análise poderá ser feita por uma empresa terceira
contratada pelo fornecedor, mas desde que seja reconhecida a
credibilidade por você contratante.

19. Permitir acesso ao log do ambiente e
sistemas
Alinhar com o provedor quais serão os mecanismos para acesso
a log do ambiente. É necessário ter visão de toda rastreabilidade
de administração de usuários e perfis de acesso, incluindo
criação, alteração, exclusão, troca de senha, além de registros de
quem realizou determinadas transações criticas. Isso pode ser
disponibilizado por um portal por exemplo.

20. Permitir o uso de ferramentas de
correlação e retenção de log
O provedor deve permitir o uso de coletores de log para envio
para ferramentas de correlação e retenção de log que ficam
dentro de sua empresa (on premises).
Depois disso, fica a cargo do correlacionador cruzar este log com
outros logs para identificar ameaças de segurança.

21. Ter um focal de segurança para atender o
contratante durante toda vigência do
contrato
O provedor deve possuir uma pessoa que seja a ponte de
aspectos de segurança com o cliente final. Esta pessoa é a
responsável por gerenciar as demandas e problemas que possam
vir a acontecer com segurança. Esta pessoa também é
responsável por organizar os relatórios de segurança para o
contratante.

22. Realizar uma gestão de vulnerabilidades,
ameaças e riscos alinhada com o
contratante.
Basicamente o ciclo de gestão de vulnerabilidades, ameaças e
riscos deve ser alinhado com a área de segurança da informação
do contratante para que a empresa contratante tenha controle
dos riscos de segurança sem ficar “no escuro”.
Este é o ponto mais complicado, pois os fornecedores não se
sentem confortáveis em compartilhar isso, então o item anterior
de Análise de Vulnerabilidades e Ethical Hacking é fundamental
para suprir parte de eventuais deficiências deste item.

23. Compartilhar a politica de continuidade de
negócios e plano de recuperação de
desastres
O recomendado neste caso é uma apresentação de como o
fornecedor gerencia estes pontos e SLAs voltados para
continuidade de negócio estabelecidos em contrato.

24. Ter a certificação SAS70 ou similar
SAS70 e certificações novas similares são certificações voltadas
para datacenter e não necessariamente para soluções na nuvem.
Então considerem que este tipo de certificação é obrigatório
para um datacenter, mas não suficiente para não checar os
demais itens de computação na nuvem.

25. Detalhar em contrato o processo de
termino de atividades
Basicamente se resume em detalhar no contrato como será
tratada a informação no caso de fim de contratação do serviço
na nuvem.
Deve ser considerada a questão de exportação e entrega da
informação e destruição de backups e rastros de dados que
ficariam no provedor.

26. Detalhar em contrato o processo de
descarte de dados
Em contrato devem ser estabelecidos os métodos utilizados para
descarte de dados considerando storage de servidores e fitas de
backup relacionadas a seu negócio.

27. Detalhar em contrato o processo de
respostas a demandas legais
Um provedor de serviços na nuvem, eventualmente pode sofrer
uma demanda legal de entrega de informações (Isso pode variar
muito de acordo com as leis de cada pais).
É necessário estabelecer um processo de comunicação para o
contratante nos casos de demanda legal, onde o mesmo deve
ser avisado, no caso da necessidade de entrega de ativos de
informação.

28. Detalhar em contrato o processo de
backup e guarda de fitas
Outro item importante que deve ser claramente detalhado em
contrato.
A frequência de backup (diário, mensal e anual por exemplo)
deve ser acordada e colocada no contrato e a guarda do backup
deve ficar em local seguro, externo a empresa do provedor.

29. Detalhar o quanto o
ambiente/infraestrutura é compartilhado
com outros clientes
Este ponto precisa ser claramente estabelecido entre as partes e
claramente documentado em contrato.
Existem diversas possibilidades de segregação que podem
ocorrer em um ambiente de solução na nuvem.

30. Segurança por obscuridade

31. Detalhar o quanto o
ambiente/infraestrutura é compartilhado
com outros clientes
Infraestrutura (Firewall, rede, servidores web) compartilhados e
dados em servidores separados.
Infraestrutura e dados em ambientes compartilhados
Dados segregados em lógica de programação (pior caso), onde o
código do programa define o que vai exibir para cada cliente.

32. Informar como gerenciam o controle de
vazamento de informação
Sua informação está em um local sem seu controle e operado
por outras pessoas. É necessário entender (E sempre colocar em
contrato) como o vazamento de informação é gerenciado pela
contratada.
Pode ser um ambiente muito restrito, onde os operadores não
acessam internet ou mídias removíveis (USB, CD, DVD, etc.) ou
um ambiente com solução de DLP instalada.

33. Detalhar procedimentos em casos de
ataques DDOS
Detalhar em contrato como funciona a prevenção a DDOS (Caso
exista) e como funciona o procedimento de comunicação para o
contratante.

34. Identificar onde ficará o datacenter ou os
datacenters da solução para atender ou se
preocupar com particularidades legais
locais
Basicamente é importante constar em contrato a localização dos
datacenters onde ficarão os dados da solução em nuvem, pois
isso influenciará a questão de atendimento a demandas legais
que podem variar de acordo com o pais.

35. Demonstrar o processo de gestão de
chaves criptográficas
Esta é uma das partes mais importantes de segurança em
computação na nuvem pois é decisiva em relação à
confidencialidade de dados.
O mais correto é que os dados sejam criptografados e que as
chaves de criptografia fiquem em poder do contratante, pois
caso fiquem em poder do contratado, existe um risco maior de
que alguém roube ou utilize as mesmas.

36. Controle de acesso
Imagine que sua aplicação está fora agora da sua empresa. Como
fica a questão de gestão de usuários (Criação, Exclusão,
Alteração) e perfis de acesso?
Um caminho é a gestão por meio da interface fornecida pelo
contratado, outro meio, é a utilização de um recurso conhecido
como federação.

37. Controle de acesso
Basicamente federação consiste em uma base de usuários
confiar em bases externas. Ou seja, a aplicação na nuvem pode
consultar um usuário dentro da sua empresa na sua base de
rede por exemplo.
Isso te dá uma série de vantagens, como por exemplo, ter o
controle dos usuários mais próximos, facilidade para bloquear
um usuário, senha única, etc.

38. Controle de acesso
Outra preocupação em relação a controle de acesso é o uso de
autenticação forte, pois considerando que o serviço ficará mais
exposto na internet, o ideal é que o usuário utilize algo mais,
além do par tradicional, usuário e senha. Neste caso,
recomendo:
● Token físico
● Cartão de senhas
● Biometria
● Senha por SMS

39. Permissão de auditorias externas
Após o fornecedor prometer os diversos itens acima, é chegada a
hora de considerarem em contrato que você contratante pode
realizar visitas de auditorias periódicas para comprovar o
andamento dos compromissos de contrato relacionados à
segurança.
Para isto ser mais efetivo, sugiro o uso de um checklist. Este
checklist pode ser utilizado para o momento de contratação e
para estas auditorias periódicas.

40. Checklist