Arquitetura de Segurança Baseada em Security Patterns para o OpenCTI (Relatório Final)

João Filho Matos Figueiredo

Departamento de Informática da Universidade Federal da Paraíba – UFPB

Este endereço de e-mail está protegido contra SpamBots. Você precisa ter o JavaScript habilitado para vê-lo.

http://www.joaomatosf.com

PLANO

Implementação de Arquitetura de Segurança

Baseada em Security Patterns para o OpenCTI

PROJETO

OpenCTI: Software de uma Central de Telemedicina para

Apoio à Decisão Médica em Medicina Intensiva

Resumo: A prestação de cuidados de saúde, uma vez executados usufruindo de meios de telecomunicações, onde as distâncias dos participantes envolvidos são relevantes, caracterizam um cenário de telemedicina. Nesse contexto, pode-se compartilhar informações clínicas sensíveis, como a história do paciente, a fim de se obter maior qualidade e precisão no atendimento ao paciente, com custos relativos menores. Todavia, este novo ambiente se depara com os desafios de segurança que englobam as redes de computadores, os quais podem ser divididos nas seguintes áreas interligadas: sigilo, autenticação, não-repúdio e controle de integridade. Este projeto de pesquisa propõe uma arquitetura de segurança, capaz de suportar uma comunicação segura entre centros médicos grandes e pequenos, com ênfase no sigilo da informação e na integridade desta e dos recursos físicos. Ademais, as necessidades de alta disponibilidade e balanceamento de carga também são alcançadas, como requisito para sistemas críticos. O modelo desenvolvido sustenta-se na sólida literatura da área da segurança computacional, security patterns, da criptografia e, em particular, na bibliografia da área de sistemas de informação em saúde, sendo baseado em padrões e tecnologias abertas. O projeto da arquitetura vem sendo avaliado, com auxílio de ferramentas de simulação, onde foram empregadas tecnologias reconhecidamente eficazes que visam atender aos requisitos almejados, das quais se destacam: OpenLDAP, VPNs, OpenSSL, VLANs, IDS e Clusters. A comunicação entre os componentes da arquitetura pôde ser alcançada em um ambiente de simulação, atendendo aos requisitos de segurança. Redes virtuais privadas permitiram abstrair o caráter distribuído entre as organizações, onde uma federação estabelecerá as relações de confiança. A autorização multilateral baseada em papéis não tem se mostrado uma tarefa trivial, entretanto, o uso da ferramenta MACA (Middleware de Autenticação e Controle de Acesso) tem mudado este cenário, oferecendo uma solução para a autenticação, possibilitando, desta forma, a concepção final do modelo.

Palavras chave: Central de telemedicina, OpenCTI, Padrões de segurança computacional, Prontuário Eletrônico do Paciente.

1. Introdução

O avanço da comunicação e da informática tem permitido conectar pessoas geograficamente distantes de maneira cada vez mais rápida e eficiente, possibilitando a colaboração através da troca de informações. Assim, as informações clínicas e a experiência de profissionais de saúde podem ser trocadas de forma colaborativa sem que o paciente tenha que se deslocar entre centros distantes para ser assistido. Tem-se então a condição necessária para expandir e melhorar a qualidade dos serviços de saúde. Desta forma, a telemedicina possibilita a quebra de barreiras geográficas, fornecendo um meio eficiente, prático e econômico na prestação dos serviços de saúde [1], principalmente em países com ter ritórios de dimensões continentais como o do Brasil.

Nas sessões de telemedicina eventualmente utilizam-se informações multimídia, como videoconferências, sinais e exames de alta definição, requerendo assim uma rede com qualidade de serviço (QoS), que possibilite o trafego do grande volume de dados de maneira eficiente.

