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

Đáp án

A — Enable Infrastructure Encryption (bật mã hoá hạ tầng).

Vì sao đúng

⚠ Infrastructure encryption tạo lớp mã hoá THỨ HAI: | 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 ở tầng hạ tầng, TUỲ CHỌN |

⚠ Ràng buộc: ⚠ chỉ bật được LÚC TẠO tài khoản lưu trữ.

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

• C (Managed Keys) và D (Azure Key Vault) — ⚠ liên quan tới việc AI QUẢN KHOÁ, không thêm lớp mã hoá.

• B (Azure Security Center, nay là Defender for Cloud) — ⚠ quản lý tư thế bảo mật, không mã hoá gì.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu THỨ BA về infrastructure encryption trong hai lô gần nhau.

⚠ 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 key, hoặc customer-managed key | | ⚠ Hai trục | ⚠ kết hợp tự do |

Từ khoá nhận diện:

"mã hoá hai lần, thêm lớp" → ⚠ infrastructure encryption "tự quản khoá" → ⚠ customer-managed key "khoá của tôi, Azure không truy cập được" → ⚠ CMK trong Managed HSM "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 | | | Tài khoản hiện có đã bật chưa | ⚠ nếu chưa thì phải tạo mới | | Có đang nhầm CMK với thêm lớp mã hoá không | |

Và ràng buộc thực tế dễ vấp nhất: 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ộ sang.

Đáp án

B, C và E.

• B — Tạo stored access policy cho từng container để thu hồi quyền hoặc đổi thời hạn.
• C — Định kỳ tái tạo khoá tài khoản để kiểm soát truy cập.
• E — Dùng Azure Blob Storage với mã hoá phía dịch vụ (SSE).

Vì sao đúng

⚠ Ba biện pháp ở ba khía cạnh: | Biện pháp | Vai trò | |---|---| | ⚠ Stored access policy | ⚠ quản lý SAS TẬP TRUNG — thu hồi hàng loạt bằng một thao tác | | ⚠ Tái tạo khoá định kỳ | ⚠ vô hiệu hoá mọi thứ ký bằng khoá cũ | | ⚠ Service-Side Encryption | ⚠ mã hoá khi lưu, bật sẵn |

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

• A (tạo SAS cho từng người và XOÁ SAS để chặn) — ⚠ KHÔNG xoá được một SAS đã phát ra; ⚠ SAS là một URL đã ký, không có nút xoá. ⚠ Đó chính là lý do stored access policy tồn tại.

• D (BYOK) — ⚠ về quản lý khoá mã hoá, không phải cách "đơn giản nhất" để lưu trữ media an toàn.

Ghi nhớ

⚠ Stored access policy giải bài toán gì: | Không có policy | Có policy | |---|---| | ⚠ SAS đã phát ra là KHÔNG thu hồi được | ⚠ sửa hoặc xoá policy là mọi SAS gắn với nó mất hiệu lực | | ⚠ Muốn chặn phải tái tạo khoá tài khoản | ⚠ ảnh hưởng MỌI thứ dùng khoá đó | | ⚠ Không đổi được thời hạn | ⚠ đổi thời hạn trong policy là xong |

⚠ Ba loại SAS: | Loại | Phạm vi | |---|---| | ⚠ Service SAS | ⚠ một dịch vụ — blob, file, queue, table | | ⚠ Account SAS | ⚠ cả tài khoản, nhiều dịch vụ — rộng, nên tránh | | ⚠ User delegation SAS | ⚠ ký bằng ENTRA ID, không dùng khoá tài khoản — TỐT NHẤT |

Từ khoá nhận diện:

"thu hồi SAS hàng loạt" → ⚠ stored access policy "SAS ký bằng định danh, thu hồi được" → ⚠ user delegation SAS "mã hoá khi lưu" → ⚠ SSE, bật sẵn "tự quản khoá mã hoá" → ⚠ customer-managed key

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có SAS nào hạn dài mà không gắn policy không | ⚠ không thu hồi được | | Khoá tài khoản lần cuối tái tạo là khi nào | | | Có chuyển sang Entra ID được không | ⚠ thì bỏ hẳn được bài toán SAS |

Và điều làm SAS trở thành rủi ro âm thầm: một khi đã phát ra thì không có nút thu hồi. Stored access policy và user delegation SAS tồn tại chính là để lấy lại quyền kiểm soát đó — dùng SAS trần không có cả hai là tự tước mất đường lùi.

