Bezpieczne Usługi internetowe: reszta przez HTTPS vs SOAP + ws-bezpieczeństwo. Co jest lepsze? [zamknięte]

REST security jest zależny od transportu, podczas gdy soap security nie jest.

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

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

Bezpieczeństwo na poziomie transportu, zabezpiecza wiadomość tylko wtedy, gdy jest na przewodzie - jak tylko opuści przewód, wiadomość nie jest już zabezpieczona.

Ale, z WS-Security, jego poziom bezpieczeństwa wiadomości - nawet jeśli wiadomość opuszcza kanał transportowy będzie nadal chroniony. Ponadto-z zabezpieczeniem poziomu wiadomości można częściowo zaszyfrować wiadomość [nie całą wiadomość, ale tylko części, które chcesz] - ale z zabezpieczeniem poziomu transportu nie można tego zrobić.

WS-Security ma środki uwierzytelniania, integralności, poufności i non-repudiation, podczas gdy SSL nie obsługuje non repudiation [z 2-legged OAuth to robi].

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

Technicznie, sposób, w jaki to napisałeś, ani nie jest poprawny, ponieważ komunikacja metody SOAP nie jest Bezpieczna, a reszta metoda nie mówiła nic o uwierzytelnianiu legalnych użytkowników.

HTTPS zapobiega atakującym przed podsłuchiwaniem komunikacji między dwoma systemami. Sprawdza również, czy system hosta (serwer) jest faktycznie systemem hosta, do którego użytkownik zamierza uzyskać dostęp.

WS-Security zapobiega dostępowi nieautoryzowanych aplikacji (użytkowników) system.

Jeśli system RESTful ma sposób uwierzytelniania użytkowników, a aplikacja SOAP z WS-Security korzysta z HTTPS, to tak naprawdę oba są bezpieczne. To po prostu inny sposób prezentacji i dostępu do danych.

Zobacz wiki Artykuł:

W sytuacjach punkt-punkt poufność i integralność danych mogą być również egzekwowane w usługach internetowych poprzez wykorzystanie TLS (Transport Layer Security), na przykład poprzez wysyłanie wiadomości przez https.

WS-Security rozwiązuje jednak szerszy problem zachowania integralności i poufności wiadomości aż do momentu wysłania wiadomości z węzła wyjściowego, zapewniając tzw. end to end security.

Że jest:

[13]}HTTPS jest mechanizmem bezpieczeństwa warstwy transportowej (point-to-point)
• WS-Security jest mechanizmem bezpieczeństwa warstwy aplikacji (end-to-end).

Jak mówisz, odpoczynek 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 przewód. Ale musisz również upewnić się, że oba serwery mogą potwierdzić, że wiedzą, z kim rozmawiają. Może to być za pośrednictwem certyfikatów klientów SSL, akcji tajemnic itp.

Na pewno można by powiedzieć, że mydło jest "bezpieczniejsze", ale chyba nie w żadnym znaczący sposób. Analogia nagiego motocyklisty jest urocza, ale jeśli jest dokładna, oznacza to, że cały internet jest niepewny.

Nie mam jeszcze rep potrzebnego do dodania komentarza, bo po prostu dodałbym to do odpowiedzi Bella. Myślę, że Bell wykonał bardzo dobrą robotę, podsumowując najlepsze plusy i minusy obu podejść. Tylko kilka innych czynników, które warto wziąć pod uwagę:

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

2) faktycznie możliwe jest użycie SSL zapewnienie serwerowi pewności 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 rację, że WS-Sec jest tu o wiele lepiej dopasowany.

3) SSL w ogóle może być trochę uciążliwe dla konfiguracji i utrzymania (nawet w prostszej konfiguracji) ze względu na głównie problemy z zarządzaniem certyfikatami. Mieć kogoś, kto wie, jak to zrobić dla Twojego platforma będzie dużym plusem.

4) jeśli potrzebujesz zrobić jakąś formę mapowania poświadczeń lub federacji tożsamości, to WS-Sec może być wart narzutu. Nie to, że nie możesz tego zrobić z odpoczynkiem, po prostu masz mniej struktury, aby ci pomóc.

5) umieszczenie wszystkich WS-Security goop we właściwych miejscach po stronie klienta może być bardziej bolesne niż myślisz, że powinno.

W końcu, choć to naprawdę zależy od wielu rzeczy, których prawdopodobnie nie będziemy wiedzieć. Na w większości sytuacji powiedziałbym, że oba podejścia będą "wystarczająco bezpieczne" i 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 ekspresywną mocą WS-Security w przeciwieństwie do HTTPS. Jest informatykiem, więc nawet jeśli nie zna całego XML, to rozumie (może lepiej ode mnie), co oznacza szyfrowanie lub podpis. Zależało mi jednak na mocnym wizerunku, który sprawiłby, że naprawdę zrozumiałaby, do czego rzeczy są przydatne, a nie jak są realizowane (to przyszło nieco później, nie uniknęła tego :-)).

