Ngân hàng đề — Microsoft Azure Security Technology

Đáp án

C — Virtual Network Service Endpoints.

Vì sao đúng

⚠ Service Endpoint giới hạn truy cập Storage theo mạng ảo: | Bước | Nội dung | |---|---| | ⚠ Bật service endpoint Microsoft.Storage cho subnet | | | ⚠ Vào firewall của Storage, chọn "Selected networks" | | | ⚠ Thêm VNet và subnet đó vào danh sách | | | ⚠ Mọi nơi khác bị chặn | | | ⚠ Miễn phí | |

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

• D (Private Endpoints) — ⚠ cũng đạt được mục tiêu và còn AN TOÀN HƠN, nhưng tốn phí và cần cấu hình DNS; ⚠ với yêu cầu đơn giản "chỉ từ một VNet", service endpoint là lựa chọn trực tiếp và miễn phí.

• A (VNet Peering) — ⚠ nối hai VNet, không kiểm soát truy cập PaaS.

• B (Private Link services) — ⚠ mặt NHÀ CUNG CẤP của Private Link, dùng khi phơi dịch vụ của mình.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23797 trong CÙNG lô.

⚠ Lô này có HAI cặp gần trùng cùng chủ đề — cặp này và cặp #23798 ↔ #23806 về Private Endpoint.

⚠ Bốn tuỳ chọn mạng của Storage Account: | Tuỳ chọn | Mức an toàn | |---|---| | ⚠ Enabled from all networks | ⚠ mặc định, kém nhất | | ⚠ Enabled from selected networks | ⚠ service endpoint và dải IP | | ⚠ Disabled + private endpoint | ⚠ an toàn nhất | | ⚠ Thêm | ⚠ tắt shared key access, chỉ cho Entra ID |

Từ khoá nhận diện:

"chỉ từ VNet này, miễn phí" → ⚠ Service Endpoint "dịch vụ có IP riêng trong VNet" → ⚠ Private Endpoint "truy cập từ mạng tại chỗ" → ⚠ Private Endpoint "nối hai VNet" → ⚠ peering, không liên quan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Storage có đang mở cho mọi mạng không | ⚠ mặc định là mở | | Firewall đã khai đúng subnet chưa | | | Shared key access đã tắt chưa | |

Và cấu hình mặc định đáng sửa nhất của mọi tài khoản lưu trữ mới: "Enabled from all networks". Chừng nào còn để nguyên, bất kỳ ai có khoá — kể cả khoá lọt vào một kho mã nguồn — đều truy cập được từ bất kỳ đâu.

Đáp án

B và C — Private Endpoints và Private Link services.

Vì sao đúng

⚠ Hai mặt của cùng một công nghệ: | Thành phần | Vai trò | |---|---| | ⚠ Private Endpoint | ⚠ bên TIÊU THỤ — card mạng IP riêng trỏ tới dịch vụ PaaS | | ⚠ Private Link Service | ⚠ bên CUNG CẤP — phơi dịch vụ của mình qua IP riêng |

⚠ Cả hai đều đưa lưu lượng đi qua backbone Microsoft trên địa chỉ RIÊNG, không ra Internet công cộng.

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

• D (Virtual Network Service Endpoints) — ⚠ vẫn dùng IP CÔNG CỘNG của dịch vụ, chỉ tối ưu đường đi; đề yêu cầu kết nối riêng.

• A (Virtual Network Peering) — ⚠ nối hai VNet với nhau, không liên quan tới truy cập PaaS.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23798 trong CÙNG lô — cùng khoá B và C, chỉ khác cách diễn đạt.

⚠ Ba lựa chọn kết nối tới PaaS — bảng so sánh: | Lựa chọn | Địa chỉ | Chi phí | Từ tại chỗ | |---|---|---|---| | ⚠ Endpoint công cộng | ⚠ IP công cộng | ⚠ miễn phí | ⚠ được, qua Internet | | ⚠ Service Endpoint | ⚠ IP công cộng | ⚠ miễn phí | ⚠ KHÔNG | | ⚠ Private Endpoint | ⚠ IP RIÊNG | ⚠ tính tiền | ⚠ ĐƯỢC |

Từ khoá nhận diện:

"kết nối riêng, IP riêng" → ⚠ Private Endpoint "vẫn IP công cộng, đi qua backbone" → ⚠ Service Endpoint "phơi dịch vụ của mình" → ⚠ Private Link Service "tên phải phân giải về IP riêng" → ⚠ Private DNS zone

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ trong VNet, tên dịch vụ phân giải ra IP nào | | | Truy cập công cộng đã tắt chưa | | | Có bao nhiêu private endpoint và chi phí hằng tháng bao nhiêu | |

Và điều cần cân nhắc khi chuyển sang Private Endpoint ở quy mô lớn: chi phí nhân theo số tài nguyên. Một tổ chức có hàng trăm tài khoản lưu trữ và CSDL sẽ thấy khoản này đáng kể — nên áp có chọn lọc theo mức nhạy cảm của dữ liệu.

Đáp án

D — Một subnet RIÊNG bên trong mạng ảo.

Vì sao đúng

⚠ Azure SQL Managed Instance BẮT BUỘC triển khai vào một subnet chuyên dụng: | Yêu cầu | Nội dung | |---|---| | ⚠ Subnet dành RIÊNG cho Managed Instance | ⚠ không chứa tài nguyên nào khác | | ⚠ Subnet phải được uỷ quyền | ⚠ delegation tới Microsoft.Sql/managedInstances | | ⚠ Kích thước tối thiểu /27 | ⚠ khuyến nghị /24 để còn mở rộng | | ⚠ Có bảng định tuyến và NSG theo yêu cầu | | | ⚠ Instance nhận IP RIÊNG trong subnet đó | |

⚠ Kết quả: ⚠ Managed Instance không có endpoint công cộng theo mặc định — chỉ truy cập được từ trong VNet, từ VNet đã peering, hoặc từ mạng tại chỗ qua VPN/ExpressRoute.

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

• B (Service Endpoints) — ⚠ dùng cho Azure SQL DATABASE và các PaaS có endpoint công cộng; ⚠ Managed Instance vốn đã nằm trong VNet, không cần cơ chế này.

• A (App Service Environment) — ⚠ môi trường cách ly cho ỨNG DỤNG WEB, không phải CSDL.

• C (Network Integration cho Azure Functions) — ⚠ cho Functions truy cập tài nguyên trong VNet, không liên quan.

Ghi nhớ

⚠ Azure SQL Database và SQL Managed Instance — khác biệt về mạng: | Tiêu chí | SQL Database | SQL Managed Instance | |---|---|---| | ⚠ Vị trí mạng | ⚠ endpoint CÔNG CỘNG mặc định | ⚠ TRONG VNet của bạn | | ⚠ Để bảo mật mạng | ⚠ firewall, service endpoint, private endpoint | ⚠ đã nằm trong VNet sẵn | | ⚠ Tương thích SQL Server | ⚠ hạn chế | ⚠ gần như đầy đủ | | ⚠ Thời gian tạo | ⚠ vài phút | ⚠ có thể hàng giờ |

Từ khoá nhận diện:

"CSDL nằm trong VNet" → ⚠ SQL Managed Instance, cần subnet riêng "CSDL PaaS có endpoint công cộng" → ⚠ Azure SQL Database "cần SQL Agent, cross-database query, CLR" → ⚠ Managed Instance "subnet chuyên dụng, được uỷ quyền" → ⚠ subnet delegation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subnet có đủ lớn để mở rộng không | | | Có endpoint công cộng nào được bật thêm không | ⚠ Managed Instance bật được, nhưng nên tắt | | NSG và bảng định tuyến có đúng yêu cầu của dịch vụ không | |

Và điều nên quyết định cẩn thận từ đầu khi dựng Managed Instance: kích thước subnet. Nó không đổi được sau này, và mỗi lần mở rộng quy mô instance đều cần thêm địa chỉ IP trong chính subnet đó.

Đáp án

D — Web Application Firewall (WAF).

Vì sao đúng

⚠ WAF là công cụ duy nhất trong danh sách phân tích được NỘI DUNG yêu cầu HTTP: | Chặn được | Nội dung | |---|---| | ⚠ SQL injection | ⚠ chèn lệnh SQL vào tham số | | ⚠ Cross-site scripting (XSS) | ⚠ chèn script chạy trong trình duyệt nạn nhân | | ⚠ Command injection | | | ⚠ Các mục trong OWASP Top 10 | | | ⚠ Bot độc hại | ⚠ với bot protection rule set |

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

