Udostępnij za pośrednictwem

Zabezpieczenia w świecie usług sieci Web: proponowana architektura i harmonogram działania

  • Artykuł

 

7 kwietnia 2002 r.
Wersja 1.0

© 2001-2002 International Business Machines Corporation, . Wszelkie prawa zastrzeżone.

Jest to wstępny dokument i może ulec znacznej zmianie w czasie. Informacje zawarte w tym dokumencie reprezentują bieżący widok międzynarodowego komputera biznesowego i firmy Microsoft Corporation w kwestiach omówionych w dniu publikacji. Ze względu na to, że IBM i Microsoft muszą reagować na zmieniające się warunki rynkowe, nie należy interpretować zobowiązania ze strony IBM i Microsoft, a IBM i Microsoft nie mogą zagwarantować dokładności żadnych informacji przedstawionych po dacie publikacji.

Prezentacja, rozpowszechnianie lub inne rozpowszechnianie informacji zawartych w tym dokumencie nie jest licencją, wyraźnie lub dorozumianą, do jakiejkolwiek własności intelektualnej będącej własnością lub kontrolowaną przez IBM lub Microsoft i\lub jakiejkolwiek innej strony trzeciej. IBM, Microsoft i/lub wszelkie inne podmioty trzecie mogą mieć patenty, wnioski patentowe, znaki towarowe, prawa autorskie lub inne prawa własności intelektualnej obejmujące tematy w tym dokumencie. Wyposażenie tego dokumentu nie daje użytkownikowi żadnej licencji na patenty, znaki towarowe, prawa autorskie lub inną własność intelektualną firmy IBM ani żadnej innej firmy. Przykładowe firmy, organizacje, produkty, nazwy domen, adresy e-mail, logo, osoby, miejsca i wydarzenia przedstawione w niniejszym dokumencie są fikcyjne. Żadne skojarzenie z prawdziwą firmą, organizacją, produktem, nazwą domeny, adresem e-mail, logo, osobą, miejscami lub wydarzeniami jest zamierzone lub nie powinny być wnioskowane.

Niniejszy dokument i zawarte w nim informacje są udostępniane na zasadzie "AS IS" i do maksymalnego zakresu dozwolonego przez obowiązujące prawo, IBM i Microsoft dostarcza dokument AS IS I ZE wszystkimi wadami, a niniejszym wyłącza wszystkie inne gwarancje i postanowienia, zarówno wyraźne, dorozumiane, jak i ustawowe, w tym, ale nie tylko, wszelkie (jeśli w ogóle) domniemane gwarancje, obowiązków lub warunków handlowych, przydatności do określonego celu, dokładności lub kompletności odpowiedzi, wyników, wysiłku pracy, braku wirusów i braku zaniedbania, wszystkich w odniesieniu do dokumentu. PONADTO NIE MA GWARANCJI ANI WARUNKÓW TYTUŁU, CICHEJ PRZYJEMNOŚCI, CICHEGO POSIADANIA, KORESPONDENCJI Z OPISEM LUB NON-INFRINGEMENT WSZELKICH PRAW WŁASNOŚCI INTELEKTUALNEJ W ODNIESIENIU DO DOKUMENTU.

W ŻADNYM PRZYPADKU FIRMA IBM LUB MICROSOFT NIE BĘDZIE PONOSIĆ ODPOWIEDZIALNOŚCI ZA KOSZT POZYSKIWANIA TOWARÓW ZASTĘPCZYCH LUB USŁUG, UTRACONYCH ZYSKÓW, UTRATY UŻYTKOWANIA, UTRATY DANYCH LUB JAKIEJKOLWIEK PRZYPADKOWEJ, WTÓRNEJ, BEZPOŚREDNIEJ, POŚREDNIEJ LUB SPECJALNEJ SZKODY, NIEZALEŻNIE OD TEGO, CZY W RAMACH UMOWY, CZYNU NIEDOZWOLONEGO, GWARANCJI LUB W INNY SPOSÓB WYNIKAJĄCE Z NINIEJSZEJ UMOWY LUB JAKIEJKOLWIEK INNEJ UMOWY DOTYCZĄCEJ TEGO DOKUMENTU, NIEZALEŻNIE OD TEGO, CZY TAKA STRONA Z WYPRZEDZENIEM POWIADOMIŁA O MOŻLIWOŚCI WYSTĄPIENIA TAKICH SZKÓD.

Abstrakt

W tym dokumencie opisano proponowaną strategię rozwiązywania problemów z zabezpieczeniami w środowisku usługi sieci Web. Definiuje kompleksowy model zabezpieczeń usługi sieci Web, który obsługuje, integruje i łączy kilka popularnych modeli zabezpieczeń, mechanizmów i technologii (w tym zarówno symetrycznych, jak i kluczowych technologii) w sposób, który umożliwia wielu systemom bezpieczne współdziałanie w sposób neutralny dla platformy i języka. Opisano również zestaw specyfikacji i scenariuszy, które pokazują, jak te specyfikacje mogą być używane razem.

Streszczenie

Branża IT od prawie dwóch lat mówi o usługach internetowych. Korzyści wynikające z luźno powiązanego, neutralnego dla języka, niezależnego od platformy sposobu łączenia aplikacji w organizacjach, w przedsiębiorstwach i w Internecie stają się coraz bardziej widoczne, ponieważ usługi internetowe są używane w programach pilotażowych i w środowisku produkcyjnym na szeroką skalę. W przyszłości nasi klienci, analitycy branżowi i prasa identyfikują kluczowy obszar, który musi być rozwiązany, ponieważ usługi internetowe stają się bardziej głównym nurtem: bezpieczeństwo. W tym dokumencie przedstawiono strategię techniczną i plan działania, w którym branża może tworzyć i implementować architekturę opartą na standardach, która jest wystarczająco elastyczna, aby zaspokoić potrzeby rzeczywistych firm w zakresie zabezpieczeń usług internetowych.

Kluczową zaletą nowej architektury usług internetowych jest możliwość dostarczania zintegrowanych, współdziałających rozwiązań. Zapewnienie integralności, poufności i bezpieczeństwa usług sieci Web dzięki zastosowaniu kompleksowego modelu zabezpieczeń ma kluczowe znaczenie zarówno dla organizacji, jak i ich klientów.

W odpowiedzi na obawy wyrażone zarówno przez naszych klientów, jak i branżę, IBM i Microsoft współpracowały nad tym proponowanym planem zabezpieczeń usług sieci Web i planem rozwoju zestawu specyfikacji zabezpieczeń usługi sieci Web, które dotyczą sposobu zapewniania ochrony komunikatów wymienianych w środowisku usług sieci Web.

Po raz pierwszy utworzyliśmy model zabezpieczeń, który łączy wcześniej niezgodne technologie zabezpieczeń, takie jak infrastruktura kluczy publicznych, Kerberos i inne. Krótko mówiąc, nie jest to idealizowana struktura, ale praktyczna, która pozwala nam tworzyć bezpieczne usługi internetowe w heterogenicznym świecie IT, w którym mieszkają dzisiaj nasi klienci.

W tym dokumencie przedstawiono szeroki zestaw specyfikacji obejmujących technologie zabezpieczeń, w tym uwierzytelnianie, autoryzację, prywatność, zaufanie, integralność, poufność, bezpieczne kanały komunikacyjne, federację, delegowanie i inspekcję w szerokim spektrum topologii aplikacji i biznesu. Te specyfikacje zapewniają strukturę rozszerzalną, elastyczną i maksymalizującą istniejące inwestycje w infrastrukturę zabezpieczeń. Te specyfikacje podsumują i rozszerzają koncepcje przedstawione wcześniej w podobnych specyfikacjach zaproponowanych przez ibm i firmę Microsoft (czyli soap-Security, WS-Security i specyfikacje WS-License).

Dzięki wykorzystaniu naturalnej rozszerzalności, która jest podstawą modelu usług sieci Web, specyfikacje bazują na podstawowych technologiach, takich jak SOAP, WSDL, XML Digital Signatures, SZYFROWANIE XML i SSL/TLS. Dzięki temu dostawcy usług sieci Web i osoby żądające mogą opracowywać rozwiązania spełniające indywidualne wymagania dotyczące zabezpieczeń swoich aplikacji.

Firma IBM i Microsoft zamierzają współpracować z klientami, partnerami i organami standardów, aby rozwijać i ulepszać ten model zabezpieczeń w podejściu etapowym. Wypełniamy ten wysiłek specyfikacją WS-Security. WS-Security definiuje podstawowe funkcje ochrony integralności i poufności komunikatu, a także mechanizmy kojarzenia oświadczeń związanych z zabezpieczeniami z komunikatem. Chociaż WS-Security jest podstawą tego wysiłku, to dopiero początek i będziemy współpracować z branżą w celu opracowania dodatkowych specyfikacji, które będą radzić sobie z kwestiami polityki, zaufania i prywatności.

