Bảo Mật Trong Business Analysis – OWASP Top 10 & Checklist Security Requirements

Vấn đề Bảo Mật Trong Business Analysis này, theo báo cáo của IBM Cost of a Data Breach 2024, trung bình một vụ rò rỉ dữ liệu gây thiệt hại 4,88 triệu USD — và hơn 40% nguyên nhân bắt nguồn từ lỗi thiết kế hoặc logic nghiệp vụ, không phải từ code.

BA là cầu nối giữa business và kỹ thuật. Mọi yêu cầu BA viết ra đều trở thành đặc tả cho developer xây dựng hệ thống. Nếu BA không nhìn thấy rủi ro bảo mật ngay trong bản yêu cầu — developer cũng sẽ không xây phòng thủ vào đó.

“A secure system begins with a secure requirement — not a secure codebase.” Hệ thống an toàn bắt đầu từ yêu cầu an toàn, không phải từ code an toàn.

BA không cần biết cách tấn công. Nhưng BA cần biết:

• Lỗ hổng nào thường xuất phát từ thiết kế sai
• Câu hỏi nào cần hỏi để phát hiện rủi ro sớm
• Làm thế nào để viết security requirements đúng chuẩn

>>> Tìm hiểu thêm về: Khóa học IT Business Analyst tại Cole.vn dành cho người mới

OWASP Top 10 Dưới Góc Nhìn Business Analyst

OWASP (Open Web Application Security Project) là tổ chức phi lợi nhuận công bố danh sách 10 lỗ hổng bảo mật web phổ biến và nguy hiểm nhất — được cộng đồng bảo mật toàn cầu sử dụng như chuẩn mực chung.

Bảng tóm tắt nhanh OWASP Top 10 (2021) theo góc nhìn BA:

Phần dưới đây đi sâu vào các lỗ hổng mà BA trực tiếp tác động thông qua thiết kế yêu cầu.

Chi Tiết Các Lỗ Hổng Quan Trọng — BA Cần Làm Gì?

1. Broken Access Control (BAC) — Lỗi Phân Quyền

Đây là lỗ hổng #1 trong OWASP Top 10 và cũng là lỗi mà BA chịu trách nhiệm nhiều nhất.

BAC xảy ra khi hệ thống không kiểm tra quyền hạn đúng cách — cho phép người dùng truy cập tài nguyên vượt quá thẩm quyền.

Ví dụ thực tế trong dự án:

• User thay đổi ID trên URL từ thành → xem được đơn hàng người khác (IDOR)
• Nhân viên thường truy cập được trang chỉ bằng cách gõ thẳng URL
• API trả về toàn bộ dữ liệu khách hàng dù frontend chỉ hiển thị một phần

BA cần làm gì?

• Xây dựng ma trận phân quyền (Permission Matrix) đầy đủ: Ai được làm gì với dữ liệu nào?
• Với mỗi tính năng, hỏi rõ: “Nếu user A cố tình truy cập tài nguyên của user B, hệ thống phản ứng như thế nào?”
• Đặc tả rõ: phân quyền phải được kiểm tra ở server-side, không tin vào thông tin từ client

Câu hỏi BA nên hỏi trong buổi thiết kế:

“Có trường hợp nào một user có thể xem hoặc thay đổi dữ liệu của user khác không? Điều kiện để điều đó được phép là gì?”

2. SQL Injection — Khi Ô Nhập Liệu Trở Thành Vũ Khí

SQL Injection là kỹ thuật tấn công chèn mã SQL độc hại vào trường nhập liệu để thao túng cơ sở dữ liệu — có thể xóa toàn bộ dữ liệu hoặc lấy cắp thông tin nhạy cảm.

Ví dụ thực tế: Ô tìm kiếm sản phẩm nhận input: → Hệ thống trả về toàn bộ database thay vì kết quả tìm kiếm.

BA cần làm gì?

• Liệt kê tất cả các trường nhập liệu trong hệ thống (search, form, filter, API parameter)
• Đặc tả validation rules cụ thể: chỉ chấp nhận ký tự nào, độ dài tối đa bao nhiêu
• Yêu cầu dùng Parameterized Queries — ghi rõ trong technical requirement
• Yêu cầu không hiển thị lỗi hệ thống cho người dùng cuối (ẩn error message chi tiết)

3. Cross-Site Scripting (XSS) — Đánh Cắp Phiên Làm Việc

