38
1 Sumário 1 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) .............................. 18 2 Critérios para a escolha do Modelo ..................................................................... 19 3 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 ......................................................... 37 4 Bibliografia .......................................................................................................... 38

Arquitectura e modelos de sistemas distribuidos

Embed Size (px)

Citation preview

Page 1: Arquitectura e modelos de sistemas distribuidos

1

Sumário 1 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) ..............................18 2 Critérios para a escolha do Modelo .....................................................................19 3 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 .........................................................37 4 Bibliografia ..........................................................................................................38

Page 2: Arquitectura e modelos de sistemas distribuidos

3

Modelos de Estruturação de Sistemas Distribuídos

Os modelos servem para compreender o funcionamento de um sistema no que

concerne:

• 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 Arquitectural

Ilustra a estruturação dos diferentes componentes e suas interacções.

1.1 Modelo de camada

Estruturação do software em diferentes níveis:

• Plataforma; e

• Middleware.

Fig. 1: Camadas de serviços de software e hardware num SD

1.1.1 Plataforma

Os níveis mais baixo de camadas de software e hardware, são frequentemente

referenciados como sendo a plataforma para sistemas e aplicações distribuídas. Estas

camadas (níveis) mais baixas disponibilizam serviços para as camadas acima delas,

que são implementados independentemente em cada computador, trazendo o interface

Page 3: Arquitectura e modelos de sistemas distribuidos

2

Índice de Figuras Fig. 1: Camadas de serviços de software e hardware num SD ......................................3 Fig. 2: Máquinas, Sistemas de Rede e Sistemas Operacionais de diversos fabricantes 4 Fig. 3: Rede formada por diversas plataformas .............................................................5 Fig. 4: Desafio de integração de ambientes heterogéneos .............................................5 Fig. 5: Midleware como solução para integração de ambientes heterogéneos ..............6 Fig. 6: Clientes invocam servidor individual.................................................................9 Fig. 7: Web crawler .....................................................................................................10 Fig. 8: Um serviço providenciado por múltiplos servidores........................................11 Fig. 9: Servidor proxy ..................................................................................................12 Fig. 10: Uma aplicação distribuída baseada em processos peer ..................................14 Fig. 11: Applets Web....................................................................................................14

Page 4: Arquitectura e modelos de sistemas distribuidos

4

de programação para um nível que facilita a coordenação e comunicação entre

processos. Intel x86/Windows; SPARC/SunOS, intel X86/Solarris, Intel x86/Linux

são principais exemplos.

1.1.2 Middleware

Problemas:

Como integrar e distribuir os sistemas?

Como construir um ambiente para solucionar este novo paradigma com a existência

de:

• 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 middleware

Uma das Motivações do surgimento do Midleware é o ambiente de computação actual

em que Máquinas, Sistemas de Rede e Sistemas Operacionais são de diversos

fabricantes, conforme ilustra a fig. 2.

Fig. 2: Máquinas, Sistemas de Rede e Sistemas Operacionais de diversos fabricantes

Page 5: Arquitectura e modelos de sistemas distribuidos

5

Então surge uma questão: como ultrapassar estas limitações, visualizadas na fig. 3.

Fig. 3: Rede formada por diversas plataformas

Fig. 4: Desafio de integração de ambientes heterogéneos

Os constrangimentos, colocados nas figuras 2 a 4, podem ser resolvidas com a integração usando Midleware.

Page 6: Arquitectura e modelos de sistemas distribuidos

6

Fig. 5: Midleware como solução para integração de ambientes heterogéneos

Segundo (Rymer 1996), Middleware é um software que permite elementos de

aplicações inter operarem através de redes, apesar das diferenças nos protocolos de

comunicação, arquitecturas de sistemas, sistemas operacionais, bases de dados e

outros serviços de aplicação.

É simplesmente um software de conectividade que consiste de um conjunto de

serviç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 obter

dados de um lugar (..) para outro lugar (..). Segundo, ele deve mascarar as diferenças

existentes entre: sistema operativo; plataformas de hardware e protocolos de rede.

Terceiro, ele deve ocultar a complexidade do processo de transporte da rede, do

desenvolvedor da aplicação. (Salamone 1996)

Para cada uma das camadas (apresentação, aplicação e de dados), definiu-se um

middleware correspondente. Um exemplo de:

Page 7: Arquitectura e modelos de sistemas distribuidos

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

Page 8: Arquitectura e modelos de sistemas distribuidos

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.

Page 9: Arquitectura e modelos de sistemas distribuidos

9

1.2 Modelo de arquitectura de Sistemas

