Segurança em SOA

Introdução

A abordagem da metodologia SOA nas empresas vem crescendo nos últimos anos. SOA não é um conceito novo, vem sendo discutidos dês dos sistemas distribuídos, e tem como abordagem a reutilização e manutenção dos processos distribuídos na empresa.

SOA pode ser baseada em alguns conceitos como: serviço; interoperabilidade; distribuição e reutilização. SOA incorpora uma característica técnica e organizacional, objetivando o compartilhamento de serviços para os processos de negocio controlados por diferentes donos da informação.

Porem SOA deve ser introduzida de forma gradual, gerenciada e organizada. Buscando o máximo de aproveitamento em longo prazo.

Ao adotar SOA todo o seu modelo de negocio precisa ser revisto, estudado e analisado para se transformar em serviço e ser utilizado por outras aplicações, sendo assim, é de extrema importância estabelecer critérios de segurança para garantir a proteção básica da informação. O objetivo deste artigo é apresentar os pontos principais da segurança SOA, explorando pontos fundamentais e fazendo uma breve comparação com os modelos tradicionais.

Independente da metodologia a ser utilizada segurança é um item que exige atenção reforçada dos profissionais de TI envolvidos no projeto, sem a devida atenção, pode-se até possibilitar o fracasso do projeto e deixar com isso de obter as vantagens esperadas pela empresa.

1. O que é SOA

Segundo Thomas Erl (2007) “SOA é a transformação de recursos de TI em serviços de software descentralizados que podem se comunicar entre si aumentando a flexibilidade dos aplicativos de negocio.”

Arquitetura Orientada a Serviço é uma estratégia de TI que transforma regras de negócios existes em aplicações em serviços de software que se comunica com outros serviços por meio de contratos bem definidos.

Baseados neste conceito deveram seguir alguns fundamentos e princípio da arquitetura SOA, tais como:

· Neutralidade: é a independência de plataforma;

· Padronizado: é baseada no uso de padrões;

· Consumível: é permitir sua descoberta e seu uso automatizado;

· Reusabilidade: é o reuso do serviço, não por cópia de código ou re-implementação;

· Abstração: é o serviço totalmente abstraído da sua implementação;

· Publicado: é preciso, com especificações das funcionalidades publicadas através de uma interface do serviço e não por implementação;

· Formal: é o contrato de uso formal entre os pontos de uso, determinando obrigações entre o fornecedor e o consumidor;

· Relevante: possui funcionalidades apresentadas numa granularidade reconhecida pelo usuário como um serviço significativo e etc.

Devemos pensar em SOA como um paradigma arquitetural no quais componentes de aplicações é distribuído, combinados e consumidos. Não podemos então confundir SOA com uma tecnologia, biblioteca de recursos de sistemas ou algo do gênero, e sim uma forma de projetar e organizar a infra-estrutura de funcionalidades em um ambiente corporativo.

2. Segurança

A segurança da informação é um conjunto de medidas que se constituem basicamente de controles e política de segurança, tendo como objetivo a proteção das informações dos clientes e da empresa, controlando o risco de revelação ou alteração por processo não autorizadas.

“Segurança da Informação está relacionada com proteção de um conjunto de dados, no sentido de preservar o valor que possuem para um indivíduo ou uma organização. São características básicas da segurança da informação os atributos de confidencialidade, integridade e disponibilidade, não estando esta segurança restrita somente a sistemas computacionais, informações eletrônicas ou sistemas de armazenamento.” (WIKIPÉDIA, 2010).

3. Abordagem de segurança SOA

Nesta parte do artigo vamos rever algumas abordagens tradicionais de segurança SOA e avaliá-los tentando encontrar possíveis vulnerabilidades e sugerir novas abordagens que podem ser usadas para melhorar determinados conceitos.

3.1. SOA reduz antigas barreiras

Todo profissional da área de TI já se encontrou em uma situação onde uma determinada tecnologia impede a evolução de uma regra de negocio por limites de recursos ou de possíveis integrações, podemos chamar isso de barreiras tecnológicas. Aplicações desenvolvidas de forma independente, desde que a funcionalidade pode ser usada apenas dentro da fronteira de cada negócio podem trazer diversos desafios no futuro, tais como:

· Diferenças entre plataformas, linguagens de programação e protocolos de comunicação antigos e outros limites da tecnologia que não são fáceis de atravessar;

· Segurança aplicada de forma que dificulta a integração de outras ferramentas com o aplicado de negocio.

