Segurança

Depois das longas pesquisas sobre replicação vamos agora para a segurança!!!

Quando se fala em segurança temos de considerar quatro componentes:

• Autenticação, subdividida em cliente e servidor
• Autorização, necessária para sistemas de elevada granularidade
• Confidencialidade, proteger infomação como chaves, passwords, etc.
• Privacidade, proteger toda a informação

Para já vamos focarnos em garantir autenticação cliente e servidor, autorização e confidencialidade.

Conselhos práticos:

• Usar protoclos públicos, cohecidos e testados.
• Usar diferentes chaves para autenticação e confidencialidade
• Uso de autenticadores associados a um utiliador evitando o envio de passwords, protegido por uma marca para evitar falsificação e com tempo de expiração para diminuir o tempo de utilzação em caso de quebra de segurança.
• Alteração periódica da chave para evitar ataque de força bruta.

nota: O identificador do autenticador tem de ser criptográficamente aleatório, a fim de evitar a previsão de possives identificadores e respetiva falsificação.

Opções de implementação do Repositório de Dados

Escritas:

• (Log operações, Dados), cada réplica é constituida por um conjunto de operações ordenadas e uma base de dados resultado da execução dessas operações. Propagar operações reduz a quantidade de informação a ser transmitida, assim como evita os conflitos de inserção e remoção de registos. Necessita de espaço para guardar essa informação. Não é necessária para reconciliação do tipo "Total". Mais´eficiente na detecção de conflito e sua resolução.

Reconciliação:

• Tipo(Total, Diferencial), na propagação diferencial a quantidade de informação a ser propagada é proporcional ás alterações efectuadas em vez de ser depedndente do tamanho da base de dados.
• Modo(Incremental, Transaccional), no modo incremental é possível a recuperação de uma falha de comunicação durante a fase de reconciliação em vez de ter de repetir todas as operações e evita estados inconsistentes. Cada operação reconciliada com sucesso é registada no servidor, assim como o identificador da ultima. Em caso de falha é a partir deta que a reconciliação é recomeçada. Necessita de um protocolo de transporte que garanta a ordem na entrega das mansagens.

Ligações:

• não estruturadas (pares), reconciliação entre qualquer par de réplicas, propagação mais rápida baseada na teoria de epidemia, não necessita de um servidor activo para efectuar actualizações, mais complexo no contorlo de versões, necessidade de duas réplicas se encontrarem online em simultaneo que no nosso caso será quase impossível.
• estruturada (master-slave, ring, ...), maior controlo sobre a propagação de actualizações usando uma hierarquia. As replicas masters reconcilian-se entre sí as slave apenas com o seu master, obriga a ter o master activo para poder reconciliar. Em ring existe um caminho predeterminado para propagação.

No nosso caso usamos a hierarquia master-slaves em estrela, um master(repositorio central) e varios slaves (réplicas locais). Facilita a remoção de informação dos logs, pois cada réplica pode exonerar todas as operações já reconciliadas e no servidor todas as já propagadas para todas as réplicas existentes.

Flexible Update Propagation forWeakly Consistent Replication.
Petersen, K., Spreitzer, M.J., Terry, D.B., Theimer,
M.M., Demers, A.J. Proceedings of the Sixteenth
ACM Symposium on Operating System Principles
(SOSP), Saint-Malo, Franco, October 1997.

Designing and Implementing Asynchronous Collaborative Applications with Bayou

Introdução
Bayou é uma infrastrutura de suporte de aplicações distribuidas colaborativas, em ambientes de conectividade variada e armazenamento de fraca consistência. Permite ás aplicações a descrição da semantica de restrições de integridadde, dectecção de conflitos, procedimentos de resolução automáticos e politicas de propagação. Baseia-se na existência de diversos colaboradores, permitindo edição offline através de réplicas e posterior reconciliação. Permite a reconciliação entre qualquer par de réplicas.

Caracteristica da colaboração assincrona
Utilizadores não necessitam de ser notificados em tempo real das alterações realizadas por outros, trabalhando independentemente por periodos de tempo. Facilita a gestão do tempo e espaço de trabalho. Permite trabalhar em condições de fraca conectividade, ou mesmo na sua ausencia como por exemplo em aviões. A independência é talvez a caracteristica chave do trabalho assíncrono