Além disso, o Conselho Federal de Medicina estipula que o prontuário eletrônico pertence ao paciente e deve ser usado apenas por ele ou pelo médico a fim de assisti-lo [2]. Portanto, os requisitos de segurança que visam garantir disponibilidade, sigilo, autenticação, não – repudio e controle de integridade [3], são indispensáveis para a telemedicina e implantação efetiva do OpenCTI. Neste contexto, o sigilo está relacionado ao fato de manter as informações ocultas para usuários não-autorizados. A autenticação gerencia o processo que determina com quem você, ou as aplicações, estão se comunicando, antes de revelar informações críticas. O não-repudio é outro requisito imprescindível, uma vez que trata das assinaturas, evitando que indivíduos neguem determinadas ações, como prescrições precipitadas, negligencia ou qualquer conduta errônea. O controle de integridade responsabiliza-se em identificar tentativas de adulteração do conteúdo das informações, impedindo, desta forma, falsificação e fraudes [4].

Com base neste levantamento, este trabalho propõe um modelo arquitetural de segurança que atenda aos requisitos mencionados e dê suporte a aplicações avançadas de telemedicina (AATs). Procurou-se levar em consideração as limitações tecnológicas, a heterogeneidade e a cultura das organizações, bem como as políticas de segurança. Ou seja, um modelo que se adapte a estas variáveis e que possibilite um tratamento seguro dos recursos e das informações das organizações, potencializando, desta forma, os benefícios advindos da telemedicina.

Para proporcionar bons níveis de confiabilidade à arquitetura de segurança, foi fundamental uma clara definição do seu escopo, o qual incluiu fundamentalmente os seguintes Security Patterns [3]: Canais Seguros, Known Partners (Parceiros Conhecidos), Zona Desmilitarizada (DMZ), Protection Reverse Proxy, Integration Reverse Proxy, Intrusion Detection Requirements, além da utilização de mecanismos que impusessem o cumprimento de determinadas políticas e diretrizes de segurança, os quais, em sua maioria, são citados na literatura como boas práticas de segurança. Este conjunto de padrões pode formar grupos especializados, dos quais se destacam padrões para aplicações de internet, arquitetura e sistema de controle de acesso e padrões de firewall [3].

O protótipo foi desenvolvido usufruindo de modernas tecnologias de virtualização, o que possibilitou uma redução considerável nos custos envolvidos para sua implantação, economia de espaço físico e maiores níveis de segurança, dadas as vantagens de gerencia centralizada e às tecnologias para elevação da disponibilidade oferecidas pelo ambiente Citrix XenServer[5].

2. Metodologia

A comunicação entre aplicações de telemedicina deve, idealmente, ser ponto-a-ponto, devido à necessidade de um meio ágil, flexível, disponível e, principalmente, seguro para transmissão de informações sensíveis, como diagnósticos médicos, usufruindo de tecnologias robustas de criptografia, que garantam a integridade e a confiabilidade da comunicação [6].

Ademais, os dados utilizados durante as sessões de telemedicina não deverão permanecer armazenados em entidades que não os geraram, mas apenas nos bancos de dados das entidades legalmente responsáveis por sua guarda. O acesso aos dados por outras entidades se dará por enlaces de comunicação entre elas, possibilitando que hospitais geograficamente separados se comportem como se estivessem fisicamente interligados, ao mesmo tempo em que estão isolados dos demais segmentos e sistemas internos e externos (rede corporativa e internet).

As organizações que estabelecerão sessões de telemedicina, via AATs, possuirão autonomia para decidir como gerenciar seus próprios recursos e definir suas políticas de autenticação e controle de acesso. Forçar os possíveis colaboradores a implantar um novo plano de gerência e configuração é inviável e proibitivo por questões financeiras e culturais [7]. Assim, será necessário um mecanismo de normatização e regulamentação de regras e processos, a fim de lidar com as diversas características tecnológicas, administrativas ou organizacionais de cada participante.

Em ambientes de produção, onde a quantidade de requisições e a escalabilidade são fatores não previsíveis, identificou-se a necessidade de mecanismos não funcionais que auxiliem os requisitos funcionais a desempenharem o seu papel durante a maior parte do tempo. No escopo desta pesquisa, os principais security patterns e requisitos identificados para compor o modelo final estão listados abaixo, respectivamente, bem como sua breve descrição [3]:

• Security Patters:

Canais Seguros: Criação de canais seguros, criptografados fim-a-fim, instigando o sigilo das informações trocadas em sessões de telemedicina.

