Bezpieczne usługi internetowe: REST przez HTTPS vs SOAP + WS-Security. Co jest lepsze? [Zamknięte]

183

W żadnym wypadku nie jestem ekspertem od bezpieczeństwa, ale wolę tworzyć usługi sieciowe w stylu REST.

Tworząc nową usługę, która musi mieć bezpieczne przesyłane dane. Rozpoczęliśmy debatę nad tym, które podejście jest bezpieczniejsze - REST z HTTPS czy SOAP WS z WS-Security.

Mam wrażenie, że moglibyśmy używać protokołu HTTPS do wszystkich wywołań usług internetowych i takie podejście byłoby bezpieczne. Sposób, w jaki na to patrzę, jest następujący: „jeśli HTTPS jest wystarczająco dobry dla witryn bankowych i finansowych, to jest wystarczająco dobry dla mnie”. Ponownie, nie jestem ekspertem w tej dziedzinie, ale myślę, że ci ludzie poważnie przemyśleli ten problem i czują się dobrze z HTTPS.

Współpracownik nie zgadza się i mówi, że SOAP i WS-Security to jedyne możliwe rozwiązanie.

Wydaje się, że sieć jest na całej planszy.

Może społeczność tutaj mogłaby rozważyć zalety i wady każdego z nich? Dzięki!

Vinnie
źródło
9
jest to w zasadzie wybór zabezpieczeń na poziomie transportu i zabezpieczeń na poziomie wiadomości
flash
Wystarczy dodać .. iseebug.com/category/web-service
Vaibs

Odpowiedzi:

135

HTTPS zabezpiecza transmisję wiadomości przez sieć i zapewnia klientowi pewność co do tożsamości serwera. To jest ważne dla Twojego banku lub maklera giełdowego online. Ich zainteresowanie uwierzytelnianiem klienta nie leży w tożsamości komputera, ale w twojej tożsamości. Tak więc numery kart, nazwy użytkowników, hasła itp. Służą do uwierzytelnienia. Następnie zwykle podejmuje się pewne środki ostrożności, aby zapewnić, że zgłoszenia nie zostały zmodyfikowane, ale ogólnie rzecz biorąc, cokolwiek wydarzy się podczas sesji, jest uważane za zainicjowane przez Ciebie.

WS-Security zapewnia poufność i ochronę integralności od utworzenia wiadomości do jej użycia. Dlatego zamiast zapewnić, że treść wiadomości może być odczytana tylko przez właściwy serwer, zapewnia to, że może ona zostać odczytana tylko przez właściwy proces na serwerze. Zamiast zakładać, że cała komunikacja w bezpiecznie zainicjowanej sesji pochodzi od uwierzytelnionego użytkownika, każdy z nich musi być podpisany.

Jest tutaj zabawne wyjaśnienie dotyczące nagich motocyklistów:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

Tak więc WS-Security oferuje lepszą ochronę niż HTTPS, a SOAP oferuje bogatsze API niż REST. Moim zdaniem, jeśli naprawdę nie potrzebujesz dodatkowych funkcji lub ochrony, powinieneś pominąć narzut SOAP i WS-Security. Wiem, że to trochę wykrętka, ale decyzje o tym, ile ochrony jest w rzeczywistości uzasadnione (a nie tylko co byłoby fajne do zbudowania), muszą być podejmowane przez tych, którzy dobrze znają problem.

dzwon
źródło
Dodatkowy punkt - bezpieczeństwo transmisji wymaga uwierzytelnienia inicjatora transmisji. Na przykład nie warto mieć SSH, jeśli wszyscy znają hasło. W aplikacjach rozproszonych kluczowe znaczenie ma wielowarstwowe bezpieczeństwo. Myśl o tożsamości, uczciwości, odpowiedzialności
Aiden Bell
20
Niedawno widziałem interesującą mieszankę. Nasz duży klient F500 używa mieszanki REST i SOAP (REST do dostępu do danych tylko do odczytu, SOAP do reszty) i aby uniknąć używania różnych schematów zabezpieczeń, zdecydował się na użycie WS-Sec do obu. Robią to, umieszczając informacje nagłówka WS-Sec w nagłówkach HTTP dla wywołań REST. Ich pośrednik ds. Bezpieczeństwa wie, jak wyciągnąć ich z dowolnej lokalizacji, aby przeprowadzić kontrole. Pierwszy raz widziałem takie podejście.
sfitts
66

Zabezpieczenia REST są zależne od transportu, a zabezpieczenia SOAP nie.

REST dziedziczy środki bezpieczeństwa z transportu bazowego, podczas gdy SOAP definiuje własne za pośrednictwem WS-Security.

Kiedy mówimy o REST, przez HTTP - wszystkie zastosowane środki bezpieczeństwa HTTP są dziedziczone i jest to znane jako bezpieczeństwo na poziomie transportu.

