Ngân hàng đề — Google Cloud Professional Cloud Security Engineer

Đáp án

C — Tạo khoá mới, đưa vào ứng dụng, rồi XOÁ khoá cũ khỏi service account.

Vì sao đúng

⚠ Google KHÔNG có lệnh "rotate" cho khoá service account — phải làm ba bước thủ công:

⚠ Bước 1: TẠO khoá mới
   gcloud iam service-accounts keys create
        ↓
⚠ Bước 2: CẬP NHẬT ứng dụng dùng khoá mới
   (⚠ triển khai, kiểm tra chạy được)
        ↓
⚠ Bước 3: XOÁ khoá cũ
   gcloud iam service-accounts keys delete

⚠ Bước 3 là bước quyết định: ⚠ không xoá thì việc xoay vòng vô nghĩa, ⚠ vì khoá cũ vẫn dùng được.

Vì sao các phương án khác sai

• D (tạo khoá mới, giữ khoá cũ làm dự phòng) — ⚠ bẫy nguy hiểm nhất: ⚠ khoá cũ vẫn hợp lệ vô thời hạn; ⚠ nếu xoay vòng vì nghi bị lộ thì việc giữ lại hoàn toàn phá hỏng mục đích.

• A (gcloud iam service-accounts enable-auto-rotate) — ⚠ lệnh KHÔNG tồn tại: ⚠ Google không cung cấp xoay vòng tự động cho khoá service account do người dùng quản.

• B (gcloud iam service-accounts keys rotate) — ⚠ cũng là lệnh bịa: ⚠ chỉ có keys create, keys delete, keys list, keys disable, keys enable.

Ghi nhớ

⚠ Lệnh THẬT với khoá service account — bảng phải thuộc: | Lệnh | Việc | |---|---| | ⚠ keys create | ⚠ tạo khoá mới | | ⚠ keys list | ⚠ liệt kê, xem ngày tạo | | ⚠ keys disable | ⚠ vô hiệu tạm, đảo ngược được | | ⚠ keys delete | ⚠ xoá hẳn | | ⚠ keys rotate | ⚠ KHÔNG TỒN TẠI | | ⚠ enable-auto-rotate | ⚠ KHÔNG TỒN TẠI |

Từ khoá nhận diện:

"xoay vòng khoá service account" → ⚠ tạo mới → cập nhật → XOÁ cũ "giữ khoá cũ làm dự phòng" → ⚠ LUÔN SAI "xoay vòng tự động" → ⚠ không có cho service account key; CÓ cho khoá Cloud KMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có khoá service account nào quá 90 ngày không | ⚠ keys list xem ngày tạo | | Có khoá nào tạo ra rồi không ai dùng không | ⚠ xem audit log | | Đã bật chính sách chặn tạo khoá chưa | ⚠ disableServiceAccountKeyCreation |

Và cách tốt nhất để giải bài toán xoay vòng khoá: loại bỏ khoá ra khỏi kiến trúc. Khoá không tồn tại thì không có gì để lộ, để xoay vòng, hay để quên xoá.

Đáp án

B — Đặt độ dài mật khẩu tối thiểu là 8 ký tự.

Vì sao đúng

⚠ Con số của Cloud Identity phải nhớ: | Thiết lập | Giá trị | |---|---| | ⚠ Độ dài TỐI THIỂU cho phép cấu hình | ⚠ 8 ký tự | | ⚠ Độ dài TỐI ĐA cho phép cấu hình | ⚠ 100 ký tự | | ⚠ Mặc định của Cloud Identity | ⚠ 8 ký tự |

⚠ 8 là con số Google khuyến nghị và cũng là giá trị nhỏ nhất mà quản trị viên đặt được.

Vì sao các phương án khác sai

• A (tối thiểu 6 ký tự) — ⚠ THẤP HƠN mức Cloud Identity cho phép: ⚠ hệ thống không nhận giá trị dưới 8.

• C (tối thiểu 12 ký tự) — ⚠ đặt được nhưng không phải hướng dẫn của Cloud Identity: ⚠ đề hỏi "hướng dẫn nào", ⚠ tức con số Google nêu ra, ⚠ không phải con số nghiêm hơn tuỳ chọn.

