Güvenli Web Servisleri: HTTPS üzerinden SOAP + WS-Security üzerinden REST. Hangisi daha iyi? [kapalı]

Hiçbir şekilde bir güvenlik uzmanı değilim, ancak REST tarzı web hizmetleri oluşturmayı tercih ediyorum.

Aktardığı verilerin güvenli olması gereken yeni bir hizmet oluştururken. Hangi yaklaşımın daha güvenli olduğu üzerine bir tartışma yaptık - HTTPS ile REST veya WS-Security ile bir SOAP WS.

Tüm web servis çağrıları için HTTPS kullanabileceğimiz izlenimi altındayım ve bu yaklaşım güvenli olacaktır. Benim bakış açım, "HTTPS banka ve finansal web siteleri için yeterince iyi ise, benim için yeterince iyi" dir. Yine, bu alanda uzman değilim, ama bu insanların bu sorun hakkında oldukça sert düşündüklerini ve HTTPS ile rahat olduklarını düşünüyorum.

Bir iş arkadaşı aynı fikirde değil ve SOAP ve WS-Security'nin tek yol olduğunu söylüyor.

Web tüm bu konuda görünüyor.

Belki buradaki topluluk her birinin artılarını ve eksilerini değerlendirebilir? Teşekkürler!

HTTPS, iletinin ağ üzerinden iletilmesini sağlar ve istemciye sunucunun kimliği konusunda bir miktar güvence sağlar. Bankanız veya çevrimiçi borsa komisyoncunuz için önemli olan budur. İstemcinin kimliğini doğrulamaya olan ilgileri bilgisayarın kimliğiyle değil, kimliğinizle ilgilidir. Böylece kimlik doğrulamak için kart numaraları, kullanıcı adları, şifreler vb. Kullanılır. Daha sonra, gönderilerin tahrif edilmediğinden emin olmak için genellikle bazı önlemler alınır, ancak genel olarak oturumda ne olursa olsun sizin tarafınızdan başlatılmış olarak kabul edilir.

WS-Security, mesajın oluşturulmasından tüketimine kadar gizlilik ve bütünlük koruması sunar. Bu nedenle, iletişim içeriğinin yalnızca doğru sunucu tarafından okunmasını sağlamak yerine, yalnızca sunucudaki doğru işlem tarafından okunmasını sağlar. Güvenli bir şekilde başlatılan oturumdaki tüm iletişimlerin kimliği doğrulanmış kullanıcıdan geldiğini varsaymak yerine her birinin imzalanması gerekir.

Burada çıplak motosikletçileri içeren eğlenceli bir açıklama var:

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

WS-Security, HTTPS'den daha fazla koruma sunar ve SOAP, REST'ten daha zengin bir API sunar. Benim fikrime göre, ek özelliklere veya korumaya gerçekten ihtiyacınız yoksa, SOAP ve WS-Security yükünü atlamanız gerekir. Bunun bir copl-out olduğunu biliyorum, ancak ne kadar korumanın gerçekten haklı olduğuna karar vermek (sadece inşa etmek için neyin iyi olacağını değil), sorunu yakından bilenler tarafından yapılmalıdır.

REST güvenliği, SOAP güvenliği olmadığında aktarıma bağlıdır.

REST, güvenlik önlemlerini temel alınan aktarımdan devralırken SOAP, WS-Security üzerinden kendi tanımını yapar.

REST hakkında konuştuğumuzda, HTTP üzerinden - HTTP uygulanan tüm güvenlik önlemleri devralınır ve buna taşıma düzeyi güvenliği denir.

Taşıma seviyesi güvenliği, mesajınızı yalnızca tel üzerindeyken korur - kablodan çıkar çıkmaz mesaj artık güvenli değildir.

Ancak, WS-Security ile ileti düzeyi güvenliği - ileti taşıma kanalından ayrılsa bile yine de korunacaktır. Ayrıca - mesaj seviyesi güvenliği ile mesajı kısmen [tüm mesajı değil, sadece istediğiniz parçaları] şifreleyebilirsiniz - ancak taşıma seviyesi güvenliği ile bunu yapamazsınız.

WS-Security, kimlik doğrulama, bütünlük, gizlilik ve reddedilmeme önlemleri alırken SSL, reddedilmeyi desteklemiyor [2 aşamalı OAuth ile].

Performans açısından SSL, WS-Security'den çok daha hızlıdır.

Teşekkürler...

Teknik olarak, ifade etme şekliniz de doğru değil çünkü SOAP yönteminin iletişimi güvenli değil ve REST yöntemi meşru kullanıcıların kimlik doğrulaması hakkında hiçbir şey söylemedi.

HTTPS, saldırganların iki sistem arasındaki iletişimi gizlice dinlemesini önler . Ayrıca, ana bilgisayar sisteminin (sunucu) aslında kullanıcının erişmek istediği ana bilgisayar sistemi olduğunu doğrular.

WS-Security, yetkisiz uygulamaların (kullanıcılar) sisteme erişmesini önler.

