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

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!

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.

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...

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.

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).

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.

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.

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

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.

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.

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!

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.