Đáp án

C — Customer Managed Keys (khoá do khách hàng quản lý).

Vì sao đúng

⚠ CMK cho phép tổ chức áp chuẩn quản khoá của mình: | Khả năng | Nội dung | |---|---| | ⚠ Khoá nằm trong Key Vault hoặc Managed HSM CỦA BẠN | | | ⚠ Bạn kiểm soát vòng đời | ⚠ tạo, xoay vòng, thu hồi, xoá | | ⚠ Thu hồi quyền truy cập khoá | ⚠ là dữ liệu KHÔNG đọc được nữa | | ⚠ Có nhật ký mọi lần khoá được dùng | | | ⚠ Với Managed HSM | ⚠ khoá KHÔNG BAO GIỜ rời khỏi ranh giới HSM |

⚠ Đề nói "Azure không có quyền truy cập khoá" → ⚠ mức chặt nhất là Managed HSM với CMK.

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

• A (Azure Managed Keys) và B (Service Managed Keys) — ⚠ là cùng một thứ: MICROSOFT quản khoá; ⚠ ngược với yêu cầu của đề.

• D (RBAC keys) — ⚠ không phải một khái niệm có thật; RBAC là kiểm soát quyền, không phải loại khoá.

Ghi nhớ

⚠ Ba mức quản khoá — từ đơn giản tới chặt nhất: | Mức | Nội dung | |---|---| | ⚠ Microsoft-managed key | ⚠ mặc định, không phải làm gì, Microsoft quản toàn bộ | | ⚠ Customer-managed key trong Key Vault | ⚠ bạn quản, khoá bảo vệ bằng phần mềm hoặc HSM dùng chung | | ⚠ CMK trong Managed HSM | ⚠ HSM đơn nhiệm của bạn, FIPS 140-2 Level 3 |

Từ khoá nhận diện:

"tự quản khoá theo chuẩn của tổ chức" → ⚠ customer-managed key "Microsoft quản khoá" → ⚠ service-managed key, mặc định "khoá không rời khỏi HSM" → ⚠ Managed HSM "thêm một lớp mã hoá" → ⚠ infrastructure encryption, chuyện khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Purge protection đã bật trên vault chứa CMK chưa | | | Ai có quyền xoá khoá đó | ⚠ càng ít càng tốt | | Có quy trình xoay vòng khoá không | |

Và câu hỏi nên tự trả lời trước khi chuyển sang CMK: tổ chức có thật sự đủ năng lực vận hành khoá không? CMK trao quyền kiểm soát, nhưng cùng với đó là trách nhiệm mà nếu làm sai thì hậu quả là mất dữ liệu vĩnh viễn.

Đáp án

C — Transparent Database Encryption (TDE).

Vì sao đúng

⚠ TDE mã hoá dữ liệu KHI LƯU: | Mã hoá gì | Nội dung | |---|---| | ⚠ Tệp dữ liệu | ⚠ .mdf | | ⚠ Tệp nhật ký | ⚠ .ldf | | ⚠ Bản sao lưu | ⚠ tự động được mã hoá theo | | ⚠ Ảnh chụp và tệp tạm | |

⚠ "Transparent" nghĩa là ⚠ ứng dụng KHÔNG cần sửa gì — mã hoá và giải mã diễn ra ở tầng CSDL.

⚠ TDE BẬT SẴN cho mọi CSDL mới tạo trong Azure SQL Database.

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

• B (Always Encrypted) — ⚠ mã hoá ở phía CLIENT, bảo vệ dữ liệu KHI DÙNG; ⚠ mạnh hơn TDE ở khía cạnh khác nhưng không phải câu trả lời cho "mã hoá khi lưu".

• A (Dynamic Data Masking) — ⚠ CHE khi hiển thị, dữ liệu trong CSDL vẫn nguyên; ⚠ không phải mã hoá.

• D (Microsoft Entra authentication) — ⚠ xác thực, không mã hoá.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô trước có #23784 và #23816 cùng về bảo vệ dữ liệu trong Azure SQL, cả hai đều có TDE trong khoá. ⚠ Ba câu nhất quán.

⚠ Ba trạng thái dữ liệu và biện pháp tương ứng: | Trạng thái | Biện pháp | Ai không đọc được | |---|---|---| | ⚠ At rest | ⚠ TDE | ⚠ người lấy được tệp đĩa | | ⚠ In transit | ⚠ TLS | ⚠ người nghe lén đường truyền | | ⚠ In use | ⚠ Always Encrypted | ⚠ kể cả quản trị viên CSDL |

