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

Tìm thấy 395 câu.

Câu 31
As an AI consulting firm, your client is running their e-commerce website on Google Kubernetes Engine and requires customer transaction analysis in BigQuery. How can you ensure that credit card information is not stored in BigQuery?
  1. A Before ingesting data into BigQuery, utilize the Cloud Data Loss Prevention API to censor associated infoTypes.
  2. B To query and delete impacted rows, generate a BigQuery view that utilizes regular expressions to match credit card numbers.
  3. C To prevent the storage of credit card numbers in BigQuery logs, it is recommended to utilize Cloud Identity-Aware Proxy for filtration purposes.
  4. D Utilize Security Command Center to perform a scan in BigQuery for assets categorized as Credit Card Number.
Xem giải thích

Đáp án

A — Dùng Cloud Data Loss Prevention API để che các infoType liên quan TRƯỚC khi nạp dữ liệu vào BigQuery.

Vì sao đúng

⚠ Nguyên tắc quyết định: ⚠ dữ liệu bạn không lưu là dữ liệu không thể rò rỉ.

⚠ Dữ liệu giao dịch từ GKE
        ↓ ⚠ DLP API quét và che
   ⚠ infoType: CREDIT_CARD_NUMBER
        ↓
⚠ Nạp vào BigQuery
        ↓
⚠ BigQuery KHÔNG BAO GIỜ chứa
   số thẻ

⚠ Che TRƯỚC khi nạp là điểm mấu chốt — ⚠ các phương án khác đều xử lý sau khi đã lưu.

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

  • B (tạo view BigQuery dùng biểu thức chính quy để tìm và xoá dòng bị ảnh hưởng) — ⚠ dữ liệu ĐÃ nằm trong BigQuery rồi: ⚠ đã có cửa sổ rò rỉ; ⚠ view không xoá dữ liệu gốc; ⚠ ⚠ và bản sao lưu, log, snapshot vẫn còn.

  • D (dùng Security Command Center quét BigQuery tìm tài sản loại Credit Card Number) — ⚠ PHÁT HIỆN chứ không NGĂN: ⚠ báo cho bạn biết là đã có rồi.

  • C (dùng Identity-Aware Proxy để lọc số thẻ khỏi log BigQuery) — ⚠ sai công cụ hoàn toàn: ⚠ IAP kiểm soát truy cập vào ứng dụng web, ⚠ không lọc nội dung dữ liệu.

Ghi nhớ

⚠ Thứ tự ưu tiên khi xử lý dữ liệu nhạy cảm — bảng phải thuộc: | Ưu tiên | Cách | |---|---| | ⚠ 1. KHÔNG thu thập | ⚠ tốt nhất | | ⚠ 2. Che ngay tại nguồn, TRƯỚC khi lưu | ⚠ đề này | | ⚠ 3. Token hoá để vẫn ghép nối được | | | ⚠ 4. Mã hoá và kiểm soát chặt truy cập | | | ⚠ 5. Phát hiện sau khi lưu | ⚠ là lưới an toàn, không phải giải pháp |

Từ khoá nhận diện:

"không được lưu số thẻ vào kho dữ liệu" → ⚠ DLP de-identify TRƯỚC khi nạp "tìm xem dữ liệu nhạy cảm nằm ở đâu" → ⚠ DLP data profiling hoặc SCC "vẫn cần ghép giao dịch của cùng một thẻ" → ⚠ token hoá giữ định dạng

⚠ infoType hay gặp trong DLP infoType
⚠ CREDIT_CARD_NUMBER
⚠ EMAIL_ADDRESS, PHONE_NUMBER
⚠ US_SOCIAL_SECURITY_NUMBER
⚠ PERSON_NAME, STREET_ADDRESS
⚠ Tự định nghĩa được ⚠ custom infoType bằng regex hoặc từ điển
⚠ Có mức tin cậy ⚠ VERY_LIKELY tới VERY_UNLIKELY — đặt ngưỡng
⚠ PCI DSS nói gì về lưu số thẻ Quy định
⚠ TUYỆT ĐỐI không lưu mã CVV ⚠ kể cả có mã hoá
⚠ Số thẻ nếu lưu phải làm cho không đọc được ⚠ che, băm, token hoá, hoặc mã hoá mạnh
⚠ Hiển thị tối đa 6 số đầu và 4 số cuối
⚠ Cách né toàn bộ phạm vi PCI ⚠ token hoá ngay tại cổng thanh toán, hệ thống mình không bao giờ thấy số thẻ
⚠ Vì sao "xoá sau" không đủ Lý do
⚠ BigQuery có time travel 7 ngày ⚠ dữ liệu đã xoá vẫn truy vấn lại được
⚠ Snapshot và bản sao bảng vẫn còn
⚠ Log truy vấn có thể chứa dữ liệu
⚠ Đã có người truy vấn trong khoảng thời gian đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bảng nào đang chứa dữ liệu nhạy cảm không | ⚠ chạy DLP data profiling | | Việc che diễn ra ở tầng nào của đường ống | ⚠ phải là trước khi ghi | | Log truy vấn có ghi lại giá trị nhạy cảm không | |

Và nguyên tắc gọn nhất để nhớ toàn bộ chủ đề này: cách rẻ nhất để bảo vệ một dữ liệu là không giữ nó.

Câu 32
As an online education platform company, which document should you review to identify Google Cloud's inherent controls for PCI compliance evaluation?
  1. A Documentation related to Compute Engine product.
  2. B Matrix of Customer Responsibility in Google Cloud Platform
  3. C Security Assessment Procedures and PCI DSS Requirements
  4. D Guidelines for Cloud Computing by PCI SSC.
Xem giải thích

Đáp án

B — Ma trận trách nhiệm khách hàng (Customer Responsibility Matrix) của Google Cloud Platform.

Vì sao đúng

⚠ Đề hỏi: tài liệu nào cho biết kiểm soát SẴN CÓ của Google Cloud khi đánh giá tuân thủ PCI.

⚠ Đánh giá PCI DSS trên đám mây
        ↓ ⚠ Câu hỏi cốt lõi
⚠ "Yêu cầu nào Google ĐÃ làm?"
⚠ "Yêu cầu nào TÔI phải làm?"
        ↓
⚠ Ma trận trách nhiệm khách hàng
   trả lời đúng câu đó

⚠ Nội dung ma trận: ⚠ liệt kê từng yêu cầu PCI DSS và ghi rõ ⚠ Google chịu / khách chịu / cùng chịu.

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

  • C (PCI DSS Requirements and Security Assessment Procedures) — ⚠ bẫy gần nhất: đó là ⚠ tiêu chuẩn PCI gốc, ⚠ nói yêu cầu là gì, ⚠ nhưng không nói Google đã làm phần nào.

  • D (Hướng dẫn điện toán đám mây của PCI SSC) — ⚠ hướng dẫn CHUNG cho mọi đám mây: ⚠ không nói riêng về Google Cloud.

  • A (tài liệu sản phẩm Compute Engine) — ⚠ tài liệu kỹ thuật một sản phẩm: ⚠ không ánh xạ sang yêu cầu tuân thủ.

