Dịch vụ web an toàn: REST qua HTTPS so với SOAP + WS-Security. Cái nào tốt hơn? [đóng cửa]

Tôi không phải là chuyên gia bảo mật, nhưng tôi thích tạo các dịch vụ web theo kiểu REST.

Trong việc tạo ra một dịch vụ mới cần có dữ liệu mà nó truyền tải an toàn. Chúng tôi đã tham gia một cuộc tranh luận về cách tiếp cận nào an toàn hơn - REST với HTTPS hoặc SOAP WS với WS-Security.

Tôi có ấn tượng rằng chúng tôi có thể sử dụng HTTPS cho tất cả các cuộc gọi dịch vụ web và phương pháp này sẽ được bảo mật. Theo cách nhìn của tôi, "nếu HTTPS đủ tốt cho các trang web tài chính và ngân hàng, thì nó đủ tốt cho tôi". Một lần nữa, tôi không phải là chuyên gia trong lĩnh vực này, nhưng tôi nghĩ rằng những người này đã suy nghĩ rất kỹ về vấn đề này và cảm thấy thoải mái với HTTPS.

Một đồng nghiệp không đồng ý và nói SOAP và WS-Security là cách duy nhất để đi.

Các trang web dường như trên tất cả các bảng về điều này.

Có lẽ cộng đồng ở đây có thể cân nhắc về ưu và nhược điểm của mỗi người? Cảm ơn!

HTTPS đảm bảo việc truyền thông điệp qua mạng và cung cấp một số đảm bảo cho khách hàng về danh tính của máy chủ. Đây là những gì quan trọng đối với ngân hàng hoặc nhà môi giới chứng khoán trực tuyến của bạn. Sự quan tâm của họ trong việc xác thực ứng dụng khách không nằm ở danh tính của máy tính, mà ở danh tính của bạn. Vì vậy, số thẻ, tên người dùng, mật khẩu, vv được sử dụng để xác thực bạn. Sau đó, một số biện pháp phòng ngừa thường được thực hiện để đảm bảo rằng các bài nộp không bị giả mạo, nhưng trên tất cả mọi thứ xảy ra trong phiên đều được coi là do bạn khởi xướng.

WS-Security cung cấp bảo vệ tính bảo mật và toàn vẹn từ việc tạo thông điệp đến mức tiêu thụ của nó. Vì vậy, thay vì đảm bảo rằng nội dung của các thông tin liên lạc chỉ có thể được đọc bởi đúng máy chủ, nó đảm bảo rằng nó chỉ có thể được đọc bởi đúng quy trình trên máy chủ. Thay vì giả định rằng tất cả các thông tin liên lạc trong phiên được khởi tạo an toàn là từ người dùng được xác thực, mỗi người phải được ký.

Có một lời giải thích thú vị liên quan đến người đi xe máy trần truồng ở đây:

https://docs.microsoft.com/archive/bloss/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motor Motorcycle-naken

Vì vậy, WS-Security cung cấp bảo vệ nhiều hơn HTTPS và SOAP cung cấp API phong phú hơn REST. Ý kiến ​​của tôi là trừ khi bạn thực sự cần các tính năng bổ sung hoặc bảo vệ, bạn nên bỏ qua chi phí hoạt động của SOAP và WS-Security. Tôi biết đó là một chút của một khoản đồng thanh toán nhưng các quyết định về mức độ bảo vệ thực sự là hợp lý (không chỉ là thứ tuyệt vời để xây dựng) cần phải được đưa ra bởi những người hiểu rõ vấn đề.

Bảo mật REST phụ thuộc vào vận chuyển trong khi bảo mật SOAP thì không.

REST kế thừa các biện pháp bảo mật từ vận chuyển cơ bản trong khi SOAP tự xác định thông qua WS-Security.

Khi chúng ta nói về REST, qua HTTP - tất cả các biện pháp bảo mật được áp dụng HTTP đều được kế thừa và điều này được gọi là bảo mật mức vận chuyển.

Bảo mật cấp vận chuyển, bảo mật tin nhắn của bạn chỉ trong khi trên dây - ngay khi nó rời khỏi dây, tin nhắn sẽ không còn được bảo mật nữa.