Known Partners ( Parceiros Conhecidos ): Utilização de mecanismos que possam garantir a identidade dos envolvidos nas sessões. Desta forma, pode-se trocar dados com maiores níveis de confiabilidade, uma vez que as partes envolvidas passam pelo processo de autenticação.

Zona Desmilitarizada: Separação dos serviços com acesso público (tais como HTTP, SVN, sFTP, Correio Eletronico) da rede local. Para tanto, tais servidores de aplicações publicas não deverão ter rotas para a rede local, limitando, desta forma, possíveis danos nos demais pontos da rede caso um destes serviços seja comprometido.

Protection Reverse Proxy: A DMZ eleva a proteção na rede local, isolando-a dos servidores públicos, porém, esses também precisam elevar seus níveis de segurança, muito embora continuem susceptíveis a ataques pela internet. Desta forma, este padrão funciona como um filtro de pacotes no nível de rede. Além disso, proporciona proteção às aplicações ao nível de protocolo.

Integration Reverse Proxy: Nos sistemas distribuídos robustos, é importante que a existência de muitos servidores, interoperando entre si, seja abstraída aos usuários. A utilização de proxys reversos busca fornecer uma visão homogênea de um conjunto de servidores.

Intrusion Detection Requirements: O IDS é um serviço de segurança que automatiza o acompanhamento dos eventos que ocorrem em servidores ou na rede. Ele é capaz de tomar decisões, como modificar configurações do firewall, baseado na ocorrência dos eventos, além de funcionar como um importante mecanismo capaz de impor o cumprimento de algumas políticas de segurança.

• Requisitos coadjuvantes:

Escalabilidade: a quantidade total de serviços oferecidos ou o total de participantes pode crescer arbitrariamente;

Flexibilidade: a entrada/saída de membros deve ser feita de modo transparente e sem necessidade de grande esforço, mantendo a qualidade do serviço;

Segurança dinâmica: além de possíveis canais seguros e exclusivos, previamente criados, deve-se prover mecanismos de autenticação e autorização através de meios de comunicações não confiáveis, como a Internet;

Descentralização: as relações de confiança entre as organizações podem ser desenvolvidas e estabelecidas de forma descentralizada, gerando uma rede de confiança, que contribui para diminuir a sobrecarga de um elemento central e para aumentar a eficiência dessas relações;

Confiança mútua: todas as partes envolvidas devem possuir níveis de confiança similares, apesar das discrepâncias existentes entre as organizações.

Os relacionamentos entre os padrões de segurança estão ilustrados na figura 1.

Figura 1 – Padrões de segurança para aplicações seguras de internet [3].

A seguir são levantadas considerações sobre técnicas de criptografia, boas praticas de segurança e uma breve descrição da implementação, que serão arcabouço para base do protótipo.

• Criptografia e boas práticas de segurança

Com exceção da camada física, quase toda segurança se baseia em princípios criptográficos [4], portanto, este assunto deve ser cuidadosamente aplicado, visto que a utilização inadequada de padrões (algoritmos e protocolos) pode levar a exposição crítica do sistema.

Na camada de enlace, os pacotes podem ser codificados à medida que saem de uma estação, e decodificados quando atingem o destino. No entanto, quando os pacotes têm de atravessar vários roteadores, essa abordagem se mostra ineficiente, pois se faz necessário descriptografa-los em cada roteador, possibilitando ataques dentro dos mesmos. Para contornar essa situação, pode-se utilizar a combinação de VPNs e IPSec, criando o já mencionado canal seguro.

Na camada de rede, podem ser instalados os Protection Reverse Proxy, firewalls, Integration Reverse Proxy, Intrusion Detection Requirements, além da segurança do IP. Na camada de transporte, é possível criptografar conexões inteiras fim a fim, processo a processo, obtendo segurança máxima. Finalmente, na camada de aplicação, são tratadas as questões como autenticação e não repúdio.

