WebServices – Aspectos de Segurança
O conceito de WebServices não é novidade nos meios da computação. Trata-se de expor serviços através de algum tipo
de interface, de forma que outros possam acessá-los. Sob este ponto de vista, não apresentam grandes diferenciais
em relação aos antigos RPC (Remote Procedure Call), CORBA (Common Object Request Broker Architect), etc. No
entanto, uma série
de características específicas vêm fazendo com que os WebServices mereçam mais atenção. Entre elas, destacam-se:
- Metodologia e linguagem padrões para a exposição das interfaces:
Os WebServices utilizam XML[1] (eXtensible Markup Language) como linguagem básica e o WSDL[2] (WebServices
Description Language - dialeto XML) como forma de descrição das interfaces, ou seja, linguagens são padronizadas,
públicas e de fácil aceitação;
- Total independência de plataforma e linguagem de programação:
Os WebServices podem ser escritos em qualquer linguagem de programação e executados em qualquer plataforma de
hardware e software. Esta característica é uma das mais importantes e permite que sistemas legados possam ser
totalmente reaproveitados construindo-se, apenas, um wrapper que permita sua utilização por outros sistemas.
- Podem utilizar vários tipos de protocolo de transporte, embora o mais utilizado atualmente seja o http ou https[4].
Vamos pensar, por exemplo, em uma transação de compra via Internet na qual, ao final da operação, o comprador informa
seu endereço e o sistema calcula o frete para a entrega dos produtos. Todo processo de cálculo de frete pode ser
encapsulado em um WebService. Desta forma, a plataforma de comércio eletrônico usada na transação em questão,
apenas faz a chamada "Cálculo de frete ao WebService". Este pode ter vida completamente independente do sistema
de comércio eletrônico, tanto nas questões técnicas (plataforma, linguagem, etc) como nas questões geográficas
(localização) e de gerenciamento (quais os perfis que o controlam). Da mesma forma que houve o isolamento do cálculo
de frete em um WebService, outros sub-sistemas também poderiam ter tratamento semelhante (status da ordem de
compra, acesso ao meio de liquidação financeira, etc).
Além de operações B2C, os WebServices vêm ganhando muita relevância nos outros segmentos, principalmente no
mundo B2B e B2G. O objetivo é o de termos comunicação entre este conceito de forma bastante automatizada, inclusive
com serviços espontâneos de localização, descrição de características e integração. Nesta linha UDDI[3] (Universal Description,
Discovery and Integration) vem se mostrando como uma tendência.
Mas o estágio atual dos WebServices ainda carece de mais desenvolvimentos. Muitos chegam a afirmar que estes
aplicativos são muito simples pois resolvem problemas simples. Desta forma, colocam em questão a sua capacidade de
resolver questões mais complexas sem que se tornem, também, piores do que no estágio atual.
De toda forma, os WebServices já passaram pela fase dos "early adopters" e começam a serem adotados em maiores
quantidades e para solução de problemas mais complexos e críticos para a operação das empresas. Nessa adoção em
situações reais, algumas necessidades se fazem imediatas, sendo uma delas (talvez a principal) a questão da segurança.
Na medida que WebServices disponibilizam serviços para o mundo algumas preocupações com segurança aparecem de
imediato, entre elas:
- Como garantir a quem está acessando o serviço que o provedor é realmente quem se diz ser;
- Como garantir ao provedor do serviço que quem está acessando possui perfil compatível para acessá-lo;
- Como garantir que os dados que estejam trafegando entre as partes não foram adulterados, violados, etc.
A solução atualmente disponível é a segurança no protocolo de transporte, através do uso do https[4]. No entanto, esta
solução não é totalmente suficiente nem adequada para resolver todos os problemas.
As mensagens trocadas pelos WebServices são encapsuladas em envelopes SOAP[5] (simple obejct access protocol).
Estes envelopes permitem identificação do destinatário, do serviço que se está querendo acessar, dos parâmetros
necessários para a execução do serviço, etc. Apenas para exemplificar as dificuldades não endereçadas, caso este
envelope SOAP seja criptografado como um todo, numa transação com mais de 2 participantes (o que é bastante comum
em sistemas reais), haveria necessidade de conhecimento das chaves de criptografia por todas as partes, o que
diminuiria significativamente o nível de segurança do sistema em questão.{mospagebreak }
As necessidades de segurança em WebServices passam portanto pela segurança a nível do SOAP, ou mais
especificamente, a nível de campos XML, diminuindo-se assim a granularidade. Várias iniciativas vem sendo tomadas
http://www.pulso.com.br - Pulso
Powered by Mambo
Generated: 16 May, 2008, 13:21
para equacionar estas necessidades, entre elas o ws-security[5]. De toda forma, estas iniciativas ainda estão na fase de
termino de especificação e o mercado necessita de algum tipo de solução imediata para poder colocar sistemas baseados
em WebServices em produção com total segurança.
Entrando na seara da adoção prática destes mecanismos de segurança, seria muito interessante se pudéssemos contar
com uma infra-estrutura capaz de oferecer serviços que permitam implantá-la da forma mais automatizada possível. Isto
para evitarmos que cada um dos serviços tenham que implementar os mecanismos de segurança individualmente, o que
levaria indubitavelmente a:
- Replicação de código;
- Complexidade excessiva dos módulos;
- Aumento do custo de infra-estrutura;
- Diminuição dos níveis de segurança.
Uma solução bastante interessante está baseada nos conceitos utilizados em sistemas de single signon[6]. A idéia é
concentrarmos os mecanismos de segurança em um "servidor de políticas de segurança" (PolicyServer) e instalarmos um
agent no web server que está sendo utilizado para servir o WebService. A figura abaixo mostra esta arquitetura.
A seguinte seqüência ocorre quando um determinado cliente pretende utilizar o WebService:
1. Cliente de um WS cria um "SOAP request message". Esta mensagem já possui incorporada informações
necessárias para autenticação/autorização do cliente ("security tokens");
2. O WSAgent intercepta o pedido, captura os "security tokens" e os envia os para o PolicyServer;
3. O PolicyServer checa as informação contra suas bases de dados e envia a resposta;
4. O WSAgent checa a resposta do PolicyServer;
5. Se autorização OK, o WSAgent acrescenta informações da autorização na mensagem SOAP;
6. A mensagem é passada para o WS que está sendo requisitado;
7. O Cliente recebe uma resposta "SOAP reponse message".
Obs.: A obtenção dos "security tokens" não está descrita aqui. Pode utilizar diversos tipos de mecanismos, dentre os
quais "username/password", certificados x.509 e "tokens kerberous".
Esta solução possui, entre outros, os seguintes pontos positivos:
- Apresenta uma solução imediata para prover segurança em sistemas que utilizam WebServices;
- Os WebServices em si, não implementam a lógica de segurança, tornado o código mais simples e seguro;
- Toda lógica de segurança está concentrada em um único Ponto (PolicyServer) o que permite manutenção mais
simples, maior segurança e menor custo das plataformas.
Cabe ressaltar que a solução proposta utiliza como base protocolos padrão de mercado, tais como XML Signature[7] e
XML Encryption[8], SAML Authentication, etc.
Conclusões:
- WebServices passarão a ser parte fundamental das soluções de sistemas internet nos próximos anos, principalmente em
B2B e B2G;
- Os mecanismos de segurança para WebServices ainda não estão totalmente padronizados, principalmente no aspecto
de implementação;
- Para que sistemas baseados em WebServices sejam colocados em produção, os mecanismos de segurança precisam
ser resolvidos;
- Devemos adotar soluções de segurança flexíveis, que permitam a evolução dos mecanismos de segurança com um mínimo
custo de manutenção;
- A solução descrita acima resolve grande parte das preocupações descritas.
Referências: [1]-xml: http://www.w3.org/XML/ [2]-wsdl: http://www.w3.org/TR/wsdl [3]-uddi: http://www.uddi.org/ [4]https: http://developer.netscape.com/docs/manuals/security/sslin/contents.htm [5]-ws-security:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp [6]-single signon:
http://www.pulso.com.br/portugues/conteudo/produtos/signon.htm [7]-XML Signature: http://www.w3.org/TR/xmldsigcore/ [8]-XML Encryption: http://www.w3.org/Encryption/2001/
http://www.pulso.com.br - Pulso
Powered by Mambo
Generated: 16 May, 2008, 13:21
http://www.pulso.com.br - Pulso
Powered by Mambo
Generated: 16 May, 2008, 13:21