• D (tối thiểu 10 ký tự) — ⚠ cùng lý do với C: đặt được nhưng không phải hướng dẫn chuẩn.

Ghi nhớ

⚠ Chính sách mật khẩu của Cloud Identity — bảng phải thuộc: | Thiết lập | Giá trị | |---|---| | ⚠ Độ dài tối thiểu | ⚠ 8 (khoảng cho phép 8–100) | | ⚠ Bắt buộc đổi mật khẩu ở lần đăng nhập đầu | ⚠ bật/tắt được | | ⚠ Cấm dùng lại mật khẩu cũ | ⚠ bật/tắt được | | ⚠ Hạn dùng mật khẩu | ⚠ đặt số ngày, hoặc không bao giờ hết hạn | | ⚠ Cưỡng chế mật khẩu mạnh | ⚠ Google chấm điểm độ mạnh |

Từ khoá nhận diện:

"độ dài mật khẩu tối thiểu Cloud Identity" → ⚠ 8 "tối đa" → ⚠ 100 "chống đăng nhập trái phép hiệu quả nhất" → ⚠ MFA, không phải mật khẩu dài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách mật khẩu đặt tối thiểu bao nhiêu | | | MFA đã bắt buộc cho mọi tài khoản chưa | ⚠ nhất là tài khoản quản trị | | Tài khoản quản trị có dùng khoá phần cứng không | |

Và điều đáng nghĩ lại: tranh cãi 8 hay 12 ký tự ít quan trọng hơn nhiều so với việc đã bật MFA hay chưa. Một mật khẩu 20 ký tự không có lớp thứ hai vẫn thua một mật khẩu 8 ký tự kèm khoá bảo mật.

Đáp án

D — Phần mở rộng bảo mật cho DNS (DNSSEC).

Vì sao đúng

⚠ Bài toán đề nêu: kẻ tấn công chiếm tên miền / địa chỉ IP và chuyển hướng người dùng sang trang độc hại.

⚠ Người dùng gõ tên miền
        ↓
⚠ Truy vấn DNS
        ↓ ⚠ KẺ TẤN CÔNG chen vào
⚠ Trả về IP GIẢ
        ↓
⚠ Người dùng vào trang độc hại
   mà KHÔNG hay biết

⚠ DNSSEC chặn đúng chỗ này:

⚠ Ký SỐ mọi bản ghi DNS
        ↓
⚠ Trình phân giải KIỂM TRA chữ ký
        ↓
⚠ Bản ghi bị sửa → ⚠ chữ ký sai
   → ⚠ TỪ CHỐI kết quả

⚠ Bật trong Cloud DNS chỉ bằng một thiết lập trên managed zone.

Vì sao các phương án khác sai

• C (Cloud Armor — DDoS và WAF) — ⚠ bảo vệ SAU khi lưu lượng tới đúng nơi: ⚠ nếu DNS đã bị chuyển hướng thì ⚠ người dùng không bao giờ chạm tới Cloud Armor.

• A (Identity-Aware Proxy) — ⚠ kiểm soát AI được vào ứng dụng, ⚠ không bảo vệ quá trình phân giải tên miền.

• B (VPC Flow Logs) — ⚠ chỉ GHI LẠI siêu dữ liệu lưu lượng: ⚠ giúp điều tra sau, ⚠ không ngăn chặn gì cả.

Ghi nhớ

⚠ Ai chống được cái gì — bảng phải thuộc: | Mối đe doạ | Công cụ | |---|---| | ⚠ Đầu độc DNS, chiếm tên miền | ⚠ DNSSEC | | ⚠ DDoS, SQL injection, XSS | ⚠ Cloud Armor | | ⚠ Truy cập trái phép vào ứng dụng nội bộ | ⚠ IAP | | ⚠ Nghe lén đường truyền | ⚠ TLS / HTTPS | | ⚠ Cần bằng chứng điều tra | ⚠ VPC Flow Logs, Audit Logs |

Từ khoá nhận diện:

"chiếm tên miền, chuyển hướng DNS" → ⚠ DNSSEC "tấn công tầng 7, WAF" → ⚠ Cloud Armor "chỉ người trong công ty vào được" → ⚠ IAP "ghi lại ai nói chuyện với ai" → ⚠ VPC Flow Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | DNSSEC đã bật trên vùng chưa | ⚠ và bản ghi DS đã đăng ở nhà đăng ký chưa | | Tài khoản nhà đăng ký tên miền có MFA không | ⚠ đây là điểm yếu thật sự | | Có bản ghi CAA giới hạn ai cấp chứng chỉ không | |

Và điều nhiều tổ chức bỏ qua: bật DNSSEC nhưng quên đăng bản ghi DS ở nhà đăng ký. Khi đó chuỗi tin cậy không nối được lên trên, và toàn bộ việc ký số không bảo vệ được gì.

Đáp án

A — Dùng hạ tầng dưới dạng mã (infrastructure as code) và đưa phân tích tĩnh vào đường ống CI/CD để cưỡng chế chính sách.

Vì sao đúng

⚠ Bài toán đề nêu: đội phát triển muốn triển khai ứng dụng mới mà không phải chờ rà soát thủ công đường đi mạng, xử lý request và quy tắc firewall.

⚠ Cách CŨ: mỗi lần triển khai
   → ⚠ đội bảo mật đọc tay
   → ⚠ chờ vài ngày
   → ⚠ nút thắt cổ chai
        ↓
⚠ Cách MỚI: viết hạ tầng thành MÃ
   → ⚠ CI/CD chạy phân tích tĩnh
   → ⚠ vi phạm chính sách thì CHẶN
   → ⚠ hợp lệ thì triển khai NGAY

⚠ Đây là "policy as code": ⚠ luật bảo mật được viết một lần, ⚠ máy kiểm tra mỗi lần, ⚠ con người chỉ rà soát khi chính luật thay đổi.

Vì sao các phương án khác sai

• B (dùng Firewall filter với Forseti để phát hiện cấu hình không mong muốn ở production) — ⚠ PHÁT HIỆN SAU khi đã triển khai: ⚠ vấn đề vẫn lọt ra production trước; ⚠ đề muốn chặn TRƯỚC.

• D (đưa mọi lưu lượng VPC qua router do khách quản để phát hiện mẫu độc hại) — ⚠ thêm nút thắt và điểm hỏng: ⚠ tốn kém, ⚠ và ⚠ vẫn không giải quyết chuyện rà soát cấu hình.

• C (chạy production tại chỗ, cho lập trình viên toàn quyền trên Google Cloud làm môi trường phát triển) — ⚠ từ bỏ kiểm soát: ⚠ "toàn quyền không giới hạn" là ⚠ ngược hoàn toàn với nguyên tắc quyền tối thiểu.

Ghi nhớ

⚠ Dịch trái sang phải (shift left) — bảng phải thuộc: | Giai đoạn | Kiểm gì | |---|---| | ⚠ Lúc VIẾT MÃ | ⚠ linter, pre-commit hook, quét secret | | ⚠ Lúc BUILD (CI) | ⚠ phân tích tĩnh IaC, quét lỗ hổng ảnh container | | ⚠ Lúc TRIỂN KHAI | ⚠ Binary Authorization, Policy Controller | | ⚠ Lúc CHẠY | ⚠ Security Command Center, Organization Policy | | ⚠ Càng sớm càng rẻ | ⚠ sửa ở CI rẻ hơn sửa ở production rất nhiều |

Từ khoá nhận diện:

"triển khai nhanh mà vẫn an toàn" → ⚠ IaC + phân tích tĩnh trong CI/CD "phát hiện cấu hình sai ở production" → ⚠ SCC — nhưng là quá muộn "chặn container chưa được ký" → ⚠ Binary Authorization "cưỡng chế luật ở mức tổ chức" → ⚠ Organization Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạ tầng có được quản bằng mã không | ⚠ hay vẫn bấm tay trên Console | | CI có bước kiểm chính sách không | | | Ai sửa tay trên Console thì có ai biết không | ⚠ phát hiện trôi cấu hình |

Và lý do thật khiến rà soát bảo mật thủ công thất bại: nó không mở rộng được. Một đội bảo mật mười người không thể đọc tay ba trăm lần triển khai mỗi tuần — họ chỉ có thể viết luật cho máy đọc thay.

Đáp án