Na prática, haverá um framework, o MACA [8], que deverá gerenciar a autenticação e a autorização multidomínio, baseado no modelo RBAC [9], no qual privilégios são associados a papéis e papéis são associados a usuários. Neste processo, é importante salientar que a literatura mostra a importância da utilização de algoritmo forte (mas público) e de uma chave longa, a fim de garantir o sigilo. Algoritmos fortes, de chaves simétricas, geralmente são mais rápidos que algoritmos de chaves públicas, porém esses normalmente serão usados apenas para o compartilhamento das chaves simétricas. O MACA também não deverá usar algoritmos que possibilitem “ataques de aniversário”, ou seja, igual ou inferior ao MD5, ou “ataque por reflexão”, devendo, para tanto, obedecer a quatro regras essenciais[4]:

Fazer com que o transmissor prove quem é antes de o receptor.
Fazer com que o transmissor e o receptor utilizem chaves especificas para provarem quem são, mesmo que isso signifique ter duas chaves compartilhadas, Kab e Kba.
Fazer com que o transmissor e o receptor extraiam seus desafios de conjuntos distintos. Por exemplo, o transmissor deve usar números pares e o receptor deve usar números impares.
Tornar o protocolo resistente a ataques que envolvam uma segunda sessão paralela, no qual as informações obtidas em uma sessão sejam usadas em uma sessão diferente.

(Tanenbaum, 2003)

Além disso, o algoritmo de Diffie-Hellman também deve ser evitado, por ser sujeito a ataques de “homem ao meio”. O uso da autenticação bidirecional, com protocolo de desafio-resposta abreviado é uma boa implementação prática que atende as necessidades do OpenCTI, desde que obedeça as regras anteriores.

• Protótipo

O protótipo da arquitetura de segurança baseada em security patterns para OpenCTI vem sendo implantado de forma incremental, buscando atender rigorosamente aos requisitos levantados no âmbito desta pesquisa. Seu desenvolvimento foi realizado no Laboratório de Arquitetura e Sistemas de Software do Departamento de Informática da Universidade Federal da Paraíba – LARQSS/DI/UFPB e no Hospital Universitário Lauro Wanderley – HULW/UFPB, onde foram utilizados os seguintes equipamentos:

1. Dois servidores HP Proliant ML350 Intel Xeon, 4Mb de memória cachê, 2Gb de memória RAM, 1 disco SCSI de 500Gb e 2 discos SATA de 250Gb cada.

2. Um roteador Wireless D-link 624g

3. Um computador IBM Pentium III, 256Mb de memória RAM.

As tecnologias empregadas são open source, das quais se destacaram as listadas a seguir:

Suse Enterprise Server 10: Distribuição de código aberto do sistema operacional Linux voltado para aplicações de servidor e mantida pela empresa Novell Data System Inc.

CentOS 5: Distribuição de código aberto do sistema operacional Linux baseada na distribuição RedHat Enterprise Server.

FreeBSD 7.1: Sistema operacional de código aberto voltado especialmente para roteadores, firewalls ou servidores com grande número de requisições.

OpenVPN: Software livre voltado para criar redes privadas virtuais (VPNs) do tipo ponto-a-ponto ou server-to-multiclient através de túneis criptografados.

OpenLDAP: Serviço de diretórios no padrão X.500 que implementa o protocolo LDAP.

OSSEC HIDS: Sistema de detecção de intrusos capaz de proteger um conjunto de computadores/servidores, garantindo a integridade dos sistemas monitorados.

Citrix XenServer 5.5: Plataforma de virtualização do tipo bare-metal, que roda direto sobre o hardware, dispensando sistema operacional hospedeiro. Suporta o recurso de “migração à quente”, possibilitando que maquinas virtuais sejam transferidas entre servidores sem interrupção na produção, elevando, desta forma, a disponibilidade.

Iptables Firewall: Ferramenta para gerencia de regras de firewall.

Squid: Servidor proxy e/ou proxy reverse, responsável pela ligação da rede interna com a internet. Realiza cache para otimizar requisições e pode ser integrado a serviços de diretórios a fim de prover autenticação via Browser.

OpenSSL: Disponibiliza várias funções de criptografia, tais como geração de certificados digitais, assinatura de mensagens baseado em criptografia de chaves públicas, entre outras.