Aby rozwiązać problemy i rozwiązania omówione w tym dokumencie tak konkretne, jak to możliwe, omówimy kilka scenariuszy, które odzwierciedlają bieżące i przewidywane zastosowania usług sieci Web. Obejmują one przetwarzanie zapory, prywatność, korzystanie z przeglądarek i klientów mobilnych, kontrolę dostępu, delegowanie i inspekcję.

Przewidujemy obawy dotyczące tego, co można zrobić, aby zapewnić współdziałanie i spójną implementację różnych proponowanych specyfikacji. Aby rozwiązać ten problem, firma IBM i firma Microsoft będą ściśle współpracować z organizacjami standardów, społecznością deweloperów i organizacjami branżowymi, takimi jak WS-I.org, aby opracować profile współdziałania i testy, które zapewnią wskazówki dla dostawców narzędzi.

W tym dokumencie opisano kompleksowe, modułowe rozwiązanie, które po wdrożeniu umożliwi klientom tworzenie wzajemnie współdziałających i bezpiecznych usług sieci Web, które wykorzystują i rozszerzają istniejące inwestycje w infrastrukturę zabezpieczeń, jednocześnie umożliwiając im pełne wykorzystanie zalet integracji i współdziałania technologii usług internetowych.

1 Wprowadzenie i motywacja

Zapewnienie kompleksowego modelu funkcji zabezpieczeń i składników usług sieci Web wymaga integracji obecnie dostępnych procesów i technologii ze zmieniającymi się wymaganiami dotyczącymi zabezpieczeń przyszłych aplikacji. Wymaga ona ujednolicenia pojęć; wymaga rozwiązań zarówno technologicznych (bezpiecznych komunikatów) jak i procesów biznesowych (problemów z zasadami, ryzykiem, zaufaniem); i wreszcie wymaga skoordynowanych wysiłków dostawców platform, deweloperów aplikacji, dostawców sieci i infrastruktury oraz klientów.

Ujednolicenie zakresu dostępnych technologii zabezpieczeń oznacza, że wymagania funkcjonalne zabezpieczeń aplikacji muszą być abstrahowane od określonych mechanizmów stosowanych. Na przykład klient dokonujący zakupu online nie powinien mieć wpływu na to, czy korzysta z telefonu komórkowego, czy komputera przenośnego, o ile każde urządzenie może bezpiecznie wyrazić odpowiednią tożsamość.

Celem jest umożliwienie klientom łatwego tworzenia rozwiązań współdziałalnych przy użyciu systemów heterogenicznych. Na przykład model bezpiecznego przesyłania komunikatów proponowany w dalszej części tego dokumentu obsługuje zarówno infrastrukturę kluczy publicznych (PKI), jak i mechanizmy tożsamości Kerberos jako konkretne ucieleśnienia bardziej ogólnego obiektu i może być rozszerzone w celu obsługi dodatkowych mechanizmów zabezpieczeń. Integracja za pośrednictwem abstrakcji pojedynczego modelu zabezpieczeń umożliwia organizacjom korzystanie z istniejących inwestycji w technologie zabezpieczeń podczas komunikowania się z organizacjami przy użyciu różnych technologii.

Ponadto, ponieważ organizacje korzystające z różnych mechanizmów tożsamości współpracują z usługami sieci Web, model zaufania zabezpieczeń zapewnia elastyczną strukturę, w ramach której organizacje mogą łączyć się po skonfigurowaniu z odpowiednią autoryzacją.

Jednocześnie każdy klient i każda usługa internetowa mają własne unikatowe wymagania dotyczące zabezpieczeń na podstawie konkretnych potrzeb biznesowych i środowiska operacyjnego. Na przykład w ustawieniach grupy roboczej prostota i łatwość operacji są głównym problemem, podczas gdy w przypadku publicznych aplikacji internetowych możliwość wytrzymania uzgodnionych ataków typu "odmowa usługi" jest wyższym priorytetem. Ponieważ te wymagania mogą być łączone na wiele sposobów i wyrażane na różnych poziomach szczegółowości, skuteczne podejście do zabezpieczeń usługi sieci Web wymaga zestawu elastycznych, współdziałających elementów pierwotnych zabezpieczeń, które za pośrednictwem zasad i konfiguracji umożliwiają korzystanie z różnych bezpiecznych rozwiązań.

Aby sprostać tym wyzwaniom, ten dokument proponuje ewolucyjne podejście do tworzenia bezpiecznych, współdziałających usług sieci Web opartych na zestawie abstrakcji zabezpieczeń, które ujednolicają wcześniej różne technologie. Umożliwia to specjalizację konkretnym wymaganiom klienta w ramach ogólnej struktury, jednocześnie umożliwiając rozwój technologii wraz z upływem czasu i wdrażanie przyrostowe.

Przykładem tego ewolucyjnego podejścia jest możliwość dodania bezpiecznego modelu obsługi komunikatów do istniejących rozwiązań zabezpieczeń na poziomie transportu. Klient może dodać integralność na poziomie komunikatu lub stałą poufność (szyfrowanie elementów komunikatów) do istniejącej usługi sieci Web, której komunikaty są przenoszone, na przykład Secure Sockets Layer (SSL/TLS). Komunikaty mają teraz integralność (lub poufność), która utrzymuje się poza warstwą transportu.

Przewidujemy, że proponowany model i specyfikacje, które pojawią się, będą szeroko dostępne od wielu dostawców i będą brane pod uwagę przez odpowiednie organizacje standardów. Razem model, specyfikacje i proces standardów umożliwiają firmom szybkie i ekonomiczne zwiększanie bezpieczeństwa istniejących aplikacji oraz bezpieczne opracowywanie nowych, bezpiecznych usług internetowych.

Zaletą biznesową takiego modelu jest jasne. Dzięki utworzeniu kompleksowej architektury zabezpieczeń dla usług sieci Web organizacje i klienci mogą lepiej zapewnić ochronę swoich inwestycji i zasobów, ponieważ procesy biznesowe stają się coraz bardziej przekształcone w usługi sieci Web.

Terminologia dotycząca modelu zabezpieczeń usług sieci Web

Ponieważ terminologia różni się między technologiami, ten dokument definiuje kilka terminów, które mogą być stosowane spójnie w różnych formatach i mechanizmach zabezpieczeń. W związku z tym terminologia używana w tym miejscu może różnić się od innych specyfikacji i jest zdefiniowana, aby czytelnik mógł mapować terminy na preferowane słownictwo.

  • usługi sieci Web— termin "Usługa internetowa" ma szerokie zastosowanie do różnych topologii aplikacji opartych na sieci. W tym dokumencie używamy terminu "Usługa internetowa" do opisywania składników aplikacji, których funkcje i interfejsy są widoczne dla potencjalnych użytkowników za pośrednictwem stosowania istniejących i pojawiających się standardów technologii internetowych, w tym XML, SOAP, WSDL i HTTP. W przeciwieństwie do witryn sieci Web, interakcji opartych na przeglądarce lub technologii zależnych od platformy usługi sieci Web to usługi oferowane komputer-komputer za pośrednictwem zdefiniowanych formatów i protokołów, w sposób niezależny od platformy i neutralny dla języka.

  • token zabezpieczający— definiujemy token zabezpieczający jako reprezentację informacji związanych z zabezpieczeniami (np. certyfikat X.509, bilety Protokołu Kerberos i uwierzytelnianie, tokeny zabezpieczające urządzeń przenośnych z kart SIM, nazwy użytkownika itp.).

    Na poniższym diagramie przedstawiono niektóre z różnych rodzajów tokenów zabezpieczających.

  • podpisany token zabezpieczający— definiujemy podpisany token zabezpieczający jako token zabezpieczający zawierający zestaw powiązanych oświadczeń (asercji) kryptograficznie zatwierdzonych przez wystawcę. Przykłady podpisanych tokenów zabezpieczających obejmują certyfikaty X.509 i bilety protokołu Kerberos.

  • Claims— oświadczenie jest oświadczeniem dotyczącym podmiotu lub innej strony, która kojarzy podmiot z roszczeniem. Ważną kwestią jest to, że ta specyfikacja nie próbuje ograniczyć typów oświadczeń, które można wykonać, ani nie próbuje ograniczyć sposobu wyrażenia tych oświadczeń. Oświadczenia mogą dotyczyć kluczy potencjalnie używanych do podpisywania lub szyfrowania komunikatów. Oświadczenia mogą być instrukcjami przekazywanymi przez token zabezpieczający. Oświadczenia mogą służyć na przykład do potwierdzenia tożsamości nadawców lub autoryzowanej roli.

  • Podmiot— podmiot tokenu zabezpieczającego jest podmiotem zabezpieczeń (np. osobą, aplikacją lub jednostką biznesową), o której mają zastosowanie oświadczenia wyrażone w tokenie zabezpieczającym. W szczególności podmiot, jako właściciel tokenu zabezpieczającego posiada informacje niezbędne do udowodnienia własności tokenu zabezpieczającego.

  • dowód posiadania— definiujemy dowód posiadania informacje używane w procesie potwierdzania własności tokenu zabezpieczającego lub zestawu roszczeń. Na przykład dowód posiadania może być kluczem prywatnym skojarzonym z tokenem zabezpieczającym zawierającym klucz publiczny.

  • zasady punktu końcowego usługi sieci Web— usługi sieci Web mają pełną elastyczność w określaniu oświadczeń, których wymagają w celu przetwarzania komunikatów. Zbiorczo odnosimy się do tych wymaganych oświadczeń i powiązanych informacji jako "zasady punktu końcowego usługi internetowej". Zasady punktu końcowego mogą być wyrażane w formacie XML i mogą służyć do wskazywania wymagań związanych z uwierzytelnianiem (np. potwierdzeniem tożsamości użytkownika lub grupy), autoryzacją (np. potwierdzeniem niektórych możliwości wykonywania) lub innymi wymaganiami niestandardowymi.

  • Wymagania oświadczeń— wymagania dotyczące oświadczeń mogą być powiązane z całymi komunikatami lub elementami komunikatów, do wszystkich akcji danego typu lub akcji tylko w określonych okolicznościach. Na przykład usługa może wymagać od osoby żądającej potwierdzenia uprawnień dotyczących kwot zakupu większych niż określony limit.

  • pośredników— ponieważ komunikaty protokołu SOAP są wysyłane od początkowego osoby żądającej do usługi, mogą być obsługiwane przez pośredników wykonujących działania, takie jak kierowanie wiadomości, a nawet modyfikowanie wiadomości. Na przykład pośrednik może dodawać nagłówki, szyfrować lub odszyfrowywać fragmenty wiadomości lub dodawać dodatkowe tokeny zabezpieczające. W takich sytuacjach należy zachować ostrożność, aby zmiany w wiadomości nie unieważniły integralności wiadomości, naruszały model zaufania lub niszczyły odpowiedzialność.

  • aktor— aktor jest pośrednikiem lub punktem końcowym (zdefiniowanym w specyfikacji SOAP), który jest identyfikowany przez identyfikator URI i który przetwarza komunikat PROTOKOŁU SOAP. Należy pamiętać, że ani użytkownicy, ani oprogramowanie klienckie (np. przeglądarki) nie są aktorami.

