การรักษาความปลอดภัยบริการเว็บ: พักผ่อนมากกว่า HTTPS กับ SOAP + WS-Security ไหนดีกว่ากัน [ปิด]

ฉันไม่ได้เป็นผู้เชี่ยวชาญด้านความปลอดภัย แต่อย่างใดฉันชอบสร้างบริการเว็บ REST

ในการสร้างบริการใหม่ที่จำเป็นต้องมีข้อมูลที่จะส่งผ่านความปลอดภัย เราได้ถกเถียงกันว่าแนวทางใดปลอดภัยกว่า - REST กับ HTTPS หรือ SOAP WS ด้วย WS-Security

ฉันอยู่ภายใต้การแสดงผลที่เราสามารถใช้ HTTPS สำหรับการเรียกใช้บริการเว็บทั้งหมดและวิธีการนี้จะปลอดภัย วิธีที่ฉันดูคือ "ถ้า HTTPS ดีพอสำหรับเว็บไซต์ธนาคารและการเงินก็ดีพอสำหรับฉัน" อีกครั้งฉันไม่ใช่ผู้เชี่ยวชาญในพื้นที่นี้ แต่ฉันคิดว่าคนเหล่านี้คิดอย่างหนักเกี่ยวกับปัญหานี้และยินดีที่จะใช้ HTTPS

ผู้ร่วมงานไม่เห็นด้วยและบอกว่า SOAP และ WS-Security เป็นวิธีเดียวที่จะไป

เว็บดูเหมือนทั่วกระดานในเรื่องนี้

บางทีชุมชนที่นี่อาจชั่งน้ำหนักในข้อดีและข้อเสียของแต่ละคน? ขอบคุณ!

HTTPS รักษาความปลอดภัยการส่งข้อความผ่านเครือข่ายและให้ความมั่นใจกับลูกค้าเกี่ยวกับตัวตนของเซิร์ฟเวอร์ นี่คือสิ่งสำคัญสำหรับธนาคารหรือนายหน้าซื้อขายหุ้นออนไลน์ของคุณ ความสนใจของพวกเขาในการพิสูจน์ตัวตนลูกค้าไม่ได้อยู่ในตัวตนของคอมพิวเตอร์ แต่ในตัวตนของคุณ ดังนั้นหมายเลขบัตรชื่อผู้ใช้รหัสผ่าน ฯลฯ จึงใช้เพื่อรับรองความถูกต้องของคุณ ข้อควรระวังบางอย่างนั้นมักจะถูกนำมาใช้เพื่อให้แน่ใจว่าการส่งนั้นไม่ได้รับการแก้ไข แต่โดยรวมแล้วสิ่งที่เกิดขึ้นในเซสชั่นถือเป็นการเริ่มต้นโดยคุณ

WS-Security นำเสนอการรักษาความลับและการป้องกันความสมบูรณ์จากการสร้างข้อความถึงปริมาณการใช้ ดังนั้นแทนที่จะตรวจสอบให้แน่ใจว่าเนื้อหาของการสื่อสารสามารถอ่านได้โดยเซิร์ฟเวอร์ที่ถูกต้องเท่านั้นทำให้มั่นใจได้ว่ากระบวนการที่ถูกต้องบนเซิร์ฟเวอร์สามารถอ่านได้ แทนที่จะสมมติว่าการสื่อสารทั้งหมดในเซสชันที่เริ่มต้นอย่างปลอดภัยมาจากผู้ใช้ที่ได้รับการรับรองความถูกต้องแต่ละคนจะต้องลงชื่อ

มีคำอธิบายที่น่าขบขันเกี่ยวกับผู้ขับขี่รถจักรยานยนต์ที่นี่:

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

ดังนั้น WS-Security จึงให้การปกป้องมากกว่า HTTPS และ SOAP จะเสนอ API ที่สมบูรณ์ยิ่งขึ้นกว่า REST ความคิดเห็นของฉันคือถ้าคุณไม่ต้องการคุณสมบัติหรือการป้องกันเพิ่มเติมคุณควรข้ามค่าใช้จ่ายของ SOAP และ WS-Security ฉันรู้ว่ามันเป็นการออกส่วนเล็กน้อย แต่การตัดสินใจเกี่ยวกับการคุ้มครองจำนวนมากนั้นเป็นเหตุผลที่แท้จริง (ไม่ใช่เพียงแค่สิ่งที่เท่ห์ในการสร้าง) จำเป็นต้องทำโดยผู้ที่รู้ปัญหาอย่างใกล้ชิด

