JWT của bạn đang đánh lừa bạn - Vấn đề ủy quyền không ai giải quyết đúng cách

Một mã thông báo hợp lệ chứng minh danh tính của người dùng. Tuy nhiên, mã thông báo này gần như không cung cấp thông tin về những gì người dùng được phép thực hiện. Khoảng cách giữa hai mệnh đề trên là nơi hầu hết các kiến trúc ủy quyền sụp đổ một cách âm thầm và là nơi các mạng botnet (mạng máy tính ma) lặng lẽ xâm nhập. Thời gian đọc: khoảng 20 phút Cấp độ: Kỹ sư cấp cao, Kiến trúc sư nền tảng/bảo mật, Trưởng nhóm kỹ thuật Thẻ: Ủy quyền (Authorization), OPA (Open Policy Agent), Open Policy Agent, Chính sách dưới dạng mã (Policy as Code), Keycloak, Bảo mật (Security), Microservices, RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control), Botnet. Phần 2/2 — Đọc Phần 1: Giải thích Xác thực & Ủy quyền: So sánh Okta và Keycloak, Luồng & Yêu cầu/Phản hồi thực tế → Bẫy mã thông báo Bạn đã thực hiện mọi thứ đúng cách. Bạn đã triển khai OAuth 2.0 với PKCE. Các JWT (JSON Web Token) của bạn có thời gian sống ngắn. Bạn xác thực chữ ký, nhà phát hành, đối tượng, thời gian hết hạn – mọi yêu cầu. Bạn đã đọc Phần 1 của loạt bài này và bạn đang gật đầu đồng tình. Và sau đó, quản lý sản phẩm của bạn nói: "Người dùng tài chính ở khu vực EU chỉ có thể xuất báo cáo trong giờ làm việc, nhưng chỉ khi báo cáo không chứa PII (Thông tin nhận dạng cá nhân), và chỉ khi quản lý của họ đã phê duyệt yêu cầu truy cập dữ liệu trong 30 ngày qua." JWT của bạn ghi "role": "finance". Chỉ có vậy. Đó là toàn bộ tín hiệu ủy quyền trong mã thông báo của bạn. Và bây giờ bạn có một cây quyết định với sáu nhánh có thể thay đổi bất cứ lúc nào, không thể mã hóa cứng và cần được kiểm toán cho cuộc kiểm toán SOC 2 Type II của bạn. Chào mừng đến với vấn đề ủy quyền thực sự. Bài viết này đề cập đến những gì xảy ra sau khi mã thông báo được xác thực – lớp mà hầu hết các ứng dụng đang thực hiện một cách nguy hiểm sai lầm. Chúng ta sẽ đề cập đến: Tại sao ủy quyền dựa trên mã thông báo sụp đổ ở quy mô lớn Bốn mô hình ủy quyền và khi nào mỗi mô hình được áp dụng Ủy quyền dựa trên mã và lý do tại sao nó trở thành một gánh nặng Các công cụ quy tắc: sức mạnh và cạm bẫy Open Policy Agent (OPA) — kiến trúc, ngôn ngữ Rego, yêu cầu/phản hồi thực tế Bức tranh tổng thể về các công cụ chính sách: Cedar, Casbin, Cerbos, SpiceDB — với những đánh đổi trung thực Cách các mạng botnet khai thác ủy quyền yếu kém — và cách ngăn chặn chúng ở lớp chính sách Hãy xây dựng hệ thống thực sự bền vững. Phần 1 — Tại sao JWT của bạn không đủ Ảo ảnh ủy quyền JWT Một mã thông báo truy cập JWT mã hóa các yêu cầu (claims). Các yêu cầu là các khẳng định tĩnh được đưa vào mã thông báo tại thời điểm phát hành. Vấn đề là: các quyết định ủy quyền gần như không bao giờ tĩnh. Hãy xem xét những gì một quyết định ủy quyền thực sự yêu cầu: CÂU HỎI: Người dùng U có thể thực hiện hành động A trên tài nguyên R không? Yêu cầu: ✓ U là ai? ← JWT cho bạn biết điều này ✓ U thuộc vai trò/nhóm nào? ← JWT có thể cho bạn biết điều này ✗ Trạng thái hiện tại của R là gì? ← JWT không biết gì ✗ Các quy tắc sở hữu của R là gì? ← JWT không biết gì ✗ Thời gian/ngữ cảnh hiện tại là gì? ← JWT không biết gì ✗ Quyền truy cập của U đã bị thu hồi kể từ ← JWT không biết gì khi mã thông báo được cấp chưa? (mã thông báo có giá trị cho đến khi hết hạn) ✗ U có yêu cầu phê duyệt đang chờ xử lý ← JWT không biết gì cho tài nguyên cụ thể này không? JWT chỉ biết về người dùng tại thời điểm phát hành. Mọi thứ động – trạng thái tài nguyên, chính sách tổ chức, quy tắc dựa trên thời gian, quy trình phê duyệt – đều nằm ngoài mã thông báo. Vấn đề bùng nổ Microservices Trong một hệ thống nguyên khối (monolith), logic ủy quyền của bạn nằm ở một nơi. Không hoàn hảo, nhưng có thể quản lý được. Trong một kiến trúc microservices với 40 dịch vụ: Nếu không có lớp ủy quyền tập trung, bạn sẽ gặp phải: Sự trôi dạt chính sách — 6 nhóm triển khai cùng một quy tắc theo 6 cách khác nhau Truy cập bóng — các dịch vụ gọi các dịch vụ khác mà không có bất kỳ kiểm tra ủy quyền nào Địa ngục kiểm toán — không có nơi nào duy nhất để trả lời "ai có thể truy cập X vào thứ Ba tuần trước?" Ghép nối triển khai — thay đổi một quy tắc kinh doanh yêu cầu triển khai 12 dịch vụ Đây là sự ép buộc về kiến trúc. chức năng cho các công cụ chính sách bên ngoài. Phần 2 – Bốn mô hình ủy quyền Trước khi chọn một công cụ, cần xác định rõ mô hình mà vấn đề của bạn yêu cầu. Hầu hết các hệ thống thực tế cần kết hợp nhiều mô hình. Mô hình 1: RBAC – Kiểm soát truy cập dựa trên vai trò Đây là mô hình được triển khai rộng rãi nhất. Quyền hạn được gắn với các vai trò; các vai trò được gán cho người dùng. Người dùng ──→ Vai trò ──→ Quyền hạn ───────────────────────────── alice → quản trị viên → [đọc, ghi, xóa, quản lý_người_dùng] bob → biên tập viên → [đọc, ghi] carol → người xem → [đọc] Điểm mạnh: Đơn giản, có thể kiểm toán, trực quan, được hỗ trợ tốt ở mọi nơi Điểm yếu: Bùng nổ vai trò (các doanh nghiệp có hơn 500 vai trò), không nhận biết ngữ cảnh, mức độ chi tiết thô Sử dụng khi: Quyền hạn ánh xạ rõ ràng tới một tập hợp nhỏ các vai trò tổ chức Mô hình 2: ABAC – Kiểm soát truy cập dựa trên thuộc tính Các quyết định truy cập được tính toán từ các thuộc tính của chủ thể (người dùng), tài nguyên, hành động và môi trường, được đánh giá dựa trên một chính sách. CHÍNH SÁCH: cho_phép_truy_cập = ( chủ_thể.mức_độ_phân_loại >= tài_nguyên.phân_loại VÀ chủ_thể.phòng_ban TRONG tài_nguyên.các_phòng_ban_được_phép VÀ môi_trường.địa_chỉ_IP TRONG chủ_thể.các_dải_IP_tin_cậy VÀ hành_động TRONG ["đọc", "tải_xuống"] VÀ KHÔNG tài_nguyên.đã_lưu_trữ ) Điểm mạnh: Cực kỳ linh hoạt, nhận biết ngữ cảnh, xử lý các quy tắc đa chiều phức tạp Điểm yếu: Phức tạp để suy luận, khó gỡ lỗi hơn, rủi ro chính sách lan rộng Sử dụng khi: Quyền hạn mang tính ngữ cảnh, đa chiều hoặc thay đổi thường xuyên Mô hình 3: ReBAC – Kiểm soát truy cập dựa trên mối quan hệ Quyền truy cập được xác định bởi biểu đồ các mối quan hệ giữa người dùng và tài nguyên. Đây là mô hình đằng sau Google Drive, Google Docs và Google Calendar – và là mô hình được mô tả trong bài báo Zanzibar của Google (được xuất bản tại USENIX 2019). alice chủ_sở_hữu tài_liệu:ngân_sách_quý_3 bob biên_tập_viên tài_liệu:ngân_sách_quý_3 carol người_xem thư_mục:tài_chính ──→ (thừa_kế) người_xem tài_liệu:ngân_sách_quý_3 Điểm mạnh: Mở rộng quy mô cho các mô hình quyền hạn mạng xã hội và SaaS, rất biểu cảm Điểm yếu: Duyệt biểu đồ phức tạp, khó triển khai từ đầu Sử dụng khi: Quyền hạn có tính phân cấp, kế thừa hoặc dựa trên mối quan hệ (ví dụ: Google Drive, GitHub, Notion) Mô hình 4: Chính sách dưới dạng mã (Policy-as-Code) Các chính sách được thể hiện dưới dạng mã hoặc dữ liệu có cấu trúc trong một ngôn ngữ dành riêng cho miền, được lưu trữ trong kiểm soát phiên bản, được kiểm thử và thực thi bởi một công cụ chính sách chuyên dụng. rego # Chính sách OPA - ngôn ngữ Rego package finance.reports default allow = false allow { input.user.role == "analyst" input.user.department == "finance" input.resource.classification != "pii" is_business_hours } is_business_hours