Zasady modelu zabezpieczeń usług internetowych

Dostęp do usług sieci Web można uzyskać, wysyłając komunikaty PROTOKOŁU SOAP do punktów końcowych usługi zidentyfikowanych przez identyfikatory URI, żądając określonych akcji i odbierając odpowiedzi komunikatów protokołu SOAP (w tym wskazania błędów). W tym kontekście szeroki cel zabezpieczania usług sieci Web dzieli się na cele zależne dostarczania obiektów zapewniających integralność i poufność wiadomości oraz zapewnienie, że usługa działa tylko na żądaniach w komunikatach, które wyrażają oświadczenia wymagane przez zasady.

Obecnie protokół Secure Socket Layer (SSL) wraz z de facto protokołem Transport Layer Security (TLS) służy do zapewnienia zabezpieczeń na poziomie transportu dla aplikacji usług internetowych. Protokół SSL/TLS oferuje kilka funkcji zabezpieczeń, w tym uwierzytelnianie, integralność danych i poufność danych. Protokół SSL/TLS umożliwia bezpieczne sesje typu punkt-punkt.

IPSec to kolejny standard warstwy sieciowej dla zabezpieczeń transportu, który może stać się ważny dla usług sieci Web. Podobnie jak protokół SSL/TLS, protokół IPSec zapewnia również bezpieczne sesje z uwierzytelnianiem hosta, integralnością danych i poufnością danych.

Dzisiejsze topologie aplikacji usług internetowych obejmują szeroką kombinację urządzeń przenośnych, bram, serwerów proxy, modułów równoważenia obciążenia, stref zdemilitaryzowanych (DMZ), centrów danych z zewnątrz i globalnie rozproszonych dynamicznie skonfigurowanych systemów. Wszystkie te systemy polegają na możliwości przekazywania komunikatów przez pośredników przetwarzania komunikatów. W szczególności model komunikatów PROTOKOŁU SOAP działa na logicznych punktach końcowych, które abstrakcji sieci fizycznej i infrastruktury aplikacji, a tym samym często zawierają topologię wieloskoku z aktorami pośrednimi.

Gdy dane są odbierane i przekazywane przez pośrednika poza warstwą transportową, zarówno integralność danych, jak i wszelkie informacje o zabezpieczeniach, które przepływa z nim, mogą być utracone. Zmusza to wszystkich nadrzędnych procesorów komunikatów do polegania na ocenach zabezpieczeń dokonanych przez poprzednich pośredników i całkowitej zaufania ich obsłudze treści komunikatów. To, co jest potrzebne w kompleksowej architekturze zabezpieczeń usługi internetowej, to mechanizm zapewniający kompleksowe zabezpieczenia. Pomyślne rozwiązania zabezpieczeń usługi internetowej będą mogły korzystać zarówno z mechanizmów zabezpieczeń transportu, jak i warstwy aplikacji w celu zapewnienia kompleksowego zestawu funkcji zabezpieczeń.

konfiguracja punkt-punkt

kompleksowej konfiguracji

Model zabezpieczeń usługi sieci Web opisany w niniejszym dokumencie umożliwia nam osiągnięcie tych celów przez proces, w którym:

  • Usługa sieci Web może wymagać, aby komunikat przychodzący udowodnił zestaw oświadczeń (np. nazwa, klucz, uprawnienie, możliwości itp.). Jeśli komunikat pojawi się bez konieczności posiadania wymaganych oświadczeń, usługa może zignorować lub odrzucić komunikat. Odwołujemy się do zestawu wymaganych oświadczeń i powiązanych informacji jako zasad.
  • Żądający może wysyłać komunikaty z potwierdzeniem wymaganych oświadczeń przez skojarzenie tokenów zabezpieczających z komunikatami. W związku z tym komunikaty wymagają konkretnej akcji i dowodzą, że ich nadawca ma roszczenie dotyczące żądania akcji.
  • Gdy osoba żądającą nie ma wymaganych oświadczeń, osoba żądającą lub ktoś w jego imieniu może spróbować uzyskać niezbędne roszczenia, kontaktując się z innymi usługami sieci Web. Te inne usługi sieci Web, które nazywamy usług tokenu zabezpieczającego, mogą z kolei wymagać własnego zestawu oświadczeń. Zaufanie brokera usług tokenów zabezpieczających między różnymi domenami zaufania przez wystawianie tokenów zabezpieczających.

Ten model jest przedstawiony na poniższej ilustracji, pokazując, że każdy obiekt żądający może być również usługą i że usługa tokenu zabezpieczającego może być również w pełni usługą sieci Web, w tym wyrażanie zasad i wymaganie tokenów zabezpieczających.

Ten ogólny model obsługi komunikatów — oświadczenia, zasady i tokeny zabezpieczające — podsumowania i obsługuje kilka bardziej szczegółowych modeli, takich jak zabezpieczenia oparte na tożsamościach, listy kontroli dostępu i zabezpieczenia oparte na możliwościach. Umożliwia korzystanie z istniejących technologii, takich jak certyfikaty kluczy publicznych X.509, bilety protokołu Kerberos shared-secret, a nawet skróty haseł. Jak omówimy później, zapewnia również integrację abstrakcji, umożliwiając systemom tworzenie mostu między różnymi technologiami zabezpieczeń. Ogólny model jest wystarczający do konstruowania mechanizmów wymiany kluczy wyższego poziomu, uwierzytelniania, autoryzacji, inspekcji i zaufania.

2 Specyfikacje zabezpieczeń usług sieci Web

Strategia zabezpieczeń wyrażona w tym miejscu i specyfikacja zabezpieczeń WS-Security przedstawiona poniżej stanowią strategiczne cele i podstawę dla tego proponowanego modelu zabezpieczeń usług sieci Web.

W przyszłości kontynuujemy proces współpracy z klientami, partnerami i organizacjami standardów w celu opracowania początkowego zestawu specyfikacji zabezpieczeń usługi internetowej.

Ten zestaw będzie zawierać model zabezpieczeń komunikatów (WS-Security), który stanowi podstawę dla innych specyfikacji zabezpieczeń. W tej warstwie mamy warstwę zasad obejmującą zasady punktu końcowego usługi sieci Web (WS-Policy), model zaufania (WS-Trust) i model prywatności (WS-Privacy). Razem te wstępne specyfikacje stanowią podstawę, na której możemy pracować w celu ustanowienia bezpiecznych usług sieci Web, które można współdziałać między domenami zaufania.

Korzystając z tych początkowych specyfikacji, będziemy nadal współpracować z klientami, partnerami i organizacjami standardów w celu zapewnienia następujących specyfikacji dotyczących zabezpieczeń federacyjnych, które obejmują bezpieczne konwersacje (WS-SecureConversation), federacyjne zaufanie (WS-Federation) i autoryzację (WS-Authorization).

