Risco em projetos cloud computing
2 gostaram1,158 visualizações
O documento discute os riscos associados a projetos de computação em nuvem e fornece recomendações para mitigar esses riscos. As recomendações incluem estabelecer acordos de nível de serviço detalhados, fornecer informações sobre a arquitetura de segurança e permitir auditorias de segurança. O objetivo é ajudar os clientes a se protegerem adequadamente ao adotarem serviços de nuvem.
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: [email protected] • 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.
- 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