Xây dựng ứng dụng web để đánh giá yêu cầu truy cập tập trung

Ứng dụng đánh giá truy cập tập trung làm gì

Yêu cầu truy cập thường xuất hiện khắp nơi: một tin nhắn nhanh trên Slack “thêm tôi vào dự án”, một chuỗi email với ba quản lý được CC, một ticket trong một trong nhiều hàng đợi, và đôi khi một bảng tính ai đó cập nhật “tạm thời”. Kết quả là dễ đoán: yêu cầu bị bỏ sót, phê duyệt không đồng nhất, và không ai trả lời chắc chắn được ai đã phê duyệt gì (hoặc vì sao).

Một ứng dụng đánh giá truy cập tập trung khắc phục điều này bằng cách đưa các yêu cầu truy cập về một chỗ có cấu trúc duy nhất.

“Đánh giá tập trung” nói đơn giản

Đánh giá tập trung nghĩa là mọi yêu cầu đều chảy vào một hộp thư (hoặc hàng đợi) duy nhất với quy tắc nhất quán về thông tin cần thiết, ai phải phê duyệt, và cách quyết định được ghi lại.

Thay vì để người duyệt diễn giải các tin nhắn tự do, ứng dụng hướng dẫn người yêu cầu điền vào một biểu mẫu chuẩn, định tuyến yêu cầu đến người phê duyệt phù hợp, và lưu lại một dấu vết quyết định có thể truy xuất. Nghĩ: một hệ thống lưu trữ các quyết định truy cập, chứ không phải một tập hợp ảnh chụp màn hình và lịch sử chat.

Ai được lợi (và như thế nào)

• Người yêu cầu được lợi vì họ biết nộp yêu cầu ở đâu, cần những chi tiết gì, và cách kiểm tra trạng thái mà không phải nhắn tin làm phiền người khác.
• Người phê duyệt được lợi vì họ nhận được yêu cầu hoàn chỉnh theo định dạng nhất quán, có thể đưa quyết định có/không nhanh chóng với bối cảnh, và có thể ủy quyền hoặc leo thang khi cần.
• IT và an ninh được lợi vì họ có thể thực thi nguyên tắc quyền tối thiểu, giảm các ngoại lệ tạm thời, và chuẩn hóa quy trình phê duyệt giữa các nhóm.
• Người kiểm toán được lợi vì ứng dụng có thể tạo ra bản ghi kiểm toán: ai đã yêu cầu, ai phê duyệt, khi nào, quyền nào được cấp, và khi nào nó hết hạn hoặc bị thu hồi.

Bài viết này tập trung vào gì

Hướng dẫn này không phải để xây dựng một nền tảng định danh đầy đủ từ đầu. Nó tập trung vào phần lõi thực tế: thiết kế quy trình yêu cầu truy cập, mô hình dữ liệu phía sau tài nguyên và quyền, và những nguyên tắc an toàn cơ bản như phê duyệt, truy xuất nguồn gốc, và các kiểm soát hợp lý. Sau khi đọc xong, bạn sẽ có bức tranh rõ ràng về những gì ứng dụng cần làm trước khi chọn framework hoặc bắt đầu code.

Người dùng, vai trò và trách nhiệm

Một ứng dụng đánh giá truy cập tập trung sống hoặc chết bởi sự rõ ràng: ai tham gia, họ được phép làm gì, và họ bị ngăn cản làm gì. Bắt đầu bằng việc định nghĩa một tập nhỏ vai trò, rồi ánh xạ mọi màn hình và hành động tới những vai trò đó.

Các tác nhân cốt lõi trong một yêu cầu truy cập

Requester (nhân viên/nhà thầu): Gửi yêu cầu, cung cấp lý do nghiệp vụ, và theo dõi trạng thái. Họ nên xem được các yêu cầu của chính mình, thêm bình luận và hủy yêu cầu đang chờ—nhưng không được thấy ghi chú nội bộ dành cho người phê duyệt.

Manager: Xác nhận yêu cầu phù hợp với công việc của người đó và thời điểm hợp lý. Managers thường có thể phê duyệt/từ chối, bình luận, yêu cầu chỉnh sửa, và xem yêu cầu của người báo cáo trực tiếp.