Połączenie tych specyfikacji zabezpieczeń umożliwia korzystanie z wielu scenariuszy (z których niektóre zostały opisane w dalszej części tego dokumentu), które są trudne do zaimplementowania przy użyciu dzisiejszych bardziej podstawowych mechanizmów zabezpieczeń.

Równolegle zaproponujemy i przejdziemy naprzód wraz z powiązanymi działaniami, które rozszerzają strukturę zabezpieczeń usług sieci Web o specyfikacje związane z inspekcją, zarządzaniem i prywatnością.

Ponadto firmy IBM i Microsoft są zaangażowane w współpracę z organizacjami, takimi jak WS-I na temat profilów współdziałania.

Połączenie specyfikacji zabezpieczeń, powiązanych działań i profilów współdziałania umożliwi klientom łatwe tworzenie wzajemnie bezpiecznych usług sieci Web.

Poniżej przedstawiono podsumowanie wszystkich proponowanych specyfikacji:

specyfikacji początkowej

  • WS-Security: opisuje sposób dołączania nagłówków podpisów i szyfrowania do komunikatów PROTOKOŁU SOAP. Ponadto opisuje sposób dołączania tokenów zabezpieczających, w tym binarnych tokenów zabezpieczających, takich jak certyfikaty X.509 i bilety Protokołu Kerberos, do komunikatów.
  • WS-Policy: opisuje możliwości i ograniczenia zasad zabezpieczeń (i innych firm) dotyczących pośredników i punktów końcowych (np. wymaganych tokenów zabezpieczających, obsługiwanych algorytmów szyfrowania, reguł prywatności).
  • WS-Trust: opisuje strukturę modeli zaufania, która umożliwia usługom sieci Web bezpieczne współdziałanie.
  • WS-Privacy: będzie opisywać model sposobu, w jaki usługi sieci Web i żądają preferencji prywatności państwa oraz zasady zachowania poufności informacji organizacji.

Follow-On Specifications

  • WS-SecureConversation: opisuje sposób zarządzania i uwierzytelniania wymiany komunikatów między stronami, w tym wymiany kontekstu zabezpieczeń i ustanawiania i wyprowadzania kluczy sesji.
  • WS-Federation: opisuje sposób zarządzania relacjami zaufania i brokera w heterogenicznych środowiskach federacyjnych, w tym obsługę tożsamości federacyjnych.
  • WS-Authorization: opisuje sposób zarządzania danymi autoryzacji i zasadami autoryzacji.

Zapewnienie zabezpieczeń WS-Security wymaga należytej staranności w produkcji opisów, specyfikacji i profilów w wielu obszarach funkcjonalnych. Te dokumenty zmienią się i ewoluują przez proces, który równoważy potrzeby klientów z potrzebami społeczności deweloperów usług internetowych i naszego własnego procesu edukacyjnego w trakcie procesu specyfikacji.

WS-Security

WS-Security opisuje ulepszenia obsługi komunikatów protokołu SOAP w celu zapewnienia jakości ochrony za pośrednictwem integralności wiadomości i poufności wiadomości. Ponadto ta specyfikacja definiuje sposób dołączania i dołączania tokenów zabezpieczających w komunikatach PROTOKOŁU SOAP. Na koniec dostępny jest mechanizm określania tokenów zabezpieczających zakodowanych w formacie binarnym (np. certyfikatów X.509). Te mechanizmy mogą być używane niezależnie lub w połączeniu, aby pomieścić szeroką gamę modeli zabezpieczeń i technologii szyfrowania.

WS-Security udostępnia mechanizm ogólnego przeznaczenia do kojarzenia tokenów zabezpieczających z komunikatami. Żaden określony typ tokenu zabezpieczającego nie jest wymagany przez WS-Security. Jest on przeznaczony do rozszerzania (np. obsługuje wiele formatów tokenów zabezpieczających). Na przykład żądający może dostarczyć dowód tożsamości i dowód, że ma określony certyfikat biznesowy.

Integralność komunikatów jest zapewniana przez wykorzystanie podpisu XML w połączeniu z tokenami zabezpieczającymi (które mogą zawierać lub oznaczać kluczowe dane), aby zapewnić przesyłanie komunikatów bez modyfikacji. Mechanizmy integralności zostały zaprojektowane tak, aby obsługiwały wiele podpisów, potencjalnie przez wielu aktorów i były rozszerzalne w celu obsługi dodatkowych formatów podpisów. Podpisy mogą odwoływać się (tj. wskazywać) token zabezpieczający.

Podobnie poufność wiadomości jest zapewniana przez wykorzystanie szyfrowania XML w połączeniu z tokenami zabezpieczającymi w celu zachowania poufności części komunikatów PROTOKOŁU SOAP. Mechanizmy szyfrowania są przeznaczone do obsługi dodatkowych technologii szyfrowania, procesów i operacji przez wielu podmiotów. Szyfrowanie może również odwoływać się do tokenu zabezpieczającego.

Na koniec WS-Security opisuje mechanizm kodowania binarnych tokenów zabezpieczających. W szczególności specyfikacja opisuje sposób kodowania certyfikatów X.509 i biletów Protokołu Kerberos oraz sposobu dołączania nieprzezroczystych kluczy zaszyfrowanych. Zawiera również mechanizmy rozszerzalności, które mogą służyć do dalszego opisywania cech tokenów zabezpieczających dołączonych do komunikatu.

WS-Policy

WS-Policy opisze, w jaki sposób nadawcy i odbiorcy mogą określić ich wymagania i możliwości.

WS-Policy będą w pełni rozszerzalne i nie będą ograniczać typów wymagań i możliwości, które mogą być opisane; jednak specyfikacja prawdopodobnie zidentyfikuje kilka podstawowych atrybutów usługi, w tym atrybuty prywatności, formaty kodowania, wymagania dotyczące tokenu zabezpieczającego i obsługiwane algorytmy.

Ta specyfikacja zdefiniuje ogólny format zasad PROTOKOŁU SOAP, który może obsługiwać więcej niż tylko zasady zabezpieczeń. Ta specyfikacja zdefiniuje również mechanizm dołączania lub kojarzenia zasad usługi z komunikatami PROTOKOŁU SOAP.

WS-Trust

WS-Trust opisze model ustanawiania relacji zaufania bezpośredniego i pośredniczącego (w tym podmiotów trzecich i pośredników).

Ta specyfikacja opisuje, w jaki sposób istniejące relacje zaufania bezpośredniego mogą być używane jako podstawa zaufania brokera poprzez tworzenie usług wystawiania tokenów zabezpieczających. Te usługi wystawiania tokenów zabezpieczających bazują na WS-Security w celu przeniesienia wymaganych tokenów zabezpieczających w sposób zapewniający integralność i poufność tych tokenów.

Następnie ta specyfikacja opisuje, jak można używać kilku istniejących mechanizmów zaufania w połączeniu z tym modelem zaufania.

Na koniec model zaufania będzie jawnie zezwalał, ale nie będzie zezwalał na delegowanie, delegowanie i personifikację przez podmioty zabezpieczeń. Należy pamiętać, że delegowanie jest zgodne z personifikacją, ale zapewnia dodatkowe poziomy możliwości śledzenia.

WS-Privacy

Organizacje tworzące usługi sieci Web, zarządzające nimi i korzystające z nich często muszą określać zasady ochrony prywatności i wymagać od przychodzących żądań oświadczeń dotyczących przestrzegania tych zasad przez nadawców.

Korzystając z kombinacji usług WS-Policy, WS-Securityi WS-Trust organizacje mogą określać zgodność z określonymi zasadami ochrony prywatności. Ta specyfikacja opisuje model sposobu osadzenia języka prywatności w opisach WS-Policy oraz o tym, jak WS-Security może służyć do kojarzenia oświadczeń prywatności z komunikatem. Na koniec ta specyfikacja opisuje, w jaki sposób WS-Trust mechanizmy mogą służyć do oceny tych oświadczeń dotyczących prywatności zarówno dla preferencji użytkownika, jak i oświadczeń dotyczących praktyk organizacyjnych.

WS-SecureConversation

WS-SecureConversation opisze, w jaki sposób usługa sieci Web może uwierzytelniać komunikaty żądających, jak osoby żądające mogą uwierzytelniać usługi i jak ustanowić wzajemnie uwierzytelnione konteksty zabezpieczeń.

Ta specyfikacja opisuje sposób ustanawiania kluczy sesji, kluczy pochodnych i kluczy poszczególnych komunikatów.

Na koniec ta specyfikacja opisuje, jak usługa może bezpiecznie wymieniać kontekst (kolekcje oświadczeń dotyczących atrybutów zabezpieczeń i powiązanych danych). Aby to osiągnąć, specyfikacja będzie opisywać i opierać się na pojęciach dotyczących wystawiania i wymiany tokenów zabezpieczających zdefiniowanych w WS-Security i WS-Trust. Użycie tych mechanizmów może na przykład obsługiwać tokeny zabezpieczające przy użyciu słabej technologii klucza symetrycznego, a także wystawiać silniejsze tokeny zabezpieczające przy użyciu kluczy nieudostępnianych (asymetrycznych).

