Sistemas Distribuídos. Enunciado da Segunda Parte do Projecto

Transcrição

1 LEIC-A, LEIC-T, LETI, MEIC-T, MEIC-A Sistemas Distribuídos 2 o Semestre 2013/2014 Enunciado da Segunda Parte do Projecto Este enunciado apresenta os requisitos relativos à segunda parte do projeto de Sistemas Distribuídos e pressupõe a realização de todos os requisitos da primeira parte. As soluções desenvolvidas na primeira parte CHEQUEREFEICAO e REGISTOFATURA têm limitações importantes no que diz respeito a segurança e tolerância a faltas. A segunda parte do projeto pretende estender as soluções desenvolvidas com alguns requisitos de qualidade que seriam fundamentais para usar os serviços no mundo real. Cada um dos requisitos deverá, sempre que possível, ser implementado sem alterar a lógica de negócio já implementada, ou seja, sem alterar os contratos WSDL. As secções seguintes descrevem cada requisito em maior detalhe. 1. Segurança de CHEQUEREFEICAO Os cheques de refeição são uma forma de dinheiro eletrónico. Isto significa que o serviço vai ser alvo de ataques de clientes mal intencionados, que o tentarão enganar de várias formas, por exemplo, para sacar cheques mais do que uma vez, etc. Pretende-se conceber e implementar uma política de segurança que assegure que o sistema de cheques é resistente a ataques. Nesta segunda fase, um número de cheque poderá ser visto como sendo uma sequência de caracteres que inclui duas partes: um identificador público e um segredo. O conhecimento do número de um cheque (identificador público + segredo) constitui uma capacidade (capability) que dá a quem a conhece a permissão de usar o cheque armazenado no servidor. Mais precisamente: Quando um utilizador faz um pagamento usando um cheque, o número do cheque deve ser fornecido à entidade que beneficiará do cheque. Usando esse número, a entidade beneficiária poderá depois sacar o cheque. Por outro lado, operações como listar, que não se pretende que concedam permissões de uso a quem as invoca, devem devolver apenas o identificador público de cada cheque.

2 1.1. Protocolo base O protocolo base consiste na emissão e utilização de um cheque. O protocolo é descrito de seguida e são identificados requisitos de segurança. São usadas as seguintes abreviaturas: CR é o serviço CHEQUEREFEICAO, T é o Titular, B é o Beneficiário. T e B são utilizadores de CR. + indica concatenação. (i) O Titular pede para emitir um cheque. T CR : emitir(t, valor, endossavel) Deve-se garantir que: CR é capaz de confirmar que foi T quem escreveu o pedido e que o mesmo não foi modificado no caminho; apenas CR consegue ler o pedido. (ii) O CHEQUEREFEICAO emite o cheque. T CR : id+segredo Deve-se garantir que: o segredo foi gerado de forma não previsível (secure random number); foi CR quem escreveu a resposta e a mesma não pode ser modificada; apenas T consegue ler a resposta. (iii) O Titular apresenta o número de cheque como pagamento ao Beneficiário. T B : id+segredo Este passo é manual. Por exemplo, no REST o utilizador preenche o número de cheque no formulário de pagamento. (iv) O Beneficiário saca o cheque. B CR : sacar(b, id+segredo) Deve-se garantir que: CR é capaz de confirmar que foi B quem escreveu o pedido e o mesmo não pode ser modificado; apenas CR consegue ler o pedido. (v) O CHEQUEREFEICAO marca o cheque como usado e devolve o seu valor. B CR : valor Deve-se garantir que: consegue-se verificar que foi CR quem escreveu a resposta e que a mesma não pode ser modificada no caminho; apenas B consegue ler a resposta. Para permitir a autenticação e o não-repúdio de algumas operações, foi decidido que todas as entidades CHEQUEREFEICAO e cada um dos seus utilizadores terão um par de chaves de criptografia assimétrica (chave pública e chave privada). 2

