Những yêu cầu bảo mật đối với nền tảng số

Vì vậy, bảo mật nền tảng số không thể chỉ được hiểu là cài phần mềm chống mã độc hoặc mã hóa đường truyền. Nền tảng cần đáp ứng một hệ thống yêu cầu bao gồm quản trị rủi ro, bảo vệ dữ liệu, quản lý danh tính, kiểm soát truy cập, bảo đảm tính toàn vẹn của giao dịch, phát triển phần mềm an toàn, giám sát bất thường, ứng phó sự cố và duy trì khả năng phục hồi.

Cách tiếp cận này tương ứng với sáu chức năng quản trị rủi ro an ninh mạng của NIST Cybersecurity Framework 2.0 gồm Govern, Identify, Protect, Detect, Respond và Recover. NIST xác định đây là những chức năng liên tục, hỗ trợ tổ chức quản lý rủi ro trong toàn bộ vòng đời hệ thống chứ không phải các công việc độc lập chỉ thực hiện một lần.

Quản trị bảo mật phải gắn với rủi ro của nền tảng

Yêu cầu đầu tiên của bảo mật nền tảng số là xác định rõ ai chịu trách nhiệm, tài sản nào cần bảo vệ và mức rủi ro nào có thể chấp nhận.

Tổ chức vận hành cần lập danh mục tài sản gồm dữ liệu, tài khoản đặc quyền, máy chủ, cơ sở dữ liệu, API, ứng dụng, dịch vụ đám mây, khóa mật mã và các kết nối với bên thứ ba. Mỗi tài sản phải có chủ sở hữu, mức độ quan trọng và yêu cầu bảo vệ tương ứng.

Quản trị bảo mật cần bao gồm:

·         Chính sách an toàn thông tin và bảo vệ dữ liệu

·         Vai trò, quyền hạn và trách nhiệm của từng bộ phận

·         Quy trình đánh giá và xử lý rủi ro

·         Quản lý nhà cung cấp và chuỗi cung ứng công nghệ

·         Tiêu chí chấp nhận rủi ro và phê duyệt ngoại lệ

·         Kiểm tra tuân thủ và đánh giá định kỳ

·         Báo cáo rủi ro cho cấp quản lý

Việc chỉ giao bảo mật cho bộ phận kỹ thuật là chưa đủ. Các quyết định về thu thập dữ liệu, thiết kế sản phẩm, thuê dịch vụ đám mây hoặc tích hợp đối tác đều có thể tạo ra rủi ro. Vì thế, trách nhiệm bảo mật phải được đưa vào hoạt động quản trị, đầu tư và phát triển sản phẩm.

NIST CSF 2.0 bổ sung chức năng Govern nhằm nhấn mạnh rằng an ninh mạng là một loại rủi ro doanh nghiệp cần được lãnh đạo xem xét cùng với rủi ro pháp lý, tài chính và uy tín.

Dữ liệu phải được bảo vệ trong toàn bộ vòng đời

Nền tảng số cần biết mình đang thu thập dữ liệu gì, sử dụng cho mục đích nào, lưu ở đâu, chia sẻ với ai và khi nào phải xóa.

Nguyên tắc cốt lõi là chỉ thu thập lượng dữ liệu cần thiết cho mục đích đã xác định. Thu thập càng nhiều dữ liệu không đồng nghĩa với nền tảng càng có giá trị; ngược lại, dữ liệu dư thừa làm tăng phạm vi thiệt hại khi xảy ra sự cố.

Phân loại và kiểm soát dữ liệu

Dữ liệu nên được phân loại theo mức độ nhạy cảm, chẳng hạn:

·         Dữ liệu công khai

·         Dữ liệu sử dụng nội bộ

·         Dữ liệu bí mật kinh doanh

·         Dữ liệu cá nhân

·         Dữ liệu xác thực

·         Dữ liệu tài chính hoặc thanh toán

Mỗi nhóm cần có chính sách truy cập, thời hạn lưu trữ, phương thức truyền nhận và biện pháp tiêu hủy khác nhau. Dữ liệu nhạy cảm không nên xuất hiện trong nhật ký hệ thống, môi trường thử nghiệm hoặc báo cáo vận hành khi không thực sự cần thiết.

Mã hóa và quản lý khóa

Dữ liệu nhạy cảm cần được mã hóa khi truyền qua mạng và khi lưu trữ. Tuy nhiên, mã hóa chỉ có hiệu quả khi khóa mật mã được quản lý độc lập, giới hạn quyền truy cập, luân chuyển định kỳ và có cơ chế thu hồi khi bị nghi ngờ lộ lọt.

Không nên lưu khóa mã hóa, mật khẩu cơ sở dữ liệu hoặc thông tin bí mật trực tiếp trong mã nguồn. Các bí mật này cần được quản lý bằng kho chuyên dụng, đồng thời ghi nhận mọi hoạt động truy cập hoặc thay đổi.

Tuân thủ quyền của chủ thể dữ liệu

Tại Việt Nam, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 có hiệu lực từ ngày 1/1/2026. Luật xác lập các quyền như được biết về hoạt động xử lý, đồng ý hoặc không đồng ý, rút lại sự đồng ý, truy cập, chỉnh sửa và yêu cầu xóa dữ liệu. Nghị định 356/2025/NĐ-CP có hiệu lực cùng ngày quy định chi tiết một số điều và biện pháp thi hành luật.

Do đó, nền tảng cần có khả năng:

·         Ghi nhận và chứng minh sự đồng ý hợp lệ

·         Cho phép người dùng xem hoặc cập nhật thông tin

·         Tiếp nhận yêu cầu hạn chế, phản đối hoặc xóa dữ liệu

·         Kiểm soát việc chuyển và chia sẻ dữ liệu

·         Xác định thời hạn lưu trữ

·         Lưu dấu vết các hoạt động xử lý dữ liệu

·         Thông báo và xử lý sự cố theo nghĩa vụ pháp lý áp dụng

Tài khoản phải được xác thực và phân quyền chặt chẽ

Tài khoản là điểm truy cập trực tiếp vào dữ liệu và chức năng của nền tảng. Nếu cơ chế xác thực yếu, các lớp bảo vệ phía sau có thể mất tác dụng.

Xác thực người dùng

Nền tảng cần hỗ trợ mật khẩu đủ mạnh, ngăn sử dụng mật khẩu phổ biến hoặc đã bị lộ và lưu mật khẩu bằng thuật toán băm chuyên dụng kèm giá trị salt ngẫu nhiên. Mật khẩu không được lưu dưới dạng có thể đọc lại.

Xác thực đa yếu tố nên được áp dụng cho:

·         Tài khoản quản trị

·         Tài khoản có quyền truy cập dữ liệu nhạy cảm

·         Giao dịch có giá trị hoặc rủi ro cao

·         Thay đổi thông tin bảo mật

·         Đăng nhập từ thiết bị hoặc vị trí bất thường

Mã xác thực một lần phải có thời hạn ngắn, không được tái sử dụng và cần được tạo bằng bộ sinh số ngẫu nhiên an toàn. OWASP ASVS 5.0 yêu cầu mã xác thực ngoài băng có thời hạn tối đa 10 phút, TOTP có thời hạn tối đa 30 giây và các mã này chỉ được sử dụng thành công một lần.

Quản lý phiên đăng nhập

Sau khi xác thực, nền tảng phải bảo vệ phiên làm việc bằng mã phiên khó dự đoán, cookie an toàn và thời gian hết hạn phù hợp. Phiên cần bị vô hiệu hóa khi người dùng đăng xuất, đổi mật khẩu, khóa tài khoản hoặc phát hiện dấu hiệu chiếm quyền.

Các thao tác nhạy cảm như đổi số điện thoại, thay phương thức xác thực, thêm tài khoản nhận tiền hoặc xuất dữ liệu nên yêu cầu xác thực lại.

Phân quyền theo nguyên tắc tối thiểu

Người dùng và dịch vụ chỉ nên có quyền tối thiểu cần thiết để hoàn thành nhiệm vụ. Quyền truy cập cần được kiểm tra tại máy chủ, không dựa vào việc ẩn nút hoặc màn hình ở phía người dùng.

Nền tảng phải ngăn được các tình huống như:

·         Người dùng xem dữ liệu của tài khoản khác bằng cách thay đổi mã định danh

·         Nhân viên truy cập thông tin ngoài phạm vi công việc

·         Dịch vụ nội bộ gọi API không thuộc quyền hạn

·         Tài khoản cũ tiếp tục giữ quyền sau khi đổi vai trò

·         Quản trị viên tự phê duyệt thao tác của chính mình

Đối với chức năng quan trọng, nên áp dụng nguyên tắc tách biệt nhiệm vụ, chẳng hạn một người tạo yêu cầu và một người khác phê duyệt.

Giao dịch phải bảo đảm tính xác thực và toàn vẹn

Một giao dịch an toàn cần trả lời được bốn câu hỏi: ai thực hiện, họ có đủ thẩm quyền không, nội dung có bị thay đổi không và hệ thống có lưu được bằng chứng hay không.

Nền tảng cần liên kết giao dịch với đúng tài khoản, phiên đăng nhập, thời điểm, thiết bị và nội dung đã được người dùng xác nhận. Mọi tham số quan trọng như số tiền, người nhận, sản phẩm hoặc phạm vi quyền hạn phải được kiểm tra lại tại máy chủ.

Ngăn giả mạo và phát lại giao dịch

Mỗi yêu cầu giao dịch cần có mã định danh duy nhất, thời hạn hợp lệ hoặc cơ chế chống gửi lại. Nếu cùng một yêu cầu được truyền nhiều lần do lỗi mạng hoặc thao tác lặp, hệ thống phải tránh thực hiện giao dịch nhiều lần ngoài ý muốn.

Với giao dịch rủi ro cao, nền tảng nên áp dụng xác thực tăng cường dựa trên nội dung giao dịch. Người dùng cần nhìn thấy rõ thông tin quan trọng trước khi xác nhận, thay vì chỉ nhập một mã xác thực không gắn với người nhận hoặc giá trị giao dịch.

Bảo vệ dữ liệu thanh toán

Khi nền tảng lưu trữ, xử lý hoặc truyền dữ liệu thẻ thanh toán, phạm vi áp dụng PCI DSS cần được xác định chính xác. PCI DSS bảo vệ dữ liệu chủ thẻ và dữ liệu xác thực nhạy cảm; phiên bản được PCI Security Standards Council công bố hiện nay là PCI DSS 4.0.1.

Số tài khoản chính của thẻ phải được làm cho không thể đọc được khi lưu trữ. Các thành phần khác nằm trong môi trường dữ liệu chủ thẻ vẫn phải được bảo vệ bằng kiểm soát mạng, quản lý truy cập, quản lý lỗ hổng và những biện pháp PCI DSS tương ứng.

Để giảm rủi ro, nền tảng có thể sử dụng token thay cho dữ liệu thanh toán thực và hạn chế tối đa việc đưa dữ liệu thẻ vào hệ thống của mình.

Lưu dấu vết giao dịch

Nhật ký cần ghi nhận các sự kiện quan trọng như:

·         Đăng nhập và đăng xuất

·         Thay đổi quyền truy cập

·         Thay đổi thông tin bảo mật

·         Tạo, sửa, hủy hoặc phê duyệt giao dịch

·         Truy cập và xuất dữ liệu nhạy cảm

·         Thay đổi cấu hình hệ thống

·         Hành động của tài khoản quản trị

Nhật ký phải được bảo vệ khỏi chỉnh sửa, đồng bộ thời gian và giới hạn người được phép truy cập. Tuy nhiên, nhật ký không nên chứa mật khẩu, mã xác thực, khóa bí mật hoặc toàn bộ dữ liệu nhạy cảm.

Luật Giao dịch điện tử số 20/2023/QH15 có hiệu lực từ ngày 1/7/2024 tạo khung pháp lý cho thông điệp dữ liệu và hoạt động giao dịch bằng phương tiện điện tử. Vì vậy, khả năng bảo đảm tính toàn vẹn, truy xuất nguồn gốc và lưu giữ bằng chứng điện tử là yêu cầu quan trọng đối với nền tảng thực hiện giao dịch.

Phần mềm và API phải được phát triển theo quy trình an toàn

Bảo mật cần được đưa vào ngay từ giai đoạn thiết kế thay vì chỉ kiểm thử trước khi phát hành.

Quy trình phát triển an toàn cần bao gồm:

·         Phân tích yêu cầu bảo mật

·         Mô hình hóa mối đe dọa

·         Tiêu chuẩn lập trình an toàn

·         Rà soát mã nguồn

·         Kiểm thử bảo mật tự động và thủ công

·         Quản lý thư viện phụ thuộc

·         Kiểm soát thay đổi và phát hành

·         Sửa chữa lỗ hổng theo mức độ nghiêm trọng

OWASP ASVS cung cấp cơ sở để kiểm thử các kiểm soát bảo mật kỹ thuật của ứng dụng web và danh sách yêu cầu hỗ trợ phát triển phần mềm an toàn. Tiêu chuẩn này bao phủ các nội dung như xác thực, quản lý phiên, kiểm soát truy cập, xử lý dữ liệu, mật mã, API và cấu hình.

API cần xác thực mọi yêu cầu, kiểm tra quyền trên từng đối tượng dữ liệu, giới hạn tốc độ gọi và xác thực cấu trúc đầu vào. Không nên mặc định rằng API nội bộ là an toàn chỉ vì không được công khai trên Internet.

Đối với thư viện và thành phần bên thứ ba, nền tảng cần có danh mục phiên bản, theo dõi cảnh báo lỗ hổng và quy trình cập nhật. Một thành phần đã lỗi thời có thể trở thành đường tấn công ngay cả khi mã do tổ chức tự phát triển không có sai sót.

Hạ tầng phải được cấu hình an toàn và có khả năng chống chịu

Máy chủ, vùng chứa, dịch vụ đám mây, thiết bị mạng và cơ sở dữ liệu phải được cấu hình theo nguyên tắc an toàn mặc định.

Các yêu cầu cơ bản gồm:

·         Tắt dịch vụ và cổng mạng không cần thiết

·         Phân tách môi trường phát triển, thử nghiệm và sản xuất

·         Phân đoạn mạng theo mức độ tin cậy

·         Hạn chế truy cập quản trị

·         Cập nhật bản vá theo mức rủi ro

·         Sao lưu dữ liệu và cấu hình

·         Kiểm thử khả năng khôi phục

·         Quản lý cấu hình bằng quy trình có kiểm soát

·         Bảo vệ tài nguyên trước tấn công từ chối dịch vụ

Bản sao lưu chỉ có giá trị khi có thể khôi phục. Do đó, tổ chức phải xác định mục tiêu thời gian khôi phục và mức dữ liệu tối đa có thể mất, sau đó thử nghiệm định kỳ thay vì chỉ kiểm tra rằng tệp sao lưu đã được tạo.

Hệ thống quan trọng cần tránh điểm lỗi duy nhất. Tuy nhiên, dự phòng kỹ thuật không thay thế được dự phòng vận hành: nếu cùng một lỗi cấu hình hoặc tài khoản quản trị bị xâm nhập trên toàn bộ cụm hệ thống, nhiều máy chủ dự phòng vẫn có thể bị ảnh hưởng đồng thời.

Nền tảng phải liên tục phát hiện hành vi bất thường

Biện pháp phòng ngừa không thể loại bỏ hoàn toàn rủi ro. Nền tảng cần giám sát để phát hiện sớm các hành vi có thể cho thấy tài khoản, ứng dụng hoặc hạ tầng đã bị xâm nhập.

Hoạt động giám sát nên tập trung vào:

·         Nhiều lần đăng nhập thất bại

·         Đăng nhập từ thiết bị hoặc vị trí bất thường

·         Thay đổi quyền quản trị

·         Truy xuất dữ liệu với khối lượng lớn

·         Giao dịch có mẫu khác thường

·         Lưu lượng API tăng đột biến

·         Cấu hình bảo mật bị thay đổi

·         Phần mềm độc hại hoặc tiến trình không được phép

·         Nhật ký bị xóa hoặc ngừng gửi

Cảnh báo cần có người chịu trách nhiệm xử lý, mức độ ưu tiên và thời hạn phản hồi. Thu thập nhiều nhật ký nhưng không phân tích hoặc không có quy trình xử lý sẽ không tạo ra năng lực phát hiện thực tế.

Việc phát hiện gian lận cũng không nên chỉ dựa trên một dấu hiệu. Ví dụ, đăng nhập từ vị trí mới có thể hợp lệ; nhưng nếu đồng thời xuất hiện thiết bị lạ, đổi phương thức xác thực và thực hiện giao dịch lớn, mức rủi ro sẽ cao hơn đáng kể.

Phải có quy trình ứng phó và thông báo sự cố

Khi xảy ra sự cố, tổ chức cần biết phải xác minh, cô lập, xử lý và truyền thông như thế nào. Nếu không có kế hoạch từ trước, phản ứng chậm hoặc thiếu nhất quán có thể làm thiệt hại lan rộng.

Kế hoạch ứng phó cần xác định:

·         Tiêu chí phân loại sự cố

·         Người có quyền kích hoạt quy trình

·         Kênh liên lạc khẩn cấp

·         Cách bảo toàn nhật ký và bằng chứng

·         Biện pháp cô lập tài khoản hoặc hệ thống

·         Quy trình khôi phục an toàn

·         Nghĩa vụ thông báo cho cơ quan có thẩm quyền

·         Cách thông tin cho người dùng và đối tác

·         Hoạt động điều tra nguyên nhân gốc

·         Biện pháp ngăn sự cố tái diễn

Tổ chức cần diễn tập các tình huống như lộ dữ liệu, chiếm quyền tài khoản quản trị, mã độc tống tiền, gián đoạn dịch vụ hoặc gian lận giao dịch. Diễn tập giúp kiểm tra xem danh sách liên hệ, quyền ra quyết định, bản sao lưu và công cụ kỹ thuật có thực sự hoạt động hay không.

Sau sự cố, nền tảng chỉ nên đưa dịch vụ trở lại khi đã xác định được phạm vi ảnh hưởng, loại bỏ nguyên nhân và kiểm tra rằng hệ thống khôi phục không còn dấu hiệu xâm nhập.

Bên thứ ba phải đáp ứng yêu cầu bảo mật tương đương

Nền tảng số thường phụ thuộc vào dịch vụ đám mây, cổng thanh toán, đơn vị xác thực, công cụ phân tích, nhà cung cấp phần mềm và API đối tác. Dữ liệu hoặc quyền truy cập được chia sẻ với bên thứ ba có thể mở rộng đáng kể bề mặt tấn công.

Trước khi tích hợp, tổ chức cần đánh giá:

·         Dữ liệu nào sẽ được chia sẻ

·         Đối tác được phép sử dụng dữ liệu cho mục đích nào

·         Kiểm soát truy cập và mã hóa của đối tác

·         Vị trí lưu trữ và xử lý dữ liệu

·         Cách đối tác quản lý nhà thầu phụ

·         Thời hạn thông báo sự cố

·         Khả năng xóa hoặc hoàn trả dữ liệu

·         Điều kiện chấm dứt kết nối

·         Quyền kiểm tra và yêu cầu khắc phục

Khóa API và tài khoản tích hợp phải có quyền tối thiểu, được luân chuyển và thu hồi ngay khi không còn sử dụng. Hoạt động của đối tác cũng cần được ghi nhật ký và giám sát như hoạt động nội bộ.

Bảo mật phải được đo lường và cải tiến liên tục

Không thể kết luận nền tảng an toàn chỉ vì chưa ghi nhận sự cố. Tổ chức cần sử dụng chỉ số để đánh giá liệu các kiểm soát có hoạt động đúng hay không.

Một số chỉ số có thể theo dõi gồm:

·         Tỷ lệ tài khoản đặc quyền đã bật xác thực đa yếu tố

·         Thời gian phát hiện và xử lý sự cố

·         Tỷ lệ lỗ hổng được khắc phục đúng hạn

·         Số quyền truy cập không còn cần thiết

·         Tỷ lệ khôi phục sao lưu thành công

·         Số thành phần phần mềm hết hỗ trợ

·         Tỷ lệ giao dịch rủi ro được kiểm tra

·         Số sự kiện truy cập dữ liệu bất thường

·         Kết quả kiểm thử xâm nhập và diễn tập sự cố

Các chỉ số phải gắn với mục tiêu và mức rủi ro cụ thể. Ví dụ, số lượng cảnh báo tăng không nhất thiết chứng minh hệ thống kém an toàn; nguyên nhân có thể là khả năng giám sát tốt hơn. Giá trị thực sự nằm ở việc phân tích xu hướng, nguyên nhân và hiệu quả khắc phục.

Kiểm thử bảo mật nên được thực hiện sau thay đổi quan trọng, đồng thời tiến hành định kỳ theo mức độ rủi ro. Với nền tảng có giao dịch hoặc dữ liệu nhạy cảm, chỉ quét lỗ hổng tự động là chưa đủ; cần kết hợp rà soát kiến trúc, kiểm thử logic nghiệp vụ và kiểm thử xâm nhập độc lập.

Một nền tảng số đáp ứng yêu cầu bảo mật không chỉ có tường lửa, mã hóa hoặc xác thực đa yếu tố. Nền tảng phải kiểm soát đồng thời con người, quy trình, dữ liệu, phần mềm, hạ tầng, giao dịch và các bên liên quan.

Ba mục tiêu trung tâm cần được duy trì là dữ liệu chỉ được người có thẩm quyền truy cập, thông tin và giao dịch không bị thay đổi trái phép, đồng thời dịch vụ vẫn có thể vận hành hoặc khôi phục khi xảy ra sự cố. Để đạt được các mục tiêu này, bảo mật phải được thiết kế từ đầu, kiểm chứng bằng tiêu chuẩn và bằng chứng kỹ thuật, giám sát trong quá trình vận hành và cải tiến theo sự thay đổi của rủi ro.