Cách bảo vệ khóa API MB Bank trên website và khi triển khai ứng dụng

Để bảo vệ khóa API dùng cho tích hợp MB Bank, hãy giữ khóa hoàn toàn ở phía máy chủ, cấp quyền tối thiểu và không đưa khóa vào mã JavaScript gửi xuống trình duyệt. Đồng thời, cần kiểm soát nơi khóa xuất hiện trong quá trình build, triển khai, ghi log và xử lý giao dịch.

Trước khi cấu hình, hãy xác định khóa do MB Bank cấp qua kênh tích hợp được xác nhận hay do một nhà cung cấp trung gian cấp. Hai trường hợp có thể khác nhau về quyền truy cập, cách xác thực và quy trình thu hồi khóa. Bài viết này hướng dẫn kiến trúc bảo vệ và cách kiểm tra; không giả định MB Bank có API công khai hoặc một cơ chế chữ ký cụ thể.

Xác định khóa đang cấp quyền cho ai và cho việc gì

Lập danh sách thông tin xác thực mà ứng dụng sử dụng: khóa gọi dịch vụ, secret xác minh webhook nếu có, tài khoản quản trị nhà cung cấp và thông tin kết nối cơ sở dữ liệu. Không xem các giá trị này là cùng một loại hoặc mặc định có thể dùng thay nhau.

Với dịch vụ trung gian kết nối dữ liệu giao dịch MB Bank, tài liệu của nhà cung cấp quyết định cách dùng khóa của dịch vụ đó. Không gọi khóa này là khóa API chính thức của MB Bank khi chưa có căn cứ.

• Phạm vi quyền: xác định khóa chỉ đọc giao dịch hay có thêm quyền khác; chọn quyền tối thiểu nếu hệ thống hỗ trợ.
• Phạm vi tài khoản: làm rõ khóa truy cập tài khoản nhận tiền nào, tránh dùng nhầm giữa các website.
• Khả năng kiểm soát: kiểm tra cơ chế thu hồi, thay khóa, giới hạn IP và lịch sử truy cập nếu được cung cấp.

Kết quả cần có là danh sách khóa, người chịu trách nhiệm và vị trí sử dụng, nhưng không ghi giá trị khóa vào tài liệu chung.

Giữ khóa ở máy chủ thay vì che giấu trong trình duyệt

Luồng phù hợp là trình duyệt gửi yêu cầu đến backend của website; backend kiểm tra quyền người dùng rồi mới gọi dịch vụ ngân hàng hoặc bên trung gian. Trình duyệt chỉ nhận dữ liệu cần hiển thị, không nhận khóa hay toàn bộ phản hồi nội bộ.

Mã hóa chuỗi, đổi tên biến hoặc làm rối JavaScript không bảo vệ được khóa đã gửi xuống trình duyệt. Người dùng vẫn có thể xem mã tải về và các yêu cầu mạng. Biến môi trường được công cụ frontend nhúng vào bản build cũng không còn là bí mật.

Đặt secret ngoài vùng phục vụ tệp công khai

Có thể truyền secret vào tiến trình backend qua cơ chế quản lý secret của nền tảng hoặc cấu hình riêng có quyền truy cập hạn chế. Nếu dùng tệp .env, phải đặt ngoài thư mục công khai, không commit và không đưa vào bản sao lưu mà nhiều người tải được.

Backend cũng không nên cung cấp một endpoint chuyển tiếp tùy ý. Mỗi chức năng như xem trạng thái đơn nạp phải kiểm tra đăng nhập, quyền sở hữu đơn và giới hạn dữ liệu trả về.

Kiểm soát secret trong Git, CI/CD và máy chủ triển khai

Rò rỉ thường xảy ra khi sao chép cấu hình hoặc sửa lỗi triển khai. Vì vậy, cần kiểm soát cả đường đi của khóa, không chỉ nơi ứng dụng đọc khóa lúc chạy.

1. Tách môi trường: dùng cấu hình riêng cho phát triển, kiểm thử và production. Ưu tiên sandbox nếu nhà cung cấp hỗ trợ; không đưa khóa thật lên máy cá nhân không cần thiết.
2. Kiểm tra kho mã: loại tệp secret khỏi Git trước lần commit đầu tiên. Nếu khóa từng được commit, thêm vào .gitignore không xóa được nó khỏi lịch sử; cần thu hồi hoặc thay khóa.
3. Giới hạn CI/CD: chỉ cấp secret cho tác vụ triển khai cần dùng. Không đưa secret production vào quy trình chạy mã từ nguồn không tin cậy.
4. Kiểm tra bản build: không đóng gói secret trong frontend, image container, artifact hoặc tệp cấu hình mẫu. Đặc biệt tránh ghi secret vào một lớp image rồi chỉ xóa ở lớp sau.
5. Phân quyền máy chủ: chạy ứng dụng bằng tài khoản phù hợp, hạn chế quyền đọc tệp secret và tách quyền triển khai khỏi quyền quản trị khi khả thi.

Không in biến môi trường để chẩn đoán lỗi. Tính năng che giá trị trong log CI/CD chỉ là lớp hỗ trợ, không bảo đảm che được mọi dạng biến đổi của secret.

Bảo vệ luồng nạp tiền gắn với giao dịch MB Bank

Giữ kín khóa chưa đủ để bảo vệ số dư người dùng. Hệ thống nạp tiền còn phải xác định đúng giao dịch, xác minh nguồn dữ liệu và chống xử lý trùng.

Tạo đơn và đối chiếu dữ liệu ở backend

Khi người dùng tạo đơn nạp, backend lưu mã đơn, chủ đơn, số tiền dự kiến, tài khoản nhận và thời hạn. Nội dung chuyển khoản có thể chứa mã nhận diện theo thiết kế đã thống nhất, nhưng không được chứa secret.

Khi nhận dữ liệu giao dịch, đối chiếu số tiền, tài khoản nhận, trạng thái và mã liên kết đơn. Không cộng tiền chỉ vì nội dung chuyển khoản trông giống một mã đơn. Giao dịch thiếu thông tin, sai số tiền hoặc khớp nhiều đơn cần chuyển sang đối soát thủ công.

Xác minh webhook và chống cộng tiền hai lần

Nếu nhà cung cấp hỗ trợ webhook, thực hiện xác minh đúng tài liệu của họ: có thể liên quan đến chữ ký, token hoặc cơ chế khác. Không tự đoán tên header, thuật toán hay quy tắc tạo chữ ký. Giới hạn IP, nếu có danh sách chính thức phù hợp, chỉ là lớp bổ sung.

Không tin callback từ trình duyệt để xác nhận đã nhận tiền. Giao diện phải hỏi backend về trạng thái đã được xác minh.

Ví dụ giả lập: đơn NAP_DEMO_42 chờ 250.000 đồng. Cùng một giao dịch được gửi lại ba lần do retry. Backend cần lưu mã giao dịch duy nhất, đặt ràng buộc duy nhất trong cơ sở dữ liệu và xử lý bản ghi giao dịch, cập nhật đơn, cộng số dư trong một transaction. Phạm vi duy nhất cần tính đến nhà cung cấp hoặc tài khoản theo quy tắc mã giao dịch của nguồn dữ liệu.

Nếu transaction lỗi, dữ liệu phải rollback để lần thử lại có thể xử lý an toàn. Giao dịch đã hoàn tất không được cộng lại. Cách phản hồi xác nhận cho webhook phải theo tài liệu, không tự giả định mọi nhà cung cấp có cùng chính sách retry.

Ghi log và xử lý khi nghi ngờ lộ khóa

Log nên lưu mã yêu cầu nội bộ, mã đơn, mã giao dịch, kết quả xác minh và lỗi đã lọc dữ liệu nhạy cảm. Không ghi nguyên header xác thực, secret, chuỗi kết nối hoặc toàn bộ payload ngân hàng. Dữ liệu tài khoản và giao dịch cũng cần giới hạn người được xem, thời gian lưu và phạm vi sao lưu.

Khi nghi ngờ lộ khóa, ưu tiên thu hồi hoặc vô hiệu hóa theo cơ chế nhà cung cấp, đánh giá luồng xử lý bị ảnh hưởng rồi cấp khóa mới. Rà soát lịch sử truy cập, giao dịch bất thường và đối soát số dư trong khoảng thời gian có rủi ro. Xóa khóa khỏi mã nguồn không thay thế việc thu hồi.

Nếu cần chuyển đổi không gián đoạn, phải kiểm tra nhà cung cấp có cho phép hai khóa cùng hoạt động hay không. Không mặc định tính năng này tồn tại.

Kiểm thử trước khi cho phép cộng tiền thật

• Kiểm tra frontend: tìm giá trị khóa trong tệp build, mã trang, source map công khai và yêu cầu mạng; kết quả mong đợi là không xuất hiện.
• Kiểm tra truy cập: thử truy cập các đường dẫn cấu hình trong môi trường được phép kiểm thử; máy chủ không được trả nội dung secret.
• Kiểm tra xác thực: webhook thiếu hoặc sai thông tin xác minh phải bị từ chối và không đổi số dư.
• Kiểm tra retry: gửi lặp và gửi đồng thời cùng giao dịch trong môi trường thử; chỉ một lần được ghi nhận cộng tiền.
• Kiểm tra đối soát: thử sai số tiền, sai tài khoản nhận và đơn hết hạn; hệ thống phải xử lý theo chính sách rõ ràng.

Ưu tiên sandbox hoặc dữ liệu giả lập. Chỉ thử giao dịch thật khi đã có quyền, phạm vi và phương án kiểm soát phù hợp.

Câu hỏi thường gặp

Dùng HTTPS có đủ bảo vệ khóa không?

Không. HTTPS bảo vệ dữ liệu trên đường truyền, không ngăn khóa bị lộ từ frontend, Git, log hoặc máy chủ bị truy cập trái phép.

Có thể đặt khóa trong mã nguồn PHP không?

Không nên ghi cứng khóa. Dù PHP thường chạy phía máy chủ, mã nguồn vẫn có thể bị lộ qua kho mã, bản sao lưu hoặc cấu hình sai. Nên tách secret khỏi mã và giới hạn quyền đọc.

Chưa có tài liệu xác minh webhook thì có thể bật tự động không?

Không nên bật tự động cộng tiền dựa trên callback chưa xác minh. Hãy yêu cầu tài liệu và giữ giao dịch ở trạng thái chờ đối soát cho đến khi có nguồn xác nhận đáng tin cậy.

Lập sơ đồ luồng khóa trước lần triển khai tiếp theo

Hãy đánh dấu nơi cấp khóa, nơi lưu, tiến trình sử dụng và người có quyền thay đổi; sau đó kiểm thử một đơn nạp từ lúc tạo đến khi đối soát. Nếu cần chọn mã nguồn hoặc hạ tầng, bạn có thể tham khảo danh mục liên quan tại sieuthicode.com và xác nhận khả năng quản lý secret, phân quyền, hỗ trợ cùng thông số triển khai trước khi mua.