ความปลอดภัย REST ขึ้นอยู่กับการขนส่งในขณะที่ความปลอดภัย SOAP ไม่ได้

ส่วนที่เหลือสืบทอดมาตรการความปลอดภัยจากการขนส่งพื้นฐานในขณะที่ SOAP กำหนดของตัวเองผ่าน WS-Security

เมื่อเราพูดถึง REST ผ่าน HTTP - มาตรการรักษาความปลอดภัยทั้งหมดที่ใช้กับ HTTP นั้นได้รับการสืบทอดและเป็นที่รู้จักกันในชื่อความปลอดภัยระดับการขนส่ง

การรักษาความปลอดภัยระดับการขนส่งรักษาความปลอดภัยข้อความของคุณเฉพาะในขณะที่มันอยู่ในสาย - ทันทีที่มันออกจากสาย, ข้อความจะไม่ปลอดภัยมากขึ้น

แต่ด้วย WS-Security ความปลอดภัยระดับข้อความ - แม้ว่าข้อความจะออกจากช่องทางขนส่งมันจะยังคงได้รับการคุ้มครอง นอกจากนี้ - ด้วยการรักษาความปลอดภัยระดับข้อความคุณสามารถเข้ารหัสข้อความได้บางส่วน [ไม่ใช่ข้อความทั้งหมด แต่มีเพียงบางส่วนที่คุณต้องการ] - แต่ด้วยความปลอดภัยระดับการขนส่งคุณไม่สามารถทำได้

WS-Security มีมาตรการสำหรับการตรวจสอบความถูกต้องความลับและการปฏิเสธในขณะที่ SSL ไม่สนับสนุนการปฏิเสธไม่ใช่ [ด้วย OAuth แบบ 2 ขา]

SSL ที่ใช้งานง่ายนั้นเร็วกว่า WS-Security มาก

ขอบคุณ ...

ในทางเทคนิควิธีที่คุณใช้พูดไม่ถูกต้องเนื่องจากการสื่อสารของวิธี SOAP ไม่ปลอดภัยและวิธีการ REST ไม่ได้พูดอะไรเกี่ยวกับการตรวจสอบสิทธิ์ผู้ใช้ที่ถูกต้องตามกฎหมาย

HTTPS ป้องกันผู้โจมตีจากการดักข้อมูลบนการสื่อสารระหว่างสองระบบ นอกจากนี้ยังตรวจสอบว่าระบบโฮสต์ (เซิร์ฟเวอร์) เป็นระบบโฮสต์ที่ผู้ใช้ต้องการเข้าถึง

WS-Security ป้องกันแอปพลิเคชั่นที่ไม่ได้รับอนุญาต (ผู้ใช้) ไม่ให้เข้าถึงระบบ

หากระบบ RESTful มีวิธีตรวจสอบสิทธิ์ผู้ใช้และแอปพลิเคชัน SOAP ที่มี WS-Security กำลังใช้ HTTPS แสดงว่าทั้งสองนั้นปลอดภัยจริงๆ มันเป็นวิธีที่แตกต่างในการนำเสนอและเข้าถึงข้อมูล

ดูบทความwiki :

ในสถานการณ์แบบจุดต่อจุดการรักษาความลับและความถูกต้องของข้อมูลยังสามารถบังคับใช้กับบริการเว็บผ่านการใช้ Transport Layer Security (TLS) ตัวอย่างเช่นโดยการส่งข้อความผ่าน https

WS-Security ระบุถึงปัญหาที่กว้างขึ้นของการรักษาความถูกต้องและการรักษาความลับของข้อความจนกว่าจะมีการส่งข้อความจากโหนดต้นทางซึ่งให้การรักษาความปลอดภัยแบบ end-to-end

นั่นคือ:

• HTTPS เป็นกลไกการรักษาความปลอดภัยการขนส่งเลเยอร์ (จากจุดหนึ่งไปยังอีกจุดหนึ่ง)
• WS-Security เป็นกลไกการรักษาความปลอดภัยของแอปพลิเคชันเลเยอร์ (จากต้นทางถึงปลายทาง)

อย่างที่คุณพูด REST นั้นดีพอสำหรับธนาคารดังนั้นควรดีพอสำหรับคุณ

มีสองประเด็นหลักเพื่อความปลอดภัย: 1) การเข้ารหัสและ 2) ตัวตน