Từ khoá nhận diện:

"mã hoá khi lưu, trong suốt với ứng dụng" → ⚠ TDE "kể cả DBA cũng không đọc được" → ⚠ Always Encrypted "che số thẻ khi hiển thị" → ⚠ Dynamic Data Masking "chỉ thấy dòng của mình" → ⚠ Row-Level Security

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TDE có đang bật không | ⚠ mặc định bật, nhưng CSDL di chuyển từ nơi khác có thể chưa | | Có cột nào cần Always Encrypted không | | | Nếu dùng CMK thì purge protection đã bật chưa | |

Và giới hạn cần hiểu đúng về TDE: nó bảo vệ dữ liệu khi ai đó lấy được tệp, không bảo vệ khi ai đó có quyền truy vấn. Với mối đe doạ từ bên trong, TDE gần như không giúp gì — đó là chỗ của Always Encrypted và kiểm soát quyền.

Đáp án

A và C.

• A — Tự động khám phá và phân loại dữ liệu.
• C — Theo dõi dòng dữ liệu (data lineage) trên môi trường đa đám mây.

Vì sao đúng

⚠ Microsoft Purview là nền tảng quản trị dữ liệu: | Khả năng | Nội dung | |---|---| | ⚠ Data Map | ⚠ quét và lập bản đồ tài sản dữ liệu toàn tổ chức | | ⚠ Phân loại tự động | ⚠ nhận diện số thẻ, số định danh cá nhân, dữ liệu nhạy cảm | | ⚠ Data lineage | ⚠ dữ liệu đi từ đâu tới đâu, qua những bước xử lý nào | | ⚠ Data Catalog | ⚠ để người dùng tìm và hiểu dữ liệu | | ⚠ Đa nguồn | ⚠ Azure, AWS, GCP, SQL tại chỗ, SaaS |

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

• B (xử lý dữ liệu thời gian thực) — ⚠ đó là Stream Analytics, Event Hubs, Databricks.

• D (phân tích dữ liệu) — ⚠ đó là Synapse, Fabric, Power BI; ⚠ Purview quản trị dữ liệu chứ không phân tích nó.

Ghi nhớ

⚠ Purview gồm hai nhánh lớn — hay bị lẫn: | Nhánh | Nội dung | |---|---| | ⚠ Purview Data Governance | ⚠ Data Map, Catalog, lineage — cho DỮ LIỆU trong kho và CSDL | | ⚠ Purview Compliance (trước là Microsoft 365 Compliance) | ⚠ Compliance Manager, DLP, Information Protection — cho DỮ LIỆU trong Microsoft 365 |

Từ khoá nhận diện:

"khám phá và phân loại dữ liệu, dòng dữ liệu" → ⚠ Purview governance portal "điểm tuân thủ của tổ chức" → ⚠ Purview Compliance Manager "dán nhãn nhạy cảm cho tài liệu" → ⚠ Purview Information Protection "chặn rò rỉ dữ liệu" → ⚠ Data Loss Prevention

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức có biết dữ liệu nhạy cảm nằm ở đâu không | | | Có nguồn dữ liệu nào chưa được quét không | | | Ai chịu trách nhiệm quản trị dữ liệu | |

Và bước đầu tiên của mọi chương trình bảo vệ dữ liệu, thường bị bỏ qua để nhảy thẳng vào công cụ: biết mình đang có dữ liệu gì và nó nằm ở đâu. Không có bản đồ đó thì mọi chính sách bảo vệ đều chỉ phủ được phần bạn tình cờ nhớ tới.

Đáp án

D — Passwordless authentication.

Vì sao đúng

⚠ Passwordless nâng chất lượng xác minh danh tính lên mức cao nhất: | Phương thức | Yếu tố xác minh | |---|---| | ⚠ Windows Hello for Business | ⚠ sinh trắc học hoặc PIN GẮN VỚI thiết bị | | ⚠ FIDO2 security key | ⚠ khoá phần cứng, chống phishing | | ⚠ Microsoft Authenticator | ⚠ thiết bị đã đăng ký, có number matching |

⚠ Khác với mật khẩu: ⚠ những yếu tố này không thể bị đoán, bị phun, hay bị dùng lại từ vụ rò rỉ khác.

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

• B (Password Protection) — ⚠ chặn mật khẩu yếu, vẫn là thế giới của mật khẩu.