B — Bảo đảm hệ thống ERP xác minh được JWT assertion trong các request HTTP.

Vì sao đúng

⚠ IAP hoạt động thế nào:

⚠ Người dùng → ⚠ Load Balancer → ⚠ IAP
        ↓ ⚠ IAP xác thực và uỷ quyền
⚠ IAP thêm header
   ⚠ x-goog-iap-jwt-assertion
   (⚠ JWT ký bằng khoá của Google)
        ↓
⚠ Ứng dụng ERP KIỂM CHỮ KÝ
        ↓
⚠ Chữ ký hợp lệ → ⚠ chắc chắn
  request đi qua IAP

⚠ Vì sao phải kiểm JWT chứ không tin header thường: | Vấn đề | Hậu quả | |---|---| | ⚠ Kẻ tấn công đến THẲNG VM, bỏ qua Load Balancer | ⚠ tự đặt header giả | | ⚠ Header thường KHÔNG có chữ ký | ⚠ ai cũng giả được | | ⚠ JWT có chữ ký của Google | ⚠ KHÔNG giả được |

Vì sao các phương án khác sai

• C (xác thực identity header trong request HTTP) — ⚠ bẫy gần nhất: ⚠ IAP có thêm header x-goog-authenticated-user-email, ⚠ nhưng header đó KHÔNG có chữ ký — ⚠ chỉ đáng tin nếu chắc chắn mọi lưu lượng đều qua IAP.

• D (xác minh header định danh duy nhất của người dùng) — ⚠ cùng vấn đề với C: ⚠ header không ký thì giả được.

• A (xác minh header x-forwarded-for) — ⚠ sai hoàn toàn: ⚠ x-forwarded-for chỉ ghi địa chỉ IP, ⚠ ai cũng đặt được, ⚠ và không nói gì về danh tính.

Ghi nhớ

⚠ Header IAP thêm vào — bảng phải thuộc: | Header | Tin được không | |---|---| | ⚠ x-goog-iap-jwt-assertion | ⚠ CÓ — có chữ ký, PHẢI kiểm | | ⚠ x-goog-authenticated-user-email | ⚠ chỉ khi chắc chắn mọi lưu lượng qua IAP | | ⚠ x-goog-authenticated-user-id | ⚠ như trên | | ⚠ x-forwarded-for | ⚠ KHÔNG — không liên quan danh tính |

Từ khoá nhận diện:

"chỉ cho lưu lượng từ IAP đi qua" → ⚠ xác minh JWT assertion "IAP thay VPN thế nào" → ⚠ BeyondCorp, kiểm danh tính chứ không kiểm vị trí mạng "header x-forwarded-for" → ⚠ luôn là phương án sai trong ngữ cảnh danh tính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có kiểm JWT không, hay chỉ đọc email header | | | Có kiểm trường aud không | ⚠ hay bị bỏ sót nhất | | Firewall có chặn truy cập thẳng vào VM không | ⚠ bỏ qua IAP |

Và lỗ hổng kinh điển khi triển khai IAP: firewall vẫn mở cổng ứng dụng ra Internet. Người ta bật IAP, thấy đăng nhập hoạt động, rồi quên rằng đường cũ đi thẳng vào VM vẫn còn nguyên.

Đáp án

A — Cloud Logging trên Google Cloud Platform.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này gần như không có bẫy: ⚠ ba phương án còn lại chỉ là định nghĩa dịch vụ (GKE là dịch vụ Kubernetes, Cloud SQL là CSDL được quản, "dịch vụ lưu trữ của Google Cloud"), ⚠ không cái nào liên quan tới kiểm toán, giám sát hay phân tích.

⚠ Dùng câu này để nhớ nhóm công cụ quan sát, đừng chỉ nhớ đáp án.

Vì sao đúng

⚠ Cloud Logging làm đúng ba việc đề nêu: | Việc đề hỏi | Cloud Logging làm | |---|---| | ⚠ Kiểm toán (auditing) | ⚠ Cloud Audit Logs — ai làm gì, khi nào | | ⚠ Giám sát (monitoring) | ⚠ log-based metric và alert | | ⚠ Phân tích (analysis) | ⚠ Logs Explorer, xuất sang BigQuery |

Vì sao các phương án khác sai

