Partilhar via

Segurança em um mundo de serviços Web: uma arquitetura e um roteiro propostos

  • Artigo

 

7 de abril de 2002
Versão 1.0

© 2001-2002 International Business Machines Corporation, . Todos os direitos reservados.

Este é um documento preliminar e pode ser alterado substancialmente ao longo do tempo. As informações contidas neste documento representam a exibição atual da International Business Machine e da Microsoft Corporation sobre os problemas discutidos a partir da data da publicação. Como a IBM e a Microsoft devem responder às mudanças nas condições do mercado, ela não deve ser interpretada como um compromisso por parte da IBM e da Microsoft, e a IBM e a Microsoft não podem garantir a precisão de qualquer informação apresentada após a data da publicação.

A apresentação, distribuição ou outra divulgação das informações contidas neste documento não é uma licença, expressa ou implícita, para qualquer propriedade intelectual de propriedade ou controlada pela IBM ou Pela Microsoft e\ou por qualquer outro terceiro. IBM, Microsoft e\ou qualquer outro terceiro pode ter patentes, pedidos de patentes, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual que abrangem assunto neste documento. O fornecimento deste documento não lhe dá nenhuma licença para patentes, marcas comerciais, direitos autorais ou outra propriedade intelectual da IBM ou da Microsoft ou de qualquer outro terceiro. As empresas de exemplo, organizações, produtos, nomes de domínio, endereços de email, logotipos, pessoas, locais e eventos descritos aqui são fictícios. Nenhuma associação com qualquer empresa real, organização, produto, nome de domínio, endereço de email, logotipo, pessoa, locais ou eventos é pretendida ou deve ser inferida.

Este documento e as informações contidas aqui são fornecidas em uma base "AS IS" e, na extensão máxima permitida pela lei aplicável, a IBM e a Microsoft fornecem o documento COMO ESTÁ E COM TODAS AS FALHAS e, portanto, isentam todas as outras garantias e condições, expressas, implícitas ou estatutárias, incluindo, mas não se limitando a, quaisquer garantias implícitas (se houver), funções ou condições de comercialização, de aptidão para uma finalidade específica, de precisão ou integridade de respostas, de resultados, de esforço de trabalho, de falta de vírus e de falta de negligência, tudo em relação ao documento. ALÉM DISSO, NÃO HÁ GARANTIA OU CONDIÇÃO DE TÍTULO, GOZO SILENCIOSO, POSSE TRANQUILA, CORRESPONDÊNCIA À DESCRIÇÃO OU NON-INFRINGEMENT DE QUAISQUER DIREITOS DE PROPRIEDADE INTELECTUAL EM RELAÇÃO AO DOCUMENTO.

EM NENHUM CASO, A IBM OU A MICROSOFT SERÃO RESPONSABILIZADAS POR QUALQUER OUTRA PARTE PELO CUSTO DA COMPRA DE BENS OU SERVIÇOS SUBSTITUTOS, LUCROS PERDIDOS, PERDA DE USO, PERDA DE DADOS OU QUAISQUER DANOS INCIDENTAIS, CONSEQUENCIAIS, DIRETOS, INDIRETOS OU ESPECIAIS, SEJA SOB CONTRATO, TORT, GARANTIA OU DE OUTRA FORMA, DECORRENTES DE QUALQUER SAÍDA DESTE OU DE QUALQUER OUTRO CONTRATO RELACIONADO A ESTE DOCUMENTO, SE ESSA PARTE TINHA OU NÃO AVISO PRÉVIO SOBRE A POSSIBILIDADE DE TAIS DANOS.

Abstrair

Este documento descreve uma estratégia proposta para abordar a segurança em um ambiente de serviço Web. Ele define um modelo de segurança de serviço Web abrangente que dá suporte, integra e unifica vários modelos de segurança populares, mecanismos e tecnologias (incluindo tecnologias simétricas e de chave pública) de uma maneira que permite que uma variedade de sistemas interopere com segurança de maneira neutra em plataforma e linguagem. Ele também descreve um conjunto de especificações e cenários que mostram como essas especificações podem ser usadas em conjunto.

Resumo

O setor de TI fala sobre serviços Web há quase dois anos. Os benefícios de ter uma maneira livremente acoplada, neutra em linguagem e independente de plataforma de vincular aplicativos dentro de organizações, entre empresas e em toda a Internet estão se tornando mais evidentes à medida que os serviços Web são usados em programas piloto e em produção em larga escala. Seguindo em frente, nossos clientes, analistas do setor e a imprensa identificam uma área chave que precisa ser abordada à medida que os serviços Web se tornam mais comuns: segurança. Este documento propõe uma estratégia técnica e um roteiro pelo qual o setor pode produzir e implementar uma arquitetura baseada em padrões abrangente, mas flexível o suficiente para atender às necessidades de segurança dos serviços Web de negócios reais.

Um dos principais benefícios da arquitetura de serviços Web emergentes é a capacidade de fornecer soluções integradas e interoperáveis. Garantir a integridade, a confidencialidade e a segurança dos serviços Web por meio da aplicação de um modelo de segurança abrangente é fundamental, tanto para as organizações quanto para seus clientes.

Respondendo a preocupações expressas tanto de nossos clientes quanto do setor, a IBM e a Microsoft colaboraram neste plano de segurança de serviços Web proposto e roteiro para desenvolver um conjunto de especificações de Segurança do Serviço Web que abordam como fornecer proteção para mensagens trocadas em um ambiente de serviço Web.

Pela primeira vez, criamos um modelo de segurança que reúne tecnologias de segurança anteriormente incompatíveis, como infraestrutura de chave pública, Kerberos e outros. Em suma, essa não é uma estrutura idealizada, mas uma estrutura prática que pode nos permitir criar serviços Web seguros no mundo heterogêneo de TI no qual nossos clientes vivem hoje.

Neste documento, apresentamos um amplo conjunto de especificações que abrangem tecnologias de segurança, incluindo autenticação, autorização, privacidade, confiança, integridade, confidencialidade, canais de comunicação seguros, federação, delegação e auditoria em um amplo espectro de topologias de aplicativos e negócios. Essas especificações fornecem uma estrutura extensível, flexível e maximiza os investimentos existentes em infraestrutura de segurança. Essas especificações subsume e expandem as ideias expressas em especificações semelhantes propostas anteriormente pela IBM e pela Microsoft (ou seja, as especificações SOAP-Security, WS-Security e WS-License).

Aproveitando a extensibilidade natural que está no núcleo do modelo de serviços Web, as especificações se baseiam em tecnologias fundamentais como SOAP, WSDL, Assinaturas Digitais XML, Criptografia XML e SSL/TLS. Isso permite que provedores de serviços Web e solicitantes desenvolvam soluções que atendam aos requisitos de segurança individuais de seus aplicativos.

A IBM e a Microsoft pretendem trabalhar com clientes, parceiros e entidades de padrões para evoluir e aprimorar esse modelo de segurança em uma abordagem em fases. Estamos propagando esse esforço com a especificação de WS-Security. WS-Security define as principais instalações para proteger a integridade e a confidencialidade de uma mensagem, bem como mecanismos para associar declarações relacionadas à segurança com a mensagem. Embora WS-Security seja a base desse esforço, é apenas o começo e cooperaremos com o setor para produzir especificações adicionais que lidarão com questões de política, confiança e privacidade.