Nhưng, với WS-Security, bảo mật mức thông báo của nó - mặc dù tin nhắn rời khỏi kênh truyền tải, nó vẫn sẽ được bảo vệ. Ngoài ra - với bảo mật cấp tin nhắn, bạn có thể mã hóa một phần tin nhắn [không phải toàn bộ tin nhắn, mà chỉ các phần bạn muốn] - nhưng với bảo mật cấp vận chuyển, bạn không thể thực hiện được.

WS-Security có các biện pháp xác thực, tính toàn vẹn, bảo mật và không thoái thác trong khi SSL không hỗ trợ không thoái thác [với OAuth 2 chân mà nó thực hiện].

Trong SSL hiệu năng-khôn ngoan nhanh hơn WS-Security rất nhiều.

Cảm ơn...

Về mặt kỹ thuật, cách bạn nói, không đúng, bởi vì giao tiếp của phương thức SOAP không an toàn và phương thức REST không nói gì về việc xác thực người dùng hợp pháp.

HTTPS ngăn chặn kẻ tấn công nghe lén thông tin liên lạc giữa hai hệ thống. Nó cũng xác minh rằng hệ thống máy chủ (máy chủ) thực sự là hệ thống máy chủ mà người dùng dự định truy cập.

WS-Security ngăn các ứng dụng trái phép (người dùng) truy cập hệ thống.

Nếu một hệ thống RESTful có cách xác thực người dùng và ứng dụng SOAP với WS-Security đang sử dụng HTTPS, thì thực sự cả hai đều an toàn. Đó chỉ là một cách khác nhau để trình bày và truy cập dữ liệu.

Xem bài viết wiki :

Trong các tình huống điểm-điểm, tính bảo mật và toàn vẹn dữ liệu cũng có thể được thực thi trên các dịch vụ Web thông qua việc sử dụng Bảo mật lớp vận chuyển (TLS), ví dụ, bằng cách gửi tin nhắn qua https.

Tuy nhiên, WS-Security giải quyết vấn đề rộng hơn là duy trì tính toàn vẹn và bảo mật của tin nhắn cho đến khi tin nhắn được gửi từ nút gốc, cung cấp cái gọi là bảo mật end to end.

Đó là:

• HTTPS là một cơ chế bảo mật lớp vận chuyển (điểm-điểm)
• WS-Security là một cơ chế bảo mật của lớp ứng dụng (end-to-end).

Như bạn nói, REST đủ tốt cho các ngân hàng vì vậy nên đủ tốt cho bạn.

Có hai khía cạnh chính để bảo mật: 1) mã hóa và 2) danh tính.

Truyền trong SSL / HTTPS cung cấp mã hóa qua mạng. Nhưng bạn cũng cần đảm bảo rằng cả hai máy chủ đều có thể xác nhận rằng họ biết họ đang nói chuyện với ai. Điều này có thể thông qua chứng chỉ ứng dụng khách SSL, chia sẻ bí mật, v.v.

Tôi chắc chắn người ta có thể làm cho trường hợp SOAP "an toàn hơn" nhưng có lẽ không theo bất kỳ cách quan trọng nào. Sự tương tự người lái xe mô tô khỏa thân là dễ thương nhưng nếu chính xác sẽ ngụ ý rằng toàn bộ internet là không an toàn.

Tôi chưa có đại diện cần thiết để thêm nhận xét hoặc tôi sẽ chỉ thêm câu này vào câu trả lời của Bell. Tôi nghĩ rằng Bell đã làm rất tốt khi tổng hợp những ưu và nhược điểm cấp cao nhất của hai phương pháp. Chỉ cần một vài yếu tố khác mà bạn có thể muốn xem xét:

1) Các yêu cầu giữa khách hàng và dịch vụ của bạn có cần thông qua các trung gian yêu cầu quyền truy cập vào tải trọng không? Nếu vậy thì WS-Security có thể phù hợp hơn.

2) Thực sự có thể sử dụng SSL để cung cấp cho máy chủ sự đảm bảo về danh tính khách hàng bằng cách sử dụng một tính năng gọi là xác thực lẫn nhau. Tuy nhiên, điều này không được sử dụng nhiều ngoài một số tình huống rất đặc biệt do sự phức tạp của việc cấu hình nó. Vì vậy, Bell đã đúng khi WS-Sec phù hợp hơn nhiều ở đây.

