it-swarm-vi.com

Ưu điểm của chứng chỉ ứng dụng khách để xác thực ứng dụng khách?

Tôi không phải là chuyên gia bảo mật, vì vậy vui lòng chỉ hỏi trong một nhận xét nếu tôi chưa làm cho câu hỏi của mình đủ rõ ràng để trả lời.

Kịch bản

Chúng tôi có một máy chủ chạy các dịch vụ WCF và một số khách hàng kết nối. Những máy khách này thực sự là các máy tính Linux mà chúng tôi xây dựng. Chúng tôi cần thiết lập liên lạc an toàn giữa máy chủ của chúng tôi và khách hàng của chúng tôi (một lần nữa chúng tôi xây dựng chúng và triển khai chúng đến các trang web của khách hàng).

Khách hàng tin tưởng máy chủ

Chúng tôi sẽ thực hiện điều này bằng cách cho phép khách hàng thiết lập kết nối đáng tin cậy với máy chủ thông qua triển khai truyền thông SSL.

Máy chủ tin tưởng khách hàng

Bây giờ chúng tôi có nhiệm vụ xác thực khách hàng. Rõ ràng điều này được thực hiện bằng cách giữ một số loại thông tin đăng nhập trên máy khách. Khi máy khách được kết nối, nó có thể gửi thông tin đăng nhập đến máy chủ và máy chủ có thể xác thực chúng.

Một tùy chọn cho các thông tin đăng nhập này là lưu trữ một số loại Hướng dẫn hoặc id/mật khẩu khác được tạo bởi ứng dụng dựa trên WCF. Khi nhận được thông tin đăng nhập, dịch vụ WCF sẽ tra cứu cơ sở dữ liệu và xác minh chúng là chính xác.

Một tùy chọn khác là sử dụng Dịch vụ chứng chỉ để tạo chứng chỉ ứng dụng khách được sao chép vào máy khách trước khi được gửi đi. Sau khi thiết lập kết nối an toàn, máy khách sẽ gửi chứng chỉ đến máy chủ xác thực chứng chỉ với Dịch vụ chứng chỉ.

Câu hỏi

Những lợi thế nào khi sử dụng chứng chỉ để xác thực ứng dụng khách có tên người dùng/hướng dẫn? Nó có nhược điểm gì?

Vui lòng xem xét:

  • Bảo vệ
  • Sự phức tạp của việc thực hiện
  • Sự phức tạp của lập trình Tích hợp với ứng dụng. Điều này bao gồm quy trình tạo mã thông báo xác thực, liên kết siêu dữ liệu (ủy quyền/liên kết) phù hợp, quản lý xác thực như vô hiệu hóa quyền truy cập, v.v.
34
Shaun Rowan

Triển khai certs khách hàng có thể phù hợp ở đây. Những lợi thế của việc sử dụng một chứng chỉ qua tên người dùng là hơi đơn giản. Bất cứ ai cũng có thể nhập tên người dùng từ bất kỳ thiết bị khách nào. Nếu bạn đang sử dụng kết hợp tên người dùng với hướng dẫn, thì "bảo mật" hoặc đảm bảo rằng máy khách đang kết nối từ một thiết bị khách được biết/được ủy quyền phụ thuộc vào độ mạnh và tính duy nhất của hướng dẫn. Nếu có cách sao chép hoặc giả mạo hướng dẫn (địa chỉ mac có thể bị giả mạo khá dễ dàng), thì mức độ đảm bảo sẽ giảm.

Chứng chỉ ứng dụng khách có thể được triển khai cho khách hàng, có hoặc không có kiểm tra tính hợp lệ (ngoài ngày hiệu lực, cn, trượt tuyết/aki, dấu vân tay, v.v.). Các cơ chế kiểm tra tính hợp lệ theo yêu cầu như ocsp sẽ yêu cầu kiểm tra ứng dụng máy chủ với máy chủ ocsp mỗi khi máy khách kết nối/cố gắng xác thực. Nhưng từ mô tả, tôi đã không đọc rằng kiểm tra tính hợp lệ cũng quan trọng như việc có thể buộc chứng chỉ cho thiết bị khách.

