SlideShare uma empresa Scribd logo

Arquitectura e modelos de sistemas distribuidos

1 de 38
Baixar para ler offline
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
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
Í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
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
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
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

Recomendados

Mais conteúdo relacionado

Mais procurados

Sistemas operativos trabalho 10ºano
Sistemas operativos trabalho 10ºanoSistemas operativos trabalho 10ºano
Sistemas operativos trabalho 10ºanoHus Juky
 
Sistemas Operativos Servidores
Sistemas Operativos ServidoresSistemas Operativos Servidores
Sistemas Operativos ServidoresAlexandre Maia
 
Qualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasQualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasAlex Camargo
 
SI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de CódigoSI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de CódigoFrederico Madeira
 
Trabalho de sistema operativo servidor
Trabalho de sistema operativo servidorTrabalho de sistema operativo servidor
Trabalho de sistema operativo servidordtml2k
 
Sistemas Operacionais - 03 - Tipos e Estrutura dos SO
Sistemas Operacionais - 03 - Tipos e Estrutura dos SOSistemas Operacionais - 03 - Tipos e Estrutura dos SO
Sistemas Operacionais - 03 - Tipos e Estrutura dos SOMauro Duarte
 
Sistema Operativos
Sistema OperativosSistema Operativos
Sistema OperativosBugui94
 
Aula 2 introdução a sistemas distribuídos
Aula 2   introdução a sistemas distribuídosAula 2   introdução a sistemas distribuídos
Aula 2 introdução a sistemas distribuídosEduardo de Lucena Falcão
 
Introdução aos Sistemas Distribuídos
Introdução aos Sistemas DistribuídosIntrodução aos Sistemas Distribuídos
Introdução aos Sistemas DistribuídosFrederico Madeira
 
Ferramentas de Gerenciamento de Rede
Ferramentas de Gerenciamento de RedeFerramentas de Gerenciamento de Rede
Ferramentas de Gerenciamento de RedeHelder Lopes
 
Redes de computadores
Redes de computadoresRedes de computadores
Redes de computadoresAron Sporkens
 
Sistemas Multimídia - Aula 01 - Apresentação
Sistemas Multimídia - Aula 01 - ApresentaçãoSistemas Multimídia - Aula 01 - Apresentação
Sistemas Multimídia - Aula 01 - ApresentaçãoLeinylson Fontinele
 
Instalação, configuração e administração de um SO Cliente/Servidor
Instalação, configuração e administração de um SO Cliente/ServidorInstalação, configuração e administração de um SO Cliente/Servidor
Instalação, configuração e administração de um SO Cliente/ServidorEdgar Costa
 
Gerencia e Administração de Redes
Gerencia e Administração de RedesGerencia e Administração de Redes
Gerencia e Administração de RedesAllan Piter Pressi
 
Sistemas Distribuídos - Aula 01
Sistemas Distribuídos - Aula 01Sistemas Distribuídos - Aula 01
Sistemas Distribuídos - Aula 01Arthur Emanuel
 
Multimídia: Protocolos de transmissão de áudio e vídeo
Multimídia:  Protocolos de transmissão de áudio e vídeoMultimídia:  Protocolos de transmissão de áudio e vídeo
Multimídia: Protocolos de transmissão de áudio e vídeoFernando Costa
 
Es capítulo 5 - modelagem de sistemas
Es   capítulo 5  - modelagem de sistemasEs   capítulo 5  - modelagem de sistemas
Es capítulo 5 - modelagem de sistemasFelipe Oliveira
 

Mais procurados (20)

Sistemas operativos trabalho 10ºano
Sistemas operativos trabalho 10ºanoSistemas operativos trabalho 10ºano
Sistemas operativos trabalho 10ºano
 
Sistemas Operativos Servidores
Sistemas Operativos ServidoresSistemas Operativos Servidores
Sistemas Operativos Servidores
 
Qualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasQualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normas
 
SI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de CódigoSI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de Código
 
Trabalho de sistema operativo servidor
Trabalho de sistema operativo servidorTrabalho de sistema operativo servidor
Trabalho de sistema operativo servidor
 
Aula 2 - Processos de Software
Aula 2 - Processos de SoftwareAula 2 - Processos de Software
Aula 2 - Processos de Software
 
Sistemas Operacionais - 03 - Tipos e Estrutura dos SO
Sistemas Operacionais - 03 - Tipos e Estrutura dos SOSistemas Operacionais - 03 - Tipos e Estrutura dos SO
Sistemas Operacionais - 03 - Tipos e Estrutura dos SO
 