• A (SSO) — ⚠ giảm số lần đăng nhập, không nâng chất lượng xác minh.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C — Microsoft Entra Verified ID ⚠ cũng là một tính năng về xác minh danh tính, và tên gọi rất dễ khiến người làm bài chọn nó.

⚠ Vì sao FIDO2 mạnh nhất: | Lý do | Nội dung | |---|---| | ⚠ Gắn với TÊN MIỀN | ⚠ không ký cho trang giả mạo — chống phishing về mặt kỹ thuật | | ⚠ Không có bí mật nào truyền qua mạng | | | ⚠ Không bị đánh cắp SIM | | | ⚠ Đổi lại | ⚠ cần mua phần cứng và có quy trình phát khoá |

Từ khoá nhận diện:

"bỏ mật khẩu" → ⚠ passwordless "chứng thực có thể kiểm chứng, bằng cấp số" → ⚠ Verified ID "chặn mật khẩu yếu" → ⚠ Password Protection "đăng nhập một lần cho nhiều ứng dụng" → ⚠ SSO

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu người đã đăng ký phương thức passwordless | | | Legacy authentication đã bị chặn chưa | ⚠ nếu chưa thì mọi nỗ lực bị đi vòng | | Có nhóm thí điểm nào đang dùng chưa | |

Và điều kiện tiên quyết để passwordless có ý nghĩa: chặn legacy authentication trước. Nếu vẫn còn cửa cũ chấp nhận tên đăng nhập và mật khẩu, thì việc bỏ mật khẩu ở cửa chính không giải quyết được gì.

Đáp án

B, C và E.

• B — Cấu hình data connector trong Sentinel để tích hợp nhiều nguồn dữ liệu.
• C — Tạo và tuỳ chỉnh analytics rule trong Sentinel để phát hiện mẫu cụ thể.
• E — Cấu hình Data Collection.

Vì sao đúng

⚠ Ba bước dựng một giải pháp giám sát bảo mật hoàn chỉnh: | Bước | Nội dung | |---|---| | ⚠ Data Collection | ⚠ thu thập nhật ký và chỉ số — data collection rule của Azure Monitor | | ⚠ Data connectors | ⚠ đưa dữ liệu từ nhiều nguồn vào Sentinel | | ⚠ Analytics rules | ⚠ biến dữ liệu thành PHÁT HIỆN và incident |

⚠ Nguồn dữ liệu → ⚠ Data Collection → ⚠ Log Analytics
                          ↓ ⚠ data connector
                    ⚠ Microsoft Sentinel
                          ↓ ⚠ analytics rules
                    ⚠ Incident → ⚠ playbook phản ứng

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

• A (dùng Azure Monitor thu thập dữ liệu HIỆU NĂNG ứng dụng) — ⚠ hữu ích nhưng là giám sát VẬN HÀNH, không phải giám sát BẢO MẬT như đề hỏi.

• D (sửa Defender for Cloud để tích hợp với Azure Monitor) — ⚠ hai dịch vụ đã tích hợp SẴN, không phải một bước phải làm.

Ghi nhớ

⚠ Bốn thành phần của Microsoft Sentinel: | Thành phần | Vai trò | |---|---| | ⚠ Data connectors | ⚠ hơn 100 nguồn dựng sẵn, cả sản phẩm ngoài Microsoft | | ⚠ Analytics rules | ⚠ luật phát hiện, sinh ra incident | | ⚠ Workbooks | ⚠ bảng điều khiển trực quan | | ⚠ Playbooks | ⚠ tự động phản ứng, chạy trên Logic Apps | | ⚠ Hunting queries | ⚠ chủ động săn tìm dấu hiệu | | ⚠ UEBA | ⚠ phân tích hành vi bất thường |

Từ khoá nhận diện:

"đưa dữ liệu vào Sentinel" → ⚠ data connector "phát hiện mẫu tấn công" → ⚠ analytics rule "tự động phản ứng" → ⚠ playbook "thu thập nhật ký từ máy" → ⚠ data collection rule của Azure Monitor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguồn nào thực sự sinh ra phát hiện có ích | ⚠ bỏ nguồn chỉ tốn tiền | | Có playbook tự động cho sự cố thường gặp chưa | | | Ai xử lý incident hằng ngày | ⚠ SIEM không có người trực là vô dụng |

Và điều quyết định một hệ thống SIEM có giá trị hay không, không phải số nguồn dữ liệu: có người thật sự xử lý cảnh báo nó sinh ra. Không có quy trình trực và phản ứng, Sentinel chỉ là một hoá đơn hằng tháng.