RESTful sisteminin kullanıcıları doğrulamak için bir yolu varsa ve WS-Security ile bir SOAP uygulaması HTTPS kullanıyorsa, gerçekten her ikisi de güvenlidir. Bu, verileri sunmak ve verilere erişmek için yalnızca farklı bir yöntemdir.

Bkz wiki makalesine:

Noktadan noktaya durumlarda gizlilik ve veri bütünlüğü, örneğin https üzerinden ileti göndererek, Aktarım Katmanı Güvenliği (TLS) kullanılarak Web hizmetlerinde de uygulanabilir.

Bununla birlikte, WS-Security, kaynak düğümden bir ileti gönderilinceye kadar uçtan uca güvenlik adı verilene kadar iletilerin bütünlüğünü ve gizliliğini koruma konusundaki geniş sorunu giderir.

Yani:

• HTTPS bir taşıma katmanı (noktadan noktaya) güvenlik mekanizmasıdır
• WS-Security bir uygulama katmanı (uçtan uca) güvenlik mekanizmasıdır.

Dediğiniz gibi, REST bankalar için yeterince iyi, bu yüzden sizin için yeterince iyi olmalı.

Güvenliğin iki ana yönü vardır: 1) şifreleme ve 2) kimlik.

SSL / HTTPS ile iletim, kablo üzerinden şifreleme sağlar. Ancak, her iki sunucunun da kimle konuştuklarını bildiğini doğrulayabildiğinden emin olmanız gerekir. Bu SSL istemci sertifikaları, paylaşım sırları vb. Yoluyla olabilir.

Eminim bir SOAP "daha güvenli" ama muhtemelen önemli bir şekilde dava yapabilir. Çıplak motosikletçi benzetmesi sevimli ama doğruysa tüm internetin güvensiz olduğunu ima eder.

Henüz bir yorum eklemek için gereken temsilcisi yok ya da bunu Bell'in cevabına ekledim. Bence Bell, iki yaklaşımın üst düzey artılarını ve eksilerini özetlemek için çok iyi bir iş çıkardı. Dikkate almak isteyebileceğiniz diğer birkaç faktör:

1) Müşterileriniz ve hizmetiniz arasındaki taleplerin, yüke erişim gerektiren aracılardan geçmesi gerekiyor mu? Öyleyse, WS-Security daha uygun olabilir.

2) Sunucuya, karşılıklı kimlik doğrulama adı verilen bir özelliği kullanarak istemcinin kimliğine ilişkin güvence sağlamak için SSL kullanmak mümkündür. Ancak, bunu yapılandırmanın karmaşıklığı nedeniyle bazı çok özel senaryoların dışında pek fazla faydalanamaz. Bell doğru, WS-Sec'in burada çok daha iyi olması haklı.

3) Genel olarak SSL, büyük ölçüde sertifika yönetimi sorunları nedeniyle kurulum ve bakım (daha basit yapılandırmada bile) için biraz ayı olabilir. Platformunuz için bunu nasıl yapacağını bilen birine sahip olmak büyük bir artı olacaktır.

4) Bir tür kimlik bilgisi eşlemesi veya kimlik federasyonu yapmanız gerekirse, WS-Sec genel masrafa değebilir. Bunu REST ile yapamayacağınız için değil, size yardımcı olacak daha az yapınız var.

5) Tüm WS-Security goop'larının işlerin istemci tarafında doğru yerlere yerleştirilmesi, düşündüğünüzden çok daha acı verici olabilir.

Sonunda gerçekten bilmemiz pek mümkün olmayan birçok şeye bağlı. Çoğu durumda, her iki yaklaşımın da "yeterince güvenli" olacağını ve bu yüzden ana karar faktörü olmaması gerektiğini söyleyebilirim.

Brace yourself, here there's another coming :-)

Bugün HTTPS'nin aksine WS-Security'nin etkileyici gücü arasındaki farkı kız arkadaşımla açıklamak zorunda kaldım. O bir bilgisayar bilimcisi, bu yüzden tüm XML mumbo jumbo'yu bilmese bile, şifrelemenin veya imzanın ne anlama geldiğini anlıyor (belki de benden daha iyi). Ancak, nasıl uygulandıklarından ziyade, işlerin ne için yararlı olduğunu gerçekten anlayabilen güçlü bir görüntü istedim (biraz sonra geldi, bundan kaçmadı :-)).