3) SSL nói chung có thể là một chút khó khăn để thiết lập và duy trì (ngay cả trong cấu hình đơn giản hơn) do phần lớn là do vấn đề quản lý chứng chỉ. Có một người biết cách làm điều này cho nền tảng của bạn sẽ là một điểm cộng lớn.

4) Nếu bạn có thể cần thực hiện một số hình thức ánh xạ thông tin xác thực hoặc liên kết danh tính thì WS-Sec có thể có giá trị trên không. Không phải là bạn không thể làm điều này với REST, bạn chỉ có ít cấu trúc hơn để giúp bạn.

5) Đưa tất cả các WS-Security đi vào đúng vị trí ở phía máy khách của mọi thứ có thể gây ra nhiều nỗi đau hơn bạn nghĩ.

Cuối cùng, mặc dù nó thực sự phụ thuộc vào rất nhiều thứ mà chúng ta không thể biết. Trong hầu hết các tình huống, tôi sẽ nói rằng một trong hai cách tiếp cận sẽ "đủ an toàn" và do đó không phải là yếu tố quyết định chính.

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

Hôm nay tôi đã phải giải thích cho bạn gái về sự khác biệt giữa sức mạnh biểu cảm của WS-Security so với HTTPS. Cô ấy là một nhà khoa học máy tính, vì vậy ngay cả khi cô ấy không biết tất cả các mumbo XML, cô ấy hiểu (có thể tốt hơn tôi) ý nghĩa của mã hóa hoặc chữ ký. Tuy nhiên tôi muốn có một hình ảnh mạnh mẽ, có thể khiến cô ấy thực sự hiểu những thứ hữu ích cho nó, hơn là cách chúng được thực hiện (một lát sau, cô ấy đã không thoát khỏi nó :-)).

Vì vậy, nó đi như thế này. Giả sử bạn đang khỏa thân, và bạn phải lái xe máy của mình đến một điểm đến nhất định. Trong trường hợp (A) bạn đi qua một đường hầm trong suốt: hy vọng duy nhất của bạn về việc không bị bắt vì hành vi tục tĩu là không ai tìm kiếm. Đó không hẳn là chiến lược an toàn nhất mà bạn có thể đưa ra ... (chú ý giọt mồ hôi từ trán chàng trai :-)). Điều đó tương đương với một POST rõ ràng và khi tôi nói "tương đương" thì ý tôi là vậy. Trong trường hợp (B), bạn đang ở trong một tình huống tốt hơn. Đường hầm mờ đục, miễn là bạn đi vào đó thì hồ sơ công khai của bạn là an toàn. Tuy nhiên, đây vẫn không phải là tình huống tốt nhất. Bạn vẫn phải rời khỏi nhà và đến lối vào đường hầm, và một khi ở bên ngoài đường hầm có lẽ bạn sẽ phải xuống và đi bộ ở đâu đó ... và điều đó sẽ xảy ra với HTTPS. Thật, thông điệp của bạn an toàn trong khi nó vượt qua giới hạn lớn nhất: nhưng một khi bạn đã gửi nó ở phía bên kia, bạn không thực sự biết mình sẽ phải trải qua bao nhiêu giai đoạn trước khi đến điểm thực sự nơi dữ liệu sẽ được xử lý. Và tất nhiên, tất cả các giai đoạn đó có thể sử dụng một cái gì đó khác với HTTP: một MSMQ cổ điển có bộ đệm yêu cầu không thể được phục vụ ngay lập tức. Điều gì xảy ra nếu ai đó giấu dữ liệu của bạn trong khi họ ở trong tình trạng lấp lửng tiền xử lý đó? Hừm. (đọc "hm" này khi người được Morpheus thốt ra ở cuối câu "bạn có nghĩ đó là không khí mà bạn đang thở không?"). Giải pháp hoàn chỉnh (c) trong phép ẩn dụ này thật tầm thường: lấy một số quần áo bẩn thỉu trên chính mình, và đặc biệt là mũ bảo hiểm khi đi xe máy !!! Vì vậy, bạn có thể đi xung quanh một cách an toàn mà không cần phải dựa vào sự mờ đục của môi trường. Phép ẩn dụ hy vọng rất rõ ràng: quần áo đi kèm với bạn bất kể trung bình hay cơ sở hạ tầng xung quanh, như mức độ bảo mật lộn xộn. Hơn nữa, bạn có thể quyết định che một phần nhưng tiết lộ phần khác (và bạn có thể làm điều đó trên cơ sở cá nhân: an ninh sân bay có thể lấy áo khoác và giày của bạn ra, trong khi bác sĩ của bạn có thể có mức truy cập cao hơn), nhưng hãy nhớ rằng áo sơ mi tay ngắn là thực hành xấu ngay cả khi bạn tự hào về bắp tay của mình :-) (tốt hơn là áo polo, hoặc áo phông).