Sistema Operativos
Sistema OperativosSistema Operativos
Sistema Operativos
 
Aula 2 introdução a sistemas distribuídos
Aula 2   introdução a sistemas distribuídosAula 2   introdução a sistemas distribuídos
Aula 2 introdução a sistemas distribuídos
 
Introdução aos Sistemas Distribuídos
Introdução aos Sistemas DistribuídosIntrodução aos Sistemas Distribuídos
Introdução aos Sistemas Distribuídos
 
CON08 - VLAN.pdf
CON08 - VLAN.pdfCON08 - VLAN.pdf
CON08 - VLAN.pdf
 
Ferramentas de Gerenciamento de Rede
Ferramentas de Gerenciamento de RedeFerramentas de Gerenciamento de Rede
Ferramentas de Gerenciamento de Rede
 
Redes de computadores
Redes de computadoresRedes de computadores
Redes de computadores
 
Sistemas Multimídia - Aula 01 - Apresentação
Sistemas Multimídia - Aula 01 - ApresentaçãoSistemas Multimídia - Aula 01 - Apresentação
Sistemas Multimídia - Aula 01 - Apresentação
 
Instalação, configuração e administração de um SO Cliente/Servidor
Instalação, configuração e administração de um SO Cliente/ServidorInstalação, configuração e administração de um SO Cliente/Servidor
Instalação, configuração e administração de um SO Cliente/Servidor
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
Gerencia e Administração de Redes
Gerencia e Administração de RedesGerencia e Administração de Redes
Gerencia e Administração de Redes
 
Sistemas Distribuídos - Aula 01
Sistemas Distribuídos - Aula 01Sistemas Distribuídos - Aula 01
Sistemas Distribuídos - Aula 01
 
Multimídia: Protocolos de transmissão de áudio e vídeo
Multimídia:  Protocolos de transmissão de áudio e vídeoMultimídia:  Protocolos de transmissão de áudio e vídeo
Multimídia: Protocolos de transmissão de áudio e vídeo
 
Es capítulo 5 - modelagem de sistemas
Es   capítulo 5  - modelagem de sistemasEs   capítulo 5  - modelagem de sistemas
Es capítulo 5 - modelagem de sistemas
 

Destaque

Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Arthur Emanuel
 
Apresentação Sistemas Distribuídos - Conceito
Apresentação Sistemas Distribuídos - ConceitoApresentação Sistemas Distribuídos - Conceito
Apresentação Sistemas Distribuídos - ConceitoThiago Marinho
 
Sistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAAS
Sistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAASSistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAAS
Sistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAASAdriano Teixeira de Souza
 
Sistemas operacionais sistemas-distribuidos
Sistemas operacionais sistemas-distribuidosSistemas operacionais sistemas-distribuidos
Sistemas operacionais sistemas-distribuidosrobsons75
 
P2P - Sistemas Distribuídos
P2P - Sistemas DistribuídosP2P - Sistemas Distribuídos
P2P - Sistemas DistribuídosGustavo Monteiro
 
Agentes Moveis - Aspectos De Desenvolvimento
Agentes Moveis - Aspectos De  DesenvolvimentoAgentes Moveis - Aspectos De  Desenvolvimento
Agentes Moveis - Aspectos De DesenvolvimentoLuiz Matos
 
Replicação de dados
Replicação de dadosReplicação de dados
Replicação de dadoselliando dias
 
Capítulo 2 - Sistemas Distribuídos - Coulouris
Capítulo 2 - Sistemas Distribuídos - CoulourisCapítulo 2 - Sistemas Distribuídos - Coulouris
Capítulo 2 - Sistemas Distribuídos - CoulourisWindson Viana
 
Arquitetura Cliente-Servidor - Modelos
Arquitetura Cliente-Servidor - ModelosArquitetura Cliente-Servidor - Modelos
Arquitetura Cliente-Servidor - ModelosIsrael Messias
 
Apostila de sql server 2008
Apostila de sql server 2008Apostila de sql server 2008
Apostila de sql server 2008marcos0512
 
Visual Studio 2010 e C# 4
Visual Studio 2010 e C# 4Visual Studio 2010 e C# 4
Visual Studio 2010 e C# 4CDS
 
ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010Norton Guimarães
 
Desenvolvimento de Aplicações com Visual Studio
Desenvolvimento de Aplicações com Visual StudioDesenvolvimento de Aplicações com Visual Studio
Desenvolvimento de Aplicações com Visual StudioGeovani Ferreira Gonçalves
 
A Tributação do Comércio Electrónico
A Tributação do Comércio ElectrónicoA Tributação do Comércio Electrónico
A Tributação do Comércio ElectrónicoJL Saldanha Sanches
 