A divisão de responsabilidades entre componentes do sistema (aplicações, servidores

e 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 de

responsabilidades tem maiores implicações para a desempenho, confiabilidade e

seguranç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 interagem

entre eles, para realizar uma actividade. Os principais tipos de modelos de

arquitectura são mostrados da fig. 6 a fig. 9.

1.2.1 Modelo Cliente Servidor Esta arquitectura é a frequentemente mais citada quando se aborda sistemas

distribuídos. É historicamente a mais importante e continua a mais largamente

aplicada. A fig. 6 ilustra uma simples arquitectura, na qual processos clientes

interagem com os processos de servidores independentes em máquinas separadas, de

forma a aceder o canal partilhado por eles.

Fig. 6: Clientes invocam servidor individual

Page 10: Arquitectura e modelos de sistemas distribuidos

10

Em algum momento os servidores podem ser clientes de outros servidores, como

ilustra a fig. 6. Por exemplo, um servidor Web é frequentemente um cliente para um

servidor 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ços

de rede. Outro exemplo, também relacionado com a Web, são os motores de busca

que 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), que

correm por detrás do site do motor de busca usando requisições http2 para aceder

servidores Web através da Internet.

Fig. 7: Web crawler

Um motor de busca é ao mesmo tempo um servidor e um cliente: ele responde a

solicitações de navegadores cliente e ele executa Web crawlers que age como cliente

para outros servidores Web. Neste exemplo, as tarefas do servidor (respondendo as

requisições dos usuários) e as tarefas do crawler (fazendo requisições a outros

servidores Web são totalmente independentes); existe uma pequena necessidade de

sincronizá-los e eles podem correr de forma concorrente. De facto, um motor de busca

típico incluiria muitas threads de execução concorrentes, alguns servindo seus clientes

e outros executando Web crawlers .

1 De acordo com Crovella, Lindemann e Reiser (2000), os sistemas de busca na Internet cresceram consideravelmente nos últimos anos. Esses sistemas operam geralmente através de agentes. A maior parte destes mecanismos de procura e indexação de informações são chamadas de Web crawlers. 2 Hyper Text Transfer Protocol

Page 11: Arquitectura e modelos de sistemas distribuidos

11

1.2.2 Serviços Providenciados por Múltiplos Servidores

Serviços podem ser implementados como múltiplos processos de servidores em

computadores diferentes, interagindo quando necessário para providenciar serviços a

processos clientes (vide fig. 8). Os servidores podem particionar um conjunto de

objectos, nos quais os serviços estão baseados e distribuí-los pelos diferentes

servidores, ou eles podem manter cópias replicadas desses objectos em cada um dos

servidores. Estas duas opções estão ilustradas nos seguintes exemplos.

Fig. 8: Um serviço providenciado por múltiplos servidores

A Web providencia um exemplo comum de particionamento de dados, em que cada

servidor Web gere cada um dos seus recursos. Um usuário pode utilizar o browser

para aceder recursos de qualquer um dos servidores.

A replicação é usada para aumentar a desempenho, disponibilidade e minimizar a

tolerância a falhas. Por exemplo, o Web service providenciado no site é mapeado em

vários servidores que têm as bases de dados replicadas. Um outros exemplo de um

serviç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. Cada

servidor NIS possui uma réplica própria dos username’s e passwords encriptadas.

Cliente

Cliente

Servidor

Servidor

Servidor

Page 12: Arquitectura e modelos de sistemas distribuidos

12

1.2.3 Servidores proxies e caches

Cache área de armazenamento temporário onde se guarda objectos recentemente

usados que estão mais perto que os próprios objectos. Quando um novo objecto é

recebido num computador é adicionado ao cache, sobrepondo alguns objectos se for

necessário. Quando objecto é requisitado por um processo cliente, os serviços cache

verificam primeiro o cache e providenciam o objecto a partir daí, se uma cópia

recente 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 localizados

num servidor proxy que pode ser partilhado por diversos clientes.

Caches são usados extensivamente na prática. Navegadores Web mantém um cache

de página Web visitadas recentemente e outros recursos da Web no computador

cliente, usando uma requisição especial http para verificar se a página é recente no

servidor cache original, antes de mostrá-la ao cliente.

Servidores Web proxies (vide fig. 9) providencia um cache partilhado de recursos

Web para máquinas clientes num site ou para vários sites. O propósito de servidores

proxies é aumentar a disponibilidade e a desempenho do serviço diminuindo o tráfego

na rede e carga de processamento nos servidores Web. Servidores proxy podem

assumir outras funções, como por exemplo, serem usados para aceder remotamente

um servidor Web por meio de um firewall.

Fig. 9: Servidor proxy

Page 13: Arquitectura e modelos de sistemas distribuidos

13

1.2.4 Modelo P2P (Peer to Peer)

Nesta arquitectura, todos processos desempenham funções semelhantes, interagindo

cooperativamente para realizar uma actividade distribuída ou computação sem

nenhuma distinção entre clientes e servidores. Neste modelo, o código dos processos