Para tornar os problemas e soluções discutidos neste documento o mais concreto possível, discutimos vários cenários que refletem aplicativos atuais e antecipados de serviços Web. Isso inclui processamento de firewall, privacidade, uso de clientes móveis e navegador, controle de acesso, delegação e auditoria.

Antecipamos preocupações sobre o que pode ser feito para garantir a interoperabilidade e a implementação consistente das várias especificações propostas. Para resolver isso, a IBM e a Microsoft trabalharão em estreita colaboração com organizações de padrões, a comunidade de desenvolvedores e com organizações do setor, como WS-I.org para desenvolver perfis e testes de interoperabilidade que fornecerão diretrizes aos fornecedores de ferramentas.

Este documento descreve uma solução abrangente e modular que, quando implementada, permitirá que os clientes criem serviços Web interoperáveis e seguros que aproveitam e expandem os investimentos existentes em infraestrutura de segurança, permitindo que eles aproveitem ao máximo os benefícios de integração e interoperabilidade que as tecnologias de serviço Web têm a oferecer.

1 Introdução e motivação

Fornecer um modelo abrangente de funções de segurança e componentes para serviços Web requer a integração de processos e tecnologias disponíveis no momento com os requisitos de segurança em evolução de aplicativos futuros. Ele exige a unificação de conceitos; requer soluções para problemas tecnológicos (mensagens seguras) e de negócios (política, risco, confiança) ; e, por fim, requer esforços coordenados por fornecedores de plataforma, desenvolvedores de aplicativos, provedores de rede e infraestrutura e clientes.

Unificar o intervalo de tecnologias de segurança disponíveis significa que os requisitos funcionais de segurança do aplicativo devem ser abstraídos de mecanismos específicos empregados. Por exemplo, um cliente que está fazendo uma compra online não deve ser afetado por estar usando um celular ou um computador laptop, desde que cada dispositivo possa expressar com segurança a identidade adequada.

O objetivo é permitir que os clientes criem facilmente soluções interoperáveis usando sistemas heterogêneos. Por exemplo, o modelo de mensagens segura proposto posteriormente neste documento dá suporte a mecanismos de identidade PKI (infraestrutura de chave pública) e Kerberos como personificações específicas de uma instalação mais geral e é capaz de ser estendido para dar suporte a mecanismos de segurança adicionais. A integração por meio das abstrações de um único modelo de segurança permite que as organizações usem seus investimentos existentes em tecnologias de segurança enquanto se comunicam com organizações usando tecnologias diferentes.

Além disso, à medida que as organizações que usam diferentes mecanismos de identidade colaboram usando serviços Web, o modelo de confiança de segurança fornece uma estrutura flexível na qual as organizações podem se interconectar quando configuradas com a autorização apropriada.

Ao mesmo tempo, cada cliente e cada serviço Web tem seus próprios requisitos de segurança exclusivos com base em suas necessidades comerciais específicas e ambiente operacional. Dentro das configurações do grupo de trabalho, por exemplo, a simplicidade e a facilidade de operações são uma grande preocupação, enquanto para aplicativos públicos da Internet a capacidade de suportar ataques concertados de negação de serviço é uma prioridade mais alta. Como esses requisitos podem ser combinados de várias maneiras e expressos em diferentes níveis de especificidade, uma abordagem bem-sucedida para a segurança do serviço Web requer um conjunto de primitivos de segurança flexíveis e interoperáveis que, por meio de política e configuração, permitem uma variedade de soluções seguras.

Para enfrentar esses desafios, este documento propõe uma abordagem evolutiva para criar serviços Web seguros e interoperáveis com base em um conjunto de abstrações de segurança que unificam tecnologias anteriormente diferentes. Isso permite a especialização para requisitos específicos do cliente em uma estrutura geral e, ao mesmo tempo, permite que as tecnologias evoluam ao longo do tempo e sejam implantadas incrementalmente.

Como exemplo dessa abordagem evolutiva, o modelo de mensagens seguras pode ser adicionado às soluções de segurança em nível de transporte existentes. Um cliente pode adicionar integridade no nível da mensagem ou confidencialidade persistente (criptografia de elementos de mensagem) a um serviço Web existente cujas mensagens são transmitidas, por exemplo, SSL/TLS (Secure Sockets Layer). As mensagens agora têm integridade (ou confidencialidade) que persiste além da camada de transporte.

Prevemos que o modelo e as especificações propostos que surgirem estarão amplamente disponíveis de vários fornecedores e serão considerados pelas organizações de padrões apropriadas. Juntos, o processo de modelo, especificações e padrões permite que as empresas aumentem de forma rápida e econômica a segurança de seus aplicativos existentes e desenvolvam com confiança novos serviços Web seguros e interoperáveis.

A vantagem comercial desse modelo é clara. Ao enquadrar uma arquitetura de segurança abrangente para serviços Web, organizações e clientes podem garantir melhor que seus investimentos e ativos sejam protegidos à medida que os processos de negócios se tornam cada vez mais reformulados como serviços Web.

Terminologia do modelo de segurança dos Serviços Web

Como a terminologia varia entre tecnologias, este documento define vários termos que podem ser aplicados consistentemente entre os diferentes formatos e mecanismos de segurança. Consequentemente, a terminologia usada aqui pode ser diferente de outras especificações e é definida para que o leitor possa mapear os termos para seu vocabulário preferido.

  • serviço Web— o termo "serviço Web" é amplamente aplicável a uma ampla variedade de topologias de aplicativo baseadas em rede. Neste documento, usamos o termo "serviço Web" para descrever componentes de aplicativo cuja funcionalidade e interfaces são expostas a usuários potenciais por meio da aplicação de padrões de tecnologia Web existentes e emergentes, incluindo XML, SOAP, WSDL e HTTP. Em contraste com sites da Web, interações baseadas em navegador ou tecnologias dependentes da plataforma, os serviços Web são serviços oferecidos de computador para computador, por meio de formatos e protocolos definidos, de maneira independente da plataforma e neutra em termos de linguagem.

  • token de segurança— definimos um token de segurança como uma representação de informações relacionadas à segurança (por exemplo, certificado X.509, tíquetes e autenticadores Kerberos, tokens de segurança de dispositivo móvel de cartões SIM, nome de usuário etc.).

    O diagrama a seguir mostra alguns dos diferentes tipos de tokens de segurança.

  • token de segurança assinado— Definimos um token de segurança assinado como um token de segurança que contém um conjunto de declarações relacionadas (declarações) endossadas criptograficamente por um emissor. Exemplos de tokens de segurança assinados incluem certificados X.509 e tíquetes Kerberos.

  • Declarações— Uma declaração é uma declaração sobre um assunto pelo assunto ou por outra parte que associa o assunto à declaração. Um ponto importante é que essa especificação não tenta limitar os tipos de declarações que podem ser feitas, nem tenta limitar como essas declarações podem ser expressas. As declarações podem ser sobre chaves potencialmente usadas para assinar ou criptografar mensagens. As declarações podem ser instruções que o token de segurança transmite. As declarações podem ser usadas, por exemplo, para afirmar a identidade dos remetentes ou uma função autorizada.

  • Entidade— o assunto do token de segurança é uma entidade de segurança (por exemplo, uma pessoa, um aplicativo ou uma entidade de negócios) sobre a qual as declarações expressas no token de segurança se aplicam. Especificamente, o assunto, como proprietário do token de segurança, possui informações necessárias para provar a propriedade do token de segurança.

  • de Prova de Posse — definimos de prova de posse para serem informações usadas no processo de comprovação de propriedade de um token de segurança ou conjunto de declarações. Por exemplo, a prova de posse pode ser a chave privada associada a um token de segurança que contém uma chave pública.

  • de Política de Ponto de Extremidade de Serviço Web — os serviços Web têm total flexibilidade na especificação das declarações necessárias para processar mensagens. Coletivamente, nos referimos a essas declarações necessárias e informações relacionadas como a "Política de Ponto de Extremidade de Serviço Web". As políticas de ponto de extremidade podem ser expressas em XML e podem ser usadas para indicar requisitos relacionados à autenticação (por exemplo, prova de identidade de usuário ou grupo), autorização (por exemplo, prova de determinados recursos de execução) ou outros requisitos personalizados.

  • requisitos de declaração— os requisitos de declaração podem ser vinculados a mensagens ou elementos inteiros de mensagens, a todas as ações de um determinado tipo ou a ações somente em determinadas circunstâncias. Por exemplo, um serviço pode exigir que um solicitante prove autoridade para valores de compra maiores que um limite declarado.

  • Intermediários— como as mensagens SOAP são enviadas de um solicitante inicial para um serviço, elas podem ser operadas por intermediários que executam ações como rotear a mensagem ou até mesmo modificar a mensagem. Por exemplo, um intermediário pode adicionar cabeçalhos, criptografar ou descriptografar partes da mensagem ou adicionar tokens de segurança adicionais. Nessas situações, deve-se tomar cuidado para que as alterações na mensagem não invalidem a integridade da mensagem, violem o modelo de confiança ou destruam a responsabilidade.

  • Actor— um de ator é um ponto de extremidade ou intermediário (conforme definido na especificação SOAP ) que é identificado por um URI e que processa uma mensagem SOAP. Observe que nem os usuários nem o software cliente (por exemplo, navegadores) são atores.