XSS xảy ra khi kẻ tấn công chèn JavaScript độc hại vào trang web. Khi người dùng khác truy cập, mã này thực thi trên trình duyệt họ → đánh cắp cookie, token, chiếm tài khoản.

Ví dụ thực tế trong dự án: Tính năng comment sản phẩm cho phép nhập HTML → kẻ tấn công nhập → lấy cắp session của người dùng khác.

BA cần làm gì?

• Với mọi trường cho phép người dùng nhập nội dung hiển thị cho người khác: yêu cầu encode/sanitize output
• Hỏi rõ: “Trường này có cho phép HTML/Rich Text không? Nếu có, whitelist những tag nào?”
• Yêu cầu thiết lập Content Security Policy (CSP) — ghi vào non-functional requirements

4. Insecure Design — Lỗi Bắt Đầu Từ Bàn Thiết Kế

Đây là lỗ hổng BA chịu trách nhiệm NHIỀU NHẤT — vì nó nằm hoàn toàn trong logic nghiệp vụ.

Insecure Design không phải lỗi coding. Đó là lỗi từ chính cách thiết kế tính năng — thứ xuất hiện trong user story và acceptance criteria của BA.

Ví dụ thực tế:

BA cần làm gì?

• Với mọi luồng xác thực, hỏi: “OTP/Link/Token này có thời hạn không? Bao lâu?”
• Với mọi hành động quan trọng, hỏi: “Có giới hạn số lần thực hiện không? Điều gì xảy ra khi vượt giới hạn?”
• Áp dụng tư duy “What if someone tries to abuse this feature?” vào mọi user story

5. Account Takeover (ATO) — Chiếm Đoạt Tài Khoản

Account Takeover là hình thức tấn công nguy hiểm nhất với người dùng cuối — kẻ xấu chiếm quyền tài khoản hợp lệ thông qua nhiều phương thức khác nhau.

Các phương thức tấn công phổ biến:

• Phishing: Tạo trang giả mạo gần giống thật (vd: ) để lừa nhập thông tin đăng nhập
• Brute Force: Thử hàng triệu tổ hợp mật khẩu tự động
• Credential Stuffing: Dùng lại tài khoản/mật khẩu bị rò rỉ từ dịch vụ khác
• Brute Force OTP: Thử mọi giá trị OTP có thể (6 số = 1.000.000 khả năng)
• Session Hijacking: Chiếm quyền điều khiển phiên đăng nhập hiện tại

BA cần đặc tả những gì để phòng chống ATO?

- Giới hạn số lần đăng nhập sai (vd: khóa 15 phút sau 5 lần sai)
- CAPTCHA sau N lần thất bại liên tiếp
- Gửi thông báo email/SMS khi đăng nhập từ thiết bị/IP lạ
- OTP có timeout (khuyến nghị: 3–5 phút)
- Giới hạn số lần nhập OTP (vd: tối đa 3 lần/phiên)
- Yêu cầu xác thực lại khi thay đổi email, SĐT, mật khẩu
- Session tự động hết hạn sau thời gian không hoạt động

6. Bảo Mật Hạ Tầng — Những Gì BA Cần Biết (Không Cần Làm)

BA không quản lý hạ tầng, nhưng cần đủ hiểu biết để đặt câu hỏi đúng với DevOps/Security team.

DoS & DDoS:

Tấn công từ chối dịch vụ làm hệ thống quá tải, không phục vụ được người dùng hợp pháp. Với BA, điều quan trọng là đặc tả các yêu cầu phi chức năng (Non-Functional Requirements) liên quan đến traffic:

“Hệ thống cần xử lý tối đa bao nhiêu request/giây? Vào dịp campaign lớn, traffic có thể tăng gấp bao nhiêu lần? Có cần rate limiting không?”

Malware & Unauthorized Access:

Với BA, phần này quan trọng khi thiết kế tính năng upload file, import dữ liệu hoặc tích hợp bên thứ ba:

• Hỏi rõ: “File upload có giới hạn định dạng và dung lượng không?”
• Yêu cầu scan virus/malware với file upload nếu hệ thống có độ nhạy cảm cao

  

Checklist Security Requirements Cho BA — Dùng Được Ngay

Copy vào Confluence/Notion và kiểm tra trước mỗi lần submit requirement:

Authentication & Authorization

