Thiết kế hệ thống xác thực và ủy quyền chức năng

Trong bài viết này, chúng ta sẽ nói về một hệ thống thực hiện xác thực và ủy quyền một cách an toàn. Để bắt đầu hãy hiểu, sự khác biệt giữa Xác thực và Ủy quyền là gì.

• Xác thực là quá trình chứng minh bạn là ai, bạn nói bạn là ai khi truy cập một ứng dụng.
• Ủy quyền là quá trình xác định và thực thi các chính sách truy cập - tức là những gì bạn có thể làm sau khi được xác thực.

Trong bài viết này, chúng ta sẽ thấy:

• Tại sao Xác thực và Ủy quyền lại quan trọng
• Cách xác thực hoạt động
• Cách ủy quyền hoạt động
• Thiết kế hệ thống xác thực
• Phần kết luận

Tại sao Xác thực và Ủy quyền lại quan trọng?

Giả sử chúng ta đang họp và bạn là người dẫn dắt cuộc trò chuyện. Để yêu cầu cập nhật/trạng thái của một thứ gì đó cho đúng người, bạn cần xác định (tức là Xác thực ) người đó. Thậm chí để chia sẻ một số dữ liệu nhạy cảm với một người, bạn cần xác thực người đó một cách chính xác. Và đó là nơi xác thực xuất hiện.

Bây giờ, trong cùng một cuộc họp, cần phải đưa ra một số quyết định. Vì vậy, những người có quyền đưa ra những quyết định đó phải là người đưa ra quyết định, chúng ta không thể chỉ cho phép mọi người làm mọi việc. Rõ ràng là một số người không đủ khả năng để đưa ra một số quyết định, và một số chắc chắn sẽ cố gắng giải quyết vấn đề tồi tệ nhất. Vì vậy, điều đó mang lại Sự ủy quyền , điều đó mang lại cho một số người nhất định quyền đối với một số hoạt động nhất định.

Xác thực hoạt động như thế nào?

Để xác thực một người, chúng ta có thể gán một cụm từ duy nhất cho mỗi người và yêu cầu người đó nói chính xác cụm từ đó và tên của họ. Chúng tôi có thể nói rằng được rồi, chúng tôi đã xác định được người đó. Đây là cách tiếp cận tên người dùng và mật khẩu thông thường. Khi thông tin xác thực phù hợp được cung cấp, hệ thống sẽ coi danh tính là hợp lệ và cấp quyền truy cập. Điều này được gọi là xác thực 1FA hoặc xác thực một yếu tố (SFA).

SFA được coi là khá không an toàn. Tại sao? Bởi vì người dùng nổi tiếng là kém trong việc giữ an toàn thông tin đăng nhập của họ. Xác thực đa yếu tố (MFA) là một giải pháp thay thế an toàn hơn, yêu cầu người dùng chứng minh danh tính của họ bằng nhiều cách. Một số cách như vậy là:

• Số PIN/OTP sử dụng một lần
• Ứng dụng xác thực do bên thứ 3 bảo mật điều hành (ví dụ: Google/Microsoft Authenticator)
• Sinh trắc học

Sau khi được xác thực, người đó sẽ tiếp tục thực hiện các hành động một cách tự do trên ứng dụng. Và ứng dụng này dự kiến sẽ giúp người đó được nhận ra trong suốt hành trình của họ mà không quên họ. Lý tưởng nhất là sẽ là quá nhiều nếu yêu cầu người dùng cung cấp mật khẩu mỗi khi họ chuyển sang một trang khác hoặc họ thực hiện một số hoạt động. Vì vậy, chúng tôi cần một cách để giữ cho người dùng được xác thực sau khi họ đã nhập thông tin xác thực và họ đã được xác thực một lần. Điều này được gọi là Quản lý phiên .

2 cách để giữ cho người dùng được xác thực:

• Xác thực dựa trên phiên : Khi người dùng đăng nhập vào một trang web trên trình duyệt, máy chủ sẽ tạo một phiên cho người dùng đó và gán một sessionid. Sessionid này được máy chủ lưu trữ để tham khảo và gửi lại cho người dùng để lưu trữ trong cookie trên trình duyệt. Bây giờ mỗi khi người dùng đưa ra yêu cầu, trình duyệt sẽ gửi sessionid cùng với yêu cầu. Điều này sẽ giúp xác thực yêu cầu. Và do đó, duy trì xác thực trong khi người dùng ở trên trang web.
• Xác thực dựa trên mã thông báo : Để thực hiện việc này, máy chủ sẽ tạo mã thông báo được mã hóa được gửi cho người dùng và chỉ được trình duyệt lưu dưới dạng HttpOnly Cookies. Tất cả thông tin bắt buộc như thông tin người dùng, quyền và thời hạn sử dụng của mã thông báo đều được mã hóa trong mã thông báo. Mã thông báo được gửi cùng với các cuộc gọi đến máy chủ. Máy chủ chỉ cần giải mã mã thông báo bằng khóa bí mật và xác minh người dùng. Mã thông báo này được làm mới theo định kỳ.

Sự khác biệt chính giữa hai cách tiếp cận này là việc xác thực dựa trên mã thông báo là Không trạng thái , vì mã thông báo không cần phải được lưu trữ ở phía máy chủ. Nhưng đối với xác thực dựa trên phiên, mã thông báo cũng cần được lưu trữ ở phía máy chủ, điều này làm cho nó có trạng thái Stateful . Điều này gây ra sự phức tạp khi hệ thống được mở rộng quy mô hoặc số lượng người dùng tăng lên.

Để xác thực dựa trên mã thông báo, chúng tôi chủ yếu sử dụng JWT (Mã thông báo web JSON).

Ủy quyền hoạt động như thế nào?

Sau khi người dùng được xác thực, chúng tôi vẫn cần đảm bảo rằng họ chỉ được phép truy cập vào các tài nguyên mà họ có quyền truy cập. Truy cập trái phép vào dữ liệu nhạy cảm có thể là một thảm họa. Theo nguyên tắc ít đặc quyền nhất, các công ty thường thiết lập các chính sách truy cập sao cho theo mặc định, bạn hoàn toàn có quyền truy cập vào những gì được yêu cầu đối với mình. Và sau đó, dần dần bạn sẽ có quyền truy cập bổ sung. Các cách phổ biến để phân khúc quyền truy cập là:

• Kiểm soát truy cập dựa trên vai trò (RBAC) : Người dùng được chỉ định vào một nhóm/vai trò nhất định đi kèm với các quyền đã đặt. Ví dụ: quản trị viên, thành viên, chủ sở hữu.
• Kiểm soát truy cập dựa trên chính sách (PBAC) : Tự động xác định các đặc quyền truy cập trong quá trình ủy quyền dựa trên các chính sách và quy tắc. Các chính sách dựa trên vai trò của người dùng, chức năng công việc và yêu cầu của tổ chức.
• Kiểm soát truy cập dựa trên thuộc tính (ABAC) : Người dùng được phép truy cập theo các thuộc tính như chức danh, chứng nhận, đào tạo và/hoặc các yếu tố môi trường như vị trí.
• Danh sách kiểm soát truy cập (ACL) : Mỗi người dùng hoặc tổ chức có các quyền riêng lẻ có thể bật hoặc tắt, tương tự như cài đặt một ứng dụng mới trên điện thoại của bạn và quyết định cấp quyền nào (dịch vụ định vị, danh bạ, v.v.)

ACL thường được sử dụng ở cấp độ chi tiết hơn ABAC hoặc RBAC - ví dụ: để cấp cho người dùng cá nhân quyền truy cập vào một tệp nhất định. ABAC và RBAC thường được thiết lập như các chính sách toàn công ty.

Thiết kế hệ thống xác thực

Yêu cầu

Trước tiên hãy bắt đầu bằng việc xác định các yêu cầu Chức năng của hệ thống:

• Đăng ký : Cho phép người dùng đăng ký bằng cách cung cấp thông tin cần thiết.
• Đăng nhập : Xác thực người dùng dựa trên thông tin đăng nhập của họ.
• Quản lý phiên : Quản lý hiệu quả phiên người dùng để đảm bảo an ninh.
• Khôi phục mật khẩu : Cung cấp quy trình an toàn để người dùng khôi phục mật khẩu của họ.
• Kiểm soát truy cập : Xác định vai trò và quyền cho các loại người dùng khác nhau.
• Đường mòn kiểm tra : Duy trì nhật ký chi tiết về các sự kiện xác thực để kiểm tra.
• Hiệu suất : Đảm bảo độ trễ thấp và thời gian phản hồi nhanh.

Một số yêu cầu phi chức năng mà chúng tôi sẽ không xem xét trong phạm vi bài viết này là:

• Xác thực đa yếu tố (MFA) : Triển khai hệ thống MFA mạnh mẽ.
• Bảo mật : Ưu tiên bảo mật dữ liệu thông qua mã hóa, lưu trữ an toàn và liên lạc an toàn.
• Khả năng mở rộng : Thiết kế hệ thống để xử lý số lượng người dùng và giao dịch ngày càng tăng.
• Độ tin cậy : Giảm thiểu thời gian ngừng hoạt động của hệ thống và đảm bảo tính sẵn sàng cao.
• Khả năng sử dụng : Phát triển giao diện người dùng trực quan để có trải nghiệm liền mạch.

Ước tính công suất

Ước tính lưu lượng truy cập

Trước tiên hãy bắt đầu với Ước tính lưu lượng truy cập . Giả sử lưu lượng truy cập trung bình là 100.000 mỗi tháng. Chúng tôi ước tính lưu lượng truy cập người dùng là 100 nghìn mỗi tháng. Có nghĩa là 0,04 yêu cầu mỗi giây. Chúng tôi sẽ cần phản hồi từng yêu cầu trong vòng 500 mili giây trong 90% thời gian, tức là chúng tôi yêu cầu độ trễ p90 là 500 mili giây.

 assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04

Mục tiêu cấp độ dịch vụ (SLO) : 500 mili giây (độ trễ tối đa có thể chấp nhận, không quan trọng đối với tải trên hệ thống) Dung lượng trung bình mà 1 phiên bản có thể mất, dựa trên tính toán của chúng tôi là khoảng 35 mili giây để phân phát một yêu cầu, giả sử không có quá trình xử lý nặng nào xảy ra cho yêu cầu cụ thể.

Hãy tạo thêm hai số liệu phái sinh bằng cách sử dụng các số liệu trên.

• Dung lượng : Tồn đọng có thể chấp nhận trên mỗi phiên bản: Số lượng yêu cầu (tải) tối đa mà một phiên bản có thể chấp nhận mà không ảnh hưởng đến SLO.
• Nhu cầu : Tồn đọng trên mỗi phiên bản: Tổng số yêu cầu (tải) chảy vào một đơn vị/phiên bản dựa trên lưu lượng hiện tại.

Như vậy,

 SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04

Với nhu cầu và năng lực sẵn có, hãy tính tổng số instance cần thiết.

 total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1

Do đó, chúng tôi có thể dễ dàng xử lý 100 nghìn yêu cầu mỗi tháng, với 0,04 yêu cầu mỗi giây, với 1 phiên bản. Trong đó mỗi đơn vị có thể xử lý 20 yêu cầu mỗi giây mà không ảnh hưởng đến SLO.

Ước tính lưu trữ

Lý tưởng nhất là chúng tôi cần lưu trữ chi tiết người dùng cho từng người dùng để truy cập xác thực và ủy quyền. Giả sử là 5kb/người dùng

 monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB

Vì vậy, mỗi tháng, giả sử chúng tôi tiếp nhận 500 người dùng mới, chúng tôi sẽ yêu cầu thêm 2GB dung lượng lưu trữ. Trong trường hợp chúng tôi muốn giữ nhật ký xác thực. Mỗi yêu cầu xác thực dự kiến sẽ mất 2kb để lưu trữ.

 auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB

Do đó, mỗi tháng chúng tôi sẽ cần thêm 200 MB, giả sử lưu lượng truy cập hàng tháng là 100 nghìn.

Thiết kế cơ sở dữ liệu

Bây giờ chúng ta đã thực hiện ước tính công suất. Cho phép tạo các lược đồ cơ sở dữ liệu cần thiết để hỗ trợ các yêu cầu chức năng.

Hãy nhanh chóng đi qua các bảng. Chúng tôi đang sử dụng 6 bảng.

1. Người dùng - Để lưu trữ tất cả thông tin người dùng
2. Thông tin xác thực - Để lưu trữ thông tin xác thực truy cập/làm mới sau khi người dùng đã được cấp quyền.
3. Mật khẩu - Để lưu trữ mật khẩu người dùng được mã hóa của người dùng.
4. Yêu cầu mật khẩu - Để lưu trữ các yêu cầu thay đổi mật khẩu của một người dùng cụ thể.
5. Phiên - Để lưu trữ thời điểm người dùng có phiên hoạt động và hoạt động cuối cùng của họ là khi nào.
6. Phê duyệt hoạt động - Để lưu trữ các yêu cầu phê duyệt cho một hoạt động được thực hiện bởi một người dùng cụ thể, hoạt động đó sẽ được quản trị viên xác minh.

Thiết kế cấp cao cho hệ thống xác thực

Điểm cuối hệ thống

Thực hiện các yêu cầu

Bây giờ, với tất cả mọi thứ đã sẵn sàng, hãy xem cách chúng tôi có thể hoàn thành tất cả các yêu cầu.

Sự đăng ký

• Yêu cầu - Khi người dùng mới truy cập ứng dụng của chúng tôi. Chúng tôi cần lưu trữ thông tin chi tiết của người dùng để có thể ủy quyền/nhận dạng người dùng vào lần tiếp theo họ truy cập.
• Đã hoàn thành - Khi người dùng mới truy cập ứng dụng và nhập thông tin chi tiết về người dùng cùng với email và mật khẩu của họ. Điều đó sẽ được ghi lại trong cơ sở dữ liệu. Thông tin chi tiết về người dùng sẽ được lưu trữ trong bảng Người dùng. Và mật khẩu sẽ được lưu trữ trong bảng thông tin xác thực ở dạng mã hóa.

Đăng nhập

• Yêu cầu - Khi người dùng hiện tại truy cập ứng dụng của chúng tôi. Chúng tôi cần xác định người dùng để có thể ủy quyền/xác định hành động của họ và hiển thị cho họ dữ liệu thuộc về họ.
• Đã hoàn thành - Khi người dùng hiện tại truy cập ứng dụng và nhập thông tin chi tiết, email và mật khẩu của họ. Chúng tôi băm mật khẩu và khớp hàm băm với hàm băm được lưu trữ cho người dùng trong Bảng thông tin xác thực. Nếu nó khớp thì chúng tôi đã có thể xác định người dùng thành công. Nếu không, họ cần nhập đúng mật khẩu mà họ đã nhập khi đăng ký. Quá trình này được gọi là Xác thực .

Quản lý phiên

• Yêu cầu - Khi người dùng đã tự xác thực bằng cách nhập người dùng và mật khẩu của họ. Chúng tôi cần đảm bảo rằng họ luôn đăng nhập khi thực hiện các hành động trong tương lai/cố gắng xem dữ liệu nhạy cảm mà không cần phải nhập lại mật khẩu nhiều lần.
• Fulfilled - Khi người dùng xác thực thành công. Máy chủ xác thực sẽ chia sẻ 2 mã thông báo với khách hàng. Access_token và Refresh_token . Access_token có thể chứa dữ liệu được mã hóa và nó có thời gian hết hạn ngắn vì lý do bảo mật. Khi khách hàng có access_token, nó sẽ gửi lại access_token cùng với mọi yêu cầu giúp xác thực yêu cầu. Khi access_token hết hạn, khách hàng phải yêu cầu một access_token mới bằng cách sử dụng Refresh_token được cung cấp. Điều này giúp duy trì một phiên.