• B (Front Door) và C (Application Gateway) — ⚠ là NƠI ĐẶT WAF, không phải bản thân cơ chế chống tấn công web; ⚠ không bật WAF thì chúng chỉ định tuyến và cân bằng tải.

• A (Azure Firewall) — ⚠ lọc theo IP, cổng, FQDN, KHÔNG phân tích nội dung yêu cầu HTTP.

Ghi nhớ

⚠ WAF đặt được ở ba nơi: | Nơi | Phạm vi | |---|---| | ⚠ Application Gateway | ⚠ trong một vùng | | ⚠ Azure Front Door | ⚠ toàn cầu, ngay tại biên | | ⚠ Azure CDN | ⚠ tại biên |

⚠ Hai lớp luật của WAF: | Lớp | Nội dung | |---|---| | ⚠ Managed rule set | ⚠ Microsoft duy trì, dựa trên OWASP Core Rule Set | | ⚠ Custom rules | ⚠ của bạn, xét TRƯỚC — match rule và rate limit rule |

Từ khoá nhận diện:

"SQL injection, XSS, OWASP" → ⚠ WAF "lọc theo IP và cổng" → ⚠ NSG "lọc theo FQDN, threat intelligence" → ⚠ Azure Firewall "chống lưu lượng tấn công khổng lồ" → ⚠ DDoS Protection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng web công khai đã có WAF chưa | | | WAF đang ở chế độ nào | | | Có luật nào bị tắt vì cảnh báo giả không | |

Và hiểu nhầm khiến nhiều kiến trúc trông đầy đủ mà vẫn hở: tưởng Azure Firewall làm được việc của WAF. Hai công cụ nhìn vào hai thứ khác nhau — một cái nhìn kết nối và tên miền, một cái nhìn vào nội dung từng yêu cầu.

Đáp án

B, C và D — Azure Front Door, Azure DDoS Network Protection, và Azure Application Gateway.

Vì sao đúng

⚠ Ba yêu cầu, ba dịch vụ: | Yêu cầu | Dịch vụ | |---|---| | ⚠ Chống DDoS | ⚠ DDoS Network Protection cho VNet; Front Door hấp thụ ở biên | | ⚠ TLS termination | ⚠ cả Front Door lẫn Application Gateway đều làm được | | ⚠ Định tuyến theo URL | ⚠ Front Door toàn cầu, Application Gateway trong vùng |

⚠ Người dùng
     ↓ ⚠ DDoS Protection bảo vệ ở vành đai
⚠ Front Door — TLS offload, định tuyến toàn cầu, WAF ở biên
     ↓
⚠ Application Gateway — TLS, định tuyến theo URL trong vùng
     ↓
⚠ Backend

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

• A (Azure Firewall) — ⚠ lọc theo luật ở tầng mạng, không làm TLS termination hay định tuyến theo URL.

• E (Event Grid) — ⚠ định tuyến SỰ KIỆN, không phải lưu lượng web.

• F (App Configuration) — ⚠ quản lý cấu hình tập trung và feature flag.

Ghi nhớ

⚠ TLS termination — vì sao đáng làm: | Lợi ích | Nội dung | |---|---| | ⚠ Backend không tốn CPU giải mã | | | ⚠ Chứng chỉ quản một chỗ | ⚠ thay vì trên từng máy | | ⚠ WAF đọc được nội dung để kiểm tra | ⚠ mã hoá thì không kiểm tra được | | ⚠ Cần mã hoá cả chặng sau | ⚠ bật end-to-end TLS |

Từ khoá nhận diện:

"định tuyến theo URL toàn cầu" → ⚠ Front Door "định tuyến theo URL trong một vùng" → ⚠ Application Gateway "chống lưu lượng tấn công lớn" → ⚠ DDoS Protection "lọc theo FQDN cho lưu lượng ra" → ⚠ Azure Firewall

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần cả hai lớp cân bằng tải không | | | DDoS Protection đang ở bậc nào | | | Có trần tự co giãn để chặn thiệt hại chi phí không | |

Và điều đáng nhớ khi thiết kế phòng thủ trước DDoS trên đám mây: thiệt hại thường là hoá đơn chứ không phải thời gian chết. Hệ thống tự co giãn sẽ ngoan ngoãn mở rộng để phục vụ chính cuộc tấn công — nên đặt trần co giãn là một biện pháp bảo mật, không chỉ là quản trị chi phí.