WS-SecureConversation jest przeznaczony do działania w warstwie komunikatów SOAP, dzięki czemu komunikaty mogą przechodzić przez różne transporty i pośredników. Nie wyklucza to używania jej w innych strukturach obsługi komunikatów. Aby jeszcze bardziej zwiększyć bezpieczeństwo systemów, zabezpieczenia na poziomie transportu mogą być używane w połączeniu zarówno z WS-Security, jak i WS-SecureConversation między wybranymi łączami.

WS-Federation

Ta specyfikacja definiuje sposób konstruowania scenariuszy zaufania federacyjnego przy użyciu specyfikacji WS-Security, WS-Policy, WS-Trust i WS-SecureConversation specyfikacji. Na przykład opisano sposób federacji infrastruktury Kerberos i PKI (zgodnie z opisem w poniższych scenariuszach).

Ponadto wprowadzono zasady zaufania, aby wskazać i ograniczyć i zidentyfikować typ zaufania, który jest obsługiwany.

Ta specyfikacja zdefiniuje również mechanizmy zarządzania relacjami zaufania.

WS-Authorization

Ta specyfikacja opisuje sposób, w jaki zasady dostępu dla usługi sieci Web są określane i zarządzane. W szczególności opisuje sposób określenia oświadczeń w tokenach zabezpieczających i interpretacji tych oświadczeń w punkcie końcowym.

Ta specyfikacja zostanie zaprojektowana tak, aby była elastyczna i rozszerzalna w odniesieniu zarówno do formatu autoryzacji, jak i języka autoryzacji. Umożliwia to najszerszy zakres scenariuszy i zapewnia długoterminową rentowność platformy zabezpieczeń.

3 Dotyczące zabezpieczeń usług internetowych z dzisiejszymi modelami zabezpieczeń

Ten model zabezpieczeń usług sieci Web jest obecnie zgodny z istniejącymi modelami zabezpieczeń na potrzeby uwierzytelniania, integralności danych i poufności danych. W związku z tym można zintegrować rozwiązania oparte na usługach sieci Web z innymi istniejącymi modelami zabezpieczeń:

  • Transport Security— istniejące technologie, takie jak bezpieczne gniazda (SSL/TLS) mogą zapewnić prostą integralność i poufność punkt-punkt dla komunikatu. Model zabezpieczeń usług sieci Web obsługuje korzystanie z tych istniejących mechanizmów bezpiecznego transportu w połączeniu z WS-Security (i innymi specyfikacjami) w celu zapewnienia kompleksowej integralności i poufności w szczególności w wielu transportach, pośrednikach i protokołach transmisji.
  • infrastruktury kluczy publicznych — na wysokim poziomie model infrastruktury kluczy publicznych obejmuje urzędy certyfikacji wystawiające certyfikaty z publicznymi kluczami asymetrycznymi i władzami, które zapewniają właściwości inne niż własność klucza (na przykład urzędy atrybutów). Właściciele takich certyfikatów mogą używać skojarzonych kluczy do wyrażania różnych oświadczeń, w tym tożsamości. Model zabezpieczeń usług sieci Web obsługuje usługi tokenów zabezpieczających wystawiające tokeny zabezpieczające przy użyciu publicznych kluczy asymetrycznych. Infrastruktura kluczy publicznych jest używana w najszerszym sensie i nie zakłada żadnej konkretnej hierarchii ani modelu.
  • kerberos— model Kerberos opiera się na komunikacji z centrum dystrybucji kluczy (KDC) w celu brokera zaufania między stronami przez wydawanie kluczy symetrycznych zaszyfrowanych dla obu stron i "wprowadzenie" do siebie. Ponownie model usług sieci Web opiera się na podstawowym modelu z zaufaniem brokera usług tokenów zabezpieczających przez wystawianie tokenów zabezpieczających z zaszyfrowanymi kluczami symetrycznymi i zaszyfrowanymi świadectwami.

Należy pamiętać, że chociaż modele są zgodne, aby zapewnić współdziałanie, adaptery i/lub wspólne algorytmy podpisów i szyfrowania będą musiały zostać uzgodnione lub opracowane.

Istniejące modele federacji, autoryzacji (w tym delegowania), prywatności i zaufania są mniej powszechne i bardziej ad hoc. Specyfikacje dotyczące tych właściwości zabezpieczeń są identyfikowane w późniejszych fazach strategii.

Często istniejące modele zaufania są oparte na umowach biznesowych. Przykładem jest usługa internetowa UDDI. W usłudze UDDI istnieje kilku uczestników, którzy zapewniają rejestr uniwersalny firm za pośrednictwem umowy dotyczącej obsługi zestawu interfejsów API. Zamiast definiować pojedynczy model "zaufania" za pomocą wymagania określonego mechanizmu uwierzytelniania, "model zaufania" w usłudze UDDI daje odpowiedzialność za uwierzytelnianie węzła, który jest opiekunem informacji. Oznacza to, że każda implementacja usługi internetowej UDDI ma własny mechanizm uwierzytelniania i wymusza własne zasady kontroli dostępu. "zaufanie" znajduje się między operatorami i między podmiotem żądający a operatorem, który jest opiekunem jego informacji.

4 scenariusze

Poniżej przedstawiono szereg scenariuszy, które przedstawiają sposób, w jaki przewidujemy, że proponowane specyfikacje zabezpieczeń usługi internetowej są używane. Te scenariusze są celowo skoncentrowane na szczegółach technicznych, aby zilustrować możliwości ogólnej strategii zabezpieczeń. Dostępna będzie dokumentacja pomocnika, która zawiera szczegółowe scenariusze użycia biznesowego.

Przykładowe firmy, organizacje, produkty, nazwy domen, adresy e-mail, logo, osoby, miejsca i wydarzenia przedstawione w niniejszym dokumencie są fikcyjne. Żadne skojarzenie z prawdziwą firmą, organizacją, produktem, nazwą domeny, adresem e-mail, logo, osobą, miejscami lub wydarzeniami jest zamierzone lub nie powinny być wnioskowane.

Poniższa lista krótko przedstawia niektóre scenariusze, które mogą być obsługiwane przez proponowane specyfikacje początkowe i powiązane karty dostarczane:

  • Bezpośrednie zaufanie przy użyciu nazwy użytkownika/hasła i Transport-Level zabezpieczeń — w tym scenariuszu przedstawiono uwierzytelnianie przy użyciu nazwy użytkownika i hasła z zabezpieczeniami transportu.
  • Bezpośrednie zaufanie przy użyciu tokenów zabezpieczających — w tym scenariuszu przedstawiono bezpośrednie zaufanie przy użyciu certyfikatów X.509 i biletów usługi Kerberos (ST).
  • Uzyskiwanie tokenu zabezpieczającego — w tym scenariuszu przedstawiono uwierzytelnianie przy użyciu tokenu zabezpieczającego przechowywanego niezależnie od komunikatu.
  • Przetwarzanie zapory — w tym scenariuszu pokazano, jak zapory mogą korzystać z tego modelu zabezpieczeń w celu uzyskania większego stopnia kontroli.
  • Wystawiony token zabezpieczający — w tym scenariuszu przedstawiono uwierzytelnianie podstawowe.
  • Wymuszanie zasad biznesowych — w tym scenariuszu pokazano, jak używać wystawiania tokenów zabezpieczających do kodowania procesów biznesowych.
  • Prywatność — w tym scenariuszu pokazano, jak klienci i usługi mogą komunikować się ze swoimi zasadami ochrony prywatności.
  • Klienci sieci Web — w tym scenariuszu przedstawiono użycie przeglądarki sieci Web jako klienta.
  • Klienci mobilni — w tym scenariuszu pokazano, jak klienci mobilni mogą bezpiecznie korzystać z usług sieci Web.

Drugi zestaw scenariuszy jest bardziej zaawansowany. Te scenariusze mogą być oparte na bieżących elementach dostarczanych, ale wymagają specyfikacji kontynuacji (takich jak WS-SecureConversation) w celu zapewnienia bezproblemowego współdziałania.

  • Włączanie federacji — w tej sekcji opisano kilka różnych scenariuszy dotyczących zaufania federacyjnego.
  • Usługa walidacji: opisuje sposób używania usługi, która weryfikuje zabezpieczenia komunikatu (np. podpis).
  • Delegowanie pomocnicze — ilustruje to sposób używania tokenów zabezpieczających do delegowania.
  • Kontrola dostępu — ilustruje to, w jaki sposób zabezpieczenia usług sieci Web obsługują tradycyjne zabezpieczenia oparte na listach kontroli dostępu.
  • Inspekcja — ilustruje to użycie inspekcji do śledzenia działań i zdarzeń związanych z zabezpieczeniami.