Heartbeat: Serviço usado para construir clusters de altíssima disponibilidade. É instalado no servidor de produção e no servidor redundante e gerencia a disponibilidade do primeiro. Ao detectar que o servidor de produção caiu, ativa automaticamente o servidor redundante.

Mon: Normalmente usado em conjunto com Heartbeat, faz um monitoramente mais preciso do servidor de produção, a fim de identificar situações onde o servidor de produção continua disponível, porém apenas um determina serviço encontra-se indisponível. Neste caso, o heartbeat interpretaria o servidor como disponível, quando na verdade o serviço está indiponível.

DRBD (Distributed Replicated Block Device): Ferramenta que realiza espelhamento de um servidor primário em um servidor redundante, se comportando como um RAID1 via ethernet. Garante que todas as operações de escrita realizadas no primário serão replicadas no redundante, com verificação de integridade.

3. Resultados e Discussão

• Redundância

O ambiente de alta disponibilidade para o OpenCTI, usufruindo de maquinas virtuais, foi cuidadosamente planejado, dado que estes ambientes são mais sensíveis a desastres. Uma falha em uma interface de rede compartilhada por várias maquinas virtuais poderia causar danos significativos à produção e interromper sessões importantes de telemedicina. Para contornar esse problema foi necessário empregar o conceito de redundância, que trata-se de um servidor redundante, replica do servidor em produção, que checa constantemente a disponibilidade do servidor produção e, caso não obtenha respostas, ativa seus serviços em substituição ao servidor que caiu.

O processo é ilustrado na figura 2, onde o endereço de IP 192.168.0.3 é um endereço virtual, gerenciado pelo heartbeat. As requisições são respondidas preferencialmente pelo servidor 192.168.0.1 ou, quando este estiver indisponível, o heartbeat se encarrega de levantar os serviços no servidor 192.168.0.2 de maneira que ele passe a responder as requisições.

Figura 2 – Sistema de redundância usando o Heartbeat.

• Canais seguros

A criação dos canais seguros, provendo comunicação entre dois pontos distribuídos, está ilustrada na figura 3. Neste esquema, foi configurada uma rede virtual privada (VPN) entre o LARQSS e o HULW, figura 4, que abstraiu o caráter distribuído e possibilitou a autenticação de usuários em uma única base de dados com garantia de sigilo e integridade [10]. Com a VPN também é possível configurar servidores de redundância em pontos geograficamente distribuídos, oferecendo proteção dos dados mesmo em caso de grandes desastres naturais em um dos pontos.

Figura 3 – Canal seguro entre dois locais distintos usando OpenVPN.

Figura 4 – Rede virtual privada entre o LARQSS e o HULW

• Virtualização

Os sistemas operacionais, de acordo com o já mencionado, estão rodando em maquinas virtuais sobre uma camada de virtualização XenServer5.5, o que às torna independentes de hardware real. As figuras 5 e 6 ilustram como funciona arquitetura de virtualização.

Figura 5 – Arquitetura de virtualização bare-metal com Citrix XenServer.

Figura 6 – Esquema de arquitetura de virtualização para OpenCTI

• Zona desmilitarizada (DMZ)

Até este ponto prevê-se, com base na sua documentação, que o openCTI será dividido em camadas, sendo uma dessas a camada de persistência de dados, que deve ter níveis elevados de segurança. Outra camada irá oferecer uma interface com o usuário, estando em uma rede pública. Assim, a implementação de uma DMZ é necessária para o isolamento entre os servidores públicos e a rede privada, evitando danos à rede corporativa e a outros servidores privados em casos de comprometimento de segmentos da rede pública [10].

A configuração da DMZ foi realizada com a ferramenta iptables, embora a ferramenta ipfw, disponível nos sistemas operacionais BSDs, seja a mais indicada para uso em firewalls críticos. A justificativa para o uso da ferramenta iptables foi a quantidade de documentação disponível e a experiência nesta ferramenta, em detrimento ao ipfw. Na figura 7, percebe-se que o trafego entre o servidor web e o servidor de persistência passa, necessariamente, pelo firewall. Assim, duas configurações são possíveis: (a) Não existe rota entre ambas as redes, assim toda tentativa de ascender aos servidores privados pela rede pública é frustrada. (b) O firewall pode fornecer regras que permitam determinados tipos de tráfegos atravessarem a rota, possibilitando uma comunicação limitada entre as redes. A configuração (a) é utilizada na grande maioria das situações, porém, ainda é inconclusivo qual das configurações melhor atenderá às necessidades do OpenCTI.