So it goes w ten sposób. Załóżmy, że jesteś nagi i musisz jechać motocyklem do określonego miejsca docelowego. 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, jaką możesz wymyślić... (zauważ kroplę potu z czoła faceta: -)). To jest równoznaczne z postem w jasny, a kiedy mówię "równoważny"mam na myśli. W przypadku (B) jesteś w lepszej sytuacji. Tunel jest nieprzezroczyste, tak długo, jak podróżujesz do niego, twoje publiczne akta są bezpieczne. Jednak nadal nie jest to najlepsza sytuacja. Musisz jeszcze wyjść z domu i dotrzeć do wejścia do tunelu, a gdy już wyjdziesz z tunelu, prawdopodobnie będziesz musiał wysiąść i gdzieś iść... i to dotyczy HTTPS. To prawda, że Twoja wiadomość jest Bezpieczna, gdy przecina największą przepaść: Ale kiedy dostarczysz ją po drugiej stronie, tak naprawdę nie wiesz, ile etapów będzie musiała przejść, zanim dotrze do prawdziwego punktu, w którym dane będą przetwarzane. I oczywiście wszystkie te etapy mogłyby używać czegoś innego niż HTTP: klasycznego MSMQ, który buforuje żądania, które nie mogą być od razu obsłużone, na przykład. Co się stanie, jeśli ktoś czai Twoje dane, gdy znajduje się w tej zawieszeniu 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 boleśnie trywialne: ubierz się i zwłaszcza kask podczas jazdy na motocyklu!!! Dzięki temu można bezpiecznie poruszać się bez konieczności polegania na nieprzejrzystości otoczenia. Mam nadzieję, że metafora jest jasna: ubrania przychodzą z Tobą niezależnie od średniej lub otaczającej infrastruktury, tak jak bezpieczeństwo na poziomie messsage. Co więcej, możesz zdecydować się na pokrycie 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 to zła praktyka, nawet jeśli jesteś dumny ze swoich bicepsów : -) (lepiej polo, albo t-shirt).

Architektura-ws, Dzikie Pomysły

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 każdego dnia, więc chcę podsumować dobre komentarze na ten temat, starając się to zakończyć:

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

1. podłączony serwer przedstawia certyfikat potwierdzający jego tożsamość (choć może to być sfałszowane przez zatrucie DNS).
2. warstwa komunikacyjna jest szyfrowana (brak podsłuchu).

WS-Bezpieczeństwo i pokrewne standardy/implementacje używają PKI, które:

1. udowodnij tożsamość klienta.
2. udowodnij, że wiadomość nie została zmodyfikowana in-transit (MITM).
3. pozwala serwerowi uwierzytelnić/autoryzować klient.

Ostatni punkt jest ważny dla zgłoszeń serwisowych, gdy tożsamość klienta (dzwoniącego) jest najważniejsza, aby wiedzieć, czy powinien być upoważniony do otrzymywania takich danych z serwisu. Standard SSL to uwierzytelnianie jednokierunkowe (serwerowe) i nie robi nic, aby zidentyfikować klienta.

Odpowiedź rzeczywiście zależy od konkretnych wymagań.

Na przykład, czy musisz chronić swoje wiadomości internetowe lub poufność nie jest wymagana, a wszystko, czego potrzebujesz, to uwierzytelnienie stron końcowych i zapewnienie integralności wiadomości? Jeśli tak jest - i często jest tak w przypadku usług internetowych-HTTPS jest prawdopodobnie złym młotkiem.

Jednak-z mojego doświadczenia-nie przeocz złożoności budowanego systemu. Nie tylko HTTPS jest łatwiejszy do prawidłowego wdrożenia, ale aplikacja oparta na zabezpieczeniach warstwy transportowej jest łatwiejsza do debugowania (poprzez zwykły HTTP).

Powodzenia.

REST przez HTTPS powinien być bezpieczną metodą, o ile dostawca API wdraża autoryzację końca serwera. W przypadku aplikacji webowej, jak również to, co robimy, to uzyskiwanie dostępu do aplikacji webowej poprzez HTTPS i niektóre uwierzytelnianie/autoryzację, tradycyjnie aplikacje internetowe nie miały problemów z bezpieczeństwem, a Restful API również bez problemu przeciwdziałałoby problemom z bezpieczeństwem !

Jeśli wywołanie RESTFul wysyła wiadomości XML tam i z powrotem osadzone w treści Html żądania HTTP, powinieneś mieć wszystkie zalety WS-Security, takie jak szyfrowanie XML, Cerificates, itp w wiadomościach XML podczas korzystania z jakichkolwiek funkcji bezpieczeństwa dostępnych z http, takich jak szyfrowanie SSL / TLS.