Zero trust architecture dưới góc nhìn của một appsec engineer

Với một AppSec engineer, Zero Trust không nên được hiểu như một bộ công cụ mua về rồi triển khai rời rạc. Nó là cách tổ chức lại logic tin cậy của toàn hệ thống. Trong mô hình cũ, nhiều quyết định truy cập được nới lỏng chỉ vì request đi từ mạng nội bộ hoặc từ một vị trí quen thuộc. Cách làm đó từng phù hợp khi hệ thống còn tập trung trong trung tâm dữ liệu nội bộ và phần lớn người dùng làm việc trong cùng một môi trường mạng. Nhưng khi cloud, thiết bị di động, làm việc từ xa, microservices và API first trở thành trạng thái bình thường, vị trí mạng không còn đủ mạnh để đại diện cho niềm tin nữa. Từ đây, câu hỏi kiến trúc không còn là request đi từ đâu, mà là request này có đủ điều kiện để được chấp nhận hay không.

Bảng dưới đây cho thấy sự khác nhau giữa cách tiếp cận perimeter truyền thống và cách tiếp cận Zero Trust. Điểm quan trọng nhất là trust không còn gắn sẵn với một vùng mạng, mà trở thành kết quả của một quá trình đánh giá.

Từ góc nhìn AppSec, thay đổi lớn nhất nằm ở chỗ trust không còn là thuộc tính gắn sẵn cho một vùng mạng. Trust trở thành kết quả của một quá trình đánh giá. Điều đó buộc kiến trúc phải chuyển từ câu hỏi request này đến từ đâu sang câu hỏi request này có đủ điều kiện để được cho phép hay không.

1. Ba giả định nền tảng của Zero Trust dưới góc nhìn thiết kế 

Zero Trust không bắt đầu từ công cụ. Nó bắt đầu từ ba giả định nền tảng. Mỗi giả định kéo theo một kiểu câu hỏi thiết kế khác nhau. Khi đưa ba giả định này vào kiến trúc, đội phát triển buộc phải viết lại rất nhiều thói quen cũ. Không còn chuyện đã login thì được tin trong suốt phiên. Không còn chuyện service ở cùng cụm thì gọi nhau tự do. Cũng không còn chuyện mạng nội bộ được miễn nhiều kiểm tra mà request bên ngoài phải chịu.

2. Những thành phần kiến trúc mà AppSec designer phải nhìn thấy 

Một thiết kế Zero Trust chín muồi luôn làm rõ bốn điều. Nơi nào ra quyết định. Nơi nào thực thi quyết định. Tín hiệu nào tạo ra trust. Dấu vết nào được giữ lại để phục vụ audit. Nếu không làm rõ bốn điểm này, policy sẽ bị rải trong controller, gateway, service, script vận hành và cấu hình hạ tầng. Hậu quả là hệ thống mất tính nhất quán, khó kiểm thử và càng khó audit. Vì vậy, ở góc độ AppSec, Zero Trust là một kiến trúc có phân vai rõ ràng, không phải một tập rule rời rạc.

3. Identity là perimeter mới, nhưng không phải login là đủ

Trong môi trường hiện đại, identity trở thành trung tâm của quyết định truy cập. Nhưng identity ở đây không chỉ là tài khoản người dùng. Nó còn gồm machine identity, workload identity, privileged identity và toàn bộ vòng đời của credential. Nhiều hệ thống nói rằng đã có xác thực mạnh, nhưng thực tế chỉ mạnh ở bước login ban đầu. Sau đó, các request downstream lại quay về tin theo network position hoặc shared token. Đây là điểm mà AppSec engineer cần nhìn rất kỹ, vì nếu identity chỉ mạnh ở cửa vào nhưng yếu ở toàn bộ đường đi phía sau thì kiến trúc vẫn còn trust sai chỗ.

4. Dữ liệu là mục tiêu cuối cùng của trust decision 

Zero Trust không nên dừng ở API hay network flow. Đích cuối cùng của mọi quyết định trust luôn là dữ liệu, trạng thái nghiệp vụ hoặc khả năng điều khiển hệ thống. Vì vậy, AppSec engineer không thể chỉ nhìn tài nguyên dưới dạng server hay subnet. Cần nhìn theo data, application, service và business flow. Khi chuyển sang cách nhìn này, policy cũng thay đổi. Nó không còn là policy của hạ tầng đơn thuần, mà trở thành policy gắn trực tiếp với giá trị thật mà hệ thống đang bảo vệ.

5. Không có một biến thể Zero Trust duy nhất 