Figura 7 – Configuração da DMZ para isolamento entre as redes publica e local

• Proxy

Os padrões de Proxy foram implementados usufruindo das funcionalidades do SQUID, que foi testado em duas configurações: (a) filtro de pacotes em maquina virtual e (b) filtro de pacotes em uma maquina real. Em ambas as situações o squid se mostra eficiente, porém dada a sobrecarga de requisições comuns em servidores Proxy, optou-se por usar a configuração deste em uma maquina real, conforme ilustrado na figura 8.

Figura 8 – Proxy squid para filtro de pacotes, autenticação e cachê

• Serviço de diretórios X.500

O serviço de diretórios é um ponto crucial para o OpenCTI, uma vez que é a tecnologia mais indicada para guardar dados de autenticação de usuários em ambientes distribuídos [11]. No contexto desta pesquisa, o OpenCTI fará autenticação dos usuários na base de dados do OpenLDAP, que também permitirá o uso da ferramenta MACA para atribuição de papeis. Além de usuários, a arvore do openLDAP permitirá autenticação e busca de serviços, possibilitando, também, que determinados nós sejam delegados a diferentes servidores. Assim, hospitais diferentes terão autonomia para gerenciar seus próprios recursos (seu nó na arvore de diretórios), porém sem afetar a estrutura da arvore. Um exemplo de um serviço desse tipo são os servidores de DNS, onde cada provedor tem autonomia para gerenciar seus próprios domínios e servidores de DNS, mas não deixam de compor o todo.

A figura 9 ilustra a estrutura de diretórios criada para validação do protótipo.

Figura 9 – Estrutura de diretórios OpenLDAP para protótipo da arquitetura de segurança

Assim, o nó dc=larqss,dc=di,dc=ufpb pode estar nos servidores do LARQSS, enquanto o nó dc=hulw,dc=ufpb nos servidores do HULW, porém ambos constituírem uma só estrutura de arvore, permitindo autenticação centralizada em um ambiente distribuído.

Todos os demais serviços, a exemplo do SQUID, podem e devem ser integrados ao OpenLDAP, de maneira que se tenha uma única base de autenticação. Essa abordagem combinada com o Kerberos oferece o conceito de Sign-On, onde usuários informam a senha uma única vez para logar no sistema e todas as demais autenticações em outros serviços são realizadas por trocas automáticas de tickets. Desta forma, reduz-se a quantidade de vezes que o usuário deve digitar suas credenciais e evita-se que a senha trafegue pela rede, mesmo que criptografada.

As questões envolvendo criptografia, geração e troca de certificados digitais X.509, protocolos e algoritmos de autenticação e troca de informações, obedecem as normas lidas no sub-tópico Criptografia e boas práticas de segurança, tendo sido utilizado o OpenSSL para atender a tais necessidades.

• Sistema de detecção de intrusos HIDS

Configurada a base da arquitetura, pode-se iniciar as configurações do Sistema de Detecção de Intrusos e alcançar segurança em profundidade, protegendo as camadas onde o firewall não consegue atuar. O OSSEC é um sistema HIDS, multiplataforma e de código aberto, capaz de suprir as necessidades que os tradicionais NIDSs não atendiam. Das suas principais características, pode-se citar a capacidade de verificação de integridade do sistema, monitoramento de arquivos de log, monitoramento de registro, detecção de rootkits e resposta ativa [3].

