Vì sao ngân hàng cần lồng ghép Zero Trust và Defense in Depth trong thực tế

Khái niệm, cách lồng ghép và đánh giá hiệu lực trong ngân hàng

NGHIÊN CỨU & ỨNG DỤNG · BÀI 04 · ODIN LAB

Một ngân hàng có tường lửa, phân vùng mạng, bảo vệ thiết bị, giám sát và sao lưu có cần triển khai Zero Trust nữa không? Nếu triển khai, những lớp bảo vệ hiện có sẽ được giữ lại, thay đổi hay thay thế? Đây là câu hỏi về cách thiết kế và vận hành kiểm soát, trước khi là câu hỏi về lựa chọn sản phẩm.

Quan điểm của Odin Lab là tiếp tục xây dựng phòng thủ nhiều lớp, đồng thời dùng Zero Trust để xem lại những giả định về tin cậy và cách cấp quyền. Hai hướng có thể lồng ghép, nhưng sự kết hợp phải thể hiện bằng chính sách, cơ chế thực thi và bằng chứng kiểm tra. Chỉ thêm một công cụ mang nhãn Zero Trust chưa đủ.

Bài viết tham khảo NIST và CISA và tình huống Odin Lab Bank hoàn toàn giả lập để đánh giá ứng dụng. Những thiết kế và tiêu chí thử dưới đây là đề xuất của Odin Lab, không mô tả cấu hình, sự cố hoặc kết quả của một ngân hàng thực tế.

Hiểu đúng hai khái niệm trước khi so sánh

Defense in depth, gọi là phòng thủ nhiều lớp, là chiến lược kết hợp con người, công nghệ và vận hành để tạo nhiều hàng rào bảo vệ. Một lớp có thể bỏ sót hoặc thất bại; các lớp khác giúp ngăn chặn, phát hiện và hạn chế tác động. Khái niệm này rộng hơn việc đặt nhiều thiết bị trên đường kết nối mạng. [1]

Zero Trust chuyển trọng tâm sang việc kiểm tra điều kiện truy cập tài nguyên, thay vì mặc định tin cậy vì người dùng hoặc thiết bị nằm trong mạng nội bộ. NIST SP 800-207 mô tả cả nguyên tắc lẫn các thành phần quyết định, quản lý và thực thi chính sách. Vì vậy, Zero Trust có chiều tư duy và chiều kiến trúc triển khai. [2]

Trong bài trình bày của Ron Ross đăng trên NIST, Zero Trust được đặt trong chiến lược phòng thủ nhiều chiều, nhằm tăng khả năng chống xâm nhập, hạn chế thiệt hại và duy trì khả năng chống chịu. Đây là cơ sở để xem xét sự bổ trợ, thay vì chỉ đối chiếu hai nhãn “mới” và “truyền thống”. [3]

Từ đó, Odin Lab đề xuất chỉnh cách diễn đạt: defense in depth là nguyên tắc tổ chức nhiều lớp kiểm soát, không phải một kiến trúc cố định; Zero Trust là hệ nguyên tắc về tin cậy và truy cập, được hiện thực hóa thành kiến trúc và vận hành. Khi áp dụng ZT, tổ chức có thể thiết kế lại một số luồng truy cập, đồng thời tiếp tục cần những lớp bảo vệ khác.

Trụ cột Zero Trust và các lớp phòng thủ

Để hình dung phạm vi triển khai Zero Trust, bài viết tham khảo mô hình trưởng thành CISA ZTMM 2.0 với năm trụ cột: danh tính, thiết bị, mạng, ứng dụng và workload, dữ liệu. Ba năng lực xuyên suốt gồm quan sát và phân tích, tự động hóa và điều phối, quản trị. Đây là một mô hình tham khảo, không phải cách phân chia duy nhất của mọi khung Zero Trust. [6]

Với Defense in Depth, Odin Lab minh họa các lớp vật lý, mạng, thiết bị, ứng dụng và dữ liệu, cùng nền tảng con người, quy trình, giám sát, ứng phó và phục hồi. Số lớp và cách bố trí phụ thuộc hệ thống và rủi ro; không nên ánh xạ một trụ cột ZT với một lớp phòng thủ duy nhất.

Điểm khác biệt và phần giao nhau

Bảng dưới đây là cách phân tích của Odin Lab để phục vụ thiết kế, không phải bảng phân loại do NIST ban hành. Hai hướng có phần giao nhau: một kiểm soát có thể vừa tạo lớp phòng thủ, vừa thực thi chính sách Zero Trust.

Một tường lửa có thể tạo hàng rào mạng và thực thi giới hạn kết nối trong thiết kế ZT. Hệ thống bảo vệ thiết bị có thể ngăn mã độc, đồng thời cung cấp tín hiệu cho chính sách truy cập. Tuy nhiên, vai trò thứ hai chỉ có hiệu lực khi dữ liệu được tích hợp, chính sách đọc đúng dữ liệu và điểm thực thi áp dụng đúng quyết định.

Tương tự, phân vùng mạng giúp giới hạn đường đi giữa các hệ thống, nhưng chưa tự chứng minh quyền ở mức người dùng hoặc thao tác nghiệp vụ. Một người đã kết nối đúng máy chủ vẫn có thể bị cấp quyền ứng dụng quá rộng. Việc kết hợp cần kiểm tra cả đường kết nối và hành động được phép sau khi kết nối.

Vì sao Zero Trust không làm các lớp bảo vệ khác mất giá trị

Odin Lab đánh giá rằng một quyết định truy cập đúng chưa đủ để xử lý mọi rủi ro. Ứng dụng có thể còn lỗi; thiết bị được cấp quyền vẫn có thể bị khai thác; người dùng hợp lệ có thể thực hiện sai thao tác. Vì vậy, quản lý lỗ hổng, cấu hình an toàn, bảo vệ ứng dụng và dữ liệu, giám sát, ứng phó cùng phục hồi vẫn cần được thiết kế theo rủi ro.

Ví dụ, chỉ cho phép đúng người truy cập một ứng dụng không thay thế được việc vá lỗi của ứng dụng đó. Khi tài khoản bị chiếm dụng, giới hạn truy cập giúp giảm phạm vi tiếp cận, nhưng vẫn cần phát hiện hành vi bất thường và điều tra. Nếu dữ liệu bị phá hoại trong phạm vi tài khoản đang có quyền, khả năng khôi phục không thể được chứng minh bằng chính sách truy cập.

Ngược lại, nhiều lớp được xây dựng trên cùng một giả định sai có thể thất bại cùng lúc. Nếu hàng loạt hệ thống đều coi một tài khoản quản trị là đáng tin và không kiểm tra lại phạm vi quyền, việc có nhiều thiết bị bảo mật chưa giải quyết được rủi ro đó. Khi đánh giá defense in depth, cần tìm cả điểm yếu chung giữa các lớp.

Zero Trust giúp đặt lại câu hỏi về những giả định ấy. Nhưng nó cũng không bảo đảm tuyệt đối: dữ liệu đầu vào sai hoặc chính sách cấp quá rộng có thể dẫn đến quyết định sai. Sự bổ trợ có giá trị khi các lớp được thiết kế để hạn chế những kiểu thất bại khác nhau và được vận hành nhất quán.

Một tình huống OLB cho thấy cách lồng ghép

Giả sử OLB cho phép nhân viên vận hành truy cập cổng xử lý phiếu từ ngoài văn phòng. Nhân viên cần đọc phiếu và cập nhật tiến độ; việc đó không đòi hỏi quyền quản trị hạ tầng. Mục tiêu là làm việc từ xa thuận tiện mà không mở rộng khả năng tiếp cận hệ thống hoặc dữ liệu ngoài nhiệm vụ.

OLB đã có các lớp bảo vệ giả lập: giới hạn kết nối mạng, cấu hình thiết bị, bảo vệ đầu cuối, phân quyền ứng dụng và ghi nhật ký. Điểm cần đánh giá là liệu một lần đăng nhập thành công có đang được dùng làm căn cứ cho quyền truy cập quá rộng hoặc kéo dài quá lâu hay không.

Bổ sung điều kiện tin cậy vào luồng truy cập

Trong thiết kế đề xuất, yêu cầu truy cập được đối chiếu với danh tính, vai trò, trạng thái thiết bị và tài nguyên cần dùng. Chỉ thiết bị đáp ứng điều kiện đã thống nhất được vào cổng xử lý phiếu. Quyền trong ứng dụng giới hạn ở nhiệm vụ được giao. Điều kiện phải nêu rõ, chẳng hạn thiết bị có trong danh mục quản lý và tín hiệu bảo vệ còn hiệu lực, thay vì chỉ ghi chung là “thiết bị an toàn”.

Khi thiết bị xuất hiện tín hiệu không đáp ứng chính sách, tổ chức cần xác định hành động tương ứng: chặn truy cập mới, yêu cầu kiểm tra bổ sung hoặc chấm dứt phiên thuộc phạm vi có thể kiểm soát. Mỗi hành động phải được thử trên công nghệ thực tế. Không thể mặc định rằng mọi ứng dụng đều hỗ trợ thu hồi phiên ngay sau khi điều kiện thay đổi.

Việc đánh giá lại không đồng nghĩa liên tục yêu cầu người dùng nhập mật khẩu. OLB đề xuất dùng tín hiệu và sự kiện theo mức rủi ro của luồng, đồng thời xác định tuổi dữ liệu tối đa có thể chấp nhận. Một trạng thái thiết bị tốt ghi nhận từ lâu không tự chứng minh thiết bị còn đáp ứng chính sách ở thời điểm hiện tại.

Giữ những lớp xử lý rủi ro còn lại

Bảo vệ đầu cuối vẫn có nhiệm vụ ngăn hoặc phát hiện mã độc. Phân vùng vẫn giới hạn kết nối ngoài nhu cầu. Ứng dụng vẫn cần kiểm tra quyền trên thao tác và dữ liệu. Giám sát vẫn cần nối dấu vết đăng nhập với hoạt động trong phiên. Khôi phục vẫn cần thử riêng cho dữ liệu và dịch vụ. ZT đưa điều kiện truy cập vào luồng này; các lớp còn lại xử lý những rủi ro mà quyết định truy cập chưa bao phủ.

Ví dụ thử giả lập: một nhân viên đăng nhập đúng danh tính nhưng từ thiết bị ngoài phạm vi quản lý. Kỳ vọng thiết kế là yêu cầu không được vào ứng dụng chỉ vì thông tin đăng nhập đúng. Trong một phép thử khác, nhân viên dùng thiết bị phù hợp nhưng yêu cầu chức năng quản trị ngoài vai trò; ứng dụng vẫn phải từ chối. Hai phép thử đánh giá các ranh giới khác nhau, không thay thế nhau.

Áp dụng vào những môi trường khác nhau

Không có một tổ hợp công nghệ duy nhất phù hợp mọi môi trường. Một số luồng có thể tiếp tục dùng VPN với phạm vi hẹp và điều kiện bổ sung; luồng khác có thể chuyển sang truy cập theo ứng dụng. Quyết định nên dựa vào rủi ro, khả năng tích hợp, trải nghiệm và bằng chứng kiểm thử, không chỉ dựa vào tên công nghệ.

Đánh giá triển khai bằng hiệu lực thay vì số lượng công cụ

NIST SP 1800-35, công bố bản cuối tháng 6/2025, cung cấp các ví dụ triển khai ZTA trong phòng thử nghiệm và bài học tích hợp. Các ví dụ là tài liệu tham khảo để thiết kế, không chứng minh hệ thống của một tổ chức đã đạt cùng hiệu lực. [4] Odin Lab đề xuất đánh giá theo từng luồng truy cập quan trọng, theo chuỗi mục tiêu – rủi ro – kiểm soát – bằng chứng – trách nhiệm – quyết định.

Mục tiêu và rủi ro cần giải quyết

Xác định dịch vụ, nhiệm vụ và dữ liệu cần bảo vệ; sau đó mô tả tình huống có thể gây thiệt hại. Ví dụ: tài khoản bị chiếm dụng từ thiết bị ngoài kiểm soát hoặc quyền vận hành cho phép tác động sang vùng quản trị. Cần phân biệt mục tiêu giảm rủi ro với mục tiêu triển khai một sản phẩm mới.

Kiểm soát và nơi thực thi

Chỉ ra điều kiện được kiểm tra, tín hiệu dùng để kiểm tra và điểm có thể cho phép hoặc chặn. Hồ sơ phải thể hiện cả đường truy cập thay thế. Nếu cổng chính kiểm tra thiết bị nhưng còn đường trực tiếp vào ứng dụng không qua kiểm tra, phạm vi bảo vệ thực tế chưa khớp thiết kế.

Bằng chứng về tác dụng và giới hạn

Giữ phiên bản chính sách, cấu hình liên quan và kết quả thử cho trường hợp được phép, bị từ chối, thay đổi điều kiện và mất tín hiệu. Nối nhật ký quyết định với phiên hoặc hành động để truy vết được. Bằng chứng cũng cần cho biết việc chặn có đến đúng tài nguyên, thu hồi quyền có thực sự có hiệu lực và phần nào chưa thể kiểm tra.

Trách nhiệm và quyết định

Chủ dịch vụ xác định mục tiêu và tác động vận hành. Đội danh tính, thiết bị, mạng và ứng dụng chịu trách nhiệm ở phần thực thi của mình. An toàn thông tin cùng quản lý rủi ro rà soát hiệu lực và phần chưa xác minh. Chủ dịch vụ quyết định trong thẩm quyền; ngoại lệ vượt thẩm quyền phải trình người có quyền chấp nhận rủi ro. Người đánh giá độc lập kiểm tra bằng chứng thay vì chỉ nhận báo cáo hoàn thành.

Theo đề xuất của Odin Lab, nghiệm thu một luồng cần có yêu cầu hợp lệ hoạt động được, yêu cầu ngoài phạm vi bị xử lý đúng, các đường truy cập đã được rà soát và tình huống mất thành phần trọng yếu có phương án được thử. Chỉ số thời gian phát hiện, thời gian thu hồi quyền, tỷ lệ tín hiệu thiết bị còn hiệu lực và gián đoạn do chính sách cần có định nghĩa, phạm vi và ngưỡng riêng. Bài viết không đặt một ngưỡng chung cho mọi ngân hàng.

Kiểm soát chặt hơn cũng phải vận hành được khi có sự cố

NIST SP 800-207 nêu các rủi ro đối với thành phần ra quyết định và quản lý chính sách. [2] Trong thiết kế OLB, phụ thuộc vào dịch vụ danh tính, dữ liệu thiết bị, chứng thư hoặc cổng truy cập vì vậy phải được xem xét cùng yêu cầu sẵn sàng. Chính sách tốt trên giấy có thể làm gián đoạn công việc nếu mất tín hiệu bị xử lý không phù hợp.

Tổ chức cần quyết định trước hành vi khi một thành phần không khả dụng, theo từng loại truy cập. Không nên mặc định mở toàn bộ để duy trì hoạt động; cũng không thể áp một cách chặn duy nhất mà bỏ qua nhu cầu xử lý sự cố. Quyền khẩn cấp đề xuất phải có phạm vi, thời hạn, người phê duyệt, dấu vết sử dụng và rà soát sau đó. Nếu thành phần xác thực lỗi, cần có cơ chế đã được chuẩn bị và thử để tiếp cận phần phục hồi cần thiết.

Trong diễn tập DR giả lập, OLB không chỉ kiểm tra ứng dụng hoạt động ở site dự phòng. Đội thử cần kiểm tra người có nhiệm vụ có thể truy cập đúng tài nguyên, thiết bị không đáp ứng bị xử lý đúng và quyền khẩn cấp kết thúc đúng hạn. Chuyển đổi dịch vụ thành công nhưng không thể thực thi quyền phù hợp vẫn là một khoảng trống vận hành.

Triển khai từng bước và đánh giá lại sau thay đổi

NIST SP 800-207 cho phép xem xét sự cùng tồn tại của luồng ZTA và luồng chưa theo ZTA, với quá trình chuyển đổi theo từng nghiệp vụ. [2] Odin Lab đề xuất bắt đầu từ một luồng có rủi ro rõ, chủ dịch vụ rõ và khả năng kiểm tra tốt. Khảo sát tài sản, danh tính, dữ liệu, phụ thuộc và kiểm soát hiện có trước khi thiết kế phần bổ sung.

Sau đó, xác định chính sách và điều kiện bằng chứng, thử trong phạm vi hẹp rồi mới mở rộng. Phần hệ thống cũ chưa chuyển đổi cần được quản lý như khoảng trống có người chịu trách nhiệm, không chỉ ghi rằng sẽ xử lý ở giai đoạn sau. Khi thay đổi ứng dụng, quyền, nhà cung cấp hoặc đường kết nối, cần xem lại phạm vi và hiệu lực của thiết kế kết hợp.

Thông báo NSA ngày 08/10/2026 về bảo vệ OT cũng mô tả việc áp dụng nguyên tắc ZT để tăng cường defense in depth. Nguồn này đề cập môi trường OT và quốc phòng; bài viết chỉ sử dụng như một ví dụ về sự bổ trợ, không chuyển nguyên xi yêu cầu sang ngân hàng. [5]

Kết luận của Odin Lab

Trong bối cảnh làm việc linh hoạt, tài nguyên phân tán và kết nối đối tác, phòng thủ nhiều lớp vẫn là nguyên tắc hữu ích để tổ chức các kiểm soát bổ trợ. Zero Trust giúp kiểm tra lại những giả định về tin cậy và làm rõ điều kiện truy cập ở từng luồng. Để tạo tác dụng, tư duy đó phải đi vào kiến trúc, chính sách và vận hành.

Quan điểm lồng ghép có ý nghĩa thực tế khi trả lời được ba câu hỏi: quyền truy cập đã được quyết định dựa trên điều kiện nào; nếu một kiểm soát thất bại thì lớp nào tiếp tục hạn chế tác động; và bằng chứng nào cho thấy cả hai hoạt động như thiết kế. Đó là cơ sở để quyết định giữ lại, nâng cấp, thay thế hay bổ sung một kiểm soát.

Nguồn tham khảo

[1] NIST CSRC Glossary. Defense-in-depth. Tổng hợp định nghĩa từ các tài liệu NIST; sử dụng để làm rõ phạm vi khái niệm. Đối chiếu 13/10/2026.

Định nghĩa phòng thủ nhiều lớp tại NIST

[2] Rose, Borchert, Mitchell, Connelly. NIST SP 800-207, Zero Trust Architecture, tháng 8/2020. Tham khảo mục 2–3 về nguyên tắc và thành phần; mục 5 về rủi ro; mục 7 về chuyển đổi. DOI 10.6028/NIST.SP.800-207.

Đọc NIST SP 800-207

[3] Ron Ross. When Perimeter Defenses Are Not Enough: How Multidimensional Protection Strategies Can Provide True Cyber Defense-in-Depth. Bài trình bày đăng trên NIST, 21/04/2020. Nguồn quan điểm kỹ thuật, không phải tiêu chuẩn riêng.

Đọc bài trình bày về ZT và defense in depth

[4] NIST SP 1800-35. Implementing a Zero Trust Architecture, bản cuối 10/06/2025. Tài liệu thực hành và ví dụ phòng thử nghiệm. DOI 10.6028/NIST.SP.1800-35.

Đọc hướng dẫn triển khai ZTA

[5] NSA. NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems, 08/10/2026. Tham khảo phạm vi và quan điểm bổ trợ; không sử dụng làm căn cứ tuân thủ cho ngân hàng.

Đọc thông báo NSA về ZT trong môi trường OT

[6] CISA. Zero Trust Maturity Model Version 2.0, tháng 4/2023. Nguồn về năm trụ cột và ba năng lực xuyên suốt; diễn giải khái niệm trong hình do Odin Lab thực hiện.

Đọc CISA Zero Trust Maturity Model 2.0

[6] CISA. Zero Trust Maturity Model Version 2.0, tháng 4/2023. Nguồn về năm trụ cột và ba năng lực xuyên suốt; diễn giải khái niệm trong hình do Odin Lab thực hiện.

Đọc CISA Zero Trust Maturity Model 2.0

Đọc tiếp tại Odin Lab

Bài tiếp theo: Sao lưu thành công, ngân hàng đã sẵn sàng phục hồi sau tấn công mạng?

Bài 03 Nhà cung cấp bổ sung AI Ngân hàng cần đánh giá gì trước khi sử dụng

Chuyên mục Nghiên cứu và Ứng dụng

Insights · Odin Lab Bank