Một chi tiết quan trọng với certs khách hàng (certs nói chung) là có thể được xuất khẩu và hầu hết các triển khai không khóa tính di động của chứng chỉ. Bất kể liệu các máy khách sẽ được lưu trữ như thế nào, nếu không có các biện pháp thích hợp, chứng chỉ có thể dễ dàng được sao chép từ thiết bị này sang thiết bị khác. Một số triển khai lưu trữ chứng chỉ trên hệ thống tệp (các tệp kết thúc bằng .cer, .der, .key, .crt thường là dấu hiệu cho thấy certs được lưu trữ trong hệ thống tệp). Việc triển khai mạnh hơn (phụ thuộc vào ứng dụng) có thể lưu trữ certs và khóa trong kho lưu trữ khóa (tức là Java). Kho lưu trữ khóa có thể thêm bảo vệ bổ sung như đảm bảo khóa riêng không thể xuất được. Tuy nhiên, Đảm bảo rằng khóa chưa được xuất chỉ mạnh như chính kho lưu trữ khóa. Cửa hàng khóa phần cứng (ví dụ thẻ thông minh, usb hsm, ironkey, v.v.) cung cấp một đảm bảo mạnh mẽ hơn nhiều rằng khóa riêng không thể xuất được so với lưu trữ khóa phần mềm.

BTW, điểm trên cũng ảnh hưởng đến khóa máy chủ. Hầu hết các triển khai lưu trữ khóa riêng trong kho lưu trữ khóa phần mềm và thường được đánh dấu có thể xuất được. Hơn nữa, khóa riêng thường không được bảo vệ bằng mật khẩu để bất kỳ ai có quyền truy cập vào máy chủ đều có thể bỏ qua khóa riêng. Nếu một chứng chỉ có thể được sao chép, thì nó không cung cấp sự từ chối.

Để trả lời câu hỏi của bạn, nếu có một cách tốt để tận dụng id loại phần cứng (hướng dẫn, số sê-ri, chứng chỉ được lưu trữ trong HSM, v.v.), điều đó có thể sẽ đảm bảo hơn so với sử dụng id dựa trên phần mềm (bao gồm cả phần mềm máy khách) . Việc sử dụng certs khách hàng với chức năng bảo vệ mật khẩu được bật để truy cập khóa riêng cung cấp xác thực mạnh hơn một chút vì khách hàng không chỉ cần có quyền truy cập vào khóa riêng mà còn cả mật khẩu để sử dụng.

Nếu bạn quyết định sử dụng certs của khách hàng, thì bạn sẽ phải xây dựng hoặc sử dụng cơ sở hạ tầng PKI hiện có. Các nhà cung cấp như Codomo, Entrust, Symantec (trước đây là vrsn, thawte và geotrust), Godaddy, và một loạt những người khác cung cấp cả cơ sở hạ tầng công cộng và tư nhân để sử dụng. Tuy nhiên, chi phí thực hiện chứng chỉ ứng dụng khách dựa trên phần mềm có thể sẽ cao hơn so với sử dụng id phần cứng dựa trên phần mềm hoặc thậm chí có thể là id duy nhất dựa trên phần cứng.

Nếu bất cứ điều gì, hãy xác định mức độ đảm bảo bạn muốn có và quyết định xem phần mềm, phần mềm + mật khẩu hoặc phần cứng là đủ.

19
bangdang

Với xác thực chứng chỉ ứng dụng khách, bí mật (khóa riêng) không bao giờ rời khỏi máy khách và không đi đến máy chủ. Cho dù bạn có tin tưởng máy chủ hay không (dù sao bạn cũng nên kiểm tra điều đó trước tiên), khóa riêng của bạn sẽ không bị rò rỉ. Đây là một lợi thế so với xác thực dựa trên mẫu hoặc HTTP Basic truyền thống.