การส่งสัญญาณใน SSL / HTTPS ให้การเข้ารหัสผ่านสาย แต่คุณจะต้องตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ทั้งสองสามารถยืนยันได้ว่าพวกเขารู้ว่าพวกเขากำลังพูดถึงใคร สิ่งนี้สามารถผ่านใบรับรองไคลเอ็นต์ SSL, แบ่งปันความลับ ฯลฯ

ฉันแน่ใจว่าหนึ่งสามารถทำให้ SOAP นั้น "ปลอดภัยมากขึ้น" แต่อาจไม่ได้สำคัญ การเปรียบเทียบผู้ขับขี่รถจักรยานยนต์เปลือยนั้นน่ารัก แต่ถ้าถูกต้องก็หมายความว่าอินเทอร์เน็ตทั้งหมดนั้นไม่ปลอดภัย

ฉันยังไม่มีตัวแทนที่จำเป็นในการเพิ่มความคิดเห็นมิเช่นนั้นฉันจะเพิ่มคำตอบของเบลล์ ฉันคิดว่าเบลล์ทำงานได้ดีมากในการสรุปข้อดีข้อเสียของทั้งสองวิธี อีกสองปัจจัยอื่น ๆ ที่คุณอาจต้องการพิจารณา:

1) คำขอระหว่างลูกค้าของคุณและบริการของคุณต้องผ่านตัวกลางที่ต้องมีการเข้าถึง payload หรือไม่? ถ้าเป็นเช่นนั้น WS-Security อาจเหมาะสมกว่า

2) จริง ๆ แล้วเป็นไปได้ที่จะใช้ SSL เพื่อให้เซิร์ฟเวอร์มีความมั่นใจในตัวตนของลูกค้าโดยใช้คุณสมบัติที่เรียกว่าการรับรองความถูกต้องซึ่งกันและกัน อย่างไรก็ตามสิ่งนี้ไม่ได้ใช้ประโยชน์มากนักนอกสถานการณ์พิเศษบางอย่างเนื่องจากความซับซ้อนของการกำหนดค่า ดังนั้นเบลล์จึงถูกต้องที่ WS-Sec เหมาะสมกว่านี้มาก

3) SSL โดยทั่วไปสามารถทนต่อการติดตั้งและบำรุงรักษาได้ (แม้ในการกำหนดค่าที่ง่ายกว่า) เนื่องจากปัญหาด้านการจัดการใบรับรอง มีคนที่รู้วิธีการทำเช่นนี้สำหรับแพลตฟอร์มของคุณจะเป็นข้อดี

4) หากคุณอาจจำเป็นต้องทำการแมปข้อมูลประจำตัวบางรูปแบบหรือสหพันธรัฐเอกลักษณ์ WS-Sec อาจมีค่าใช้จ่าย ไม่ใช่ว่าคุณไม่สามารถทำได้ด้วย REST แต่คุณมีโครงสร้างน้อยกว่าที่จะช่วยเหลือคุณ

5) การนำ WS-Security ไปสู่สถานที่ที่ถูกต้องในฝั่งไคลเอ็นต์ของสิ่งต่าง ๆ อาจมีความเจ็บปวดมากกว่าที่คุณคิด

ในท้ายที่สุดแม้ว่ามันจะขึ้นอยู่กับหลายสิ่งหลายอย่างที่เราไม่น่าจะรู้ สำหรับสถานการณ์ส่วนใหญ่ฉันจะบอกว่าวิธีใดวิธีหนึ่งจะ "ปลอดภัยเพียงพอ" และนั่นไม่ควรเป็นปัจจัยในการตัดสินใจหลัก

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

วันนี้ฉันต้องอธิบายให้แฟนของฉันทราบถึงความแตกต่างระหว่างพลังการแสดงออกของ WS-Security เมื่อเทียบกับ HTTPS เธอเป็นนักวิทยาศาสตร์คอมพิวเตอร์ดังนั้นแม้ว่าเธอจะไม่รู้จักจัมโบ้ XML ขนาดใหญ่ทั้งหมดเธอก็เข้าใจ (อาจดีกว่าฉัน) ความหมายของการเข้ารหัสหรือลายเซ็น อย่างไรก็ตามฉันต้องการภาพลักษณ์ที่แข็งแกร่งซึ่งสามารถทำให้เธอเข้าใจสิ่งที่เป็นประโยชน์สำหรับสิ่งที่ดีกว่าวิธีการนำไปใช้ (ซึ่งต่อมาอีกเล็กน้อยเธอไม่ได้หลบหนี :-))