Ghi nhớ

⚠ Tài liệu tuân thủ — bảng phải thuộc: | Tài liệu | Nội dung | |---|---| | ⚠ Customer Responsibility Matrix | ⚠ ai chịu yêu cầu nào — đề này | | ⚠ Chứng nhận và báo cáo kiểm toán | ⚠ bằng chứng Google đã đạt chuẩn — trên Compliance Reports Manager | | ⚠ Tiêu chuẩn gốc (PCI DSS, ISO 27001) | ⚠ yêu cầu là gì | | ⚠ Blueprint bảo mật của Google | ⚠ cách triển khai kiến trúc đạt chuẩn |

Từ khoá nhận diện:

"kiểm soát nào Google đã cung cấp sẵn" → ⚠ Customer Responsibility Matrix "tải báo cáo kiểm toán, chứng nhận" → ⚠ Compliance Reports Manager "yêu cầu của tiêu chuẩn là gì" → ⚠ tài liệu của chính tổ chức tiêu chuẩn

⚠ Ba loại trách nhiệm trong ma trận Loại
⚠ Google hoàn toàn chịu ⚠ an ninh vật lý trung tâm dữ liệu
⚠ Khách hoàn toàn chịu ⚠ phân quyền IAM, mã hoá dữ liệu ứng dụng
⚠ CÙNG chịu ⚠ vá lỗi: Google lo hạ tầng, khách lo hệ điều hành khách
⚠ Mục dễ bỏ sót nhất ⚠ những mục "cùng chịu" — hay bị tưởng là Google lo hết
⚠ Chứng chỉ tuân thủ Google Cloud có Chứng chỉ
⚠ PCI DSS ⚠ thanh toán thẻ
⚠ ISO 27001, 27017, 27018 ⚠ quản lý an toàn thông tin
⚠ SOC 1, SOC 2, SOC 3
⚠ HIPAA ⚠ y tế — cần ký BAA
⚠ FedRAMP ⚠ chính phủ Mỹ
⚠ Lưu ý ⚠ Google đạt chuẩn KHÔNG có nghĩa hệ thống của bạn đạt chuẩn
⚠ Hiểu lầm nguy hiểm nhất về tuân thủ đám mây Hiểu lầm
⚠ "Google có PCI DSS nên tôi cũng có" ⚠ SAI
⚠ Google chứng nhận cho HẠ TẦNG
⚠ Ứng dụng và cấu hình của bạn phải tự đánh giá
⚠ Cấu hình sai một bucket là mất tuân thủ
⚠ Cách đúng ⚠ dùng ma trận để biết phần việc còn lại của mình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã đọc phần "khách chịu" của ma trận chưa | | | Dịch vụ đang dùng có nằm trong phạm vi chứng nhận không | ⚠ không phải dịch vụ nào cũng có | | Có ai chịu trách nhiệm cho các mục "cùng chịu" không | |

Và câu hỏi mà mọi đợt kiểm toán đám mây đều đi tới: phần nào là của nhà cung cấp, phần nào là của bạn?. Ma trận trách nhiệm tồn tại chính vì câu hỏi đó không có câu trả lời chung cho mọi dịch vụ.

Câu 33
What GCP solution should a digital product design agency company use to migrate its ongoing data backup and disaster recovery solutions from its on-premises environment to GCP, as a first step towards the migration of the on-premises production environment?
  1. A One way to utilize Cloud Storage with Cloud Interconnect is by implementing a scheduled task that utilizes gsutil.
  2. B The process of continuously updating BigQuery through a data pipeline job using Cloud VPN.
  3. C Cloud Interconnect is used to connect Compute Engine Virtual Machines to Persistent Disks.
  4. D Regularly scheduled batch upload jobs via Cloud VPN are used to upload data to Cloud Datastore.
Xem giải thích

Đáp án

A — Dùng Cloud Storage qua Cloud Interconnect, với tác vụ theo lịch chạy gsutil.

Vì sao đúng

⚠ Ghép từng phần của đề với từng phần của đáp án: | Yêu cầu | Thành phần | |---|---| | ⚠ Sao lưu và khôi phục thảm hoạ | ⚠ Cloud Storage — kho đối tượng, bền, rẻ | | ⚠ Khối lượng lớn từ tại chỗ | ⚠ Cloud Interconnect — băng thông cao, ổn định | | ⚠ Liên tục, đều đặn | ⚠ tác vụ theo lịch chạy gsutil | | ⚠ Bước ĐẦU của di trú | ⚠ đơn giản, không đụng ứng dụng |

⚠ Vì sao sao lưu là bước đầu hợp lý: ⚠ không rủi ro cho production, ⚠ giúp đội quen với đám mây, ⚠ và ⚠ đã có sẵn dữ liệu trên đám mây khi di trú thật.

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

  • B (đường ống liên tục cập nhật BigQuery qua Cloud VPN) — ⚠ sai kho đích: ⚠ BigQuery là kho phân tích, ⚠ không phải nơi lưu bản sao lưu; ⚠ và ⚠ VPN băng thông thấp cho khối lượng sao lưu.

  • D (tải theo lô định kỳ vào Cloud Datastore qua Cloud VPN) — ⚠ Datastore là CSDL NoSQL cho ứng dụng, ⚠ hoàn toàn không phải nơi sao lưu tệp.

  • C (Cloud Interconnect dùng để nối VM với Persistent Disk) — ⚠ mô tả SAI về Interconnect: ⚠ Interconnect nối mạng tại chỗ với Google Cloud; ⚠ VM nối với Persistent Disk là chuyện nội bộ, không cần gì cả.

Ghi nhớ

⚠ Chọn kho lưu trữ theo mục đích — bảng phải thuộc: | Mục đích | Dịch vụ | |---|---| | ⚠ Sao lưu, lưu trữ tệp, DR | ⚠ Cloud Storage | | ⚠ Phân tích SQL khối lượng lớn | ⚠ BigQuery | | ⚠ NoSQL cho ứng dụng web | ⚠ Firestore / Datastore | | ⚠ CSDL quan hệ | ⚠ Cloud SQL / Spanner | | ⚠ Đĩa gắn vào VM | ⚠ Persistent Disk |

Từ khoá nhận diện:

"sao lưu, khôi phục thảm hoạ, lưu trữ lâu dài" → ⚠ Cloud Storage "chuyển khối lượng lớn từ tại chỗ, ổn định" → ⚠ Cloud Interconnect "chuyển một lần hàng trăm TB" → ⚠ Transfer Appliance "chuyển từ đám mây khác hoặc từ URL" → ⚠ Storage Transfer Service

