Quản trị rủi ro
Security baseline và privacy
Lấy OWASP MASVS làm khung tham chiếu, kiểm kê third-party SDK, và coi khai báo dữ liệu trên store là điều kiện chặn release.
Nội dung bài
Thuật ngữ trong bài (19)
- acceptance criteria · tiêu chí nghiệm thu
- CI · tích hợp liên tục
- deprecated · đánh dấu ngừng dùng
- pull request · yêu cầu gộp mã
- test case · ca kiểm thử
- release · bản phát hành
- incident · sự cố
- keystore · kho khóa ký ứng dụng
- MASVS · chuẩn kiểm định bảo mật app mobile
- OTP · mã dùng một lần
- OWASP · tổ chức chuẩn bảo mật ứng dụng
- permission · quyền truy cập
- refresh token · khóa làm mới phiên
- secret · thông tin bí mật
- session · phiên đăng nhập
- API · giao diện lập trình
- deep link · liên kết vào thẳng màn hình
- SDK · bộ thư viện tích hợp
- token · khóa truy cập
Không tự nghĩ ra danh sách bảo mật riêng
Bảo mật là lĩnh vực đã có chuẩn công khai, được cập nhật liên tục, và đủ chi tiết cho mobile. Một đội tự liệt kê "những thứ cần chú ý về bảo mật" sẽ luôn thiếu — thiếu đúng những thứ mình chưa từng gặp.
Khung tham chiếu của dự án là OWASP MASVS, chia security requirement của mobile app thành các nhóm: storage, cryptography, authentication, network, platform interaction, code quality, resilience và privacy. Bộ đi kèm là OWASP MASTG, chuyển từng control thành test case cụ thể cho iOS và Android.
Cách dùng: không đọc hết. Khi làm một tính năng chạm tới dữ liệu nhạy cảm, mở đúng nhóm tương ứng trong MASVS, lấy các control liên quan làm acceptance criteria.
Checklist bắt buộc mỗi release
Đây là phần rút gọn, áp dụng cho mọi release, không phụ thuộc tính năng:
- Access token và refresh token lưu trong Keychain (iOS) hoặc Keystore (Android), không lưu plaintext, không lưu trong SharedPreferences/UserDefaults thường
- Không log dữ liệu nhạy cảm: mật khẩu, token, OTP, số thẻ, nội dung tin nhắn
- Certificate validation bật đầy đủ, không tắt để tiện debug rồi quên bật lại
- Deep link và URL scheme kiểm tra tham số đầu vào, không tin dữ liệu từ link
- Session hết hạn đúng thiết kế; refresh token xoay vòng và thu hồi được từ server
- Database local có dữ liệu nghiệp vụ thì phải mã hoá
- Màn hình nhạy cảm che nội dung khi app vào app switcher
- Không đẩy dữ liệu nhạy cảm ra clipboard, hoặc có thì tự xoá sau thời gian ngắn
- OTP và đăng nhập có rate limit phía server, không chỉ chặn ở client
- Secret scan và dependency scan trong CI không báo lỗi mức High trở lên
Quy tắc đọc checklist này: kiểm ở phía server mới tính. Mọi thứ chỉ chặn ở client đều có thể bị bỏ qua bằng cách gọi thẳng API.
Kiểm kê third-party SDK
Mỗi SDK là một phần code chạy trong app với toàn quyền của app, do người ngoài viết, cập nhật theo lịch của người ngoài. Đây là nguồn risk lớn nhất và ít được nhìn nhất của một mobile app.
Dự án giữ một bảng kiểm kê, cập nhật mỗi quý:
| Cột | Nội dung |
|---|---|
| SDK | Tên và version đang dùng |
| Chủ sở hữu | Một người trong đội chịu trách nhiệm theo dõi |
| Mục đích | Vì sao cần — không trả lời được thì gỡ |
| Permission | SDK đòi những quyền gì |
| Dữ liệu thu thập | Nó gửi gì ra ngoài, gửi đi đâu |
| Version mới nhất | Và có lỗ hổng nào đã công bố không |
Luật: thêm một SDK mới phải được chủ kỹ thuật duyệt, kèm câu trả lời cho ba câu hỏi — tự làm tốn bao lâu, SDK này thu thập dữ liệu gì, nếu ngày mai nó ngừng hỗ trợ thì gỡ ra tốn bao lâu.
Khai báo dữ liệu trên store
Apple yêu cầu privacy nutrition label, Google Play yêu cầu Data Safety form. Cả hai đều là khai báo do đội tự điền, và cả hai đều là điều kiện chặn release chứ không phải thủ tục cuối.
Rủi ro thật không nằm ở việc quên điền. Nó nằm ở chỗ khai báo lệch với hành vi thật của app — và nguyên nhân phổ biến nhất là một SDK âm thầm thu thập dữ liệu mà không ai trong đội biết. Khai báo sai có thể dẫn tới bị từ chối bản cập nhật hoặc gỡ app, và đó là loại sự cố không có bản vá kỹ thuật nào cứu được.
Vì vậy bảng kiểm kê SDK ở trên và phần khai báo store phải được soát cùng lúc, mỗi quý và mỗi khi thêm SDK mới.
Khi đội không có người bảo mật chuyên trách
Phần lớn đội mobile không có. Cách phân bổ thực dụng:
| Việc | Ai làm | Nhịp |
|---|---|---|
| Checklist bắt buộc mỗi release | Người cắt bản | Mỗi release |
| Secret scan, dependency scan | CI, tự động | Mỗi pull request |
| Đối chiếu MASVS cho tính năng mới chạm dữ liệu nhạy cảm | Chủ kỹ thuật | Khi thiết kế |
| Kiểm kê SDK và khai báo store | Chủ kỹ thuật | Mỗi quý |
| Rà soát độc lập từ bên ngoài | Thuê ngoài | Trước mốc lớn, hoặc mỗi năm |
Điểm mấu chốt: security tham gia lúc thiết kế, không phải lúc sắp release rồi nói "không được đâu". Một yêu cầu bảo mật phát hiện lúc thiết kế tốn một cuộc họp; phát hiện lúc sắp release tốn cả một bản làm lại.
Giới hạn
- MASVS có nhiều mức. Alliance App không phải app ngân hàng, nên các control chống dịch ngược và chống can thiệp (nhóm resilience) chỉ áp cho luồng thanh toán, không áp toàn app.
- Checklist trên chặn được lỗi phổ biến, không thay được một lần rà soát độc lập. Đừng nhầm hai thứ đó với nhau.
- Mỗi control thêm vào danh sách phải chặn được một risk có thật với dữ liệu app đang giữ. Control thêm vì lo xa mà chưa từng bắt được gì thì bỏ đi.

