No último artigo sobre SOA, vimos sobre a Arquitetura Orientada a Serviços e como ela funciona. Vimos que uma implementação dessa arquitetura pode ser realizada com qualquer tecnologia baseada em web, mas geralmente a SOA é implementada utilizando Web Services, já que estes são fáceis de implementar e distribuir. Estes mesmos web services também são responsáveis por expor, através de uma rede, um determinado serviço. Sendo assim, eles precisam de uma atenção especial quanto à segurança. Como saber se meus web services estão realmente protegidos?
Serviços
Antes de qualquer coisa vamos retomar à definição sobre o que é um serviço. Para que se possa ter uma real governança em TI em uma empresa é necessário saber que isso não é atingido do dia para a noite. É um processo de longo prazo, por isso exige muita cautela dos processos como um todo, mantendo um alinhamento estratégico entre o negócio e a TI. O Negócio e a TI precisam trabalhar juntos!
Um dos autores mais famosos deste segmento, Thomas Erl, escreveu o livro SOA: Princípios do Design de Serviços, onde ele aborda 8 “regras” para definir um serviço. Nesse livro, ele enumera o que considera essencial para fazer uso da SOA “de verdade”. São eles:
Serviços são reutilizáveis
Essa é talvez uma das principais regras. Para isso acontecer, é necessária a interação da TI e do negócio. Quanto mais um serviço for genérico e puder ser reaproveitado, melhor!
Serviços compartilham um contrato formal
Todo serviço deve vir acompanhado de um “contrato”, onde ele deve informar o que o serviço faz e como ele se comunica.
Serviços possuem baixo acoplamento
Baixo acoplamento significa que certas implementações de um serviço podem ser modificadas, evoluídas e até mesmo substituídas, sem afetar negativamente os consumidores deste serviço.
Serviços abstraem a lógica
Serviços não devem expressar as regras de negócio. Os serviços SOA devem guardar os detalhes de sua implementação, até mesmo caso seja preciso modificar a lógica do negócio, não comprometendo as obrigações do serviço escritos no seu contrato.
Serviços são capazes de se compor de outros serviços
A composição também é uma forma de reutilização. Sendo assim, um serviço pode muito bem chamar um outro serviço para executar a sua tarefa.
Serviços são autônomos
Um serviço também deve ser autônomo, ou seja, apenas ele é suficiente para executar sua lógica.
Serviços evitam alocação de recursos por longos períodos
Quando um serviço é reutilizado, devemos tomar alguns cuidados. Não se deve criar muitas instâncias de um mesmo serviço, pois isso pode sobrecarregar a infra-estrutura. Para isso não acontecer, o serviço deve evitar reter informações específicas em uma determinada atividade.
Serviços devem possuir a capacidade de serem descobertos
O que eu quero dizer é que a capacidade dos serviços serem descobertos significa a visibilidade deles.
Para que isso ocorra, o contrato deve ser bem descrito, evitando que novos requerimentos resultem em serviços redundantes.
Agora que já entendemos um pouco melhor sobre como nossos serviços devem se comportar, vamos a um outro ponto do nosso artigo.
Imagine que uma empresa esteja fazendo o uso de SOA. O que pode acontecer se ela estiver utilizando um web service onde suas informações estão trafegando pela rede sem proteção???
Isso mesmo: acessos indevidos e possíveis interceptações das informações que trafegam pela infraestrutura dos serviços SOA!
Sendo assim, a necessidade de se proteger os recursos envolvidos com a aplicação da SOA no ambiente de TI é uma necessidade real.
Curso Python - SQLAlchemy ORM
Conhecer o cursoConheça o WS-Security: Segurança para Web Services##
A tecnologia WS-Security (Web Services Security) é um padrão que tem a intenção de apoiar a SOA no sentido de prover segurança quando os dados são trocados. O WS-Security disponibiliza um sistema rico para prover segurança, tanto em confidencialidade quanto em autenticação.
Apesar disso, o WS-Security não funciona sozinho. Ele funciona em conjunto com as especificações WS-Policy e WS-SecurityPolicy. Essas especificações têm por objetivo, respectivamente, estabelecer políticas gerais a respeito de segurança, qualidade de serviço, confiabilidade; além de estabelecer quais são as políticas de segurança aplicáveis a um determinado serviço.
Na figura abaixo, podemos ver a estrutura de segurança que é fornecida pelo WS-Security, fazendo também uso da estrutura do WS-Policy.
Esses conceitos são baseados em cinco requisitos comuns de segurança: identificação, autenticação, autorização, confidencialidade e integridade.
Se um solicitante quiser acessar os serviços em segurança, primeiramente ele deve fornecer informações que expressem a sua origem. O WS-Security armazena essas informações em um cabeçalho padronizado, cujo ponto é referido como um token.
A autenticação requer a prova de que a mensagem que está sendo entregue ao destinatário é realmente do remetente que alega ser, fornecendo uma prova de que sua identidade reivindicada é verdadeira.
Após a autenticação, o destinatário pode precisar determinar se o solicitante está autorizado a fazer o que ele tenta fazer. Isto é chamado de autorização. Já a confidencialidade está diretamente ligada com a proteção e privacidade do conteúdo da mensagem, onde a mensagem deve ser mantida como confidencial e nenhum serviço ou mensagem não autorizada deve ver seu conteúdo.
Por último, temos a integridade, que garante que a mensagem não foi alterada desde a sua saída do remetente, garantindo que a mensagem permaneceu intacta a partir do momento de transmissão para o ponto de entrega.
Percebe a necessidade de se proteger as estruturas SOA em uma organização? Os benefícios adquiridos são muitos. Fazendo o uso correto das normas de segurança, a empresa poderá se beneficiar com o uso da SOA sem se preocupar com a integridade de suas informações, ponto de preocupação este que é de certa forma recorrente em organizações que iniciam o processo de adoção de uma arquitetura SOA.