⚠ Bốn lớp lưu trữ của Cloud Storage Lớp
⚠ Standard ⚠ truy cập thường xuyên
⚠ Nearline ⚠ khoảng một lần/tháng, giữ tối thiểu 30 ngày
⚠ Coldline ⚠ khoảng một lần/quý, tối thiểu 90 ngày
⚠ Archive ⚠ dưới một lần/năm, tối thiểu 365 ngày — rẻ nhất
⚠ Sao lưu thường dùng ⚠ Nearline hoặc Coldline, chuyển tự động bằng Lifecycle
⚠ Bảo vệ bản sao lưu khỏi bị xoá Cách
⚠ Bucket Lock / Retention Policy ⚠ không xoá được trước hạn, kể cả admin
⚠ Object Versioning ⚠ giữ phiên bản cũ khi ghi đè
⚠ Bucket riêng, project riêng ⚠ tách quyền khỏi môi trường production
⚠ Lý do ⚠ mã tống tiền hoặc thao tác nhầm sẽ xoá luôn bản sao lưu nếu cùng quyền
⚠ Ba con số của kế hoạch DR Con số
⚠ RTO ⚠ bao lâu thì khôi phục xong
⚠ RPO ⚠ chấp nhận mất bao nhiêu dữ liệu
⚠ Chi phí ⚠ RTO/RPO càng nhỏ càng đắt
⚠ Bốn mẫu DR ⚠ backup/restore → pilot light → warm standby → hot (multi-site)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ⚠ Đã BAO GIỜ thử khôi phục thật chưa | ⚠ quan trọng nhất | | Bản sao lưu có bị xoá cùng lúc với dữ liệu gốc được không | | | RTO và RPO thực tế có khớp cam kết không | |

Và sự thật phũ phàng về sao lưu: một bản sao lưu chưa bao giờ được khôi phục thử thì không phải là bản sao lưu, chỉ là một hy vọng.

Câu 34
As an Online education platform company, you need to develop an internal App Engine application that can access a user's Google Drive without relying on current user credentials, while following Google's recommended practices. What steps should you take to accomplish this using Google Cloud Services?
  1. A Generate a fresh Service account and assign Service Account User role to all the users of the application.
  2. B To ensure secure operations of the application, it is recommended to use a separate G Suite Admin account and authenticate the application's activities using these credentials.
  3. C To impersonate the user, you should create a new service account and provide it G Suite domain-wide delegation, which the application can use.
  4. D To grant access to all application users, a new Service account should be created and a Google Group should be created and all application users should be added to this group. Then, grant the Service Account User role to this group.
Xem giải thích

Đáp án

C — Tạo service account mới và cấp cho nó quyền uỷ nhiệm toàn miền (domain-wide delegation) của G Suite để mạo danh người dùng.

Vì sao đúng

⚠ Yêu cầu của đề: ứng dụng truy cập Google Drive của người dùng ⚠ mà KHÔNG cần thông tin đăng nhập của người đó tại thời điểm chạy.

⚠ Service account
        ↓ ⚠ được cấp domain-wide delegation
   (⚠ quản trị viên G Suite phê duyệt
     kèm danh sách phạm vi OAuth)
        ↓
⚠ Service account MẠO DANH người dùng
        ↓
⚠ Truy cập Drive của người đó
   ⚠ mà không cần họ đăng nhập

⚠ Đây là cơ chế Google thiết kế đúng cho ca dùng này — ứng dụng nền, tác vụ theo lịch.

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

  • A (tạo service account và cấp vai trò Service Account User cho mọi người dùng) — ⚠ hiểu ngược vai trò: ⚠ Service Account User cho phép người dùng dùng service account, ⚠ chứ không cho service account truy cập dữ liệu của người dùng.

  • D (tạo service account, tạo Google Group, thêm mọi người dùng, cấp Service Account User cho group) — ⚠ cùng lỗi với A, chỉ thêm một lớp nhóm.

  • B (dùng tài khoản quản trị G Suite riêng để xác thực mọi hoạt động của ứng dụng) — ⚠ cực kỳ nguy hiểm: ⚠ dùng tài khoản người thật cho ứng dụng, ⚠ quyền quản trị cao nhất, ⚠ mật khẩu nằm trong cấu hình, ⚠ và ⚠ audit log không phân biệt được ai làm gì.

Ghi nhớ

⚠ Domain-wide delegation — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Ai bật | ⚠ quản trị viên Google Workspace, trong Admin console | | ⚠ Khai gì | ⚠ Client ID của service account + danh sách phạm vi OAuth | | ⚠ Cho phép gì | ⚠ mạo danh BẤT KỲ người dùng nào trong miền | | ⚠ Rủi ro | ⚠ RẤT CAO — như chìa khoá vạn năng | | ⚠ Giảm rủi ro | ⚠ khai phạm vi HẸP NHẤT có thể |

Từ khoá nhận diện:

"truy cập Drive/Gmail của người dùng mà không cần họ đăng nhập" → ⚠ domain-wide delegation "người dùng bấm đồng ý cho ứng dụng" → ⚠ OAuth ba chân bình thường "Service Account User" → ⚠ cho NGƯỜI dùng service account, không phải ngược lại

⚠ Vì sao domain-wide delegation phải rất cẩn thận Lý do
⚠ Mạo danh được MỌI người, kể cả CEO
⚠ Người dùng KHÔNG được hỏi ý kiến
⚠ Khoá của service account đó bị lộ = toàn miền bị lộ
⚠ Không giới hạn được theo từng người dùng ⚠ chỉ giới hạn được theo phạm vi OAuth
⚠ Nên làm ⚠ service account chuyên biệt, không tạo khoá, rà soát định kỳ
⚠ Ba kiểu danh tính cần phân biệt Kiểu
⚠ Tài khoản người dùng ⚠ người thật, có mật khẩu, có 2FA
⚠ Service account ⚠ cho ứng dụng, không có mật khẩu
⚠ Google Group ⚠ gom quyền, không đăng nhập được
⚠ Đừng bao giờ ⚠ dùng tài khoản người thật cho ứng dụng chạy nền
⚠ Vì sao dùng tài khoản admin cho ứng dụng là sai Lý do
⚠ Quyền rộng hơn nhiều so với cần thiết
⚠ Người đó nghỉ việc là ứng dụng chết
⚠ Audit log ghi tên người, không biết là ứng dụng làm
⚠ 2FA làm ứng dụng không tự động hoá được ⚠ nên người ta tắt 2FA — càng tệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có service account nào có domain-wide delegation | ⚠ rà trong Admin console | | Phạm vi OAuth khai có hẹp không | ⚠ readonly thay vì full | | Có tài khoản người nào đang bị dùng làm tài khoản ứng dụng không | |