Należy pamiętać, że w poniższych opisach użycie terminu żądającego jest używane do opisywania szerokiej gamy potencjalnych użytkowników usługi sieci Web i nie ma na celu ograniczenia cech osoby żądającego. Osoby żądające mogą obejmować jednostki biznesowe wchodzące w interakcje z usługą w środowisku B2B lub osoby, które uzyskują dostęp do usług z przeglądarki lub urządzenia przenośnego.

Bezpośrednie zaufanie przy użyciu nazwy użytkownika/hasła i zabezpieczeń Transport-Level

Oto bardzo podstawowy przykład przedstawiający sposób użycia zabezpieczeń usług sieci Web z istniejącymi mechanizmami zabezpieczeń transportu:

Obiekt żądający otwiera połączenie z usługą sieci Web przy użyciu bezpiecznego transportu (np. SSL/TLS). Wysyła żądanie i zawiera token zabezpieczający zawierający nazwę użytkownika i hasło. Usługa uwierzytelnia informacje, przetwarza żądanie i zwraca wynik.

W tym scenariuszu poufność i integralność wiadomości są obsługiwane przy użyciu istniejących mechanizmów zabezpieczeń transportu.

W tym scenariuszu przyjęto założenie, że obie strony używały już pewnego mechanizmu do ustanowienia wspólnego wpisu tajnego — hasła osoby żądającego. Nie przyjmuje się żadnych założeń dotyczących relacji organizacyjnych między tymi stronami.

Bezpośrednie zaufanie przy użyciu tokenów zabezpieczających

W tym scenariuszu przedstawiono użycie tokenu zabezpieczającego, który jest bezpośrednio zaufany przez usługę sieci Web. W tym przypadku bezpośrednia relacja zaufania oznacza, że token zabezpieczający żądania (lub jego urząd podpisywania) jest znany i zaufany przez usługę sieci Web. W tym scenariuszu przyjęto założenie, że obie strony wykorzystały jakiś mechanizm do ustanowienia relacji zaufania do korzystania z tokenu zabezpieczającego. To zaufanie można ustanowić ręcznie, konfigurując aplikację lub używając bezpiecznego transportu do wymiany kluczy. Dzięki bezpiecznemu transportowi kluczy oznaczamy, że transport, taki jak SSL (lub inny mechanizm lub proces), może być używany jako sposób na potwierdzenie ważności klucza lub tokenu zabezpieczającego dla strony adresata. Nie przyjmuje się żadnych założeń dotyczących relacji organizacyjnych między stronami.

Żądający wysyła komunikat do usługi i zawiera podpisany token zabezpieczający oraz zapewnia dowód posiadania tokenu zabezpieczającego przy użyciu na przykład podpisu. Usługa weryfikuje dowód i ocenia token zabezpieczający. Podpis tokenu zabezpieczającego jest prawidłowy i jest bezpośrednio zaufany przez usługę. Usługa przetwarza żądanie i zwraca wynik.

Bezpośrednie zaufanie zakłada, że zasady ochrony prywatności są dobrze zrozumiałe dla zaangażowanych stron.

Uzyskiwanie tokenu zabezpieczającego

W niektórych przypadkach używany token zabezpieczający nie jest przekazywany w ramach komunikatu. Zamiast tego podano odwołanie do tokenu zabezpieczającego, które może służyć do lokalizowania i uzyskiwania tokenu.

Żądający wysyła żądanie do usługi i zawiera odwołanie do tokenu zabezpieczającego i dostarcza dowód posiadania. Usługa sieci Web używa podanych informacji w celu uzyskania tokenu zabezpieczającego z usługi magazynu tokenów i zweryfikowania dowodu. Zaufanie usługi sieci Web (należy pamiętać, że zaufanie zostało ustanowione poza semantyki komunikatów) token zabezpieczający, więc żądanie jest przetwarzane i zwracana jest odpowiedź.

Przetwarzanie zapory

Zapory pozostają krytycznym składnikiem architektury zabezpieczeń usług sieci Web — muszą one nadal wymuszać reguły przetwarzania granic.

Jak pokazano poniżej, zapora sprawdza przychodzące komunikaty PROTOKOŁU SOAP i zezwala tylko tym osobom z "autoryzowanych" żądających na przeniknięcie przez zaporę.

W tym scenariuszu mamy dwóch żądających wysyłających komunikaty do usługi internetowej wewnątrz zapory. Zapora sprawdza komunikaty, aby określić, czy osoba żądający jest "autoryzowana" do wysyłania komunikatów do określonej usługi sieci Web wewnątrz zapory.

W tym scenariuszu zapora podejmuje tę decyzję, sprawdzając token zabezpieczający użyty do podpisania komunikatu. Jeśli podpis jest prawidłowy, a urząd podpisywania tokenu zabezpieczającego jest zaufany do autoryzowania komunikatów do zapory, a token informuje, że autoryzuje komunikaty do zapory, komunikat jest dozwolony; w przeciwnym razie zostanie odrzucona. W niektórych przypadkach podpis może odwoływać się do zapory jako aktor protokołu SOAP.

W innych scenariuszach zapora może również działać jako urząd wystawiający token zabezpieczający i zezwalać tylko na komunikaty zawierające dowód posiadania tokenu zabezpieczającego wystawionego przez zaporę.

Wystawiony token zabezpieczający

Oto przykład pokazujący, jak zabezpieczenia usług sieci Web obsługują proste uwierzytelnianie przez zaufaną firmę:

W dwóch pierwszych krokach osoba żądającą komunikuje się z urzędem certyfikacji w celu uzyskania tokenu zabezpieczającego, w szczególności podpisanej oświadczenia potwierdzenia potwierdzającej tożsamość obiektu żądającego.

Żądający uzyskał token zabezpieczający, ponieważ usługa sieci Web ma zasady wymagające, aby wymagany był token zabezpieczający odpowiedniego typu (w tym przypadku dowód tożsamości).

Następnie żądający wysyła wiadomość z tokenem zabezpieczającym i dowodem posiadania dołączonym do wiadomości (pomyśl o uwierzytelnieniu lub podpisanym wyzwaniu) do usługi internetowej i otrzymuje odpowiedź.

Należy pamiętać, że w powyższym opisie działanie usługi certyfikacji tożsamości nie zostało szczegółowo opisane. Aby uzyskać token zabezpieczający tożsamości, osoby żądających mogą używać istniejących protokołów zabezpieczeń lub mogą korzystać ze specyfikacji zabezpieczeń usług sieci Web.

Jeśli zakładamy, że żądający korzysta ze specyfikacji zabezpieczeń usług sieci Web, system będzie działać w następujący sposób: usługa tożsamości opisuje jej wymagania w zasadach, a żądający może zażądać tokenu zabezpieczającego wraz z jego dowodem tożsamości.

Należy pamiętać, że usługa tożsamości jest tylko usługą tokenu zabezpieczającego. Ponadto symetria usług sieci Web umożliwia również hermetyzację usługi tokenu zabezpieczającego dla dowolnej usługi sieci Web.

Na koniec należy pamiętać, że usługi sieci Web mogą uzyskiwać tokeny zabezpieczające w imieniu osoby żądającego (z usługi tokenu zabezpieczającego) i zwracać je do osoby żądającego w celu użycia w kolejnych komunikatach.

Wymuszanie zasad biznesowych

W wielu procesach biznesowych istnieją określone zasady, które muszą być wymuszane. Na przykład usługa może wymagać, aby konsumenci mieli pewną ocenę lub pozycję z określoną firmą przeprowadzającą inspekcję. Dzięki usługom sieci Web wiele z tych zasad można automatycznie skodyfikować i weryfikować, upraszczając ogólny proces.

Rozważmy następujący przykład:

Nicholas'Dealership ma usługę internetową, której używa do interakcji ze swoimi dostawcami części. Chcą jednak radzić sobie tylko z dostawcami, których części są certyfikowane przez producenta.

Firma częściowa, Joshua's Parts, pójdzie do producenta i przedstawi (i udowodnić) swój token zabezpieczający tożsamości (na przykład z ilustrowanej usługi tokenu zabezpieczającego) i zażąda tokenu zabezpieczającego od producenta, stwierdzając, że jest certyfikowanym dealerem części (zakładając, że są certyfikowane i w dobrej sytuacji). Joshua's Parts może następnie skontaktować się z Dealership Nicholasa i dostarczyć (i udowodnić) oba tokeny zabezpieczające.

Jeśli dealerstwo Mikołaja skodyfikowało swoją politykę biznesową w polityce usług, ciężar zgodności polityki może być ładowany z przodu do firmy częściowej (np. Części Joshuy).

Zasady usług mogą również określać ograniczenia dotyczące informacji, które producent może przechowywać w celu zapewnienia zgodności z zasadami ochrony prywatności.

Prywatność

Prywatność obejmuje szeroki zestaw zagadnień i należy uwzględnić je w każdej ze specyfikacji wynikających z tej strategii.