Todas essas barreiras dificultam as mudanças necessárias nos modelos de negócios com uso de uma ferramenta facilitadora de TI. No intuito de reagir a essas mudanças, SOA pretende resolver este problema e devolver às empresas a flexibilidade e a agilidade que precisam para vencer os desafios do mercado.

3.2. Redução das barreiras nos obriga a repensar a segurança

Barreiras podem ser um bom aliado para segurança, mas geralmente ficam no caminho dos negócios. Sendo assim, precisamos pensar e aplicar as barreiras de forma inteligente, que não comprometa a segurança e atenda os objetivos do negocio. A figura 1 mostra a arquitetura tradicional de segurança do aplicativo, um aplicativo gerencia sua própria segurança e conta com canais de proteção para os dados que faz intercâmbio com aplicativos do cliente.

Figura 1 - Um servidor de aplicações com varias funcionalidade

independentes e um único módulo de segurança.

Como podemos ver na figura 1, concluímos que nada esta errada no processo de segurança do aplicativo, pensando de forma tradicional com visão centralizada, esse tipo de segurança então funciona bem. Antes de analisar esse modelo de segurança e ver os aspectos desta quebra no modelo SOA, podemos observar que existem duas suposições implícitas que estão sendo feitas aqui.

· Quando o servidor de aplicativo é solicitado, como saber qual o modelo de segurança adequado para a solicitação em execução. Quando falamos de segurança, estamos dizendo qual decisão tomar no processo em questão;

· Quando o servidor de aplicação é assumido como confiável é o suficiente para que o requisitante tenha acesso a todas as informações do servidor, incluindo quaisquer dados sensíveis que o cliente esta enviando.

Agora, vamos considerar um aplicativo que é composto de serviços a partir de múltiplas aplicações, como mostrado na figura 2. Primeiramente vamos entender como o servidor de aplicativos da figura 1 difere os servidores de aplicações em comparação a figura 2.

· No modelo SOA podemos trabalhar com as funcionalidades de um aplicativo e facilmente combiná-los com funcionalidades de outros aplicativos assim criando recursos compostos;

· As aplicações compostas podem também combinar funcionalidades de negócios com serviços de outras empresas ou parceiros;

· Outra vantagem no modelo SOA é que um determinado recurso pode ser invocado diretamente pelo cliente, conforme demonstrado na figura 2.

Figura 2 - Múltiplos servidores de aplicações incluindo de

parceiros, e módulos de segurança dedicados.

É difícil um arquiteto prever todos os recursos de seguranças necessários para uma aplicação no inicio do projeto, sendo assim, podemos concluir que no modelo SOA em múltiplas camadas de negócios podemos ter seguranças aplicadas de forma independente do negocio, aumentando com isso a flexibilidade do projeto sem impacto na segurança da informação.

4. Padrões de segurança de serviço

O site SOA Patterns, que pode ser acesso pelo endereço http://www.soapatterns.org, disponibiliza diversas informações sobre padrões boas praticas de desenvolvimento de aplicações no modelo SOA. Baseado no estudo de padrões de segurança SOA cito os pontos relevantes ao artigo.

4.1. Blindagem de Exceções

Devemos prevenir divulgação de informações sobre sua implementação interna quando ocorrem exceções. A não filtragem na saída de dados de um determinado serviço pode conter detalhes de sua implementação interna que pode comprometer a segurança do serviço e do seu ambiente de transações. A figura 3 abaixo ilustra um cenário sem filtragem lógica.

Figura 3 – Divulgação de mensagem quando ocorre exceção.

Para solucionar este problema é aplicado o seguinte conceito. Substituem-se os dados de exceção potencialmente inseguros por dados de exceção seguro, retornando na resposta ao solicitante dados higienizados. A figura 4 abaixo ilustra um cenário seguro.

Figura 4 - Divulgação de mensagem tratada quando ocorre exceção

Desenvolver um ambiente com blindagem pode exigir um esforço significativo da equipe de desenvolvimento acrescentando lógica a um serviço e afetando o desempenho no processo de filtragem quando o serviço for executado. No entanto este processo é chamado somente quando ocorrem exceções, sendo assim está lógica não deve afetar o funcionamento regular do serviço.

5. Identificação, autenticação e autorização

No protocolo de transferência SOAP (Simple Object Access Protocol) pode-se utilizar o recurso de extensão no modelo WS-Security (Segurança em Serviços Web) definindo os cabeçalhos de segurança padrão para SOAP. Enviar o nome do usuário no pedido é uma forma de afirmação de identidade. Alguns serviços requerem um usuário para estabelecer sua identidade. Um usuário afirma uma identidade através do envio de um identificador, tais como endereço, nome de usuário e-mail, ou certificado digital. Mas nem todos os casos podem estabelecer identificação de usuário como fonte de confiança, tentando garantir autenticidade do requisitante se aplica senhas para autenticação.