Và dấu hiệu rõ nhất của một hệ thống danh tính có vấn đề: một tài khoản mang tên người thật nhưng thực ra là một script đang chạy. Khi người đó nghỉ việc, không ai dám khoá tài khoản.

Câu 35
As a Crowdfunding platform company, how can you ensure that only the administrator has access to log files containing personally identifiable information (PII) while analysts only have access to logs without PII that are backed up to a Cloud Storage bucket shared by both parties utilizing the Google Cloud Storage service?
  1. A Both the shared bucket and the bucket exclusively accessible by the administrator must receive the logs. Use the Cloud DataLoss Prevention API to create a job trigger, and set it up to delete any files in the shared bucket that have PII.
  2. B To ensure that any uploaded file to the shared bucket is subjected to a Data Loss Prevention scan, make use of Cloud Pub/Sub and Cloud Functions. In the event that PII is detected during the scan, the function should then proceed to move the file to a Cloud Storage bucket that is strictly accessible by the administrator.
  3. C Configure Object Lifecycle Management on the shared bucket with both analysts and administrators to automatically delete objects that contain any Personally Identifiable Information (PII).
  4. D Set up a Cloud Storage Trigger on the bucket accessible to the analysts and administrator that only activates when personally identifiable information (PII) data is uploaded. Employ Cloud Functions to capture the trigger and remove these files.
Xem giải thích

Đáp án

B — Dùng Cloud Pub/Sub và Cloud Functions để mọi file tải lên bucket dùng chung đều được quét DLP; phát hiện PII thì hàm CHUYỂN file sang bucket chỉ quản trị viên truy cập được.

Vì sao đúng

⚠ Đề có hai yêu cầu, phải thoả cả hai: | Yêu cầu | Cách B giải | |---|---| | ⚠ Quản trị viên đọc được log CÓ PII | ⚠ file có PII được CHUYỂN sang bucket riêng — vẫn còn | | ⚠ Nhà phân tích chỉ thấy log KHÔNG PII | ⚠ file có PII rời khỏi bucket chung |

⚠ File tải lên bucket chung
        ↓ ⚠ thông báo qua Pub/Sub
⚠ Cloud Function chạy
        ↓ ⚠ gọi DLP quét
⚠ Có PII?
   ⚠ CÓ  → ⚠ CHUYỂN sang bucket admin
   ⚠ KHÔNG → ⚠ để nguyên chỗ cũ

⚠ Điểm quyết định: ⚠ CHUYỂN chứ không XOÁ — ⚠ quản trị viên vẫn cần dữ liệu đó.

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

  • A (ghi log vào cả hai bucket, DLP job trigger XOÁ file có PII ở bucket chung) — ⚠ gần đúng nhưng có cửa sổ rủi ro: ⚠ job trigger chạy theo lịch, ⚠ file có PII nằm ở bucket chung một khoảng thời gian trước khi bị xoá.

  • D (Cloud Storage Trigger chỉ kích hoạt khi PII được tải lên, Cloud Function XOÁ file) — ⚠ hai lỗi: ⚠ trigger không biết trước file có PII hay không (phải quét mới biết); ⚠ và ⚠ XOÁ là mất luôn dữ liệu quản trị viên cần.

  • C (Object Lifecycle Management tự xoá object chứa PII) — ⚠ Lifecycle KHÔNG đọc được nội dung: ⚠ nó chỉ làm việc theo tuổi, lớp lưu trữ, phiên bản, ⚠ hoàn toàn không biết PII là gì.

Ghi nhớ

⚠ Object Lifecycle Management làm được gì — bảng phải thuộc: | Điều kiện | Có làm được | |---|---| | ⚠ Tuổi của object | ⚠ CÓ | | ⚠ Ngày tạo, số phiên bản cũ | ⚠ CÓ | | ⚠ Lớp lưu trữ hiện tại | ⚠ CÓ | | ⚠ Hậu tố tên file | ⚠ CÓ | | ⚠ NỘI DUNG bên trong file | ⚠ KHÔNG — luôn là bẫy |

Từ khoá nhận diện:

"xử lý theo NỘI DUNG file" → ⚠ DLP + Cloud Functions, KHÔNG phải Lifecycle "chuyển sang lớp rẻ hơn sau N ngày" → ⚠ Lifecycle "phản ứng ngay khi file được tải lên" → ⚠ Cloud Storage notification → Pub/Sub → Function

⚠ Mẫu kiến trúc hướng sự kiện cho Cloud Storage Mẫu
⚠ Bucket phát thông báo sang Pub/Sub ⚠ gsutil notification create
⚠ Cloud Function hoặc Cloud Run đăng ký nhận
⚠ Xử lý xong thì ghi kết quả hoặc chuyển file
⚠ Ưu điểm ⚠ phản ứng trong vài giây, không phải chờ lịch
⚠ Nhớ ⚠ hàm phải chịu được gọi lặp (idempotent)
⚠ CHUYỂN so với XOÁ trong ngữ cảnh này So sánh
⚠ Chuyển: dữ liệu còn, chỉ đổi ai đọc được ⚠ đề yêu cầu vậy
⚠ Xoá: mất vĩnh viễn ⚠ quản trị viên cũng mất
⚠ Đọc kỹ đề ⚠ "chỉ quản trị viên truy cập" ≠ "không ai truy cập"
⚠ Cách còn tốt hơn nữa (ngoài phạm vi đề) Cách
⚠ Quét DLP TRƯỚC khi ghi vào bucket chung ⚠ không có cửa sổ rủi ro nào
⚠ Hoặc ghi thẳng vào bucket riêng rồi mới lọc ra bản sạch
⚠ Nguyên tắc ⚠ dữ liệu nhạy cảm không nên bao giờ chạm vào nơi công khai hơn, dù chỉ một giây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có khoảng thời gian nào file PII nằm ở bucket chung không | | | Hàm xử lý lỗi thì file ở đâu | ⚠ cần dead-letter queue | | IAM của hai bucket có thật sự khác nhau không | |

Và điều dễ bị bỏ qua trong mọi thiết kế kiểu "quét rồi chuyển": chuyện gì xảy ra khi hàm quét thất bại?. Nếu file cứ nằm nguyên tại chỗ khi có lỗi, thì thiết kế đó mở cửa đúng vào lúc nó cần đóng nhất.

Câu 36
An electric vehicle manufacturer company is moving to Google Cloud Platform to manage their online sales. The company wants to ensure payment information is secured between the customer's browser and GCP during the checkout process. What steps should they take to achieve this?
  1. A The task involves setting up encryption by configuring an SSL certificate on a network TCP load balancer.
  2. B To enable outbound traffic on port 443 while preventing all other outbound traffic, configure the firewall.
  3. C To enable inbound traffic on port 443, and restrict all other incoming traffic, adjust the firewall settings.
  4. D Set up SSL certificate on an L7 Load Balancer and mandate encryption.