Princípios do modelo de segurança dos Serviços Web

Os serviços Web podem ser acessados enviando mensagens SOAP para pontos de extremidade de serviço identificados por URIs, solicitando ações específicas e recebendo respostas de mensagens SOAP (incluindo indicações de falha). Nesse contexto, o objetivo amplo de proteger os serviços Web divide as metas subsidiárias de fornecer instalações para proteger a integridade e a confidencialidade das mensagens e garantir que o serviço atue apenas em solicitações em mensagens que expressam as declarações exigidas pelas políticas.

Hoje, a camada de soquete seguro (SSL) juntamente com o TLS (Transport Layer Security) de fato é usado para fornecer segurança no nível de transporte para aplicativos de serviços Web. O SSL/TLS oferece vários recursos de segurança, incluindo autenticação, integridade de dados e confidencialidade de dados. O SSL/TLS permite sessões seguras ponto a ponto.

IPSec é outro padrão de camada de rede para segurança de transporte que pode se tornar importante para os serviços Web. Assim como o SSL/TLS, o IPSec também fornece sessões seguras com autenticação de host, integridade de dados e confidencialidade de dados.

As topologias de aplicativo de serviço Web de hoje incluem uma ampla combinação de dispositivos móveis, gateways, proxies, balanceadores de carga, DMZs (zonas desmilitarizadas), data centers terceirizados e sistemas globalmente distribuídos e configurados dinamicamente. Todos esses sistemas dependem da capacidade de intermediários de processamento de mensagens encaminharem mensagens. Especificamente, o modelo de mensagem SOAP opera em pontos de extremidade lógicos que abstraem a rede física e a infraestrutura do aplicativo e, portanto, incorpora frequentemente uma topologia de vários saltos com atores intermediários.

Quando os dados são recebidos e encaminhados por um intermediário além da camada de transporte, a integridade dos dados e quaisquer informações de segurança que fluam com ele talvez tenham sido perdidas. Isso força todos os processadores de mensagens upstream a depender das avaliações de segurança feitas por intermediários anteriores e confiar completamente no tratamento do conteúdo das mensagens. O que é necessário em uma arquitetura de segurança de serviço Web abrangente é um mecanismo que fornece segurança de ponta a ponta. Soluções de segurança de serviço Web bem-sucedidas poderão aproveitar os mecanismos de segurança de camada de aplicativo e transporte para fornecer um conjunto abrangente de recursos de segurança.

de configuração ponto a ponto

de configuração de ponta a ponta

O modelo de segurança do serviço Web descrito aqui nos permite atingir essas metas por um processo no qual:

  • Um serviço Web pode exigir que uma mensagem de entrada prove um conjunto de declarações (por exemplo, nome, chave, permissão, funcionalidade etc.). Se uma mensagem chegar sem ter as declarações necessárias, o serviço poderá ignorar ou rejeitar a mensagem. Nos referimos ao conjunto de declarações necessárias e informações relacionadas como de política.
  • Um solicitante pode enviar mensagens com a prova das declarações necessárias associando tokens de segurança com as mensagens. Assim, as mensagens exigem uma ação específica e provam que o remetente tem a declaração para exigir a ação.
  • Quando um solicitante não tem as declarações necessárias, o solicitante ou alguém em seu nome pode tentar obter as declarações necessárias entrando em contato com outros serviços Web. Esses outros serviços Web, que chamamos de serviços de token de segurança, podem, por sua vez, exigir seu próprio conjunto de declarações. Confiança do agente de serviços de token de segurança entre diferentes domínios de confiança, emitindo tokens de segurança.

Esse modelo é ilustrado na figura abaixo, mostrando que qualquer solicitante também pode ser um serviço e que o Serviço de Token de Segurança também pode ser totalmente um serviço Web, incluindo expressar a política e exigir tokens de segurança.

Esse modelo geral de mensagens — declarações, políticas e tokens de segurança — subsume e dá suporte a vários modelos mais específicos, como segurança baseada em identidade, listas de controle de acesso e segurança baseada em recursos. Ele permite o uso de tecnologias existentes, como certificados de chave pública X.509, tíquetes de segredo compartilhado Kerberos e até resumos de senha. Como discutiremos mais tarde, ele também fornece uma abstração de integração que permite que os sistemas criem uma ponte entre diferentes tecnologias de segurança. O modelo geral é suficiente para construir mecanismos de troca, autenticação, autorização, auditoria e confiança de nível superior.

2 Especificações de segurança dos Serviços Web

A estratégia de segurança expressa aqui e a especificação de do WS-Security introduzida abaixo fornecem as metas estratégicas e a base para esse modelo de segurança de serviços Web proposto.

Seguindo em frente, continuamos o processo de trabalhar com clientes, parceiros e organizações padrões para desenvolver um conjunto inicial de especificações de segurança do serviço Web.

Esse conjunto incluirá um modelo de segurança de mensagem (WS-Security) que fornece a base para as outras especificações de segurança. Sobre isso, temos uma camada de política que inclui uma política de ponto de extremidade de serviço Web (WS-Policy), um modelo de confiança (WS-Trust) e um modelo de privacidade (WS-Privacy). Juntos, essas especificações iniciais fornecem a base sobre a qual podemos trabalhar para estabelecer serviços Web interoperáveis seguros em domínios confiáveis.