มันจะเป็นแบบนี้ สมมติว่าคุณเปลือยกายและคุณต้องขับมอเตอร์ไซค์ของคุณไปยังปลายทางที่แน่นอน ในกรณี (A) คุณไปถึงอุโมงค์โปร่งใส: ความหวังเดียวของคุณที่ไม่ถูกจับกุมเพราะพฤติกรรมลามกอนาจารคือไม่มีใครมอง นั่นไม่ใช่กลยุทธ์ที่ปลอดภัยที่สุดที่คุณสามารถทำได้ด้วย ... (สังเกตจากเหงื่อตกที่หน้าผาก :-)) นั่นเทียบเท่ากับ POST อย่างชัดเจนและเมื่อฉันพูดว่า "เทียบเท่า" ฉันหมายถึงมัน ในกรณี (B) คุณอยู่ในสถานการณ์ที่ดีขึ้น อุโมงค์นั้นทึบแสงตราบใดที่คุณเดินทางเข้าไปยังบันทึกสาธารณะของคุณจะปลอดภัย อย่างไรก็ตามนี่ไม่ใช่สถานการณ์ที่ดีที่สุด คุณยังต้องออกจากบ้านและไปถึงทางเข้าอุโมงค์และเมื่ออยู่นอกอุโมงค์คุณอาจต้องออกจากและเดินไปที่ไหนสักแห่ง ... และนั่นก็เพื่อ HTTPS ทรูมันนี่ ข้อความของคุณปลอดภัยในขณะที่ข้ามช่องว่างที่ใหญ่ที่สุด: แต่เมื่อคุณส่งข้อความในอีกด้านหนึ่งคุณไม่ทราบว่าจะต้องผ่านหลายขั้นตอนก่อนที่จะถึงจุดจริงที่ข้อมูลจะถูกประมวลผล และแน่นอนว่าทุกขั้นตอนเหล่านั้นสามารถใช้สิ่งที่แตกต่างจาก HTTP: MSMQ แบบคลาสสิกที่บัฟเฟอร์การร้องขอที่ไม่สามารถให้บริการได้ในทันที จะเกิดอะไรขึ้นถ้ามีคนคอยอ่านข้อมูลของคุณขณะที่พวกเขาอยู่ในส่วนเตรียมประมวลผลนั้น ฮึ่ม (อ่าน "หืม" นี้ตามที่ Morpheus กล่าวไว้ในตอนท้ายของประโยค "คุณคิดว่าเป็นอากาศที่คุณหายใจหรือไม่?") การแก้ปัญหาที่สมบูรณ์ (c) ในอุปมานี้เป็นสิ่งที่เจ็บปวดอย่างยิ่ง: รับเสื้อผ้ายี้ใจมาหาตัวคุณเอง ดังนั้นคุณสามารถไปไหนมาไหนได้อย่างปลอดภัยโดยไม่ต้องพึ่งพาความทึบแสงของสภาพแวดล้อม การอุปมาอุปมัยมีความชัดเจนหวังว่า: เสื้อผ้ามากับคุณโดยไม่คำนึงถึงค่าเฉลี่ยหรือโครงสร้างพื้นฐานโดยรอบเช่นเดียวกับการรักษาความปลอดภัยระดับความยุ่งเหยิงไม่ นอกจากนี้คุณสามารถตัดสินใจที่จะครอบคลุมส่วนหนึ่ง แต่เปิดเผยอีกส่วนหนึ่ง (และคุณสามารถทำได้ด้วยตัวเอง: ความปลอดภัยของสนามบินสามารถถอดแจ็คเก็ตและรองเท้าออกได้ในขณะที่แพทย์ของคุณอาจมีระดับการเข้าถึงที่สูงขึ้น) แต่จำไว้ว่า การปฏิบัติที่ไม่ดีแม้ว่าคุณจะภูมิใจในลูกหนู :-) (ควรเป็นเสื้อโปโลหรือเสื้อยืด)