Xem giải thích

Đáp án

D — Cài chứng chỉ SSL trên Load Balancer tầng 7 (L7) và bắt buộc mã hoá.

Vì sao đúng

⚠ Đề nêu: bảo vệ thông tin thanh toán trên đường từ trình duyệt khách tới Google Cloud trong lúc thanh toán.

⚠ Trình duyệt khách
        ↓ ⚠ HTTPS (TLS)
⚠ HTTP(S) Load Balancer (L7)
   ⚠ có chứng chỉ SSL
   ⚠ chuyển hướng HTTP → HTTPS
        ↓
⚠ Backend

⚠ Vì sao phải là L7: | Lý do | Nội dung | |---|---| | ⚠ Đây là lưu lượng web (HTTPS) | ⚠ L7 là loại đúng | | ⚠ Cưỡng chế chuyển hướng sang HTTPS | ⚠ chỉ L7 làm được | | ⚠ Dùng được Cloud Armor / WAF | ⚠ chỉ L7 hỗ trợ | | ⚠ Google quản chứng chỉ tự động | ⚠ Google-managed SSL certificate |

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

  • A (cài chứng chỉ SSL trên network TCP load balancer) — ⚠ Network LB KHÔNG kết thúc TLS: ⚠ nó là bộ cân bằng xuyên qua (pass-through) tầng 4, ⚠ không cài chứng chỉ được.

  • C (mở firewall cho cổng 443 vào, chặn phần còn lại) — ⚠ firewall không mã hoá gì cả: ⚠ mở cổng 443 chỉ cho phép lưu lượng đi qua, ⚠ không đảm bảo lưu lượng đó được mã hoá.

  • B (mở cổng 443 chiều RA, chặn phần còn lại) — ⚠ sai chiều và sai bản chất: ⚠ đây là lưu lượng khách hàng đi VÀO, không phải chiều ra.

Ghi nhớ

⚠ Mã hoá đường truyền — bảng phải thuộc: | Chặng | Cách bảo vệ | |---|---| | ⚠ Trình duyệt → Load Balancer | ⚠ TLS với chứng chỉ trên LB — đề này | | ⚠ Load Balancer → backend | ⚠ bật HTTPS ở backend service | | ⚠ Giữa các dịch vụ Google | ⚠ Google tự mã hoá mọi lưu lượng qua mạng công cộng | | ⚠ Dữ liệu khi lưu trữ | ⚠ mặc định mã hoá; CMEK nếu cần kiểm soát |

Từ khoá nhận diện:

"bảo vệ dữ liệu giữa trình duyệt và đám mây" → ⚠ TLS trên L7 LB "firewall mở cổng 443" → ⚠ KHÔNG phải mã hoá — luôn là bẫy "chặn tấn công tầng ứng dụng" → ⚠ Cloud Armor trên L7 LB "lưu lượng không phải HTTP nhưng cần TLS" → ⚠ SSL Proxy LB

⚠ Chứng chỉ SSL do Google quản lý Đặc điểm
⚠ Google tự cấp và tự GIA HẠN ⚠ không lo hết hạn
⚠ Miễn phí
⚠ Cần bản ghi DNS trỏ đúng vào LB trước
⚠ Mất vài chục phút tới vài giờ để cấp
⚠ Thay thế ⚠ chứng chỉ tự quản nếu cần EV hoặc wildcard riêng
⚠ Cưỡng chế HTTPS thế nào Cách
⚠ URL map chuyển hướng HTTP sang HTTPS ⚠ mã 301
⚠ Header HSTS ⚠ trình duyệt tự dùng HTTPS lần sau
⚠ Chính sách SSL: tối thiểu TLS 1.2 ⚠ loại bỏ giao thức cũ
⚠ Bộ mã hoá: dùng profile MODERN hoặc RESTRICTED
⚠ PCI DSS yêu cầu ⚠ tối thiểu TLS 1.2
⚠ Sai lầm hay gặp về "an toàn đường truyền" Sai lầm
⚠ Tưởng mở cổng 443 là đã mã hoá ⚠ cổng chỉ là con số
⚠ Tưởng có ổ khoá xanh là an toàn tuyệt đối ⚠ trang lừa đảo cũng có
⚠ Quên mã hoá chặng LB → backend ⚠ mã hoá đứt giữa đường
⚠ Để TLS 1.0/1.1 vẫn bật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy cập bằng HTTP có bị chuyển hướng không | | | Chính sách SSL tối thiểu là phiên bản nào | | | Chặng từ LB tới backend có mã hoá không | |

Và hiểu lầm dai dẳng nhất về bảo mật mạng: cổng và mã hoá là hai chuyện hoàn toàn khác nhau. Một firewall chỉ mở đúng cổng 443 vẫn có thể đang cho đi qua lưu lượng không mã hoá gì cả.

Câu 37
How should your team design the network for a Crowdfunding platform company to ensure that the backend database can only be accessed by the frontend application and not any other instances on the network using Google Cloud Services?
  1. A To ensure network isolation, it is recommended to establish connectivity between two VPC networks via Cloud VPN gateways. Therefore, the creation of two VPC networks is necessary.
  2. B To establish network isolation, it is recommended to create separate subnets for both the frontend application and database.
  3. C To achieve network isolation, it is recommended to establish two VPC networks and link them through VPC peering.
  4. D To enable access solely from the application to the database, establish an ingress firewall rule utilizing firewall tags.
Xem giải thích

Đáp án

D — Tạo quy tắc firewall chiều vào (ingress) dùng network tag để chỉ cho phép ứng dụng truy cập cơ sở dữ liệu.

Vì sao đúng

⚠ Bài toán: chỉ frontend gọi được database, ⚠ mọi instance khác trong mạng thì không.

⚠ VM frontend: tag "app"
⚠ VM database: tag "db"
        ↓
⚠ Firewall rule ingress:
   ⚠ target tag: "db"
   ⚠ source tag: "app"
   ⚠ cổng: 3306 (hoặc 5432)
   ⚠ action: allow
        ↓
⚠ Mọi VM khác bị chặn
   (⚠ luật mặc định deny ingress)

⚠ Vì sao dùng TAG thay vì dải IP: | Ưu điểm | Nội dung | |---|---| | ⚠ VM mới chỉ cần gắn tag là có quyền | ⚠ không sửa luật | | ⚠ Không phụ thuộc địa chỉ IP | ⚠ IP đổi khi tạo lại VM | | ⚠ Đọc luật là hiểu ngay ý định | |