Para atender as necessidades de segurança em perímetro, foram estudadas duas formas de atuação do OSSEC a fim de se definir a que melhor atenda aos requisitos da arquitetura para telemedicina. Na primeira configuração, o sistema HIDS foi instalado em cada estação a ser protegida, oferecendo segurança local. Porém, essa solução se mostrou pouco escalável e de gerencia complexa. Na segunda configuração, o OSSEC foi instalado em modo Servidor em uma estação e em modo Agente nas demais, de maneira que as estações agentes relatem seus eventos ao Servidor e este, por sua vez, possa tomar decisões com base nos logs e enviar alertas ao responsável. A comunicação entre os Agentes e o Servidor OSSEC pode se dar por canais seguros exclusivos, estabelecidos com uma chave previamente compartilhada. Nesta configuração, a confiança recai sobre a estação OSSEC Servidor, exigindo maiores cuidados quanto a sua segurança. Portanto, decidiu-se utilizar nesta estação o Sistema Operacional FreeBSD, por ter um histórico de falhas mais que dez vezes menor que o Linux, segundo dados da secunia em [12] e [13].

• Modelo final

A figura 10 apresenta o ambiente final, ilustrando de maneira expandida, sem considerar os servidores como virtualizados. O router firewall insere os servidores públicos em uma DMZ, enquanto a rede local conta com um Proxy SQUID para filtro de pacotes e autenticação. O sistema de detecção de intrusos OSSEC Agente deve ser instalado em todos os servidores envolvidos, para que o OSSEC Server, ilustrado na figura 10, possa realizar o monitoramento da integridade dos mesmos.

A figura 11 apresenta a arquitetura do servidor virtualizado, de maneira que o modelo abaixo possa ser implementando com maquinas e switchs virtuais.

Figura 10 – Modelo final expandido

Figura 11 – Modelo final implementando em um único hardware físico com auxilio de virutalização

Toda configuração apresentada foi baseada nos Security Patters, nas boas práticas de segurança e nos casos de sucesso encontrados na literatura da segurança computacional. Identificou-se ampla necessidade de aplicação das tecnologias de segurança no campo da informática em saúde, que desfruta de literatura dispersa no que diz respeito a integração destas tecnologias de maneira que componham um cenário completo de segurança. Em geral tem-se dado maior parte da atenção às certificações digitais, que por si só são deficientes, sendo apenas mais um dos requisitos que devem ser cumpridos para se atingir bons níveis de segurança.

Percebeu-se, ainda, que a aplicação de clusters de acordo com o explanado na proposta inicial, apesar de contribuir significativamente para elevação de desempenho, poderia inserir pontos críticos de vulnerabilidade [14]. Assim, o uso de clusters no modelo final se limitou apenas a característica conhecida como altíssima disponibilidade. Para compensar esta mudança, usufruiu-se da tecnologia de balanceamento de carga, disponível no servidor web Apache, que supri as necessidades de desempenho dividindo a carga entre servidores distintos, porém de maneira menos complexa e mais robusta do que utilizando um complexo cluster SMP distribuído.

Conclusões

O modelo apresentado busca oferecer uma base sólida, a fim de servir como referência a instituições que desejem utilizar um cenário de telemedicina, com especial atenção nos quesitos; disponibilidade, sigilo, autenticação, não–repudio, controle de integridade e desempenho elevado.

O modelo também leva em consideração a heterogeneidade das instituições que por ventura estarão envolvidas. Toda a abordagem foi baseada em modelos e tecnologias livres, sempre com intuito de reduzir custos e viabilizar a efetivação da solução.

Proporcionar segurança em ambientes multidominios, com particular uso de autorização baseada em papéis, tem sido campo de vastos estudos e pesquisas, não se mostrando uma tarefa trivial. Recentemente o framework MACA[8] disponibilizou um modulo para suporte multiorganizacional, fruto de recentes pesquisas, que oferece uma solução para autenticação coletiva de usuários em diferentes organizações. Esta solução ainda esta sendo analisada, a fim de se certificar quanto aos níveis de segurança oferecidos, com base nos requisitos do OpenCTI.

Com um escopo bem definido, pôde-se oferecer um modelo capaz de suprir as necessidades de segurança levantadas, possibilitando que sessões de telemedicina sejam realizadas com níveis elevados de garantia.

4. Referencias Bibliográficas

[1] CHANG T, LEE J, WU S. The Telemedicine and Teleconsultation System Application in Clinical Medicine. In Anual International Conference of the IEEE; 2004 September. p. 3392-3395.

