mTLS giữa các dịch vụ: Xác thực hai chiều đúng cách

Mã hóa đường truyền chưa đủ để một dịch vụ biết chính xác ai đang gọi mình. Với TLS thông thường, máy khách chủ yếu xác minh máy chủ. Mutual TLS (mTLS) bổ sung chiều ngược lại: máy chủ yêu cầu chứng thư của máy khách, kiểm tra chuỗi tin cậy và bằng chứng sở hữu khóa riêng trước khi chấp nhận kết nối.

mTLS đặc biệt hữu ích cho giao tiếp service-to-service, nơi IP, hostname hay vị trí mạng không còn là danh tính đáng tin cậy. Tuy nhiên, bật tùy chọn “require client certificate” chỉ là bước đầu. Một hệ thống vận hành tốt còn cần mô hình định danh, private CA, cấp phát và xoay vòng tự động, chính sách phân quyền, quan sát được lỗi bắt tay và kế hoạch thay CA không gián đoạn.

1. TLS một chiều, mTLS và token khác nhau thế nào?

Ba lớp này có thể dùng cùng nhau. mTLS xác thực workload A với workload B, còn token có thể cho biết yêu cầu đang đại diện cho người dùng nào và được phép đọc tài nguyên nào. Không nên biến chứng thư máy thành nơi chứa mọi quyền nghiệp vụ.

2. Điều gì xảy ra trong bắt tay mTLS?

Trong TLS 1.3, máy chủ gửi CertificateRequest khi muốn xác thực máy khách bằng chứng thư. Hai phía gửi chứng thư và thông điệp CertificateVerify; chữ ký trong thông điệp này chứng minh endpoint đang giữ khóa riêng tương ứng. Mô tả chuẩn nằm trong RFC 8446.

1. Client kết nối và đề xuất phiên bản TLS, thuật toán cùng các tham số cần thiết.
2. Server gửi chứng thư để client xác minh danh tính server.
3. Server yêu cầu chứng thư client và cho biết các tham số chấp nhận.
4. Client gửi chuỗi chứng thư, rồi ký transcript của phiên bắt tay bằng khóa riêng.
5. Mỗi phía kiểm tra chữ ký, thời hạn, chuỗi CA, mục đích sử dụng và danh tính mong đợi.
6. Chỉ sau khi các kiểm tra đạt yêu cầu, ứng dụng mới xử lý dữ liệu trên kênh đã mã hóa.

Chứng thư công khai có thể được gửi qua mạng; khóa riêng thì không. Nếu một quy trình “triển khai mTLS” yêu cầu sao chép cùng một khóa riêng cho nhiều dịch vụ, mô hình danh tính đã bị phá vỡ.

3. Thiết kế danh tính trước khi cấp chứng thư

Danh tính nên ổn định theo workload hoặc vai trò dịch vụ, không theo IP của pod, tên máy tạm thời hay tên nhân viên. Hãy định nghĩa một namespace rõ ràng, chẳng hạn theo môi trường, trust domain và service account. Giá trị này phải được mã hóa vào Subject Alternative Name (SAN) theo dạng mà hạ tầng hai phía hiểu thống nhất.

RFC 5280 định nghĩa SAN, Key Usage và Extended Key Usage (EKU). Chứng thư server cần phù hợp với mục đích serverAuth; chứng thư client cần phù hợp với clientAuth. Nếu một chứng thư chứa cả Key Usage và EKU, trình xác minh phải xử lý cả hai. Không nên dựa vào Common Name như cơ chế định danh duy nhất của thiết kế mới.

• SAN: danh tính mà peer sẽ đối chiếu, ví dụ DNS name hoặc URI của workload.
• EKU: giới hạn chứng thư dùng cho phía server, client hoặc cả hai theo chủ đích.
• Issuer và chain: xác định trust domain nào đã bảo chứng danh tính.
• NotBefore/NotAfter: cửa sổ hiệu lực; clock skew có thể làm chứng thư hợp lệ bị từ chối.
• Serial và key identifier: hỗ trợ theo dõi, thu hồi và điều tra sự cố.

4. Xây private CA theo ranh giới tin cậy

Không đưa root CA online vào luồng cấp phát hằng ngày. Một mô hình phổ biến là giữ root ngoại tuyến hoặc được bảo vệ chặt, rồi dùng intermediate CA cho từng môi trường hoặc miền quản trị. Production và non-production nên tách rời để một CA thử nghiệm không thể cấp danh tính được production tin cậy.

Trust bundle phải là allowlist có chủ đích. Đừng nhập mọi CA nội bộ vào mọi dịch vụ chỉ để “cho hết lỗi”. Nếu cần liên thông nhiều trust domain, hãy xác định CA nào được tin ở cổng nào, tên nào được phép và ai sở hữu vòng đời của quan hệ đó.

5. mTLS xác thực, không tự động phân quyền

Một chứng thư hợp lệ chỉ cho biết peer thuộc trust domain và chứng minh được khóa riêng. Nó không có nghĩa peer được gọi mọi API. Sau khi xác thực, hệ thống cần ánh xạ danh tính chuẩn hóa sang chính sách: service orders được gọi thao tác đọc tồn kho, nhưng không được sửa bảng giá.

NIST tách mutual authentication khỏi access control trong hướng dẫn service mesh: SP 800-204A bàn về hạ tầng giao tiếp microservice an toàn, còn SP 800-204B nhấn mạnh cần cả xác thực lẫn cơ chế kiểm soát truy cập. Vì vậy policy nên “deny by default”, dùng danh tính đã xác minh và được kiểm thử bằng các ca phủ định.

6. Biết TLS kết thúc ở đâu

Nếu mTLS kết thúc tại ingress, gateway hoặc sidecar, ứng dụng phía sau có thể chỉ nhìn thấy danh tính của proxy. Điều này không sai, nhưng ranh giới tin cậy phải được ghi rõ. Header chứa danh tính gốc chỉ đáng tin khi proxy xóa mọi giá trị do client gửi, tự chèn giá trị đã xác minh và đường từ proxy tới ứng dụng cũng được bảo vệ.

Service mesh giúp cấp phát chứng thư và áp policy đồng nhất mà ít sửa code. NIST SP 800-204A xem proxy-based service mesh là một cách cung cấp hạ tầng bảo mật nhất quán cho microservices. Dù vậy, mesh không xóa trách nhiệm kiểm tra cấu hình: chế độ permissive kéo dài có thể để lại đường plaintext hoặc client chưa xác thực.

7. Khóa riêng và vòng đời chứng thư

• Sinh khóa tại workload hoặc kho khóa được bảo vệ; tránh chuyển khóa qua artifact, image hay CI log.
• Giới hạn quyền đọc file khóa cho đúng process; không mount một secret dùng chung vào nhiều workload.
• Dùng chứng thư sống ngắn và cấp phát tự động để giảm thời gian lộ khóa.
• Gia hạn trước khi hết hạn, có jitter để tránh toàn cụm đồng loạt yêu cầu cấp mới.
• Hot reload an toàn hoặc rolling restart; xác nhận kết nối mới dùng chứng thư mới.
• Cảnh báo theo thời gian còn lại, không chỉ vào đúng ngày hết hạn.

Chứng thư sống ngắn không thay thế hoàn toàn thu hồi. Khi khóa bị lộ, cần lựa chọn rõ giữa CRL, OCSP, denylist tại control plane hoặc rút ngắn lifetime tùy kiến trúc và yêu cầu phản ứng. Đừng tuyên bố đã thu hồi nếu proxy thực tế vẫn cache trạng thái đến hết hạn.

8. Xoay CA mà không gián đoạn

1. Phân phối trust bundle chứa cả CA cũ và CA mới tới tất cả peer.
2. Xác minh mọi instance đã nạp bundle kép và có telemetry.
3. Bắt đầu cấp chứng thư leaf từ CA mới.
4. Đợi workload xoay vòng và kết nối cũ kết thúc theo chính sách.
5. Kiểm tra không còn chứng thư từ CA cũ trong traffic hợp lệ.
6. Gỡ CA cũ khỏi trust bundle, rồi giám sát lỗi handshake.

Thứ tự quan trọng: tin CA mới trước, phát hành từ CA mới sau, bỏ CA cũ cuối cùng. Quy trình ngược lại sẽ tạo khoảng thời gian peer chưa thể xác minh chứng thư vừa được cấp.

9. Lộ trình bật mTLS trên hệ thống đang chạy

1. Lập bản đồ caller–callee, cổng kết nối và nơi TLS đang terminate.
2. Chọn mô hình identity, trust domain, CA và owner của từng policy.
3. Cấp chứng thư tự động, nhưng ban đầu chỉ quan sát danh tính và lỗi xác minh.
4. Bật chế độ song song hoặc permissive trong thời gian ngắn có deadline rõ ràng.
5. Áp mTLS bắt buộc theo từng tuyến nhỏ; theo dõi latency, error rate và handshake failure.
6. Thêm authorization deny-by-default sau khi mapping danh tính ổn định.
7. Xóa đường plaintext, secret tạm và CA chuyển tiếp khi migration kết thúc.

10. Chẩn đoán bằng OpenSSL

openssl s_client \
  -connect payments.internal:8443 \
  -servername payments.internal \
  -CAfile ca.pem \
  -cert client.pem \
  -key client-key.pem \
  -verify_return_error

-servername gửi SNI, -CAfile chọn trust anchor, còn -cert và -key cung cấp danh tính client. Không dùng tùy chọn bỏ qua xác minh để “sửa” production. Có thể kiểm tra chain riêng:

openssl verify \
  -CAfile root.pem \
  -untrusted intermediate.pem \
  service.pem

Khi lỗi, hãy ghi nhận mã lỗi và tầng phát sinh: unknown CA, hostname/SAN mismatch, sai EKU, chứng thư hết hạn hoặc chưa có hiệu lực, thiếu intermediate, client không gửi chứng thư, signature algorithm không tương thích, hay policy từ chối sau khi handshake thành công.

11. Telemetry cần có

• Tỷ lệ handshake thành công/thất bại theo listener và mã lỗi.
• Danh tính peer đã chuẩn hóa, issuer và fingerprint/serial phù hợp cho audit.
• Phiên bản TLS và cipher suite đã thương lượng.
• Thời gian còn lại trước khi chứng thư hết hạn và kết quả lần gia hạn gần nhất.
• Số request bị authorization từ chối sau khi mTLS thành công.

Không log private key, nội dung secret, toàn bộ token hay dữ liệu chứng thư không cần thiết. Cũng đừng dùng DN thô làm nhãn metric có cardinality cao; chuẩn hóa thành service identity hữu hạn.

12. Bộ kiểm thử tối thiểu

• Client có chứng thư hợp lệ và đúng SAN/EKU được chấp nhận.
• Không gửi chứng thư client thì bị từ chối ở endpoint bắt buộc mTLS.
• Chứng thư do CA lạ cấp, hết hạn hoặc chưa có hiệu lực đều bị từ chối.
• Chứng thư đúng CA nhưng sai identity hoặc sai EKU bị từ chối.
• Service đã xác thực nhưng không đủ quyền bị chặn ở lớp authorization.
• Gia hạn và hot reload tạo kết nối mới thành công mà không rò khóa.
• Giai đoạn trust bundle kép chấp nhận cả leaf cũ và mới; sau cutover chỉ CA mới được chấp nhận.
• Clock skew, thiếu intermediate và control plane tạm thời không khả dụng có hành vi đã dự kiến.

13. Những anti-pattern thường gặp

• Dùng một chứng thư và một khóa riêng chung cho toàn bộ cluster.
• Tin mọi chứng thư từ corporate CA dù chỉ cần một trust domain nhỏ.
• Kiểm tra chain nhưng không kiểm tra SAN hoặc mục đích EKU.
• Cho rằng có mTLS đồng nghĩa mọi request đã được phân quyền.
• Tắt verify hostname hoặc chấp nhận chứng thư tự ký tùy ý để hết lỗi.
• Giữ chế độ permissive vô thời hạn và quên đóng đường plaintext.
• Xoay leaf nhưng không diễn tập xoay intermediate/root CA.
• Đặt chứng thư dài hạn trong container image hoặc repository.

Checklist production

• Mỗi workload có danh tính riêng, ổn định và kiểm tra được qua SAN.
• EKU/Key Usage phù hợp vai trò client hoặc server.
• Private CA, intermediate và trust bundle có owner cùng runbook xoay vòng.
• Khóa riêng không rời vùng bảo vệ và không được dùng chung.
• Cấp phát, gia hạn, reload và cảnh báo hết hạn đều tự động.
• Endpoint quan trọng từ chối client không có chứng thư hợp lệ.
• Authorization dùng identity đã xác minh và deny-by-default.
• Đã xác định đúng điểm terminate TLS và cách truyền identity qua proxy.
• Negative test cùng diễn tập CA rotation đã chạy thành công.
• Dashboard phân biệt lỗi TLS, lỗi xác thực và lỗi phân quyền.

Kết luận

mTLS đáng tin cậy không nằm ở chiếc công tắc “bắt buộc client certificate”, mà ở toàn bộ vòng đời danh tính máy. Hãy bắt đầu bằng namespace danh tính rõ ràng, SAN/EKU đúng mục đích và private CA có ranh giới nhỏ; sau đó tự động hóa cấp phát, xoay vòng, quan sát và kiểm thử phủ định. Cuối cùng, luôn giữ ranh giới khái niệm: mTLS bảo vệ kênh và xác thực workload, còn quyền thực hiện hành động phải do policy riêng quyết định.