Khôi phục mật khẩu

• Yêu cầu - Khi người dùng quên mật khẩu, họ cần có thể đặt lại mật khẩu một cách an toàn.
• Đã hoàn tất - Khi người dùng quên mật khẩu, họ có thể gửi địa chỉ email của mình vào trang quên mật khẩu và chúng tôi sẽ tạo mã một lần và gửi liên kết đến email của họ. Khi người dùng nhấp vào liên kết này với mã và địa chỉ email. Chúng tôi sẽ có thể xác định một cách an toàn rằng yêu cầu khôi phục mật khẩu là xác thực. Và cung cấp cho người dùng để đặt mật khẩu mới của họ. Và do đó có thể khôi phục mật khẩu.

Kiểm soát truy cập

• Yêu cầu - Khi người dùng thực hiện một hành động nhất định, chúng tôi cần đảm bảo rằng người dùng được xác thực để thực hiện hành động đó và chỉ khi đó mới cho phép hành động đó xảy ra.
• Đã hoàn thành - Chúng tôi sẽ duy trì một danh sách các hành động, giả sử từ 1-12, để đơn giản. Đối với mỗi người dùng, chúng tôi sẽ duy trì các hành động được xác thực cho người dùng đó. Vì vậy, bây giờ giả sử người dùng cố gắng thực hiện hành động #id 4. Chúng tôi sẽ kiểm tra xem người dùng có quyền thực hiện hành động 4. Nếu có, chúng tôi sẽ tiếp tục và hoàn thành yêu cầu. Mặt khác, chúng tôi cho thấy rằng yêu cầu không thành công do thiếu quyền.

Đường mòn kiểm toán

• Yêu cầu - Trong trường hợp xảy ra sự cố bảo mật, chúng tôi phải có đủ nhật ký để xem qua và có lý do chính đáng về những gì có thể đã xảy ra/hoặc bất kỳ manh mối nào về nguyên nhân có thể xảy ra của sự cố đó.
• Đã hoàn thành - Đối với những trường hợp như vậy, chúng tôi có thể lưu giữ nhật ký cho mọi hành động xác thực xảy ra trên máy chủ. (Một). Đối với mỗi yêu cầu đăng nhập, chúng tôi sẽ lưu giữ nhật ký về thời điểm xác thực xảy ra, từ đâu, ip và các chi tiết liên quan khác. (b). Đối với mỗi yêu cầu khôi phục mật khẩu, chúng tôi sẽ lưu giữ nhật ký về thời điểm bắt đầu, từ đâu, ip, yêu cầu đã hoàn tất hay chưa và các chi tiết liên quan khác. (c). Ngoài ra, chúng tôi sẽ lưu giữ nhật ký mỗi khi người dùng được ủy quyền/không được phép thực hiện một hành động và bởi ai. Nói chung, những nhật ký này sẽ có thể cho biết điều gì có thể đã xảy ra trong trường hợp bạn cố gắng hiểu một số tình huống.

Hiệu suất

• Yêu cầu - Yêu cầu về hiệu suất như đã thảo luận trong phần ước tính công suất, là 0,04 yêu cầu/giây và 100k yêu cầu mỗi tháng.
• Đã hoàn thành - Chúng tôi đã xử lý yêu cầu với đủ máy chủ trong phần ước tính dung lượng.

Phần kết luận

Trong bài viết này, chúng tôi bắt đầu bằng cách tìm hiểu sự khác biệt giữa Xác thực và Ủy quyền. Tiếp theo, chúng tôi đã tạo Hệ thống xác thực và ủy quyền. Đó là sự an toàn, bảo mật, mang lại hiệu suất đồng thời đáp ứng các tiêu chuẩn ngành và đáp ứng tất cả các yêu cầu mong muốn. Trong tương lai, tôi có thể cập nhật một số phần nhất định của bài viết để làm cho nó phù hợp cũng như cung cấp thêm thông tin và hiểu biết sâu sắc hơn trong việc xây dựng một hệ thống như vậy.