Giải pháp bảo mật thông tin và phát triển phần mềm an toàn

Phát triển phần mềm an toàn là đưa bảo mật vào mọi giai đoạn của vòng đời phần mềm, từ lúc viết yêu cầu, thiết kế, lập trình, kiểm thử đến vận hành, thay vì chờ tới trước ngày ra mắt mới thuê kiểm thử xâm nhập. Cách làm này thường gọi là Secure SDLC hoặc "dịch chuyển sang trái" (shift left). Lý do rất thực tế: lỗi bảo mật phát hiện ở bước thiết kế chỉ cần sửa bản vẽ, còn phát hiện sau khi đã có dữ liệu khách hàng bị lộ thì cái giá là uy tín và trách nhiệm pháp lý. Bài viết trình bày các giải pháp cụ thể cho đội phát triển phần mềm doanh nghiệp.

Bảo mật thông tin trong bối cảnh phát triển phần mềm

Đội phát triển nắm giữ nhiều tài sản nhạy cảm hơn họ thường nghĩ: mã nguồn, khóa API của đối tác, chuỗi kết nối database production, dữ liệu thử nghiệm sao chép từ dữ liệu thật, quyền deploy. Một lập trình viên vô tình đẩy file cấu hình chứa mật khẩu lên kho mã công khai có thể gây sự cố tương đương một cuộc tấn công. Vì vậy giải pháp bảo mật phải bao phủ cả sản phẩm lẫn quy trình và công cụ làm ra sản phẩm.

Những sai lầm bảo mật phổ biến của doanh nghiệp, như mật khẩu yếu, không cập nhật bản vá, phân quyền lỏng lẻo, được tổng hợp trong bài phân tích về các sai lầm bảo mật doanh nghiệp Việt hay mắc; nhiều trong số đó bắt nguồn từ chính quy trình phát triển.

Giai đoạn yêu cầu: viết bảo mật thành yêu cầu

Bảo mật cần có mặt trong backlog như mọi tính năng. Ví dụ với chức năng đăng nhập:

• Khóa tạm tài khoản hoặc yêu cầu thử thách sau nhiều lần đăng nhập sai liên tiếp.
• Hỗ trợ xác thực hai lớp, bắt buộc với tài khoản quản trị.
• Thông báo cho người dùng khi đăng nhập từ thiết bị mới.
• Không tiết lộ email có tồn tại trong hệ thống hay không qua thông báo lỗi.

Tài liệu OWASP ASVS (Application Security Verification Standard) cung cấp danh mục yêu cầu theo ba cấp độ, có thể dùng làm checklist chọn lọc theo mức rủi ro của ứng dụng.

Giai đoạn thiết kế: mô hình hóa mối đe dọa

Threat modeling là buổi làm việc ngắn, trả lời bốn câu hỏi: chúng ta đang xây gì; điều gì có thể sai; chúng ta sẽ làm gì với nó; chúng ta đã làm đủ tốt chưa. Vẽ sơ đồ luồng dữ liệu, đánh dấu ranh giới tin cậy (giữa trình duyệt và máy chủ, giữa service và database, giữa hệ thống và đối tác), rồi dùng mô hình STRIDE để gợi ý mối đe dọa:

Kiến trúc tách lớp rõ ràng giúp đặt các kiểm soát đúng chỗ: kiểm tra đầu vào ở lớp ngoài, kiểm tra quyền ở use case. Xem thêm bài thiết kế kiến trúc Clean Architecture.

Giai đoạn lập trình: thói quen viết code an toàn