Zabezpieczenie na poziomie transportu, zabezpiecza twoją wiadomość tylko wtedy, gdy jest na kablu - gdy tylko opuści przewód, wiadomość nie jest już zabezpieczona.

Ale dzięki WS-Security jego bezpieczeństwo na poziomie wiadomości - nawet jeśli wiadomość opuszcza kanał transportowy, będzie nadal chroniona. Ponadto - dzięki zabezpieczeniom na poziomie wiadomości możesz częściowo zaszyfrować wiadomość [nie całą wiadomość, ale tylko wybrane części] - ale z zabezpieczeniem na poziomie transportu nie możesz tego zrobić.

WS-Security ma środki do uwierzytelniania, integralności, poufności i niezaprzeczalności, podczas gdy SSL nie obsługuje niezaprzeczalności [w przypadku dwuetapowej autoryzacji OAuth].

Pod względem wydajności SSL jest znacznie szybszy niż WS-Security.

Dzięki...

Prabath Siriwardena
źródło
1
Przepraszam, ale muszę to poprawić. Spójrz na Wiki dla REST : REST został początkowo opisany w kontekście HTTP, ale nie jest ograniczony do tego protokołu. SOAP nie ma nic wspólnego z zabezpieczeniami WS-Security i obie implementacje REST / SOAP do pewnego stopnia opierają się w każdym przypadku na podstawowym transporcie. SOAP jest oparty na języku XML i dlatego WS-Security został później ułożony jako implementacja bezpieczeństwa danych aplikacji. W przeciwnym razie dobre informacje.
Darrell Teague
13
Jak wspomniałem powyżej, REST nie zależy od konkretnego transportu - chociaż w większości przypadków było to wyjaśniane w kontekście HTTP. Ale REST nie mówi o żadnym bezpieczeństwie, całkowicie polega na transporcie bazowym dla bezpieczeństwa - niech to będzie HTTP lub cokolwiek. W SOAP - jasno definiuje standard bezpieczeństwa niezależny od transportu. WS-Security jest przeznaczony dla protokołu SOAP. Jeśli chcesz używać bezpieczeństwa na poziomie transportu z SOAP, nie ma problemu, możesz go użyć. REST to wzorzec architektoniczny, nie mówi o bezpieczeństwie.
Prabath Siriwardena,
Super Prabath! Dzięki temu było przydatne
sunleo
22

Technicznie rzecz biorąc, sposób, w jaki to sformułowano, też nie jest poprawny, ponieważ komunikacja metody SOAP nie jest bezpieczna, a metoda REST nie mówi nic o uwierzytelnianiu uprawnionych użytkowników.

HTTPS zapobiega podsłuchiwaniu komunikacji między dwoma systemami. Sprawdza również, czy system hosta (serwer) jest w rzeczywistości systemem hosta, do którego użytkownik zamierza uzyskać dostęp.

WS-Security uniemożliwia nieautoryzowanym aplikacjom (użytkownikom) dostęp do systemu.

Jeśli system zgodny z REST ma sposób na uwierzytelnianie użytkowników, a aplikacja SOAP z WS-Security korzysta z protokołu HTTPS, to naprawdę oba są bezpieczne. To tylko inny sposób prezentowania i uzyskiwania dostępu do danych.

kemiller2002
źródło
19

Zobacz artykuł wiki :

W sytuacjach typu punkt-punkt poufność i integralność danych można również egzekwować w usługach sieci Web za pomocą protokołu Transport Layer Security (TLS), na przykład wysyłając wiadomości za pośrednictwem protokołu HTTPS.

WS-Security rozwiązuje jednak szerszy problem utrzymania integralności i poufności wiadomości do momentu wysłania wiadomości z węzła źródłowego, zapewniając tzw. Bezpieczeństwo od końca do końca.

To jest:

  • HTTPS to mechanizm zabezpieczeń warstwy transportowej (punkt-punkt)
  • WS-Security to mechanizm zabezpieczeń warstwy aplikacji (end-to-end).
zestaw narzędzi
źródło
15

Jak mówisz, REST jest wystarczająco dobry dla banków, więc powinien być wystarczająco dobry dla Ciebie.

Istnieją dwa główne aspekty bezpieczeństwa: 1) szyfrowanie i 2) tożsamość.

Transmisja w SSL / HTTPS zapewnia szyfrowanie przez kabel. Ale musisz też upewnić się, że oba serwery mogą potwierdzić, że wiedzą, z kim rozmawiają. Może to być za pośrednictwem certyfikatów klienta SSL, udostępnionych tajemnic itp.

Jestem pewien, że można by powiedzieć, że SOAP jest „bezpieczniejszy”, ale prawdopodobnie nie w żaden znaczący sposób. Analogia nagiego motocyklisty jest urocza, ale jeśli jest trafna, oznaczałoby to, że cały internet jest niepewny.