Đáp án

A, B, C và E.

• A — Giám sát sự kiện bảo mật qua Azure Monitor Logs.
• B — Tự động hoá phản ứng trước mối đe doạ cụ thể.
• C — Tuỳ chỉnh analytics rule để nhận diện mối đe doạ tiềm tàng.
• E — Đánh giá và quản lý các cảnh báo được sinh ra.

Vì sao đúng

⚠ Bốn việc phủ trọn vòng đời của một sự cố an ninh: | Giai đoạn | Việc | |---|---| | ⚠ Thu thập | ⚠ Sentinel dựa trên Log Analytics workspace của Azure Monitor | | ⚠ Phát hiện | ⚠ analytics rule tuỳ chỉnh bằng KQL | | ⚠ Điều tra | ⚠ đánh giá và quản lý incident | | ⚠ Phản ứng | ⚠ playbook tự động trên Logic Apps |

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

• D (thiết lập khả năng cross-workspace) — ⚠ Sentinel CÓ hỗ trợ truy vấn nhiều workspace, nhưng đây là một cấu hình hạ tầng nâng cao, ⚠ không phải một trong bốn năng lực cốt lõi mà đề nhắm tới.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23851 trong lô này hỏi các BƯỚC dựng giải pháp giám sát. ⚠ Câu này hỏi Sentinel LÀM ĐƯỢC gì. Hai câu bổ sung nhau.

⚠ Sentinel là SIEM cộng SOAR: | Viết tắt | Vai trò | |---|---| | ⚠ SIEM | ⚠ thu thập, tương quan, phát hiện | | ⚠ SOAR | ⚠ điều phối và tự động phản ứng |

⚠ Playbook làm được gì: | Hành động | Ví dụ | |---|---| | ⚠ Vô hiệu hoá tài khoản | ⚠ khi phát hiện bị chiếm | | ⚠ Chặn IP trên firewall | | | ⚠ Cô lập máy | ⚠ qua Defender for Endpoint | | ⚠ Tạo ticket | ⚠ ServiceNow, Jira | | ⚠ Gửi thông báo | ⚠ Teams, email | | ⚠ Hỏi người trực xác nhận | ⚠ rồi mới hành động |

Từ khoá nhận diện:

"SIEM và SOAR gốc đám mây" → ⚠ Microsoft Sentinel "tư thế bảo mật tài nguyên" → ⚠ Defender for Cloud "chỉ số và nhật ký vận hành" → ⚠ Azure Monitor "tự động phản ứng" → ⚠ playbook

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có playbook tự động cho loại sự cố hay gặp chưa | | | Thời gian trung bình từ cảnh báo tới xử lý là bao lâu | | | Có bao nhiêu incident đang mở quá hạn | |

Và chỉ số quan trọng nhất để đánh giá một trung tâm vận hành an ninh, quan trọng hơn số cảnh báo phát hiện được: thời gian từ lúc cảnh báo xuất hiện tới lúc có người xử lý. Tự động hoá bằng playbook tồn tại chính là để rút ngắn con số đó.

Đáp án

A, B, D và E.

• A — Bật Microsoft Defender cho Azure SQL Database.
• B — Phản hồi các cảnh báo bảo mật do Defender for Cloud sinh ra.
• D — Đánh giá kết quả quét lỗ hổng từ Defender for Servers.
• E — Tự động hoá quy trình phản ứng trước mối đe doạ được phát hiện.

Vì sao đúng

⚠ Bốn việc thuộc đúng phạm vi của Defender for Cloud: | Việc | Nội dung | |---|---| | ⚠ Bật các gói Defender | ⚠ cho SQL, Storage, Servers, Containers, Key Vault... | | ⚠ Xử lý cảnh báo | ⚠ trang Security alerts, có phân loại mức độ | | ⚠ Xem kết quả quét lỗ hổng | ⚠ cho máy chủ và ảnh container | | ⚠ Workflow automation | ⚠ kích hoạt Logic App khi có cảnh báo hoặc khuyến nghị |

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

• C (cấu hình Virtual Network Gateway) — ⚠ là việc của mạng, hoàn toàn ngoài phạm vi Defender for Cloud.

• F (cài agent của Defender for Cloud) — ⚠ cách nói lỗi thời; ⚠ ngày nay dùng Azure Monitor Agent và Defender for Endpoint, và việc triển khai là TỰ ĐỘNG qua auto-provisioning chứ không phải cài tay.