Resource owner (chủ sở hữu hệ thống/app/dữ liệu): Xác thực quyền được yêu cầu có phù hợp với tài nguyên không và có thể phê duyệt/từ chối dựa trên rủi ro, giấy phép, và hạn chế vận hành.

IT admin / đội thực thi: Thực hiện quyền đã được phê duyệt (hoặc kích hoạt tự động hóa). Họ nên xem các yêu cầu đã được phê duyệt, thực hiện các bước thực thi, đính kèm chứng cứ (ảnh chụp màn hình/trích xuất log), và đánh dấu hoàn thành—không được thay đổi phê duyệt.

Security/Compliance reviewer (bước tùy chọn): Duyệt các truy cập rủi ro cao hơn (ví dụ: vai trò admin, bộ dữ liệu nhạy cảm). Họ có thể phê duyệt/từ chối, thêm các kiểm soát bắt buộc (MFA, tham chiếu ticket), hoặc yêu cầu quyền có thời hạn.

Auditor: Quyền chỉ đọc để tìm kiếm, lọc và xuất chứng cứ. Không có khả năng bình luận trực tiếp trên các yêu cầu đang hoạt động.

Quyền: mỗi vai trò thấy và làm gì

Định nghĩa quyền ở mức hành động: xem, phê duyệt/từ chối, ủy quyền, bình luận, và xuất. Giữ chặt chẽ: người duyệt chỉ nên thấy các yêu cầu được phân công cho họ, cộng với bất kỳ quyền hiển thị theo chính sách (ví dụ: quản lý thấy đội của họ).

Tách nhiệm công việc (Separation of duties - SoD)

Ngăn tự phê duyệt và vòng phê duyệt vòng. Quy tắc phổ biến:

• Người yêu cầu không thể phê duyệt yêu cầu của chính họ.
• Quản lý không thể phê duyệt quyền mà trao cho họ quyền kiểm soát chính sách phê duyệt (ví dụ: admin hệ thống phê duyệt).
• Với các vai trò đặc quyền cao, không cho phép một người duyệt duy nhất làm tất cả: yêu cầu người duyệt thứ hai (an ninh hoặc một chủ sở hữu khác).

Phủ tạm thời và ủy quyền

Lên kế hoạch cho việc vắng mặt ngay từ đầu. Hỗ trợ ủy quyền có thời hạn (ngày bắt đầu/kết thúc), kèm bản ghi kiểm toán ai ủy quyền cho ai. Hiển thị ủy quyền rõ ràng trên UI phê duyệt và cho phép admin reassignment khẩn cấp—với lý do bắt buộc.

Loại yêu cầu truy cập và dữ liệu cần thiết

Một ứng dụng đánh giá truy cập tập trung hoạt động tốt nhất khi coi các yêu cầu như các đối tượng có cấu trúc, không phải tin nhắn tự do. Đầu vào chuẩn giúp định tuyến dự đoán được, giảm trao đổi lại, và cải thiện bản ghi kiểm toán.

Loại yêu cầu cốt lõi

Phần lớn nhu cầu có thể được bao phủ bằng bốn loại:

• New access: cấp quyền lần đầu cho một người dùng.
• Change access: sửa đổi quyền hiện có (ví dụ Reader → Admin).
• Remove access: thu hồi quyền chủ động (offboarding, thay đổi vai trò, dọn dẹp quyền tối thiểu).
• Extension: gia hạn truy cập có thời hạn dài hơn so với phê duyệt ban đầu.

Mỗi loại nên ánh xạ rõ ràng tới mô hình RBAC của bạn (role, group, permission set) để việc thực thi không mơ hồ.

Dữ liệu cần thiết (và vì sao nó quan trọng)

Ít nhất, ghi nhận:

• Người dùng (người nộp so với đối tượng được cấp): ai cần truy cập.
• Tài nguyên: hệ thống/app/dự án mà quyền áp dụng.
• Mức truy cập: role/group/permission được yêu cầu.
• Lý do nghiệp vụ: lý do ngắn để người duyệt đánh giá.
• Thời hạn: vĩnh viễn hay có ngày kết thúc cho truy cập tạm thời.

Với tài nguyên rủi ro cao hơn, yêu cầu thêm trường để hỗ trợ quản trị truy cập nhất quán:

• Liên kết ticket (ví dụ: incident/change request): liên kết quyền với công việc có tài liệu.
• Xác nhận đào tạo: xác nhận đã hoàn thành các đào tạo bảo mật/tuân thủ cần thiết.
• Độ nhạy dữ liệu: có liên quan đến dữ liệu production, PII hay hệ thống tài chính không.

Mô hình trạng thái để mọi người đồng bộ

Định nghĩa vòng đời rõ ràng để người duyệt, người thực thi và người yêu cầu luôn biết bước tiếp theo:

Draft → Submitted → In Review → Approved/Denied → Fulfillment In Progress → Fulfilled → Expired/Revoked

Giữ “Fulfilled” riêng là quan trọng: một phê duyệt chưa hoàn thành cho tới khi quyền thực sự được cấp (bằng tay hoặc tích hợp SSO/provisioning). “Expired” (hoặc “Revoked”) giúp thực thi nguyên tắc quyền tối thiểu cho các quyền có thời hạn.

Thiết kế quy trình: định tuyến, leo thang và ngoại lệ

Một quy trình tốt làm hai việc cùng lúc: đẩy các yêu cầu thường xuyên nhanh, và làm chậm lại chỉ khi rủi ro hoặc mơ hồ cao. Chìa khóa là làm cho “ai phê duyệt gì” rõ ràng, dễ đoán và dễ kiểm toán.

Vẽ đường phê duyệt rõ ràng

Bắt đầu với chuỗi phê duyệt mặc định phù hợp cách quyết định thường được thực hiện. Một mẫu phổ biến là:

• Phê duyệt của quản lý (quyền này có cần thiết cho vai trò và công việc hiện tại không?)
• Phê duyệt của chủ sở hữu tài nguyên (điều này có phù hợp với cách hệ thống nên được sử dụng không?)
• Phê duyệt an ninh (có điều kiện) cho tài nguyên nhạy cảm hoặc quyền nâng cao

Giữ đường đi hiển thị trong view yêu cầu để người duyệt biết bước tiếp theo và người yêu cầu biết mong đợi.

Định tuyến dựa trên luật (không phải áp dụng một kiểu cho tất cả)

Thard-coding các đường phê duyệt dẫn đến ngoại lệ liên tục và công việc admin. Thay vào đó, định nghĩa luật định tuyến dựa trên:

• Tài nguyên (ví dụ: “Finance ERP” luôn cần phê duyệt chủ sở hữu)
• Mức rủi ro (ví dụ: vai trò admin, truy cập production, quyền ghi)
• Thuộc tính người yêu cầu (phòng ban, vị trí, loại hợp đồng)

Các luật cần dễ hiểu với người không phải kỹ sư. Dùng trình soạn thảo kiểu “when/then” (khi/thì) hoặc bảng đơn giản và bao gồm đường lui an toàn khi không có luật nào khớp.

SLA, leo thang và tự hết hạn

Phê duyệt sẽ bị ách trừ khi bạn thiết kế cho hành vi con người. Đặt SLA cho từng bước (ví dụ: quản lý: 2 ngày làm việc; chủ sở hữu: 3 ngày) và triển khai:

• Nhắc trước khi SLA hết hạn
• Leo thang đến người ủy quyền hoặc người phê duyệt kế tiếp
• Giao lại khi người duyệt vắng mặt
• Tự hết hạn các yêu cầu chờ sau cửa sổ xác định, kèm đường dẫn nộp lại rõ ràng

Ngoại lệ nhưng có kiểm soát

Bạn sẽ cần ngoại lệ, nhưng chúng phải có cấu trúc:

• Fast-track cho truy cập rủi ro thấp (vẫn được ghi nhật ký)
• Emergency access with time limits and mandatory post-approval review
• Manual overrides chỉ dành cho admin chỉ định, yêu cầu lý do và ghi chú kiểm toán

Xử lý ngoại lệ như các trạng thái quy trình chính thức, không phải các cuộc trò chuyện phụ trong chat. Đó là cách giữ tốc độ mà không mất trách nhiệm.

Giao diện và trải nghiệm người duyệt