3 Assume-se que: CHEQUEREFEICAO conhece à partida a sua chave privada e as chaves públicas de todos os utilizadores; Cada utilizador conhece à partida a sua chave privada e a chave pública de CHEQUEREFEICAO Protocolo de endosso O protocolo de endosso consiste na delegação da capacidade de utilização do cheque do Titular para um terceiro, chamado Endossado (E). O protocolo é descrito de seguida. (a) O Titular contacta CHEQUEREFEICAO para endossar o cheque. T CR : endossar(t, E, id+segredo) (b) O CHEQUEREFEICAO endossa o cheque e o segredo associado ao cheque deve mudar. T CR : id+segredo2 (c) O Titular fornece o cheque ao Endossado. T E : id+segredo2 Este passo é manual. (d) O Endossado apresenta o número de cheque como pagamento ao Beneficiário. E B : id+segredo2 Este passo é manual. De seguida o Beneficiário vai sacar o cheque, de forma semelhante à do protocolo base. Que requisitos de segurança devem ser garantidos em cada passo? São necessárias modificações ao protocolo base? 1.3. Protocolo de endosso desligado Como aspeto avançado, seria vantajoso que o endosso pudesse ser feito sem intervenção do CHEQUEREFEICAO, permitindo ao Titular fazer a sua gestão de cheques de forma desligada do serviço. Por exemplo, uma empresa (titular) iria emitir vários cheques. Depois iria dá-los aos seus colaboradores (endossados) quando entendesse ser oportuno e sem contactar o serviço. Os colaboradores utilizariam os cheques para pagar refeições. Deve-se estender o protocolo para permitir o endosso desligado, usando as funções criptográficas à disposição, ponderando vantagens e desvantagens de cada abordagem possível. O protocolo estendido deve ser apresentado de forma semelhante ao protocolo base e de endosso, indicando os passos e respetivos requisitos de segurança. 3

4 2. Replicação do serviço REGISTOFATURA A tolerância a faltas do serviço REGISTOFATURA é crítica. Por essa razão pretende-se estender o serviço com suporte a replicação, para o dotar de uma maior disponibilidade. Pretende-se seguir a abordagem de replicação passiva, usando como ponto de partida o protocolo estudado nas aulas teóricas. Cada gestor de réplica deverá utilizar uma base de dados própria para armazenar o seu estado (exceto grupos LETI, que não precisam de implementar a persistência). A solução implementada deve (I) garantir consistência sequencial mesmo em situações de falha do servidor primário e substituição do mesmo pelo servidor secundário. A solução deve também (II) assegurar transparência de replicação, tanto quanto possível. Em simultâneo, a solução deverá, sempre que possível, (III) privilegiar o desempenho da resposta ao cliente. A avaliação do projeto dará forte ênfase a estes três requisitos. Face à solução apresentada nas teóricas, a solução a desenvolver deverá suportar a existência de múltiplos servidores secundários. Tal implica desenhar um protocolo adequado para deteção da falha do servidor primário e respetiva substituição por um único servidor secundário eleito. Como modelo de interação e faltas, deve assumir-se que: Os gestores de réplica podem falhar silenciosamente mas não arbitrariamente; O conjunto de gestores de réplica é estático; no entanto, os seus endereços não são conhecidos a priori e podem variar ao longo do tempo; Não se considera a recuperação dos gestores de réplica depois de falha, o que obrigaria a repor a consistência do gestor de réplica que recupera; O sistema é síncrono e não acontecem falhas permanentes da rede; A comunicação é feita sobre um protocolo de transporte fiável que assegura entrega ordenada de mensagens (e.g. HTTP); Os gestores de réplica têm relógios locais sincronizados, com taxas de desvios negligenciáveis. 4

5 3. Metodologia No caso de grupos ES+SD, é esperado que sejam seguidas as boas práticas de gestão de projecto (SCRUM) e que a aplicação e os serviços funcionem todos em conjunto na demonstração final. Recomenda-se que cada grupo siga o seguinte planeamento: Desenho dos protocolos e detalhes de implementação. Ao fim do primeiro sprint, entregar ao docente de laboratório um documento curto (com 1 ou 2 páginas) com o esboço da solução definida pelo grupo (texto e/ou pseudo-código e/ou diagramas temporais); dessa forma o docente poderá comentar e apontar correções na solução mais cedo; Implementar a solução base. No fim de cada sprint apresentar uma demonstração simples ao docente para que este possa comentar e apontar melhorias possíveis; Estender a solução base com os aspetos avançados indicados. No sprint final, ter uma solução funcional e usar o tempo que antecede a discussão para preparar uma demonstração final onde os docentes possam aceitar as histórias desenvolvidas. 4. Relatório e demonstração Cada equipa do grupo deve entregar um relatório sobre os requisitos de qualidade implementados (com 2 ou 3 páginas). Cabe aos estudantes valorizar o seu trabalho, demonstrando que funciona corretamente. Por exemplo: mostrar a deteção de cheques falsificados, mostrar a recuperação do servidor de faturas. etc. Os alunos que estão a realizar o projecto de ES+SD devem usar as ferramentas e técnicas de teste aí ensinadas. 5. Entrega e avaliação O prazo de entrega da segunda parte do projeto de SD é dia 14 de Maio às 20h00. A entrega do projeto é feita através do repositório SVN (ou através do Fénix para os grupos que não têm repositório), de acordo com as instruções na página web. A avaliação de SD desta entrega incidirá sobre os requisitos descritos neste enunciado, sobre a integração com ES; e os testes realizados. Continuação de bom trabalho! 5