Suportar colaboração assincrona
A replicação é um meio frequentemente usado para conseguir a independência do trabalho. Permite separar as ações dos utilizadores, aumentar o desempenho e tolerancia a falhas. Uma das formas mais fortes da independência é a abilidade de trabalhar completamente desconectado da rede e poder adicionar dados á sua própria replica. Este facto requer suporte de replicas de fraca consistencia. Os utilizadores devem poder controlar quando deve ocurrer a sincronização. Resolvedores de conflitos automáticos melhoram o sincronismo. Cada aplicação deve poder definir as politicas de resolução de conflitos.

Modelo
Bayou é composto por um conjunto de servidores, contendo cada um uma réplica dos dados. É usada uma base de dados relacional, podendo no entanto ser usados outros modelos de dados. Permite acesso a pequenas partes dos dados, util para detecção e resolução de conflitos. A garantia de consistencia é dada pela imposição de uma ordem global nas operações de escrita e garantia de propagação.

Mecanismos para a semântica da aplicação
Detecção e resolução de conflitos - separado em três componentes: verificação da dependência; instrução de update; protocolo de fusão.
Garantia de sessão
Diferenciação entre dados estaveis e tentativas.
Selecção da réplica a sincronizar.
Politicas de propagação, que permitem controlar quando é realizada a propagação.

nota: solução próxima da pretendida se entendermos que o utilizador pode tomar o papel de diferentes colaboradores dependendo da maquina utilizada.

The IceCube approach to the reconciliation of divergent replicas

Baseada na utilização de log's de acções.
As acções são combinadas duas a duas, obtendo todas as restrições estáticas entre elas.
É realizado um reordenamento dessas acções por forma a evitar esses conflitos.

Conflitos estáticos - conflitos de ordem entre as acções (apagar registo -> alterar registo)
Conflitos dinamicos - conflitos de estado (1 <= dia <= 31)

Sheduling phase:
recebe como entrada os dois logs a reconciliar, verifica as relações entre as acções e reordena os logs.

Simulation phase:
simula a reordenação feita anteriormente obtendo um resultado. Estas duas fases são realizadas diversas vezes gerando vários estados possiveis.

Selection phase:
selectionar um dos estados gerados, por exemplo utilizando uma função de custo.

Referências sobre sincronização

Gentilmente cedidas por José Simão.

Designing and Implementing Asynchronous Collaborative Applications with Bayou

W. Keith Edwards, Elizabeth D. Mynatt, Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, and Marvin Theimer. ACM Symposium on User Interface Software and Technology, 1997.

Session Guarantees for Weakly Consistent Replicated Data

D. B. Terry, A. J. Demers, K. Petersen, M. J. Spreitzer, M. M. Theimer, and B. B. Welch. Proceedings International Conference on Parallel and Distributed Information Systems (PDIS), Austin, Texas, September 1994, pages 140-149.

The IceCube approach to the reconciliation of divergent replicas

Anne-Marie Kermarrec, Anthony Rowstron, Marc Shapiro, and Peter Druschel. PODC, 2001.

Controlo de registos

Controlo de registos passa sempre por questionar o utilizador.
Pode ser complexo para o utilizador dar uma resposta.

Criação de árbitros, com conhecimento do dominio, que implementem o PDRA.
A resolução de ameaças reais passa também por questionar o utilizador, no entanto, e visto o árbitro ter conhecimento do dominio, permite questionar o utilizador de forma mais especifica do problema.

Replicação do repositório

Aumenta a tolerancia a falhas

Aumenta a disponibilidade do serviço

Backup ou balanceamento de carga??

Gerido pelo serviço de localização??

Protocolos para sincronismo

Protocolo de Detecção e Propagação de Actualizações (PDPA)

Detectar alterações, quer do repositório quer da réplica

Propagar essas alterações

Confirmar as alterações

Protocolo de Detecção e Resolução de Ameaças (PDRA)

Detectar possiveis ameaças (alteração dos mesmos registos)

Resolver ameaças reais (alteração dos mesmos dados)

Identificadores

É necessário criar identificadores globais para evitar conflitos na replicação

Uma possivel solução é colocar informação local associada ao identificador

Funcionamento offline

Uma alteração offline tem de ser confirmada pelo repositório

E entretanto na réplica?

     1. Cria-se uma vista que permita conjugar essas alterações à custa do log
     2. Assume-se que é válida e caso exista conflitos no repositório, este procede à reposição do estado anterior

Funcionamento online

Modo assincrono, alterações registadas em log e posteriormente actualizadas (semelhante ao modo offline)

Modo sincrono?

     1. Aumento do trefego
     2. Operações mais lentas
     3. Diminui conflitos porque os dados encontrna-se num estado mais consistente.
     4. Reduz a probabilidade de ameaças, visto que só uma réplica estará online em cada momento