Segurança SOA

SOA não é sinônimo de Web Services. Portanto quando falamos de Segurança SOA, não faz sentido reduzirmos o assunto aos padrões pertinentes a segurança de Web Services como Web Services Security, WS-Trust, SAML, etc, etc, etc.

Mais uma vez é preciso que tenhamos uma visão mais ampla sobre o tema, envolvendo todos os componentes da arquitetura, e não somente o ESB ou motor BPEL ou qualquer outro software específico isoladamente.

Com este objetivo, um modelo de segurança SOA foi elaborado aqui na Sun, há mais ou menos 3 anos. O modelo parte de conceitos bem conhecidos pertinentes ao tema e é basicamente definido em uma matriz de 7 aspectos por 6 facetas específicas de segurança. Por outro lado, o modelo é extensível para permitir a adição de novos mecanismos de segurança, novos aspectos, padrões, especificações, etc.

Aspectos de Segurança

1. Autenticação: Identificação de um sujeito (humano, processo, componente, sistema externo).
2. Autorização: Avaliação de permissão de recursos por parte da entidade. Acontece, usualmente, após a autenticação.
3. Integridade: Garantia de não modificação de informações durante a transferência do seu originador. Tipicamente atingida por assinaturas digitais.
4. Confidencialidade: Garantia que informações não estão disponíveis para sujeitos não autorizados. Tipicamente atingida com criptografia.
5. Responsabilidade (“Accountability”): Associação histórica de eventos que ocorreram com sujeitos.
6. Aprovisionamento de Usuários: Manipulação de bases de dados para inclusão, alteração e remoção de usuários.
7. Políticas de Segurança: Conjunto de regras de negócio que estabelecem o comportamento de um sistema de computação. Podem ser definidas em quaisquer participantes SOA.

Facetas de Segurança

1. Transporte: Proteção de informação durante o trânsito entre duas partes. Fácil implementação através de SSL ou TLS.
2. Mensagens: Proteção de requisições individuais quando são roteadas entre os consumidores, intermediários e provedores de serviços. Em comunicação baseada em SOAP é definida no padrão emergente WS-Security.
3. Aplicação: Mecanismos de segurança da lógica da aplicação. Por exemplo: um diretor pode aprovar ordens de compra até $50K e valores superiores necessitam de aprovação de algum VP.
4. Ativos (Dados): Proteção de quaisquer ativos usados e/ou encapsulados em um serviço. O mais comum é a proteção de dados mas outros tipos de ativos como dispositivos devem ser considerados.
5. Conhecimento: Proteção de informações que descrevem serviços, aplicações e outros ativos sensíveis. Exemplos são: WSDLs e schemas, repositório de políticas, etc.
6. Controle: Inclui todos os mecanismos de segurança que existem para a proteção da solução de governança propriamente dita. Dentre eles estão: violação dos dados de governança, “bypassing workflows”, ataques à infra-estrutura de governança e gerenciamento de serviços.

A idéia é que, de posse destes aspectos e facetas, construamos uma matriz onde possamos identificar o nível de aderência entre estes dois grupos. A matriz abaixo é um exemplo disso:


Os símbolos descrevem o nível de suporte de um determinado aspecto em relação a uma faceta. A tabela abaixo indica o significado de cada símbolo.
Fornece: solução provê esta funcionalidade nativamente ou com mínimo suporte dos consumidores e provedores de serviços.
Suporta: solução facilita a implementação desta funcionalidade pelos consumidores e provedores de serviços.
Permite: solução não atrapalha a implementação desta funcionalidade pelos consumidores e provedores de serviços.
Não fornece: esta funcionalidade está fora do escopo de atuação da solução.

Então, como exemplo: a matriz acima indica que o ambiente usado para a implementação de SOA fornece e implementa o aspecto de autenticacão na faceta de Transporte mas não na de Conhecimento ("Knowledge"). Claro que o ideal é que todas os aspectos sejam endereçados corretamente em todas as facetas do ambiente.

Como conclusão temos que as questões envolvendo Segurança SOA devem ser pensadas de forma mais ampla do que aquela envolvendo as mensagens trafegando por entre os componentes da arquitetura. Melhor seria que o projeto de Segurança SOA fosse encarado como subprojeto de Governança. Em outras palavras, Segurança SOA é melhor entendida como uma dos diversas dimensões ou um caso particular de Governança SOA.