Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA của một dự án ngân hàng số. Một sáng đẹp trời, khách hàng gọi điện phàn nàn rằng tài liệu phân tích yêu cầu (BRD) chứa thông tin lương nhân sự nội bộ đã "lọt" ra ngoài cho một nhà thầu phụ — vốn chỉ được phép xem các yêu cầu chức năng. Khi rà soát lại, bạn phát hiện ra rằng nhà thầu này, do được thêm vào project với vai trò quá rộng, có thể đọc mọi issue và mọi trang Confluence trong space. Không ai cố tình làm sai. Vấn đề nằm ở chỗ: hệ thống phân quyền (permissions) bị cấu hình lỏng lẻo.
Đây chính xác là lý do bài học này tồn tại. Là một BA, bạn không chỉ viết yêu cầu — bạn còn là người "gác cổng" thông tin của dự án. Bạn quyết định ai được nhìn thấy backlog, ai được sửa story, ai được phê duyệt tài liệu, ai chỉ được đọc. Trong JIRA và Confluence, phân quyền không phải là việc của riêng admin hệ thống. BA thường là người hiểu rõ nhất "ai cần biết gì", nên bạn phải nắm vững mô hình phân quyền để đề xuất cấu hình đúng, tránh hai thái cực nguy hiểm: quá đóng (mọi người bị chặn, công việc tắc nghẽn) hoặc quá mở (rò rỉ thông tin nhạy cảm).
Bài này sẽ giúp bạn hiểu rõ ba tầng phân quyền trong JIRA, cách Confluence quản lý quyền theo space và page, và quan trọng nhất là tư duy thiết kế phân quyền sao cho an toàn mà vẫn không cản trở công việc.
Khái niệm cốt lõi
Ba tầng phân quyền trong JIRA
JIRA tổ chức phân quyền theo ba tầng từ rộng đến hẹp. Hiểu được ranh giới giữa chúng là chìa khóa.
1. Global Permissions (Quyền toàn hệ thống)
Đây là tầng cao nhất, áp dụng cho toàn bộ instance JIRA chứ không riêng một project nào. Những quyền tiêu biểu:
- JIRA Administrators — quản trị cấu hình: tạo project, sửa workflow, scheme, custom field.
- JIRA System Administrators — quyền cao nhất, chạm được vào cấu hình hệ thống, tích hợp, sao lưu, application links.
- Browse Users and Groups — được phép tìm và xem danh sách user (quan trọng khi gán issue cho người khác).
- Create Shared Objects — tạo filter và dashboard chia sẻ cho người khác.
- Bulk Change — thực hiện thao tác hàng loạt trên nhiều issue.
2. Project Permissions (Quyền theo project)
Đây là tầng quan trọng nhất với công việc hằng ngày của BA. Mỗi project được gắn với một Permission Scheme — một bộ quy tắc định nghĩa "ai được làm gì trong project này". Một permission scheme có thể được dùng lại cho nhiều project.
Trong permission scheme, mỗi loại quyền (ví dụ: Browse Projects, Create Issues, Edit Issues, Assign Issues, Transition Issues, Resolve Issues, Delete Issues, Manage Sprints) được gán cho một hoặc nhiều "đối tượng". Đối tượng ở đây không nhất thiết là một người cụ thể, mà thường là:
- Project Role (ví dụ: Developers, Administrators, BA, QA) — cách linh hoạt nhất.
- Group (nhóm user toàn hệ thống, ví dụ:
jira-software-users). - Reporter / Current Assignee / Project Lead — gán động theo vai trò trong từng issue.
- User custom field value — ví dụ trao quyền cho người được điền trong field "Business Owner".
3. Issue Security (Bảo mật cấp issue)
Đây là tầng tinh vi nhất, cho phép giấu một số issue cụ thể ngay cả với những người có quyền Browse Project. Bạn tạo một Issue Security Scheme gồm nhiều security level (ví dụ: "Nội bộ", "Mật", "Chỉ Ban lãnh đạo"). Mỗi issue có thể được gán một security level, và chỉ những đối tượng nằm trong level đó mới nhìn thấy issue.
Issue Security cực kỳ hữu ích cho BA khi xử lý các issue nhạy cảm: lỗ hổng bảo mật, vấn đề nhân sự, hay yêu cầu liên quan đến hợp đồng giá trị lớn mà chỉ một nhóm nhỏ được biết.
Phân quyền trong Confluence
Confluence dùng mô hình hai tầng đơn giản hơn nhưng cũng đầy sức mạnh:
1. Space Permissions (Quyền theo space) — Mỗi space có bảng phân quyền riêng. Bạn cấp cho từng user hoặc group các quyền: View (xem), Add/Delete Pages, Add/Delete Comments, Add/Delete Attachments, Export, và Space Admin. Nguyên tắc nền tảng: muốn xem bất kỳ trang nào trong space, trước hết user phải có quyền View trên space đó.
2. Page Restrictions (Hạn chế cấp trang) — Trong một space mà mọi người đều xem được, bạn vẫn có thể "khóa" một trang cụ thể. Có hai kiểu: Viewing restriction (chỉ một số người được xem) và Editing restriction (mọi người xem được nhưng chỉ một số được sửa). Lưu ý quan trọng: restriction có tính kế thừa — nếu bạn hạn chế xem một trang cha, thì các trang con cũng bị ảnh hưởng tương ứng.
Một điểm khác biệt cốt lõi cần khắc cốt ghi tâm: trong Confluence, permission luôn được cộng dồn nhưng restriction luôn thắng. Nghĩa là dù bạn có quyền View ở cấp space, nếu một trang có viewing restriction không chứa tên bạn, bạn vẫn không xem được trang đó.
Nguyên tắc đặc quyền tối thiểu (Least Privilege)
Toàn bộ tư duy phân quyền nên xoay quanh nguyên tắc này: chỉ cấp đúng những quyền tối thiểu mà một người cần để hoàn thành công việc, không hơn. Mặc định nên là "đóng", rồi mở ra theo nhu cầu thực tế, chứ không phải mở toang rồi mới đi bịt lỗ hổng.
Tình huống thực tế
Tình huống 1 — Nhà thầu phụ tại một fintech ở TP.HCM
Công ty MoMo-style fintech "PayViet" thuê một nhà thầu phụ gồm 4 lập trình viên để làm module thanh toán hóa đơn điện nước. Ban đầu, để cho nhanh, admin thêm cả 4 người vào group jira-software-users và cho họ vào project với role Developers — cùng role với nhân viên nội bộ.
Hậu quả: nhà thầu nhìn thấy mọi epic, kể cả những epic liên quan đến chiến lược tích hợp ví với một ngân hàng đối tác (thông tin còn đang đàm phán, chưa công bố). Một thành viên nhà thầu vô tình chụp màn hình backlog gửi vào nhóm chat chung, làm lộ kế hoạch.
Bài học và cách xử lý: BA của PayViet đề xuất tạo một project role riêng tên "External Contractors" với permission scheme giới hạn — chỉ được Browse, Create, Edit Issues trên những issue thuộc component "Bill Payment". Các epic chiến lược được gán Issue Security level "Internal Only" chỉ chứa role nội bộ. Sau thay đổi, nhà thầu vẫn làm việc bình thường nhưng không còn thấy được gì ngoài phạm vi của họ. Bài học: đừng bao giờ dùng chung role giữa nội bộ và bên ngoài chỉ vì tiện.
Tình huống 2 — BRD lương thưởng tại một công ty bảo hiểm
Tại "Bảo An Life", phòng BA viết một BRD cho hệ thống tính hoa hồng đại lý trong Confluence. Tài liệu này nằm trong space "Sales System" mà cả phòng Kinh doanh (khoảng 60 người) đều có quyền View để theo dõi tiến độ. Vấn đề: BRD có một mục chi tiết về công thức tính hoa hồng theo từng cấp bậc — thông tin cực kỳ nhạy cảm, chỉ Ban giám đốc và Trưởng phòng Kinh doanh được biết.
Cách xử lý: BA tách phần công thức nhạy cảm thành một trang con riêng và áp Viewing restriction chỉ cho group ban-giam-doc và 2 cá nhân là Trưởng phòng. Trang cha (mô tả tổng quan, mục tiêu, scope) vẫn để cả space xem được. Nhờ vậy, 60 người vẫn nắm được bối cảnh dự án, còn phần "mật" thì được khóa chặt.
Bài học: Đừng để cả tài liệu mở hoặc cả tài liệu đóng. Hãy thiết kế cấu trúc trang sao cho mức độ nhạy cảm khác nhau nằm ở các trang khác nhau, rồi áp restriction đúng chỗ. Đây là kỹ năng kiến trúc thông tin mà BA giỏi luôn vận dụng.
Tình huống 3 — "Vô tình" khóa cả team khỏi backlog
Một startup logistics ở Hà Nội, "GiaoNhanh", có một BA mới nhiệt tình muốn "bảo mật". Anh áp Editing restriction lên trang Confluence chứa toàn bộ user story master list, chỉ để mình anh sửa được. Một tuần sau, cả team Dev và QA than phiền không thể cập nhật trạng thái hay thêm ghi chú vào story. Tệ hơn, khi anh đi nghỉ phép, không ai có quyền Space Admin để gỡ restriction — vì anh cũng vô tình thu hẹp luôn quyền admin space.
Cách xử lý: Quản trị phải nhờ Confluence System Admin can thiệp ở cấp instance để khôi phục quyền. Sau đó, công ty đặt ra quy tắc: mọi space phải có ít nhất hai người giữ quyền Space Admin, và restriction chỉ áp cho trang thực sự nhạy cảm, không áp bừa lên trang làm việc chung.
Bài học: Phân quyền quá chặt cũng nguy hiểm như quá lỏng. Luôn có dự phòng (ít nhất hai admin) và đừng nhầm lẫn giữa "bảo mật" với "tự cô lập công việc của team".
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn cấu hình và kiểm tra phân quyền.
Bước 1 — Cấu hình Project Role trong JIRA. Vào Project Settings → People (hoặc Users and roles). Tạo hoặc dùng các role có sẵn (Administrators, Developers, BA, QA, Stakeholders). Thêm đúng người vào đúng role. Nhớ: hãy nghĩ theo vai trò, không theo cá nhân.
Bước 2 — Rà soát Permission Scheme. Vào Project Settings → Permissions. Xem từng quyền (Browse, Create, Edit, Transition, Delete...) đang gán cho đối tượng nào. Nếu phát hiện một quyền nhạy cảm (như Delete Issues hay Manage Sprints) đang gán cho "Any logged-in user", hãy thu hẹp lại về role cụ thể.
Bước 3 — Thiết lập Issue Security nếu cần. Vào Settings → Issues → Issue security schemes, tạo scheme với các level (ví dụ "Internal Only"). Gán scheme cho project, rồi trên từng issue nhạy cảm, đặt trường Security Level tương ứng. Kiểm tra bằng cách đăng nhập bằng một tài khoản không thuộc level đó để xác nhận issue đã bị ẩn.
Bước 4 — Cấu hình Space Permissions trong Confluence. Vào Space Settings → Permissions. Cấp quyền View cho các group cần thiết, và chỉ trao Space Admin cho ít nhất hai người đáng tin cậy. Loại bỏ những quyền thừa cho group "confluence-users" mặc định nếu space cần kín.
Bước 5 — Áp Page Restriction khi cần. Mở trang cần bảo vệ, nhấn biểu tượng ổ khóa (Restrictions). Chọn "Viewing and editing restricted" hoặc "Editing restricted", thêm đúng người/group. Kiểm tra phần "inherited restrictions" để hiểu trang đang chịu ràng buộc gì từ trang cha.
Bước 6 — Kiểm thử bằng tài khoản khác (impersonation hoặc tài khoản test). Đây là bước nhiều người bỏ qua nhưng quan trọng nhất. Luôn xác minh "góc nhìn" của một người dùng bình thường, đừng tin vào lý thuyết. Atlassian có công cụ Permission Helper trong JIRA admin giúp bạn kiểm tra một user cụ thể có/không có một quyền nào đó và lý do tại sao.
Lỗi thường gặp & mẹo
Lỗi 1 — Gán quyền cho cá nhân thay vì role/group. Khi người đó nghỉ việc hoặc đổi vai trò, không ai nhớ gỡ. Mẹo: luôn gán qua Project Role (JIRA) hoặc Group (Confluence).
Lỗi 2 — Để "Any logged-in user" hoặc "confluence-users" có quyền rộng. Đây là nguyên nhân rò rỉ phổ biến nhất. Mẹo: định kỳ rà soát các quyền gán cho nhóm mặc định.
Lỗi 3 — Quên rằng restriction kế thừa xuống trang con trong Confluence. Hạn chế xem trang cha có thể vô tình giấu cả nhánh trang con. Mẹo: luôn kiểm tra cây trang sau khi áp restriction.
Lỗi 4 — Nhầm lẫn permission cấp space với restriction cấp page. Nhớ công thức: muốn xem trang cần View ở space, nhưng restriction ở page có thể chặn lại dù bạn có View. Restriction luôn thắng.
Lỗi 5 — Chỉ có một Space Admin hoặc một JIRA System Admin. Khi người đó vắng mặt, cả tổ chức kẹt. Mẹo: luôn có tối thiểu hai người ở mỗi vai trò quản trị quan trọng.
Mẹo vàng: Dùng Permission Helper (JIRA) và tính năng "Restrictions" inspector (Confluence) trước khi go-live mọi cấu hình quan trọng. Và hãy ghi lại "ma trận phân quyền" (ai — vai trò — quyền gì) thành một bảng trong Confluence để cả team minh bạch và dễ audit về sau.
Bài tập thực hành
- Thiết kế ma trận phân quyền. Cho một project JIRA gồm 4 nhóm: BA nội bộ, Dev nội bộ, QA, và nhà thầu phụ. Hãy lập bảng quy định mỗi nhóm được/không được các quyền: Browse, Create, Edit, Transition, Delete Issues, Manage Sprints. Giải thích lý do cho từng ô.
- Cấu hình Issue Security. Trong một project thử nghiệm, tạo một Issue Security Scheme có level "Confidential" chỉ chứa role BA và Project Lead. Gán level này cho 2 issue, rồi đăng nhập bằng tài khoản test (role Developers) để xác nhận 2 issue đó bị ẩn. Ghi lại kết quả.
- Tách BRD theo độ nhạy cảm trong Confluence. Lấy một BRD mẫu, tách phần thông tin nhạy cảm (giả định: bảng giá hợp đồng) sang một trang con và áp Viewing restriction chỉ cho 2 người. Sau đó kiểm thử bằng một tài khoản thứ ba để xác nhận họ thấy trang cha nhưng không thấy trang con.
- Audit phân quyền. Chọn một space Confluence thật trong tổ chức của bạn (hoặc giả lập), liệt kê tất cả group/user có quyền và đánh dấu những quyền bạn cho là thừa theo nguyên tắc least privilege. Đề xuất phương án thu hẹp.
Tóm tắt
Phân quyền là kỹ năng nền tảng mà mọi BA chuyên nghiệp phải nắm vững, vì bạn là người hiểu rõ nhất "ai cần biết gì" trong dự án. Trong JIRA, hãy nhớ ba tầng: Global Permissions (toàn hệ thống), Project Permissions thông qua Permission Scheme và Project Role (tầng quan trọng nhất hằng ngày), và Issue Security để giấu những issue nhạy cảm. Trong Confluence, có hai tầng: Space Permissions và Page Restrictions, với quy luật cốt lõi là permission cộng dồn nhưng restriction luôn thắng.
Tư duy xuyên suốt là nguyên tắc đặc quyền tối thiểu: mặc định đóng, mở ra theo nhu cầu thực. Luôn gán quyền qua role/group thay vì cá nhân, luôn có dự phòng ít nhất hai admin, và luôn kiểm thử bằng tài khoản khác trước khi go-live. Ba tình huống thực tế ở trên cho thấy cả hai thái cực — quá mở gây rò rỉ, quá đóng làm tắc nghẽn — đều phải trả giá. Người BA giỏi là người tìm được điểm cân bằng: an toàn cho thông tin nhạy cảm, nhưng vẫn thông suốt cho công việc chung của team.