• Đã xây dựng Permission Matrix (ai – làm gì – với dữ liệu nào)?
• Phân quyền được kiểm tra ở server-side?
• Có giới hạn số lần đăng nhập sai không?
• OTP có timeout và giới hạn số lần nhập?
• Có thông báo đăng nhập bất thường?
• Yêu cầu xác thực lại khi thay đổi thông tin nhạy cảm?

Input Validation & Data Security

• Tất cả trường nhập liệu đã có validation rules?
• Dữ liệu nhạy cảm (mật khẩu, CCCD, thẻ tín dụng) được mã hóa?
• Hệ thống dùng HTTPS toàn bộ?
• Error message không lộ thông tin kỹ thuật cho người dùng?
• File upload có giới hạn định dạng và dung lượng?

Business Logic Security

• Mọi hành động quan trọng có giới hạn số lần thực hiện?
• Link/token reset mật khẩu có thời gian hết hạn?
• Các luồng tài chính (thanh toán, hoàn tiền) có được kiểm tra chéo?
• API không trả về dữ liệu thừa ngoài những gì cần thiết?
• Tấn công IDOR đã được xem xét cho mọi resource ID?

Monitoring & Compliance

• Có logging cho các hành động nhạy cảm?
• Đã xác định dữ liệu nào thuộc phạm vi PDPA/GDPR?
• Có kế hoạch xử lý khi phát hiện breach?

Câu Hỏi Bảo Mật BA Cần Hỏi Trong Mỗi Dự Án

Đây là bộ câu hỏi bắt buộc nên đưa vào mỗi buổi requirement workshop:

Về phân quyền:

“Ai là những loại user khác nhau trong hệ thống? Mỗi loại được phép xem/làm gì? Có trường hợp nào một người vô tình thấy dữ liệu của người khác không?”

Về dữ liệu nhạy cảm:

“Thông tin nào trong hệ thống này được coi là nhạy cảm? Chúng được lưu trữ và truyền tải như thế nào?”

Về luồng xác thực:

“Điều gì xảy ra nếu ai đó thử đăng nhập sai 10 lần liên tiếp? OTP có hết hạn không và sau bao lâu?”

Về giới hạn hệ thống:

“Có tính năng nào có thể bị lạm dụng nếu được thực hiện lặp đi lặp lại không? Chúng ta có cần rate limiting không?”

Về tính tuân thủ:

“Hệ thống này có lưu dữ liệu cá nhân không? Chúng ta có nghĩa vụ tuân thủ quy định nào (PDPA, GDPR, PCI-DSS)?”

Case Study: Lỗ Hổng Bảo Mật Trong Business Analysis Từ Yêu Cầu Sai — Dự Án Fintech

Bối cảnh: Một ứng dụng ví điện tử được triển khai với tính năng chuyển tiền bằng OTP xác nhận.

Yêu cầu ban đầu (của BA):

“Hệ thống gửi OTP 6 số. Người dùng nhập OTP để xác nhận giao dịch.”

Vấn đề bảo mật bị bỏ qua:

• Không có timeout cho OTP → OTP có hiệu lực vĩnh viễn
• Không có giới hạn số lần nhập → Kẻ tấn công có thể brute-force
• OTP 6 số = 1.000.000 khả năng → Với 1.000 request/giây, có thể dò trong ~17 phút

Hậu quả: Sau khi ra mắt, hệ thống bị tấn công ATO hàng loạt trong đêm đầu tiên.

Yêu cầu đúng cần có:

“OTP 6 số, hết hạn sau 3 phút, tối đa 3 lần nhập sai/phiên. Sau 3 lần sai: hủy giao dịch và yêu cầu tạo OTP mới. Ghi log toàn bộ lần thử.”

Bài học: Một câu yêu cầu thiếu 3 điều kiện đã tạo ra lỗ hổng nghiêm trọng. BA hiểu bảo mật sẽ viết đúng ngay từ đầu.

Từ Điển Thuật Ngữ Bảo Mật Cho BA