Zero Trust có thể được triển khai theo nhiều hướng khác nhau. Có tổ chức đi từ identity. Có tổ chức đi từ micro segmentation. Có nơi bắt đầu bằng việc thay VPN bằng ZTNA. Điều quan trọng không phải là chọn một nhãn kiến trúc thời thượng, mà là hiểu biến thể nào đang giúp xử lý đúng trust assumption sai của tổ chức mình. Đây là điểm rất thực tế dưới góc nhìn AppSec, vì thiết kế tốt luôn phải xuất phát từ điểm gãy thực sự của kiến trúc đang tồn tại.

6. Lộ trình triển khai phải đi từ trust foundation tới observability 

Một kiến trúc Zero Trust khó có thể triển khai trọn vẹn toàn bộ ngay một lần. Cách đi hiệu quả hơn là theo từng lớp, từ nền danh tính đến thực thi, rồi tới quan sát và cải tiến. Điều này phù hợp với cách một AppSec designer làm việc, vì thiết kế tốt thường được xây theo dependency order chứ không phải gom tất cả control vào cùng lúc.

Một lộ trình như vậy giúp hệ thống tránh hai thái cực. Một là làm quá ít, ví dụ: mới triển khai thêm MFA rồi tự cho rằng đã có Zero Trust. Hai là làm quá nhiều cùng lúc, khiến policy chồng chéo, công cụ rời rạc và vận hành không theo kịp.

7. Case study ngân hàng số dưới góc nhìn AppSec designer

Trong môi trường tài chính số, ba điểm gãy rất thường gặp là human access quá rộng, workload identity yếu, và East West traffic gần như không quan sát được. Khi nhìn dưới view của AppSec, đây không chỉ là vấn đề công nghệ. Đây là ba trust assumption sai đã tồn tại trong kiến trúc.

Khi ba vấn đề này được nhìn thành ba trust gap, lộ trình xử lý cũng trở nên rõ ràng hơn. Tổ chức phải sửa niềm tin ở người dùng, rồi sửa niềm tin ở service, rồi mới hoàn thiện khả năng quan sát để policy sống được lâu dài trong vận hành.  Một kiến trúc điển hình sau khi hoàn thiện có thể được nhìn như sau:

Đây là cách kiến trúc chuyển từ trust by location sang trust by evaluated context. Điểm quan trọng là các thành phần này không tồn tại riêng lẻ. Chúng tham gia vào cùng một chuỗi quyết định truy cập. 

8. Minh họa

Khi implementation, Zero Trust chỉ thật sự có ý nghĩa khi các nguyên tắc thiết kế được chuyển thành cấu trúc kỹ thuật rõ ràng. Chuỗi minh này đi từ request context, sang trust score, tới policy engine, access decision, enforcement filter và unit test. Với AppSec designer, đây là một chuỗi rất đúng logic vì nó biến trust decision thành một lớp thiết kế kiểm chứng được.

Mọi thứ bắt đầu từ request context.

</> Java
// ZeroTrustContext.java
package com.vietsecure.zt.model;
 
import java.time.Instant;
import java.util.List;
import java.util.Map;
 
public record ZeroTrustContext(
    String subjectId,
    String subjectType,
    List<String> roles,
    Map<String, String> attrs,
    String deviceId,
    boolean deviceManaged,
    boolean edpHealthy,
    String deviceCertThumbprint,
    int patchLevelScore,
    String sourceIp,
    String networkZone,
    boolean tlsVerified,
    String resourceId,
    String action,
    Instant requestTime,
    double riskScore
) {}

Ở đây, request không chỉ gồm user và URI. Nó mang theo identity, device posture, network zone, TLS state, resource, action và risk score. Điều này phản ánh đúng suy nghĩ của Zero Trust. Không có decision tốt nếu đầu vào nghèo ngữ cảnh.

Tiếp đó là trust score engine.

</> Java
// TrustScoreEngine.java
package com.vietsecure.zt.engine;
 
import com.vietsecure.zt.model.ZeroTrustContext;
 
public class TrustScoreEngine {
 
    private static final double W_DEVICE_MANAGED    = 0.25;
    private static final double W_DEVICE_HEALTH     = 0.20;
    private static final double W_DEVICE_PATCH      = 0.15;
    private static final double W_NETWORK_ZONE      = 0.20;
    private static final double W_TLS_VERIFIED      = 0.10;
    private static final double W_BEHAVIOR_PENALTY  = 0.10;
 
