Os principais modelos de estruturação de sistemas distribuídos incluem: 1) O modelo arquitetural ilustra a estruturação dos componentes e suas interações. Isto inclui o modelo de camadas e o modelo de arquitetura de sistemas. 2) Os modelos fundamentais abordam a interação entre entidades, falhas e segurança. 3) Os principais modelos de arquitetura de sistemas são o modelo cliente-servidor, serviços providenciados por múltiplos servidores e servidores proxies.

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
1

2. 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
3

3. Í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
2

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
4

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

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:
6

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

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
10

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
Servidor
Cliente
Servidor
Cliente
Servidor
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.
11

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
12

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

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ção
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
Servidor
Cliente
Web
Código Applet
14

15. b) Cliente interage com o Applet
Servidor
Cliente Applet
Web
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
15

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

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
17

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
18

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

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

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
21

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:
22

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

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

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
25

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

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 Z Re: Meeting
24 X Meeting
25 Z Re: Meeting
Fig. 13: Ordenação de eventos em tempo real
X 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 - Tempo
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
27

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

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
O processo pára e fica parado. Os outros processos não
conseguem detectar este facto (a menos que se assuma
Crash, 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 errados
Tabela 2: Falhas por Omissão
29

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 Afecta Descrição
falha
O relógio do processo tem um desvio superior ao permitido em relação
Relógio
Processo ao tempo real
O processo leva mais tempo do que o estipulado a executar uma
Desempenho
Processo operação
Desempenho
Canal A mensagem levou mais tempo do que o previsto
30

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 Privilégios
de acesso
Objecto
Invocação
Cliente
Servidor
Resposta
Principal Rede Principal
(Usuário) (Servidor) 31

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

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
Cópia de m O inimigo
m’
Processo P Processo Q
m
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
33

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

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

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
Principal A
Principal B
Processo P Canal seguro Processo Q
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:
36

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
37

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
38