• B (Google Kubernetes Engine) — ⚠ chạy container, không phải công cụ kiểm toán.

• C (Cloud SQL) — ⚠ cơ sở dữ liệu quan hệ được quản, không liên quan.

• D (dịch vụ lưu trữ của Google Cloud) — ⚠ lưu dữ liệu, không phân tích hoạt động.

Ghi nhớ

⚠ Bộ công cụ quan sát (Cloud Operations) — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Cloud Logging | ⚠ thu thập, lưu, tìm và xuất log | | ⚠ Cloud Monitoring | ⚠ chỉ số, biểu đồ, cảnh báo, uptime check | | ⚠ Cloud Trace | ⚠ theo dấu một request qua nhiều dịch vụ | | ⚠ Cloud Profiler | ⚠ hàm nào ngốn CPU và bộ nhớ | | ⚠ Error Reporting | ⚠ gom ngoại lệ thành nhóm |

Từ khoá nhận diện:

"ai đã làm gì trên tài nguyên nào" → ⚠ Cloud Audit Logs "độ trễ, tỉ lệ lỗi, cảnh báo" → ⚠ Cloud Monitoring "request chậm ở dịch vụ nào" → ⚠ Cloud Trace "hàm nào tốn CPU" → ⚠ Cloud Profiler

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Data Access log đã bật cho dịch vụ quan trọng chưa | | | Log có được xuất đi nơi khác để giữ lâu không | | | Có cảnh báo nào dựa trên log không | ⚠ hay chỉ lưu rồi để đó |

Và câu hỏi đáng đặt cho mọi hệ thống đang chạy: nếu ngày mai có sự cố bảo mật, log đủ để dựng lại chuyện gì đã xảy ra không? Nếu câu trả lời là không, thì hôm nay là ngày sửa.

Đáp án

B — Thiết lập Google Cloud Directory Sync với hệ thống thư mục nội bộ để tự động thêm và gỡ người dùng khỏi Cloud Identity.

Vì sao đúng

⚠ Yêu cầu của đề: nhân viên nghỉ việc thì tài khoản Google tự động bị thu hồi.

⚠ HR đánh dấu nghỉ việc
        ↓
⚠ Tài khoản bị vô hiệu trong
   Active Directory / LDAP
        ↓ ⚠ Cloud Directory Sync (chạy theo lịch)
⚠ Cloud Identity vô hiệu tài khoản
        ↓
⚠ Mất quyền vào MỌI dịch vụ Google

⚠ Điểm mấu chốt: ⚠ thư mục nội bộ là NGUỒN SỰ THẬT DUY NHẤT, ⚠ Cloud Identity chỉ phản chiếu nó.

Vì sao các phương án khác sai

• D (thiết lập Cloud Directory Sync để GỠ QUYỀN IAM) — ⚠ nhầm việc GDS làm: ⚠ GDS đồng bộ người dùng và nhóm, ⚠ KHÔNG quản lý quyền IAM. ⚠ Nhưng ⚠ tài khoản bị vô hiệu thì quyền IAM cũng vô dụng.

• C (dùng thư mục và Cloud SDK để cấp phát và thu hồi người dùng) — ⚠ tự viết script thay vì dùng công cụ có sẵn: ⚠ phải tự bảo trì, ⚠ tự xử lý lỗi, ⚠ dễ bỏ sót.

• A (dùng thư mục và Cloud SDK để thu hồi quyền IAM) — ⚠ hai lỗi cùng lúc: ⚠ tự viết script, ⚠ và ⚠ nhắm sai đối tượng (quyền IAM thay vì tài khoản).

Ghi nhớ

⚠ Google Cloud Directory Sync (GCDS) — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Đồng bộ MỘT CHIỀU | ⚠ LDAP/AD → Cloud Identity, KHÔNG ngược lại | | ⚠ Đồng bộ gì | ⚠ người dùng, nhóm, danh bạ, đơn vị tổ chức | | ⚠ KHÔNG đồng bộ | ⚠ mật khẩu (trừ khi dùng GSPS), quyền IAM | | ⚠ Chạy thế nào | ⚠ công cụ chạy TẠI CHỖ, theo lịch | | ⚠ An toàn | ⚠ có chế độ mô phỏng trước khi áp dụng |