ฉันยินดีที่จะบอกว่าเธอได้ประเด็น! ฉันต้องบอกว่าอุปมาเสื้อผ้านั้นทรงพลังมาก: ฉันถูกล่อลวงให้ใช้เพื่อแนะนำแนวคิดของนโยบาย (ดิสโก้คลับจะไม่ยอมให้คุณใส่รองเท้ากีฬาคุณไม่สามารถถอนเงินในธนาคารในชุดชั้นในของคุณได้ ในขณะที่นี่เป็นรูปลักษณ์ที่ยอมรับได้อย่างสมบูรณ์ในขณะที่สมดุลตัวเองในการโต้คลื่นและอื่น ๆ ) แต่ฉันคิดว่าสำหรับบ่ายวันหนึ่งมันก็เพียงพอ ;-)

สถาปัตยกรรม - WS ความคิดที่ดุร้าย

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

ฉันทำงานในพื้นที่นี้ทุกวันดังนั้นฉันต้องการสรุปความคิดเห็นที่ดีเกี่ยวกับเรื่องนี้เพื่อพยายามปิดเรื่องนี้:

SSL (HTTP / s) เป็นเพียงเลเยอร์เดียวที่รับประกันว่า:

1. เซิร์ฟเวอร์ที่เชื่อมต่ออยู่จะแสดงใบรับรองเพื่อพิสูจน์ตัวตน (แม้ว่าจะสามารถปลอมแปลงผ่านการวางยา DNS)
2. เลเยอร์การสื่อสารถูกเข้ารหัส (ไม่มีการดักฟัง)

WS-Security และมาตรฐาน / การใช้งานที่เกี่ยวข้องใช้ PKI ที่:

1. พิสูจน์เอกลักษณ์ของลูกค้า
2. พิสูจน์ว่าข้อความไม่ได้ถูกแก้ไขระหว่างการขนส่ง (MITM)
3. อนุญาตให้เซิร์ฟเวอร์ตรวจสอบ / อนุญาตไคลเอนต์

จุดสุดท้ายมีความสำคัญสำหรับการร้องขอบริการเมื่อตัวตนของลูกค้า (ผู้โทร) เป็นสิ่งสำคัญยิ่งหากรู้ว่าพวกเขาควรได้รับอนุญาตให้รับข้อมูลดังกล่าวจากบริการ SSL มาตรฐานคือการตรวจสอบความถูกต้องทางเดียว (เซิร์ฟเวอร์) และไม่ทำอะไรเลยเพื่อระบุไคลเอ็นต์

คำตอบนั้นขึ้นอยู่กับข้อกำหนดเฉพาะของคุณ

ตัวอย่างเช่นคุณต้องการปกป้องข้อความบนเว็บของคุณหรือไม่จำเป็นต้องมีการรักษาความลับและสิ่งที่คุณต้องมีคือการรับรองความถูกต้องของฝ่ายต่างๆและรับรองความสมบูรณ์ของข้อความ หากเป็นกรณีนี้ - และบ่อยครั้งที่เกิดขึ้นกับบริการบนเว็บ - HTTPS อาจเป็นค้อนที่ผิด

อย่างไรก็ตามจากประสบการณ์ของฉัน - อย่ามองข้ามความซับซ้อนของระบบที่คุณกำลังสร้าง HTTPS ไม่เพียง แต่ปรับใช้อย่างถูกต้องได้ง่ายขึ้น แต่แอปพลิเคชันที่อาศัยความปลอดภัยเลเยอร์การขนส่งนั้นสามารถทำการดีบักได้ง่ายกว่า (ผ่าน HTTP ธรรมดา)

โชคดี.

REST Over HTTPS ควรเป็นวิธีที่ปลอดภัยตราบใดที่ผู้ให้บริการ API ใช้การอนุญาตที่ปลายเซิร์ฟเวอร์ ในกรณีของแอปพลิเคชันบนเว็บรวมถึงสิ่งที่เราทำคือการเข้าถึงแอปพลิเคชันทางเว็บผ่าน HTTPS และการตรวจสอบ / การอนุญาตบางอย่างตามปกติแอปพลิเคชันทางเว็บไม่มีปัญหาด้านความปลอดภัย

หากการเรียกใช้ RESTFul ของคุณส่งข้อความ XML กลับไปกลับมาฝังอยู่ใน Html Body ของคำขอ HTTP คุณควรจะได้รับประโยชน์ทั้งหมดของ WS-Security เช่นการเข้ารหัส XML, ใบรับรอง, ใบรับรอง ฯลฯ ในข้อความ XML ของคุณในขณะที่ใช้คุณลักษณะด้านความปลอดภัย พร้อมใช้งานจาก http เช่นการเข้ารหัส SSL / TLS