Đáp án

B — Azure Bastion.

Vì sao đúng

⚠ Bastion cho phép quản trị viên RDP và SSH ngay trong Azure Portal: | Đặc điểm | Nội dung | |---|---| | ⚠ Kết nối qua HTTPS cổng 443 | ⚠ không mở 3389 hay 22 ra Internet | | ⚠ Máy ảo không cần IP công cộng | | | ⚠ Truy cập trực tiếp từ Portal | ⚠ hoặc bằng client gốc ở bậc Standard | | ⚠ Bastion nằm trong VNet của bạn | ⚠ subnet AzureBastionSubnet |

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

• C (Azure Disk Encryption) — ⚠ mã hoá đĩa máy ảo, không phải kênh truy cập.

• A (AKS) — ⚠ điều phối container.

• D (API Management) — ⚠ cổng quản lý API.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với câu #23777 trong CÙNG lô.

⚠ Cùng với #23129 ở lô 170, đây là câu thứ ba về Bastion trong các lô gần đây.

⚠ Ba cách bảo vệ cổng quản trị: | Cách | Nội dung | |---|---| | ⚠ Azure Bastion | ⚠ không cần IP công cộng, qua trình duyệt | | ⚠ Just-in-Time VM Access | ⚠ mở cổng có thời hạn, cần Defender for Servers | | ⚠ NSG chặt | ⚠ chỉ dải IP nội bộ |

Từ khoá nhận diện:

"RDP/SSH không mở cổng ra Internet" → ⚠ Bastion "mở cổng tạm thời khi cần" → ⚠ JIT VM Access "mã hoá đĩa" → ⚠ Azure Disk Encryption "kết nối riêng tới PaaS" → ⚠ Private Endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có NSG nào cho phép 3389 hoặc 22 từ Internet không | | | Máy ảo còn IP công cộng không cần thiết không | | | Có ghi nhật ký phiên quản trị không | ⚠ Bastion Premium hỗ trợ |

Và điểm mạnh về mặt kiến trúc của Bastion so với mọi cách khác: không còn cửa nào để mở. JIT vẫn phải mở cổng trong một khoảng thời gian; Bastion thì cổng quản trị không bao giờ phơi ra Internet, dù chỉ một phút.

Đáp án

A, B và C.

• A — Bật Microsoft Defender for Kubernetes.
• B — Tích hợp với Azure Monitor và Log Analytics.
• C — Bật Azure Policy for AKS.

Vì sao đúng

⚠ Ba cấu hình phủ đủ hai yêu cầu — bảo mật và giám sát: | Cấu hình | Vai trò | |---|---| | ⚠ Defender for Kubernetes | ⚠ phát hiện mối đe doạ, quét lỗ hổng ảnh, đánh giá cấu hình | | ⚠ Azure Monitor và Log Analytics | ⚠ thu thập chỉ số và nhật ký cụm, truy vấn bằng KQL | | ⚠ Azure Policy for AKS | ⚠ buộc pod tuân theo chuẩn — không chạy root, giới hạn tài nguyên |

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

• D (dùng networking Kubernetes mặc định) — ⚠ KHÔNG cải thiện bảo mật; nên bật network policy để kiểm soát lưu lượng giữa các pod.

• E (Azure Key Vault) — ⚠ hữu ích để cất bí mật, nhưng bản thân nó không phải cấu hình bảo mật hay giám sát của CỤM; ⚠ tích hợp qua Secrets Store CSI Driver mới là cấu hình cụ thể.

Ghi nhớ

⚠ Container Insights — phần giám sát của Azure Monitor cho AKS: | Thu thập | Nội dung | |---|---| | ⚠ Chỉ số node và pod | ⚠ CPU, bộ nhớ | | ⚠ Nhật ký container | ⚠ stdout và stderr | | ⚠ Sự kiện Kubernetes | | | ⚠ Kiểm kê workload | | | ⚠ Truy vấn bằng | ⚠ KQL trong Log Analytics |

⚠ Azure Policy for AKS làm được gì: | Chính sách ví dụ | Nội dung | |---|---| | ⚠ Không cho container chạy quyền privileged | | | ⚠ Chỉ cho kéo ảnh từ registry được duyệt | | | ⚠ Buộc khai giới hạn CPU và bộ nhớ | | | ⚠ Buộc dùng HTTPS cho ingress | | | ⚠ Nền tảng | ⚠ Gatekeeper và OPA |