Destaque (20)

Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02
 
Apresentação Sistemas Distribuídos - Conceito
Apresentação Sistemas Distribuídos - ConceitoApresentação Sistemas Distribuídos - Conceito
Apresentação Sistemas Distribuídos - Conceito
 
Modelo de falhas
Modelo de falhasModelo de falhas
Modelo de falhas
 
Sistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAAS
Sistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAASSistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAAS
Sistemas Distribuídos - Aspectos de Segurança em Sistemas Distribuídos e JAAS
 
Segurança em sistemas distribuidos
Segurança em sistemas distribuidosSegurança em sistemas distribuidos
Segurança em sistemas distribuidos
 
Sistemas Distribuídos - Clusters
Sistemas Distribuídos - ClustersSistemas Distribuídos - Clusters
Sistemas Distribuídos - Clusters
 
Sistemas operacionais sistemas-distribuidos
Sistemas operacionais sistemas-distribuidosSistemas operacionais sistemas-distribuidos
Sistemas operacionais sistemas-distribuidos
 
P2P - Sistemas Distribuídos
P2P - Sistemas DistribuídosP2P - Sistemas Distribuídos
P2P - Sistemas Distribuídos
 
Agentes Moveis - Aspectos De Desenvolvimento
Agentes Moveis - Aspectos De  DesenvolvimentoAgentes Moveis - Aspectos De  Desenvolvimento
Agentes Moveis - Aspectos De Desenvolvimento
 
Classes abstratas e interfaces
Classes abstratas e interfacesClasses abstratas e interfaces
Classes abstratas e interfaces
 
Replicação de dados
Replicação de dadosReplicação de dados
Replicação de dados
 
Capítulo 2 - Sistemas Distribuídos - Coulouris
Capítulo 2 - Sistemas Distribuídos - CoulourisCapítulo 2 - Sistemas Distribuídos - Coulouris
Capítulo 2 - Sistemas Distribuídos - Coulouris
 
Arquitetura Cliente-Servidor - Modelos
Arquitetura Cliente-Servidor - ModelosArquitetura Cliente-Servidor - Modelos
Arquitetura Cliente-Servidor - Modelos
 
Apostila de sql server 2008
Apostila de sql server 2008Apostila de sql server 2008
Apostila de sql server 2008
 
Visual Studio 2010 e C# 4
Visual Studio 2010 e C# 4Visual Studio 2010 e C# 4
Visual Studio 2010 e C# 4
 
ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010
 
Asp.net e c#
Asp.net e c#Asp.net e c#
Asp.net e c#
 
Fundamentos de JDBC
Fundamentos de JDBCFundamentos de JDBC
Fundamentos de JDBC
 
Desenvolvimento de Aplicações com Visual Studio
Desenvolvimento de Aplicações com Visual StudioDesenvolvimento de Aplicações com Visual Studio
Desenvolvimento de Aplicações com Visual Studio
 
A Tributação do Comércio Electrónico
A Tributação do Comércio ElectrónicoA Tributação do Comércio Electrónico
A Tributação do Comércio Electrónico
 

Semelhante a Arquitectura e modelos de sistemas distribuidos

Microsoft redes introdução
Microsoft redes   introduçãoMicrosoft redes   introdução
Microsoft redes introduçãoJoão Dias
 
sistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfsistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfJoelManuel8
 
Intro redes
Intro redesIntro redes
Intro redesTiago
 
Proj. pesq. ibes-pim - marcelo soares - implantação de software livre na em...
Proj. pesq.   ibes-pim - marcelo soares - implantação de software livre na em...Proj. pesq.   ibes-pim - marcelo soares - implantação de software livre na em...
Proj. pesq. ibes-pim - marcelo soares - implantação de software livre na em...Marcelo Medeiros Soares
 
Apostila redes computadores_lages
Apostila redes computadores_lagesApostila redes computadores_lages
Apostila redes computadores_lagesredesinforma
 
Protocolos redes velocidade
Protocolos redes velocidadeProtocolos redes velocidade
Protocolos redes velocidaderedesinforma
 
My sql
My sqlMy sql
My sqlTiago
 
Linguagem c
Linguagem cLinguagem c
Linguagem cTiago
 
Redes de computadores e internet.
Redes de computadores e internet.Redes de computadores e internet.
Redes de computadores e internet.valdarnini
 
Virtualizacao de Servidores: Um comparativo entre VMware e Xen
Virtualizacao de Servidores: Um comparativo entre VMware e XenVirtualizacao de Servidores: Um comparativo entre VMware e Xen
Virtualizacao de Servidores: Um comparativo entre VMware e XenAlan Brumate
 
