Tam giác bảo mật S.F.U

Như trong bài viết này, tôi có đề cập đến ba mục tiêu chính cần đạt được trong công tác bảo mật cho một hệ thống thông tin và ba mục tiêu này tạo thành bộ ba (hay tam giác) bảo mật  C.I.A. Hôm nay, tôi sẽ nói về một tam giác bảo mật (security triangle) khác mà trong đó 3 thành tố của nó có mối liên hệ và ảnh hưởng tới nhau.

Hình trên cho biết 3 đặc tính cơ bản của một hệ thống thông tin và đó cũng là 3 yếu tố (tương ứng với 3 góc) của tam giác bảo mật S.F.U (hoặc S.F.E) mà tôi muốn nhắc đến trong bài này đó là:

  • Functionality: chức năng (mặt định lượng)
  • Security: tính bảo mật
  • Usability (hoặc Ease of Use): tính tiện dụng

Ở bên trong tam giác S.F.U này có một quả bóng nhỏ. Khi quả bóng này có thiên hướng di chuyển về một góc nào đó của tam giác thì có nghĩa rằng yếu tố tương ứng với góc đó được chú trọng, tăng cường và đồng thời 2 yếu tố còn lại sẽ bị coi nhẹ, suy giảm. Cụ thể:

  • Nếu nâng cao độ bảo mật cho hệ thống (quả bóng di chuyển về góc Security) cũng đồng nghĩa với việc người dùng phải chịu nhiều rằng buộc, trải qua nhiều bước kiểm tra an ninh khi muốn tiếp cận và sử dụng hệ thống (tức, tính Usability bị giảm đi) và số lượng các chức năng của hệ thống sẽ được giữ ở mức tối thiểu nhất có thể vì rõ ràng, càng nhiều chức năng thì hệ thống đó tiềm ẩn thêm những lỗ hổng có thể bị khai thác (tức, tính Functionalitybị giảm đi).
  • Nếu bổ sung thêm nhiều chức năng cho hệ thống (quả bóng di chuyển về gócFunctionality) cũng đồng nghĩa việc hệ thống đó có thể chứa đựng nhiều lỗ hổng không lường trước được, các mối đe dọa và rủi ro tăng lên (tức, tính Security giảm đi) và rõ ràng, càng nhiều chức năng thì độ phức tạp khi sử dụng hệ thống tăng lên (tức, tính Usability giảm đi).
  • Cuối cùng, nếu muốn việc sử dụng hệ thống trở nên đơn giản, thuận tiện hơn (quả bóng di chuyển về góc Usability) thì buộc lòng ta phải giảm tinh giản, làm gọn các chức năng trong hệ thống (tức, tính Functionality giảm đi) và nới lỏng các biện pháp an ninh (tức, tính Security giảm đi).

Để dễ hiểu hơn, tôi xin lấy một ví dụ thế này. Bạn có một hệ thống E-commerce nhằm quảng bá cho các sản phẩm, dịch vụ của bạn và đồng thời cho phép khách hàng đặt hàng, thanh toán trực tuyến. Rõ ràng, khi giao dịch qua mạng Internet thế này thì yếu tố bảo mật phải được đặt lên hàng đầu nhằm tránh rủi ro, thiệt hại cho khách hàng và chính bạn khi xảy ra các sự cố an ninh như hệ thống bị tấn công khiến dữ liệu khách hàng, bí mật kinh doanh bị đánh cắp, thông tin giao dịch bị lộ, hay toàn bộ hệ thống bị tê liệt… Trước nguy cơ đó, để phòng chống với các mối đe dọa thì tất nhiên bạn sẽ đầu tư xây dựng và triển khai một loạt các cơ chế bảo vệ đa tầng (Defense-in-Depth) như:

  • Xác thực đa yếu tố (multi-factor) với smart card, mã PIN kết hợp với mật khẩu mạnh.
  • Mã hóa cho các phiên giao dịch với SSL Certificate.
  • Kiểm soát truy cập, giám sát, cảnh báo, phản ứng sử dụng firewall,VPN,  proxy, IDS/IPS, Anti-Virus,… cộng với các chính sách bảo mật nghiêm ngặt.
  • v.v..