Com base nessas especificações iniciais, continuaremos a trabalhar com clientes, parceiros e organizações padrões para fornecer especificações de acompanhamento para segurança federada que incluem conversas seguras (WS-SecureConversation), confiança federada (WS-Federation) e autorização (WS-Authorization).

A combinação dessas especificações de segurança permite muitos cenários (alguns dos quais são descritos posteriormente neste documento) que são difíceis de implementar com os mecanismos de segurança mais básicos de hoje.

Em paralelo, vamos propor e avançar com atividades relacionadas que aprimoram a estrutura de segurança dos serviços Web com especificações relacionadas à auditoria, gerenciamento e privacidade.

Além disso, a IBM e a Microsoft estão comprometidas em trabalhar com organizações como WS-I em perfis de interoperabilidade.

A combinação de especificações de segurança, atividades relacionadas e perfis de interoperabilidade permitirá que os clientes criem facilmente serviços Web seguros interoperáveis.

Cada uma das especificações propostas é resumida abaixo:

especificações iniciais

  • WS-Security: descreve como anexar cabeçalhos de assinatura e criptografia a mensagens SOAP. Além disso, descreve como anexar tokens de segurança, incluindo tokens de segurança binários, como certificados X.509 e tíquetes Kerberos, a mensagens.
  • WS-Policy: descreverá os recursos e restrições das políticas de segurança (e outras empresas) em intermediários e pontos de extremidade (por exemplo, tokens de segurança necessários, algoritmos de criptografia compatíveis, regras de privacidade).
  • WS-Trust: descreverá uma estrutura para modelos de confiança que permite que os serviços Web interoperem com segurança.
  • WS-Privacy: descreverá um modelo de como serviços Web e solicitantes declaram preferências de privacidade e declarações de prática de privacidade organizacional.

especificações de Follow-On

  • WS-SecureConversation: descreverá como gerenciar e autenticar trocas de mensagens entre partes, incluindo troca de contexto de segurança e estabelecer e derivar chaves de sessão.
  • WS-Federation: descreverá como gerenciar e intermediar as relações de confiança em um ambiente federado heterogêneo, incluindo suporte para identidades federadas.
  • Autorização do WS: descreverá como gerenciar dados de autorização e políticas de autorização.

Fornecer segurança para WS-Security requer a devida diligência na produção das descrições, especificação e perfis em várias áreas funcionais. Esses documentos mudarão e evoluirão por meio de um processo que equilibra as necessidades dos clientes com as necessidades da comunidade de desenvolvimento de serviços Web e nosso próprio processo educacional à medida que passamos pelo processo de especificação.

WS-Security

WS-Security descreve melhorias no sistema de mensagens SOAP para fornecer qualidade de proteção por meio da integridade da mensagem e da confidencialidade da mensagem. Além disso, essa especificação define como anexar e incluir tokens de segurança em mensagens SOAP. Por fim, um mecanismo é fornecido para especificar tokens de segurança codificados binários (por exemplo, certificados X.509). Esses mecanismos podem ser usados independentemente ou em combinação para acomodar uma ampla variedade de modelos de segurança e tecnologias de criptografia.

WS-Security fornece um mecanismo de uso geral para associar tokens de segurança a mensagens. Nenhum tipo específico de token de segurança é exigido por WS-Security. Ele foi projetado para ser extensível (por exemplo, dar suporte a vários formatos de token de segurança). Por exemplo, um solicitante pode fornecer uma prova de identidade e prova de que ele tem uma certificação comercial específica.

A integridade da mensagem é fornecida aproveitando assinatura XML em conjunto com tokens de segurança (que podem conter ou implicar dados de chave) para garantir que as mensagens sejam transmitidas sem modificações. Os mecanismos de integridade são projetados para dar suporte a várias assinaturas, potencialmente por vários atores, e para serem extensíveis para dar suporte a formatos de assinatura adicionais. As assinaturas podem referenciar (ou seja, apontar para) um token de segurança.

Da mesma forma, a confidencialidade da mensagem é fornecida aproveitando de Criptografia XML em conjunto com tokens de segurança para manter partes de mensagens SOAP confidenciais. Os mecanismos de criptografia são projetados para dar suporte a tecnologias, processos e operações de criptografia adicionais por vários atores. A criptografia também pode fazer referência a um token de segurança.

Por fim, WS-Security descreve um mecanismo para codificar tokens de segurança binária. Especificamente, a especificação descreve como codificar certificados X.509 e tíquetes Kerberos, bem como como incluir chaves criptografadas opacas. Ele também inclui mecanismos de extensibilidade que podem ser usados para descrever ainda mais as características dos tokens de segurança incluídos em uma mensagem.

WS-Policy

WS-Policy descreverá como remetentes e receptores podem especificar seus requisitos e recursos.

WS-Policy será totalmente extensível e não colocará limites nos tipos de requisitos e recursos que podem ser descritos; no entanto, a especificação provavelmente identificará vários atributos de serviço básicos, incluindo atributos de privacidade, formatos de codificação, requisitos de token de segurança e algoritmos com suporte.

Essa especificação definirá um formato de política SOAP genérico, que pode dar suporte a mais do que apenas políticas de segurança. Essa especificação também definirá um mecanismo para anexar ou associar políticas de serviço a mensagens SOAP.

WS-Trust

WS-Trust descreverá o modelo para estabelecer relações de confiança diretas e intermediadas (incluindo terceiros e intermediários).

Essa especificação descreverá como as relações de confiança direta existentes podem ser usadas como base para intermediar a confiança por meio da criação de serviços de emissão de token de segurança. Esses serviços de emissão de token de segurança se baseiam em WS-Security para transferir os tokens de segurança necessários de uma maneira que garanta a integridade e a confidencialidade desses tokens.

Em seguida, essa especificação descreverá como vários mecanismos de confiança existentes podem ser usados em conjunto com esse modelo de confiança.

Por fim, o modelo de confiança permitirá explicitamente, mas não exigirá, delegação e representação por entidades de segurança. Observe que a delegação é consistente com a representação, mas fornece níveis adicionais de rastreabilidade.

WS-Privacy

As organizações que criam, gerenciam e usam serviços Web geralmente precisam declarar suas políticas de privacidade e exigem que as solicitações de entrada façam declarações sobre a adesão dos remetentes a essas políticas.

Usando uma combinação de WS-Policy, WS-Security e WS-Trust, as organizações podem declarar e indicar conformidade com as políticas de privacidade declaradas. Essa especificação descreverá um modelo de como uma linguagem de privacidade pode ser inserida em descrições WS-Policy e como WS-Security pode ser usado para associar declarações de privacidade a uma mensagem. Por fim, essa especificação descreverá como mecanismos de WS-Trust podem ser usados para avaliar essas declarações de privacidade para preferências do usuário e declarações de prática organizacional.

WS-SecureConversation

WS-SecureConversation descreverá como um serviço Web pode autenticar mensagens solicitantes, como os solicitantes podem autenticar serviços e como estabelecer contextos de segurança mutuamente autenticados.

Essa especificação descreverá como estabelecer chaves de sessão, chaves derivadas e chaves por mensagem.