Từ khoá nhận diện:

"phát hiện đe doạ trong cụm" → ⚠ Defender for Containers "chỉ số và nhật ký cụm" → ⚠ Container Insights, Azure Monitor "buộc pod tuân chuẩn" → ⚠ Azure Policy for AKS "kiểm soát lưu lượng giữa pod" → ⚠ network policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | API server của cụm có công khai không | | | Tài khoản quản trị cục bộ đã tắt chưa | ⚠ nó bỏ qua mọi kiểm soát của Entra ID | | Bí mật đang nằm trong Kubernetes Secret hay trong Key Vault | |

Và cấu hình mặc định nguy hiểm nhất của AKS: tài khoản quản trị cục bộ vẫn bật. Ai có tệp kubeconfig đó thì toàn quyền trên cụm, không đi qua Entra ID, không MFA, và không để lại dấu vết ai đã làm gì.

Đáp án

B — Microsoft Entra ID.

Vì sao đúng

⚠ Chỉ Entra ID cho phép xác thực và uỷ quyền DỰA TRÊN ĐỊNH DANH: | Cơ chế | Dựa trên | |---|---| | ⚠ Entra ID | ⚠ ĐỊNH DANH — người dùng, nhóm, managed identity, service principal | | ⚠ Access key | ⚠ một chuỗi bí mật dùng chung, không biết ai đang dùng | | ⚠ SAS token | ⚠ một URL có chữ ký, cũng không gắn với ai | | ⚠ Anonymous access | ⚠ không xác thực gì cả |

⚠ Lợi ích của xác thực bằng Entra ID: | Lợi ích | Nội dung | |---|---| | ⚠ Nhật ký ghi rõ AI đã truy cập | | | ⚠ Áp được RBAC chi tiết | ⚠ theo container, theo thư mục | | ⚠ Áp được MFA và Conditional Access | | | ⚠ Thu hồi quyền tức thì | ⚠ tắt tài khoản là xong | | ⚠ Kết hợp managed identity là KHÔNG có bí mật nào | |

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

• C (access key) — ⚠ quyền TOÀN BỘ tài khoản lưu trữ, không phân biệt ai dùng, và lộ ra là mất tất cả.

• A (SAS) — ⚠ cấp quyền có phạm vi và thời hạn, nhưng vẫn không gắn với định danh nào.

• D (anonymous public read) — ⚠ không có xác thực, và là nguyên nhân của rất nhiều vụ lộ dữ liệu.

Ghi nhớ

⚠ Ba cách xác thực tới Blob Storage — xếp theo mức an toàn: | Cách | Mức | |---|---| | ⚠ Anonymous | ⚠ KÉM NHẤT — nên tắt hẳn ở cấp tài khoản | | ⚠ Access key | ⚠ quyền toàn bộ, khó thu hồi riêng lẻ | | ⚠ SAS token | ⚠ có phạm vi và hạn, tốt hơn key | | ⚠ Entra ID kèm RBAC | ⚠ TỐT NHẤT — gắn với định danh cụ thể |

Từ khoá nhận diện:

"dựa trên định danh" → ⚠ Entra ID "cấp quyền tạm cho một tệp" → ⚠ SAS token "khoá của cả tài khoản" → ⚠ access key, nên tắt "không cần thông tin đăng nhập trong mã" → ⚠ managed identity kèm Entra ID

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Anonymous access đã tắt ở cấp tài khoản chưa | | | Shared key access đã tắt chưa | | | Có SAS token nào hạn tính bằng năm không | |

Và nguyên nhân của phần lớn các vụ lộ dữ liệu từ kho lưu trữ đám mây: container để chế độ truy cập ẩn danh. Tắt hẳn khả năng đó ở cấp tài khoản là một công tắc duy nhất, và nó chặn cả một lớp sự cố.

Đáp án

A, B và D — Soft delete, Immutable storage, và Versioning.

Vì sao đúng

⚠ Ba cơ chế, ba loại rủi ro: | Cơ chế | Chống | |---|---| | ⚠ Soft delete | ⚠ XOÁ nhầm — khôi phục trong thời gian giữ | | ⚠ Versioning | ⚠ GHI ĐÈ nhầm — tự giữ mọi phiên bản cũ | | ⚠ Immutable storage | ⚠ SỬA hoặc XOÁ có chủ đích — WORM, kể cả admin cũng không làm được |

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

