Ngân hàng đề — Google Cloud Professional Cloud Security Engineer
Tìm thấy 395 câu.
- A The Web Security Scanner is a tool provided by Google Cloud that can automatically scan web applications for security vulnerabilities.
- B Cloud Armor is a Google Cloud service that provides security for internet-facing services against distributed denial of service (DDoS) attacks.
- C The Audit Logs in Google Cloud.
- D The identification of unusual or unexpected events, patterns, or behaviors in a system or dataset is referred to as anomaly detection.
Xem giải thích
Đáp án
A — Web Security Scanner: công cụ của Google Cloud tự động quét ứng dụng web tìm lỗ hổng bảo mật.
Vì sao đúng
Đề cần kiểm tra lỗ hổng OWASP cho ứng dụng chạy trên App Engine. Web Security Scanner sinh ra đúng cho việc đó.
⚠ Web Security Scanner làm gì:
⚠ TỰ ĐỘNG duyệt (crawl) ứng dụng web
↓
⚠ Thử các mẫu tấn công phổ biến
→ ⚠ XSS (cross-site scripting)
→ ⚠ Flash injection
→ ⚠ nội dung hỗn hợp HTTP/HTTPS
→ ⚠ thư viện lỗi thời
→ ⚠ mật khẩu dạng rõ
↓
⚠ Báo cáo lỗ hổng tìm được
⚠ Hỗ trợ App Engine, Compute Engine và GKE — đúng môi trường đề nêu.
Vì sao các phương án khác sai
-
B (Cloud Armor) — ⚠ bẫy gần nhất: Cloud Armor CHẶN tấn công (DDoS, WAF), ⚠ nhưng không QUÉT để tìm lỗ hổng trong mã của bạn. ⚠ Nó phòng thủ, không kiểm tra.
-
C (Audit Logs) — ⚠ ghi lại ai đã làm gì trên tài nguyên Google Cloud, ⚠ không quét ứng dụng web.
-
D (phát hiện bất thường — anomaly detection) — ⚠ mô tả một khái niệm chung, không phải công cụ quét lỗ hổng OWASP.
Ghi nhớ
⚠ Bốn công cụ bảo mật ứng dụng — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Web Security Scanner | ⚠ QUÉT tìm lỗ hổng OWASP — đề này | | ⚠ Cloud Armor | ⚠ CHẶN tấn công: WAF, DDoS | | Container/Artifact Analysis | ⚠ quét CVE trong image | | Security Command Center | ⚠ tổng hợp phát hiện bảo mật | | Audit Logs | ⚠ ai làm gì |
Từ khoá nhận diện:
"quét lỗ hổng OWASP, XSS" → ⚠ Web Security Scanner "chặn DDoS, WAF" → ⚠ Cloud Armor "lỗ hổng trong container image" → ⚠ Artifact Analysis "ai truy cập cái gì" → Audit Logs
| ⚠ Lưu ý quan trọng khi dùng Web Security Scanner | Lưu ý |
|---|---|
| ⚠ Nó THẬT SỰ gửi request tấn công | ⚠ có thể tạo dữ liệu rác |
| ⚠ Có thể kích hoạt form, gửi email, tạo bản ghi | |
| ⚠ CHẠY TRÊN MÔI TRƯỜNG TEST trước | ⚠ hoặc dùng tài khoản test |
| ⚠ Loại trừ URL nguy hiểm | ⚠ nút xoá, thanh toán |
| Lịch chạy | ⚠ đặt định kỳ, không chỉ một lần |
| ⚠ OWASP Top 10 — nhóm lỗ hổng cần biết | Nhóm |
|---|---|
| ⚠ Injection | ⚠ SQL, command injection |
| ⚠ Xác thực hỏng | |
| ⚠ Lộ dữ liệu nhạy cảm | |
| ⚠ Cấu hình sai bảo mật | |
| ⚠ XSS | |
| Thành phần có lỗ hổng đã biết | ⚠ thư viện cũ |
| ⚠ Quét là chưa đủ | Cần thêm |
|---|---|
| ⚠ Quét mã nguồn (SAST) | ⚠ tìm lỗi trước khi chạy |
| ⚠ Quét phụ thuộc (SCA) | |
| ⚠ Cloud Armor chặn ở tầng mạng | |
| Kiểm thử xâm nhập thủ công | ⚠ máy không tìm được lỗi logic nghiệp vụ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quét chạy trên môi trường nào | ⚠ đừng quét thẳng sản xuất lần đầu | | Có URL nguy hiểm nào chưa loại trừ không | | | Kết quả quét có ai xử lý không | ⚠ báo cáo không đọc là vô ích |
Và cảnh báo quan trọng nhất về Web Security Scanner: nó tương tác THẬT với ứng dụng của bạn. Chạy lần đầu trên sản xuất mà không loại trừ các thao tác nguy hiểm có thể tạo ra hàng nghìn bản ghi rác — hoặc tệ hơn.
- A To add the customer and employee user accounts, you can upload an .htaccess file to App Engine.
- B To grant access to customer and employee user accounts, you can activate Cloud Identity-Aware Proxy (IAP) and authorize access to a Google Group.
- C The recommended solution is to establish a VPN connection between the on-premises networks and the Virtual Private Cloud (VPC) network on Google Cloud Platform using Cloud VPN.
- D To restrict any unauthorized network traffic, set up a firewall rule in the App Engine that permits access only from the customer and employee networks while blocking all other traffic.
Xem giải thích
Đáp án
B — Bật Cloud Identity-Aware Proxy (IAP) và cấp quyền truy cập cho một Google Group.
Vì sao đúng
Đề nêu hai ràng buộc, và IAP đáp ứng cả hai:
⚠ Hai ràng buộc:
"chỉ nhân viên công ty và khách hàng
được uỷ quyền"
→ ⚠ kiểm soát theo DANH TÍNH
"từ BẤT KỲ ĐÂU"
→ ⚠ KHÔNG dựa vào địa chỉ IP
→ ⚠ loại mọi giải pháp mạng
⚠ IAP hoạt động thế nào:
⚠ Đặt trước ứng dụng
↓
⚠ Người dùng phải ĐĂNG NHẬP
bằng danh tính Google
↓
⚠ IAP kiểm quyền IAM
↓
⚠ Có quyền → cho qua
⚠ Không → chặn
↓
⚠ Không phụ thuộc vị trí mạng
Vì sao các phương án khác sai
-
D (đặt firewall rule chỉ cho phép mạng của khách và nhân viên) — ⚠ bẫy phổ biến: ⚠ dựa vào địa chỉ IP, ⚠ nhưng đề nói "từ bất kỳ đâu" — người dùng làm việc từ nhà, quán cà phê, đi công tác.
-
C (dựng Cloud VPN giữa mạng tại chỗ và VPC) — ⚠ cùng vấn đề: buộc người dùng phải ở trong mạng công ty hoặc kết nối VPN.
-
A (tải file
.htaccesslên App Engine) — ⚠ không hoạt động: ⚠ App Engine không dùng.htaccessnhư Apache; và ⚠ xác thực dạng đó rất yếu.
Ghi nhớ
⚠ IAP — điểm cốt lõi — bảng phải thuộc: | Điểm | Nội dung | |---|---| | ⚠ Kiểm soát theo DANH TÍNH, không theo mạng | ⚠ nền tảng của BeyondCorp | | ⚠ Hoạt động từ bất kỳ đâu | | | ⚠ Dùng IAM để phân quyền | ⚠ cấp cho Google Group tiện quản lý | | ⚠ Không cần VPN | | | Hỗ trợ | ⚠ App Engine, Compute Engine, GKE, Cloud Run |
Từ khoá nhận diện:
"kiểm soát theo danh tính, từ bất kỳ đâu" → ⚠ IAP "chỉ từ mạng công ty" → ⚠ firewall / VPN — không hợp với làm việc từ xa ".htaccess" → ⚠ không áp dụng cho App Engine
| ⚠ Mô hình BeyondCorp — nguyên tắc | Nguyên tắc |
|---|---|
| ⚠ KHÔNG tin mạng nội bộ mặc định | ⚠ zero trust |
| ⚠ Xác thực và uỷ quyền theo TỪNG request | |
| ⚠ Danh tính + trạng thái thiết bị + ngữ cảnh | |
| ⚠ Không cần VPN để làm việc từ xa | |
| Kết quả | ⚠ vị trí mạng không còn quyết định quyền truy cập |
| ⚠ Vì sao cấp quyền cho GOOGLE GROUP | Lý do |
|---|---|
| ⚠ Thêm/bớt người chỉ cần sửa nhóm | |
| ⚠ Không phải sửa chính sách IAM mỗi lần | |
| ⚠ Nhân viên nghỉ → xoá khỏi nhóm là mất quyền mọi nơi | |
| Kiểm toán dễ hơn | |
| ⚠ Thực hành chuẩn | ⚠ cấp quyền cho NHÓM, không cho cá nhân |
| ⚠ Nâng cao với Context-Aware Access | Nâng cao |
|---|---|
| ⚠ Thêm điều kiện: thiết bị được quản lý | |
| ⚠ Thêm điều kiện: vị trí địa lý | |
| ⚠ Thêm điều kiện: mức bảo mật thiết bị | |
| Kết hợp với IAP | ⚠ danh tính ĐÚNG + ngữ cảnh AN TOÀN |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai truy cập được ứng dụng mà không qua IAP không | ⚠ kiểm đường vòng | | Quyền cấp cho nhóm hay cá nhân | | | Người rời công ty có mất quyền ngay không | |
Và điều IAP thay đổi căn bản: vị trí mạng không còn là cơ sở để tin tưởng ai. Trong thời làm việc từ xa, "chỉ cho phép IP văn phòng" vừa bất tiện vừa không an toàn hơn — vì kẻ tấn công vào được mạng nội bộ thì cũng có IP đó.
- A Eliminate any superfluous tools that are not required by the application.
- B For the application, it is recommended to utilize public container images as the base image and incorporate multiple container image layers to conceal confidential data.
- C Create a container for a single application.
- D Make sure that the app is not executed as PID 1.
Xem giải thích
Đáp án
A và C — loại bỏ công cụ thừa, và mỗi container chỉ chạy một ứng dụng
Vì sao đúng
Hai nguyên tắc nền của container an toàn:
- A. Bỏ công cụ thừa — mỗi gói còn lại trong ảnh là một bề mặt tấn công và một nguồn lỗ hổng phải vá. Ảnh tối giản (distroless chẳng hạn) không có shell, nên kẻ tấn công vào được cũng không có công cụ nào để dùng tiếp.
- C. Một ứng dụng một container — giới hạn phạm vi thiệt hại khi bị xâm nhập, và giúp cập nhật hay thay thế từng phần độc lập.
Vì sao các phương án khác sai
- B. Dùng ảnh container công khai — ảnh từ nguồn không kiểm soát có thể chứa mã độc hoặc lỗ hổng chưa vá; nên xây từ ảnh nền tin cậy và tự quét.
- D. Đảm bảo ứng dụng không chạy dưới PID 1 — thực ra chạy đúng PID 1 là chuyện bình thường trong container; điều đáng lo là tiến trình PID 1 phải xử lý tín hiệu dừng cho tử tế.
- A After signing in through an OpenID (OIDC) compatible Identity Provider, users receive an authentication token which they can utilize to access the GCP Console.
- B The GCP Console can be accessed by users using their credentials from your on-premises Kerberos compliant identity provider.
- C Google Cloud Directory Sync enables the synchronization of data between a Google domain and an already existing Active Directory or LDAP server.
- D You can synchronize the data in your existing Active Directory or LDAP server with your Google domain manually.
Xem giải thích
Đáp án
C — Google Cloud Directory Sync (GCDS) cho phép đồng bộ dữ liệu giữa một domain Google và máy chủ Active Directory hoặc LDAP đã có.
Vì sao đúng
Đề nêu ba yêu cầu, và GCDS là công cụ chuẩn cho tất cả:
⚠ Ba yêu cầu:
"tiếp tục dùng AD/LDAP đã có"
→ ⚠ giữ nguồn danh tính hiện tại
"SSO bằng mật khẩu"
→ ⚠ người dùng dùng đúng mật khẩu cũ
"SỐ LƯỢNG LỚN người dùng"
→ ⚠ phải TỰ ĐỘNG, không làm tay
⚠ GCDS làm gì:
⚠ Chạy TẠI CHỖ, đọc AD/LDAP
↓
⚠ Đồng bộ MỘT CHIỀU sang Google domain
→ ⚠ người dùng, nhóm, tổ chức
↓
⚠ AD/LDAP vẫn là NGUỒN SỰ THẬT
↓
⚠ Kết hợp SAML SSO để xác thực
⚠ Quan trọng: GCDS đồng bộ DANH TÍNH; việc XÁC THỰC vẫn do IdP tại chỗ đảm nhiệm qua SAML.
Vì sao các phương án khác sai
-
D (đồng bộ THỦ CÔNG dữ liệu AD/LDAP với Google domain) — ⚠ không khả thi: đề nói số lượng lớn người dùng; ⚠ làm tay là sai sót và không cập nhật kịp.
-
A (đăng nhập qua IdP hỗ trợ OIDC rồi nhận token) — ⚠ không giải quyết đồng bộ danh tính: ⚠ Google Cloud vẫn cần biết những người dùng đó tồn tại.
-
B (dùng thẳng thông tin đăng nhập từ IdP Kerberos tại chỗ) — ⚠ Google Cloud không hỗ trợ Kerberos trực tiếp cho việc đăng nhập Console.
Ghi nhớ
⚠ Hai việc tách bạch trong quản lý danh tính — bảng phải thuộc: | Việc | Công cụ | |---|---| | ⚠ ĐỒNG BỘ danh tính | ⚠ GCDS — đưa user/group từ AD sang Google — đề này | | ⚠ XÁC THỰC | ⚠ SAML SSO tới IdP tại chỗ (ADFS, Okta…) | | Cấp quyền | ⚠ IAM trên Google Cloud | | ⚠ Cần cả ba | ⚠ thiếu một là không hoàn chỉnh |
Từ khoá nhận diện:
"giữ AD/LDAP, nhiều người dùng" → ⚠ GCDS "đăng nhập bằng mật khẩu công ty" → ⚠ SAML SSO "đồng bộ thủ công" → ⚠ không khả thi ở quy mô "Kerberos trực tiếp" → ⚠ không hỗ trợ
| ⚠ Đặc điểm GCDS cần nhớ | Đặc điểm |
|---|---|
| ⚠ Đồng bộ MỘT CHIỀU | ⚠ AD → Google, không ngược lại |
| ⚠ AD là nguồn sự thật | |
| ⚠ Chạy tại chỗ, theo lịch | |
| ⚠ KHÔNG đồng bộ mật khẩu mặc định | ⚠ xác thực qua SSO |
| Có chế độ chạy thử | ⚠ xem trước sẽ thay đổi gì — RẤT nên dùng |
| ⚠ Rủi ro khi cấu hình GCDS sai | Rủi ro |
|---|---|
| ⚠ Bộ lọc sai → XOÁ hàng loạt tài khoản Google | ⚠ rủi ro nghiêm trọng nhất |
| ⚠ Luôn chạy chế độ thử trước | |
| ⚠ Đặt giới hạn tỷ lệ xoá | ⚠ chặn xoá quá nhiều trong một lần |
| Kiểm báo cáo trước khi áp dụng |
| ⚠ Vòng đời tài khoản | Vòng đời |
|---|---|
| ⚠ Nhân viên vào → AD → GCDS → có tài khoản Google | |
| ⚠ Nhân viên nghỉ → tắt trong AD → GCDS → mất quyền | |
| ⚠ Đây là lợi ích lớn nhất | ⚠ quản lý vòng đời TẬP TRUNG |
| Không có GCDS | ⚠ tài khoản người đã nghỉ tồn tại mãi |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chạy chế độ thử chưa | ⚠ bắt buộc trước lần đồng bộ đầu | | Có giới hạn tỷ lệ xoá chưa | | | Nhân viên nghỉ có mất quyền GCP không | ⚠ thử với một tài khoản test |
Và lợi ích quan trọng nhất của việc đồng bộ danh tính từ AD: khi ai đó rời công ty, tắt tài khoản ở một nơi là mất quyền ở mọi nơi. Không có nó thì mỗi hệ thống là một danh sách người cũ chưa ai dọn.
- A The networking team should be given Compute Admin role for every engineering project.
- B Implement a hub and spoke model by creating a Cloud VPN Gateway that connects all engineering projects.
- C A Shared VPC Network consists of a host project and multiple service projects.
- D Implementing a hub and spoke model for VPC peering across all engineering projects.
Xem giải thích
Đáp án
C — Shared VPC Network gồm một host project và nhiều service project.
Vì sao đúng
Đề nêu ba yêu cầu, và Shared VPC đáp ứng cả ba:
⚠ Ba yêu cầu:
"TẬP TRUNG quản lý firewall, subnet, route"
→ ⚠ tất cả nằm ở HOST project
"tài nguyên tại chỗ truy cập GCP
qua VPN riêng"
→ ⚠ một kết nối VPN ở host project
→ ⚠ mọi service project dùng chung
"đội bảo mật mạng KIỂM SOÁT tài nguyên mạng"
→ ⚠ chỉ họ có quyền trên host project
⚠ Mô hình Shared VPC:
⚠ HOST PROJECT
→ ⚠ chứa VPC, subnet, firewall, route
→ ⚠ đội mạng quản lý
⚠ SERVICE PROJECT
→ ⚠ chứa VM, GKE của từng đội
→ ⚠ DÙNG mạng của host
→ ⚠ KHÔNG sửa được cấu hình mạng
Vì sao các phương án khác sai
-
D (VPC peering theo mô hình hub-and-spoke giữa các project kỹ thuật) — ⚠ bẫy gần nhất: nối được các VPC, nhưng ⚠ mỗi project vẫn có VPC RIÊNG và tự quản firewall — không tập trung. ⚠ Peering còn không truyền tiếp (không transitive).
-
B (dựng Cloud VPN Gateway nối mọi project theo hub-and-spoke) — ⚠ phức tạp và tốn kém: mỗi project một VPN là nhiều gateway, nhiều chi phí.
-
A (cấp vai trò Compute Admin cho đội mạng trên MỌI project kỹ thuật) — ⚠ quá rộng: ⚠ Compute Admin cho quyền trên cả VM và đĩa, không chỉ mạng; ⚠ và vẫn không tập trung được cấu hình.
Ghi nhớ
⚠ Shared VPC — điểm cốt lõi — bảng phải thuộc: | Điểm | Nội dung | |---|---| | ⚠ Host project giữ VPC, subnet, firewall | | | ⚠ Service project chạy workload | | | ⚠ Một kết nối lai dùng chung | ⚠ VPN, Interconnect | | ⚠ Tách quyền MẠNG khỏi quyền WORKLOAD | ⚠ đúng nguyên tắc quyền tối thiểu | | IP nằm trong một dải thống nhất | |
Từ khoá nhận diện:
"tập trung firewall/subnet, nhiều project, đội mạng quản" → ⚠ Shared VPC "nối hai VPC lại" → ⚠ VPC peering — không tập trung "cấp Compute Admin cho đội mạng" → ⚠ quá rộng
| ⚠ Vai trò IAM cho Shared VPC | Vai trò |
|---|---|
| ⚠ Shared VPC Admin | ⚠ gắn service project vào host |
| ⚠ Network Admin | ⚠ quản VPC, subnet, route |
| ⚠ Security Admin | ⚠ quản FIREWALL |
| Network User | ⚠ dùng subnet cụ thể |
| ⚠ Tách Network và Security Admin | ⚠ người quản route khác người quản firewall |
| ⚠ Shared VPC khác VPC Peering | Khác |
|---|---|
| ⚠ Shared VPC: MỘT VPC dùng chung | ⚠ quản trị tập trung |
| ⚠ Peering: NHIỀU VPC nối nhau | ⚠ mỗi bên tự quản |
| ⚠ Peering KHÔNG truyền tiếp | ⚠ A-B, B-C không cho A-C |
| Shared VPC trong cùng tổ chức | |
| Peering | ⚠ dùng khi hai bên độc lập về quản trị |
| ⚠ Lợi ích an ninh của Shared VPC | Lợi ích |
|---|---|
| ⚠ Đội ứng dụng KHÔNG mở được firewall | ⚠ quan trọng nhất |
| ⚠ Chính sách mạng thống nhất | |
| ⚠ Một điểm để kiểm toán | |
| Không có VPC "mọc dại" | ⚠ shadow network |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội ứng dụng có tạo được firewall rule không | ⚠ không được — đó là điểm chính | | Dải IP có bị chồng lấn không | ⚠ lập kế hoạch IP trước | | Ai có quyền Security Admin trên host | ⚠ nên rất ít người |
Và giá trị lớn nhất của Shared VPC về mặt an ninh: đội phát triển không thể tự mở cổng firewall. Trong mô hình mỗi project một VPC, chỉ cần một kỹ sư mở 0.0.0.0/0 là toàn bộ chính sách an ninh của tổ chức bị thủng ở đúng chỗ đó.
- A Rules for VPC Firewall.
- B The management of user access and permissions to Google Cloud resources is known as Cloud Identity and Access Management.
- C Cloud Armor is a security service provided by Google Cloud.
- D CDN on Google Cloud Platform.
Xem giải thích
Đáp án
C — Cloud Armor.
Vì sao đúng
Đề nêu hai yêu cầu, và Cloud Armor đáp ứng cả hai trong một dịch vụ:
⚠ Hai yêu cầu:
"chỉ cho truy cập từ một dải CIDR
đã biết là tốt"
→ ⚠ chính sách allowlist theo IP
"tận dụng chống SYN flood
NGUYÊN BẢN của GCP"
→ ⚠ Cloud Armor + Google Front End
chống DDoS ở tầng hạ tầng
⚠ Vì sao không phải firewall VPC:
⚠ VPC firewall lọc ở tầng MẠNG
của VPC
↓
⚠ Nhưng lưu lượng đã tới hạ tầng rồi
⚠ Cloud Armor lọc ở BIÊN
→ ⚠ tại Google Front End
→ ⚠ chặn TRƯỚC khi tới VPC
→ ⚠ hấp thụ được tấn công lớn
Vì sao các phương án khác sai
-
A (VPC firewall rules) — ⚠ bẫy mạnh nhất: lọc được theo CIDR thật, nhưng ⚠ không có chống SYN flood ở quy mô DDoS; ⚠ và lọc ở tầng thấp hơn nên tài nguyên vẫn phải xử lý lưu lượng.
-
B (Cloud IAM) — ⚠ sai tầng: IAM kiểm soát quyền trên tài nguyên Google Cloud, ⚠ không lọc lưu lượng mạng của ứng dụng.
-
D (Cloud CDN) — ⚠ sai mục đích: CDN để cache nội dung gần người dùng, không phải công cụ kiểm soát truy cập.
Ghi nhớ
⚠ Các lớp bảo vệ mạng — bảng phải thuộc: | Lớp | Công cụ | Vị trí | |---|---|---| | ⚠ Biên Internet | ⚠ Cloud Armor — WAF, DDoS, CIDR — đề này | | Trong VPC | ⚠ VPC firewall rules | | Tầng ứng dụng | ⚠ IAP — theo danh tính | | Ranh giới dữ liệu | ⚠ VPC Service Controls | | Quyền tài nguyên | ⚠ IAM |
Từ khoá nhận diện:
"chặn theo CIDR + chống DDoS/SYN flood" → ⚠ Cloud Armor "lọc lưu lượng giữa các VM" → ⚠ VPC firewall "theo danh tính người dùng" → ⚠ IAP "cache nội dung" → ⚠ Cloud CDN
| ⚠ Cloud Armor làm được gì | Việc |
|---|---|
| ⚠ Allowlist / denylist theo IP và CIDR | |
| ⚠ Chống DDoS tầng 3, 4 và 7 | |
| ⚠ Luật WAF theo OWASP | ⚠ SQLi, XSS |
| ⚠ Chặn theo địa lý | |
| Giới hạn tần suất | |
| ⚠ Chế độ preview | ⚠ xem sẽ chặn gì trước khi bật thật |
| ⚠ Vì sao chặn ở BIÊN tốt hơn | Lý do |
|---|---|
| ⚠ Lưu lượng xấu không tới được backend | |
| ⚠ Không tốn tài nguyên xử lý | |
| ⚠ Hạ tầng Google hấp thụ được tấn công rất lớn | |
| Chi phí thấp hơn | ⚠ không trả tiền xử lý lưu lượng rác |
| ⚠ Lưu ý khi cấu hình Cloud Armor | Lưu ý |
|---|---|
| ⚠ LUÔN dùng chế độ preview trước | ⚠ tránh chặn nhầm người dùng thật |
| ⚠ Cloud Armor cần Global Load Balancer | |
| ⚠ Thứ tự ưu tiên luật quan trọng | ⚠ số nhỏ chạy trước |
| Luật mặc định cuối cùng | ⚠ allow hay deny — quyết định cẩn thận |
| ⚠ Theo dõi log để chỉnh luật |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chạy preview chưa | ⚠ xem sẽ chặn nhầm ai | | Có đường vòng nào bỏ qua load balancer không | ⚠ IP công khai trực tiếp trên VM | | Luật mặc định là allow hay deny | |
Và lỗ hổng thường gặp khi triển khai Cloud Armor: backend vẫn còn IP công khai. Kẻ tấn công tìm ra IP đó là đi thẳng vào, bỏ qua toàn bộ lớp bảo vệ ở biên.
- A Accessing Google services from a private network using internal IPs is known as Private Google Access.
- B A public IP address is a unique address that identifies a device or network on the internet.
- C Enabling IP Forwarding allows packets to be forwarded from one network interface to another.
- D The IAM Network User Role and Static routes are both important components in Google Cloud.
Xem giải thích
Đáp án
A và B — Private Google Access, và địa chỉ IP công khai
Vì sao đúng
Đề hỏi hai thiết lập phải để tắt thì máy mới không ra được Internet và không tự ý gọi dịch vụ Google:
- B. IP công khai — có IP công khai là máy nói chuyện được với Internet; gỡ nó đi là cắt đường ra ở mức cơ bản nhất.
- A. Private Google Access — khi bật, máy không có IP công khai vẫn gọi được API của Google qua đường nội bộ. Muốn cô lập hoàn toàn thì phải tắt cả cái này.
Vì sao các phương án khác sai
- C. IP Forwarding — cho phép máy chuyển tiếp gói tin thay cho máy khác, dùng khi dựng NAT hoặc thiết bị mạng ảo; không phải công tắc ra Internet.
- D. Vai Network User và route tĩnh — thuộc về phân quyền và định tuyến, không phải hai thiết lập bật tắt mà đề hỏi.
- A An outbound connection blocking rule, and an inbound port 80 connection allowing rule.
- B A rule that permits all outgoing connections.
- C A regulation that blocks any incoming connections.
- D A regulation that prevents any incoming traffic on port 25.
Xem giải thích
Đáp án
B và C — cho phép mọi kết nối đi ra, và chặn mọi kết nối đi vào
Vì sao đúng
Mỗi mạng VPC của Google Cloud có hai luật tường lửa ngầm định, luôn tồn tại và không xoá được:
- B. Cho phép toàn bộ lưu lượng đi ra (
allow egress) — máy chủ động kết nối ra ngoài được. - C. Chặn toàn bộ lưu lượng đi vào (
deny ingress) — không ai từ ngoài chủ động vào được cho tới khi bạn khai luật cho phép.
Hai luật này có độ ưu tiên thấp nhất, nên mọi luật bạn tự viết đều thắng chúng. Chúng đặt ra mặc định an toàn: mở ra thì phải khai tường minh.
Vì sao các phương án khác sai
- A — mô tả sai cả hai chiều.
- D. Chặn lưu lượng vào cổng 25 — Google Cloud có chặn cổng 25 đi ra để chống thư rác, nhưng đó là chính sách riêng của nền tảng chứ không phải một trong hai luật ngầm định.
- A Create an Organizational Policy constraint for each folder environment.E. Create projects for each environment, and grant IAM rights to each engineering user.
- B Create a Google Group for the Engineering team, and assign permissions at the folder level.
- C Create a project with multiple VPC networks for each environment.
- D Create a folder for each development and production environment.
Xem giải thích
Đáp án
B và D — tạo Google Group cho đội kỹ thuật rồi gán quyền ở mức thư mục, và tạo thư mục riêng cho từng môi trường
Vì sao đúng
Đây là mô hình phân quyền chuẩn của Google Cloud:
- D. Thư mục cho mỗi môi trường — phát triển và sản xuất tách thành hai nhánh riêng trong cây tài nguyên, nên quyền cấp ở nhánh nào chỉ ảnh hưởng nhánh đó.
- B. Cấp quyền cho nhóm, không cho từng người — quyền được kế thừa xuống mọi dự án trong thư mục, và khi có người mới thì chỉ thêm vào nhóm chứ không phải cấp lại từng dự án.
Vì sao các phương án khác sai
- A. Ràng buộc Organization Policy cho mỗi thư mục — dùng để cấm cấu hình nguy hiểm, không phải cơ chế cấp quyền cho người dùng.
- C. Một dự án với nhiều VPC cho từng môi trường — tách mạng chứ không tách quyền; hai môi trường vẫn nằm chung một ranh giới IAM.
- A To establish a hierarchical structure for your organization, create an organization node and allocate folders for every business unit.
- B Create independent projects for each business unit, utilizing accounts from gmail.com.
- C Label the GCP resources in a project to indicate the owning business unit.
- D To segregate network access, allocate GCP resources in a VPC for every department.
Xem giải thích
Đáp án
A — Tạo organization node và phân bổ folder cho từng đơn vị kinh doanh, hình thành cấu trúc phân cấp.
Vì sao đúng
Đề nêu hai yêu cầu, và hệ thống phân cấp tài nguyên giải cả hai:
⚠ Hai yêu cầu:
"tổ chức project theo ĐƠN VỊ
KINH DOANH"
→ ⚠ FOLDER cho từng đơn vị
"bộ quyền IAM RIÊNG cho từng đơn vị,
hoạt động độc lập"
→ ⚠ IAM gán ở mức FOLDER
→ ⚠ kế thừa xuống project bên dưới
⚠ Hệ thống phân cấp tài nguyên:
⚠ Organization
↓
⚠ Folder (đơn vị kinh doanh)
↓
⚠ Folder con (đội, môi trường)
↓
⚠ Project
↓
⚠ Tài nguyên
↓
⚠ IAM KẾ THỪA từ trên xuống
Vì sao các phương án khác sai
-
B (tạo project riêng dùng tài khoản gmail.com) — ⚠ sai nghiêm trọng: ⚠ tài khoản cá nhân không thuộc tổ chức, ⚠ không quản trị tập trung được, ⚠ và mất kiểm soát khi nhân viên nghỉ.
-
C (gắn label cho tài nguyên để chỉ đơn vị sở hữu) — ⚠ bẫy hợp lý: label tốt cho phân bổ chi phí, nhưng ⚠ KHÔNG phải cơ chế phân quyền — không thể gán IAM theo label.
-
D (phân bổ tài nguyên vào VPC riêng cho từng phòng ban) — ⚠ nhầm tầng: VPC là cách ly MẠNG, không phải cách ly quyền quản trị.
Ghi nhớ
⚠ Hệ thống phân cấp tài nguyên — bảng phải thuộc: | Cấp | Dùng để | |---|---| | ⚠ Organization | ⚠ gốc, gắn với domain Cloud Identity | | ⚠ Folder | ⚠ nhóm theo đơn vị, môi trường, đội | | ⚠ Project | ⚠ ranh giới tài nguyên và hoá đơn | | Tài nguyên | ⚠ VM, bucket, CSDL | | ⚠ IAM và Org Policy | ⚠ KẾ THỪA từ trên xuống |
Từ khoá nhận diện:
"tổ chức theo đơn vị, quyền riêng từng đơn vị" → ⚠ folder "phân bổ chi phí" → ⚠ label — không phải phân quyền "cách ly mạng" → ⚠ VPC "tài khoản gmail.com" → ⚠ luôn SAI cho doanh nghiệp
| ⚠ Vì sao KHÔNG dùng tài khoản cá nhân | Lý do |
|---|---|
| ⚠ Không thuộc tổ chức, không quản trị được | |
| ⚠ Không áp được Organization Policy | |
| ⚠ Nhân viên nghỉ mang theo quyền sở hữu | ⚠ rủi ro nghiêm trọng nhất |
| Không kiểm toán tập trung được | |
| Đây là | ⚠ một trong những sai lầm nền tảng phổ biến nhất |
| ⚠ Thiết kế folder thế nào | Thiết kế |
|---|---|
| ⚠ Theo đơn vị kinh doanh | ⚠ đề này |
| ⚠ Hoặc theo môi trường | ⚠ prod / non-prod |
| ⚠ Thường kết hợp cả hai | ⚠ BU → môi trường → project |
| Tối đa 10 cấp folder | |
| ⚠ Nguyên tắc | ⚠ thiết kế theo cách bạn muốn PHÂN QUYỀN |
| ⚠ Organization Policy — công cụ đi kèm | Công cụ |
|---|---|
| ⚠ Áp ràng buộc từ tổ chức xuống | |
| ⚠ Ví dụ: cấm tạo service account key | |
| ⚠ Ví dụ: giới hạn vùng được dùng | |
| ⚠ Ví dụ: cấm IP công khai trên VM | |
| Khác IAM | ⚠ IAM nói AI được làm gì; Org Policy nói CÁI GÌ được phép tồn tại |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có project nào ngoài organization không | ⚠ rủi ro mất kiểm soát | | Quyền cấp ở mức folder hay từng project | ⚠ folder dễ quản hơn | | Có Organization Policy nào chưa | |
Và quyết định kiến trúc quan trọng nhất khi bắt đầu với Google Cloud: thiết kế cây folder theo cách bạn muốn phân quyền và áp chính sách. Sửa cấu trúc này về sau rất tốn công — nó chạm tới mọi project.