Thuật ngữ	Giải thích nhanh cho BA
OWASP	Tổ chức công bố chuẩn bảo mật web phổ biến nhất thế giới
CVE	Mã định danh lỗ hổng bảo mật đã công bố (vd: CVE-2024-1234)
Zero-Day	Lỗ hổng chưa có bản vá — nguy hiểm nhất
IDOR	Thay đổi ID để truy cập dữ liệu người khác
Brute Force	Thử hàng loạt mật khẩu/OTP tự động
Phishing	Giả mạo website/email để lấy thông tin đăng nhập
Rate Limiting	Giới hạn số lượng request trong khoảng thời gian
HTTPS/TLS	Mã hóa dữ liệu truyền giữa client và server
Least Privilege	Chỉ cấp quyền tối thiểu cần thiết
PDPA	Luật bảo vệ dữ liệu cá nhân (Việt Nam)
PCI-DSS	Chuẩn bảo mật cho hệ thống xử lý thẻ thanh toán
MFA/2FA	Xác thực đa yếu tố — thêm lớp bảo vệ ngoài mật khẩu

FAQ — Câu Hỏi Thường Gặp Về Bảo Mật Dành Cho BA

BA có cần học bảo mật không nếu đã có Security Engineer trong team?

Có. Security Engineer bảo vệ ở tầng kỹ thuật — nhưng không thể viết lại requirement của BA. Nếu yêu cầu thiết kế sai ngay từ đầu, Security Engineer không có cơ hội can thiệp. Trách nhiệm của hai vai trò này bổ sung chứ không thay thế nhau.

BA cần học OWASP ở mức độ nào?

BA không cần hiểu cách khai thác kỹ thuật, nhưng cần hiểu: lỗ hổng nào xuất phát từ thiết kế (Insecure Design, BAC) và cần đặt câu hỏi gì trong requirement phase để phòng tránh. Đọc OWASP Top 10 ở mức tổng quan là đủ — mục tiêu là nhận diện rủi ro, không phải trở thành pentester.

Security requirements được viết ở đâu trong tài liệu BA?

Ở hai nơi: (1) Non-Functional Requirements (NFR) cho các yêu cầu toàn hệ thống như HTTPS, logging, session timeout; và (2) Acceptance Criteria của từng User Story cho các yêu cầu cụ thể như giới hạn OTP, rate limiting của tính năng cụ thể.

Làm sao để BA không bị “overwhelmed” khi nghĩ về bảo mật?

Dùng checklist. Mỗi khi hoàn thiện một user story, chạy qua 5 câu hỏi: Ai có quyền? Dữ liệu nào nhạy cảm? Tính năng này có thể bị lạm dụng không? Có giới hạn gì chưa? Lỗi được xử lý như thế nào? Năm câu hỏi này đã phủ được 80% rủi ro phổ biến.

PDPA ảnh hưởng đến công việc BA như thế nào?

PDPA (Nghị định 13/2023 tại Việt Nam) yêu cầu có cơ chế thu thập đồng ý rõ ràng, mục đích sử dụng dữ liệu, quyền xóa/chỉnh sửa dữ liệu của người dùng. BA cần xác định sớm: hệ thống lưu dữ liệu cá nhân nào, ai truy cập được, và thiết kế các tính năng tuân thủ từ đầu.

Tóm Tắt — BA Cần Nhớ Gì Về Bảo Mật?

Bảo mật không phải trách nhiệm riêng của Security hay DevOps. Trong vòng đời phát triển phần mềm, BA là người đầu tiên có cơ hội ngăn chặn lỗ hổng — trước khi nó được code vào hệ thống.

Ba điều cốt lõi mọi BA cần nội tâm hóa:

1 — Tư duy “adversarial”: Với mỗi tính năng, hỏi: “Nếu tôi muốn lạm dụng tính năng này, tôi sẽ làm gì?”

2 — Security requirements là một phần của definition of done: Một user story chưa có security considerations chưa phải là user story hoàn chỉnh.

3 — Giao tiếp là công cụ bảo mật: Hỏi đúng câu hỏi trong buổi thiết kế còn hiệu quả hơn bất kỳ security tool nào sau khi hệ thống đã ra mắt.

“Phòng bệnh hơn chữa bệnh” — trong bảo mật phần mềm, “phòng” bắt đầu từ trang giấy của Business Analyst.

>>> Có thể bạn cần đọc:

Elicitation Trong Business Analysis – Bỏ Túi 5 Kỹ Thuật, Bộ Câu Hỏi Mẫu & Checklist Thực Chiến

Kỹ Năng Business Analyst – Sự Khác Biệt Giữa BA Mới Và BA Lâu Năm – Case Study EdTech