peer mantém os recursos do nível aplicacional consistentes e os sincroniza, quando

necessário. A fig. 8 mostra três computadores com a configuração deste modelo; Em

geral n processos peer podem interagir uns com os outros e o padrão de comunicação

depende dos requisitos da aplicação.

Page 14: Arquitectura e modelos de sistemas distribuidos

14

Fig. 10: Uma aplicação distribuída baseada em processos peer

A eliminação de processos servidores reduz atrasos de comunicação entre os processos para aceder objectos locais.

1.3 Variações do modelo Cliente Servidor

Diversas variações neste modelo podem ser derivados da consideração dos seguintes

factores:

• 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óvel Applets são bem conhecidos e largamente usados como exemplo de código móvel é o

caso de o utilizador de um navegador Web seleccionar um link para Applet cujo

có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ódigo

descarregado localmente, é que pode boas respostas interactivas, pois não sofre

atrasos 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

Aplicação Código de

coordenação

Aplicação Código de

coordenação

Aplicação Código de

coordenação

Cliente Servidor Web

Código Applet

Page 15: Arquitectura e modelos de sistemas distribuidos

15

b) Cliente interage com o Applet Acedendo 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 bem

conhecidas – a Web é o exemplo mais comum, mas mesmo na Web existem alguns

sites usam funcionalidades não encontradas em navegadores Web, que requerem

có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ção

actualizada à medida que vão ocorrendo alterações no servidor. Isto não pode ser

alcançado com uma interacção normal com o servidor Web, que é sempre iniciada

pelo cliente.

1.3.2 Agentes Móveis Um agente móvel é um programa em execução (incluindo dados e código) que viajam

de um computador para outro numa rede. Um agente móvel pode invocar recursos

locais em cada site que visita – por exemplo aceder bases de dados individuais.

Comparando esta arquitectura com um cliente estático fazendo requisições remotas a

alguns recursos, possivelmente transferindo grandes quantidades de dados, existe uma

redução de custos e tempo na comunicação através da troca de requisições remotas

em locais.

Agentes móveis (como código móvel) são potenciais ameaças para os recursos do

computador que acedem. O ambiente que recebe um agente móvel deve decidir, que

recursos locais são permitidos para o agente, baseados na identidade do usuário com

quem o agente está interagindo – a identidade deve ser incluído duma forma segura

com o código e os dados do agente móvel. Adicionalmente, agentes móveis podem

eles próprios ser vulneráveis – eles podem não completar a tarefa se forem recusados

a aceder a informação que eles precisam. Por exemplo, Web crawlers que precisam

aceder recursos num servidor Web através da Internet que funcionam correctamente

Cliente Applet Servidor Web

Page 16: Arquitectura e modelos de sistemas distribuidos

16

fazendo requisições remotas a processos servidores. Por esta razão, a aplicação de

agentes móveis pode ser limitada.

1.3.3 Computadores em rede

Numa arquitectura stand-alone as aplicações correm em computadores locais. Nestes

casos, o sistema operativo e a aplicação requerem que o código e os dados sejam

colocados no disco local. Mas a manutenção dos dados e da aplicação local, requere

um esforço técnico adicional.

Os computadores em rede é a resposta para este problema. As aplicações são corridas

localmente, 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, os

usuários podem migrar de um computador de rede para outro. Nestes casos os

computadores da rede só precisam ter requisitos mínimos de hardware, podendo

reduzir os custos. Se tiver um disco, este pode ser usado como memória cache

armazenando cópias de software e dados recentemente descarregados do servidor. A

manutenção da memória cache não requere nenhum esforço manual: objectos cache

são invalidados a qualquer momento que uma nova versão do ficheiro é escrita no

servidor.

1.3.4 Thin Clients (Clientes Leves)

O termo Thin Client refere-se a uma camada de software que suporta interfaces do

usuário baseado em janelas num computador local, para o utilizador executando

aplicações num computador remoto. Esta arquitectura possui também baixo custo de

gestão e de hardware, a semelhança de arquitectura de computadores em rede. Pois ao

invés de descarregar o código das aplicações no computador local, tudo ocorre no

computador servidor. Que tem uma grande capacidade de executar uma quantidade

significativa de aplicações simultaneamente.

Page 17: Arquitectura e modelos de sistemas distribuidos

17

A principal desvantagem de uma aplicação thin client é alta actividade de interacção

gráfica, o que resulta em maior tempo de atraso no processamento da imagem. Por

exemplo, VNC (Virtual network computer), Remote Desktop Connection (RDC), …

1.3.5 Dispositivos móveis e rede espontânea O mundo está gradualmente a ser povoado por pequenos dispositivos móveis e