• Không tin dữ liệu đầu vào: kiểm tra kiểu, độ dài, định dạng ở phía máy chủ; dùng truy vấn tham số hóa thay vì nối chuỗi SQL.
• Mã hóa đầu ra theo ngữ cảnh để chống XSS; dùng cơ chế tự escape của framework giao diện, cẩn thận với các hàm chèn HTML thô.
• Kiểm tra quyền trên từng đối tượng: người dùng A không được xem đơn hàng của người dùng B chỉ bằng cách đổi mã trong URL. Đây là lỗi kiểm soát truy cập, nhóm rủi ro đứng đầu trong OWASP Top 10 bản 2021.
• Dùng thư viện mật mã chuẩn, không tự chế thuật toán; băm mật khẩu bằng hàm chuyên dụng như Argon2, bcrypt.
• Xử lý lỗi an toàn: không trả stack trace, câu SQL hay đường dẫn nội bộ cho người dùng.

Code review nên có checklist bảo mật ngắn cho các thay đổi nhạy cảm như xác thực, phân quyền, thanh toán, xử lý file tải lên.

Quản lý bí mật và phụ thuộc

Bí mật

Mật khẩu, khóa API, chứng chỉ không được nằm trong mã nguồn hay lịch sử Git. Dùng secret manager (Vault, dịch vụ quản lý bí mật của nhà cung cấp cloud) và nạp vào lúc chạy. Bật công cụ quét bí mật (như gitleaks, tính năng secret scanning của nền tảng Git) ở cả máy dev qua pre-commit hook và trên CI. Nếu bí mật đã lỡ bị đẩy lên, coi như đã lộ: thu hồi và tạo mới ngay, xóa lịch sử chỉ là bước phụ.

Thư viện bên thứ ba

Ứng dụng hiện đại chứa nhiều mã của bên thứ ba hơn mã tự viết. Biện pháp:

• Quét lỗ hổng phụ thuộc tự động (SCA) trên mỗi pull request, ví dụ Dependabot, Renovate, OWASP Dependency-Check, Trivy.
• Khóa phiên bản bằng lock file, xem xét kỹ trước khi thêm thư viện mới (mức độ duy trì, số người đóng góp, giấy phép).
• Tạo danh mục thành phần phần mềm (SBOM) để khi có lỗ hổng lớn được công bố, biết ngay ứng dụng nào bị ảnh hưởng.

Kiểm thử bảo mật tự động trong pipeline

• SAST (phân tích mã tĩnh): Semgrep, SonarQube, CodeQL tìm mẫu code nguy hiểm.
• DAST (kiểm thử động): OWASP ZAP chạy với môi trường staging để tìm lỗi cấu hình, header thiếu, lỗi chèn.
• Quét container và hạ tầng dạng mã: phát hiện image chứa gói lỗi thời, cấu hình Kubernetes, Terraform không an toàn.

Bắt đầu ở chế độ cảnh báo, tinh chỉnh để giảm kết quả sai, rồi mới chặn merge với lỗi mức cao. Công cụ quá ồn sẽ bị đội phát triển phớt lờ.

Vận hành: bảo mật không kết thúc khi release

• Tách quyền giữa môi trường dev, staging, production; lập trình viên không cần quyền đọc dữ liệu production hằng ngày.
• Dữ liệu thử nghiệm phải được ẩn danh hóa, không sao chép nguyên dữ liệu khách hàng thật.
• Ghi log bảo mật và giám sát, có quy trình tiếp nhận báo cáo lỗ hổng từ bên ngoài (security.txt, chương trình bug bounty khi đủ trưởng thành).
• Kiểm thử xâm nhập định kỳ bởi đơn vị độc lập cho hệ thống quan trọng.

Bảo vệ dữ liệu ở cấp tổ chức, gồm sao lưu, mã hóa, đào tạo nhân viên, được trình bày trong bài đảm bảo an toàn dữ liệu cho doanh nghiệp.

Xây văn hóa bảo mật trong đội

Công cụ không thay được ý thức. Một vài cách đơn giản: chỉ định "người phụ trách bảo mật" trong mỗi đội (security champion) được đào tạo thêm; tổ chức buổi chia sẻ ngắn sau mỗi lỗi bảo mật tìm thấy, tập trung vào bài học chứ không đổ lỗi; đưa tiêu chí bảo mật vào Definition of Done.