Một ứng dụng đánh giá tập trung thành công hay thất bại dựa trên việc người duyệt có thể đưa quyết định tự tin nhanh chóng hay không. UI nên giảm việc tìm kiếm bối cảnh, giảm trao đổi qua lại, và làm cho “lựa chọn an toàn” trở nên rõ ràng.

Màn hình cốt lõi bạn cần

Biểu mẫu yêu cầu nên giống như một quy trình điền hàng mua: chọn tài nguyên, chọn mức truy cập, thêm lý do nghiệp vụ rõ ràng, chọn thời hạn (nếu áp dụng), và đính kèm liên kết hoặc tập tin hỗ trợ. Dùng hiển thị theo tiến trình—chỉ hiển thị trường nâng cao khi cần (ví dụ: truy cập khẩn cấp hoặc tạm thời).

Hộp thư người duyệt là nơi làm việc hàng ngày. Giữ cho nó dễ quét: người yêu cầu, tài nguyên, quyền, ngày hạn/SLA, và một nhãn rủi ro đơn giản. Bộ lọc hữu ích: “Rủi ro cao”, “Sắp đến hạn”, “Đội của tôi”, và “Đang chờ thông tin”.

Chi tiết yêu cầu là nơi đưa ra quyết định. Đặt điều khiển quyết định ở đầu, và bằng chứng ngay bên dưới.

Cài đặt admin nên cho phép admin quản lý biểu mẫu, luật định tuyến, mẫu và nhãn UI mà không cần redeploy.

Giúp quyết định dễ dàng với bối cảnh phù hợp

Người duyệt nên thấy:

• Quyền hiện có của người yêu cầu (họ đang có gì)
• Gợi ý quyền đồng nghiệp (ví dụ: “8 người trong Finance có vai trò này”) với tổng hợp bảo mật quyền riêng tư
• Thẻ rủi ro (dữ liệu nhạy cảm, truy cập production, chia sẻ bên ngoài, quyền nâng cao)
• Gợi ý chất lượng lý do (“Công việc gì? Bao lâu? Ticket nào?”)

Trình bày trong panel “Context” nhất quán để người duyệt biết nơi tìm kiếm.

Hành động của người duyệt (ngoài phê duyệt/từ chối)

Hỗ trợ các kết quả thực tế:

• Approve, Deny (kèm lý do bắt buộc)
• Ask for info (gửi câu hỏi lại người yêu cầu, tạm dừng SLA)
• Delegate (với rào cản: chỉ tới người được phép)
• Approve with changes (thay quyền, rút ngắn thời hạn, thêm điều kiện)

Cơ bản về tiếp cận và khả dụng

Dùng nhãn rõ ràng (tránh viết tắt nội bộ), các vùng nhấp to, điều hướng bằng bàn phím cho phân loại hộp thư và nút quyết định. Cung cấp trạng thái focus rõ, nhãn trạng thái tương phản cao, và bố cục an toàn cho di động để phê duyệt nhanh. Giữ xác nhận rõ ràng (“Bạn đang phê duyệt quyền Admin cho X”) và ngăn gửi trùng bằng trạng thái loading hiển thị.

Mô hình dữ liệu cho tài nguyên, quyền và yêu cầu

Mô hình dữ liệu rõ ràng giữ cho ứng dụng đánh giá truy cập dễ hiểu khi mở rộng. Nếu người duyệt không thể biết chính xác họ đang yêu cầu gì, vì sao và điều gì xảy ra tiếp theo, UI và bản ghi kiểm toán đều sẽ tệ.

Định nghĩa “tài nguyên” vs. “quyền”

Bắt đầu bằng cách tách đối tượng được bảo vệ khỏi quyền cụ thể có thể cấp:

• Resource: một ứng dụng, database, thư mục, tenant SaaS, hoặc môi trường (Prod/Dev).
• Entitlement: một group, role, permission set, grant database, hoặc mục ACL thư mục liên kết với resource.

Điều này cho phép mô hình các mẫu phổ biến như “một app, nhiều role” hoặc “một database, nhiều schema” mà không ép mọi thứ thành một khái niệm “role”.

Mô hình hóa yêu cầu và hành trình của nó

Ít nhất, bạn cần các quan hệ cốt lõi:

• User → tạo một Request cho một hoặc nhiều Request items
• Mỗi item tạo ra một hoặc nhiều Approvals (quản lý, chủ sở hữu, an ninh)
• Các item được phê duyệt tạo Fulfillment tasks (provisioning tự động hoặc ticket thủ công)

Giữ các approvals như các bản ghi độc lập, không phải là trường trên request. Điều đó giúp định tuyến, phê duyệt lại và thu thập chứng cứ dễ dàng hơn.

Truy cập có thời hạn: ngày hiệu lực có ý nghĩa

Lưu thời gian truy cập ở mức request-item:

• Start date, end date, và lý do
• Lịch sử gia hạn như log append-only (ai gia hạn, từ/đến, lý do)

Cấu trúc này hỗ trợ quyền tối thiểu và ngăn quyền “tạm” trở thành vĩnh viễn vô tình.

Lưu giữ và xuất mà không lộn xộn

Lập kế hoạch giữ dữ liệu theo loại bản ghi: requests và approvals thường cần giữ lâu; thông báo tạm thời thì không. Thêm các định danh thân thiện để xuất (số yêu cầu, key tài nguyên, key quyền) để kiểm toán viên có thể lọc và đối chiếu mà không cần truy vấn tùy chỉnh.

Tích hợp định danh và thư mục

Ứng dụng của bạn không thể đánh giá yêu cầu một cách đáng tin nếu nó không biết ai là ai, họ thuộc đâu trong tổ chức và họ đã có gì. Tích hợp định danh và thư mục trở thành nguồn tin cậy cho bối cảnh đó—và ngăn phê duyệt dựa trên bảng tính lỗi thời.

Chọn nguồn định danh chính

Bắt đầu bằng việc quyết định hệ thống nào quản lý thông tin:

• Xác thực (ai có thể đăng nhập): thường là nhà cung cấp SSO (Okta, Azure AD, Google Workspace) dùng SAML/OIDC.
• Trạng thái lực lượng lao động (ai nên tồn tại): thường là HR (Workday, BambooHR) cho ngày tuyển, chấm dứt, ngày kết thúc nhà thầu.
• Cấu trúc tổ chức và nhóm (ai báo cáo cho ai, membership hiện tại): thường là directory (Azure AD, AD, Google) hoặc kết hợp HR + directory.

Nhiều đội dùng mô hình hybrid: HR cho trạng thái tuyển dụng và phòng ban, directory cho mối quan hệ quản lý và membership nhóm.

Đồng bộ dữ liệu tổ chức bạn phụ thuộc

Tối thiểu, đồng bộ:

• Hồ sơ người dùng và định danh (email, employee ID)
• Quản lý và chuỗi báo cáo (dùng cho định tuyến)
• Phòng ban / cost center (cho chính sách phê duyệt)
• Trạng thái tuyển dụng (active, leave, terminated)
• Membership nhóm/entitlement hiện tại (để phát hiện trùng lặp và thực thi quyền tối thiểu)

Thiết kế sync dưới dạng lấy gia tăng (delta) khi có thể, và lưu timestamp “last verified” để người duyệt biết dữ liệu còn tươi hay cũ.

Lên kế hoạch cho các sự kiện vòng đời

Quy trình của bạn nên phản ứng tự động với thay đổi: nhân viên mới có thể cần gói truy cập cơ bản; chuyển bộ phận có thể kích hoạt xem lại các quyền hiện có; chấm dứt và hết hạn hợp đồng nhà thầu nên đưa vào hàng đợi revocation ngay lập tức và chặn yêu cầu mới.

Xử lý thất bại một cách rõ ràng

Ghi lại điều gì xảy ra khi dữ liệu lộn xộn: thông tin quản lý cũ (định tuyến đến người phê duyệt bộ phận), thiếu người dùng (cho phép liên kết định danh thủ công), định danh trùng (quy tắc hợp nhất và chặn an toàn), và gián đoạn thư mục (giảm chức năng mềm mại kèm hàng đợi retry). Các đường xử lý thất bại rõ ràng giữ cho phê duyệt có uy tín và có thể kiểm toán.

Thực thi, thực hiện và thu hồi