portáteis, incluindo laptops, dispositivos de mão, tais como PDAs (Personal Digital

Assistants), telemóveis, câmaras digitais, relógios smarts,… Muitos desses

dispositivos tem capacidades de serem integrados em redes sem fio.

Com apropriada integração em sistemas distribuídos, estes dispositivos providenciam

suporte a computação móvel. Onde os utilizadores, utilizam seus dispositivos moveis

em diferentes redes e tiram vantagens dos serviços locais e remotos. A forma de

distribuiçã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 ter

serviç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

Page 18: Arquitectura e modelos de sistemas distribuidos

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 processo

servidor ou peer) é especificado por uma ou mais definições de interfaces. Numa

forma básica da arquitectura cliente servidor, cada processo servidor é visto como

uma entidade com funções de interface bem definidas para serem invocadas.

Fig. 12: Modelo de interfaces e objectos

Page 19: Arquitectura e modelos de sistemas distribuidos

19

Em linguagens orientadas a objectos tais como Java e C++, com suporte adicional

apropriado, processos distribuídos podem ser construídas em mais formas de

orientação a objectos. Muitos objectos podem ser encapsulados num processo

servidor ou peer e suas referências são passadas a outros objectos de forma que

possam 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)

Page 20: Arquitectura e modelos de sistemas distribuidos

20

3 Modelo fundamental

Todos modelos, acima descritos, compartilham algumas propriedades fundamentais.

Em particular, todos são compostos por processos que se comunicam por

envio/recebimento de mensagens numa rede de computadores.

Todos modelos compartilham os aspectos gerais de um projecto de sistemas

distribuído (que devem ser considerados) vistos nas aulas anteriores, concernentes ao

desempenho, confiabilidade, redes e segurança de recursos no sistema. Neste ponto

são apresentados modelos baseados nas características fundamentais que nos

permitem ser mais específicos acerca das suas características, falhas e riscos de

seguranç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

colectivamente

Objectivo 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, de

forma a decidir sobre o seu desenvolvimento.

Page 21: Arquitectura e modelos de sistemas distribuidos

21

Os aspectos de sistemas distribuídos que se deseja compreender em modelos

fundamentais são: interacção, falhas e segurança.

Interacção – computação ocorre em processos. Processos se comunicam em troca de

mensagens, resultando em comunicação e coordenação (sincronização e ordenação de

actividades) 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 independentes

podem ser coordenados e limitados por estes atrasos e pela dificuldade de manter a

mesma noção de tempo em todos computadores num sistema distribuído.

Falhas – O funcionamento correcto do sistema distribuído é ameaçado a qualquer

momento que ocorre uma falha em qualquer um dos computadores onde estiver a ser

executado (incluindo falhas de software) ou na rede que os conecta. O modelo de

falha define e classifica as falhas. Este modelo providência as bases para análise dos

seus potenciais efeitos e para o desenho de sistemas que são capazes de tolerar cada

tipo de falha enquanto continuam a funcionar correctamente.

Segurança – a natureza modular de um sistema distribuído e a sua abertura o expõe a

ataques, por ambos agentes: internos e externos. O modelo de segurança define e

clarifica como esse ataques podem acontecer, providenciando as bases essenciais para

análise das ameaças aos sistemas e para o desenho de sistemas que são capazes de

resistir a esses ataques.

3.1 Modelo de interacção Sistemas distribuídos são compostos por muitos processos, interagindo de uma forma

complexa. 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

Page 22: Arquitectura e modelos de sistemas distribuidos

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ência

de passos a serem realizados para o alcance de um propósito ou resolução de um

problema. Programas simples são controlados por um algoritmo, cujos passos são

rigorosamente sequenciais. O comportamento do programa e o estado das suas

variáveis é determinado pelo algoritmo. O tal programa é executado como um

processo simples. Os sistemas distribuídos são compostos por processos múltiplos tais

como os exemplificados no primeiro parágrafo deste ponto. O comportamento e o

estado são descritos por algoritmos distribuídos – uma definição dos passos que

devem ser realizados por cada um dos processos que compõem o sistema, incluindo a

transmissão de mensagens entre eles. As mensagens são transmitidas entre processos

para 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 mensagens

entre eles, em geral, não pode ser previsto. É também difícil descrever todos os

estados de um algoritmo distribuído, porque ele deve lidar com falhas de um ou mais

processos envolvidos ou a falha de transmissão de mensagens.

A interacção entre processos permite a realização de todas actividades de um sistema

distribuído. Cada processo tem o seu estado, consistindo dos dados que ele pode

aceder e actualizar, incluindo as variáveis do seu programa. O estado pertencente a

cada processo é completamente privado, isto é, não pode ser acedido e actualizado por

qualquer um dos outros processos.

A seguir são apresentados dois factores significantes que afectam a interacção de

processo em sistemas distribuídos:

Page 23: Arquitectura e modelos de sistemas distribuidos

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ção O desempenho do canal de comunicação é realizado de várias formas num sistema

distribuído, por exemplo, a implementação de streams ou por uma simples passagem

de uma mensagem numa rede. A comunicação numa rede tem as seguintes

caracterí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 o

iní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ção

que pode ser transmitida num dado instante de tempo. Quando um grande número de

canais de comunicação está usando a mesma rede, eles tem de partilhar a mesma

largura 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 de

dados áudio forem tocados com diferentes intervalos, o som será distorcido.

Page 24: Arquitectura e modelos de sistemas distribuidos

24

3.1.2 Relógio do computador e tempos de eventos Cada computador num sistema distribuído tem o seu relógio interno, que pode ser

usado pelo processo local para obter o tempo corrente. Deste modo, dois processos a

serem executados em computadores diferentes podem associar nos seus eventos um

selo do tempo. Contudo, mesmo se dois processos lerem os seus relógios ao mesmo

tempo, os seus relógios locais pode indicar valores (horas) diferentes. Isto porque o

relógio do computador oscila na hora certa, ainda o mais importante é que essa

oscilação média difere de um computador a outro.

Há varias abordagens para correcção do tempo em processos do computador. Por

exemplo, computadores podem usar receptores de rádios para obter hora a partir do

GPS com precisão por volta de 1 micro segundo. Mas o receptor GPS não funciona

numa área coberta, assim como os custo podem não se justificarem para todos

computadores. Apesar disso, um computador que tenha uma fonte de tempo tal como

GPS pode enviar mensagens de tempo para outros computadores na rede. O resultado

acordado entre relógios locais é afectado por variação de atraso de mensagens.

3.1.3 Variações do modelo de interacção Em sistemas distribuídos é difícil estabelecer limites no tempo usado para execução

do processo, entrega de mensagens ou oscilação do relógio. Dois pontos extremos

providenciam um par do modelo simples: o primeiro tem maior aproximação de

tempo e o segundo não faz nenhuma aproximação sobre o tempo.

3.1.3.1 Sistemas distribuídos síncronos

Segundo Hadzilacos Tueng [1994], um sistema distribuído síncrono aquele em que os

seguintes 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.

Page 25: Arquitectura e modelos de sistemas distribuidos

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ícil

chagar a valores concretos e providenciar garantias nos valores escolhidos. A não ser

que os valores dos intervalos estejam possam ser garantidos, todo d desenho baseado

nos valores escolhidos não será confiável. De qualquer modo, modelar um algoritmo

como um sistema assíncrono pode ser útil para dar umas ideias de como vai se

comportar num verdadeiro sistema distribuído.

Em sistemas síncronos é possível usar timeout por exemplo para detectar a falha de

um processo.

Sistemas distribuídos síncronos podem ser construídos. O que é necessário é que os

processos realizem executam actividades com recursos conhecidos, para os quais

podem ser garantidos uma velocidade do processador suficiente e capacidade de rede.

3.1.3.2 Sistemas distribuídos assíncronos

Muitos sistemas distribuídos, por exemplo a Internet, são muito importantes sem

serem classificados como sistemas síncronos. Por isso a necessidade de um modelo

alternativo: 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 de

tempo 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

Page 26: Arquitectura e modelos de sistemas distribuidos

26

demora. Por exemplo, para transferir um ficheiro usando FTP. Às vezes uma

mensagem de e-mail pode demorar dias para chegar ao destino.

A tabela nº 1 mostra dificuldades para alcançar um acordo em sistemas distribuídos

assíncronos.

Mas alguns problemas de desenho podem ser resolvidos mesmo com estas suposições.

Por exemplo, embora a Web nem sempre pode providenciar uma determinada

resposta num certo intervalo de tempo, os navegadores (browsers) foram desenhados

para 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 para

o síncrono.

Actualmente, os sistemas distribuídos, por causa da necessidade dos processos

compartilharem processadores e canais de comunicação compartilharem a rede. Por

exemplo, vários processos que não são conhecidos as suas características

compartilharem o processador, então o desempenho que ai resultar de qualquer deles

não pode se garantido. Mas há vários problemas de desempenho que não podem ser

resolvidos se for usado algum aspecto de tempo. A necessidade de cada elemento de

dados multimédia que passam sucessivamente para serem entregues antes do término

do tempo, é o referido problema. Para este tipo de problema, é necessário usar

modelos síncronos. A tabela nº 1 mostra a impossibilidade de sincronização de

relógios em sistemas assíncronos.

3.1.4 Ordenação de Eventos

Em muitas casos nos interessa saber quando um evento (envio ou recepção de uma

mensagem) de um processo ocorreu antes, depois ou dum forma concorrente com um

outro evento de um outro processo. A execução de eventos pode ser descrita em