Podstawowe problemy z prywatnością zostaną rozwiązane przez udostępnienie zasad zachowania poufności informacji w ramach zasad usługi. Bardziej zaawansowane scenariusze obejmujące delegowanie i autoryzację zostaną omówione w specyfikacjach specyficznych dla tych scenariuszy.

Na przykład poszczególne stany zestawu "preferencji prywatności", które opisują, co dana osoba robi lub nie chce zezwalać aplikacjom działającym w imieniu osób fizycznych na wykonywanie z danymi osobowymi. Aplikacja do obsługi kalendarza, pracując w imieniu osób fizycznych, może teraz uzyskiwać dostęp do usługi kalendarzowej, która korzysta z zestawu "zasad praktyki prywatności", do podejmowania oświadczeń i decyzji dotyczących używania i ujawniania danych osobowych. Usługa kalendarza podejmuje decyzję, łącząc zasady praktyki prywatności z preferencjami prywatności w celu ustalenia, czy proponowane użycie lub ujawnienie jest dopuszczalne.

Klienci sieci Web

Rozważmy przykład, w którym klient internetowy komunikuje się z aplikacją internetową warstwy środkowej, która z kolei komunikuje się (bezpiecznie) z usługą sieci Web w innej domenie. Aplikacja sieci Web w warstwie środkowej, która obsługuje usługi sieci Web, chce uzyskać token zabezpieczający dla klienta sieci Web.

Ponadto w tym scenariuszu przyjęto założenie, że token zabezpieczający umożliwia aplikacji warstwy środkowej działanie w imieniu klienta podczas rozmowy z usługą.

Aby włączyć ten scenariusz, przeglądarka klienta sieci Web uzyskuje dostęp do aplikacji warstwy środkowej i jest przekierowywana do skojarzonej usługi tożsamości. Po uwierzytelnieniu (na przykład przy użyciu formularza HTML i https) żądanie jest przekierowywane z powrotem do aplikacji warstwy środkowej. Usługa tożsamości udostępnia token zabezpieczający (potwierdzenie tożsamości i delegowania) do oryginalnego serwera sieci Web aplikacji warstwy środkowej (na przykład przy użyciu ciągu zapytania wysyłanego za pośrednictwem protokołu HTTPS). Serwer sieci Web może teraz używać tych tokenów zabezpieczających i wysyłać żądania z własnej tożsamości do usługi sieci Web. Usługa sieci Web przetwarza żądania i zwraca wyniki do serwera sieci Web, na którym wyniki są sformatowane i zwrócone w przeglądarce.

Klienci mobilni

Specyfikacje opisane w powyższym dokumencie zapewniają znaczną elastyczność w rozwiązywaniu problemów projektowych, które są unikatowe dla bezpieczeństwa urządzeń przenośnych.  Elastyczność podejścia usług sieci Web umożliwia obsługę wielu technologii kryptograficznych zapewniających zarówno silną, jak i wydajną ochronę kryptograficzną na urządzeniach z ograniczonymi możliwościami obliczeniowymi i magazynowymi.  Podobnie umożliwia operatorom sieci zapewnienie serwerów proxy zabezpieczeń, takich jak bramy sieci, do działania w imieniu klientów mobilnych. 

Poniżej przedstawiono przykład łączący oba te koncepcje.  Gdy operator sieci obsługuje klientów sieci komórkowej (przy użyciu tych specyfikacji zabezpieczeń usługi sieci Web), może skonfigurować tych klientów do wysyłania żądań za pośrednictwem bramy operatora sieci.  W tym scenariuszu brama jest pośrednikiem protokołu SOAP, który aktywnie uczestniczy w ogólnym przepływie komunikatów; w szczególności operator sieci udostępnia algorytm szyfrowania dodający wartość przeznaczony dla urządzeń przenośnych.  Brama może rozszerzyć lub zmienić tokeny zabezpieczające i jakość ochrony komunikatu.  Należy pamiętać, że elastyczność związana z tym modelem zabezpieczeń usług sieci Web umożliwia korzystanie z tego rozwiązania nawet wtedy, gdy urządzenie jest roamingu w sieci obcej. 

Przedstawiono to w poniższym przykładzie:

Włączanie federacji

Model zabezpieczeń usług sieci Web jest przeznaczony do obsługi federacji. Oto prosty przykład federacji tożsamości:

Alicja w firmie Adventure456 chce użyć usługi internetowej Currency w firmie Business456. Usługa Waluta będzie przetwarzać żądania tylko przy użyciu tokenu zabezpieczającego wystawionego przez firmę Business456. Alicja ma tylko token zabezpieczający z oświadczeniami tożsamości (tj. tokenem zabezpieczającym tożsamości) wystawionym przez firmę Adventure456.

W tym scenariuszu Alice będzie mogła uzyskać dostęp tylko do usługi Waluta, jeśli firma Business456 jest gotowa zaakceptować federację zabezpieczeń z adventure456.

W poniższych podsekcjach opisano kilka podejść do federacji zabezpieczeń.

Federacja przy użyciu wymiany tokenów zabezpieczających

W tym podejściu zasady usługi Currency stwierdzają, że akceptuje tylko tokeny zabezpieczające wystawione przez firmę Business456. Ponieważ zasady wskazują, gdzie uzyskać wymagany token zabezpieczający, Alice prezentuje (i potwierdza) token zabezpieczający Adventure456 do usługi tokenu zabezpieczającego Business456 i otrzymuje token zabezpieczający Business456. Następnie przedstawia (i potwierdza) ten token zabezpieczający w żądaniach do usługi Currency. Przedstawiono to na poniższym diagramie:

W tym podejściu usługa tokenu zabezpieczającego Business456 została skonfigurowana do akceptowania tokenów zabezpieczających z oświadczeniami tożsamości wystawionymi przez firmę Adventure456

Należy zauważyć, że ten przykład jest bardzo podobny do przykładu w scenariuszu Wymuszanie zasad biznesowych. Pokazuje to elastyczność modelu zabezpieczeń usługi internetowej.

Federacja przy użyciu łańcucha zaufania

W tym podejściu usługa Waluta zaakceptuje żądanie z dowolnym tokenem zabezpieczającym, ale nie przetworzy żądania, chyba że będzie mogła uzyskać token zabezpieczający Business456 na podstawie dostarczonego tokenu zabezpieczającego (i dowodu).

W tym celu usługa Waluta przekazuje oryginalne żądanie do usługi tokenu zabezpieczającego Business456, która ocenia początkowy token zabezpieczający. Jeśli jest prawidłowa, popiera żądanie i może zawierać token zabezpieczający Business456 dla Alice do użycia w kolejnych żądaniach. Przedstawiono to na poniższej ilustracji.

W tym podejściu usługa tokenu zabezpieczającego Business456 została skonfigurowana do akceptowania tokenów zabezpieczających z oświadczeniami tożsamości wystawionymi przez firmę Adventure456

Federacja przy użyciu wymiany tokenów zabezpieczeń (PKIKerberos)

W tym podejściu Adventure456 wydała Alice token zabezpieczeń klucza publicznego, a zasady usługi Walutowej wskazują, że akceptuje tylko tokeny zabezpieczające Kerberos z centrum dystrybucji kluczy dystrybucji kluczy.

W kierunku zasad usługi Walutowej Alice przedstawia (i potwierdza) swój token zabezpieczający klucza publicznego do usługi tokenu zabezpieczającego Business456. Usługa tokenu zabezpieczającego hermetyzuje centrum dystrybucji kluczy biznesowych456. W rezultacie jest w stanie zweryfikować token zabezpieczający klucza publicznego Alicji i wystawiać token zabezpieczający Protokołu Kerberos dla usługi Currency. Przedstawiono to na poniższej ilustracji:

W tym podejściu usługa tokenu zabezpieczającego Business456 została skonfigurowana do akceptowania tokenów zabezpieczających kluczy publicznych z oświadczeniami tożsamości wystawionymi przez firmę Adventure456.

Federacja przy użyciu wymiany tokenów zabezpieczeń (KerberosSecurity Token Service)

W tym podejściu Adventure456 wydała Alice token zabezpieczający Kerberos, a zasady usługi Currency wskazują, że akceptuje tylko tokeny zabezpieczające wystawione przez własną usługę tokenów zabezpieczających.

W tym miejscu zakładamy, że administratorzy w firmie Adventure456 i Business456 wymienili certyfikaty kluczy publicznych w celu federacji zabezpieczeń. Ponadto zakładamy, że Alicja obsługuje tylko technologię klucza symetrycznego.

Na podstawie zasad usługi internetowej Waluta Alicja musi uzyskać token zabezpieczający, który może służyć do uzyskiwania dostępu do usługi tokenu zabezpieczającego w firmie Business456. Ponieważ Alice używa symetrycznych tokenów zabezpieczających kluczy, Alicja najpierw kontaktuje się z usługą tokenu zabezpieczającego w celu uzyskania tokenu zabezpieczającego przeznaczonego dla usługi tokenu zabezpieczającego Business456. Należy pamiętać, że ten token zabezpieczający będzie zawierać klucz symetryczny Sab zakodowany przy użyciu klucza publicznego usługi tokenu zabezpieczającego Business456.