Từ khoá nhận diện:

"tự động thêm/gỡ người dùng theo thư mục nội bộ" → ⚠ GCDS "đăng nhập một lần bằng danh tính công ty" → ⚠ SAML SSO / Identity Platform "đồng bộ mật khẩu" → ⚠ G Suite Password Sync (GSPS), công cụ riêng "ai được làm gì trên tài nguyên" → ⚠ IAM, không phải GCDS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài khoản nào của người đã nghỉ còn hoạt động không | | | GCDS chạy bao lâu một lần | ⚠ mỗi giờ hay mỗi ngày | | Ai sở hữu các service account | ⚠ người nghỉ việc thường để lại |

Và lỗ hổng dai dẳng nhất trong quản lý danh tính: service account do một cá nhân tạo ra rồi bỏ lại. Tài khoản người thì có quy trình nghỉ việc; service account thì thường không ai nhận trách nhiệm.

Đáp án

A — Bucket trên Cloud Storage

Vì sao đúng

Yêu cầu là giữ hai năm với chi phí thấp nhất. Cloud Storage là nơi rẻ nhất cho việc lưu trữ dài hạn, và còn rẻ hơn nữa khi áp chính sách vòng đời để chuyển log cũ sang lớp Nearline, Coldline hay Archive. Sink của Cloud Logging ghi thẳng vào bucket, không phải dựng gì thêm.

Vì sao các phương án khác sai

• B. Giữ trong chính Cloud Logging — được, nhưng đắt hơn hẳn cho lưu trữ dài hạn; đó là nơi để tra cứu nóng chứ không phải kho lưu trữ.
• C. Dataset trong BigQuery — hợp khi cần truy vấn thường xuyên bằng SQL; chi phí lưu trữ cao hơn Cloud Storage nên không hợp mục tiêu tiết kiệm.
• D. Topic trong Pub/Sub — là kênh truyền thông điệp, chỉ giữ trong thời gian ngắn; hoàn toàn không phải nơi lưu trữ.

Đáp án

D — Cân bằng tải bằng SSL Proxy.

Vì sao đúng

⚠ Đọc kỹ ba manh mối của đề: | Manh mối | Suy ra | |---|---| | ⚠ Cổng 587 | ⚠ SMTP submission — KHÔNG phải HTTP | | ⚠ Kết nối được bảo vệ bằng TLS | ⚠ cần mã hoá | | ⚠ TLS kết thúc TẠI Load Balancer | ⚠ LB phải giải mã, không chỉ chuyển tiếp |

⚠ Lưu lượng TCP có TLS,
   KHÔNG phải HTTP
        ↓
⚠ Cần kết thúc TLS ở LB
        ↓
⚠ SSL Proxy Load Balancing
   (⚠ đúng một lựa chọn)

Vì sao các phương án khác sai

• B (TCP Proxy Load Balancing) — ⚠ bẫy gần nhất, khác đúng một điểm: ⚠ TCP Proxy chuyển tiếp TCP nhưng KHÔNG kết thúc TLS; ⚠ đề yêu cầu LB phải kết thúc TLS → ⚠ phải là SSL Proxy.

• C (HTTP(S) Load Balancing) — ⚠ chỉ dành cho HTTP và HTTPS: ⚠ cổng 587 là SMTP, ⚠ không phải giao thức HTTP.

• A (Network Load Balancing) — ⚠ tầng 4, chuyển tiếp thô (pass-through): ⚠ không kết thúc TLS, ⚠ gói tin đi thẳng tới VM.

Ghi nhớ

⚠ Chọn Load Balancer — bảng phải thuộc: | Lưu lượng | Loại LB | |---|---| | ⚠ HTTP/HTTPS, cần định tuyến theo URL | ⚠ HTTP(S) LB (tầng 7) | | ⚠ TCP CÓ TLS, không phải HTTP, LB giải mã | ⚠ SSL Proxy — đề này | | ⚠ TCP không TLS, hoặc TLS đi xuyên qua | ⚠ TCP Proxy | | ⚠ UDP, hoặc cần giữ IP nguồn gốc | ⚠ Network LB (pass-through) | | ⚠ Nội bộ trong VPC | ⚠ Internal LB |

