Arquitectura e modelos de sistemas distribuidos

11,134 views

Published on

Arquitectura e modelos de sistemas distribuidos

  1. 1. Sumário1 Modelo Arquitectural.............................................................................................3 1.1 Modelo de camada .........................................................................................3 1.1.1 Plataforma ..............................................................................................3 1.1.2 Middleware ............................................................................................4 1.2 Modelo de arquitectura de Sistemas ..............................................................9 1.2.1 Modelo Cliente Servidor........................................................................9 1.2.2 Serviços Providenciados por Múltiplos Servidores .............................11 1.2.3 Servidores proxies e caches .................................................................12 1.2.4 Modelo P2P (Peer to Peer) .................................................................13 1.3 Variações do modelo Cliente Servidor ........................................................14 1.3.1 Código Móvel ......................................................................................14 1.3.2 Agentes Móveis ...................................................................................15 1.3.3 Computadores em rede ........................................................................16 1.3.4 Thin Clients (Clientes Leves)...............................................................16 1.3.5 Dispositivos móveis e rede espontânea................................................17 1.4 Modelo de interfaces e objectos (Orientado a objectos) ..............................182 Critérios para a escolha do Modelo .....................................................................193 Modelo fundamental ............................................................................................20 3.1 Modelo de interacção...................................................................................21 3.1.1 Desempenho do Canal de Comunicação..............................................23 3.1.2 Relógio do computador e tempos de eventos ......................................24 3.1.3 Variações do modelo de interacção .....................................................24 3.1.3.1 Sistemas distribuídos síncronos .......................................................24 3.1.3.2 Sistemas distribuídos assíncronos....................................................25 3.1.4 Ordenação de Eventos..........................................................................26 3.2 Modelo de falhas..........................................................................................27 3.2.1 Definições Básicas ...............................................................................28 3.2.1.1 Fault tolerance - tolerância a falhas ...........................................28 3.2.1.2 Availability – disponibilidade....................................................28 3.2.1.3 Reliability - fiabilidade...............................................................28 3.2.1.4 Timeliness- adequação temporal ou pontualidade ..............28 3.2.2 Tipos de falhas .....................................................................................28 3.2.2.1 Falhas por omissão e arbitrárias ............................................29 3.2.2.2 Mascarar falhas de componentes ..........................................30 3.2.3 Falhas temporais ..................................................................................30 3.3 Modelo de segurança ...................................................................................31 3.3.1 Protegendo objectos .............................................................................31 3.3.2 Protegendo processos e suas interacções .............................................32 3.3.3 O inimigo .............................................................................................33 3.3.3.1 Ameaças a processos........................................................................33 3.3.3.2 Ameaças a canais de comunicação ..................................................34 3.3.4 Defendendo-se das ameaças de segurança...........................................35 3.3.5 Outras possibilidades de ameaça de um inimigo .................................36 3.3.5.1 Denial of Service..............................................................................37 3.3.5.2 Código móvel...................................................................................37 3.3.6 O uso dos modelos de segurança .........................................................374 Bibliografia ..........................................................................................................38 1
  2. 2. Modelos de Estruturação de Sistemas DistribuídosOs modelos servem para compreender o funcionamento de um sistema no queconcerne: • As principais entidades que formam o sistema; • A forma como essas entidades interagem entre si; • A factores que afectam o comportamento individual e/ou colectivo das entidades.Em sistemas distribuídos tem-se os seguintes modelos:1 Modelo ArquitecturalIlustra a estruturação dos diferentes componentes e suas interacções.1.1 Modelo de camadaEstruturação do software em diferentes níveis: • Plataforma; e • Middleware.Fig. 1: Camadas de serviços de software e hardware num SD1.1.1 PlataformaOs níveis mais baixo de camadas de software e hardware, são frequentementereferenciados como sendo a plataforma para sistemas e aplicações distribuídas. Estascamadas (níveis) mais baixas disponibilizam serviços para as camadas acima delas,que são implementados independentemente em cada computador, trazendo o interface 3
  3. 3. Índice de FigurasFig. 1: Camadas de serviços de software e hardware num SD ......................................3Fig. 2: Máquinas, Sistemas de Rede e Sistemas Operacionais de diversos fabricantes 4Fig. 3: Rede formada por diversas plataformas .............................................................5Fig. 4: Desafio de integração de ambientes heterogéneos .............................................5Fig. 5: Midleware como solução para integração de ambientes heterogéneos ..............6Fig. 6: Clientes invocam servidor individual.................................................................9Fig. 7: Web crawler .....................................................................................................10Fig. 8: Um serviço providenciado por múltiplos servidores........................................11Fig. 9: Servidor proxy ..................................................................................................12Fig. 10: Uma aplicação distribuída baseada em processos peer..................................14Fig. 11: Applets Web....................................................................................................14 2
  4. 4. de programação para um nível que facilita a coordenação e comunicação entreprocessos. Intel x86/Windows; SPARC/SunOS, intel X86/Solarris, Intel x86/Linuxsão principais exemplos.1.1.2 MiddlewareProblemas:Como integrar e distribuir os sistemas?Como construir um ambiente para solucionar este novo paradigma com a existênciade: • Ambiente de desenvolvimento heterogéneo; • Rede diversas (arquitecturas e protocolos), • Multe vendedores, • Não existe consenso sobre a plataforma de hardware, • Não existe consenso sobre sistema operacional, • Não existe consenso sobre a plataforma de desenvolvimento, • Não existe consenso sobre a middlewareUma das Motivações do surgimento do Midleware é o ambiente de computação actualem que Máquinas, Sistemas de Rede e Sistemas Operacionais são de diversosfabricantes, conforme ilustra a fig. 2.Fig. 2: Máquinas, Sistemas de Rede e Sistemas Operacionais de diversos fabricantes 4
  5. 5. Então surge uma questão: como ultrapassar estas limitações, visualizadas na fig. 3.Fig. 3: Rede formada por diversas plataformasFig. 4: Desafio de integração de ambientes heterogéneosOs constrangimentos, colocados nas figuras 2 a 4, podem ser resolvidas com aintegração usando Midleware. 5
  6. 6. Fig. 5: Midleware como solução para integração de ambientes heterogéneosSegundo (Rymer 1996), Middleware é um software que permite elementos deaplicações inter operarem através de redes, apesar das diferenças nos protocolos decomunicação, arquitecturas de sistemas, sistemas operacionais, bases de dados eoutros serviços de aplicação.É simplesmente um software de conectividade que consiste de um conjunto deserviços que permitem múltiplos processos rodando sobre uma ou mais máquinas,interagirem através de uma rede. (Eckerson 1995)Um middleware deve fazer diversas coisas. Primeiro, ele provê um modo para obterdados de um lugar (..) para outro lugar (..). Segundo, ele deve mascarar as diferençasexistentes entre: sistema operativo; plataformas de hardware e protocolos de rede.Terceiro, ele deve ocultar a complexidade do processo de transporte da rede, dodesenvolvedor da aplicação. (Salamone 1996)Para cada uma das camadas (apresentação, aplicação e de dados), definiu-se ummiddleware correspondente. Um exemplo de: 6
  7. 7. • Middleware de apresentação é o trio: navegador; protocolo HTTP e servidor Web que dividem a responsabilidade da comunicação para mostrar uma página através da Internet. • Middleware de dados é, em geral, fornecido pela desenvolvedora do banco de dados e tem como função fazer as consultas SQL no servidor através da rede, retornando o resultado à estação cliente. • Outro exemplo de middleware de dados são os gateways que gerenciam acessos a diferentes bancos de dados, usando uma API ODBC (Application Programming Interface Open Database Connectivity).A seguir são apresentadas as categorias de Middleware: • Middleware não orientado a objetos: – Distributed Computing Environment (DCE) – conjunto de serviços e ferramentas que executam sobre um sistema operativo existente auxiliando no desenvolvimento de aplicações distribuídas. – Message Oriented Middleware (MOM) – método de comunicação entre componentes de software utilizado em sistemas distribuídos. O MOM é um tipo de middleware orientado a mensagem. Um cliente pode enviar e receber mensagens de forma assíncrona de qualquer outro cliente, conectados a um agente especial que fornece facilidades para criar, enviar, receber e ler mensagens. – Database Middleware – providencia uma forma padrão de aceder a dados de uma base de dados. – Distributed TP (Transaction Processing) Monitors – os monitores de TP reduzem uma aplicação para o nível de transacções. Desenvolvedores criam a maior parte das funções das aplicações como transacções com um início, um meio e um fim. Estas funções são usualmente discretas como uma actualização num banco de dados de clientes, ou remoção de linhas de vários bancos de dados heterogéneos ao mesmo tempo. Uma aplicação é simplesmente o processo de invocar uma transacção após a outra. Utilizando este modelo transaccional, os monitores de TP são capazes de recuperar problemas que podem ocorrer durante o processamento da transacção e retornar o 7
  8. 8. sistema de volta ao estado em que ele estava antes da transacção ser invocada. Este esquema evita problemas na rede e no banco de dados, já que, ou a transação funciona até ao fim ou todas as suas acções são desfeitas (rollback).• Middleware orientado a objetos distribuídos: – CORBA – Common Object Request Broker Architecture – arquitectura padrão criada pelo Object Management Group para estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogéneos. – DCOM – Distributed Component Object Model - é um modelo mais popular de objectos distribuídos, à semelhança do CORBA. A diferença é que o DCOM é proprietário da Microsoft. – RMI – Remote Method Invocation – interface de programação que permite a execução de chamadas remotas no estilo RPC em aplicações desenvolvidas em Java. É uma forma de implementar um sistema distribuído em plataforma Java – Web Service – solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. OsWeb services são componentes que permitem às aplicações enviar e receber dados em formato XML (eXtensible Markup Language). Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML. – EJB – Enterprise JavaBeans – é um dos principais componentes da plataforma J2EE (Java 2 Enterprise Edition). É um componente do tipo servidor que roda no container para EJB do servidor de aplicação. Os principais objectivos da tecnologia EJB são fornecer rápido e simplificado desenvolvimento de aplicações Java baseadas em componentes, distribuídas, transnacionais, seguras e portáveis. 8
  9. 9. 1.2 Modelo de arquitectura de SistemasA divisão de responsabilidades entre componentes do sistema (aplicações, servidorese outros processos) e a colocação desses componentes em computadores em rede é,talvez, o aspecto mais evidente do desenho de sistemas distribuídos. Esta divisão deresponsabilidades tem maiores implicações para a desempenho, confiabilidade esegurança do sistema. Neste ponto, mostram-se os principais modelos de arquitectura,nos quais esta distribuição de responsabilidades é baseada.Em sistemas distribuídos, processos com responsabilidades bem definidas interagementre eles, para realizar uma actividade. Os principais tipos de modelos dearquitectura são mostrados da fig. 6 a fig. 9.1.2.1 Modelo Cliente ServidorEsta arquitectura é a frequentemente mais citada quando se aborda sistemasdistribuídos. É historicamente a mais importante e continua a mais largamenteaplicada. A fig. 6 ilustra uma simples arquitectura, na qual processos clientesinteragem com os processos de servidores independentes em máquinas separadas, deforma a aceder o canal partilhado por eles.Fig. 6: Clientes invocam servidor individual 9
  10. 10. Em algum momento os servidores podem ser clientes de outros servidores, comoilustra a fig. 6. Por exemplo, um servidor Web é frequentemente um cliente para umservidor local de ficheiros, que faz a gestão das páginas Web em si armazenadas.Servidores Web e muitos outros serviços de Internet são clientes dos serviços DNS(Domain Name System), que traduz os nomes dos domínios da Internet para endereçosde rede. Outro exemplo, também relacionado com a Web, são os motores de buscaque permitem aos usuários pesquisar resumos de páginas Web em sites da Internet.Estes resumos são feitos, por programas chamados Web crawler1 (vide fig. 7), quecorrem por detrás do site do motor de busca usando requisições http2 para acederservidores Web através da Internet.Fig. 7: Web crawlerUm motor de busca é ao mesmo tempo um servidor e um cliente: ele responde asolicitações de navegadores cliente e ele executa Web crawlers que age como clientepara outros servidores Web. Neste exemplo, as tarefas do servidor (respondendo asrequisições dos usuários) e as tarefas do crawler (fazendo requisições a outrosservidores Web são totalmente independentes); existe uma pequena necessidade desincronizá-los e eles podem correr de forma concorrente. De facto, um motor de buscatípico incluiria muitas threads de execução concorrentes, alguns servindo seus clientese outros executando Web crawlers .1 De acordo com Crovella, Lindemann e Reiser (2000), os sistemas de busca na Internet cresceramconsideravelmente nos últimos anos. Esses sistemas operam geralmente através de agentes. A maiorparte destes mecanismos de procura e indexação de informações são chamadas de Web crawlers.2 Hyper Text Transfer Protocol 10
  11. 11. 1.2.2 Serviços Providenciados por Múltiplos ServidoresServiços podem ser implementados como múltiplos processos de servidores emcomputadores diferentes, interagindo quando necessário para providenciar serviços aprocessos clientes (vide fig. 8). Os servidores podem particionar um conjunto deobjectos, nos quais os serviços estão baseados e distribuí-los pelos diferentesservidores, ou eles podem manter cópias replicadas desses objectos em cada um dosservidores. Estas duas opções estão ilustradas nos seguintes exemplos.Fig. 8: Um serviço providenciado por múltiplos servidores Servidor Cliente Servidor Cliente ServidorA Web providencia um exemplo comum de particionamento de dados, em que cadaservidor Web gere cada um dos seus recursos. Um usuário pode utilizar o browserpara aceder recursos de qualquer um dos servidores.A replicação é usada para aumentar a desempenho, disponibilidade e minimizar atolerância a falhas. Por exemplo, o Web service providenciado no site é mapeado emvários servidores que têm as bases de dados replicadas. Um outros exemplo de umserviço baseado na replicação de dados é NIS (Network Information Service) da Sun,que é usado pelos computadores uma LAN quando os usuários fazem o log on. Cadaservidor NIS possui uma réplica própria dos username’s e passwords encriptadas. 11
  12. 12. 1.2.3 Servidores proxies e cachesCache área de armazenamento temporário onde se guarda objectos recentementeusados que estão mais perto que os próprios objectos. Quando um novo objecto érecebido num computador é adicionado ao cache, sobrepondo alguns objectos se fornecessário. Quando objecto é requisitado por um processo cliente, os serviços cacheverificam primeiro o cache e providenciam o objecto a partir daí, se uma cópiarecente desse objecto estiver disponível. Caso contrário, uma cópia recente do objectoé solicitada. Caches podem ser colocados com cada cliente ou podem ser localizadosnum servidor proxy que pode ser partilhado por diversos clientes.Caches são usados extensivamente na prática. Navegadores Web mantém um cachede página Web visitadas recentemente e outros recursos da Web no computadorcliente, usando uma requisição especial http para verificar se a página é recente noservidor cache original, antes de mostrá-la ao cliente.Servidores Web proxies (vide fig. 9) providencia um cache partilhado de recursosWeb para máquinas clientes num site ou para vários sites. O propósito de servidoresproxies é aumentar a disponibilidade e a desempenho do serviço diminuindo o tráfegona rede e carga de processamento nos servidores Web. Servidores proxy podemassumir outras funções, como por exemplo, serem usados para aceder remotamenteum servidor Web por meio de um firewall.Fig. 9: Servidor proxy 12
  13. 13. 1.2.4 Modelo P2P (Peer to Peer)Nesta arquitectura, todos processos desempenham funções semelhantes, interagindocooperativamente para realizar uma actividade distribuída ou computação semnenhuma distinção entre clientes e servidores. Neste modelo, o código dos processospeer mantém os recursos do nível aplicacional consistentes e os sincroniza, quandonecessário. A fig. 8 mostra três computadores com a configuração deste modelo; Emgeral n processos peer podem interagir uns com os outros e o padrão de comunicaçãodepende dos requisitos da aplicação. 13
  14. 14. Fig. 10: Uma aplicação distribuída baseada em processos peer Aplicação Aplicação Código de Código de coordenação coordenação Aplicação Código de coordenaçãoA eliminação de processos servidores reduz atrasos de comunicação entre osprocessos para aceder objectos locais.1.3 Variações do modelo Cliente ServidorDiversas variações neste modelo podem ser derivados da consideração dos seguintesfactores: • O uso de código móvel em agentes móveis; • Necessidades de usuário em uso de computadores de baixo custo com recursos de hardware limitados que são simples de gerir. • Os requisitos de adicionar e remover dispositivos móveis duma forma conveniente.1.3.1 Código MóvelApplets são bem conhecidos e largamente usados como exemplo de código móvel é ocaso de o utilizador de um navegador Web seleccionar um link para Applet cujocódigo esta num servidor Web; o código é descarregado para o navegador e éexecutado no mesmo, como é mostrado na fig. 9. A vantagem de executar o códigodescarregado localmente, é que pode boas respostas interactivas, pois não sofreatrasos nem variabilidade da largura de banda associado com as comunicações.Fig. 11: Applets Web a) Requisição do cliente resulta no download do código Applet Servidor Cliente Web Código Applet 14
  15. 15. b) Cliente interage com o Applet Servidor Cliente Applet WebAcedendo serviços significa executar código que pode invocar outras operações.Alguns serviços já estão estandardizados que podem ser acedidos com aplicações bemconhecidas – a Web é o exemplo mais comum, mas mesmo na Web existem algunssites usam funcionalidades não encontradas em navegadores Web, que requeremcódigo adicional. O código adicional pode, por exemplo, comunicar com o servidor.Considerando uma aplicação que requere que o usuários tenham informaçãoactualizada à medida que vão ocorrendo alterações no servidor. Isto não pode seralcançado com uma interacção normal com o servidor Web, que é sempre iniciadapelo cliente.1.3.2 Agentes MóveisUm agente móvel é um programa em execução (incluindo dados e código) que viajamde um computador para outro numa rede. Um agente móvel pode invocar recursoslocais em cada site que visita – por exemplo aceder bases de dados individuais.Comparando esta arquitectura com um cliente estático fazendo requisições remotas aalguns recursos, possivelmente transferindo grandes quantidades de dados, existe umaredução de custos e tempo na comunicação através da troca de requisições remotasem locais.Agentes móveis (como código móvel) são potenciais ameaças para os recursos docomputador que acedem. O ambiente que recebe um agente móvel deve decidir, querecursos locais são permitidos para o agente, baseados na identidade do usuário comquem o agente está interagindo – a identidade deve ser incluído duma forma seguracom o código e os dados do agente móvel. Adicionalmente, agentes móveis podemeles próprios ser vulneráveis – eles podem não completar a tarefa se forem recusadosa aceder a informação que eles precisam. Por exemplo, Web crawlers que precisamaceder recursos num servidor Web através da Internet que funcionam correctamente 15
  16. 16. fazendo requisições remotas a processos servidores. Por esta razão, a aplicação deagentes móveis pode ser limitada.1.3.3 Computadores em redeNuma arquitectura stand-alone as aplicações correm em computadores locais. Nestescasos, o sistema operativo e a aplicação requerem que o código e os dados sejamcolocados no disco local. Mas a manutenção dos dados e da aplicação local, requereum esforço técnico adicional.Os computadores em rede é a resposta para este problema. As aplicações são corridaslocalmente, mas ficheiros ou dados são geridos por um servidor remoto de ficheiros.Dado que todos dados da aplicação e o código estão guardados num servidor Web, osusuários podem migrar de um computador de rede para outro. Nestes casos oscomputadores da rede só precisam ter requisitos mínimos de hardware, podendoreduzir os custos. Se tiver um disco, este pode ser usado como memória cachearmazenando cópias de software e dados recentemente descarregados do servidor. Amanutenção da memória cache não requere nenhum esforço manual: objectos cachesão invalidados a qualquer momento que uma nova versão do ficheiro é escrita noservidor.1.3.4 Thin Clients (Clientes Leves)O termo Thin Client refere-se a uma camada de software que suporta interfaces dousuário baseado em janelas num computador local, para o utilizador executandoaplicações num computador remoto. Esta arquitectura possui também baixo custo degestão e de hardware, a semelhança de arquitectura de computadores em rede. Pois aoinvés de descarregar o código das aplicações no computador local, tudo ocorre nocomputador servidor. Que tem uma grande capacidade de executar uma quantidadesignificativa de aplicações simultaneamente. 16
  17. 17. A principal desvantagem de uma aplicação thin client é alta actividade de interacçãográfica, o que resulta em maior tempo de atraso no processamento da imagem. Porexemplo, VNC (Virtual network computer), Remote Desktop Connection (RDC), …1.3.5 Dispositivos móveis e rede espontâneaO mundo está gradualmente a ser povoado por pequenos dispositivos móveis eportáteis, incluindo laptops, dispositivos de mão, tais como PDAs (Personal DigitalAssistants), telemóveis, câmaras digitais, relógios smarts,… Muitos dessesdispositivos tem capacidades de serem integrados em redes sem fio.Com apropriada integração em sistemas distribuídos, estes dispositivos providenciamsuporte a computação móvel. Onde os utilizadores, utilizam seus dispositivos moveisem diferentes redes e tiram vantagens dos serviços locais e remotos. A forma dedistribuição que integra dispositivos móveis, e outros dispositivos em uma rede étalvez a melhor descrição de rede espontânea.Num hotel é um exemplo de uma rede espontânea em que os clientes podem terserviços de música, alarme e acesso a Internet.Os pontos chaves de uma rede espontânea são: • Facilidade de conexão a rede local – Redes sem fios não precisam de cabos pré-instalados e os dispositivos que estiverem na rede são configurados de uma forma transparente (transparência de configuração) para obter conexão sem precisar de descrever os nomes ou endereços dos serviços locais para poder acede-los. • Facilidade de integração com serviços locais – dispositivos colocados em (e se movendo entre) redes existentes, eles automaticamente acedem os serviços disponibilizados pela rede sem uma configuração especial por parte de utilizador. • Conexão limitada – os utilizadores nem sempre estão conectados enquanto eles se movem. Põe exemplo, eles podem ser desconectados de rede wireless, se estiverem a viajar de comboio num túnel. Eles podem também estar 17
  18. 18. desconectados por um longo período de tempo em regiões onde a rede wireless não cobre ou quando é caro para o utilizador se manter ligado. • Segurança e privacidade – muitos aspectos relacionados com segurança e privacidades devem ser tomados em conta em cenários semelhantes aos do hotel em que temos serviços de música, alarme e acesso a Internet. Os clientes do hotel são vulneráveis a ataques de outros clientes ou empregados do hotel que acedem serviços não supervisionados. Os clientes que, a partir do hotel, acedem a intranet das duas casas podem expor dados pessoais que são supostos estarem escondidos nos firewalls ou podem abrir portas de ataque a partir de fora.1.4 Modelo de interfaces e objectos (Orientado a objectos)O conjunto de funções disponível para invocação num processo (quer seja processoservidor ou peer) é especificado por uma ou mais definições de interfaces. Numaforma básica da arquitectura cliente servidor, cada processo servidor é visto comouma entidade com funções de interface bem definidas para serem invocadas.Fig. 12: Modelo de interfaces e objectos 18
  19. 19. Em linguagens orientadas a objectos tais como Java e C++, com suporte adicionalapropriado, processos distribuídos podem ser construídas em mais formas deorientação a objectos. Muitos objectos podem ser encapsulados num processoservidor ou peer e suas referências são passadas a outros objectos de forma quepossam ser acedidas pela invocação remota. Esta abordagem é adoptada por CORBA,Java, … com o seu mecanismo de invocação remota (RMI).2 Critérios para a escolha do Modelo • Desempenho o Tempo de resposta: carga do servidor e da rede, delay em atravessar camadas de software, volume de dados o Capacidade de processamento cliente, servidor, rede (throughput) o Balanceamento de carga (divisão de trabalho, eg. applets, DNS, etc) • Qualidade de serviço • Uso de cache e replicação • Dependabilidade: garantia (confiança) que um sistema oferece no provimento de um serviço ou tarefa o Correcção, confiabilidade e segurança • Aspectos: o Tolerância a falhas Uso de múltiplos componentes (replicação) para permitir a disponibilidade o serviço o Segurança Localizar (pôr) dados e recursos sensíveis em locais que ofereçam os níveis adequados de segurança e de controle o Disponibilizar recursos de forma parcial (baseado na autorização do usuário) 19
  20. 20. 3 Modelo fundamentalTodos modelos, acima descritos, compartilham algumas propriedades fundamentais.Em particular, todos são compostos por processos que se comunicam porenvio/recebimento de mensagens numa rede de computadores.Todos modelos compartilham os aspectos gerais de um projecto de sistemasdistribuído (que devem ser considerados) vistos nas aulas anteriores, concernentes aodesempenho, confiabilidade, redes e segurança de recursos no sistema. Neste pontosão apresentados modelos baseados nas características fundamentais que nospermitem ser mais específicos acerca das suas características, falhas e riscos desegurança que são sujeitos.Deste modo, o modelo de sistema deve responder as seguintes questões: • Quais as principais entidades no sistema? • Como essas entidades interagem • Quais as características que afecta o comportamento individual e colectivamenteObjectivo de um modelo é: • Tornar explícitas todas suposições relevantes sobre o sistema em modelação. • Permitir generalizações sobre o que é possível ou impossível de ser realizado dadas as suposições. As generalizações podem se tornar sob forma de objectivo principal de algoritmos ou propriedades desejáveis que sejam garantidas. A garantia depende da análise lógica, quando apropriado, prova matemática.Isto é suficiente para se ganhar pelo conhecimento do que o sistema faz ou não.Permitindo saber se o modelo de sistema em desenvolvimento funcionará ou não, deforma a decidir sobre o seu desenvolvimento. 20
  21. 21. Os aspectos de sistemas distribuídos que se deseja compreender em modelosfundamentais são: interacção, falhas e segurança.Interacção – computação ocorre em processos. Processos se comunicam em troca demensagens, resultando em comunicação e coordenação (sincronização e ordenação deactividades) entre processos. Na análise e desenho de sistemas distribuídos concentra-se especialmente nestas interacções.O modelo de interacção deve reflectir que comunicação ocorre com atraso,frequentemente considerado duração, e a exactidão com que processos independentespodem ser coordenados e limitados por estes atrasos e pela dificuldade de manter amesma noção de tempo em todos computadores num sistema distribuído.Falhas – O funcionamento correcto do sistema distribuído é ameaçado a qualquermomento que ocorre uma falha em qualquer um dos computadores onde estiver a serexecutado (incluindo falhas de software) ou na rede que os conecta. O modelo defalha define e classifica as falhas. Este modelo providência as bases para análise dosseus potenciais efeitos e para o desenho de sistemas que são capazes de tolerar cadatipo de falha enquanto continuam a funcionar correctamente.Segurança – a natureza modular de um sistema distribuído e a sua abertura o expõe aataques, por ambos agentes: internos e externos. O modelo de segurança define eclarifica como esse ataques podem acontecer, providenciando as bases essenciais paraanálise das ameaças aos sistemas e para o desenho de sistemas que são capazes deresistir a esses ataques.3.1 Modelo de interacçãoSistemas distribuídos são compostos por muitos processos, interagindo de uma formacomplexa. Por exemplo. • Processos de servidores múltiplos podem cooperar uns com os outros para providenciar serviços. Por exemplo, Domain Name Service que particiona e replica seus dados em diferentes servidores na Internet; Network Information 21
  22. 22. Service da Sun que mantém cópias de passwords em vários servidores na rede local. • Um conjunto de processos peer podem cooperar uns com os outros para atingir um objectivo comum. Por exemplo, o Sistema de vídeo-conferência que distribui fluxos de dados áudio e imagem de forma similar, mas com severos constrangimentos em tempo real.Muitos programadores estão familiarizados com o conceito de algoritmo – sequênciade passos a serem realizados para o alcance de um propósito ou resolução de umproblema. Programas simples são controlados por um algoritmo, cujos passos sãorigorosamente sequenciais. O comportamento do programa e o estado das suasvariáveis é determinado pelo algoritmo. O tal programa é executado como umprocesso simples. Os sistemas distribuídos são compostos por processos múltiplos taiscomo os exemplificados no primeiro parágrafo deste ponto. O comportamento e oestado são descritos por algoritmos distribuídos – uma definição dos passos quedevem ser realizados por cada um dos processos que compõem o sistema, incluindo atransmissão de mensagens entre eles. As mensagens são transmitidas entre processospara transferir informação entre eles e para coordenar as suas actividades.A velocidade com que cada processo procede e o tempo de transmissão de mensagensentre eles, em geral, não pode ser previsto. É também difícil descrever todos osestados de um algoritmo distribuído, porque ele deve lidar com falhas de um ou maisprocessos envolvidos ou a falha de transmissão de mensagens.A interacção entre processos permite a realização de todas actividades de um sistemadistribuído. Cada processo tem o seu estado, consistindo dos dados que ele podeaceder e actualizar, incluindo as variáveis do seu programa. O estado pertencente acada processo é completamente privado, isto é, não pode ser acedido e actualizado porqualquer um dos outros processos.A seguir são apresentados dois factores significantes que afectam a interacção deprocesso em sistemas distribuídos: 22
  23. 23. • O desempenho do canal de comunicação é frequentemente uma característica limitante; • É impossível manter uma simples noção global do tempo.3.1.1 Desempenho do Canal de ComunicaçãoO desempenho do canal de comunicação é realizado de várias formas num sistemadistribuído, por exemplo, a implementação de streams ou por uma simples passagemde uma mensagem numa rede. A comunicação numa rede tem as seguintescaracterísticas de desempenho relacionadas com latência, largura de banda e Jitter.O atraso entre o inicio da transmissão de uma mensagem a partir de um processo e oinício da recepção por um outro processo é referido como latência. A latência inclui: • O tempo levado pelo primeiro string de bits transmitidos pela rede para atingir o destinatário. Por exemplo, a latência para a transmissão de uma mensagem através de uma ligação satélite é o tempo para um sinal de rádio viajar para o satélite e de volta. • O atraso no acesso da rede, que aumenta significativamente quando a rede está sobrecarregada. Por exemplo, numa transmissão Ethernet a estação emissora espera para que o tráfego na rede fique aliviado. • O tempo levado pelos serviços de comunicação do sistema operativo em ambos processos e envio recepção, que varia de acordo com a carga corrente do sistema operativo.A largura de banda de uma rede de computadores é a quantidade total de informaçãoque pode ser transmitida num dado instante de tempo. Quando um grande número decanais de comunicação está usando a mesma rede, eles tem de partilhar a mesmalargura de banda.Jitter é a variação no tempo levado para entregar uma série de mensagens. Jitter érelevante para mensagens multimédia. Por exemplo, se consecutivos segmentos dedados áudio forem tocados com diferentes intervalos, o som será distorcido. 23
  24. 24. 3.1.2 Relógio do computador e tempos de eventosCada computador num sistema distribuído tem o seu relógio interno, que pode serusado pelo processo local para obter o tempo corrente. Deste modo, dois processos aserem executados em computadores diferentes podem associar nos seus eventos umselo do tempo. Contudo, mesmo se dois processos lerem os seus relógios ao mesmotempo, os seus relógios locais pode indicar valores (horas) diferentes. Isto porque orelógio do computador oscila na hora certa, ainda o mais importante é que essaoscilação média difere de um computador a outro.Há varias abordagens para correcção do tempo em processos do computador. Porexemplo, computadores podem usar receptores de rádios para obter hora a partir doGPS com precisão por volta de 1 micro segundo. Mas o receptor GPS não funcionanuma área coberta, assim como os custo podem não se justificarem para todoscomputadores. Apesar disso, um computador que tenha uma fonte de tempo tal comoGPS pode enviar mensagens de tempo para outros computadores na rede. O resultadoacordado entre relógios locais é afectado por variação de atraso de mensagens.3.1.3 Variações do modelo de interacçãoEm sistemas distribuídos é difícil estabelecer limites no tempo usado para execuçãodo processo, entrega de mensagens ou oscilação do relógio. Dois pontos extremosprovidenciam um par do modelo simples: o primeiro tem maior aproximação detempo e o segundo não faz nenhuma aproximação sobre o tempo.3.1.3.1 Sistemas distribuídos síncronosSegundo Hadzilacos Tueng [1994], um sistema distribuído síncrono aquele em que osseguintes intervalos estão definidos: • O tempo para executar cada estágio do processo que se conheça o intervalo (mínimo e máximo) • Cada mensagem transmitida no canal é recebida dentro do seu tempo mais longo (limite superior do intervalo) • Cada processo tem sua hora local, que é a variação média, da hora certa do limite máximo conhecido. 24
  25. 25. É possível sugerir o limite superior e inferior da oscilação do tempo de execução,atraso de mensagens e oscilações de relógio em sistemas distribuídos. Mas é difícilchagar a valores concretos e providenciar garantias nos valores escolhidos. A não serque os valores dos intervalos estejam possam ser garantidos, todo d desenho baseadonos valores escolhidos não será confiável. De qualquer modo, modelar um algoritmocomo um sistema assíncrono pode ser útil para dar umas ideias de como vai secomportar num verdadeiro sistema distribuído.Em sistemas síncronos é possível usar timeout por exemplo para detectar a falha deum processo.Sistemas distribuídos síncronos podem ser construídos. O que é necessário é que osprocessos realizem executam actividades com recursos conhecidos, para os quaispodem ser garantidos uma velocidade do processador suficiente e capacidade de rede.3.1.3.2 Sistemas distribuídos assíncronosMuitos sistemas distribuídos, por exemplo a Internet, são muito importantes semserem classificados como sistemas síncronos. Por isso a necessidade de um modeloalternativo: o sistema distribuído assíncrono em que não há limite: • Velocidade de execução dos processos – por exemplo, a execução de um processo numa determinada fase pode demorar um pico segundo e um outro demorar um século. Isto é, cada fase de execução pode demorar um longo período de tempo aleatório. • Atraso na transmissão da mensagem – por exemplo, uma mensagem enviada do processo A para o processo B pode demorar zero segundos, e outro pode demorar vários anos. Em outras palavras, uma mensagem pode ser recebida após um longo período aleatório de tempo. • Oscilação do relógio – mais uma vez a oscilação do relógio é aleatória.Os modelos assíncronos não permitem suposições (aproximações) de intervalos detempo envolvido numa execução. Isto modela exactamente a Internet, no qual não háintrínseco limite no servidor ou na carga da rede. E desta forma, no tempo que esta 25
  26. 26. demora. Por exemplo, para transferir um ficheiro usando FTP. Às vezes umamensagem de e-mail pode demorar dias para chegar ao destino.A tabela nº 1 mostra dificuldades para alcançar um acordo em sistemas distribuídosassíncronos.Mas alguns problemas de desenho podem ser resolvidos mesmo com estas suposições.Por exemplo, embora a Web nem sempre pode providenciar uma determinadaresposta num certo intervalo de tempo, os navegadores (browsers) foram desenhadospara permitir aos usuários fazerem outras tarefas enquanto esperam pela resposta.Qualquer solução válida para um sistema distribuído assíncrono também é válida parao síncrono.Actualmente, os sistemas distribuídos, por causa da necessidade dos processoscompartilharem processadores e canais de comunicação compartilharem a rede. Porexemplo, vários processos que não são conhecidos as suas característicascompartilharem o processador, então o desempenho que ai resultar de qualquer delesnão pode se garantido. Mas há vários problemas de desempenho que não podem serresolvidos se for usado algum aspecto de tempo. A necessidade de cada elemento dedados multimédia que passam sucessivamente para serem entregues antes do términodo tempo, é o referido problema. Para este tipo de problema, é necessário usarmodelos síncronos. A tabela nº 1 mostra a impossibilidade de sincronização derelógios em sistemas assíncronos.3.1.4 Ordenação de EventosEm muitas casos nos interessa saber quando um evento (envio ou recepção de umamensagem) de um processo ocorreu antes, depois ou dum forma concorrente com umoutro evento de um outro processo. A execução de eventos pode ser descrita emtermos de eventos e sua ordenação, apesar de falta de precisão de relógios.Por exemplo: considere a seguintes troca de mensagens do grupo de usuários de e-mail e utilizadores X, Y e Z na lista de e-mail’s. 1. Utilizador X envia uma mensagem com tema: Meeting; 26
  27. 27. 2. Usuários Y e Z respondem, enviando uma mensagem com tema Re: Meeting ;Em tempo real, mensagem de X foi enviada primeiro. Y lê-a e responde; Z lê ambasmensagens do X e Y e as responde com referência a ambas. Mas pela independênciado tempo de atraso na entrega da mensagem, a mensagem pode ser entregues como émostrado na fig. 13, e alguns utilizadores, poderão ver estas duas mensagem na ordemerrada, como por exemplo, o usuário A deverá ver:Tabela 1: Sistema Assíncrono Inbox:Item De Tema23 Z Re: Meeting24 X Meeting25 Z Re: MeetingFig. 13: Ordenação de eventos em tempo realX E (m1) R (m2) R (m3) R (m1) E (m2)Y R (m1) R (m2) E (m3)Z R (m3) R (m1) R (m2)A T1 T2 T3 Legenda: • E – Envia • R – Recebe • M – Mensagem • T - Tempo3.2 Modelo de falhasNum sistema tanto os processos (e computador) como os canais de comunicaçãopodem falhar pois, não é possível conceber componentes sem falhas, apenas se podediminuir a probabilidade de as mesmas ocorrerem 27
  28. 28. O modelo de falha consiste na definição dos mecanismos no qual as falhas podemocorrer, de modo a se compreender o efeito dessas falhas. O modelo de falhas abrangeainda a indicação rigorosa do comportamento global do sistema na presença dosdiferentes tipos de falhas.3.2.1 Definições Básicas3.2.1.1 Fault tolerance - tolerância a falhasPropriedade de um sistema distribuído que lhe permite recuperar da existência defalhas sem introduzir comportamentos incorrectos. Um sistema deste tipo podemascarar as falhas e continuar a operar, ou parar e voltar a operar mais tarde, de formacoerente, após reparação da falha.3.2.1.2 Availability – disponibilidade.Mede a fracção de tempo em que um serviço está a operar correctamente, isto é, deacordo com a sua especificação. Para um sistema ser altamente disponível (highlyavailable) deve combinar um reduzido número de falhas com um curto período derecuperação das falhas (durante o qual não está disponível).3.2.1.3 Reliability - fiabilidadeMede o tempo desde um instante inicial até à primeira falha, i.e., o tempo que umsistema funciona correctamente sem falhas. Um sistema que falha com grandefrequência e recupere rapidamente tem baixa fiabilidade, mas alta disponibilidade.3.2.1.4 Timeliness- adequação temporal ou pontualidadeEm sistemas de tempo real é a garantia de que o sistema é capaz de obedecer aconstrangimentos temporais, isto é, a capacidade que o sistema tem de garantir limitespara o tempo que as diferentes acções levam a executar.3.2.2 Tipos de falhasHadzilaco e Teang [1994], apresentou uma classificação em que distingue entre asfalhas de processos e as do canal de comunicação. 28
  29. 29. 3.2.2.1 Falhas por omissão e arbitráriasFalhas por omissão - dá-se quando um processo ou um canal de comunicação falha aexecução de uma acção que devia executar. Por exemplo uma mensagem que deviachegar não chegou, processo falha (crash – quer dizer que interrompeu a execução eas fases subsequentes não serão realizados).Falha arbitrária ou bizantina - dá-se quando se produziu algo não previsto.Exemplo: chegou uma mensagem corrompida, um atacante produziu uma mensagemnão esperada.Tipo Afecta Descrição O processo pára e fica parado. Os outros processos não conseguem detectar este facto (a menos que se assumaCrash, fail stop Processo sistema síncrono) Uma mensagem colocada no buffer de outgoing de um canal nunca Omissão Canal chega à outra extremidade Um processo ou um canal têm comportamentos arbitrários: enviar ou Arbitrária Processo transmitir mensagens em momentos arbitrários, parar ou exibir (Bizantina) /Canal comportamentos erradosTabela 2: Falhas por Omissão 29
  30. 30. 3.2.2.2 Mascarar falhas de componentesPara compensar os problemas levantados pelas falhas usam-se técnicas para asmascarar. Desta forma é possível confinar os seus efeitos sobre o sistema.As falhas de omissão podem ser mascaradas por replicação ou repetição.Exemplo: se uma mensagem não chegou dentro de um certo período – o que sedetecta por um timeout – então pode-se emiti-la novamente. Outra hipótese é duplicaro canal, enviar mais do que uma cópia em paralelo e filtrar as mensagens duplicadas.As falhas arbitrárias podem ser difíceis de mascarar. Pode-se tentar transformá-lasem falhas por omissão.Exemplo: um CRC numa mensagem permite transformar uma falha bizantinado canal numa falha por omissão.O mesmo tipo de técnicas usam-se em muitas vezes nos componentes hardware dotipo3.2.3 Falhas temporaisUma falha temporal dá-se quando um evento que se devia produzir num determinadoperíodo de tempo ocorreu mais tarde. • As falhas temporais são difíceis ou impossíveis de mascarar. • Normalmente apenas os sistemas de tempo real se preocupam com este tipo de falha.Classe de Afecta Descriçãofalha O relógio do processo tem um desvio superior ao permitido em relaçãoRelógio Processo ao tempo real O processo leva mais tempo do que o estipulado a executar umaDesempenho Processo operaçãoDesempenho Canal A mensagem levou mais tempo do que o previsto 30
  31. 31. Nota: As falhas por omissão e as falhas temporais dizem-se falhas benignas pois sãomais facilmente mascaráveis e não corrompem tão facilmente os outros componentes.3.3 Modelo de segurançaNas primeiras aulas foi apontada a partilha de recursos como um dos factoresmotivadores para Sistemas Distribuídos e foi descrita posteriormente a arquitecturados seus sistemas em termos de processos encapsulando objectos e providenciadoacesos a eles através de interacções com outros processo.O modelo arquitectural providencia as bases para o modelo de segurança: a segurançaem sistemas distribuídos pode ser alcançada assegurando os processos e os canaisusados para a sua interacção e protegendo os objectos que eles encapsulam contraacesos não autorizados.A protecção é descrita em temos de objectos, embora os conceitos se apliquemigualmente a recursos de todos os tipos.3.3.1 Protegendo objectosA figura a seguir mostra um servidor que possui uma colecção de objectos que podemser invocados por usuários. Estes usuários podem executar programas clientes queenviam requisições ao servidor para realizar operações nos objectos. O servidorexecuta a operação especificada em cada requisição e envia a resposta ao cliente.Fig. 14: Principal e objectos Privilégios de acesso Objecto Invocação Cliente Servidor Resposta Principal Rede Principal (Usuário) (Servidor) 31
  32. 32. Os objectos podem ser usados em diferentes formas por diferentes usuários. Porexemplo, alguns objectos podem conter dados privados do utilizador, como passworde outros objectos podem conter dados partilhados tais como páginas Web. Parasuportar isto, os privilégios de acesso especificam quem é permitido para realizaroperações num objecto, por exemplo, quem é permitido para ler e alterar o estado doobjecto.É por isso que se inclui os usuários neste modelo como os beneficiários dosprivilégios de acesso. Isso é feito associando cada requisição e cada resultado àrespectiva autoridade. A referida autoridade é chamada principal. Um principal podeser um usuário ou um processo. O servidor é responsável por verificar a identidadedos principais em cada requisição e verificar se eles detém privilégios suficientes pararealizar a operação pretendida num determinado objecto, recusando se não os tiver. Ocliente pode verificar a identidade do principal do processo servidor para garantir queo resultado provém de um servidor válido.3.3.2 Protegendo processos e suas interacçõesOs processos interagem pelo envio de mensagens. As mensagens são expostas aataque porque o serviço da rede e comunicação que os processos usam estão abertos,para habilitar qualquer par de processos a interagirem. Os processos servidores e peerexpõem seus interfaces, permitindo que invocações sejam enviadas aos respectivosprocessos por quaisquer outros processos.Os sistemas distribuídos são frequentemente implementados e usados em tarefas sãosujeitos a ataques externos por usuários hostis. Isto é especialmente verdadeiro paraaplicações que lidam com transacções bancárias, informação classificada ouconfidencial ou outra informação cuja integridade é crucial. A integridade é ameaçadaa violações de segurança a processos assim como a falhas de comunicações. 32
  33. 33. 3.3.3 O inimigoPara modelar ameaças de segurança, o inimigo (também conhecido como adversário)é identificado como sendo capaz de enviar qualquer mensagem para qualquerprocesso e ler e copiar qualquer mensagem entre um par de processos, como estáilustrado na figura abaixo.Fig. 15; O inimigo Cópia de m O inimigo m’ Processo P Processo Q mEste tipo de ataque pode ser feito usando um computador ligado a rede no qual sepode executar um programa que lê o conteúdo das mensagens da rede que sãoenviados a outros computadores da rede ou um programa que gera mensagens paraemitir requisições falsas a serviços dando a entender que provém de usuáriosautorizados. O ataque pode advir de um computador reconhecido da rede ou docomputador da rede não autorizado. As ameaças de um potencial inimigo estãodescritas nos pontos abaixo que abordam ameaças a processos, ameaças a canais decomunicação e negação de serviço.3.3.3.1 Ameaças a processosUm processo que é desenhado para lidar com requisições pode receber mensagens dequalquer processo num sistema distribuído, e não pode necessariamente determinar aidentidade do emissor. Os protocolos de comunicação tais como Internet Protocol (IP)que incluem o endereço do computador emissor em cada mensagem, mas não é difícilpara um inimigo gerar uma mensagem com um endereço fictício. A falta de confiança 33
  34. 34. no emissor da mensagem é uma ameaça ao correcto funcionamento a ambosservidores e clientes, como é descrito abaixo: • Servidores: dado que o servidor pode receber requisições de quaisquer clientes, ele não pode determinar a identidade do principal que está associado a uma invocação. Mesmo que o servidor requeira a identidade do principal em cada invocação, um inimigo pode gerar uma invocação com uma falsa identidade. Sem a confiança da identidade do emissor, um servidor não pode determinar se uma operação pode ser aceite ou rejeitada. Por exemplo, um servidor de e-mail não poderia saber se um usuário associado a uma invocação que requisita um e-mail de uma determinada caixa de entrada é permitido a fezê-lo ou foi uma requisição de um inimigo. • Clientes: quando um cliente recebe uma resposta de uma invocação a um servidor, não pode determinar se o resultado provém de um servidor válido ou de um inimigo, talvez ‘spoofing’ o servidor de e-mail. Deste modo o cliente pode receber um resultado de um servidor não relacionado com a invocação, como, por exemplo, uma caixa de entrada falsa ( que não pertence ao dono da caixa de entrada)3.3.3.2 Ameaças a canais de comunicaçãoUm inimigo pode copiar, alterar ou injectar mensagens na rede. Tais ataquesrepresentam ameaças a privacidade e integridade da informação e do sistema àmedida que circulam pela rede. Por exemplo, um resultado contendo o e-mail dousuário pode ser revelado a um outro usuário ou pode ser alterado para mostrar algodiferente.A outra forma de ataque é a tentativa de gravar mensagens e tentar reenviá-las numoutro momento, fazendo com que seja possível reenviar a mesma mensagem váriasvezes. Por exemplo, alguém pode-se beneficiar da tentativa de reenviar umamensagem de invocação solicitando a transferência de dinheiro de uma conta bancáriaa outra. 34
  35. 35. Todos esses ataques podem ser evitados usando canais seguros de comunicação, quesão descritos abaixo como e baseados em criptografia e autenticação.3.3.4 Defendendo-se das ameaças de segurançaCriptografia e segredos partilhados: suponhamos um par de processos (porexemplo um cliente e um servidor concreto) partilham um segredo, ou seja, só eles, osdois, conhecem o segredo e não mais outro processo no sistema distribuído. Então sea mensagem trocada pelo par de processos inclui informação que prova a identidadedo emissor, o receptor sabe com certeza, que emissor foi o outro processo par.Evidentemente, o cuidado deve ser tomado para que o segredo não seja revelado aoinimigo.Criptografia é ciência que mantém as mensagens seguras, e a encriptação é oprocesso de transformar uma mensagem num conteúdo ilegível. A criptografiamoderna é baseada em algoritmos de encriptação que usam chaves secretas – grandesnúmeros que são difíceis de adivinhar – que transformam dados numa forma que nãopode ser somente reservada ao conhecimento da chave de decriptação.Autenticação – o uso de segredos partilhados e encriptação p providenciam as basespara a autenticação de mensagens – providenciando identidades apresentados pelosemissores. A técnica básica de autenticação é incluir na mensagem um porçãoencriptada que contém elementos suficientes na mensagem que garantemautenticidade. A porção de autenticação de uma requisição a um servidor de ficheirospara a leitura de uma parte de um ficheiro, por exemplo, pode incluir a representaçãoda identidade do principal da requisição, a identidade do ficheiro e a data horas darequisição, todos encriptados com uma chave secreta partilhada entre o servidor deficheiros e o processo requisitante. O servidor poderia decriptar e verificar se osdetalhes não encriptados correspondem aos detalhes especificados na requisição.Canais seguros: A encriptação e autenticação são usadas para construir canaisseguros como camadas de serviço no topo dos serviços de comunicação existentes. 35
  36. 36. Um canal seguro é um canal de comunicação conectando um par de processos, cadaum deles actua em nome do principal, como mostrado na fig. abaixo.Fig. 16: Canal seguro Principal A Principal B Processo P Canal seguro Processo QUm canal seguro tem as seguintes propriedades: • Cada processo reconhece a confiabilidade da identidade do principal em nome do qual o processo é executado. Por isso, se as comunicação de um cliente e um servidor via canal seguro, o servidor conhece a identidade do principal que está o invocando e pode verificar os privilégios antes de responder a qualquer solicitação. Isto permite que os servidores protejam seus objectos correctamente e permite ao cliente de ter a certeza que está recebendo resultados de um servidor autêntico. • Um canal seguro assegura que a privacidade e a integridade (protecção contra interferências) dos dados transmitidos no mesmo • Cada mensagem detém o selo (stamp) do tempo físico e lógico para que a mensagem seja reenviada ou reordenada.Os canais seguros tornaram-se uma importante ferramenta para proteger comércioelectrónico e da comunicação, os exemplos disso são as VPN’s – Virtual PrivateNetwork, o protocolo Secure Sockets Layer (SSL).3.3.5 Outras possibilidades de ameaça de um inimigoA negação de um serviço (denial of service) e o código móvel são as possibilidadesoportunas para um inimigo poder interromper as actividades de processo: 36
  37. 37. 3.3.5.1 Denial of ServiceEsta é uma forma de ataque em que o inimigo interfere com as actividades de usuáriosautorizados, fazendo invocações excessivas a serviços ou transmissão de mensagensna rede, resultando na sobrecarga dos recursos físicos (largura de banda, capacidadedo processamento do servidor). Tais ataques são frequentemente realizados com aintenção de atrasar ou impedir acções de outros usuários. Por exemplo, a operação detrancar electronicamente uma porta num edifício pode ser desabilitada por um ataqueque sature o controlo electrónico com requisições inválidas.3.3.5.2 Código móvelO código móvel levanta um interessante problema de segurança para qualquerprocesso que executa um código de programa vindo de outro lugar, por exemplo umanexo de e-mail. Tal código pode ter um papel de um cavalo de Tróia, dando aentender que tem propósitos inocentes aos processos, mas que não seja o originário docódigo. Os métodos em que os ataques podem ser feitos são vários, o ambiente desistema distribuído deve ser construído cuidadosamente de forma a evitar essesataques. Muitas dessas questões forma endereçadas pelo Java e outros sistemas decódigo móvel, mas a história recente mostra algumas fraquezas. Isto mostra anecessidade de uma análise e desenho rigoroso de todo sistema de segurança.3.3.6 O uso dos modelos de segurançaO alcance da segurança em sistemas distribuídos pode ser reforçado com oenvolvimento do controlo de acesso a objectos com privilégios pré definidos e o usode canais seguros para comunicação. Infelizmente, este não é em geral ocaso. O usode técnicas de segurança tais como a encriptação e controlos de acesso incorre emcustos substanciais de gestão e processamento. O modelo de segurança descrito acimaprovidencia as bases para análise e desenho de sistemas seguros nos quais estes custospodem ser minimizados, mas as ameaças a sistemas distribuídos levantam-se emmuitos pontos e uma análise cuidadosa dever ser realizada em todas as fontespossíveis no ambiente do sistema, físico e humano. O modelo envolve a construção 37
  38. 38. do modelo de ameaça, listando todas as formas de ataque para os quais o sistema estáexposto e avaliação dos riscos e das consequências de cada uma. A eficiência e oscustos das técnicas de segurança necessárias podem ser balanceados contra asameaças.4 Bibliografia • Tanebaum, André S.; Steen, Marten van. Distributed Systems: principles and paradigms, 2002 • Coulouris, George et. Al. Distributed Systems: concepts and design 3rd edition, 2001 • Marques, José Alves; Gudes, Paulo. Tecnologia de Sistemas Distribuídos 2ª edição, FCA, 1998 • Boger, Marko. Java in Distributed Sytems: concurrency, distribution and persistance; 2001 38

×