4.3 Módulo de Backups da IPBrick Cloud
4.3.3 Funcionalidade de Encriptação de Backups
Os backups são dados tipicamente em repouso, por esse motivo e pelo facto de o local de ar- mazenamento dos dados dos backups no modelo-solução consistir numa VM apropriada para tal na IPBrick cloud, ou seja, em espaço remoto, os dados devem permanecer encriptados até que seja feito um restore do backup. A ferramenta Bacula possui uma funcionalidade própria de encrip- tação de backups que permite garantir os requisitos de segurança pertencentes ao triângulo CID: confidencialidade, integridade e disponibilidade. Essa funcionalidade recorre a diversas técnicas
4.3 Módulo de Backups da IPBrick Cloud 69
criptográficas, destacando-se as seguintes: cifra assimétrica RSA, cifra simétrica AES e certifica- dos x509. Os dados dos backups são encriptados na máquina correspondente ao cliente Bacula e armazenados na máquina do diretor. As chaves criptográficas devem ficar permanentemente armazenadas na máquina do cliente.
Chave privada RSA Certificado x509
| |
client.key client.cert Estrutura PKI client.cert /etc/bacula/Figura 4.17: Protocolo com vista à geração da estrutura PKI para encriptação dos dados dos backups, pela ferramenta Bacula.
A chave secreta simétrica para encriptação dos dados é gerada automaticamente a partir da file-daemondo cliente, no entanto, o par de chaves público-privado RSA bem como o certificado x509 devem ser fornecidos pelo utilizador. Para geração automática das chaves RSA e do certifi- cado x509 auto-assinado pela IPBrick SA, foi criado o protocolo representado pela Figura4.17. Da geração da chave privada e acrescentado a chave pública correspondente, resulta o certificado x509. A concatenação entre certificado x509 e chave privada forma uma public key infrastruc- ture(PKI). O ficheiro correspondente à PKI é exportado para o diretório onde está localizada a file-daemondo cliente Bacula. Os ficheiros correspondentes à chave privada e ao certificado x509 devem ser guardados num diretório seguro e distinto do "/etc/bacula". As recomendações da CSA em relação às boas práticas para gestão de chaves criptográficas, enunciadas no ponto2.3.3.5, são seguidas, uma vez que as chaves mantém-se armazenadas num local diferente dos dados encrip- tados. No caso de perda das chaves e do certificado, para que se mantenha a disponibilidade dos dados dos backups, a ferramenta Bacula permite a criação de uma PKI suplente que é gerada, de igual forma, a partir do protocolo representado pela Figura4.17, e que deve ser armazenada num local diferente da VM1. Os mecanismos criptográficos da ferramenta Bacula asseguram também a verificação da integridade dos dados através do uso da função de hash, SHA-256.
4.3.4 Desenvolvimento do Protótipo 4.3.4.1 Tecnologias Utilizadas
Para implementação de um protótipo do módulo de backups da IPBrick cloud foram utilizadas as seguintes tecnologias:
• Ambiente de Desenvolvimento - Duas VMs com o guest OS IPBrick v6.1 (Debian GNU/- Linux 7.5 wheezy).
• Pacote de Instalação - Bacula-7.2.0.
• Linguagens Front-End - JavaScript, HTML, CSS.
• Gerenciador de Base de Dados - Gerenciador de base de dados PostgreSQL. • Linguagens Back-End - PHP, Linux Shell Scripting.
4.3.4.2 Desenvolvimento do Front-End
A implementação do front-end foi desenvolvida na máquina do cliente Bacula, representando essa máquina um possível cliente da IPBrick SA. Na interface web de gestão da IPBrick cloud foi criado um sub-menu designado por "Backups Bacula" que aponta para a página principal do módulo de backups dos dados da IPBrick cloud. A página principal (Figura4.18), foi desenvolvida de modo a apresentar uma lista de diferentes tarefas em estados distintos.
Figura 4.18: Página principal do módulo de backups da IPBrick cloud. Aparecem listadas para exemplo, três tarefas com parametrizações distintas.
Na Figura4.18 são apresentadas duas tarefas de backup que se distinguem pela parâmetro periodicidade. Periodicidade "single" associada ao "Single Backup", indica que a tarefa de backup programada deve ser realizada apenas uma única vez, definindo-se uma data e hora específicas para a sua execução. Para as tarefas de periodicidade "daily" é necessário apenas definir a hora que se pretende que iniciem. O IP do servidor de backups Bacula é exibido no parâmetro "Backup
4.3 Módulo de Backups da IPBrick Cloud 71
Location". A encriptação é parametrizada apenas nas tarefas de backup. A tarefa restore acontece no exato instante em que é programada, sendo necessário indicar apenas o ponto de restauro no tempo, mantendo-se os restantes parâmetros associados ao backup selecionado para o efeito. Na lista de tarefas da página principal é também possível visualizar o estado das mesmas. Existem quatro estados distintos: "Programmed", "Running", "Finished" e "Error". A tarefa restore pelo facto de ser executada no mesmo instante em que é programada, poderá passar por todos os estados com exceção do "Programmed".
A partir da página principal, é possível criar uma nova tarefa acedendo à página correspondente através da ligação "Insert". Os formulários diferem no tipo de tarefa a programar e no caso dos backups, na periodicidade que se pretende atribuir. As Figuras4.19,4.20e 4.21representam os três formulários criados para programação das diferentes tarefas.
Figura 4.20: Página correspondente à parametrização de um backup singular.
Figura 4.21: Página correspondente à parametrização da tarefa restore.
A partir da lista de tarefas exposta na página principal, é também possível selecionar individu- almente cada tarefa e alterar os parâmetros que lhe estão associados, bem como elimina-la da lista de tarefas.
4.3 Módulo de Backups da IPBrick Cloud 73
Figura 4.22: Resultado da implementação da página individual de cada tarefa.
4.3.4.3 Desenvolvimento do Middle-End
Para exportar a parametrização feita pelo cliente aquando da inserção, alteração ou eliminação de uma tarefa, recorre-se ao auxílio de uma tabela criada para o propósito na base de dados local da VM correspondente ao cliente Bacula, através do gestor PostgreSQL.
Administrador Alterar_Tarefa Tarefas
ID Tarefa Tipo Nome ID Morada 1 1 Endereço_IP Inserir_ Tarefa Eliminar_ Tarefa Período Data Hora Estado Encriptação
Figura 4.23: Modelo entidade-associação na origem da criação da tabela de auxílio ao módulo de backups, na base de dados local.
As três relações distintas entre a entidade "Administrador" e a entidade "Tarefas Bacula" são representadas na Figura4.23. Foi criada uma tabela na base de dados local associada à entidade "Tarefas Bacula" em que os tuplos da entidade representam as a maior parte das colunas integran- tes da tabela. A chave primária "ID" da entidade "Tarefas Bacula" foi configurada, aquando da geração da tabela, como sendo foreign-key de outra chave primária de uma tabela pertencente ao schemaassociado à ferramenta Bacula, identificadora de cada tarefa programada na ferramenta. Refira-se novamente que a ferramenta Bacula tem uma base de dados própria para auxílio na ges-
tão de backups localizada na VM correspondente ao diretor ou servidor Bacula. Essa interação entre tabelas de diferentes schemas, possuindo ambas o mesmo elemento identificador de tarefas, permite com que seja obtida informação relevante diretamente da base de dados da ferramenta Bacula através da interface fornecida pela bconsole que suporta a realização de SQL queries do lado do cliente. Para eliminar e alterar tarefas, adicionaram-se duas colunas à tabela associada à entidade "Tarefas Bacula", que funcionam como flags indicando se a tarefa sofreu alteração ou ordem de remoção.
4.3.4.4 Desenvolvimento do Back-End
O desenvolvimento propriamente dito do software relativo à camada back-end teve como base a leitura dos valores inseridos pelo cliente na interface web de administração da IPBrick cloud, a partir tabela criada para o efeito na base de dados local. Fazendo uso dos valores lidos, foram executados pedidos ao servidor Bacula através da bconsole. Um exemplo de um pedido executado a partir de um dos ficheiros desenvolvidos, pode ser observado na lista de código4.4.
1 $ (e c h o " r u n Backup " && e c h o " mod " && e c h o " 6 " && e c h o \" ". $ h o r a D a t a ." \ " && e c h o " mod " && e c h o " 1 " && e c h o \" ". $ t i p o ." \ " && e c h o " y e s ") | b c o n s o l e
Lista de Código 4.4: Comando para execução de um pedido ao servidor Bacula para realização da tarefa de backup.
O código da lista4.4é constituído maioritariamente por comandos estáticos da própria bibli- oteca de comandos da bconsole. O comandos estáticos traçam o trajeto necessário para serem aplicadas as configurações do cliente através dos comandos dinâmicos fazendo uso das variáveis "$horaData" e "$tipo". A variável "$horaData" possui o valor correspondente à concatenação da hora e da data definidas para execução da tarefa, e a variável "$tipo" possui o valor correspon- dente ao tipo de backup a executar: incremental ou completo; sendo que o primeiro backup a executar é por defeito um backup completo. Ambas as variáveis possuem os valores resultantes da parametrização da tarefa de backup realizada pelo cliente da IPBrick SA.
A tarefa de backup com periodicidade diária requer ainda que seja programado de forma dinâ- mica, um cronjob no sistema. Um exemplo de um cronjob relativo ao backup diário programado para as 00:00h de cada dia pode ser visto na lista de código4.5.
1 00 00 ∗ ∗ ∗ (e c h o " r u n " && e c h o " 1 " && e c h o " mod " && e c h o " 1 " && e c h o " 1 " && e c h o " y e s ") | b c o n s o l e
Lista de Código 4.5: Exemplo da definição de um cronjob para agendamento dos backups diários. Para encriptar os dados dos backups na VM do cliente, é executado um script baseado no protocolo da figura4.17, aquando do primeiro pedido do cliente para realização de um backup en- criptado, sendo que a partir daí as chaves criptográficas pertencentes ao cliente ficam armazenadas nos diretórios secretos criados para o efeito, de forma permanente. É necessário também ajustar
4.3 Módulo de Backups da IPBrick Cloud 75
dinamicamente as configurações da file-daemon do cliente Bacula (lista de código4.6), de forma a ativar a funcionalidade de encriptação do Bacula.
1 2 F i l e D a e m o n { 3 Name = s r v r s −f d 4 F D p o r t = 9102 5 W o r k i n g D i r e c t o r y = / v a r / r u n / b a c u l a 6 P i d D i r e c t o r y = / v a r / r u n / b a c u l a 7 Maximum C o n c u r r e n t J o b s = 20 8 FDAddress = 1 7 2 . 3 1 . 3 . 5 8 9 10 # Dynamic c o n f i g u r a t i o n s t o e n a b l e e n c r y p t i o n 11 PKI S i g n a t u r e s = Yes 12 PKI E n c r y p t i o n = Yes 13 PKI K e y p a i r = " / e t c / b a c u l a / c l i e n t . pem " 14 PKI M a s t e r K e y p a i r = " / e t c / b a c u l a / m a s t e r . pem " 15 }
Lista de Código 4.6: Configurações geradas dinamicamente para ativação da encriptação dos backups, linhas (10-14).
Na lista de código 4.6 gerada dinamicamente são ativadas as "PKI Signatures" para verifi- cação da integridade dos dados, a funcionalidade de encriptação através da "PKI Encryption", e indicados os caminhos da PKI gerada para encriptação dos dados no atributo "PKI Keypair", e da PKI suplente no atributo "PKI Master Keypair". Caso não se deseje encriptar os dados para uma dada tarefa, as configurações da file-daemon são novamente ajustadas ficando os atributos "PKI Signatures" e "PKI Encryptions" ajustados com o parâmetro "No".
No que toca à implementação da tarefa de restore, esta requer a execução de um conjunto de comandos fornecendo-se o ponto exato no tempo para a recuperação do backup que mais se apro- xima desse ponto. A lista de código4.7mostra um exemplo do conjunto de comandos utilizados:
1 $ e c h o " r e s t o r e " && e c h o " 6 " && e c h o \" ". $ h o r a D a t a ." \ " && e c h o " 2 " && e c h o " 2 " && e c h o " mark ∗ " && e c h o " d o n e " && e c h o " y e s ") | b c o n s o l e
Lista de Código 4.7: Comando para execução de um pedido ao servidor Bacula para realização da tarefa de restore.
4.3.5 Testes Funcionais
Para comprovar a eficácia de toda a implementação feita na IPBrick cloud relativa ao módulo de backup dos dados da ferramenta Bacula, foram realizados três testes conclusivos, sobre as funcionalidades implementadas. Na tabela a baixo é possível observar o processo de validação levado a cabo por cada teste realizado.
ID Descrição por Passos Progonóstico Resultado 1 Teste de verificação da execução de tarefas
pela ferramenta Bacula:
1. Programação de uma tarefa backup a realizar no instante imediato.
2. Programação de uma tarefa restore a re- alizar a partir de um ponto anterior ao instante atual.
3. Observação dos dados das tarefas nos diretórios correspondentes.
Prevê-se a visualização dos da- dos relativos ao backup numa poolde armazenamento em for- mato hexadecimal, no diretório correspondente do servidor Ba- cula bem como a visualização dos dados relativos ao restore em claro no diretório correspon- dente no cliente Bacula.
Bem Sucedido
2 Teste de verificação da encriptação dos dados dos backups:
1. Programação de uma tarefa backup a realizar no instante imediato, ativando a funcionalidade de encriptação. 2. Observação dos dados no servidor Ba-
cula efetuando um dump dos dados da pool, armazenados no formato hexade- cimal.
3. Programação de uma tarefa restore a re- alizar a partir de um ponto anterior ao instante atual.
Após a realização de um dump dos dados hexadecimais arma- zenados no servidor Bacula, espera-se que os mesmos se en- contrem no formato encriptado. Do resultado do restore devem ser observados os dados correta- mente desencriptados.
Bem Sucedido
3 Teste do mecanismo de verificação da integri- dade dos dados:
1. Programação de uma tarefa backup a realizar no instante imediato, ativando a funcionalidade de encriptação. 2. Manipulação dos dados do backup ar-
mazenados no formato hexadecimal na pool de armazenamento no servidor Bacula.
3. Programação de uma tarefa restore a re- alizar a partir de um ponto anterior ao instante atual.
Durante o restore aguarda-se a deteção da violação da integri- dade dos dados efetuada e algum procedimento de ação relativa- mente ao dados em causa.
Bem Sucedido
Tabela 4.2: Testes efetuados para verificação das funcionalidades do módulo de backup dos dados da IPBrick cloud.
4.4 Conclusão 77
De referir que os dados são comprimidos antes de serem armazenados na pool de armazena- mento criada para o efeito no servidor Bacula e por isso ficam expostos num formato hexadecimal. Para visualização dos dados em texto claro é necessário converte-los para o formato binário fa- zendo um dump dos mesmos, utilizando para isso um comando Linux específico. Relativamente ao teste sobre o mecanismo de integridade, após a deteção de irregularidades na integridade dos dados, o restore é anulado e o backup correspondente aos dados manipulados é dado como incon- sistente.
4.4
Conclusão
Todo o trabalho desenvolvido e descrito no presente capítulo teve como objetivo a implemen- tação do modelo-solução definido no capítulo anterior, na IPBrick cloud.
A integração da eCryptfs decorreu sem causar perturbações no restante conjunto de servi- ços pertencentes à IPBrick cloud e validou a estratégia de encriptação definida no capítulo 3, conseguindo-se garantir essencialmente, os parâmetros de confidencialidade e disponibilidade dos dados tipicamente em repouso, associados às aplicações assíncronas. Ao nível do utilizador definiram-se dois modos de encriptação em que um deles procede ao armazenamento da password do cliente na VM com o objetivo de aumentar o nível de disponibilidade do sistema. Mas ainda que a password seja armazenada de forma ofuscada e a sua desencriptação requerer algum estudo dos protocolos implementados por parte de um possível adversário, existirá sempre pelo menos uma backdoor explorável. Contudo, pretende-se com estes dois modos, dar a opção de escolha ao cliente entre um nível de segurança máximo ou a autonomia e com isso, a disponibilidade total da IPBrick cloud isto porque, no caso de um reboot da VM do cliente seria necessário uma nova introdução da password na interface de administração e até ao acontecimento do referido proce- dimento, os dados permaneceriam encriptados. A implementação do mecanismo de autenticação do host revelou-se uma alternativa consistente em relação aos restantes métodos criptográficos aplicados. De fato, este mecanismo pode até prevenir eventuais backdoors existentes por exem- plo, no modo de encriptação "Safe", já referido, alertando para possíveis invasões e impedindo a exposição imediata dos dados em texto claro.
A implementação do módulo de backups dos dados trouxe um serviço eficaz à IPBrick cloud permitindo um aumento da disponibilidade dos dados do cliente, existindo possíveis pontos de re- cuperação úteis sobretudo em procedimentos de distaster recovery. Os dados dos backups podem ainda ser encriptados, garantindo-se sempre a tríade CID no que a este módulo diz respeito.
A partir dos testes funcionais realizados, conclui-se que o modelo-solução foi corretamente implementado sendo evidente a eficácia das estratégias e ferramentas adotadas.
Capítulo 5
Conclusões e Trabalho Futuro
O último capítulo da dissertação pretende expor ao leitor o ponto de vista do autor em relação às metas concretizadas, tendo em conta os objetivos iniciais propostos pela IPBrick SA. Pretende igualmente explorar o trabalho futuro no que diz respeito ao aperfeiçoamento das estratégias im- plementadas para o cumprimento dos objetivos e possíveis procedimentos adicionais de segurança a acrescentar aos já integrados na IPBrick cloud.
5.1
Objetivos Alcançados
Os três objetivos definidos inicialmente relacionados com a segurança da IPBrick cloud: im- plementação de uma estratégia encriptação dos dados, implementação de uma estratégia de bac- kupdos dados, e a criação de interfaces de gestão das estratégias para interação com o cliente da IPBrick SA, foram satisfeitos. No entanto, as expetativas no que se refere essencialmente à encriptação dos dados do cliente na IPBrick cloud eram porventura, demasiado otimistas. O autor considerou inicialmente a abordagem de estratégias que possibilitassem a encriptação da totali- dade dos dados do cliente, de forma permanente, independentemente da fase do ciclo de vida em que se pudessem encontrar ou do tipo de aplicações a que estivessem associados sendo que, e tal como foi descrito no capítulo 3, a estratégia baseada na aplicação do algoritmo FHE permitiria hipoteticamente atingir esse nível de segurança criptográfica. Contudo, no contexto tecnológico atual, não existe capacidade de processamento computacional suficiente para implementação prá- tica da estratégia FHE. À falta de outras alternativas idênticas, optou-se por encurtar a gama de dados da IPBrick cloud visada pelos processos de encriptação, integrando-se uma ferramenta crip- tográfica no próprio ambiente de virtualização da cloud, permitindo-se garantir a segurança dos dados armazenados no disco virtual sendo esses dados tipicamente dados em repouso. Posto isto, o objetivo de encriptação dos dados foi reformulado e passou a ter-se em conta apenas a proteção criptográfica exercida sobre os discos virtuais sendo o mesmo concretizado com sucesso, tal como já referido anteriormente. Uma outra estratégia de autenticação do host do guest OS, não direta- mente relacionadas com os objetivos da encriptação dos dados, mas que contribui ativamente para a eficácia do mesmo, foi igualmente implementada e testada com sucesso.
Tendo em conta a estratégia de backup dos dados, o objetivo inicial em relação à mesma passava pelo incremento do requisito de disponibilidade dos dados do cliente. Adicionalmente foi também possível integrar uma funcionalidade específica de encriptação dos dados dos backups. O objetivo foi assim concluído com êxito.
Das ameaças e vulnerabilidades nos serviços em cloud descritas em2.3.2, os protótipos im- plementados visam principalmente, colmatar as ameaças e vulnerabilidades que possam advir do ponto 3 relativo à partilha de tecnologias, e do ponto 4 relativo à perda ou fuga de dados.
Considerando o próprio trabalho desenvolvido na IPBrick SA, os protótipos implementados demonstraram o correto funcionamento das estratégias e ferramentas adotadas, para darem res- posta aos objetivos propostos. Posto isto, os objetivos quer ao nível académico e científico, quer ao nível da estratégia empresarial, foram alcançados de forma satisfatória.