Sistema de monitoramento para redes sem fio com Zabbix e openWRT
 Sistema de monitoramento para redes sem fio com Zabbix e openWRT Sistema de monitoramento para redes sem fio com Zabbix e openWRT
Sistema de monitoramento para redes sem fio com Zabbix e openWRTMarcelo Santana Camacho
 
Relatório de Projecto de Licenciatura
Relatório de Projecto de LicenciaturaRelatório de Projecto de Licenciatura
Relatório de Projecto de LicenciaturaJoel Carvalho
 
Windows Server 2008pdf
Windows Server 2008pdfWindows Server 2008pdf
Windows Server 2008pdfDavidRamos87
 

Semelhante a Arquitectura e modelos de sistemas distribuidos (20)

Microsoft redes introdução
Microsoft redes   introduçãoMicrosoft redes   introdução
Microsoft redes introdução
 
sistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfsistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdf
 
Intro redes
Intro redesIntro redes
Intro redes
 
Proj. pesq. ibes-pim - marcelo soares - implantação de software livre na em...
Proj. pesq.   ibes-pim - marcelo soares - implantação de software livre na em...Proj. pesq.   ibes-pim - marcelo soares - implantação de software livre na em...
Proj. pesq. ibes-pim - marcelo soares - implantação de software livre na em...
 
Apostila redes computadores_lages
Apostila redes computadores_lagesApostila redes computadores_lages
Apostila redes computadores_lages
 
Protocolos redes velocidade
Protocolos redes velocidadeProtocolos redes velocidade
Protocolos redes velocidade
 
My sql
My sqlMy sql
My sql
 
Arquitetura de-computadores-apostila-avançada completa
Arquitetura de-computadores-apostila-avançada completaArquitetura de-computadores-apostila-avançada completa
Arquitetura de-computadores-apostila-avançada completa
 
Apostilando mysql
Apostilando mysqlApostilando mysql
Apostilando mysql
 
Linguagem c
Linguagem cLinguagem c
Linguagem c
 
Linux
LinuxLinux
Linux
 
Apostila redes
Apostila redesApostila redes
Apostila redes
 
Redes de computadores e internet.
Redes de computadores e internet.Redes de computadores e internet.
Redes de computadores e internet.
 
Apostila cantu
Apostila cantuApostila cantu
Apostila cantu
 
Apostila redes e internet
Apostila redes e internetApostila redes e internet
Apostila redes e internet
 
Virtualizacao de Servidores: Um comparativo entre VMware e Xen
Virtualizacao de Servidores: Um comparativo entre VMware e XenVirtualizacao de Servidores: Um comparativo entre VMware e Xen
Virtualizacao de Servidores: Um comparativo entre VMware e Xen
 
Sistema de monitoramento para redes sem fio com Zabbix e openWRT
 Sistema de monitoramento para redes sem fio com Zabbix e openWRT Sistema de monitoramento para redes sem fio com Zabbix e openWRT
Sistema de monitoramento para redes sem fio com Zabbix e openWRT
 
Relatório de Projecto de Licenciatura
Relatório de Projecto de LicenciaturaRelatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
 
Windows Server 2008pdf
Windows Server 2008pdfWindows Server 2008pdf
Windows Server 2008pdf
 
Internet basico
Internet basicoInternet basico
Internet basico
 

Mais de Portal_do_Estudante_SD (10)

Sistemas operativos distribuidos e de redes
Sistemas operativos distribuidos e de redesSistemas operativos distribuidos e de redes
Sistemas operativos distribuidos e de redes
 
Sd capitulo01
Sd capitulo01Sd capitulo01
Sd capitulo01
 
Jdbc
JdbcJdbc
Jdbc
 
Corbawebserves
CorbawebservesCorbawebserves
Corbawebserves
 
Conceitos basicos
Conceitos basicosConceitos basicos
Conceitos basicos
 
Computacao distribuida com rmi
Computacao distribuida com rmiComputacao distribuida com rmi
Computacao distribuida com rmi
 
Caracterizacao de sistemas distribuidos
Caracterizacao de sistemas distribuidosCaracterizacao de sistemas distribuidos
Caracterizacao de sistemas distribuidos
 
Aula sd 2008_02aspectosprojectosds
Aula sd 2008_02aspectosprojectosdsAula sd 2008_02aspectosprojectosds
Aula sd 2008_02aspectosprojectosds
 
Atividade sd
Atividade sdAtividade sd
Atividade sd
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 

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