5.1. Autenticação com usuário e senha

O recurso WS-Security suporta o uso de nome de usuário e senha para autenticação em invocações de serviço web, para isso vamos utilizar o recurso de envio de mensagens SOAP, enviando junto com o nome de usuário uma senha, quando o serviço é solicitado é feito a autenticação para autorização da funcionalidade se o mesmo estiver correto, o servidor processa a solicitação e retorna o resultado, caso não esteja correto, retorna uma falha ao solicitante.

5.2. Exemplo de um cabeçalho com usuário e senha

<soapenv: Header>

<wsse: Security soapenv:actor="FlavioMariotti" soapenv: mustUnderstand="0"

xmlns:wsse=". . . /oasis-200401-wsswssecurity-secext-1. 0. xsd" >

<wsse:UsernameToken>

<wsse: Username>flavio</wsse:Username>

<wsse: Password>senha</ wsse: Password>

</wsse: UsernameToken>

</wsse: Security>

</soapenv:Header>

A entrada de cabeçalho de segurança é simples de compreender. Ele contém o nome de usuário e senha em texto claro. Porem com esse cabeçalho surge algumas duvidas como:

· Como essas credenciais são adicionadas na entrada do cabeçalho?;

· Quem processa a entrada no lado do servidor?;

· Como garante a autenticidade?.

Para compreendermos melhor esse conceito a figura 5 ilustra uma visão geral da aplicação com usuário e senha.

Figura 5 - Visão geral da implementação de um nome de usuário e senha, baseado autenticação.

6. Política de segurança para codificação

No decorrer deste artigo vimos como aplicar a segurança no modelo SOA que reduz a carga da aplicação nos terminais. Vamos nos concentrar agora em três desafios que podem ser resolvidos através da adoção de uma abordagem declarativa de segurança:

· Facilidade de desenvolvimento e administração. Há alguns detalhes que todos os desenvolvedores de serviço e administrador de segurança precisam saber na tentativa de efetivar e garantir o serviço.

· Coerência dos controles de segurança. Isto quer dizer evitar ter mais de um serviço de segurança, facilitando o controle, manutenção e gerenciamento do serviço.

· Interoperabilidade da solução de segurança adotada, lembrando que em alguns momentos seu serviço pode interagir com serviços de outras empresas como fornecedores, parceiros e clientes.

Então como garantir que todas essas preocupações estão sendo atendidas no modelo de segurança adotado. Vamos entender o conceito de segurança declarativa em SOA e mostrar como é possível abordar estes três desafios com utilização de políticas de segurança em serviços web.

6.1. Segurança declarativa

A complexidade no desenvolvimento de sistemas vem crescendo ao longo dos anos, os profissionais têm que estar familiarizado com diversas tecnologias, linguagens, padrões e melhores praticas para ser eficaz em seu trabalho. A programação declarativa vem com o propósito de auxiliar a distribuição de responsabilidade no desenvolvimento de aplicativos, separando as preocupações de cada especialista. Como SOA, por exemplo, que tem vários especialistas diferentes colaborando para desenvolver uma solução.

Partindo deste principio podemos entender então que os desenvolvedores podem criar serviços de negócio, e os especialistas em segurança pode configurar políticas de proteção, e a união das comunidades vai acontecer sem problemas. Para compreendermos melhor como esta teoria se aplicada na pratica a figura 6 ilustra um modelo de desenvolvimento com visão de segurança declarativa.

Figura 6 Aplicação de segurança declarativa especialistas de

segurança e desenvolvedores atuando juntos.

A segurança declarativa pode ser empregada nas seguintes situações: Uso interno dentro de uma empresa para assegurar a aplicação coerente de políticas de segurança por todas as soluções de segurança SOA; Em tempo de execução ou desenho da solução para garantir a interoperabilidade entre as soluções de segurança e aplicações de legados como parceiros, cliente, fornecedores e etc.

6.2. O que é política

Política se refere ao tratamento das regras e orientações. A definição da política no contexto de serviços web se torna um pouco mais formal, podemos traduzir a política como uma maquina de leitura de expressão do que é exigido na troca de mensagens entre serviços de web.

6.3. Políticas de segurança em serviços web