Ghi nhớ

⚠ Workflow automation — phần hay bị bỏ quên: | Kích hoạt bởi | Nội dung | |---|---| | ⚠ Security alert | ⚠ khi có cảnh báo mới | | ⚠ Recommendation | ⚠ khi trạng thái khuyến nghị đổi | | ⚠ Regulatory compliance | ⚠ khi mức tuân thủ đổi | | ⚠ Hành động | ⚠ chạy Logic App — gửi Teams, tạo ticket, hoặc tự khắc phục |

Từ khoá nhận diện:

"tư thế bảo mật, khuyến nghị, secure score" → ⚠ Defender for Cloud "điều tra sự cố, SIEM" → ⚠ Sentinel "quét lỗ hổng máy chủ" → ⚠ Defender for Servers Plan 2 "tự động khi có cảnh báo" → ⚠ workflow automation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Auto-provisioning đã bật chưa | ⚠ nếu không thì máy mới không được bảo vệ | | Có cảnh báo mức nghiêm trọng nào chưa xử lý không | | | Có workflow automation nào đang chạy không | |

Và cấu hình đáng bật sớm nhất trong Defender for Cloud: auto-provisioning. Không có nó, mỗi máy ảo mới tạo là một điểm mù cho tới khi ai đó nhớ ra phải cài agent — và trong môi trường co giãn tự động thì "ai đó nhớ ra" không bao giờ xảy ra kịp.

Đáp án

A, B và C.

• A — Đánh giá mức tuân thủ so với các khung bảo mật trong Defender for Cloud.
• B — Thêm chuẩn GDPR vào Defender for Cloud.
• C — Thêm initiative tuỳ chỉnh vào Defender for Cloud.

Vì sao đúng

⚠ Ba bước tương ứng ba yêu cầu: | Yêu cầu | Bước | |---|---| | ⚠ Đánh giá theo GDPR | ⚠ thêm chuẩn GDPR vào Regulatory Compliance | | ⚠ Xem kết quả | ⚠ trang Regulatory Compliance hiển thị theo từng kiểm soát | | ⚠ Thêm biện pháp bảo mật RIÊNG | ⚠ custom initiative — bộ Azure Policy của bạn |

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

• E (GỠ chuẩn GDPR hiện có) — ⚠ ngược với yêu cầu; đề muốn ĐÁNH GIÁ theo GDPR.

• D (theo dõi cảnh báo của Azure Security Center) — ⚠ về phát hiện mối đe doạ, không phải đánh giá tuân thủ; ⚠ và "Azure Security Center" là tên CŨ của Defender for Cloud.

• F (cài agent) — ⚠ cách nói lỗi thời, việc triển khai nay là tự động.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23821 ở lô trước cũng hỏi việc làm được với Defender for Cloud về tuân thủ (khoá gồm "thêm chuẩn ngành"). ⚠ Hai câu nhất quán.

⚠ Custom initiative — vì sao cần: | Lý do | Nội dung | |---|---| | ⚠ Chuẩn dựng sẵn không phủ hết yêu cầu nội bộ | | | ⚠ Tổ chức có quy tắc riêng | ⚠ buộc gắn thẻ, cấm vùng, cấm SKU | | ⚠ Gom nhiều Azure Policy thành một bộ | | | ⚠ Hiện lên trong Regulatory Compliance như một chuẩn | | | ⚠ Nền tảng | ⚠ custom initiative CHÍNH LÀ policy initiative của Azure Policy |

Từ khoá nhận diện:

"đánh giá theo chuẩn ngành" → ⚠ Regulatory Compliance "chuẩn riêng của tổ chức" → ⚠ custom initiative "điểm tổng hợp tư thế bảo mật" → ⚠ Secure Score "tuân thủ của cả tổ chức, gồm quy trình và con người" → ⚠ Purview Compliance Manager

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuẩn cần tuân thủ đã được thêm chưa | | | Có kiểm soát nào đang không đạt không | | | Có quy tắc nội bộ nào nên đưa vào custom initiative không | |

Và điều dễ gây hiểu nhầm về báo cáo tuân thủ trong Defender for Cloud: nó chỉ đánh giá phần kỹ thuật. Đạt 100% trên bảng điều khiển không đồng nghĩa với việc tổ chức tuân thủ GDPR — phần quy trình và con người nằm ngoài tầm nhìn của công cụ.