Phê duyệt chỉ là một nửa công việc. Ứng dụng của bạn cũng cần đường dẫn rõ ràng từ “Đã phê duyệt” đến “quyền thực sự được cấp”, cùng cách đáng tin để loại bỏ quyền sau này.

Chọn cách thực hiện

Hầu hết các đội dùng một (hoặc kết hợp) các mô hình:

• Tạo ticket trong Jira/ServiceNow và để đội admin thực hiện.
• Gọi API để cấp trực tiếp (ví dụ: thêm vào group, gán role, tạo entitlement).
• Gửi task cho admin trong app khi không thể tự động (kèm ngày hết hạn và chủ sở hữu).

Lựa chọn tốt nhất phụ thuộc vào hệ thống và mức chấp nhận rủi ro của bạn. Với truy cập tác động cao, thực thi qua ticket cùng bước kiểm tra thứ hai có thể là tính năng, không phải hạn chế.

Tách trạng thái phê duyệt khỏi thực thi

Thiết kế quy trình sao cho Approved ≠ Granted. Theo dõi thực thi như một state machine riêng, ví dụ:

• Requested → Approved/Rejected
• Approved → Fulfillment Queued → In Progress → Granted (or Failed)

Sự tách này ngăn tin tưởng sai lệch và cho các bên nhìn thấy thực tế đang chờ là gì.

Xác minh và chứng cứ

Sau khi thực thi, thêm bước xác minh: xác nhận quyền đã được áp dụng trong hệ thống đích. Lưu chứng cứ nhẹ như ID tham chiếu (số ticket), timestamp, và “xác minh bởi” user hoặc tiến trình tự động. Điều này biến quản trị truy cập thành thứ bạn có thể chứng minh, không chỉ là khẳng định.

Thu hồi và hết hạn

Xử lý thu hồi như một tính năng chính:

• Hỗ trợ ngày kết thúc khi tạo yêu cầu.
• Chạy tự động xóa khi ngày kết thúc trôi qua (qua API) hoặc đưa vào hàng đợi thu hồi nếu thủ công.
• Ghi kết quả thu hồi (Removed/Failed) giống như ghi grant.

Khi việc thu hồi dễ và hiển thị được, nguyên tắc quyền tối thiểu sẽ trở thành thực hành hàng ngày chứ không chỉ là khẩu hiệu.

Bản ghi kiểm toán và chứng cứ cho các cuộc rà soát

Một ứng dụng đánh giá truy cập tập trung chỉ có uy tín khi có chứng cứ. Các phê duyệt và từ chối cần có thể giải thích được sau vài tháng—không phụ thuộc vào trí nhớ hay ảnh chụp màn hình trong email.

Thiết kế nhật ký audit bất biến

Xử lý mọi hành động có ý nghĩa như một sự kiện và ghi vào nhật ký audit append-only. Ít nhất, ghi ai hành động, cái gì họ làm, khi nào, từ đâu, và vì sao.

Điều này thường bao gồm:

• Định danh người tác động (user ID, tên hiển thị, vai trò tại thời điểm đó)
• Loại hành động (submitted, approved, denied, reassigned, escalated, revoked)
• Timestamp (server-side) và định danh request/resource
• Chi tiết nguồn (địa chỉ IP, user agent, SSO session ID)
• Trường lý do (lý do quyết định và bình luận tự do)

Ghi lại bối cảnh quyết định (không chỉ quyết định)

Người kiểm toán thường hỏi, “Người duyệt có những thông tin gì khi họ phê duyệt?” Lưu bối cảnh quyết định cùng với sự kiện:

• Bình luận và lý do có cấu trúc (ví dụ “onboarding dự án”, “khẩn cấp”)
• Tệp đính kèm (ticket, ngoại lệ chính sách)
• Chính sách hoặc luật áp dụng (RBAC mapping, kết quả kiểm tra SoD)
• Ghi đè: ai ghi đè, phần nào bị vượt, và lý do

Giữ tệp đính kèm có phiên bản và liên kết với bước yêu cầu cụ thể để chúng không bị tách rời sau này.

Ngăn chặn giả mạo và làm rõ thay đổi admin

Lưu nhật ký audit ở dạng append-only trong lưu trữ (ví dụ: bảng write-once, object storage bất biến, hoặc dịch vụ logging riêng). Giới hạn khả năng admin chỉ được thêm sự kiện sửa chữa thay vì chỉnh sửa lịch sử.