Como podemos concluir com o que vimos até agora, uma abordagem declarativa para a segurança SOA pode trazer alguns benefícios, tais como: Simplificar o trabalho no desenvolvimento do serviço; Trazer consistência para verificações de segurança feito por diferentes soluções de segurança; e Garantir a interoperabilidade com a solução de segurança dos aplicativos que necessitarem de integração.

A política de segurança em um serviço web fornece então o relacionamento de segurança e as afirmações que podem ser usadas em um documento de WS-Policy (Política de Serviço Web) para expressar as necessidades, capacidades e limitações da segurança em um serviço web. As afirmações definidas pela política de segurança do serviço web podem ser classificadas em três grupos:

· 1. Políticas de segurança que pode ser definida no nível de extremidade.

· 2. Políticas de segurança que pode ser definido por operação.

· 3. Políticas de segurança definidas no nível de mensagem.

7. Confidencialidade das mensagens usando criptografia

Na parte de identificação, vimos como podemos estender a segurança através do conceito de autenticação com usuário e senha, porem alguns dados exigem atenção especial, podemos ter como exemplo uma transação que envie dados sigilosos de uma conta bancaria, mesmo o serviço exigindo autenticação para disponibilizar a informação é um principio de segurança básico e pode ser quebrado. Partindo deste principio que vamos entender como aplicar criptografia somente nas partes confidencias de uma mensagem, assim podemos melhorar o desempenho de uma solução sem comprometer a segurança, esta criptografia garante que somente o seu destinatário possa ter acesso a essa informação.

7.1. Noções Básicas de Criptografia

Para entender como funciona a criptografia, considere o caso que uma entidade remetente envia uma mensagem para outra entidade destinatário, sendo assim, como pode se certificar de que somente a entidade destinatário pode ler essa mensagem? Para se certificar que a mensagem será lida somente pela entidade de destino é necessário enviar de uma forma que ninguém (em certos casos nem mesmo o remetente) possa entender a mensagem.

Ou seja, o remetente transforma os dados da mensagem em cifra, e o receptor desfaz a transformação de modo que ele possa voltar os dados no formato original, essa transformação é chamada de codificação e decodificação, respectivamente conforme ilustra a figura 7.

Figura 7 criptografia de chave pública em ação

7.2. Tipos de Algoritmos de Criptografia

A eficácia da criptografia para proteger a confidencialidade de uma mensagem é muito importante a escolha certa do algoritmo usado. Para definir um algoritmo forte, ou seja, difícil de ser quebrado precisamos nos precaver dos seguintes itens:

· Um ataque pode tentar todas as chaves possíveis, sendo assim se o numero de chaves for pequeno o método se torna frágil.

· Analise de texto com frase cifrada, este cenário exige uma distribuição aleatória da tabela de letras, dificultando a comparação lógica.

Infelizmente, dada uma função, é difícil provar que a criptográfica é forte. Existem analises teórica e revisão por pares que pode comprometer a confiança de qualquer algoritmo de criptografia.

Conclusão

SOA está tendo uma boa aceitação no mercado de TI, com isso muitos profissionais se atrevem a implantar SOA sem um conhecimento adequado da metodologia. Não introduza SOA na sua empresa por que está na moda, nem por que alguém disse que é legal. Faça porque é possível obter diversos benefícios para seu negocio.

O importante é saber que SOA não é uma ferramenta que se instala e utiliza, é um conceito que precisa ser estudado e compreendido, para que a solução possa se envolver com os processos de negócios trazendo o máximo de vantagens na sua utilização, e recursos de TI. É de extrema importância o envolvimento de todas as áreas da empresa pra se aplicar a estratégia SOA.

Por fim, existem diversas vantagens para se utilizar SOA. O mais importante é dar atenção a todos os aspectos e seu conceito, como segurança, por exemplo, podemos verificar neste artigo o quanto é amplo o assunto e exige o máximo de conhecimento para não ter surpresas inesperadas, como informações confidenciais sendo disponibilizadas para colaborares sem permissão ou pior para concorrentes.

Segurança da informação é de extrema importância para empresa e deve ser respeitada pelos profissionais de TI, seja no modelo SOA ou qualquer outra metodologia, garantindo sempre a proteção dos dados da organização que representa.

Referência

ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Vancouver: Prentice Hall, 2005. 792 p.

ERL, Thomas. SOA: Principles of Service Design. Vancouver: Prentice Hall, 2007. 608 p.

KANNEGANTI, Ramarao; CHODAVARAPU, Prasad. SOA Security. Greenwich: Manning Publications, 2007. 500 p.

ERL, Thomas. SOA: Design Patterns. Vancouver: Prentice Hall, 2008. 500 p.

Gerência - Arquitetura

Leia também