Por fim, essa especificação descreverá como um serviço pode trocar com segurança o contexto (coleções de declarações sobre atributos de segurança e dados relacionados). Para fazer isso, a especificação descreverá e se baseará nos conceitos de mecanismos de emissão e troca de token de segurança definidos em WS-Security e WS-Trust. Usando esses mecanismos, um serviço pode, por exemplo, dar suporte a tokens de segurança usando tecnologia de chave simétrica fraca, bem como emitir tokens de segurança mais fortes usando chaves não compartilhadas (assimétricas).

WS-SecureConversation foi projetado para operar na camada de mensagem SOAP para que as mensagens possam percorrer uma variedade de transportes e intermediários. Isso não impede seu uso em outras estruturas de mensagens. Para aumentar ainda mais a segurança dos sistemas, a segurança em nível de transporte pode ser usada em conjunto com WS-Security e WS-SecureConversation entre links selecionados.

WS-Federation

Essa especificação definirá como construir cenários federados de confiança usando as especificações WS-Security, WS-Policy, WS-Trust e WS-SecureConversation. Por exemplo, ele descreverá como federar infraestruturas Kerberos e PKI (conforme descrito nos cenários abaixo).

Além disso, uma política de confiança é introduzida para indicar e restringir e identificar o tipo de confiança que está sendo intermediado.

Essa especificação também definirá mecanismos para gerenciar as relações de confiança.

WS-Authorization

Essa especificação descreverá como as políticas de acesso para um serviço Web são especificadas e gerenciadas. Em particular, ele descreverá como as declarações podem ser especificadas em tokens de segurança e como essas declarações serão interpretadas no ponto de extremidade.

Essa especificação será projetada para ser flexível e extensível em relação ao formato de autorização e à linguagem de autorização. Isso permite a maior variedade de cenários e garante a viabilidade de longo prazo da estrutura de segurança.

3 Relacionando a segurança dos serviços Web aos modelos de segurança atuais

Esse modelo de segurança de serviços Web é compatível com os modelos de segurança existentes para autenticação, integridade de dados e confidencialidade de dados em uso comum atualmente. Como consequência, é possível integrar soluções baseadas em serviços Web a outros modelos de segurança existentes:

  • de Segurança de Transporte — tecnologias existentes, como soquetes seguros (SSL/TLS), podem fornecer integridade e confidencialidade ponto a ponto simples para uma mensagem. O modelo de segurança dos Serviços Web dá suporte ao uso desses mecanismos de transporte seguro existentes em conjunto com WS-Security (e outras especificações) para fornecer integridade de ponta a ponta e confidencialmente, em particular em vários transportes, intermediários e protocolos de transmissão.
  • PKI — Em um alto nível, o modelo PKI envolve autoridades de certificação que emitem certificados com chaves assimétricas públicas e autoridades que declaram propriedades diferentes da propriedade de chave (por exemplo, autoridades de atributo). Os proprietários desses certificados podem usar as chaves associadas para expressar uma variedade de declarações, incluindo identidade. O modelo de segurança dos serviços Web dá suporte aos serviços de token de segurança que emitem tokens de segurança usando chaves assimétricas públicas. A PKI é usada aqui no sentido mais amplo e não assume nenhuma hierarquia ou modelo específico.
  • kerberos— o modelo Kerberos depende da comunicação com o KDC (Centro de Distribuição de Chaves) para intermediar a confiança entre as partes, emitindo chaves simétricas criptografadas para ambas as partes e "introduzindo" umas às outras. O modelo de serviços Web, novamente, baseia-se no modelo principal com serviços de token de segurança intermediando a confiança emitindo tokens de segurança com chaves simétricas criptografadas e testamentos criptografados.

Observe que, embora os modelos sejam compatíveis, para garantir a interoperabilidade, os adaptadores e/ou algoritmos comuns para assinaturas e criptografia precisarão ser acordados ou desenvolvidos.

Modelos existentes para federação, autorização (incluindo delegação), privacidade e confiança são menos comuns e mais ad hoc. As especificações para lidar com essas propriedades de segurança são identificadas nas fases posteriores da estratégia.

Muitas vezes, os modelos de confiança existentes são baseados em contratos comerciais. Um exemplo disso é o serviço Web UDDI. Na UDDI, há vários participantes que fornecem um Registro De Negócios Universal por meio de um contrato para dar suporte a um conjunto de APIs. Em vez de definir um único modelo de "confiança" por meio da exigência de um mecanismo de autenticação específico, o "modelo de confiança" na UDDI dá a responsabilidade de autenticação ao nó, que é o guardião das informações. Ou seja, cada implementação do serviço Web UDDI tem seu próprio mecanismo de autenticação e impõe sua própria política de controle de acesso. A "confiança" é entre operadores e entre o solicitante e o operador que é o guardião de suas informações.

4 cenários

Abaixo, apresentamos uma série de cenários que exemplificam como imaginamos as especificações de segurança do Serviço Web propostas sendo usadas. Esses cenários são intencionalmente focados nos detalhes técnicos para ilustrar os recursos da estratégia de segurança geral. Haverá documentação complementar que fornece cenários detalhados de uso de negócios.

As empresas de exemplo, organizações, produtos, nomes de domínio, endereços de email, logotipos, pessoas, locais e eventos descritos aqui são fictícios. Nenhuma associação com qualquer empresa real, organização, produto, nome de domínio, endereço de email, logotipo, pessoa, locais ou eventos é pretendida ou deve ser inferida.

A lista abaixo apresenta brevemente alguns dos cenários que podem ser compatíveis com as especificações iniciais propostas e as entregas associadas:

  • Confiança Direta usando nome de usuário/senha e segurança de Transport-Level — este cenário ilustra a autenticação usando um nome de usuário e senha com segurança de transporte.
  • Confiança Direta usando Tokens de Segurança — esse cenário ilustra a confiança direta usando a certificação X.509 e os Tíquetes de serviço Kerberos (ST).
  • Aquisição de token de segurança — esse cenário ilustra a autenticação usando um token de segurança armazenado independentemente da mensagem.
  • Processamento de firewall — esse cenário ilustra como os firewalls podem aproveitar esse modelo de segurança para obter mais graus de controle.
  • Token de segurança emitido — este cenário ilustra a autenticação básica.
  • Imposição de Política de Negócios — esse cenário ilustra como usar a emissão de token de segurança para codificar processos de negócios.
  • Privacidade — Este cenário ilustra como clientes e serviços podem comunicar suas políticas de privacidade.
  • Clientes Web — Esse cenário ilustra o uso de um navegador da Web como um cliente.
  • Clientes móveis — esse cenário ilustra como os clientes móveis podem interagir com segurança com os serviços Web.

O segundo conjunto de cenários é mais sofisticado. Esses cenários podem ser criados com base nas entregas atuais, mas precisam de especificações de acompanhamento (como WS-SecureConversation) para tornar a interoperabilidade perfeita.

  • Habilitando a Federação — esta seção descreve vários cenários diferentes envolvendo confiança federada.
  • Serviço de Validação: descreve como usar um serviço que valida a segurança de uma mensagem (por exemplo, assinatura).
  • Delegação de suporte — isso ilustra como usar tokens de segurança para delegação.
  • Controle de acesso — isso ilustra como a segurança dos serviços Web dá suporte à segurança tradicional baseada em lista de controle de acesso.
  • Auditoria — isso ilustra o uso da auditoria para controlar atividades e incidentes relacionados à segurança.