pbreitenbach
źródło
13

Nie mam jeszcze przedstawiciela potrzebnego do dodania komentarza lub po prostu dodałbym to do odpowiedzi Bella. Myślę, że Bell wykonał bardzo dobrą robotę podsumowując zalety i wady obu podejść na najwyższym poziomie. Tylko kilka innych czynników, które warto rozważyć:

1) Czy żądania między klientami a usługą muszą przechodzić przez pośredników, którzy wymagają dostępu do ładunku? Jeśli tak, to WS-Security może być lepszym rozwiązaniem.

2) W rzeczywistości możliwe jest użycie SSL, aby zapewnić serwerowi pewność co do tożsamości klientów za pomocą funkcji zwanej wzajemnym uwierzytelnianiem. Jednak nie ma to większego zastosowania poza niektórymi bardzo wyspecjalizowanymi scenariuszami ze względu na złożoność konfiguracji. Bell ma więc rację, że WS-Sec jest tutaj o wiele lepiej dopasowany.

3) SSL ogólnie może być trochę trudny do skonfigurowania i utrzymania (nawet w prostszej konfiguracji), głównie ze względu na problemy z zarządzaniem certyfikatami. Posiadanie kogoś, kto wie, jak to zrobić dla Twojej platformy, będzie dużym plusem.

4) Jeśli może być konieczne wykonanie jakiejś formy mapowania poświadczeń lub federacji tożsamości, WS-Sec może być wart narzutu. Nie znaczy to, że nie możesz tego zrobić z REST, po prostu masz mniej struktury, która ci pomoże.

5) Umieszczenie całego oprogramowania WS-Security we właściwych miejscach po stronie klienta może być bardziej uciążliwe niż myślisz, że powinno.

W końcu zależy to od wielu rzeczy, których prawdopodobnie nie będziemy wiedzieć. W większości sytuacji powiedziałbym, że każde podejście będzie „wystarczająco bezpieczne”, a więc nie powinno to być głównym czynnikiem decydującym.

sfitts
źródło
Bankowość to jedna z tych sytuacji, w których nie ma „większości”.
Bryan Bryce,
11
Brace yourself, here there's another coming :-)

Dzisiaj musiałem wyjaśnić mojej dziewczynie różnicę między wyrazistą mocą WS-Security a HTTPS. Jest informatykiem, więc nawet jeśli nie zna wszystkich bzdurnych XML-jumbo, rozumie (może lepiej ode mnie), co oznacza szyfrowanie lub podpis. Zależało mi jednak na mocnym wizerunku, który pozwoliłby jej naprawdę zrozumieć, do czego rzeczy się przydają, a nie jak są one realizowane (to przyszło nieco później, nie umknęła jej :-)).

Więc to wygląda tak. Załóżmy, że jesteś nagi i musisz jechać motocyklem w określone miejsce. W przypadku (A) przechodzisz przez przezroczysty tunel: jedyną nadzieją na to, że nie zostaniesz aresztowany za nieprzyzwoite zachowanie, jest to, że nikt nie patrzy. To nie jest najbezpieczniejsza strategia, z jaką możesz wyjść ... (zwróć uwagę na kroplę potu z czoła faceta :-)). Jest to równoznaczne z jawnym postem POST, a kiedy mówię „równoważny”, mam to na myśli. W przypadku (B) jesteś w lepszej sytuacji. Tunel jest nieprzejrzysty, więc dopóki w nim się znajdujesz, Twój publiczny rejestr jest bezpieczny. Jednak nadal nie jest to najlepsza sytuacja. Nadal musisz wyjść z domu i dotrzeć do wejścia do tunelu, a gdy znajdziesz się poza tunelem, prawdopodobnie będziesz musiał wysiąść i gdzieś iść ... i to dotyczy protokołu HTTPS. Prawdziwe, Twoja wiadomość jest bezpieczna, gdy przekracza największą przepaść: ale kiedy dostarczysz ją po drugiej stronie, tak naprawdę nie wiesz, przez ile etapów będzie musiała przejść, zanim dotrze do rzeczywistego punktu, w którym dane zostaną przetworzone. I oczywiście na wszystkich tych etapach może być używane coś innego niż HTTP: na przykład klasyczny MSMQ, który buforuje żądania, których nie można obsłużyć od razu. Co się stanie, jeśli ktoś czai się w twoich danych, będąc w stanie zawieszenia przetwarzania wstępnego? Hm. (przeczytaj to „hm” jako wypowiedziane przez Morfeusza na końcu zdania „czy myślisz, że oddychasz powietrzem?”). Kompletne rozwiązanie (c) w tej metaforze jest do bólu banalne: załóż na siebie jakieś cholerne ciuchy, a zwłaszcza kask na motocyklu !!! Możesz więc bezpiecznie poruszać się po okolicy bez konieczności polegania na nieprzezroczystości otoczenia. Miejmy nadzieję, że metafora jest jasna: ubrania są z tobą niezależnie od średniej lub otaczającej infrastruktury, tak jak robi to ochrona na poziomie wiadomości. Co więcej, możesz zdecydować się na zakrycie jednej części, ale ujawnienie innej (i możesz to zrobić osobiście: ochrona lotniska może zdjąć kurtkę i buty, podczas gdy lekarz może mieć wyższy poziom dostępu), ale pamiętaj, że koszule z krótkim rękawem są zły trening, nawet jeśli jesteś dumny ze swoich bicepsów :-) (lepiej polo lub t-shirt).