termos 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;

Page 27: Arquitectura e modelos de sistemas distribuidos

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ê ambas

mensagens do X e Y e as responde com referência a ambas. Mas pela independência

do 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 ordem

errada, como por exemplo, o usuário A deverá ver:

Tabela 1: Sistema Assíncrono

Inbox:

Item De Tema

23

24

25

Z

X

Z

Re: Meeting

Meeting

Re: Meeting

Fig. 13: Ordenação de eventos em tempo real

3.2 Modelo de falhas

Num sistema tanto os processos (e computador) como os canais de comunicação

podem falhar pois, não é possível conceber componentes sem falhas, apenas se pode

diminuir a probabilidade de as mesmas ocorrerem

X Y Z A

Legenda: • E – Envia • R – Recebe • M – Mensagem • T - Tempo

E (m1) R (m2) R (m3)

R (m1) E (m2)

R (m1) R (m2) E (m3)

R (m3) R (m1) R (m2)

T1 T2 T3

Page 28: Arquitectura e modelos de sistemas distribuidos

28

O modelo de falha consiste na definição dos mecanismos no qual as falhas podem

ocorrer, de modo a se compreender o efeito dessas falhas. O modelo de falhas abrange

ainda a indicação rigorosa do comportamento global do sistema na presença dos

diferentes tipos de falhas.

3.2.1 Definições Básicas

3.2.1.1 Fault tolerance - tolerância a falhas

Propriedade de um sistema distribuído que lhe permite recuperar da existência de

falhas sem introduzir comportamentos incorrectos. Um sistema deste tipo pode

mascarar as falhas e continuar a operar, ou parar e voltar a operar mais tarde, de forma

coerente, 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 é, de

acordo com a sua especificação. Para um sistema ser altamente disponível (highly

available) deve combinar um reduzido número de falhas com um curto período de

recuperação das falhas (durante o qual não está disponível).

3.2.1.3 Reliability - fiabilidade

Mede o tempo desde um instante inicial até à primeira falha, i.e., o tempo que um

sistema funciona correctamente sem falhas. Um sistema que falha com grande

frequência e recupere rapidamente tem baixa fiabilidade, mas alta disponibilidade.

3.2.1.4 Timeliness- adequação temporal ou pontualidade

Em sistemas de tempo real é a garantia de que o sistema é capaz de obedecer a

constrangimentos temporais, isto é, a capacidade que o sistema tem de garantir limites

para o tempo que as diferentes acções levam a executar.

3.2.2 Tipos de falhas

Hadzilaco e Teang [1994], apresentou uma classificação em que distingue entre as

falhas de processos e as do canal de comunicação.

Page 29: Arquitectura e modelos de sistemas distribuidos

29

3.2.2.1 Falhas por omissão e arbitrárias

Falhas por omissão - dá-se quando um processo ou um canal de comunicação falha a

execução de uma acção que devia executar. Por exemplo uma mensagem que devia