Observe que, nas descrições abaixo, o uso do solicitante de termos é usado para descrever a ampla variedade de usuários potenciais de um Serviço Web e não se destina a limitar as características do solicitante. Os solicitantes podem incluir entidades comerciais interagindo com um serviço em um ambiente B2B ou indivíduos acessando serviços de um navegador ou dispositivo móvel.

Confiança Direta usando nome de usuário/senha e segurança de Transport-Level

Aqui está um exemplo muito básico mostrando como a Segurança dos serviços Web pode ser usada com os mecanismos de segurança de transporte existentes:

O solicitante abre uma conexão com o serviço Web usando um transporte seguro (por exemplo, SSL/TLS). Ele envia sua solicitação e inclui um token de segurança que contém seu nome de usuário e senha. O serviço autentica as informações, processa a solicitação e retorna o resultado.

Nesse cenário, a confidencialidade e a integridade da mensagem são tratadas usando mecanismos de segurança de transporte existentes.

Esse cenário pressupõe que as duas partes já usaram algum mecanismo para estabelecer um segredo compartilhado: a senha do solicitante. Nenhuma suposição é feita sobre a relação organizacional entre essas partes.

Confiança Direta usando Tokens de Segurança

Esse cenário ilustra o uso de um token de segurança que é diretamente confiável por um serviço Web. Aqui, a confiança direta significa que o token de segurança do solicitante (ou sua autoridade de assinatura) é conhecido e confiável pelo serviço Web. Esse cenário pressupõe que as duas partes tenham usado algum mecanismo para estabelecer uma relação de confiança para o uso do token de segurança. Essa confiança pode ser estabelecida manualmente, configurando o aplicativo ou usando um transporte seguro para trocar chaves. Por transporte seguro de chaves, queremos dizer que um transporte como SSL (ou outro mecanismo ou processo) pode ser usado como uma maneira de uma parte confiável afirmar a validade de uma chave ou token de segurança para uma parte do destinatário. Nenhuma suposição é feita sobre a relação organizacional entre as partes.

O solicitante envia uma mensagem para um serviço e inclui um token de segurança assinado e fornece prova de posse do token de segurança usando, por exemplo, uma assinatura. O serviço verifica a prova e avalia o token de segurança. A assinatura no token de segurança é válida e é diretamente confiável pelo serviço. O serviço processa a solicitação e retorna um resultado.

A confiança direta pressupõe que as políticas de privacidade sejam bem compreendidas pelas partes envolvidas.

Aquisição de token de segurança

Em alguns casos, o token de segurança usado não é passado como parte da mensagem. Em vez disso, uma referência de token de segurança é fornecida que pode ser usada para localizar e adquirir o token.

O solicitante emite uma solicitação para o serviço e inclui uma referência ao token de segurança e fornece prova de posse. O serviço Web usa as informações fornecidas para obter o token de segurança do serviço de repositório de tokens e validar a prova. O serviço Web confia (observe que a confiança foi estabelecida fora da semântica da mensagem) o token de segurança, de modo que a solicitação é processada e a resposta é retornada.

Processamento de firewall

Os firewalls continuam sendo um componente crítico da arquitetura de segurança dos serviços Web. Eles devem ser capazes de continuar a impor regras de processamento de limites.

Conforme mostrado abaixo, o firewall examina as mensagens SOAP de entrada e só permite que elas de solicitantes "autorizados" penetram no firewall.

Nesse cenário, temos dois solicitantes enviando mensagens para um serviço Web dentro de um firewall. O firewall examina as mensagens para determinar se o solicitante está "autorizado" a enviar mensagens para o serviço Web especificado dentro do firewall.

Nesse cenário, o firewall toma essa decisão examinando o token de segurança usado para assinar a mensagem. Se a assinatura for válida e a autoridade de assinatura do token de segurança for confiável para autorizar mensagens no firewall, e o token indicar que ele autoriza mensagens no firewall, a mensagem será permitida; caso contrário, ele será rejeitado. Em alguns casos, uma assinatura pode referenciar especificamente o firewall como um ator SOAP.

Em outros cenários, o firewall também pode atuar como uma autoridade de emissão de token de segurança e permitir apenas mensagens que incluem a prova de posse de um token de segurança emitido pelo firewall.

Token de segurança emitido

Aqui está um exemplo mostrando como a Segurança dos serviços Web dá suporte à autenticação simples por uma parte confiável:

Nas duas primeiras etapas, o solicitante se comunica com uma autoridade de certificação para obter um token de segurança, especificamente uma declaração assinada de declarações atestando a identidade do solicitante.

O solicitante obteve um token de segurança porque o serviço Web tem uma política que exige que um token de segurança do tipo apropriado seja necessário (nesse caso, prova de identidade).

Em seguida, o solicitante envia uma mensagem, com o token de segurança e uma prova de posse anexada à mensagem (pense autenticador ou desafio assinado), para o serviço Web e recebe uma resposta.

Observe que, na descrição acima, a operação do serviço de certificação de identidade não foi descrita em detalhes. Para obter um token de segurança de identidade, os solicitantes podem usar protocolos de segurança existentes ou podem aproveitar as especificações de segurança dos serviços Web.

Se assumirmos que o solicitante está usando as especificações de segurança dos serviços Web, o sistema operará da seguinte maneira: o serviço de identidade descreve seus requisitos em uma política e o solicitante poderá solicitar um token de segurança junto com sua prova de identidade.

Observe que o serviço de identidade é apenas um serviço de token de segurança. Além disso, a simetria dos serviços Web permite que qualquer serviço Web também encapsule um serviço de token de segurança.

Por fim, observe que os serviços Web podem obter tokens de segurança em nome do solicitante (de um serviço de token de segurança) e devolvê-los ao solicitante para uso em mensagens subsequentes.

Impondo a política de negócios

Em muitos processos empresariais, há políticas específicas que devem ser impostas. Por exemplo, um serviço pode exigir que os consumidores tenham uma determinada classificação ou posição com uma empresa de auditoria específica. Com os serviços Web, muitas dessas políticas podem ser codificadas e validadas automaticamente, simplificando o processo geral.

Considere o seguinte exemplo:

A Concessionária Nicholas tem um serviço Web que usa para interagir com seus fornecedores de peças. No entanto, eles só querem lidar com fornecedores cujas peças são certificadas pelo fabricante.

Uma empresa de peças, Joshua's Parts, iria até o fabricante e apresentaria (e provaria) seu token de segurança de identidade (por exemplo, o Serviço de Token de Segurança ilustrado) e solicitaria um token de segurança do fabricante informando que eles são um revendedor de peças certificado (supondo que eles sejam certificados e em boa posição). As Partes de Joshua podem entrar em contato com a Concessionária nicholas e fornecer (e provar) ambos os tokens de segurança.