Nếu thay đổi cấu hình ảnh hưởng đến phê duyệt (luật định tuyến, nhóm người duyệt, thời gian leo thang), cũng ghi những thay đổi đó với giá trị trước/sau rõ ràng. Lịch sử thay đổi này thường quan trọng ngang với quyết định truy cập.

Chế độ xem audit và xuất đáp ứng câu hỏi thực tế

Cung cấp màn hình và xuất thân thiện với kiểm toán với các bộ lọc thực tế: theo người dùng, tài nguyên, quyền, khoảng thời gian, trạng thái yêu cầu, và người phê duyệt. Xuất phải nhất quán và đầy đủ (CSV/PDF), xử lý múi giờ, và giữ định danh để có thể đối chiếu với hệ thống thư mục hoặc ticketing.

Mục tiêu: mỗi phê duyệt kể một câu chuyện hoàn chỉnh, nhanh, với chứng cứ đáng tin cậy.

Kiểm soát bảo mật và quyền riêng tư

Ứng dụng đánh giá truy cập tập trung nhanh chóng trở thành mục tiêu giá trị cao: nó chứa ai có quyền gì, lý do yêu cầu và ai phê duyệt. Bảo mật và quyền riêng tư không thể “bổ sung sau”—chúng định hình cách bạn thiết kế vai trò, màn hình và lưu trữ dữ liệu.

Nguyên tắc quyền tối thiểu trong ứng dụng

Bắt đầu bằng cách khóa tầm nhìn, chứ không chỉ hành động. Nhiều yêu cầu chứa bối cảnh nhạy cảm (tên khách hàng, mã sự cố, ghi chú HR).

Định nghĩa vai trò ứng dụng rõ ràng (ví dụ: requester, reviewer, resource owner, auditor, admin) và quy phạm những gì mỗi vai trò được thấy:

• Người duyệt chỉ thấy yêu cầu định tuyến cho họ, không phải toàn bộ hàng đợi.
• Chủ sở hữu tài nguyên thấy yêu cầu cho tài nguyên của họ, không phải tất cả.
• Auditor có thể cần quyền đọc quyết định và chứng cứ, nhưng không phải tất cả trường văn bản tự do nếu chứa dữ liệu cá nhân.

Xem quyền admin là đặc quyền: yêu cầu MFA, giới hạn nhóm nhỏ, và ghi lại mọi hành động đặc quyền.

Bảo vệ dữ liệu đầu-cuối

Mã hóa khi truyền (TLS) và khi lưu (database và backup). Lưu bí mật (mật khẩu DB, khóa signing, token webhook) trong secrets manager, không lưu trong file môi trường commit vào repo.

Cân nhắc kỹ về những gì lưu:

• Tránh lưu raw access tokens.
• Ẩn hoặc template hóa trường lý do khi có thể.
• Tách dữ liệu định danh khỏi ghi chú yêu cầu để giảm rủi ro lộ thông tin.

Các biện pháp phòng chống tấn công phổ biến

Thêm các kiểm soát cơ bản sớm:

• Giới hạn tần suất cho đăng nhập, tìm kiếm và endpoint API để giảm scraping và brute force.
• Bảo vệ CSRF cho phiên trình duyệt; dùng cookie SameSite và token anti-CSRF.
• Validate input chặt chẽ (server-side) cho ID, bình luận và bộ lọc.
• Kiểm soát tải lên tập tin: allowlist MIME types, quét upload, giới hạn kích thước, lưu trữ ngoài web root.

Tuân thủ cơ bản: giảm thiểu, lưu giữ và kiểm soát nhật ký

Đặt thời hạn lưu cho yêu cầu, bình luận và tệp đính kèm dựa trên chính sách (ví dụ: 1–7 năm cho chứng cứ kiểm toán, ngắn hơn cho ghi chú cá nhân). Giữ một nhật ký audit được kiểm soát truy cập với sự kiện bất biến (ai/cái/gì/khi), và giới hạn truy cập log cho auditor và security. Khi phân vân, lưu ít hơn—và ghi chép lý do vì sao bạn giữ những gì bạn giữ.