    public TrustScore compute(ZeroTrustContext ctx) {
        double score = 0.0;
        StringBuilder rationale = new StringBuilder();
 
        if (ctx.deviceManaged()) {
            score += W_DEVICE_MANAGED;
           rationale.append("[+] Device enrolled in MDM. ");
        } else {
           rationale.append("[-] Unmanaged device. ");
        }
 
        if (ctx.edpHealthy()) {
            score += W_DEVICE_HEALTH;
           rationale.append("[+] EDR healthy. ");
        } else {
           rationale.append("[-] EDR unhealthy or absent. ");
        }
 
        double patchContrib = (ctx.patchLevelScore() / 100.0) * W_DEVICE_PATCH;
        score += patchContrib;
       rationale.append(String.format("[patch=%.0f%%] ", ctx.patchLevelScore() * 1.0));
 
        double networkScore = switch (ctx.networkZone()) {
            case "corporate" -> W_NETWORK_ZONE;
            case "remote"    -> W_NETWORK_ZONE * 0.7;
            case "public"    -> W_NETWORK_ZONE * 0.3;
           default          -> 0.0;
        };
        score += networkScore;
       rationale.append(String.format("[zone=%s] ", ctx.networkZone()));
 
        if (ctx.tlsVerified()) {
            score += W_TLS_VERIFIED;
        } else {
            score = 0.0;
           rationale.append("[FATAL] TLS not verified. ");
            return new TrustScore(0.0, rationale.toString(), TrustLevel.DENIED);
        }
 
        double behaviorPenalty = ctx.riskScore() * W_BEHAVIOR_PENALTY;
        score = Math.max(0.0, score - behaviorPenalty);
       rationale.append(String.format("[riskPenalty=%.2f] ", behaviorPenalty));
 
        TrustLevel level = classifyLevel(score);
        return new TrustScore(score, rationale.toString(), level);
    }
 
    private TrustLevel classifyLevel(double score) {
        if (score >= 0.75) return TrustLevel.HIGH;
        if (score >= 0.50) return TrustLevel.MEDIUM;
        if (score >= 0.25) return TrustLevel.LOW;
        return TrustLevel.DENIED;
    }
 
    public record TrustScore(double value, String rationale, TrustLevel level) {}
 
    public enum TrustLevel { HIGH, MEDIUM, LOW, DENIED }
}

Thiết kế này cho thấy trust không phải là một bit bật tắt. Nó là kết quả tổng hợp từ nhiều tín hiệu, trong đó có điều kiện cứng như TLS và điều kiện mềm như behavior risk. Chính sự phân biệt này làm cho policy bớt ngây thơ hơn trước attacker.  Phần tiếp theo là policy engine, nơi thực sự ra quyết định.

</> Java
// ZeroTrustPolicyEngine.java
package com.vietsecure.zt.engine;
 
import com.vietsecure.zt.model.ZeroTrustContext;
import com.vietsecure.zt.engine.TrustScoreEngine.TrustLevel;
import java.time.LocalTime;
import java.util.Set;
 
public class ZeroTrustPolicyEngine {
 
    private final TrustScoreEngine trustEngine = new TrustScoreEngine();
 
    private static final Set<String> CRITICAL_RESOURCES = Set.of(
       "payment-service", "core-banking", "kyc-service", "admin-console"
    );
 
    private static final LocalTime BIZ_START = LocalTime.of(7, 0);
    private static final LocalTime BIZ_END   = LocalTime.of(22, 0);
 
    public AccessDecision evaluate(ZeroTrustContext ctx) {
        var trustScore = trustEngine.compute(ctx);
 
        if (trustScore.level() == TrustLevel.DENIED) {
            return AccessDecision.deny(
               "Trust score below minimum threshold: " + trustScore.rationale());
        }
 
        if (CRITICAL_RESOURCES.contains(ctx.resourceId())) {
            return evaluateCriticalAccess(ctx, trustScore);
        }
 
        return evaluateStandardAccess(ctx, trustScore);
    }
 
    private AccessDecision evaluateCriticalAccess(
           ZeroTrustContext ctx,
           TrustScoreEngine.TrustScore trustScore) {
 
        if (trustScore.level() != TrustLevel.HIGH) {
            if (trustScore.level() == TrustLevel.MEDIUM && ctx.deviceManaged()) {
                return AccessDecision.challenge(
                   "STEP_UP_MFA",
                   "Critical resource requires step-up authentication.");
            }
            return AccessDecision.deny(
               "Insufficient trust for critical resource: score=" + trustScore.value());
        }
 
        if (!isReadAction(ctx.action())) {
            LocalTime now = LocalTime.from(ctx.requestTime().atZone(
               java.time.ZoneId.of("Asia/Ho_Chi_Minh")));
            if (now.isBefore(BIZ_START) || now.isAfter(BIZ_END)) {
                return AccessDecision.deny(
                   "Write operations on critical resources only allowed during business hours.");
            }
        }
 
        return AccessDecision.allow(trustScore.value());
    }
 
    private AccessDecision evaluateStandardAccess(
           ZeroTrustContext ctx,
           TrustScoreEngine.TrustScore trustScore) {
 
        if (trustScore.level() == TrustLevel.LOW) {
            if (!isReadAction(ctx.action()) || !ctx.deviceManaged()) {
                return AccessDecision.deny(
                   "Low trust: only managed device read access permitted.");
            }
        }
 
        if ("admin".equals(ctx.action()) && trustScore.level() != TrustLevel.HIGH) {
            return AccessDecision.deny(
               "Admin actions require HIGH trust level.");
        }
 
        return AccessDecision.allow(trustScore.value());
    }
 
    private boolean isReadAction(String action) {
        return "read".equals(action) || "list".equals(action);
    }
}

Ở đây, tài nguyên quan trọng cần trust cao hơn. Trạng thái trung bình có thể dẫn tới challenge thay vì cho phép ngay. Thao tác nhạy cảm còn có thể bị ràng buộc theo thời gian. Đây là cách policy trở thành logic kiến trúc rõ ràng chứ không bị nhúng rải rác vào business code.  Outcome của policy cần được mô hình hóa rõ.

</> Java
// AccessDecision.java
package com.vietsecure.zt.engine;
 
public record AccessDecision(
    Outcome outcome,
    String challengeType,
    String reason,
    double trustScore
) {
    public enum Outcome { ALLOW, CHALLENGE, DENY }
 
    public static AccessDecision allow(double trustScore) {
        return new AccessDecision(Outcome.ALLOW, null, "Access granted", trustScore);
    }
 
    public static AccessDecision challenge(String challengeType, String reason) {
        return new AccessDecision(Outcome.CHALLENGE, challengeType, reason, 0);
    }
 
    public static AccessDecision deny(String reason) {
        return new AccessDecision(Outcome.DENY, null, reason, 0);
    }
 
    public boolean isAllowed() { return outcome == Outcome.ALLOW; }
    public boolean requiresChallenge() { return outcome == Outcome.CHALLENGE; }
}

Cách thiết kế này rất quan trọng vì nó thừa nhận challenge là một outcome chính thức, không phải xử lý ngoại lệ tùy hứng. Điều đó giúp hệ thống phản ứng tinh hơn với rủi ro đang thay đổi. 

Sau cùng là enforcement filter.

</> Java
// ZeroTrustEnforcementFilter.java
package com.vietsecure.zt.security;
 
import com.vietsecure.zt.engine.AccessDecision;
import com.vietsecure.zt.engine.ZeroTrustPolicyEngine;
import com.vietsecure.zt.model.ZeroTrustContext;
import jakarta.servlet.*;
import jakarta.servlet.http.*;
import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;
import java.io.IOException;
import java.time.Instant;
 
@Component
@Order(1)
public class ZeroTrustEnforcementFilter implements Filter {
 
    private final ZeroTrustPolicyEngine policyEngine;
    private final DevicePostureService deviceService;
    private final JwtContextExtractor jwtExtractor;
    private final AuditLogger auditLogger;
 
    public ZeroTrustEnforcementFilter(ZeroTrustPolicyEngine pe,
           DevicePostureService dps, JwtContextExtractor je, AuditLogger al) {
       this.policyEngine = pe;
       this.deviceService = dps;
       this.jwtExtractor = je;
       this.auditLogger = al;
    }
 
    @Override
    public void doFilter(ServletRequest req, ServletResponse res,
                        FilterChain chain) throws IOException, ServletException {
        var request  = (HttpServletRequest) req;
        var response = (HttpServletResponse) res;
 
       ZeroTrustContext ctx = buildContext(request);
        AccessDecision decision = policyEngine.evaluate(ctx);
       auditLogger.log(ctx, decision);
 
        switch (decision.outcome()) {
            case ALLOW -> chain.doFilter(req, res);
 
            case CHALLENGE -> {
               response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
               response.setHeader("X-ZT-Challenge", decision.challengeType());
               response.getWriter().write(
                   "{\"error\":\"step_up_required\",\"challenge\":\""+
                   decision.challengeType()+"\"}");
            }
 
            case DENY -> {
               response.setStatus(HttpServletResponse.SC_FORBIDDEN);
               response.getWriter().write("{\"error\":\"access_denied\"}");
            }
        }
    }
 
    private ZeroTrustContext buildContext(HttpServletRequest req) {
        var jwtClaims  = jwtExtractor.extract(req);
        var deviceInfo = deviceService.getPosture(req.getHeader("X-Device-Id"));
        String zone    = classifyNetworkZone(req.getRemoteAddr());
 
        return new ZeroTrustContext(
           jwtClaims.subject(),
           jwtClaims.subjectType(),
           jwtClaims.roles(),
           jwtClaims.attributes(),
           req.getHeader("X-Device-Id"),
           deviceInfo.managed(),
           deviceInfo.edrHealthy(),
           deviceInfo.certThumbprint(),
           deviceInfo.patchScore(),
           req.getRemoteAddr(),
            zone,
           isRequestTlsVerified(req),
           extractResourceId(req),
           extractAction(req),
           Instant.now(),
           jwtClaims.riskScore()
        );
    }
 
    private String classifyNetworkZone(String ip) {
        if (ip.startsWith("10.") || ip.startsWith("192.168.")) return "corporate";
        if (ip.startsWith("172.")) return "remote";
        return "public";
    }
 
    private boolean isRequestTlsVerified(HttpServletRequest req) {
        return "https".equalsIgnoreCase(req.getHeader("X-Forwarded-Proto"))
               || req.isSecure();
    }
 
    private String extractResourceId(HttpServletRequest req) {
        String path = req.getRequestURI();
        if (path.startsWith("/api/payments")) return "payment-service";
        if (path.startsWith("/api/admin"))   return "admin-console";
        if (path.startsWith("/api/kyc"))     return "kyc-service";
        return "general";
    }
 
    private String extractAction(HttpServletRequest req) {
        return switch (req.getMethod().toUpperCase()) {
            case "GET", "HEAD"   -> "read";
            case "POST"          -> "write";
            case "PUT", "PATCH"  -> "write";
            case "DELETE"        -> "delete";
           default              -> "unknown";
        };
    }
}

Đây là chỗ thiết kế chạm vào thực thi. Request bị chặn trước business logic, policy được gọi tập trung, audit log được sinh ra cho mọi outcome, và thông tin nội bộ không bị lộ quá mức ra client. Đó là cách Zero Trust vận hành như một lớp kiến trúc chứ không chỉ là một tập kiểm tra riêng lẻ.

Ở mức tham chiếu, nhiều framework khác nhau có thể hỗ trợ tổ chức thiết kế lộ trình Zero Trust. Sự khác biệt chính nằm ở mức độ trung lập vendor, tính thực dụng, và độ rõ của roadmap trưởng thành.

Sự lựa chọn đúng không nằm ở việc framework nào nổi tiếng hơn. Nó nằm ở việc framework nào giúp tổ chức trả lời tốt hơn các câu hỏi thiết kế đang mở của mình.

9. Compliance là hệ quả của kiến trúc đúng 

Khi kiến trúc đã kiểm soát tốt segmentation, identity, access control, logging và data protection, rất nhiều yêu cầu compliance sẽ được đáp ứng:

Điều cần nhấn mạnh ở đây là compliance không nên là lý do duy nhất để theo đuổi Zero Trust. Nó nên được xem như hệ quả hợp lý của một kiến trúc ra quyết định truy cập chặt chẽ và kiểm chứng được.

Lời Kết

Dưới góc nhìn của AppSec designer, Zero Trust là việc biến niềm tin thành một quyết định có điều kiện. Không có request nào được tin mặc định. Không có tài nguyên nào được bảo vệ chỉ bằng một lần đăng nhập. Không có service nào được gọi tự do chỉ vì nó đang ở bên trong. Mọi thứ phải quay về context, policy, enforcement, audit và khả năng thu hồi trust khi điều kiện thay đổi. 

Khi được thiết kế đúng, Zero Trust không phải là một lớp phủ bảo mật đặt lên trên hệ thống. Nó trở thành một thuộc tính của chính kiến trúc. Dữ liệu đầu vào cho trust được mô hình hóa rõ ràng. Quy tắc ra quyết định được tách thành lớp riêng. Điểm thực thi được xác định rõ. Và toàn bộ cơ chế đó có thể được audit, test và cải tiến liên tục. Đó là chỗ Zero Trust phù hợp nhất với vai trò của AppSec designer. Không phải vì nó có nhiều công nghệ đi kèm, mà vì nó buộc hệ thống phải thành thật về điều gì đang được tin và vì sao lại được tin như vậy.