Từ khoá nhận diện:

"kết thúc TLS tại load balancer, không phải HTTP" → ⚠ SSL Proxy "TCP nhưng không cần giải mã" → ⚠ TCP Proxy "UDP" → ⚠ chỉ Network LB làm được "định tuyến theo đường dẫn URL" → ⚠ HTTP(S) LB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng có thật sự là HTTP không | ⚠ quyết định loại LB | | Có cần WAF không | ⚠ nếu có thì phải dùng HTTP(S) LB | | Backend có cần biết IP thật của khách không | ⚠ proxy thì phải đọc header |

Và điều hay bị bỏ qua khi dùng proxy load balancer: backend không còn thấy địa chỉ IP thật của người dùng. Muốn ghi log đúng thì phải đọc từ header do LB thêm vào, chứ không phải từ kết nối TCP.

Đáp án

B — Bắt buộc mọi người dùng G Suite bật xác thực hai lớp (2FA).

Vì sao đúng

⚠ Đề nêu chính xác kịch bản: ⚠ mật khẩu của nhân viên ĐÃ BỊ LỘ, ⚠ làm sao người ngoài vẫn không vào được.

⚠ Kẻ tấn công có mật khẩu đúng
        ↓
⚠ Hệ thống hỏi yếu tố THỨ HAI
   (⚠ điện thoại, khoá vật lý, mã)
        ↓
⚠ Kẻ tấn công KHÔNG có
        ↓
⚠ Truy cập bị chặn

⚠ 2FA là biện pháp duy nhất trong bốn phương án trực tiếp vô hiệu hoá mật khẩu bị lộ.

Vì sao các phương án khác sai

• D (bật Identity-Aware Proxy cho ứng dụng App Engine) — ⚠ bẫy hợp lý nhất: ⚠ IAP là lớp bảo vệ tốt, ⚠ nhưng IAP vẫn dựa trên cùng tài khoản Google đó; ⚠ mật khẩu bị lộ mà không có 2FA thì ⚠ kẻ tấn công qua được IAP.

• C (dựng Cloud VPN giữa mạng nội bộ và Google Cloud) — ⚠ bảo vệ theo VỊ TRÍ MẠNG: ⚠ không ngăn được người dùng chính chủ bị chiếm tài khoản; ⚠ và ⚠ ứng dụng App Engine vẫn công khai.

• A (dùng G Suite Password Sync để cấp mật khẩu) — ⚠ chỉ đồng bộ mật khẩu: ⚠ vẫn là một yếu tố duy nhất; ⚠ lộ vẫn là lộ.

Ghi nhớ

⚠ Ba yếu tố xác thực — bảng phải thuộc: | Yếu tố | Ví dụ | |---|---| | ⚠ Điều bạn BIẾT | ⚠ mật khẩu, mã PIN | | ⚠ Điều bạn CÓ | ⚠ điện thoại, khoá bảo mật Titan | | ⚠ Điều bạn LÀ | ⚠ vân tay, khuôn mặt | | ⚠ Hai lớp | ⚠ phải là HAI yếu tố KHÁC LOẠI | | ⚠ Mật khẩu + câu hỏi bí mật | ⚠ KHÔNG phải 2FA — cùng loại "biết" |

Từ khoá nhận diện:

"mật khẩu đã bị lộ mà vẫn an toàn" → ⚠ 2FA / MFA "chỉ người trong công ty vào được ứng dụng nội bộ" → ⚠ IAP "chống lừa đảo mạnh nhất" → ⚠ khoá bảo mật phần cứng FIDO "kiểm soát theo thiết bị" → ⚠ Endpoint Verification + Context-Aware Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu phần trăm tài khoản đã bật 2FA | ⚠ Admin console có báo cáo | | Tài khoản quản trị có bắt buộc chưa | ⚠ ưu tiên số một | | Có quy trình cho người mất điện thoại chưa | |

Và lý do khiến nhiều tổ chức trì hoãn 2FA rồi hối tiếc: họ chờ tới khi có sự cố mới bật. Chi phí phiền toái của 2FA là vài giây mỗi lần đăng nhập; chi phí của một tài khoản quản trị bị chiếm thì không đo bằng giây.