• C (Azure Queues) — ⚠ dịch vụ hàng đợi tin nhắn, hoàn toàn không liên quan tới bảo vệ dữ liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23782 trong CÙNG lô, và có một điểm KHÔNG NHẤT QUÁN đáng chú ý ở bộ đề gốc.

⚠ Bảo vệ dữ liệu Blob theo lớp: | Rủi ro | Cơ chế | |---|---| | ⚠ Xoá nhầm blob | ⚠ blob soft delete | | ⚠ Xoá nhầm container | ⚠ container soft delete | | ⚠ Ghi đè nhầm | ⚠ versioning | | ⚠ Sửa hoặc xoá có chủ đích | ⚠ immutability policy | | ⚠ Hỏng phần cứng | ⚠ LRS, ZRS | | ⚠ Mất cả vùng | ⚠ GRS, GZRS | | ⚠ Ransomware | ⚠ immutability là biện pháp mạnh nhất |

Từ khoá nhận diện:

"khôi phục sau khi xoá" → ⚠ soft delete "giữ phiên bản cũ" → ⚠ versioning "không ai sửa hay xoá được" → ⚠ immutable storage, WORM "chịu được mất cả vùng" → ⚠ GRS hoặc GZRS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Soft delete bật cho cả blob lẫn container chưa | | | Thời gian giữ có đủ để phát hiện sự cố không | ⚠ 7 ngày thường quá ngắn | | Dữ liệu tuân thủ đã có immutability chưa | |

Và biện pháp mạnh nhất chống ransomware trên Azure Storage: immutability policy đã khoá. Kể cả kẻ tấn công chiếm được tài khoản quản trị cũng không xoá hay mã hoá được dữ liệu trong thời gian giữ — đó là điều mà sao lưu thông thường không đảm bảo được.

Đáp án

D — Mã hoá hai lần bằng infrastructure encryption.

Vì sao đúng

⚠ Hai lớp mã hoá chồng lên nhau: | Lớp | Nội dung | |---|---| | ⚠ Lớp 1 — Storage Service Encryption | ⚠ AES-256, LUÔN bật, không tắt được | | ⚠ Lớp 2 — Infrastructure Encryption | ⚠ mã hoá THÊM lần nữa ở tầng hạ tầng, TUỲ CHỌN |

⚠ Ràng buộc: ⚠ phải bật LÚC TẠO tài khoản lưu trữ; không bật được về sau.

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

• A (Bring Your Own Key) — ⚠ đổi AI QUẢN KHOÁ, không thêm lớp mã hoá.

• B (Soft delete) và C (Versioning) — ⚠ bảo vệ chống mất dữ liệu, không phải mã hoá.

• E (BitLocker) — ⚠ mã hoá đĩa của HỆ ĐIỀU HÀNH Windows, không áp cho Azure Storage.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23781 trong CÙNG lô.

⚠ Lô này đã có bốn cặp gần trùng — Bastion, Service Endpoint, Private Endpoint, và cặp này.

⚠ Hai trục độc lập của mã hoá Storage: | Trục | Lựa chọn | |---|---| | ⚠ Bao nhiêu LỚP | ⚠ một, hoặc hai với infrastructure encryption | | ⚠ AI quản KHOÁ | ⚠ Microsoft-managed, hoặc customer-managed trong Key Vault | | ⚠ Hai trục | ⚠ kết hợp tự do với nhau |

Từ khoá nhận diện:

"thêm lớp mã hoá" → ⚠ infrastructure encryption "tự quản khoá" → ⚠ customer-managed key, BYOK "mã hoá đĩa máy ảo" → ⚠ Azure Disk Encryption, dùng BitLocker hoặc dm-crypt "mã hoá khi truyền" → ⚠ TLS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy định có đòi mã hoá nhiều lớp không | ⚠ nếu có thì phải tạo tài khoản MỚI | | Key Vault chứa CMK đã bật purge protection chưa | | | Ai có quyền xoá khoá đó | |

Và ràng buộc dễ vấp nhất với infrastructure encryption: chỉ bật được lúc tạo tài khoản. Phát hiện ra yêu cầu này sau khi đã có dữ liệu nghĩa là phải tạo tài khoản mới và di chuyển toàn bộ.