Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là BA cho một ngân hàng số tại Việt Nam. Đội phát triển vừa ra mắt tính năng chuyển tiền mới, mọi thứ chạy mượt trong demo. Ba tuần sau, một khách hàng phát hiện họ có thể xem được lịch sử giao dịch của người khác chỉ bằng cách đổi một con số trên URL. Sự cố lên báo, Ngân hàng Nhà nước vào cuộc, và câu hỏi đầu tiên trong cuộc họp khẩn là: "Yêu cầu bảo mật cho tính năng này nằm ở đâu trong tài liệu?". Im lặng. Vì không ai viết nó cả.
Đây không phải kịch bản hù dọa. Đây là thực tế lặp đi lặp lại ở rất nhiều dự án. Security thường bị coi là "việc của đội security" hoặc "việc của dev", và BA lặng lẽ bỏ qua. Nhưng sự thật là: nếu một yêu cầu bảo mật không được viết ra như một requirement chính thức — có tiêu chí chấp nhận rõ ràng, được test, được trace — thì nó gần như chắc chắn sẽ rơi rụng đâu đó giữa thiết kế và triển khai.
Với BA, ba trụ cột bạn bắt buộc phải nắm và phải biết cách diễn đạt thành requirement là: Authentication (xác thực — bạn là ai?), Authorization (phân quyền — bạn được phép làm gì?), và Encryption (mã hóa — dữ liệu được bảo vệ thế nào?). Bài này dạy bạn cách hiểu đúng ba khái niệm đó và biến chúng thành các yêu cầu mà developer có thể xây và tester có thể kiểm chứng.
Khái niệm cốt lõi
Authentication (AuthN) — "Bạn là ai?"
Authentication là quá trình hệ thống xác minh danh tính của người dùng. Khi bạn gõ username/password và hệ thống xác nhận "đúng là bạn", đó là authentication. Có ba nhóm yếu tố xác thực (authentication factors):
- Something you know — điều bạn biết: mật khẩu, mã PIN, câu hỏi bí mật.
- Something you have — vật bạn sở hữu: điện thoại nhận OTP, thẻ thông minh, token cứng, ứng dụng Authenticator.
- Something you are — đặc điểm sinh trắc của bạn: vân tay, khuôn mặt (Face ID), giọng nói.
Là BA, bạn cần biết các cơ chế authentication phổ biến để mô tả requirement chính xác:
- Password-based: cơ bản nhất, đi kèm chính sách mật khẩu (độ dài, độ phức tạp, thời hạn).
- OTP (One-Time Password): mã dùng một lần qua SMS, email hoặc app. Tại Việt Nam, Smart OTP đang dần thay thế SMS OTP vì an toàn hơn.
- Biometric: vân tay, khuôn mặt — rất phổ biến trên mobile banking.
- SSO (Single Sign-On) và OAuth 2.0 / OpenID Connect: đăng nhập một lần dùng cho nhiều hệ thống, hoặc "Đăng nhập bằng Google".
Authorization (AuthZ) — "Bạn được phép làm gì?"
Sau khi biết bạn là ai, hệ thống phải quyết định bạn được làm gì. Đó là authorization. Một nhân viên giao dịch và một giám đốc chi nhánh đều đăng nhập thành công (cùng pass authentication), nhưng giám đốc được duyệt khoản vay 5 tỷ còn nhân viên thì không — đó là sự khác biệt do authorization.
Hai mô hình phân quyền BA cần biết:
- RBAC (Role-Based Access Control) — phân quyền theo vai trò. Bạn gán quyền cho các role (Admin, Manager, Teller, Customer), rồi gán role cho người dùng. Đây là mô hình phổ biến nhất và dễ mô tả nhất trong requirement.
- ABAC (Attribute-Based Access Control) — phân quyền theo thuộc tính. Quyết định dựa trên nhiều thuộc tính: ai (role, phòng ban), cái gì (loại dữ liệu), bối cảnh (thời gian, địa điểm, thiết bị). Ví dụ: "Chỉ cho phép duyệt giao dịch trên 1 tỷ trong giờ hành chính và từ địa chỉ IP nội bộ". ABAC linh hoạt hơn nhưng phức tạp hơn.
- Least Privilege (đặc quyền tối thiểu): mỗi người chỉ được cấp đúng quyền cần thiết để làm việc, không hơn.
- Segregation of Duties (phân tách trách nhiệm): người tạo giao dịch không được là người duyệt giao dịch. Đây là yêu cầu bắt buộc trong tài chính ngân hàng để chống gian lận.
Encryption — "Dữ liệu được bảo vệ thế nào?"
Encryption (mã hóa) biến dữ liệu đọc được thành dữ liệu vô nghĩa với người không có khóa. Có hai trạng thái dữ liệu cần được bảo vệ:
- Encryption in transit — mã hóa khi truyền: dữ liệu di chuyển giữa client và server phải được mã hóa qua TLS/HTTPS. Không bao giờ truyền mật khẩu hay thông tin thẻ qua HTTP thường.
- Encryption at rest — mã hóa khi lưu trữ: dữ liệu nằm trong database, file, backup phải được mã hóa để nếu ổ cứng bị đánh cắp, kẻ tấn công vẫn không đọc được.
Tại Việt Nam, các yêu cầu này còn gắn với pháp lý: Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân yêu cầu áp dụng biện pháp bảo vệ dữ liệu cá nhân; ngành thẻ phải tuân thủ PCI-DSS; ngân hàng phải theo các thông tư của Ngân hàng Nhà nước về an toàn hệ thống thông tin.
Tình huống thực tế
Tình huống 1 — Lỗ hổng IDOR tại một ví điện tử
Một công ty ví điện tử giả định, gọi là PayViet, ra mắt tính năng "Xem chi tiết hóa đơn". API có dạng GET /api/invoices/10523. Tester chức năng kiểm tra: đăng nhập, bấm xem hóa đơn của mình, hiển thị đúng — pass. Nhưng không ai test việc đổi số 10523 thành 10522. Một người dùng tò mò làm điều đó và thấy hóa đơn của người khác, gồm tên, số tiền, số điện thoại.
Đây là lỗ hổng kinh điển tên IDOR (Insecure Direct Object Reference) — hệ thống làm authentication (biết bạn đã đăng nhập) nhưng quên authorization (không kiểm tra hóa đơn này có thuộc về bạn không).
Bài học cho BA: vấn đề gốc rễ là BA chỉ viết requirement chức năng "Người dùng xem được hóa đơn của mình" mà không viết requirement bảo mật "Hệ thống PHẢI từ chối (HTTP 403) khi người dùng cố truy cập hóa đơn không thuộc về họ". Một dòng acceptance criteria về authorization đã có thể chặn sự cố này từ giai đoạn test. Authentication và authorization là hai việc khác nhau — pass cái này không có nghĩa pass cái kia.
Tình huống 2 — MFA cứu một ngân hàng số khỏi chiến dịch lừa đảo
Một ngân hàng số (lấy cảm hứng từ các neobank tại Đông Nam Á) ban đầu chỉ dùng username + password cho đăng nhập web. Một chiến dịch phishing gửi email giả mạo, lừa được khoảng 800 khách hàng nhập mật khẩu vào trang giả. Kẻ tấn công có mật khẩu thật, nhưng khi đăng nhập, hệ thống yêu cầu OTP qua Smart OTP trên app — yếu tố "something you have" mà kẻ tấn công không có. Kết quả: 0 đồng bị mất dù 800 mật khẩu bị lộ.
Bài học cho BA: requirement ban đầu nếu chỉ là "người dùng đăng nhập bằng mật khẩu" thì hệ thống đã thất thủ. Chính việc BA viết requirement "Mọi giao dịch tài chính và đăng nhập từ thiết bị mới PHẢI yêu cầu MFA (mật khẩu + OTP)" đã tạo lớp phòng thủ thứ hai. Khi viết requirement bảo mật, hãy luôn hỏi: "Nếu lớp thứ nhất bị phá thì sao?". Bảo mật theo chiều sâu (defense in depth) bắt đầu từ chính các requirement bạn viết.
Tình huống 3 — Mất laptop và bài toán encryption at rest
Một fintech BNPL giả định, FinNow, lưu thông tin định danh khách hàng (CMND/CCCD, ngày sinh) trong một database phân tích. Một nhân viên để quên laptop chứa bản backup database trên taxi. May mắn thay, backup đã được mã hóa at rest bằng AES-256, và khóa giải mã được quản lý riêng trong hệ thống quản lý khóa (KMS), không nằm cùng laptop. Dữ liệu bị mất về mặt vật lý nhưng vô dụng với người nhặt được.
Bài học cho BA: rất nhiều người chỉ nghĩ đến encryption in transit (HTTPS) mà quên encryption at rest. Câu hỏi BA phải đặt ra trong elicitation là: "Dữ liệu nhạy cảm được lưu ở đâu, ai có thể chạm vào ổ cứng/backup đó, và nếu nó bị đánh cắp vật lý thì sao?". Nếu đáp án khiến bạn rùng mình, bạn cần một requirement encryption at rest. Đặc biệt với dữ liệu cá nhân theo Nghị định 13, đây gần như là bắt buộc.
Hướng dẫn từng bước
Đây là quy trình thực dụng để BA khai thác và viết security requirements cho một tính năng.
Bước 1 — Phân loại dữ liệu (Data Classification). Trước tiên, xác định tính năng động chạm tới loại dữ liệu nào: công khai, nội bộ, hay nhạy cảm (PII, dữ liệu tài chính, thông tin sức khỏe). Mức độ bảo mật tỷ lệ thuận với độ nhạy cảm. Một trang giới thiệu sản phẩm không cần MFA; một màn hình chuyển tiền thì có.
Bước 2 — Xác định yêu cầu Authentication. Hỏi: Ai được phép truy cập? Cần xác thực mức nào? Có cần MFA không? Viết rõ chính sách mật khẩu, cơ chế OTP/biometric, xử lý phiên (session timeout sau bao lâu), khóa tài khoản sau bao nhiêu lần sai.
Bước 3 — Xác định yêu cầu Authorization. Lập ma trận quyền (permission matrix): liệt kê các role ở cột, các hành động ở hàng, đánh dấu role nào được làm gì. Ma trận này là tài liệu vàng cho cả dev và tester. Đừng quên áp dụng least privilege và kiểm tra segregation of duties.
Bước 4 — Xác định yêu cầu Encryption. Với mỗi luồng dữ liệu nhạy cảm, ghi rõ: in transit dùng gì (TLS 1.2+ / HTTPS), at rest dùng gì (AES-256), mật khẩu được hash thế nào (bcrypt/Argon2). Nêu rõ khóa được quản lý ở đâu.
Bước 5 — Viết thành requirement có thể kiểm chứng. Mỗi yêu cầu bảo mật phải có acceptance criteria đo lường được. So sánh:
- Mơ hồ (sai): "Hệ thống phải an toàn."
- Tốt: "Hệ thống PHẢI khóa tài khoản trong 30 phút sau 5 lần nhập sai mật khẩu liên tiếp, và gửi email cảnh báo cho chủ tài khoản."
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm authentication với authorization. Đây là lỗi phổ biến nhất. Nhớ câu thần chú: AuthN = "ai", AuthZ = "được làm gì". Đăng nhập thành công không có nghĩa được phép làm mọi thứ.
Lỗi 2 — Viết "hệ thống phải bảo mật" rồi xong. Đây không phải requirement, đó là mong ước. Mọi yêu cầu bảo mật phải cụ thể, đo được, test được.
Lỗi 3 — Quên non-functional và edge case bảo mật. Điều gì xảy ra khi nhập sai mật khẩu 100 lần? Khi token hết hạn giữa giao dịch? Khi hai người cùng đăng nhập một tài khoản? Các luồng "âm bản" (negative path) thường là nơi lỗ hổng ẩn náu.
Lỗi 4 — Nói "mã hóa mật khẩu trong DB". Mật khẩu phải được hash (một chiều), không phải encrypt (hai chiều). Dùng sai thuật ngữ khiến dev hiểu sai và làm sai.
Lỗi 5 — Bỏ quên encryption at rest. Nhiều người dừng ở HTTPS. Hãy luôn hỏi về dữ liệu lúc nằm yên trong DB và backup.
Mẹo 1 — Tận dụng OWASP Top 10. Đây là danh sách 10 rủi ro bảo mật web phổ biến nhất. BA không cần khắc phục chúng, nhưng dùng nó như một checklist để đặt câu hỏi elicitation rất hiệu quả.
Mẹo 2 — Dùng từ khóa "PHẢI" (SHALL/MUST) cho requirement bảo mật. Yêu cầu bảo mật là bắt buộc, không phải tùy chọn. Ngôn ngữ phải dứt khoát.
Mẹo 3 — Đừng tự thiết kế thuật toán bảo mật. Vai trò BA là nêu cái gì cần bảo vệ và đến mức nào, không phải chọn thuật toán cụ thể trong tranh cãi với security. Hãy tham chiếu chuẩn (PCI-DSS, Nghị định 13) thay vì tự chế.
Bài tập thực hành
Bài 1 — Phân biệt AuthN/AuthZ. Cho 5 phát biểu sau, gắn nhãn mỗi cái là Authentication hay Authorization: (a) Người dùng quét vân tay để mở app; (b) Nhân viên thường không thể vào trang quản trị; (c) Hệ thống gửi OTP khi đăng nhập thiết bị mới; (d) Chỉ giám đốc duyệt được khoản vay trên 2 tỷ; (e) Khách nhập mật khẩu để vào tài khoản.
Bài 2 — Lập ma trận phân quyền. Cho một hệ thống quản lý đơn hàng với 3 role: Khách hàng, Nhân viên kho, Quản lý. Các hành động: Tạo đơn, Xem đơn của mình, Xem mọi đơn, Cập nhật trạng thái giao hàng, Hủy đơn, Hoàn tiền. Hãy lập permission matrix và áp dụng nguyên tắc least privilege.
Bài 3 — Viết lại requirement. Chuyển requirement mơ hồ sau thành requirement có thể kiểm chứng, kèm ít nhất 2 acceptance criteria: "Tính năng đăng nhập phải bảo mật và bảo vệ tài khoản người dùng."
Bài 4 — Tình huống encryption. Một app y tế giả định lưu hồ sơ bệnh án và cho phép bệnh nhân xem kết quả xét nghiệm online. Hãy liệt kê các yêu cầu encryption cần có (in transit, at rest, hashing mật khẩu) và giải thích vì sao mỗi cái cần thiết, có tham chiếu Nghị định 13.
Tóm tắt
Security không phải "việc của người khác" — nó là một phần requirement mà BA bắt buộc phải viết ra, nếu không nó sẽ bị bỏ sót. Ba trụ cột cần nhớ: Authentication trả lời "bạn là ai" (password, OTP, biometric, MFA); Authorization trả lời "bạn được làm gì" (RBAC, ABAC, least privilege, segregation of duties); Encryption bảo vệ dữ liệu cả khi truyền (TLS/HTTPS), khi lưu (AES-256 at rest) và đặc biệt là hashing cho mật khẩu.
Nguyên tắc cốt lõi của bài: một yêu cầu bảo mật chỉ thực sự tồn tại khi nó được viết ra cụ thể, đo được, test được và trace được. "Hệ thống phải an toàn" là vô nghĩa; "Khóa tài khoản sau 5 lần sai trong 30 phút" mới là requirement. Hãy luôn hỏi về negative path, về dữ liệu lúc nằm yên, và về điều gì xảy ra khi lớp phòng thủ thứ nhất bị phá. Trong bối cảnh Việt Nam, đừng quên gắn yêu cầu của bạn với Nghị định 13/2023, PCI-DSS và quy định của Ngân hàng Nhà nước. Làm tốt việc này, bạn không chỉ là BA viết tài liệu — bạn là người bảo vệ khách hàng và doanh nghiệp khỏi những sự cố có thể lên báo.