Z radością mogę powiedzieć, że zrozumiała! Muszę powiedzieć, że metafora ubioru jest bardzo mocna: kusiło mnie, aby go użyć do wprowadzenia koncepcji polisy (kluby disco nie wpuszczą cię w butach sportowych; nie możesz iść po pieniądze do banku w bieliźnie , co prawda to jak najbardziej akceptowalny wygląd podczas balansowania na surfingu; i tak dalej), ale pomyślałem, że na jedno popołudnie wystarczy ;-)

Architektura - WS, Wild Ideas

Dzięki uprzejmości: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

taus-iDeveloper
źródło
1
Ładna i prosta analogia, którą podałeś, aby odróżnić https i ws-security. Ale w prawdziwym Internecie, właściwie przez większość czasu jeździmy na naszym motocyklu nago: D i stosowanie WS-secuirty wszędzie byłoby przesadą pod względem wydajności i kosztów. Możemy więc zaimprowizować tę analogię, biorąc pod uwagę te sytuacje, w których musimy się ubrać, a zakładanie ubrań byłoby niepotrzebne.
shashankaholic
9

Pracuję w tej przestrzeni codziennie, więc chciałbym podsumować dobre komentarze na ten temat, starając się to zamknąć:

SSL (HTTP / s) to tylko jedna warstwa zapewniająca:

  1. Serwer, z którym łączy się połączenie, przedstawia certyfikat potwierdzający jego tożsamość (chociaż można to sfałszować poprzez zatruwanie DNS).
  2. Warstwa komunikacyjna jest szyfrowana (bez podsłuchiwania).

WS-Security i powiązane standardy / implementacje używają PKI, które:

  1. Udowodnij tożsamość klienta.
  2. Udowodnij, że wiadomość nie została zmodyfikowana podczas przesyłania (MITM).
  3. Umożliwia serwerowi uwierzytelnianie / autoryzację klienta.

Ostatni punkt jest ważny w przypadku zgłoszeń serwisowych, gdy tożsamość klienta (dzwoniącego) jest najważniejsza, aby wiedzieć, czy powinien on być upoważniony do otrzymywania takich danych z usługi. Standardowy protokół SSL to uwierzytelnianie jednokierunkowe (serwer) i nie służy do identyfikacji klienta.

Darrell Teague
źródło
5

Odpowiedź w rzeczywistości zależy od Twoich konkretnych wymagań.

Na przykład, czy musisz chronić swoje wiadomości internetowe, czy też poufność nie jest wymagana, a wszystko, czego potrzebujesz, to uwierzytelnić strony końcowe i zapewnić integralność wiadomości? W takim przypadku - i często tak jest w przypadku usług internetowych - HTTPS jest prawdopodobnie niewłaściwym narzędziem.

Jednak - z mojego doświadczenia - nie zapomnij o złożoności systemu, który budujesz. Nie tylko HTTPS jest łatwiejszy do prawidłowego wdrożenia, ale aplikacja, która opiera się na zabezpieczeniach warstwy transportowej, jest łatwiejsza do debugowania (przez zwykły HTTP).

Powodzenia.

user105991
źródło
5

REST przez HTTPS Powinien być bezpieczną metodą, o ile dostawca API implementuje autoryzację po stronie serwera. W przypadku aplikacji sieciowej to, co robimy, to uzyskiwanie dostępu do aplikacji internetowej za pośrednictwem protokołu HTTPS i niektórych uwierzytelnień / autoryzacji, tradycyjnie aplikacje internetowe nie miały problemów z bezpieczeństwem, a Restful API również bez problemu rozwiązałoby problemy z bezpieczeństwem!

Rakesh Waghela
źródło
4

Jeśli wywołanie RESTFul wysyła wiadomości XML tam iz powrotem osadzone w treści HTML żądania HTTP, powinieneś mieć wszystkie zalety WS-Security, takie jak szyfrowanie XML, certyfikaty itp. W wiadomościach XML, korzystając z dowolnych funkcji bezpieczeństwa są dostępne z http, takie jak szyfrowanie SSL / TLS.

LRJ
źródło