Bạn thậm chí có thể sử dụng một số mã thông báo/thẻ thông minh mã hóa phần cứng được thiết kế theo cách mà khóa riêng không bao giờ rời khỏi mã thông báo (các chữ ký liên quan đến bắt tay TLS xảy ra trên tàu).

Nếu bạn sử dụng chứng chỉ ứng dụng khách trong bối cảnh Cơ sở hạ tầng khóa công khai (rất có thể), bạn cũng có thể tận hưởng các lợi ích do PKI cung cấp. Điều này chủ yếu hữu ích cho các cấu trúc lớn, nhưng bạn có thể:

  • Nhận dạng danh tính của người dùng mà bạn chưa từng đăng ký trước đây.

    Đây là những gì Cơ quan Chứng nhận dành cho. Nếu bạn tin tưởng CA, bạn tin tưởng vào chứng chỉ mà nó cấp. Nếu người dùng không xác định đăng nhập mà không có tài khoản tồn tại trên hệ thống của bạn và nếu họ xuất trình chứng chỉ mà bạn tin tưởng, bạn sẽ có thể nhận ra danh tính của họ, như được chứng minh bởi CA. Bạn có thể hoặc không muốn nhận thêm thông tin chi tiết từ người dùng, nhưng danh tính chính sẽ được xác nhận với CA và sẽ để lại dấu vết hành chính ở đó.

  • Nhận dạng tương tự được xác nhận bởi chứng chỉ có thể được sử dụng trên nhiều trang web độc lập (miễn là chúng tin tưởng cùng một CA), có thể được sử dụng như một hình thức Đăng nhập một lần.

  • Giấy chứng nhận bị xâm phạm có thể bị CA thu hồi trực tiếp.

  • Thông qua CA, bạn giải quyết vấn đề chứng minh danh tính của người dùng từ việc cung cấp dịch vụ. Các phương pháp khác như OpenID cũng đạt được mục tiêu này, nhưng hầu như không cung cấp mức độ đảm bảo giống như những gì CA có thể làm (với điều kiện CA làm công việc của họ một cách chính xác). Mức độ đảm bảo sẽ khác nhau tùy thuộc vào chất lượng của CA.

    Một lợi thế với điều này là bạn có thể cấp lại chứng chỉ mới cho cùng một người dùng với các khóa khác nhau (nếu chứng chỉ trước đó đã hết hạn hoặc nếu khóa riêng bị xâm phạm) và giữ cùng một mã định danh (Chủ đề) trên tất cả các hệ thống tin tưởng điều này CA.

(Bạn cũng có thể sử dụng chứng chỉ ứng dụng khách bên ngoài ngữ cảnh của PKI, nhưng bạn phải xác định quy tắc tin cậy của riêng mình, điều này có thể khá tẻ nhạt.)

Chứng chỉ ứng dụng khách cũng có thể được sử dụng độc lập với giao thức chạy trên SSL/TLS. Bạn thậm chí có thể sử dụng chúng cho S/MIME chẳng hạn, nếu có.

Một lợi thế khác là, vì xác thực không xảy ra ở cấp HTTP, nên nó thực sự không trạng thái, nếu những thứ như REST kiểu kiến ​​trúc quan trọng với bạn.

Một số dịch vụ web cũng có thể sử dụng điều này để bảo mật ở cấp độ tin nhắn, do đó có khả năng để lại dấu vết kiểm toán để không thoái thác các tin nhắn nhất định nếu cần thiết.