Korzystając z tokenu zabezpieczającego przeznaczonego dla usługi tokenu zabezpieczającego Business456, Alice żąda tokenu zabezpieczającego dla usługi Currency. Usługa tokenu zabezpieczającego Business456 udostępnia Alicji klucz symetryczny, Sac i token zabezpieczający dla usługi Currency.

Korzystając z tokenu zabezpieczającego przeznaczonego dla usługi Waluta i skojarzonego klucza symetrycznego, Alice wysyła żądania do usługi Waluta.

Federacja przy użyciu wymiany poświadczeń (KerberosKerberos)

W tym podejściu Adventure456 wydała Alice token zabezpieczający Kerberos, a zasady usługi Walutowej wskazują, że akceptuje tylko tokeny zabezpieczające Kerberos wystawione przez własną usługę tokenu zabezpieczającego, która hermetyzuje swoje centrum dystrybucji kluczy.

W tym miejscu zakładamy, że administratorzy w firmie Adventure456 i Business456 nie chcą ustanawiać wzajemnego zaufania przechodniego, ale są gotowi wymieniać certyfikaty kluczy publicznych w celu federacji zabezpieczeń. Ponadto zakładamy, że zarówno Alice, jak i usługa Waluta obsługują tylko technologię klucza symetrycznego.

Podobnie jak w poprzednim przykładzie usługi tokenów zabezpieczających mają możliwość zapewnienia symetrycznych tokenów zabezpieczających kluczy usługom w domenie zaufania. W związku z tym opisane powyżej podejście działa w tym scenariuszu.

Usługa walidacji

Ten model zabezpieczeń usług sieci Web obsługuje również scenariusze, w których żądający outsources przetwarzania komunikatu i weryfikacji tokenu zabezpieczającego. Należy zauważyć, że nieprawidłowe użycie takiej usługi może powodować problemy ze skalowalnością. Oznacza to, że w zależności od implementacji może być tańsza ( lub droższa) dla usługi do wykonania usługi weryfikacji. Model zabezpieczeń usług sieci Web obsługuje jedną z tych metod, umożliwiając tym samym ten scenariusz.

W tym scenariuszu oddzieliliśmy usługę weryfikacji od usługi tokenu zabezpieczającego. W innych scenariuszach można je połączyć lub mieć bezpośrednią relację zaufania (dlatego nie wymagają WS-Federation).

W tym scenariuszu żądający uzyskuje token zabezpieczający z usługi tokenu zabezpieczającego. Następnie wysyła komunikat do usługi internetowej i zawiera dowód posiadania (np. podpis). Usługa sieci Web wysyła blok podpisu, token zabezpieczający i jego obliczenia skrótu podpisanego do usługi weryfikacji. Usługa walidacji, która jest zaufana przez usługę sieci Web, następnie wystawia prawidłową/nieprawidłową decyzję.

Należy zauważyć, że usługa weryfikacji może wskazać swoją decyzję, wydając token zabezpieczający w imieniu obiektu żądającego, który potwierdza odpowiednie oświadczenia.

Delegowanie pomocnicze

Zabezpieczenia usług sieci Web obsługują delegowanie. Oto zaawansowany scenariusz delegowania zaprojektowany w celu pokazania elastyczności podejścia: Alicja używa kalendarza456 do zarządzania harmonogramem. Chce pozwolić Bobowi na utworzenie spotkania z nią we wtorek. Jednak Bob nie wykonuje planowania bezpośrednio. Zamiast tego Bob używa usługi schedule456, aby skonfigurować spotkania, które należy umieścić w kalendarzu Alicji.

Alice nie wie, jak Bob zaplanuje spotkanie, ale chce ograniczyć zestaw usług, które mogą zobaczyć jej kalendarz

Alice udostępnia Bobowi token zabezpieczający, który umożliwia Bobowi zaplanowanie spotkań w swoim kalendarzu. Ten token zabezpieczający zawiera oświadczenia ograniczające możliwość zaplanowania spotkań do wtorku przez Boba. Ponadto ten token zabezpieczający umożliwia Bobowi wystawianie kolejnych tokenów zabezpieczających, o ile podmioty mogą udowodnić, że mają certyfikat prywatności od TrustUs456, usługi innej firmy.

Ponieważ usługa Schedule456 została poddane inspekcji przez trustUs456, mają token zabezpieczający, który potwierdza ich certyfikację prywatności.

Gdy usługa harmonogramu uzyskuje dostęp do kalendarza Alicji w kalendarzu Calendar456, może udowodnić, że posiada certyfikat prywatności i oświadczenie o dostępie do spotkania i zaplanuje spotkanie na podstawie tokenów zabezpieczających od Alice przez Boba.

Kontrola dostępu

Podczas współpracy Alice i Bob uważają, że często planują spotkania ze sobą i rozwijają poziom zaufania. W związku z tym Alice chce zezwolić Bobowi na planowanie spotkań bez konieczności delegowania do niego za każdym razem. Może zwiększyć wygaśnięcie tokenu zabezpieczającego delegowania, ale będzie musiała je ponownie wydać i jest to problematyczne, jeśli chce odwołać zdolność Boba do planowania spotkań.

Alicja komunikuje się z usługą kalendarza (uwierzytelnia się) i uzyskuje listę autoryzacji. Aktualizuje listę autoryzacji, aby umożliwić Bobowi wyświetlanie jej wolnych/zajętych danych i planowanie spotkań i przesyłanie ich do usługi. Teraz, gdy Bob uzyskuje dostęp do usługi kalendarza dla tych operacji, nie potrzebuje tokenu zabezpieczającego delegowania od Alice.

Inspekcja

W powyższym scenariuszu delegowania możliwe jest, że antagonista może spróbować zaplanować spotkanie bez tokenu zabezpieczającego delegowania lub z wygasłym tokenem zabezpieczającym. W takich przypadkach żądanie zakończy się niepowodzeniem, ponieważ antagonista nie może udowodnić wymaganych roszczeń.

Aby śledzić tego typu działania, usługa może udostępniać funkcje inspekcji. Oznacza to, że w przypadku wystąpienia zdarzenia związanego z zabezpieczeniami, takiego jak uwierzytelnianie lub nieuprawnione oświadczenie lub nieprawidłowy podpis, jest rejestrowane. Administrator może bezpiecznie uzyskać dostęp do dziennika, aby przejrzeć zdarzenia związane z zabezpieczeniami i zarządzać dziennikiem.

Na przykład antagoniści mogą próbować naśladować Boba. Korzystając z narzędzia monitora/zarządzania, administrator zabezpieczeń, Carol, przegląda dziennik inspekcji i widzi, że kalendarz Alicji miał wiele błędów zabezpieczeń. Podczas przeglądania danych widzi, że czasami żądanie Boba kończy się niepowodzeniem, ponieważ jego podpis nie pasuje do wiadomości lub wiadomości są stare (odtwarzane). W rezultacie Carol zbiera rekordy inspekcji do użycia w próbie wytropić antagonistów.

5 . Podsumowanie

Ponieważ usługi sieci Web są stosowane szerzej, ponieważ topologie aplikacji nadal ewoluują, aby obsługiwać pośredników, takich jak zapory, moduły równoważenia obciążenia i centra obsługi komunikatów, a świadomość zagrożeń napotykanych przez organizacje staje się coraz bardziej zrozumiała, potrzeba dodatkowych specyfikacji zabezpieczeń dla usług internetowych rośnie.  W tym dokumencie proponujemy zintegrowany model zabezpieczeń usług sieci Web i zestaw specyfikacji do realizacji tego modelu. Te nowe specyfikacje, rozszerzając i wykorzystując (zamiast zastępowania) istniejącą technologię zabezpieczeń i zasoby, umożliwią klientom i organizacjom szybsze opracowywanie bezpiecznych, współdziałających usług sieci Web.

IBM i Microsoft uważają, że jest to pierwszy krok w zdefiniowaniu kompleksowej strategii zabezpieczeń usług internetowych.  Odzwierciedla on wyzwania i rozwiązania, które zidentyfikowaliśmy do tej pory. Ponieważ nadal współpracujemy z klientami, partnerami i organizacjami standardów w celu zabezpieczenia usług sieci Web, oczekujemy, że będą potrzebne dodatkowe pomysły i specyfikacje niezbędne do ukończenia strategii. 

Współpracowników

Ten dokument został wspólnie utworzony przez ibm i firmę Microsoft.

Kluczowe czynniki obejmują (alfabetycznie): Giovanni Della-Libera, Microsoft; Brendan Dixon, Microsoft; Joel Farrell, IBM; Praerit Garg, Microsoft; Maryann Hondo, IBM; Chris Kaler, Microsoft; Butler Lampon, 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, IBM

Odwołania