Nhiêu đó thôi cũng đủ làm cho hệ thống tuy có an toàn hơn nhưng lại trở nên phức tạp hơn và gây bất tiện cho những người dùng với kiến thức bảo mật ít ỏi nhưng luôn mong mỏi được thoải mái, dễ dàng trong việc sử dụng dịch vụ, chức năng của hệ thống, đôi khi còn làm cho bản thân những người quản trị bảo mật cho hệ thống đó khó khăn trong việc điều hành, duy trì.

Ngoài tình huống trên, bạn có thể tự tìm hiểu thêm nhiều ví dụ khác minh họa cho ý nghĩa của tam giác bảo mật S.F.U.

Suy cho cùng, một giải pháp bảo mật tối ưu thì cần cân đối hài hòa giữa cả 3 yếu tố Security, Functionality và Usability. Khi đó, quả bóng kia sẽ ở tâm điểm của tam giác S.F.U.

Secure Socket Layer – SSL (Phần 3): Giải pháp bảo mật cho website với SSL

Tiếp nối phần 2, ở bài viết tiếp theo này tôi xin giới thiệu đến các bạn các phương pháp xây dựng hệ thống Web Server xác thực bằng SSL.

Secure Socket Layer – SSL (Phần 1): Tổng quan và cấu trúc SSL

Secure Socket Layer – SSL (Phần 2): Các giao thức bảo mật SSL.

Các loại chứng chỉ dùng cho SSL

Khi triển khai SSL, có hai loại chứng chỉ có thể được dùng là:

  • Chứng chỉ cho Web server: một Web server muốn áp dụng SSL thì bắt buộc phải có loại chứng chỉ này. Nó được dùng để mã hóa khóa pre-master được Web client gửi cho Web server và đồng thời giúp xác minh nhận dạng của Web server để Web client có thể tin tưởng rằng đó không phải là Web server giả mạo được kẻ tấn công dựng lên. Chứng chỉ của Web server phải bao gồm Server Authentication OID trong extension Enhanced Key Usage.
  • Chứng chỉ cho Web client: Khi một Website yêu cầu người dùng kết nối tới nó phải được xác thực thì Web client có thể sử dụng loại chứng chỉ này. Tuy các kết nối SSL không ép buộc điều này nhưng nó giúp tăng độ an toàn cho Web server trong trường hợp chỉ cho phép những người dùng được xác thực (Web client của họ được cài loại chứng chỉ này) kết nối tới nó. Chứng chỉ của Web client phải bao gồm Client Authentication OID trong extension Enhanced Key Usage.

Chọn nhà cung cấp chứng chỉ SSL cho Web server

Việc lựa chọn sẽ nhận chứng chỉ cho Web server từ đâu (CA nào) thường dựa trên việc xem xét các Web client thuộc nội bộ hay bên ngoài tổ chức. Các client nội bộ là nhân viên hoặc đối tác mà có thể có hoặc không được cấp các tài khoản dùng trong mạng của tổ chức. Các client bên ngoài thường là các khách hàng mà không được cấp các tài khoản dùng trong mạng của tổ chức.

Thường một CA riêng tư (private CA) được xây dựng để cấp chứng chỉ cho các Web server nội bộ khi:

  • Tổ chức phải tuân thủ các chính sách an ninh và chính sách chứng chỉ do họ đề ra. Trong khi đó, một chứng chỉ do một CA thương mại (như Verisign) cấp yêu cầu tổ chức phải tuân theo tập các chỉ dẫn trong CPS của CA đó.
  • Tổ chức muốn giảm chi phí mua chứng chỉ từ các CA thương mại vì các Web server chỉ cần chấp nhận các kết nối từ các nhân viên và những đối tác được tin cậy khác là đủ. Trong trường hợp này, các nhân viên và đối tác được yêu cầu phải tin cậy và cài đặt chứng chỉ của các CA của tổ chức.