[2] SCHUMACHER, M.; BUGLIONI, E. F.; HYBERTSON, D.; BUSCHMANN, F.; SOMMERLAD, P. Security patterns: integrating security and systems engineering. England: John Wiley & Sons, 2006.

[3] Conselho Federal de Médicina (Brasil). Resolução CFM Número 1.821/2007. Brasília, DF: CFM, 11 jul. 2007.

[4] TANENBAUM, A. S. Redes de Computadores. tradução Vandenberg. D. S., 4ª Edição. Rio de Janeiro: Elsevier, 2003.

[5] Citrix XenServer. Disponível em: < http://www.citrix.com/English/ps2/products/feature.asp?contentID=1686939>. Acessado em agosto de 2009.

[6] KOBAYASHI, L. O. M.; MOTTA, G. H. M. B.; Furuie, S. S.. Análise dos Requisitos Tecnológicos para Implementação de Segurança Fim-a-Fim em Imagens Médicas. In: III Latin American Congress on Biomedical Engineering, XIX Congresso Brasileiro de Engenharia Biomédica, 2004, João Pessoa - PB. Proceedings of the International Federation for Medical and Biological Engineering, 2004. v. 5. p. 597-600.

[7] SOMMERVILLE I. Engenharia de Software. Wesley: Pearson Addison, 2007.

[8] MOTTA, G. H. M. B. Um modelo de autorização contextual para o controle de acesso ao prontuário eletrônico do paciente em ambientes abertos e distribuídos. São Paulo: USP, 2004. 213 p. Tese (Doutorado) – Programa de Pós-graduação em Engenharia Elétrica, Escola Politécnica da Universidade de São Paulo, São Paulo, 2004.

[9] FERRAIOLO D. F.; KUHN, D. R.; CHANDRAMOULI, R. Role-Based Access Control. Boston: Artech House, 2003.

[10] STALLINGS, W. Criptografia e Segurança de Redes: Princípios e Práticas. 4ª Edição. Prentice-Hall, 2007.

[11] TRIGO, C, H. OpenLDAP: uma Abordagem Integrada. São Paulo: Novatec, 2007.

[12] Vulnerability Report: FreeBSD 7.1. Disponível em: < http://secunia.com/advisories/product/21677/> Acessado em agosto de 2009.

[13] Vulnerability Report: Debian GNU/Linux 5.0. Disponível em < http://secunia.com/advisories/product/21392/> Acessado em agosto de 2009.

[14] TANENBAUM, A. S. Organização estruturada de computadores. Tradução: Arlete Simille Marques; 5ª Edição. São Paulo: Pearson Prentice Hall, 2007.

a) Publicações

¹MODELO CONCEITUAL DE SEGURANÇA PARA UMA ARQUITETURA MULTIDOMÍNIO EM TELEMEDICINA – João F. M. Figueiredo, Eduardo P. Serafim, Walber J. A. Silva, Diego S. A. Pizzol, Gustavo H. M. B. Motta. ( artigo: http://www.sbis.org.br/cbis11/arquivos/953.pdf ).

A exposição do artigo, em forma oral, está disponível em: http://video.google.com/videoplay?docid=-6281250557996704708

b) Perspectivas

Esta pesquisa continuará a ser realizada no âmbito do projeto OpenCTI, onde pretende-se avançar na integração multiorganizacional e continuar o processo incremental.

c) Outras Atividades

Foram apresentados seminários com os seguintes títulos:

· Estruturação da Evolução Clinica Para o Prontuário Eletrônico do Paciente.

· TimeLine Visualizing Integrated Patient Records.

· Modelo Conceitual de Segurança Para Uma Arquitetura Multidominio em Telemedicina.

Participação no XI Congresso Brasileiro de Informática em Saúde, em Campos do Jordão – SP, onde foi publicado um artigo¹ produzido no contexto da pesquisa, o qual foi selecionado como Finalista ao Prêmio de melhor publicação no CBIS2008.

Implantação de um ambiente colaborativo, MediaWiki, para dar suporte a documentação e gerenciamento de resultados do OpenCTI.

!joomlacomment 4.0 Copyright (C) 2009 Compojoom.com . All rights reserved."