⚠ Còn tốt hơn nữa: dùng service account làm nguồn/đích thay vì tag — ⚠ vì ai cũng gắn được tag, ⚠ nhưng gán service account thì cần quyền IAM.

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

  • B (tạo subnet riêng cho frontend và database) — ⚠ subnet KHÔNG cô lập gì cả: ⚠ trong cùng VPC, ⚠ mọi subnet gọi được nhau trừ khi có firewall rule chặn.

  • C (hai VPC nối bằng VPC peering) — ⚠ phức tạp quá mức và vẫn chưa đủ: ⚠ peering rồi thì ⚠ vẫn phải có firewall rule; ⚠ và ⚠ tách VPC làm quản trị nặng nề.

  • A (hai VPC nối bằng Cloud VPN gateway) — ⚠ còn tệ hơn C: ⚠ VPN giữa hai VPC trong cùng Google Cloud là ⚠ tốn kém và chậm không cần thiết; ⚠ vẫn phải có firewall rule.

Ghi nhớ

⚠ Firewall của Google Cloud — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Áp ở cấp | ⚠ VPC, tác dụng lên từng VM (không phải subnet) | | ⚠ Có trạng thái (stateful) | ⚠ cho vào thì chiều về tự động được phép | | ⚠ Mặc định chiều VÀO | ⚠ DENY tất cả | | ⚠ Mặc định chiều RA | ⚠ ALLOW tất cả | | ⚠ Độ ưu tiên | ⚠ 0–65535, SỐ NHỎ thắng |

Từ khoá nhận diện:

"chỉ tầng A gọi được tầng B" → ⚠ firewall rule với tag hoặc service account "subnet riêng là đủ cô lập" → ⚠ SAI — luôn là bẫy "chặn hoàn toàn giữa hai môi trường" → ⚠ VPC riêng, hoặc VPC Service Controls "chặn theo tên miền hoặc URL đi ra" → ⚠ Secure Web Proxy / Cloud NGFW

⚠ Ba cách chỉ định nguồn/đích trong firewall rule Cách
⚠ Dải IP (CIDR) ⚠ đơn giản, nhưng IP thay đổi
⚠ Network tag ⚠ linh hoạt, nhưng AI CŨNG GẮN ĐƯỢC nếu có quyền sửa VM
⚠ Service account ⚠ AN TOÀN NHẤT — cần quyền IAM mới gán được
⚠ Đề thi hỏi "an toàn hơn" ⚠ chọn service account
⚠ Vì sao subnet không phải ranh giới bảo mật Lý do
⚠ Trong một VPC, mọi subnet định tuyến được tới nhau
⚠ Subnet chỉ để chia dải IP và chọn vùng
⚠ Ranh giới bảo mật là FIREWALL RULE
⚠ Ranh giới mạnh hơn nữa ⚠ VPC riêng, project riêng, VPC Service Controls
⚠ Thực hành tốt cho firewall Thực hành
⚠ Bắt đầu bằng deny-all rồi mở dần
⚠ Đặt luật deny-all-egress ưu tiên thấp và mở từng đích ⚠ chống dữ liệu bị mang ra ngoài
⚠ Bật Firewall Rules Logging cho luật quan trọng
⚠ Dùng Firewall Insights tìm luật thừa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có luật nào cho phép 0.0.0.0/0 vào cổng quản trị không | ⚠ 22, 3389 — rất phổ biến và rất nguy hiểm | | Luật dùng tag hay service account | | | Chiều RA có bị giới hạn không | ⚠ mặc định mở toang |

Và điều mà nhiều nhóm chỉ nhận ra sau sự cố: chiều đi ra mặc định được phép hết. Một máy chủ bị chiếm quyền có thể gửi dữ liệu đi bất cứ đâu, và không có luật nào ngăn lại.

Câu 38
As an Artificial Intelligence consulting firm, how can we collaborate with Infrastructure Operations Engineers to ensure that Windows Compute Engine VMs on Google Cloud are updated with the latest OS patches for an application that leverages the elastic nature of cloud computing?
  1. A Provision new serving Instance Groups (IGs) with updated VMs using Deployment Manager.
  2. B To ensure security, create fresh base images whenever there are new patches, and then leverage a continuous integration/continuous delivery pipeline to gradually deploy rebuilt VMs.
  3. C Integrate a Domain Controller with Compute Engine and apply Group Policy Object to implement weekly patches.
  4. D During the weekly maintenance window, it is recommended to restart all VMs and enable the StartUp Script to fetch the most recent patches from the internet.
Xem giải thích

Đáp án

B — Tạo ảnh nền (base image) mới mỗi khi có bản vá, rồi dùng đường ống CI/CD triển khai dần các VM được dựng lại.

Vì sao đúng

⚠ Đề nhấn "tận dụng tính co giãn của đám mây" → ⚠ VM được tạo và huỷ liên tục.

⚠ Có bản vá Windows mới
        ↓
⚠ Dựng ẢNH NỀN mới đã vá sẵn
        ↓ ⚠ CI/CD
⚠ Cập nhật instance template
        ↓
⚠ Rolling update: VM cũ bị thay
   dần bằng VM mới
        ↓
⚠ Mọi VM MỚI sinh ra đều đã vá

⚠ Đây là hạ tầng bất biến (immutable infrastructure): ⚠ không vá máy đang chạy, mà thay máy bằng máy mới đã vá.

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

  • A (dựng Instance Group mới với VM đã cập nhật bằng Deployment Manager) — ⚠ gần đúng nhưng thiếu tính lặp lại: ⚠ không nói tới ⚠ ảnh nền được vá hay ⚠ quy trình tự động liên tục; ⚠ Deployment Manager cũng đã bị Google khuyến nghị thay bằng Infrastructure Manager / Terraform.

  • C (nối Domain Controller với Compute Engine, dùng Group Policy vá hằng tuần) — ⚠ mô hình của trung tâm dữ liệu truyền thống: ⚠ với VM tự sinh liên tục, ⚠ máy mới luôn chưa vá cho tới đợt GPO tiếp theo; ⚠ và ⚠ tạo phụ thuộc nặng vào Domain Controller.

  • D (khởi động lại mọi VM trong cửa sổ bảo trì, dùng startup script tải bản vá từ Internet) — ⚠ nhiều vấn đề cùng lúc: ⚠ mỗi VM tự tải bản vá là ⚠ chậm và không nhất quán; ⚠ VM có thể vá phiên bản khác nhau; ⚠ và ⚠ cửa sổ bảo trì mâu thuẫn với tính co giãn.

Ghi nhớ

⚠ Hạ tầng bất biến so với vá tại chỗ — bảng phải thuộc: | Tiêu chí | ⚠ Bất biến (thay máy) | ⚠ Vá tại chỗ | |---|---|---| | ⚠ Tính nhất quán | ⚠ mọi máy giống hệt nhau | ⚠ trôi dần, mỗi máy một khác | | ⚠ Quay lui | ⚠ đổi lại ảnh cũ | ⚠ rất khó | | ⚠ Máy mới tự sinh | ⚠ đã vá sẵn | ⚠ chưa vá | | ⚠ Thời gian | ⚠ lâu hơn cho mỗi lần | ⚠ nhanh | | ⚠ Đám mây co giãn | ⚠ BẮT BUỘC dùng cách bất biến | |

