AllianceProject Handbook
← Knowledge

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.

Cập nhật 12/09/2026chất lượngsecurityprivacy

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ộtNội dung
SDKTên và version đang dùng
Chủ sở hữuMột người trong đội chịu trách nhiệm theo dõi
Mục đíchVì sao cần — không trả lời được thì gỡ
PermissionSDK đòi những quyền gì
Dữ liệu thu thậpNó gửi gì ra ngoài, gửi đi đâu
Version mới nhấtVà 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ệcAi làmNhịp
Checklist bắt buộc mỗi releaseNgười cắt bảnMỗi release
Secret scan, dependency scanCI, tự độngMỗi pull request
Đối chiếu MASVS cho tính năng mới chạm dữ liệu nhạy cảmChủ kỹ thuậtKhi thiết kế
Kiểm kê SDK và khai báo storeChủ kỹ thuậtMỗi quý
Rà soát độc lập từ bên ngoàiThuê ngoàiTrướ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.