Thường một CA thương mại (commercial CA) được chọn để cấp chứng chỉ cho các Web server của tổ chức khi:

  • Tổ chức không muốn triển khai một hạ tầng PKI nội bộ để giảm chi phí cho việc thiết kế, triển khai và quản lý CA và các chứng chỉ.
  • Tổ chức sử dụng Website để bán hàng hóa và cung cấp các dịch vụ qua Internet cho nhiều đối tượng khách hàng khác nhau, và các CA thương mại mặc định đã được tin cậy bởi hầu hết các Web client. Điều này vì vậy mang lại sự thuận tiện và đảm bảo cho các giao dịch điện tử.
  • Tổ chức muốn triển khai chứng chỉ EV (Extended Validation) để thanh địa chỉ của Web browser sẽ chuyển sang màu xanh và có tên của tổ chức ở bên trái. Điều này nói lên rằng CA thương mại đã bỏ thêm tài nguyên và thời gian để xác minh người sở hữu chứng chỉ SSL của website thực sự là đại diện của tổ chức. Cũng vì vậy mà chứng chỉ EV luôn mắc hơn các chứng chỉ loại thông thường.

Thanh địa chỉ của các Web browser cho biết Website sử dụng một EV certificate

Xác định vị trí đặt chứng chỉ của Web server

Việc lựa chọn vị trí triển khai chứng chỉ cho Web server phụ thuộc vào cấu hình mạng của tổ chức. Dưới đây là hai trường hợp thường gặp.

  • Với một Web server

Nếu chỉ có một Web server hoạt động thì hiển nhiên chứng chỉ phải được đặt tại Web server đó như được thể hiện trong Hình dưới đây:

  • Với một nhóm các Web server

Ở cấu hình gom nhóm này, website có thể nằm trên ổ đĩa dùng chung bởi nhiều máy chủ hoặc mỗi máy chủ có ổ đĩa riêng để lưu trữ bản sao của website. Trong mỗi trường hợp thì khi người dùng kết nối tới một URL nào đó thì họ được chuyển hướng tới bất kỳ máy chủ nào trong cụm các máy chủ (cluster). Đây là cơ chế căn bằng tải cho lưu lượng mạng (Network Load Balancing) như được thể hiện trong Hình dưới đây:

Khi đó mỗi Web server trong cluster sẽ phải có một chứng chỉ SSL của riêng nó. Yêu cầu duy nhất là trường subject name của chứng chỉ cần trùng với tên miền mà Web client sử dụng để kết nối tới website.

Một sự hiểu nhầm thường gặp là cho rằng các Web server trong cluster phải có một chứng chỉ SSL cùng với khóa bí mật giống nhau. Thực ra nếu mua các chứng chỉ cho từ các tổ chức thương mại như VeriSign hay RSA thì rất có thể họ yêu cầu khách hàng cần các chứng chỉ khác nhau cho mỗi Web server.

  • Web Server được bảo vệ bởi ISA Server với cấu hình Server Publishing

Khi áp dụng cấu hình Server Publishing trong ISA Server thì tất cả các lưu lượng kết nối tới cổng TCP 443 mà ISA Server đang lắng nghe trên đó sẽ được chuyển hướng tới Web server nằm đằng sau firewall này:

Trong cấu hình này, chứng chỉ SSL phải được cài đặt tại Web server. Tên miền trong trường Subject của chứng chỉ phải khớp với tên miền mà Web client dùng để kết nối tới giao tiếp mạng ngoài (external interface) của ISA Server. Nói cách khác, tên miền này phải được phân giải thành địa chỉ IP được gán cho card giao tiếp mạng ngoài của ISA Server. Dạng cấu hình này được cũng được hỗ trợ bởi nhiều firewall phổ biến khác của Cisco hay Checkpoint. Như vậy, yêu cầu được thỏa mãn là triển khai mã hóa dữ liệu được truyền giữa giữa hai điểm đầu cuối là Web server và Web client.

  • Web Server được bảo vệ bởi ISA Server với cấu hình Web Publishing