Từ khoá nhận diện:

"VM tự sinh liên tục, phải luôn được vá" → ⚠ ảnh nền mới + CI/CD + rolling update "vá VM đang chạy theo lịch" → ⚠ VM Manager / OS Patch Management — cho VM tồn tại lâu "Group Policy, Domain Controller" → ⚠ mô hình cũ, thường là bẫy trong đề đám mây

⚠ Đường ống dựng ảnh nền Bước
⚠ Bắt đầu từ ảnh công khai của Google
⚠ Cài bản vá và phần mềm cần thiết ⚠ Packer hoặc Cloud Build
⚠ Chạy kiểm thử và quét lỗ hổng
⚠ Đưa vào image family ⚠ template luôn trỏ tới bản mới nhất của family
⚠ Rolling update cho MIG ⚠ thay dần, có maxSurge và maxUnavailable
⚠ VM Manager — khi nào vẫn dùng Trường hợp
⚠ VM tồn tại lâu, không thể dựng lại ⚠ CSDL, máy chủ trạng thái
⚠ Báo cáo tình trạng vá lỗi (patch compliance)
⚠ Kiểm kê phần mềm cài trên VM
⚠ Đừng nhầm ⚠ VM Manager KHÔNG thay thế được ảnh nền bất biến cho MIG
⚠ Vì sao "vá lỗi" là câu hỏi bảo mật Lý do
⚠ Phần lớn xâm nhập lợi dụng lỗ hổng ĐÃ có bản vá
⚠ Máy chưa vá là cửa mở suốt ngày đêm
⚠ Máy tự sinh chưa vá thì việc vá thủ công vô nghĩa
⚠ Chỉ số nên đo ⚠ tuổi trung bình của ảnh nền đang chạy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh nền đang dùng cũ bao nhiêu ngày | | | VM mới tự sinh có ảnh đã vá không | | | Quay lui về ảnh trước mất bao lâu | |

Và chỉ số đơn giản nhất cho sức khoẻ bảo mật hạ tầng: tuổi của ảnh nền. Nếu con số đó tính bằng tháng, thì mọi máy vừa được tạo ra sáng nay đều đang chạy phần mềm cũ hàng tháng trời.

Câu 39
How can a Logistics and shipping solution company ensure that Compute Engine instances in their production project do not have public IP addresses while allowing frontend application Compute Engine instances to have public IPs, using the Google Cloud service, and ensuring that only team members with the appropriate role can modify resources?
  1. A To ensure secure connectivity, it is recommended to activate Private Access for the VPC network in the production project.
  2. B Create a Virtual Private Cloud (VPC) that consists of two subnetworks: one that has public IP addresses and another that does not have public IP addresses.
  3. C Revoke the Editor permission and assign the Compute Admin IAM role to the engineers.
  4. D Establish an organizational guideline that exclusively allows front-end Compute Engine instances to use public IPs.
Xem giải thích

Đáp án

D — Thiết lập một chính sách ở cấp tổ chức chỉ cho phép các instance frontend có địa chỉ IP công khai.

Vì sao đúng

⚠ Đề có hai vế, Organization Policy giải cả hai: | Vế | Cách giải | |---|---| | ⚠ VM production KHÔNG được có IP công khai | ⚠ chính sách CHẶN ở cấp tổ chức | | ⚠ Chỉ frontend được có | ⚠ danh sách ngoại lệ trong chính sách | | ⚠ Chỉ đúng người sửa được | ⚠ chỉ Organization Policy Administrator đổi được |

⚠ Ràng buộc cụ thể: ⚠ constraints/compute.vmExternalIpAccess — ⚠ liệt kê danh sách cho phép các instance được gán IP ngoài.

⚠ Cấp TỔ CHỨC: cấm IP công khai
        ↓ ⚠ kế thừa xuống mọi folder, project
⚠ Ngoại lệ cho VM frontend
        ↓
⚠ Kỹ sư dù có quyền Compute Admin
   ⚠ VẪN KHÔNG gán được IP công khai

⚠ Điểm mạnh: ⚠ Organization Policy thắng cả IAM — ⚠ có quyền tạo VM cũng không lách được.

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

  • C (thu hồi quyền Editor, cấp vai trò Compute Admin) — ⚠ IAM không chặn được hành vi này: ⚠ Compute Admin vẫn gán được IP công khai; ⚠ IAM trả lời "ai được làm", ⚠ không trả lời "được làm THẾ NÀO".

  • B (tạo VPC với hai subnet, một có IP công khai một không) — ⚠ subnet không quyết định IP ngoài: ⚠ IP công khai gán cho từng instance, ⚠ không phụ thuộc subnet.

  • A (bật Private Access cho VPC ở project production) — ⚠ giải quyết chuyện khác: ⚠ Private Google Access cho phép VM không có IP ngoài vẫn gọi được API Google; ⚠ nó không NGĂN việc gán IP ngoài.

Ghi nhớ

⚠ Organization Policy so với IAM — bảng phải thuộc: | Tiêu chí | ⚠ Organization Policy | ⚠ IAM | |---|---|---| | ⚠ Trả lời câu hỏi | ⚠ ĐƯỢC LÀM GÌ trên tài nguyên | ⚠ AI được làm | | ⚠ Kế thừa | ⚠ từ tổ chức xuống folder, project | ⚠ cũng kế thừa | | ⚠ Ai vượt được | ⚠ KHÔNG AI, kể cả Owner | ⚠ Owner làm được nhiều thứ | | ⚠ Dùng cùng nhau | ⚠ hàng rào cứng | ⚠ phân quyền chi tiết |

Từ khoá nhận diện:

"cấm toàn tổ chức làm điều gì đó" → ⚠ Organization Policy "ai được truy cập tài nguyên nào" → ⚠ IAM "VM không có IP ngoài vẫn gọi được API Google" → ⚠ Private Google Access "chặn dữ liệu ra khỏi ranh giới" → ⚠ VPC Service Controls