chegar não chegou, processo falha (crash – quer dizer que interrompeu a execução e

as 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 mensagem

não esperada.

Tipo Afecta Descrição

Crash, fail stop Processo

O processo pára e fica parado. Os outros processos não conseguem detectar este facto (a menos que se assuma sistema síncrono)

Omissão Canal Uma mensagem colocada no buffer de outgoing de um canal nunca chega à outra extremidade

Arbitrária (Bizantina)

Processo /Canal

Um processo ou um canal têm comportamentos arbitrários: enviar ou transmitir mensagens em momentos arbitrários, parar ou exibir comportamentos errados

Tabela 2: Falhas por Omissão

Page 30: Arquitectura e modelos de sistemas distribuidos

30

3.2.2.2 Mascarar falhas de componentes

Para compensar os problemas levantados pelas falhas usam-se técnicas para as

mascarar. 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 se

detecta por um timeout – então pode-se emiti-la novamente. Outra hipótese é duplicar

o 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á-las

em falhas por omissão.

Exemplo: um CRC numa mensagem permite transformar uma falha bizantina

do canal numa falha por omissão.

O mesmo tipo de técnicas usam-se em muitas vezes nos componentes hardware do

tipo

3.2.3 Falhas temporais

Uma falha temporal dá-se quando um evento que se devia produzir num determinado

perí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 falha

Afecta Descrição

Relógio Processo

O relógio do processo tem um desvio superior ao permitido em relação ao tempo real

Desempenho Processo

O processo leva mais tempo do que o estipulado a executar uma operação

Desempenho Canal A mensagem levou mais tempo do que o previsto

Page 31: Arquitectura e modelos de sistemas distribuidos

31

Nota: As falhas por omissão e as falhas temporais dizem-se falhas benignas pois são mais facilmente mascaráveis e não corrompem tão facilmente os outros componentes.

3.3 Modelo de segurança

Nas primeiras aulas foi apontada a partilha de recursos como um dos factores

motivadores para Sistemas Distribuídos e foi descrita posteriormente a arquitectura

dos seus sistemas em termos de processos encapsulando objectos e providenciado

acesos a eles através de interacções com outros processo.

O modelo arquitectural providencia as bases para o modelo de segurança: a segurança

em sistemas distribuídos pode ser alcançada assegurando os processos e os canais

usados para a sua interacção e protegendo os objectos que eles encapsulam contra

acesos não autorizados.

A protecção é descrita em temos de objectos, embora os conceitos se apliquem

igualmente a recursos de todos os tipos.

3.3.1 Protegendo objectos

A figura a seguir mostra um servidor que possui uma colecção de objectos que podem

ser invocados por usuários. Estes usuários podem executar programas clientes que

enviam requisições ao servidor para realizar operações nos objectos. O servidor

executa a operação especificada em cada requisição e envia a resposta ao cliente.

Fig. 14: Principal e objectos

Objecto

Cliente Servidor

Principal (Usuário)

Principal (Servidor)

Rede

Invocação

Resposta

Privilégios de acesso

Page 32: Arquitectura e modelos de sistemas distribuidos

32

Os objectos podem ser usados em diferentes formas por diferentes usuários. Por

exemplo, alguns objectos podem conter dados privados do utilizador, como password

e outros objectos podem conter dados partilhados tais como páginas Web. Para

suportar isto, os privilégios de acesso especificam quem é permitido para realizar

operações num objecto, por exemplo, quem é permitido para ler e alterar o estado do

objecto.

É por isso que se inclui os usuários neste modelo como os beneficiários dos

privilégios de acesso. Isso é feito associando cada requisição e cada resultado à

respectiva autoridade. A referida autoridade é chamada principal. Um principal pode

ser um usuário ou um processo. O servidor é responsável por verificar a identidade

dos principais em cada requisição e verificar se eles detém privilégios suficientes para

realizar a operação pretendida num determinado objecto, recusando se não os tiver. O

cliente pode verificar a identidade do principal do processo servidor para garantir que

o resultado provém de um servidor válido.

3.3.2 Protegendo processos e suas interacções Os processos interagem pelo envio de mensagens. As mensagens são expostas a

ataque 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 peer

expõem seus interfaces, permitindo que invocações sejam enviadas aos respectivos

processos por quaisquer outros processos.

Os sistemas distribuídos são frequentemente implementados e usados em tarefas são

sujeitos a ataques externos por usuários hostis. Isto é especialmente verdadeiro para

aplicações que lidam com transacções bancárias, informação classificada ou

confidencial ou outra informação cuja integridade é crucial. A integridade é ameaçada

a violações de segurança a processos assim como a falhas de comunicações.

Page 33: Arquitectura e modelos de sistemas distribuidos

33

3.3.3 O inimigo

Para modelar ameaças de segurança, o inimigo (também conhecido como adversário)

é identificado como sendo capaz de enviar qualquer mensagem para qualquer

processo e ler e copiar qualquer mensagem entre um par de processos, como está

ilustrado na figura abaixo.

Fig. 15; O inimigo

Este tipo de ataque pode ser feito usando um computador ligado a rede no qual se

pode executar um programa que lê o conteúdo das mensagens da rede que são

enviados a outros computadores da rede ou um programa que gera mensagens para

emitir requisições falsas a serviços dando a entender que provém de usuários

autorizados. O ataque pode advir de um computador reconhecido da rede ou do

computador da rede não autorizado. As ameaças de um potencial inimigo estão

descritas nos pontos abaixo que abordam ameaças a processos, ameaças a canais de

comunicação e negação de serviço.

3.3.3.1 Ameaças a processos

Um processo que é desenhado para lidar com requisições pode receber mensagens de

qualquer processo num sistema distribuído, e não pode necessariamente determinar a

identidade 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ícil

para um inimigo gerar uma mensagem com um endereço fictício. A falta de confiança

Processo P Processo Q

O inimigo Cópia de m

m

m’

Page 34: Arquitectura e modelos de sistemas distribuidos

34

no emissor da mensagem é uma ameaça ao correcto funcionamento a ambos

servidores 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ção Um inimigo pode copiar, alterar ou injectar mensagens na rede. Tais ataques

representam 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 do

usuário pode ser revelado a um outro usuário ou pode ser alterado para mostrar algo

diferente.

A outra forma de ataque é a tentativa de gravar mensagens e tentar reenviá-las num

outro momento, fazendo com que seja possível reenviar a mesma mensagem várias

vezes. Por exemplo, alguém pode-se beneficiar da tentativa de reenviar uma

mensagem de invocação solicitando a transferência de dinheiro de uma conta bancária

a outra.

Page 35: Arquitectura e modelos de sistemas distribuidos

35

Todos esses ataques podem ser evitados usando canais seguros de comunicação, que

são descritos abaixo como e baseados em criptografia e autenticação.

3.3.4 Defendendo-se das ameaças de segurança

Criptografia e segredos partilhados: suponhamos um par de processos (por

exemplo um cliente e um servidor concreto) partilham um segredo, ou seja, só eles, os

dois, conhecem o segredo e não mais outro processo no sistema distribuído. Então se

a mensagem trocada pelo par de processos inclui informação que prova a identidade

do 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 ao

inimigo.

Criptografia é ciência que mantém as mensagens seguras, e a encriptação é o

processo de transformar uma mensagem num conteúdo ilegível. A criptografia

moderna é baseada em algoritmos de encriptação que usam chaves secretas – grandes

números que são difíceis de adivinhar – que transformam dados numa forma que não

pode ser somente reservada ao conhecimento da chave de decriptação.

Autenticação – o uso de segredos partilhados e encriptação p providenciam as bases

para a autenticação de mensagens – providenciando identidades apresentados pelos

emissores. A técnica básica de autenticação é incluir na mensagem um porção

encriptada que contém elementos suficientes na mensagem que garantem

autenticidade. A porção de autenticação de uma requisição a um servidor de ficheiros

para a leitura de uma parte de um ficheiro, por exemplo, pode incluir a representação

da identidade do principal da requisição, a identidade do ficheiro e a data horas da

requisição, todos encriptados com uma chave secreta partilhada entre o servidor de

ficheiros e o processo requisitante. O servidor poderia decriptar e verificar se os

detalhes não encriptados correspondem aos detalhes especificados na requisição.

Canais seguros: A encriptação e autenticação são usadas para construir canais

seguros como camadas de serviço no topo dos serviços de comunicação existentes.

Page 36: Arquitectura e modelos de sistemas distribuidos

36

Um canal seguro é um canal de comunicação conectando um par de processos, cada

um deles actua em nome do principal, como mostrado na fig. abaixo.

Fig. 16: Canal seguro

Um 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ércio

electrónico e da comunicação, os exemplos disso são as VPN’s – Virtual Private

Network, o protocolo Secure Sockets Layer (SSL).

3.3.5 Outras possibilidades de ameaça de um inimigo

A negação de um serviço (denial of service) e o código móvel são as possibilidades

oportunas para um inimigo poder interromper as actividades de processo:

Processo P Processo Q Canal seguro

Principal A Principal B

Page 37: Arquitectura e modelos de sistemas distribuidos

37

3.3.5.1 Denial of Service

Esta é uma forma de ataque em que o inimigo interfere com as actividades de usuários

autorizados, fazendo invocações excessivas a serviços ou transmissão de mensagens

na rede, resultando na sobrecarga dos recursos físicos (largura de banda, capacidade

do processamento do servidor). Tais ataques são frequentemente realizados com a

intenção de atrasar ou impedir acções de outros usuários. Por exemplo, a operação de

trancar electronicamente uma porta num edifício pode ser desabilitada por um ataque

que sature o controlo electrónico com requisições inválidas.

3.3.5.2 Código móvel O código móvel levanta um interessante problema de segurança para qualquer

processo que executa um código de programa vindo de outro lugar, por exemplo um

anexo de e-mail. Tal código pode ter um papel de um cavalo de Tróia, dando a

entender que tem propósitos inocentes aos processos, mas que não seja o originário do

código. Os métodos em que os ataques podem ser feitos são vários, o ambiente de

sistema distribuído deve ser construído cuidadosamente de forma a evitar esses

ataques. Muitas dessas questões forma endereçadas pelo Java e outros sistemas de

código móvel, mas a história recente mostra algumas fraquezas. Isto mostra a

necessidade de uma análise e desenho rigoroso de todo sistema de segurança.

3.3.6 O uso dos modelos de segurança O alcance da segurança em sistemas distribuídos pode ser reforçado com o

envolvimento do controlo de acesso a objectos com privilégios pré definidos e o uso

de canais seguros para comunicação. Infelizmente, este não é em geral ocaso. O uso

de técnicas de segurança tais como a encriptação e controlos de acesso incorre em

custos substanciais de gestão e processamento. O modelo de segurança descrito acima

providencia as bases para análise e desenho de sistemas seguros nos quais estes custos

podem ser minimizados, mas as ameaças a sistemas distribuídos levantam-se em

muitos pontos e uma análise cuidadosa dever ser realizada em todas as fontes

possíveis no ambiente do sistema, físico e humano. O modelo envolve a construção

Page 38: Arquitectura e modelos de sistemas distribuidos

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 os

custos das técnicas de segurança necessárias podem ser balanceados contra as

ameaç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