Nhược điểm chính là bạn sẽ cần giáo dục người dùng của mình các khái niệm cơ bản về mật mã khóa công khai. Điều này đặc biệt quan trọng nếu bạn không sử dụng mã thông báo phần cứng (mà chỉ giữ chứng chỉ và khóa riêng trong phần mềm của người dùng).

  • Không giống như mật khẩu, người dùng sẽ không nhớ khóa/cert riêng. Họ sẽ cần sử dụng máy đã cài đặt chứng chỉ (hoặc nơi có đầu đọc thẻ phù hợp cho các giải pháp phần cứng). Để cắt góc, một số người có thể không muốn chăm sóc các khóa riêng tư cẩn thận như bình thường (chúng thường được bảo vệ bằng mật khẩu).

  • Khi giải thích, khái niệm "chứng chỉ" có thể gây nhầm lẫn. Ngay cả các chuyên gia đôi khi rút ngắn câu. Nếu bạn nói "sử dụng chứng chỉ của mình để đăng nhập", điều bạn thực sự muốn nói là "sử dụng khóa riêng và chứng chỉ của bạn để đăng nhập": khóa riêng được ngụ ý trong biểu thức này. Ngược lại, nếu ai đó nói với bạn "gửi cho tôi chứng chỉ của bạn", thì bạn không nên sử dụng khóa riêng của mình. Nếu bạn tìm tài liệu xung quanh, bạn sẽ tìm thấy một số tài liệu tham khảo về các tệp PKCS # 12 (.p12 hoặc là .pfx) và tệp chứng chỉ PEM (.pem hoặc là .crt, thông thường). Thông thường, cái trước chứa khóa riêng trong khi cái thứ hai thì không (mặc dù nó cũng có thể làm được). Tất cả các khái niệm này sẽ gây nhầm lẫn cho người dùng trừ khi họ biết họ đang làm gì.

  • Giao diện người dùng của trình duyệt cho chứng chỉ ứng dụng khách thường khá kém. Từ góc độ giao diện người dùng khá khó khăn để đăng xuất khỏi trang web nơi bạn đã xác thực bằng chứng chỉ ứng dụng khách chẳng hạn (như HTTP Basic). (Nó làm cho việc bảo vệ CSRF thậm chí còn quan trọng hơn.) Nếu khách hàng của bạn là "máy móc" và không phải người dùng thông qua trình duyệt, thì đây không phải là vấn đề quá lớn.

Về cơ sở hạ tầng, nếu bạn không sẵn sàng sử dụng các dịch vụ của CA thương mại cho chứng chỉ ứng dụng khách của mình, bạn sẽ phải triển khai CA của chính mình. Lưu ý rằng CA được sử dụng để xác thực ứng dụng khách có thể độc lập với CA được sử dụng để xác thực máy chủ. Bạn có thể chạy một trang web với chứng chỉ được cấp bởi một CA nổi tiếng nhưng có được nó tin tưởng chứng chỉ ứng dụng khách từ CA của chính bạn. Tồn tại các công cụ khác nhau để quản lý CA, bao gồm cả các công cụ nguồn mở . Một số thậm chí có thể thực hiện tạo khóa trong trình duyệt, để khóa riêng sẵn sàng trong trình duyệt (nhược điểm là người dùng phải sử dụng lại cùng một trình duyệt để nhập chứng chỉ sau khi được cấp).

Cấu hình của các máy chủ đòi hỏi một sự hiểu biết nhất định về những chứng chỉ (chứng chỉ CA, chứng chỉ máy chủ), nhưng nó không thực sự phức tạp. Hầu hết các máy chủ hỗ trợ cách này hay cách khác.

Chứng chỉ ứng dụng khách chỉ cung cấp cho bạn xác thực. Bạn vẫn có thể cần nhận thêm các thuộc tính (ví dụ: từ LDAP hoặc cơ sở dữ liệu đối với các chủ đề của chứng chỉ). Bạn chắc chắn sẽ cần phải có một logic ủy quyền trên đầu trang này, vì nó sẽ dành cho bất kỳ hệ thống xác thực nào khác. Đó là điển hình để ánh xạ một Chủ thể DN đến một định danh cục bộ trong hệ thống của bạn.

(Có những cách sử dụng nâng cao hơn trong đó bạn có thể ủy quyền xác thực bằng chứng chỉ proxy hoặc chuyển mã thông báo ủy quyền qua chứng chỉ thuộc tính, nhưng những điều này khác thường hơn và không được chấp nhận bởi tất cả các ngăn xếp phần mềm.)

19
Bruno