Segurança + Cloud
Andrey Brito, Lívia Sampaio Campos
Sistemas Distribuídos – 2012.3
Segurança
• Objetivos: proteger recursos no sistema
– Integridade
– Privacidade
– Disponibilidade
• Se o sistema é isolado segurança = segurança
física
– Mas acesso físico pode ser importante em um SD
– Acesso ao servidor pode anular a segurança lógica
Segurança (2)
• Política vs. mecanismos
– O que é permitido e o que não é vs...
– Como isso é implementado
• No mundo físico
– Política: somente funcionários podem entrar no
prédio, o lab deve estar sempre trancado se ninguém
estiver lá
– Possíveis mecanismos: porteiro, chaves, senhas
• São independentes
Ameaças e ataques
• Classes de ataques
– Vazamento (leakage)
– Adulteração (tampering) – Vandalismo
• Em SDs, muito depende do comprometimento do canal
– Interceptação (eavesdropping) – Personificação (masquerading)
– Adulteração de mensagens (ex., man-in-the-middle) – Replay
– Negação de serviço (deny-of-service, DOS)
Participantes em protocolos
Sistemas Distribuídos 2012.3 COPIN/UFCG/CEEI 7
Alice First participant
Bob Second participant
Carol Participant in three- and four-party protocols
Dave Participant in four-party protocols
Eve Eavesdropper
Mallory Malicious attacker
Ataques e ameaças (2)
• Fontes de problemas mais comuns
– Bugs no código (recente: JRE afetando aprox. 1
bilhão de usuários)
– Irresponsabilidade de administradores e usuário
(senha mais popular: “monkey”; “m0nk3y” não é
melhor)
– Excesso de confiança (ex., cavalos de tróia,
instalação de certificados)
Desenvolvendo sistemas seguros
• Assuma que as interfaces estão expostas
• ... e que as redes são inseguras (adulteração)
• ... que algoritmos e código fonte está disponível
para o atacante (“no security-through-obscurity”)
• ... que o atacante tem muitos recursos
• Limite o escopo e tempo de vida de um segredo
• ... e a parte do sistema que precisa ser confiável
Criptografia
• Mecanismo básico para segurança
– Por chave compartilhada (eficiente, mas precisa
distribuir a chave)
– Por chave pública e privada (ineficiente, mas evita
parcialmente a distribuição)
• Usos de criptografia
– Proteção de segredo e integridade (ex., criptografas
uma mensagem a ser enviada na rede)
– Autenticação (ex., duas pontas conseguem provar que
elas sabem o segredo sem deixá-lo vazar)
Criptografia (2)
• Usos de criptografia (cont.)
– Assinatura (ex., provar que um conteúdo não foi alterado e foi produzido pelo remetente, independente do
mensageiro)
– Usando o conceito de “resumo” de uma mensagem
• Certificado: aplicação de assinatura para que duas
partes que não se conhecem possam se autenticar
– Entidade confiável C assina o certificado para o servidor S – O usuário U conhece C e sabe reconhecer sua assinatura – E se C quer revogar o certificado?
Alguns tópicos
• Segurança vs. conveniência (ex., autenticação)
• Autenticação
– OpenID, Oath, OAUTH
– Multifator, chave pública
• “Trusted computing”
• Privacidade e segurança dos dados
– O valor da informação é subestimado
– Correlação de dados, tracking, header “Do-not-track”
“Onion routing”
• Uma mensagem com muitas camadas
– Cada camada diz o próximo destino em uma rede
de roteadores (overlay)
– Criptografia entre vizinhos
– Mensagens com tamanho fixo: tira uma parte,
adiciona algo no fim, encaminha
• Tor (The Onion Router): tornar tráfego TCP
anônimo
– Desafios?
Para pensar
• Técnicas gerais de segurança (o que assumir
quando construir um sistema)
• Conceitos de criptografia
• Assinatura digital
• Autenticação
Referências
• Distributed Systems: Concepts and Design
– G. Coulouris, J. Dollimore, T. Kindberg – Addison-Wesley, 2005
• Distributed Systems for System Architects
– P. Veríssimo e L. Rodrigues
– Morgan Kaufmann Publishers, Inc., 1996
• Tor: the second-generation onion router
– R. Dingledine, N. Mathewson, P. Syverson – Usenix Security Symposium, 2004
– https://www.torproject.org/
COMPUTAÇÃO NA NÚVEM
Alguns comentários sobre cloud computing
O que é cloud computing?
• Uma forma de oferecer recursos de TI que
permite que usuários comprem
recursos
...
– Sob demanda;
– De forma automática;
– Com uma granularidade adequada às suas
necessidades;
Por que cloud computing?
• O que alguém poderia ganhar com isso?
– Você não se preocupa em
montar
a infraestrutura
– Você não se preocupa em
manter
a infraestrutura
– Você não se preocupa em
dimensionar
a
infraestrutura
• É uma moda?
– É útil porque frequentemente reduz custo
– Cobrança mais justa; maior confiabilidade;
– Você tem um gerador elétrico próprio?
Origem – Ideia
• A ideia é antiga ...
– Década de 50, mainframes eram os únicos
computadores e eram caros, origem do
compartilhamento de tempo
– Anos 60, foi especulado que um dia computação seria
uma utilidade (serviço público, como eletricidade)
• ... e ganhou destaque por vários motivos
– Desenvolvimentos tecnológicos
– Mudanças no perfil de aplicações
– Uma vez surgida, possibilitou aplicações que
realimentaram o ciclo
Desenvolvimento tecnológico
• Um exemplo de uma aparição anterior de cloud
computing é grid computing
– Grid computing é um termo derivado de “power grid” – Usuários poderiam usar os recursos na medida que
quisessem e pagar apenas pelo realmente utilizado
• Problema com computação em grade
– Tecnologia de virtualização não estava madura o suficiente (difícil isolar aplicações de diferentes clientes)
– Comunicação era cara
– Pegou apenas para nichos específicos (ex., computação científica)
Desenvolvimento tecnológico
• Aos poucos virtualização se torna mais
eficiente (suporte nativo)
– Data centers gigantes
começam a ser viáveis
– Custos de energia, comunicação e hardware caem
– Lei dos grandes números ajuda a balancear a
carga (necessário para dar a ilusão de
disponibilidade da cloud)
Onde colocar o próximo data center?
Fonte: http://www.nodeju.com/wp-content/uploads/2011/10/facebook-data-center-north-pole.jpg
Facebook está construindo um data center no norte da Suécia http://thenodepole.com/
Mudança nas aplicações
• Web 1.0
– Alguns grandes sites complexos (ex., e-commerce) – Sites pequenos e simples (ex., páginas pessoais)
• Web 2.0
– Tecnologias de interação
– Não precisa mais entender de HTML para gerar conteúdo – Sites podem lucrar com propagandas (Google AdSense) de
forma simples
– Pagamentos online se tornam mais simples (Paypal, pequenas empresas podem aceitar cartões de crédito)
Mais uma ideia
• A Amazon já é um site gigante– 90% do seu data center fica ocioso o tempo todo
– Mas ainda vale a pena tê-lo, às vezes é necessário (ex., Natal) – E se essa capacidade ociosa fosse vendida?
– 2006: Amazon Web Services
• Uma vez possível algumas aplicações ganham força
– Se aventurar com um empreendimento de e-commerce não precisa mais de um grande investimento
– Análise de dados (ex., para BI) pode usar 1000 máquinas por 1 hora ao invés de 1 por 1000 horas gastando a mesma coisa
Modelos de implantação
• Participantes: consumidores, provedores e
clientes
• Implantação física no provedor
– Nuvem privada
– Nuvem comunitária
– Nuvem pública
Modelos de implantação (2)
• Características comuns
– Dependem do bom funcionamento da rede
– Usuários têm pouco controle da localização exata
do recurso
– As cargas são balanceadas de forma transparente
– Todos os usuários estão sujeitos ao problemas de
compartilhamento de máquinas
– Erros de segurança (ex., configuração de políticas)
no servidor
Modelos de implantação (3)
• Segurança: controle e visibilidade
– Quem pode acessar o quê?
– Recursos são remotos, proteção precisa usar
tecnologias de rede
– Redes virtuais privadas (Virtual Private Network –
VPN)
– Firewall
Modelos de serviço: o que são os
recursos?
• Infraestrutura: máquinas, discos e ligações com a
Internet (virtuais)
– Processamento, armazenamento, comunicação – IaaS (Infrastructure as a Service)
• Plataformas: ambientes que rodam aplicações
– Java, Go, MapReduce (ou até Matlab, R) – PaaS (Platform as a Service)
• Software: um sistema pronto para usar (primeiro)
– Google Docs, Webmail
Responsabilidades
IaaS
• O consumidor
acessa máquinas virtuais
(VM) é
disponibilizadas
– No caso de VMs Linux: programas podem ser instalados via linha de comando remota (SSH)
– No caso de Windows: pode ser usada uma conexão de desktop remoto (RDP)
• Componentes (no provedor)
– Gerenciador de nuvem (portal para o consumidor)
– Gerenciador de cluster (lida com pedidos de alocação) – Supervisor (gerencia as VMs em um servidor físico) – Conectividade é chave
PaaS
• O usuário cria aplicações online ou faz o upload da sua aplicação
– Não se preocupa com detalhes da plataforma
– Não se preocupa com detalhes de execução (VMs, escalabilidade)
• Componentes
– Consumidor recebe um ambiente para o desenvolvimento e gerência da aplicação e um ambiente de execução
– Em alguns casos, usam plataformas com ambientes de desenvolvimento locais
– As vezes, tudo funciona via Web (nada a ser instalado pelo desenvolvedor ou pelo cliente)
– Mas um problema é que isso pode significar dificuldade de migração (sem portabilidade)
SaaS
• O usuários
configura aplicações
existentes no
provedor
• Componentes
– Tudo acontece no provedor
– Consumidores precisam apenas de um navegador
para configurar
– Clientes (frequentemente) precisam apenas de um
navegador (acesso universal)
– Pode ser recursivo (um provedor SaaS usa vários
provedores SaaS para oferecer seu serviço)
Mudança no serviço
• Data center Cloud provider (IaaS)– Já cuidava da infraestrutura física
– Mas os grão de consumo eram (são) grandes
– Elasticidade, simplicidade e dinamicidade do provedor são essenciais
• Hospedagem Cloud provider (PaaS)
– Já cuidava da infraestrutura e da plataforma
– Pouca funcionalidade e flexibilidade na plataforma de hospedagem
– Pouco suporte a elasticidade
• Hospedagem (Wikis, Blogs) Cloud provider (SaaS)
– Também já cuidava da infraestrutura e da plataforma – Aplicações simples
Por que virar um provedor?
• Uma empresa pode querer se tornar um provedor IaaS,PaaS ou SaaS
• Lucro é real: economia de escala realmente faz diferença
– Estudos apontam que grandes empresas podem conseguir recursos de 5 a 7 vezes mais barato que pequenas e micro empresas
– Exemplos: acesso à Internet, preços por serviço de manutenção, hardware em quantidade, energia com taxas diferenciadas
• Reutilizar investimento anterior (software ou hardware)
– Caso da Amazon que começou a vender recursos ociosos – Um serviço de hospedagem poderia ter que lidar com
Por que virar um provedor? (2)
• Mudar o seu modelo de negócio– Ao invés de vender software como um pacote, vender SaaS – Mais fácil de atingir novos mercados
• Aumentar seu relacionamento com seus clientes existentes
– Na medida que o cliente passa a usar um SaaS, por exemplo, a empresa tem acesso à mais informações sobre esse uso
– Estratégias de CRM + BI podem ser aplicadas
• Uma pequena empresa pode querer se tornar um provedor SaaS (mesmo que compre IaaS de outro)
Por que virar um provedor? (3)
• A evolução natural dos modelos de negócio
– Valores são apenas ordens de grandeza – O importante é a relação entre eles
• Licença + suporte: 4000/usuário + 600/usuário
– Dominante por muito tempo – Ainda não incluir o hardware
• Código livre + suporte: 0/usuário + 1600/usuário
– Poucos conseguiram fazer sucesso com isso (ex., RedHat) – Ainda não incluir o hardware
Por que virar um provedor? (4)
• Outsourcing: x + 1000/usuário
– Empresa especializada, funcionários tem experiência
– Usa sempre o mesmo hardware e software
– Hardware incluído
• SaaS: menor que (0 + 100/usuário)
– Empresa superespecializada
– Manutenção tem muita coisa automatizada (IaaS)
– Extremo:
Internet
(pago por taxas de transação ou
Exemplo – Repassando o risco
• Utilização típica de um servidor é 5% a 20%
– A taxa de pico sobre entre 2 e 10 vezes
– Subdimensionar ? Consumidores rejeitados são
rancorosos
– Se o seu serviço requer 50 servidores ao meio-dia e
somente 10 à meia-noite, se a utilização média for em
torno de 30 ao longo do dia, você pagará com cloud,
30*24 = 720 horas de uso
– Com servidores próprios, você está pagando 50*24 =
1200
Problemas com provisionamento
estático
Fonte: M. Armbrust, A. Fox, R. Griffith et. al. Above the Clouds: A Berkeley View of Cloud Computing. Relatório técnico. Fevereiro, 2009.
Eixo vertical: recursos Eixo horizontal: tempo
Sobre custo operacional
• Mas se eu usar quase 100% do datacenter
próprio, então é possível que usar um
Tempo de resposta e utilização
Exemplos
• Animoto: empresa com sistema que produz
vídeos a partir de fotos, músicas e outros vídeos
(“2 vídeos nunca são iguais”)
– Depois de disponibilizar serviço no Facebook (2008), a
quantidade de servidores necessários cresceu de 50
para 3500 em 3 dias
– O que fazer sem cloud?
• Comprar quando a carga começar a crescer? Quanto tempo demora?
• Comprar antes?
• Clientes rejeitados não voltam e o sucesso poderia ter sido menor
Desafios e obstáculos (1)
• Disponibilidade– Replicar em vários provedores
– Ainda pode ser melhor que local na empresa
• “Data Lock-in”
– Consumidor preso por causa dos dados
– Em um SaaS, os dados não estão sob controle do consumidor – Não é um problema tão grave para IaaS
• Reputação herdada
– As vezes, IPs são marcados em listas negras
– Depois esses IPs podem ser reciclados e o novo dono herda a má reputação
Desafios e obstáculos (2)
• Segurança e privacidade
– Proteção de rede (VPN e firewall)
– Tornar dados anônimos (usar identificadores, decriptografar dados na máquina do cliente)
– Deixar parte da aplicação na empresa (em uma aplicação multicamadas, algumas camadas ficam totalmente na cloud, outras apenas parcialmente)
• Transferência de dados: mesmo com muita banda,
podem ser muitos dados
– Envio de discos
– Canais contratados (demora dias, mas Amazon pode criar canais dedicados)
Desafios e obstáculos (3)
• Escalando vertical e horizontalmente
– Pode ser difícil escalar horizontalmente (dividir o trabalho por mais máquinas)
– Escalar verticalmente (deixar a VM mais poderosa) pode ser possível em breve (é mais difícil de gerenciar)
• “Encolhendo” as aplicações
– Aumentar as aplicações tem recebido mais atenção do que encolher
• Modelo de licenças ainda está se adaptando
– Você usa um software ou serviço na cloud – Como você paga? E se o serviço é revendido?