Khi áp dụng cấu hình Web Publishing, dữ liệu mà ISA Server tiếp nhận từ Web client sẽ được giải mã và kiểm duyệt bằng các bộ lọc ở tầng ứng dụng (ví dụ, URL Scanning) để phát hiện những lưu lượng Web có thể là mã độc hoặc các dạng tấn công Web khác. Có hai lựa chọn để sử dụng SSL với cấu hình Web Publishing là:

a.Triển khai SSL cho kết nối giữa hai điểm đầu cuối (End-to-End SSL)

Ở đây, SSL được thực hiện giữa Web client và ISA Server cũng như là giữa ISA Server và Web server.

Hai chứng chỉ SSL khác nhau phải được cài đặt ở cả ISA Server và Web server và hai kết nối SSL tách biệt được thiết lập là:

  1. Kết nối SSL đầu tiên xảy ra giữa Web client và ISA Server. Trường Subject của chứng chỉ được cài tại ISA Server phải chứa tên miền mà Web client sử dụng để kết nối tới Web server, và tên miền này phải được phân giải thành địa chỉ IP mặt ngoài của ISA Server.
  2. Kết nối SSL thứ hai xảy ra giữa ISA Server và Web server. Trường Subject của chứng chỉ được cài tại Web server phải chứa tên miền hoặc địa chỉ IP giống với thiết lập Web Publishing tại ISA Server.

b. Triển khai SSL giữa Web client và ISA Server

Kết nối SSL chỉ được thực hiện giữa Web client và ISA Server.

Chỉ cần một chứng chỉ SSL được cài đặt tại ISA Server. Lưu lượng HTTPS từ Web client sau khi được giải mã và kiểm duyệt bởi bộ lọc tầng ứng dụng của ISA Server sẽ được chuyển tới Web server dưới dạng HTTP (không được mã hóa) thông thường.

Ở đây, trường Subject của chứng chỉ của Web server phải chứa tên miền mà Web client dùng để kết nối tới Web server và tên miền này phải được phân giải thành địa chỉ IP mặt ngoài của ISA Server.

Lựa chọn mẫu chứng chỉ

Mẫu chứng chỉ Web Server mặc định sẽ đáp ứng nhu cầu của hầu hết các tổ chức muốn triển khai SSL cho các máy chủ Web nội bộ. Thay đổi duy nhất phải được thực hiện là chỉnh lại quyền hạn của mẫu chứng chỉ này để cho phép quyền Read và Enroll được gán cho universal hoặc global group mà chứa các tài khoản người dùng quản trị Web server.

Cấp phát chứng chỉ cho máy chủ Web

Các lựa chọn để cấp chứng chỉ từ một Windows Server-based Enterprise CA là:

  • Cấp chứng chỉ cho các máy chủ web chạy IIS nằm trong domain.
  • Cấp chứng chỉ cho các máy chủ web chạy IIS không nằm trong domain.
  • Cấp chứng chỉ cho các máy chủ web không phải IIS như Apache, Lighthttpd, v.v..

[News] – Điểm yếu trong việc áp dụng giao thức bảo mật SSL trên Android

Phương thức thông dụng nhất để bảo vệ luồng dữ liệu truyền tải qua mạng trên nền tảng Android thường là SSL hay TLS ( Secure Sockets Layer và Transport Layer Security ). Hiện có hàng ngàn ứng dụng trên sàn giao dịch ứng dụng Google Play đang áp dụng phương thức này 