Yani böyle gidiyor. Çıplak olduğunuzu ve motosikletinizi belirli bir yere götürmeniz gerektiğini varsayalım. (A) durumunda şeffaf bir tünelden geçersiniz: müstehcen davranışlar için tutuklanmamanın tek umudu kimsenin bakmamasıdır. Bu tam olarak ortaya çıkabilecek en güvenli strateji değil ... (adam alın :-) ter düşüş dikkat edin). Bu açıkça bir POST'a eşdeğerdir ve "eşdeğer" dediğimde bunu kastediyorum. (B) durumunda, daha iyi bir durumdasınız. Tünel opaktır, bu yüzden içine girdiğiniz sürece genel kaydınız güvenlidir. Ancak, bu hala en iyi durum değildir. Hala evden ayrılıp tünel girişine ulaşmalısınız ve muhtemelen tünelin dışına çıkıp bir yere gitmeniz gerekecek ... ve bu HTTPS için geçerli. Doğru, mesajınız en büyük uçurumdan geçerken güvenlidir: ancak diğer tarafa ilettiğinizde, verilerin işleneceği gerçek noktaya ulaşmadan önce kaç aşamadan geçmesi gerektiğini bilmezsiniz. Ve elbette tüm bu aşamalar HTTP'den farklı bir şey kullanabilir: örneğin, hemen sunulamayan istekleri arabelleğe alan klasik bir MSMQ. Birisi bu önişleme limbodayken verilerinizi gizliyorsa ne olur? Hm. (bu "hm" yi, "nefes aldığınızın hava olduğunu mu düşünüyorsunuz?" cümlesinin sonunda Morpheus'un söylediği gibi okuyun.). Bu metafordaki tam çözüm (c) acı verici bir öneme sahiptir: kendinize ve özellikle motosikletteyken kask giydirin! Böylece ortamların saydamlığına güvenmek zorunda kalmadan güvenle dolaşabilirsiniz. Metafor umarım açıktır: kıyafetler, mesaj seviyesinin güvenliğinin yaptığı gibi, ortalama veya çevre altyapısından bağımsız olarak yanınızda gelir. Ayrıca, bir parçayı kapsamaya karar verebilir, ancak bir başkasını açığa çıkarabilirsiniz (ve bunu kişisel olarak yapabilirsiniz: havaalanı güvenliği, doktorunuz daha yüksek bir erişim seviyesine sahipken ceketinizi ve ayakkabılarınızı çıkarabilir), ancak kısa kollu gömleklerin pazı ile gurur duysanız bile kötü uygulama :-) (daha iyi bir polo veya bir t-shirt).

Konuyu anladığını söylemekten mutluluk duyuyorum! Giysiler metaforunun çok güçlü olduğunu söylemeliyim: Politika kavramını tanıtmak için kullanmak istedim (disko kulüpleri spor ayakkabılarına izin vermez; iç çamaşırınızdaki bir bankada para çekemezsiniz) , bu bir sörf üzerinde kendinizi dengelerken mükemmel kabul edilebilir bir görünüm olsa da; vb.) ama bir öğleden sonra için yeterli olduğunu düşündüm ;-)

Mimari - WS, Vahşi Fikirler

Nezaket: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

Her gün bu alanda çalışıyorum, bu yüzden bunu kapatmak için bu konudaki iyi yorumları özetlemek istiyorum:

SSL (HTTP / s) yalnızca tek bir katmandır:

1. Bağlı olan sunucu kimliğini kanıtlayan bir sertifika sunar (ancak DNS zehirlenmesi yoluyla taklit edilebilir).
2. İletişim katmanı şifreli (gizlice dinleme yok).

WS-Security ve ilgili standartlar / uygulamalar PKI kullanır:

1. Müşterinin kimliğini kanıtlayın.
2. İletinin geçiş sırasında değiştirilmediğini kanıtlayın (MITM).
3. Sunucunun istemcinin kimliğini doğrulamasına / yetkilendirmesine izin verir.

Son nokta, istemcinin (arayan) kimliği, hizmetten bu tür verileri almaya yetkili olup olmadıklarını bilmede çok önemli olduğunda hizmet talepleri için önemlidir. Standart SSL tek yönlü (sunucu) kimlik doğrulamasıdır ve istemciyi tanımlamak için hiçbir şey yapmaz.

Cevap aslında sizin özel gereksinimlerinize bağlıdır.

Örneğin, web iletilerinizi korumanız mı gerekiyor yoksa gizlilik gerekmiyor mu? Tek ihtiyacınız olan son tarafların kimliğini doğrulamak ve ileti bütünlüğünü sağlamak mı? Durum böyleyse - ve genellikle web hizmetlerinde ise - HTTPS muhtemelen yanlış çekiçtir.

Ancak - deneyimlerime göre - inşa ettiğiniz sistemin karmaşıklığını göz ardı etmeyin. Yalnızca HTTPS'nin doğru şekilde dağıtılması daha kolay değildir, aynı zamanda aktarım katmanı güvenliğine dayanan bir uygulamanın hata ayıklaması daha kolaydır (düz HTTP üzerinden).

İyi şanslar.

HTTPS Üzerinden REST API sağlayıcı bir sunucu sonu yetkilendirmesi uyguladığı sürece güvenli bir yöntem olmalıdır. Web uygulamasında da yaptığımız şey HTTPS ve bazı kimlik doğrulama / yetkilendirme yoluyla bir web uygulamasına erişmektir, geleneksel olarak web uygulamalarının güvenlik sorunları yoktu, o zaman Restful API güvenlik sorunlarını da sorunsuz bir şekilde karşılayacaktır!

RESTFul çağrınız HTTP isteğinin Html Gövdesine gömülü XML İletileri gönderse, hangi güvenlik özelliklerini kullanırken XML iletilerinizde XML şifrelemesi, Cerificates vb. SSL / TLS şifrelemesi gibi http'den edinilebilir.