Tôi rất vui khi nói rằng cô ấy đã nhận được điểm! Tôi phải nói rằng phép ẩn dụ về quần áo rất mạnh mẽ: Tôi đã cố gắng sử dụng nó để đưa ra khái niệm chính sách (các câu lạc bộ sàn nhảy sẽ không cho bạn đi giày thể thao; bạn không thể rút tiền trong ngân hàng trong quần lót của bạn , trong khi điều này là hoàn toàn có thể chấp nhận được trong khi cân bằng bản thân khi lướt web, v.v.) nhưng tôi nghĩ rằng trong một buổi chiều là đủ ;-)

Kiến trúc - WS, Ý tưởng hoang dã

Lịch sự: http://bloss.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-securance-or-why-you-shouldn-t-drive-your-motor Motorcycle-naken. aspx

Tôi làm việc trong không gian này mỗi ngày vì vậy tôi muốn tóm tắt những nhận xét tốt về điều này trong một nỗ lực để đóng lại điều này:

SSL (HTTP / s) chỉ có một lớp đảm bảo:

1. Máy chủ đang được kết nối để xuất trình chứng chỉ chứng minh danh tính của nó (mặc dù điều này có thể bị giả mạo thông qua ngộ độc DNS).
2. Lớp truyền thông được mã hóa (không nghe lén).

WS-Security và các tiêu chuẩn / triển khai có liên quan sử dụng PKI:

1. Chứng minh danh tính của khách hàng.
2. Chứng minh tin nhắn không được sửa đổi trong quá cảnh (MITM).
3. Cho phép máy chủ xác thực / ủy quyền cho khách hàng.

Điểm cuối cùng rất quan trọng đối với các yêu cầu dịch vụ khi danh tính của khách hàng (người gọi) là tối quan trọng để biết NẾU họ nên được phép nhận dữ liệu đó từ dịch vụ. SSL tiêu chuẩn là xác thực một chiều (máy chủ) và không có gì để xác định ứng dụng khách.

Câu trả lời thực sự phụ thuộc vào yêu cầu cụ thể của bạn.

Chẳng hạn, bạn có cần bảo vệ thông điệp web của mình hay không cần bảo mật và tất cả những gì bạn cần là xác thực các bên kết thúc và đảm bảo tính toàn vẹn của tin nhắn? Nếu đây là trường hợp - và thường là với các dịch vụ web - HTTPS có lẽ là búa sai.

Tuy nhiên - từ kinh nghiệm của tôi - đừng bỏ qua sự phức tạp của hệ thống bạn đang xây dựng. Không chỉ HTTPS dễ dàng triển khai chính xác hơn, mà một ứng dụng dựa trên bảo mật lớp vận chuyển cũng dễ gỡ lỗi hơn (qua HTTP đơn giản).

Chúc may mắn.

REST Over HTTPS Nên là một phương thức bảo mật miễn là nhà cung cấp API triển khai ủy quyền kết thúc máy chủ. Trong trường hợp ứng dụng web cũng như những gì chúng tôi làm là truy cập ứng dụng web qua HTTPS và một số xác thực / ủy quyền, các ứng dụng web truyền thống không có vấn đề bảo mật thì Restful API cũng sẽ khắc phục vấn đề bảo mật mà không gặp sự cố!

Nếu cuộc gọi RESTFul của bạn gửi Tin nhắn XML qua lại được nhúng trong Phần thân Html của yêu cầu HTTP, bạn sẽ có thể có tất cả các lợi ích của WS-Security như mã hóa XML, Chứng chỉ, v.v. trong các tin nhắn XML của bạn trong khi sử dụng bất kỳ tính năng bảo mật nào có sẵn từ http như mã hóa SSL / TLS.