Se a Concessionária nicholas codificou sua política de negócios na política de serviço, o ônus da conformidade da política pode ser carregado antecipadamente para a empresa de peças (por exemplo, Joshua's Parts).

A política de serviço também pode especificar restrições sobre quais informações o fabricante teria permissão para armazenar para garantir a conformidade com a política de privacidade.

Privacidade

A privacidade inclui um amplo conjunto de preocupações e precisará ser contabilizado em cada uma das especificações que emergem dessa estratégia.

Os problemas básicos de privacidade serão resolvidos fornecendo declarações de privacidade dentro da política de serviço. Cenários mais sofisticados, envolvendo delegação e autorização, serão abordados em especificações específicas para esses cenários.

Por exemplo, um indivíduo declara um conjunto de "preferências de privacidade" que descrevem o que o indivíduo faz ou não quer permitir que aplicativos que atuam em nome dos indivíduos façam com as informações pessoais. Um aplicativo de calendário, trabalhando em nome dos indivíduos, agora pode acessar um serviço de calendário que usa um conjunto de "regras de prática de privacidade", para tomar instruções e decisões sobre uso e divulgação de informações pessoalmente. O serviço de calendário toma a decisão combinando as regras de prática de privacidade com as preferências de privacidade para determinar se um uso ou divulgação proposto é permitido.

Clientes Web

Considere um exemplo em que temos um cliente Web se comunicando com um aplicativo Web de camada intermediária que, por sua vez, está falando (com segurança) para um serviço Web em outro domínio. O aplicativo Web de camada intermediária, que tem reconhecimento de serviços Web, deseja obter um token de segurança para o cliente Web.

Além disso, esse cenário pressupõe que o token de segurança permite que o aplicativo de camada intermediária atue em nome do cliente quando ele fala com o serviço.

Para habilitar esse cenário, o navegador do cliente Web acessa o aplicativo de camada intermediária e é redirecionado para um serviço de identidade associado. Uma vez autenticada (por exemplo, usando um formulário HTML e https), a solicitação é redirecionada de volta para o aplicativo de camada intermediária. O serviço de identidade fornece um token de segurança (afirmando a identidade e as delegações) para o servidor Web de aplicativo de camada intermediária original (por exemplo, usando uma cadeia de caracteres de consulta enviada via HTTPS). O servidor Web agora pode usar esses tokens de segurança e emitir solicitações de sua própria identidade para o serviço Web. O serviço Web processa as solicitações e retorna os resultados para o servidor Web, onde os resultados são formatados e retornados para o navegador.

Clientes móveis

As especificações descritas neste documento acima fornecem flexibilidade substancial para lidar com os desafios de design exclusivos da segurança móvel.  A flexibilidade da abordagem de serviços Web permite suporte para várias tecnologias criptográficas que fornecem proteção criptográfica forte e de alto desempenho em dispositivos com recursos de computação e armazenamento limitados.  Da mesma forma, permite que os operadores de rede forneçam proxies de segurança, como gateways de rede, para agir em nome dos clientes móveis. 

Veja a seguir um exemplo combinando essas duas ideias.  Quando um operador de rede dá suporte a clientes móveis (usando essas especificações de segurança de serviço Web), ele pode configurar esses clientes para enviar solicitações por meio do gateway do operador de rede.  Nesse cenário, o gateway é um intermediário SOAP que participa ativamente do fluxo geral de mensagens; especificamente, o operador de rede está fornecendo um algoritmo de criptografia de adição de valor projetado para dispositivos móveis.  O gateway pode aumentar ou alterar os tokens de segurança e a qualidade da proteção da mensagem.  Observe que a flexibilidade inerente a esse modelo de segurança de serviços Web permite essa solução mesmo quando o dispositivo está em roaming em uma rede estrangeira. 

Isso é ilustrado no exemplo abaixo:

Habilitando a federação

O modelo de Segurança dos serviços Web foi projetado para dar suporte à federação. Aqui está um exemplo simples de federação de identidade:

Alice, da Adventure456, deseja usar o serviço Web moeda no Business456. O serviço Moeda processará apenas solicitações com um token de segurança emitido pelo Business456. Alice tem apenas um token de segurança com declarações de identidade (ou seja, um token de segurança de identidade) emitido pela Adventure456.

Nesse cenário, Alice só poderá acessar o serviço Moeda se o Business456 estiver disposto a aceitar a federação de segurança com Adventure456.

As subseções a seguir descrevem várias abordagens para a federação de segurança.

Federação usando a Troca de Tokens de Segurança

Nessa abordagem, a política do serviço moeda afirma que ele aceita apenas tokens de segurança emitidos pelo Business456. Como a política indica onde obter o token de segurança necessário, Alice apresenta (e prova) seu token de segurança Adventure456 para o serviço de token de segurança Business456 e recebe um token de segurança Business456. Em seguida, ela apresenta (e prova) esse token de segurança em solicitações para o serviço Moeda. Isso é ilustrado no diagrama abaixo:

Nessa abordagem, o serviço de token de segurança Business456 foi configurado para aceitar tokens de segurança com declarações de identidade emitidas pela Adventure456

Deve-se observar que este exemplo é muito semelhante ao exemplo no cenário de Política de Negócios de Imposição. Isso demonstra a flexibilidade do modelo de segurança do serviço Web.

Federação usando encadeamento de confiança

Nessa abordagem, o serviço Moeda aceitará uma solicitação com qualquer token de segurança, mas não processará a solicitação, a menos que possa obter um token de segurança Business456 com base no token de segurança fornecido (e na prova).

Para fazer isso, o serviço Moeda encaminha a solicitação original para o serviço de token de segurança Business456, que avalia o token de segurança inicial. Se for válido, ele endossará a solicitação e poderá incluir um token de segurança Business456 para Alice usar em solicitações subsequentes. Isso é ilustrado na figura abaixo.

Nessa abordagem, o serviço de token de segurança Business456 foi configurado para aceitar tokens de segurança com declarações de identidade emitidas pela Adventure456

Federação usando a Troca de Tokens de Segurança (PKIKerberos)

Nesta abordagem, a Adventure456 emitiu a Alice um token de segurança de chave pública e a política do serviço moeda indica que ele aceita apenas tokens de segurança Kerberos de seu KDC.

Na direção da política do serviço moeda, Alice apresenta (e prova) seu token de segurança de chave pública para o serviço de token de segurança do Business456. O serviço de token de segurança encapsula o KDC do Business456. Como resultado, ele é capaz de validar o token de segurança de chave pública de Alice e emite um token de segurança Kerberos para o serviço Currency. Isso é ilustrado na figura abaixo:

Nessa abordagem, o serviço de token de segurança Business456 foi configurado para aceitar tokens de segurança de chave pública com declarações de identidade emitidas pela Adventure456.

Federação usando a Troca de Tokens de Segurança (Serviço de Token KerberosSecurity)

Nessa abordagem, a Adventure456 emitiu a Alice um token de segurança Kerberos e a política do serviço Moeda indica que ele aceita apenas tokens de segurança emitidos por seu próprio serviço de token de segurança.

Aqui, presumimos que os administradores da Adventure456 e do Business456 trocaram certificados de chave pública para federar a segurança. Presumimos ainda que Alice só dá suporte à tecnologia de chave simétrica.

Com base na política de serviço Web de moeda, Alice precisa adquirir um token de segurança que possa ser usado para acessar o serviço de token de segurança no Business456. Como Alice está usando tokens de segurança de chave simétrica, Alice entra em contato primeiro com seu serviço de token de segurança para adquirir um token de segurança destinado ao serviço de token de segurança Business456. Observe que esse token de segurança conterá uma chave simétrica, Sab, codificada com a chave pública do serviço de token de segurança Business456.

Usando o token de segurança destinado ao serviço de token de segurança Business456, Alice solicita um token de segurança para o serviço Moeda. O serviço de token de segurança Business456 fornece a Alice uma chave simétrica, Sac e um token de segurança para o serviço Moeda.

Usando o token de segurança destinado ao serviço Moeda e à chave simétrica associada, Alice faz solicitações ao serviço Moeda.

Federação usando o Exchange de Credenciais (KerberosKerberos)

Nesta abordagem, a Adventure456 emitiu a Alice um token de segurança Kerberos e a política do serviço Moeda indica que ele aceita apenas tokens de segurança Kerberos emitidos por seu próprio serviço de token de segurança que encapsula seu KDC.

Aqui, presumimos que os administradores da Adventure456 e business456 não desejam estabelecer confiança transitiva entre realm, mas estão dispostos a trocar certificados de chave pública para federar a segurança. Além disso, presumimos que tanto Alice quanto o serviço Moeda dão suporte apenas à tecnologia de chave simétrica.

Como no exemplo anterior, os serviços de token de segurança têm a capacidade de fornecer tokens de segurança de chave simétrica aos serviços dentro de seu domínio de confiança. Como consequência, a abordagem descrita acima funciona nesse cenário.

Serviço de Validação

Esse modelo de Segurança de serviços Web também dá suporte a cenários em que o solicitante terceiriza o processamento da validação de token de segurança e mensagem. Deve-se observar que o uso indevido desse serviço pode causar problemas de escalabilidade. Ou seja, dependendo da implementação, pode ser mais barato ou mais caro para o serviço executar o serviço de validação. O modelo de segurança dos serviços Web dá suporte a qualquer abordagem, permitindo esse cenário.

Nesse cenário, separamos o serviço de validação do serviço de token de segurança. Em outros cenários, eles podem ser combinados ou ter uma relação de confiança direta (portanto, não exigindo WS-Federation).

Nesse cenário, o solicitante obtém um token de segurança do Serviço de Token de Segurança. Em seguida, ele envia uma mensagem para o serviço Web e inclui prova de posse (por exemplo, uma assinatura). O serviço Web envia o bloco de assinatura, o token de segurança e sua computação do resumo que foi assinado para o serviço de validação. O serviço de validação, que é confiável pelo serviço Web, emite uma decisão válida/inválida.

Deve-se observar que o serviço de validação pode indicar sua decisão emitindo um token de segurança em nome do solicitante que declara as declarações apropriadas.

Delegação de suporte

A segurança dos serviços Web dá suporte à delegação. Aqui está um cenário de delegação sofisticado projetado para mostrar a flexibilidade da abordagem: Alice usa calendar456 para gerenciar sua agenda. Ela quer permitir que Bob tenha uma reunião com ela na terça-feira. No entanto, Bob não faz o agendamento diretamente. Em vez disso, Bob usa o serviço, schedule456, para configurar reuniões que precisam ser colocadas no calendário de Alice.

Alice não sabe como Bob vai agendar a reunião, mas ela quer limitar o conjunto de serviços que podem ver seu calendário

Alice fornece a Bob um token de segurança que permite a Bob agendar reuniões em seu calendário. Esse token de segurança contém declarações que restringem a capacidade de Bob de agendar reuniões para terça-feira. Além disso, esse token de segurança permite que Bob emita tokens de segurança subsequentes, desde que os sujeitos possam provar que têm uma certificação de privacidade do TrustUs456, um serviço de terceiros.

Desde que o serviço Schedule456 foi auditado pelo TrustUs456, eles têm um token de segurança que declara sua certificação de privacidade.

Quando o serviço de agendamento acessa o calendário de Alice no Calendar456, ele pode provar a prova de posse de sua certificação de privacidade e sua declaração de acessar e agendar uma reunião com base nos tokens de segurança de Alice, por meio de Bob, para si mesma.

Controle de acesso

Enquanto trabalham juntos, Alice e Bob descobrem que eles estão frequentemente agendando reuniões entre si e desenvolvem um nível de confiança. Consequentemente, Alice quer permitir que Bob agende reuniões sem ter que delegar a ele todas as vezes. Ela poderia aumentar a expiração do token de segurança de delegação, mas ela precisará reemiti-los e isso é problemático se ela quiser rescindir a capacidade de Bob de agendar reuniões.

Alice se comunica com seu serviço de calendário (autentica-se) e obtém a lista de autorização. Ela atualiza a lista de autorização para permitir que Bob veja seus dados de disponibilidade e agende reuniões e as envie ao serviço. Agora, quando Bob acessa seu serviço de calendário para essas operações, ele não precisa de um token de segurança de delegação de Alice.

Auditoria

No cenário de delegação acima, é possível que um antagonista tente agendar uma reunião sem um token de segurança de delegação ou com um token de segurança expirado. Nesses casos, a solicitação falhará porque o antagonista não pode provar as declarações necessárias.

Para acompanhar esse tipo de atividade, o serviço pode fornecer recursos de auditoria. Ou seja, quando ocorre um evento relacionado à segurança, como autenticação ou uma declaração não comprovada ou uma assinatura incorreta, ele é registrado. Um administrador pode acessar com segurança o log para examinar eventos relacionados à segurança e gerenciar o log.

Por exemplo, os antagonistas podem tentar imitar Bob. Usando uma ferramenta de monitor/gerenciamento, a administradora de segurança, Carol, revisa o log de auditoria e vê que o calendário de Alice teve uma série de falhas de segurança. Ao revisar os dados, ela vê que, às vezes, a solicitação de Bob falha porque sua assinatura não corresponde à mensagem ou às mensagens são antigas (reproduzidas). Como resultado, Carol coleta os registros de auditoria para uso na tentativa de rastrear os antagonistas.

5 Resumo

À medida que os serviços Web são aplicados de forma mais ampla, à medida que as topologias de aplicativos continuam a evoluir para dar suporte a intermediários, como firewalls, balanceadores de carga e hubs de mensagens, e à medida que a consciência das ameaças que as organizações enfrentam se torna mais bem compreendida, a necessidade de especificações de segurança adicionais para serviços Web fica clara.  Neste documento, propomos um modelo de segurança de serviços Web integrado e um conjunto de especificações para perceber esse modelo. Essas novas especificações, estendendo e aproveitando (em vez de substituir) a tecnologia e os ativos de segurança existentes, permitirão que clientes e organizações desenvolvam mais rapidamente serviços Web seguros e interoperáveis.

A IBM e a Microsoft acreditam que este é o primeiro passo para definir uma estratégia abrangente de segurança de serviços Web.  Isso reflete os desafios e soluções que identificamos até agora. À medida que continuamos a trabalhar em conjunto com clientes, parceiros e organizações de padrões para proteger os serviços Web, esperamos que haja ideias e especificações adicionais necessárias para concluir a estratégia. 

Contribuintes

Este documento foi criado em conjunto pela IBM e pela Microsoft.

As principais contribuições incluem (em ordem alfabética): Giovanni Della-Libera, Microsoft; Brendan Dixon, Microsoft; Joel Farrell, IBM; Praerit Garg, Microsoft; Maryann Hondo, IBM; Chris Kaler, Microsoft; Butler Lampson, Microsoft; Kelvin Lawrence, IBM; Andrew Layman, Microsoft; Paul Leach, Microsoft; John Manferdelli, Microsoft; Hiroshi Maruyama, IBM; Anthony Nadalin, IBM; Nataraj Nagaratnam, IBM; Rick Rashid, Microsoft; John Shewchuk, Microsoft; Dan Simon, Microsoft; Ajamu Wesley

Referências