⚠ Ràng buộc tổ chức hay gặp trong đề Ràng buộc
⚠ compute.vmExternalIpAccess ⚠ cấm IP công khai — đề này
⚠ compute.trustedImageProjects ⚠ chỉ dùng ảnh từ project tin cậy
⚠ iam.disableServiceAccountKeyCreation ⚠ cấm tạo khoá service account
⚠ storage.uniformBucketLevelAccess ⚠ bắt dùng IAM thay ACL
⚠ gcp.resourceLocations ⚠ giới hạn vùng được tạo tài nguyên
⚠ sql.restrictPublicIp ⚠ cấm Cloud SQL có IP công khai
⚠ Hai kiểu ràng buộc Kiểu
⚠ Boolean ⚠ bật/tắt — ví dụ cấm tạo khoá SA
⚠ List ⚠ danh sách cho phép hoặc từ chối
⚠ Kế thừa ⚠ project con có thể ghi đè nếu chính sách cha cho phép
⚠ Muốn cứng ⚠ đặt enforce ở cấp tổ chức và không cho ghi đè
⚠ Vì sao VM không nên có IP công khai Lý do
⚠ IP công khai là bề mặt tấn công trực tiếp ⚠ bị quét liên tục
⚠ Cần ra Internet thì dùng Cloud NAT
⚠ Cần SSH thì dùng IAP TCP forwarding
⚠ Cần gọi API Google thì dùng Private Google Access
⚠ Không có lý do chính đáng nào ⚠ để VM backend có IP công khai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có VM nào đang có IP công khai không cần thiết không | | | Chính sách đặt ở cấp nào | ⚠ tổ chức thì mọi project mới đều được bảo vệ | | Đã có Cloud NAT và IAP forwarding chưa | ⚠ để thay thế IP công khai |

Và điều Organization Policy làm được mà IAM không bao giờ làm được: ngăn cả người có quyền cao nhất khỏi một hành động cụ thể. Đó là khác biệt giữa "tin tưởng con người" và "hàng rào không thể lách".

Câu 40
As a cybersecurity software provider company, how can you restrict the selection of images that can be utilized as the source for boot disks in a dedicated project in Google Cloud?
  1. A At the organization level, utilize the Organization Policy Service to establish a constraint for compute.trustedimageProjects. Specify the trusted projects as exceptions in a denial operation.
  2. B To enforce security, you can utilize the Organization Policy Service to establish a constraint for compute.trustedimageProjects at the organization level. This can be achieved by configuring a whitelist of trusted projects in an allow operation.
  3. C To grant Compute Image User access, you can add the project ID as a member with the appropriate role in the Resource Manager's organization permissions settings.
  4. D To grant access to a trusted project in Resource Manager, modify the project permissions and assign the role of Compute ImageUser to the organization as a member.
Xem giải thích

Đáp án

B — Dùng Organization Policy Service đặt ràng buộc compute.trustedImageProjects ở cấp tổ chức, cấu hình danh sách CHO PHÉP các project tin cậy.

Vì sao đúng

⚠ Bài toán: giới hạn những ảnh nào được dùng làm đĩa khởi động trong một project.

⚠ Ràng buộc compute.trustedImageProjects
        ↓ ⚠ danh sách CHO PHÉP (allow list)
   ⚠ projects/công-ty-images-đã-duyệt
   ⚠ projects/debian-cloud (nếu muốn)
        ↓
⚠ Mọi ảnh KHÁC bị từ chối
   ⚠ ngay khi tạo VM

⚠ Vì sao phải là danh sách CHO PHÉP chứ không phải TỪ CHỐI: | Kiểu | Vấn đề | |---|---| | ⚠ Cho phép (allow) | ⚠ mặc định CẤM, chỉ mở đúng cái đã duyệt — AN TOÀN | | ⚠ Từ chối (deny) | ⚠ mặc định CHO, phải liệt kê hết cái xấu — không bao giờ liệt kê hết |

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

  • A (đặt cùng ràng buộc nhưng dùng phép TỪ CHỐI với project tin cậy làm ngoại lệ) — ⚠ logic ngược: ⚠ đặt project tin cậy vào danh sách từ chối là ⚠ cấm đúng thứ mình muốn cho phép.

  • C (thêm project ID làm thành viên với vai trò Compute Image User trong Resource Manager) — ⚠ IAM CHO PHÉP dùng ảnh, không GIỚI HẠN ảnh nào được dùng: ⚠ hai chuyện khác nhau.

  • D (cấp vai trò Compute ImageUser cho tổ chức) — ⚠ cùng lỗi với C và còn mở rộng hơn: ⚠ cấp quyền chứ không giới hạn.

Ghi nhớ

⚠ IAM cấp quyền, Organization Policy giới hạn — bảng phải thuộc: | Muốn gì | Dùng gì | |---|---| | ⚠ CHO ai đó dùng ảnh của project khác | ⚠ IAM: vai trò compute.imageUser | | ⚠ GIỚI HẠN chỉ được dùng ảnh nào | ⚠ Organization Policy: trustedImageProjects | | ⚠ Cần cả hai | ⚠ thường phải dùng song song |

Từ khoá nhận diện:

"chỉ được dùng ảnh đã duyệt" → ⚠ compute.trustedImageProjects với allow list "chỉ chạy container đã ký" → ⚠ Binary Authorization "cấp quyền đọc ảnh giữa các project" → ⚠ vai trò compute.imageUser

⚠ Vì sao kiểm soát ảnh nền quan trọng Lý do
⚠ Ảnh từ nguồn không rõ có thể chứa mã độc
⚠ Ảnh cũ chứa lỗ hổng chưa vá
⚠ Ảnh công khai trên Marketplace không phải cái nào cũng được kiểm
⚠ Ảnh nội bộ đã duyệt thì kiểm soát được cấu hình cơ sở
⚠ Kết hợp ⚠ ảnh nền chuẩn + quét lỗ hổng + image family
⚠ Mẫu quản lý ảnh nền chuẩn (golden image) Mẫu
⚠ Một project riêng chứa ảnh đã duyệt
⚠ Đường ống tự động dựng ảnh, quét, đưa vào family
⚠ Đánh dấu ảnh cũ là DEPRECATED ⚠ không xoá ngay, cảnh báo trước
⚠ Organization Policy chỉ cho dùng project đó
⚠ Kết quả ⚠ mọi VM trong tổ chức đều xuất phát từ cùng một cơ sở đã kiểm
⚠ Allow list so với deny list — nguyên tắc chung Nguyên tắc
⚠ Bảo mật luôn ưu tiên ALLOW LIST ⚠ mặc định từ chối
⚠ Deny list luôn thiếu sót ⚠ cái mới xuất hiện là lọt
⚠ Áp dụng cho firewall, ảnh, tên miền, phần mềm
⚠ Đề thi ⚠ thấy hai phương án allow/deny thì chọn allow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ràng buộc đặt ở cấp tổ chức hay từng project | ⚠ cấp tổ chức thì project mới cũng được bảo vệ | | Project ảnh đã duyệt có ai ghi vào được không | ⚠ quyền ghi ở đó rất nhạy cảm | | Ảnh trong family cũ bao nhiêu ngày | |

Và nguyên tắc gọn nhất rút ra từ cả hai câu về Organization Policy: cho phép cái đã biết là tốt, cấm cái đã biết là không bao giờ đủ.