Một nhóm các nhà nghiên cứu từ các trường đại học về kĩ nghệ khoa học hàng đầu của Hoa Kỳ đã có một nghiên cứu về việc các ứng dụng Android hiện nay chứa hàng loạt sai lầm đáng ngại trong cách ứng dụng SSL/TLS vào việc bảo mật dữ liệu truyền tải qua mạng, điều này dẫn tới khả năng xảy ra các cuộc tấn công kiểu Man-in-the-Middle -1- sẽ khiến các thông tin, dữ liệu nhạy cảm của người dùng như tài khoản giao dịch ngân hàng, thông tin cá nhân, tài liệu mật, bị đánh cắp khi người dùng sử dụng các ứng dụng Android tưởng chừng an toàn này 

Nhóm nghiên cứu đã thử nghiệm trên 100 ứng dụng được lựa chọn từ Android market, và họ đã xác định được 41 ứng dụng trong số đó có khả năng bị tấn công đánh cắp thông tin ( tỷ lệ 41% ). Các nhà nghiên cứu đã tạo ra một công cụ tấn công thử nghiệm gọi là MalloDroid, được thiết kế chuyên biệt để khai thác các lỗi về ứng dụng sai cách SSL/TLS trong các ứng dụng android, giúp chỉ ra các ứng dụng này hiện đang khiến người dùng gặp nguy cơ bị đánh cắp dữ liệu mật như thế nào 

Họ đã thành công trong việc thu thập các dữ liệu mật của người dùng các ứng dụng bị lỗi áp dụng sai SSL/TLS như Tài khoản ngân hàng, tài khoản các dịch vụ online như Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, tài khoản truy cập các máy chủ quan trọng, các địa chỉ email chứa thông tin quan trọng… 
Nghiên cứu cũng cho thấy việc hoàn toàn có thể chèn và kích hoạt mã độc từ xa vào các ứng dụng android bị lập trình sai dẫn tới áp dụng sai giao thức SSL/TLS. Các tác giả đã cung cấp rộng rãi nghiên cứu này với tên “Why Eve and Mallory Love Android: An Analysis of Android (In)Security“. 

Điều quan trọng cần phải nắm là: đây là vấn đề cực kỳ nghiêm trọng, các lập trình viên với trách nhiệm của mình phải tuân thủ đúng các chỉ dẫn khi áp dụng giao thức SSL/TLS để tránh tạo các lỗ hổng để hacker khai thác và đánh cắp thông tin mật của người dùng. Đồi với những ai còn đang tự hỏi SSL là gì thì vui lòng tham khảo tài liệu “Beginner Guide to SSL Certificates”.

(Theo The Hacker News)

Giải thích thuật ngữ: 
Phương thức tấn công Man-in-the-Middle: thường hay được viết tắt là MITM, là kiểu tấn công mà tin tặc tìm cách đứng chặn ngay giữa hai máy tính đang truyền tải dữ liệu để lấy cắp thông tin đang truyền tải. Cách vốn hữu hiệu nhất để ngăn MITM là áp dụng SSL đúng cách, lúc này tin tặc có đánh cắp được tất cả các gói tin trung chuyển qua internet thì cũng không có cách gì giải mã được do nó đã bị mã hóa.

Lời khuyên cá nhân: 
Các lỗi áp dụng sai giao thức SSL/TLS này thực sự không mới, bản thân nền tảng android cũng không yêu cầu nghiêm ngặt trong việc phải áp dụng SSL/TLS một cách đúng đắn, điều này làm Android tỏ ra thua kém khi so sánh với nền tảng iOS. 
Đây là lúc cần cảnh báo người dùng, để an toàn, nên tránh sử dụng internet cho các công việc quan trọng như chuyển khoản ngân hàng tại các điểm truy cập internet công cộng. Sẽ an toàn hơn nếu bạn sử dụng kết nối Cellgular ví dụ như 4G LTE, 3G, EDGE, GPRS… thay vì kết nối vào các mạng wifi công cộng.

%d bloggers like this: