On-prem, VPC hay SaaS: FDE phải vẽ được bản đồ “cái gì chạy ở đâu”

Thử hình dung buổi họp thứ ba với một ngân hàng. Demo đã ổn và nhóm nghiệp vụ đã gật đầu. Đúng lúc đó, người phụ trách bảo mật hỏi: hệ thống của bên bạn có chạy được trong VPC của ngân hàng không?

Nhiều kỹ sư mới làm FDE trả lời ngay là “được”. Đó là một câu trả lời nguy hiểm. Khách đang hỏi phần mềm sẽ chạy trên hạ tầng của ai, dữ liệu nằm ở đâu, và vendor còn giữ những quyền gì.

Nếu bạn chưa vẽ được bức tranh đó, chữ “được” chỉ là một lời hứa mà sau này đội bảo mật sẽ kiểm tra lại từng chi tiết.

Trả lời được câu hỏi ấy nằm ngay trong mô tả công việc của nhiều vị trí FDE. Tin tuyển dụng vị trí Forward Deployed Infrastructure Engineer của Sierra ghi rõ phạm vi công việc: thiết kế kiến trúc triển khai trong môi trường của khách, gồm cấu hình VPC, phân quyền, mạng và provisioning hạ tầng.

Ai muốn vào vai trò này phải nói chuyện được với đội hạ tầng của khách.

Ba mô hình nhưng chỉ một câu hỏi: cái gì nằm ở đâu?

Với SaaS, mọi thứ chạy trong tài khoản của vendor và khách gửi dữ liệu sang. Ở đầu kia là on-prem. Tài liệu của Northflank mô tả mô hình này là phần mềm chạy trên phần cứng đặt trong data center hoặc hạ tầng riêng của khách. Khác biệt lớn nhất so với customer VPC là on-prem không nằm trên cloud provider.

Customer VPC nằm ở giữa: phần mềm chạy trong tài khoản cloud của khách. Northflank lưu ý rằng BYOC (Bring Your Own Cloud) cũng là mô hình này, chỉ khác là nhìn từ phía khách hàng. Vì thế khi khách nói “BYOC” còn sales nói “triển khai trong VPC khách”, hai bên đang nói về cùng một thứ.

Chi tiết quan trọng nhất nằm ở đây: ngay cả khi phần mềm chạy trong cloud của khách, control plane thường vẫn ở tài khoản của vendor. Control plane là phần lo điều phối, CI/CD, cấu hình, giám sát và phân phối bản cập nhật. Vì thế “chạy trong VPC của khách” gần như không bao giờ có nghĩa là mọi thứ nằm trong VPC của khách.

Databricks cho thấy ranh giới nằm ở đâu

Databricks là ví dụ dễ học nhất vì tài liệu của họ kẻ ranh giới rất rõ. Control plane gồm các dịch vụ backend do Databricks quản lý trong tài khoản Databricks. Phần chạy tính toán được tách riêng thành compute plane.

Với classic compute, tài nguyên tính toán chạy trong tài khoản AWS của khách. Với serverless, compute chạy trong một lớp tính toán thuộc tài khoản Databricks. Cùng một sản phẩm nhưng có hai câu trả lời khác nhau cho câu hỏi “tính toán diễn ra ở đâu”: chọn serverless, khách được tiện lợi hơn nhưng phải chấp nhận compute không còn nằm trong tài khoản của mình.

Đây chính là kiểu trade-off bạn sẽ phải giải thích cho khách. Bảng dưới đây gom ba mô hình theo các câu hỏi mà đội bảo mật thường đặt ra.

Câu hỏi	SaaS	Customer VPC / BYOC	On-prem
Hạ tầng thuộc về ai	Vendor	Tài khoản cloud của khách	Data center của khách
Control plane	Vendor	Thường vẫn ở vendor	Phụ thuộc thiết kế, có khi không có đường về vendor
Dữ liệu nhạy cảm	Rời khỏi khách	Có thể giữ trong VPC khách	Ở lại trong hạ tầng khách
Việc khó nhất của FDE	Hợp đồng và luồng dữ liệu	Mạng, phân quyền, peering	Cập nhật và hỗ trợ khi không có cloud

Cột on-prem đáng đọc kỹ nhất. Khi control plane không có đường về vendor, cái khó không còn là cài đặt lần đầu mà là đưa được bản cập nhật vào, và phần lỗi thường gặp bên dưới sẽ quay lại đúng chuyện này.

Ví dụ: vẽ bản đồ triển khai cho ngân hàng

Quay lại câu hỏi của ngân hàng. Thay vì trả lời “được”, bạn hẹn gửi một bản đồ triển khai. Tài liệu BYOC của E2B là một mẫu tốt để học cách viết bản đồ này, vì họ liệt kê cụ thể cái gì ở lại và cái gì đi ra.

Theo E2B, sandbox template, snapshot và runtime log được lưu trong VPC BYOC của khách. Chỉ có metric đã ẩn danh được gửi về cloud của E2B để phục vụ observability, và VPC peering cho phép kết nối riêng. Cụm BYOC được provision bằng cấu hình Terraform và machine image.

Bản đồ của bạn có thể có dạng như sau (đây là template minh họa, không phải cấu hình thật của sản phẩm nào):

deployment_model: customer_vpc   # khách gọi là BYOC
control_plane:
  location: vendor_account
  responsibilities: [orchestration, ci_cd, config, monitoring, updates]
compute_plane:
  location: customer_aws_account
data_at_rest:            # ở lại trong VPC khách
  - templates
  - snapshots
  - runtime_logs
egress_to_vendor:        # mọi thứ đi qua ranh giới
  - type: metrics
    anonymized: true
    purpose: observability
connectivity: vpc_peering
provisioning: [terraform, machine_image]
iam: least_privilege_role_for_vendor

Phần đáng giá nhất của file này là mục egress_to_vendor. Đội bảo mật không cần nghe “dữ liệu không rời khỏi hệ thống”. Họ cần một danh sách đầy đủ những gì có rời đi, ở dạng nào và để làm gì.

Tự làm theo năm bước

1. Hỏi khách dữ liệu nào được phép nằm ở đâu. Xác định dữ liệu nhạy cảm nào bắt buộc phải ở lại hạ tầng của khách. 2. Tách sản phẩm thành control plane và compute plane như cách Databricks làm. Nếu đội sản phẩm chưa từng tách hai phần này, bạn vừa phát hiện một rủi ro của dự án. 3.

Chọn mô hình và viết bản đồ như ví dụ trên, đặc biệt là danh sách egress. 4. Provision bằng code. Terraform cộng với machine image giúp bạn dựng lại cùng một cụm ở khách thứ hai, thứ ba mà không phải làm tay. 5.

Chuẩn bị cho phần việc sau go-live. Sierra mô tả vòng đời triển khai gồm triển khai ban đầu, nâng cấp định kỳ, mở rộng và hỗ trợ sự cố, đi kèm runbook. Hãy viết runbook từ ngày đầu, trước khi có sự cố đầu tiên.

Những lỗi khiến dự án kẹt ở vòng bảo mật

Lỗi phổ biến nhất là coi rà soát bảo mật là thủ tục hành chính. Sierra yêu cầu ứng viên có kinh nghiệm vượt qua security review, các yêu cầu tuân thủ và quy trình change management. Ở doanh nghiệp lớn, một thay đổi rule firewall có thể phải chờ một chu kỳ phê duyệt, nên kế hoạch của bạn phải tính đến khoảng chờ đó.

Lỗi thứ hai là mặc định rằng lúc nào cũng có đường mạng về vendor. Với mạng air-gapped thì không có đường đó. Hệ quả trực tiếp là control plane ở phía vendor không thể tự đẩy bản cập nhật xuống nữa: mỗi bản nâng cấp phải được đóng gói sẵn, chuyển vào mạng của khách và đi qua quy trình change management của họ.

Palantir từng viết trong hồ sơ IPO rằng nền tảng Apollo giúp họ triển khai vào mạng air-gapped hoặc on-prem với tốc độ thực tế ngang trên cloud. Câu đó cho thấy việc này đòi hỏi cả một nền tảng được thiết kế riêng, chứ không phải chuyện cấu hình thêm vài dòng.

Lỗi thứ ba là chỉ lo phần triển khai mà quên phần nâng cấp. Một hệ thống chạy trong tài khoản của khách nhưng không có đường cập nhật rõ ràng sẽ lạc hậu dần, và mỗi lần vá lỗi lại thành một dự án riêng.

Cách cho nhà tuyển dụng thấy bạn có kỹ năng này

Khi đọc JD của FDE, hãy tìm các từ khóa như VPC, permissioning, networking, Terraform, BYOC, air-gapped. Đó là dấu hiệu vai trò nghiêng về hạ tầng. Nếu công việc hiện tại chưa cho bạn cơ hội làm những việc này, một dự án cá nhân dùng hai AWS account là đủ để luyện tập.

Trong CV, đừng viết chung chung “có kinh nghiệm cloud”. Hãy viết những điều cụ thể như: đã viết Terraform để dựng hệ thống trong tài khoản của khách, đã thiết kế IAM role tối thiểu cho vendor, đã cấu hình VPC peering, đã viết runbook nâng cấp. Hãy sẵn sàng giải thích chi tiết từng mục trong số đó khi được hỏi.

Lần tới khi nghe câu “chạy được trong VPC của chúng tôi không?”, đừng vội trả lời. Hãy mở một file trống và bắt đầu vẽ bản đồ.