Ngân hàng đề — Microsoft Azure Security Technology
Tìm thấy 100 câu.
- A SQL Server authentication
- B Windows integrated authentication
-
C
Microsoft Entra authentication
- D API key authentication
Xem giải thích
Đáp án
C — Microsoft Entra authentication.
Vì sao đúng
⚠ Entra authentication là cách xác thực dựa trên ĐỊNH DANH cho Azure SQL: | Lợi ích | Nội dung | |---|---| | ⚠ Không lưu mật khẩu trong chuỗi kết nối | ⚠ kết hợp managed identity | | ⚠ Áp được MFA và Conditional Access | | | ⚠ Quản quyền theo NHÓM Entra ID | | | ⚠ Tắt một tài khoản là chặn mọi CSDL | | | ⚠ Nhật ký đăng nhập tập trung | |
Vì sao các phương án khác sai
-
A (SQL Server authentication) — ⚠ tên đăng nhập và mật khẩu lưu TRONG CSDL; không phải định danh tập trung.
-
B (Windows integrated authentication) — ⚠ dựa trên Kerberos và AD TẠI CHỖ; ⚠ Azure SQL Database không hỗ trợ trực tiếp.
-
D (API key authentication) — ⚠ không phải cơ chế của Azure SQL.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23783 trong lô này hỏi CSDL nào KHÔNG hỗ trợ xác thực Entra ID (đáp án MariaDB, dịch vụ đã ngừng). ⚠ Câu này hỏi nên dùng cách xác thực nào. Hai câu bổ sung nhau.
⚠ Ba loại principal trong Azure SQL với Entra ID: | Loại | Nội dung | |---|---| | ⚠ Người dùng Entra ID | ⚠ cá nhân | | ⚠ Nhóm Entra ID | ⚠ cách quản lý tốt nhất — gán quyền cho nhóm | | ⚠ Managed identity hoặc service principal | ⚠ cho ứng dụng |
⚠ Cấu hình cần có: | Bước | Nội dung | |---|---| | ⚠ Đặt Entra admin cho SQL server | ⚠ nên là một NHÓM, không phải cá nhân | | ⚠ Tạo user trong CSDL từ external provider | ⚠ CREATE USER [ten] FROM EXTERNAL PROVIDER | | ⚠ Gán vai trò trong CSDL | ⚠ db_datareader, db_datawriter... | | ⚠ Cân nhắc tắt hẳn SQL authentication | ⚠ chỉ cho phép Entra ID |
Từ khoá nhận diện:
"xác thực dựa trên định danh" → ⚠ Entra authentication "tên đăng nhập lưu trong CSDL" → ⚠ SQL authentication "ứng dụng kết nối không cần mật khẩu" → ⚠ managed identity kèm Entra "mã hoá dữ liệu khi lưu" → ⚠ TDE, chuyện khác
| ⚠ Vì sao nên đặt Entra admin là NHÓM | Lý do |
|---|---|
| ⚠ Cá nhân nghỉ việc là mất quyền quản trị CSDL | |
| ⚠ Nhóm cho phép nhiều người cùng quản | |
| ⚠ Thêm bớt thành viên không phải sửa cấu hình SQL | |
| ⚠ Chỉ đặt được | ⚠ MỘT Entra admin cho mỗi SQL server |
| ⚠ Kiến trúc kết nối không mật khẩu | Kiến trúc |
|---|---|
| ⚠ App Service bật managed identity | |
| ⚠ Tạo user trong CSDL cho identity đó | |
| ⚠ Gán vai trò tối thiểu | |
| ⚠ Chuỗi kết nối KHÔNG chứa mật khẩu | |
| ⚠ Kết quả | ⚠ không có bí mật nào để lộ hay để xoay vòng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Entra admin của SQL server là nhóm hay cá nhân | | | SQL authentication đã tắt được chưa | | | Chuỗi kết nối còn mật khẩu dạng rõ không | |
Và cấu hình đáng sửa sớm nhất của mọi Azure SQL Database: đặt Entra admin là một nhóm, không phải một người. Đặt cá nhân là tạo ra một điểm hỏng đơn lẻ ngay trong lớp quản trị CSDL.
You have a responsibility to maintain security and compliance over sensitive data in your organization.
Which of the following can you implement in Azure SQL Database to ensure the protection of this data at rest and during operations? (Select three)
- A Transparent Database Encryption (TDE)
-
B
Always Encrypted
-
C
The Microsoft Purview governance portal
-
D
Dynamic Data masking
-
E
Transparent Data Encryption (TDE) with a custom Hardware Security Module (HSM)
-
F
Data Anonymization
Xem giải thích
Đáp án
A, B và D — Transparent Data Encryption, Always Encrypted, và Dynamic Data Masking.
Vì sao đúng
⚠ Ba biện pháp phủ ba trạng thái của dữ liệu: | Biện pháp | Bảo vệ khi | |---|---| | ⚠ TDE | ⚠ dữ liệu LƯU trên đĩa — bảo vệ nếu tệp bị đánh cắp | | ⚠ Always Encrypted | ⚠ dữ liệu ĐANG DÙNG — mã hoá ngay ở phía client, máy chủ không có khoá | | ⚠ Dynamic Data Masking | ⚠ dữ liệu HIỂN THỊ — che một phần với người không đủ quyền |
Vì sao các phương án khác sai
-
C (Microsoft Purview governance portal) — ⚠ quản trị và phân loại dữ liệu toàn tổ chức, không phải tính năng bảo vệ TRONG Azure SQL Database.
-
E (TDE với HSM tuỳ chỉnh) — ⚠ TDE dùng customer-managed key trong Key Vault hoặc Managed HSM là có thật, nhưng cách diễn đạt "custom HSM" không phải một tuỳ chọn có tên như vậy.
-
F (Data Anonymization) — ⚠ không phải một tính năng có tên như vậy trong Azure SQL.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23784 trong lô này cũng hỏi biện pháp mã hoá và kiểm toán cho Azure SQL, khoá là TDE, TLS, Auditing, Advanced Threat Protection. ⚠ Câu này nghiêng về BẢO VỆ DỮ LIỆU NHẠY CẢM nên chọn Always Encrypted và Dynamic Data Masking. Hai câu bổ sung nhau, giữ nguyên cả hai khoá.
| Câu | Trọng tâm | Khoá |
|---|---|---|
| ⚠ #23784 | ⚠ mã hoá và KIỂM TOÁN | ⚠ TDE, TLS, Auditing, ATP |
| ⚠ #23816 (câu này) | ⚠ bảo vệ dữ liệu NHẠY CẢM | ⚠ TDE, Always Encrypted, DDM |
⚠ Ba trạng thái của dữ liệu và biện pháp tương ứng: | Trạng thái | Biện pháp | |---|---| | ⚠ At rest — khi lưu | ⚠ TDE | | ⚠ In transit — khi truyền | ⚠ TLS | | ⚠ In use — khi dùng | ⚠ Always Encrypted |
Từ khoá nhận diện:
"kể cả DBA cũng không đọc được" → ⚠ Always Encrypted "mã hoá tệp dữ liệu và bản sao lưu" → ⚠ TDE "che số thẻ, chỉ hiện bốn số cuối" → ⚠ Dynamic Data Masking "chỉ thấy dòng thuộc về mình" → ⚠ Row-Level Security
| ⚠ Always Encrypted — được gì, mất gì | Điều |
|---|---|
| ⚠ ĐƯỢC: máy chủ KHÔNG BAO GIỜ thấy dữ liệu rõ | ⚠ khoá nằm ở phía client |
| ⚠ ĐƯỢC: bảo vệ khỏi cả quản trị viên CSDL | |
| ⚠ MẤT: hạn chế truy vấn | ⚠ deterministic chỉ so bằng; randomized không so được |
| ⚠ MẤT: ứng dụng phải dùng driver hỗ trợ | |
| ⚠ Bản nâng cao | ⚠ Always Encrypted with secure enclaves — truy vấn được nhiều hơn |
| ⚠ Dynamic Data Masking — giới hạn cần biết | Giới hạn |
|---|---|
| ⚠ Chỉ CHE khi HIỂN THỊ | ⚠ dữ liệu trong CSDL vẫn nguyên vẹn |
| ⚠ Không phải biện pháp mã hoá | |
| ⚠ Người có quyền vẫn suy ra được bằng truy vấn khéo | |
| ⚠ Vì thế | ⚠ là lớp tiện lợi, KHÔNG phải lớp bảo vệ chính |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột nào chứa dữ liệu nhạy cảm | ⚠ dùng Data Discovery and Classification | | Có cột nào cần Always Encrypted không | ⚠ số thẻ, số định danh cá nhân | | Có đang nhầm Dynamic Data Masking là mã hoá không | |
Và điều hay bị hiểu sai nhất về Dynamic Data Masking: nó không mã hoá gì cả. Dữ liệu vẫn nằm nguyên trong CSDL — nó chỉ che ở lớp hiển thị, nên đừng dùng nó thay cho mã hoá thật.
- A Storage account firewalls
- B Azure Blob versioning
- C Soft delete for Azure Blobs
-
D
Immutable storage for Azure Blob
Xem giải thích
Đáp án
D — Immutable storage cho Azure Blob.
Vì sao đúng
⚠ Immutable storage thực hiện mô hình WORM — ghi một lần, đọc nhiều lần: | Đặc điểm | Nội dung | |---|---| | ⚠ Dữ liệu KHÔNG sửa được | | | ⚠ Dữ liệu KHÔNG xoá được | ⚠ trong thời gian giữ đã khai | | ⚠ Áp cho cả chủ tài khoản | ⚠ khi policy đã LOCKED | | ⚠ Đáp ứng yêu cầu tuân thủ | ⚠ SEC 17a-4, FINRA, CFTC |
⚠ Hai loại policy: | Loại | Nội dung | |---|---| | ⚠ Time-based retention | ⚠ khoá trong N ngày kể từ khi ghi | | ⚠ Legal hold | ⚠ khoá vô thời hạn tới khi gỡ thẻ |
Vì sao các phương án khác sai
-
C (soft delete) — ⚠ cho phép KHÔI PHỤC sau khi xoá, nhưng không NGĂN được việc xoá.
-
B (versioning) — ⚠ giữ phiên bản cũ khi ghi đè, nhưng phiên bản vẫn xoá được.
-
A (storage firewall) — ⚠ kiểm soát TRUY CẬP theo mạng, không liên quan tới tính bất biến.
Ghi nhớ
⚠ Đối chiếu: ⚠ lô này có ba câu liên quan tới immutable storage — #23782, #23813, và câu này. ⚠ Cả ba nhất quán: immutability là biện pháp mạnh nhất chống sửa và xoá.
⚠ Phân biệt ba cơ chế hay bị lẫn: | Cơ chế | Ngăn xoá | Khôi phục được | |---|---|---| | ⚠ Soft delete | ⚠ KHÔNG ngăn | ⚠ có, trong thời gian giữ | | ⚠ Versioning | ⚠ KHÔNG ngăn | ⚠ có, phiên bản cũ | | ⚠ Immutable storage | ⚠ NGĂN HẲN | ⚠ không cần — dữ liệu không mất được |
Từ khoá nhận diện:
"không sửa không xoá được trong thời gian giữ" → ⚠ immutable storage, WORM "khôi phục sau khi xoá" → ⚠ soft delete "giữ phiên bản cũ" → ⚠ versioning "chỉ mạng này truy cập được" → ⚠ storage firewall
| ⚠ Vì sao immutability là biện pháp chống ransomware mạnh nhất | Lý do |
|---|---|
| ⚠ Kẻ tấn công chiếm được tài khoản quản trị cũng KHÔNG mã hoá hay xoá được | |
| ⚠ Sao lưu thông thường vẫn có thể bị xoá bằng quyền quản trị | |
| ⚠ Policy đã LOCKED thì không ai gỡ được trước hạn | ⚠ kể cả Microsoft |
| ⚠ Đổi lại | ⚠ cân nhắc rất kỹ thời gian giữ, vì không rút ngắn được |
| ⚠ Áp ở hai cấp | Cấp |
|---|---|
| ⚠ Cấp container | ⚠ áp cho mọi blob trong đó |
| ⚠ Cấp từng blob | ⚠ version-level immutability |
| ⚠ Chế độ | ⚠ Unlocked để thử, Locked là không lùi được |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu tuân thủ đã có immutability chưa | | | Policy đang ở chế độ Unlocked hay Locked | ⚠ Unlocked thì vẫn xoá được | | Thời gian giữ có phù hợp quy định không | ⚠ khoá rồi không rút ngắn được |
Và quyết định cần cân nhắc kỹ nhất trước khi khoá một immutability policy: thời gian giữ. Đặt quá ngắn thì không đủ tuân thủ; đặt quá dài thì bạn trả tiền lưu trữ cho dữ liệu không thể xoá, trong nhiều năm, không có cách nào rút lại.
- A Azure Blueprint
- B Azure Policy
- C Azure Landing Zone
- D Azure Key Vault
Xem giải thích
Đáp án
D — Azure Key Vault.
Vì sao đúng
⚠ Key Vault là dịch vụ chuyên dụng cho bí mật: | Lưu được | Nội dung | |---|---| | ⚠ Secrets | ⚠ API key, mật khẩu, chuỗi kết nối | | ⚠ Keys | ⚠ khoá mã hoá — DÙNG được nhưng KHÔNG lấy ra được | | ⚠ Certificates | ⚠ chứng chỉ TLS, có tự gia hạn |
⚠ Key Vault cung cấp gì: | Khả năng | Nội dung | |---|---| | ⚠ Mã hoá khi lưu | | | ⚠ Kiểm soát truy cập chi tiết | ⚠ RBAC hoặc access policy | | ⚠ NHẬT KÝ mọi lần truy cập | | | ⚠ Soft delete và purge protection | | | ⚠ Tuỳ chọn bảo vệ bằng HSM | | | ⚠ Tích hợp với App Service, Functions, AKS | |
Vì sao các phương án khác sai
-
B (Azure Policy) — ⚠ áp luật lên cấu hình tài nguyên, không lưu bí mật.
-
A (Azure Blueprint) — ⚠ đóng gói mẫu môi trường; ⚠ đang được thay dần bằng Deployment Stacks.
-
C (Azure Landing Zone) — ⚠ kiến trúc tham chiếu để dựng nền tảng Azure, không phải dịch vụ lưu bí mật.
Ghi nhớ
⚠ Ba loại đối tượng trong Key Vault — khác nhau ở tính lấy ra được: | Loại | Lấy giá trị ra được không | |---|---| | ⚠ Key | ⚠ KHÔNG — chỉ dùng để mã hoá và ký | | ⚠ Secret | ⚠ CÓ — đọc được giá trị | | ⚠ Certificate | ⚠ có, gồm cả khoá riêng |
Từ khoá nhận diện:
"API key, chuỗi kết nối, mật khẩu" → ⚠ Key Vault secret "khoá mã hoá không được lấy ra" → ⚠ Key Vault key "không lưu bí mật nào" → ⚠ managed identity "cấu hình và feature flag" → ⚠ App Configuration
| ⚠ Hai lớp bảo vệ BẮT BUỘC cho Key Vault | Lớp |
|---|---|
| ⚠ Soft delete | ⚠ giữ vault và secret đã xoá — nay BẬT MẶC ĐỊNH |
| ⚠ Purge protection | ⚠ không xoá vĩnh viễn được trước hạn |
| ⚠ Vì sao quan trọng | ⚠ xoá vault chứa khoá mã hoá là MẤT DỮ LIỆU VĨNH VIỄN |
| ⚠ Với customer-managed key | ⚠ purge protection là BẮT BUỘC |
| ⚠ Thực hành tốt | Thực hành |
|---|---|
| ⚠ Ứng dụng truy cập bằng managed identity | |
| ⚠ Dùng RBAC thay cho access policy | ⚠ hướng khuyến nghị hiện nay |
| ⚠ Private endpoint cho môi trường thật | |
| ⚠ Bật nhật ký chẩn đoán | |
| ⚠ Luân chuyển secret định kỳ | |
| ⚠ Vault riêng cho từng môi trường | ⚠ dev, test, prod tách biệt |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Purge protection đã bật chưa | | | Ai có quyền xoá trên vault | ⚠ càng ít càng tốt | | Có nhật ký ai truy cập secret nào không | |
Và rủi ro nghiêm trọng nhất liên quan tới Key Vault, nghiêm trọng hơn cả việc bị lộ bí mật: xoá nhầm một vault chứa khoá mã hoá dữ liệu. Không có purge protection thì dữ liệu mã hoá bằng khoá đó không bao giờ đọc lại được.
Which of the following can be done using Azure Key Vault? (Select three)
-
A
Secrets Management
- B Deploying compliant environments
-
C
Key Management
-
D
Assigning security policies at the subscription level
-
E
Integrate with Other Azure Services
Xem giải thích
Đáp án
A, C và E — Secrets Management, Key Management, và tích hợp với các dịch vụ Azure khác.
Vì sao đúng
⚠ Ba nhóm khả năng của Key Vault: | Nhóm | Nội dung | |---|---| | ⚠ Secrets Management | ⚠ lưu và kiểm soát truy cập token, mật khẩu, chuỗi kết nối, API key | | ⚠ Key Management | ⚠ tạo và quản lý khoá mã hoá; dùng làm customer-managed key cho Storage, SQL, Disk | | ⚠ Tích hợp dịch vụ khác | ⚠ App Service, Functions, AKS, ARM template, Azure Disk Encryption |
⚠ Ngoài ra Key Vault còn quản lý CHỨNG CHỈ — cấp, gia hạn tự động, và tích hợp với CA.
Vì sao các phương án khác sai
-
B (triển khai môi trường tuân thủ) — ⚠ đó là Azure Blueprint hoặc Deployment Stacks.
-
D (gán chính sách bảo mật ở cấp subscription) — ⚠ đó là Azure Policy.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23818 trong lô này hỏi dịch vụ nào để quản lý bí mật (đáp án Key Vault). ⚠ Câu này liệt kê các khả năng của nó. Hai câu bổ sung nhau.
⚠ Key Vault tích hợp với những gì: | Dịch vụ | Cách dùng | |---|---| | ⚠ App Service và Functions | ⚠ Key Vault reference trong app settings | | ⚠ Azure Disk Encryption | ⚠ lưu khoá mã hoá đĩa | | ⚠ Storage và SQL | ⚠ customer-managed key cho mã hoá | | ⚠ AKS | ⚠ Secrets Store CSI Driver | | ⚠ ARM template và Bicep | ⚠ tham chiếu secret lúc triển khai | | ⚠ Application Gateway và Front Door | ⚠ lấy chứng chỉ TLS |
Từ khoá nhận diện:
"lưu bí mật, khoá, chứng chỉ" → ⚠ Key Vault "đóng gói môi trường chuẩn" → ⚠ Blueprint, Deployment Stacks "áp luật lên cấu hình" → ⚠ Azure Policy "cấu hình ứng dụng, feature flag" → ⚠ App Configuration
| ⚠ Hai bậc của Key Vault | Bậc |
|---|---|
| ⚠ Standard | ⚠ khoá bảo vệ bằng phần mềm |
| ⚠ Premium | ⚠ khoá bảo vệ bằng HSM dùng chung, FIPS 140-2 Level 2 |
| ⚠ Managed HSM | ⚠ dịch vụ RIÊNG, HSM đơn nhiệm, FIPS 140-2 Level 3 |
| ⚠ Key Vault và App Configuration — phân vai | Phân vai |
|---|---|
| ⚠ Key Vault | ⚠ thứ BÍ MẬT — mật khẩu, khoá, chứng chỉ |
| ⚠ App Configuration | ⚠ thứ KHÔNG bí mật — cấu hình, feature flag |
| ⚠ Dùng chung | ⚠ App Configuration tham chiếu được secret trong Key Vault |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vault có dùng RBAC hay còn access policy | ⚠ RBAC là hướng khuyến nghị | | Có secret nào chưa bao giờ được xoay vòng không | | | Nhật ký truy cập có được gửi đi và có ai xem không | |
Và cách dùng Key Vault đạt hiệu quả cao nhất: kết hợp với managed identity. Ứng dụng không giữ bí mật nào để mở Key Vault, còn Key Vault giữ mọi bí mật khác — chuỗi tin cậy khép kín mà không có mắt xích nào phải cất bằng tay.
- A Secure Inventory
- B External Attack Surface Management
- C Secure Score
- D Compliance Framework
-
E
Vulnerability Assessment
Xem giải thích
Đáp án
C — Secure Score (điểm bảo mật).
Vì sao đúng
⚠ Secure Score là con số tổng hợp tư thế bảo mật: | Đặc điểm | Nội dung | |---|---| | ⚠ Tính theo khuyến nghị đã thực hiện | ⚠ dựa trên Microsoft Cloud Security Benchmark | | ⚠ Hiển thị theo phần trăm | ⚠ và điểm tuyệt đối | | ⚠ Xếp khuyến nghị theo mức TÁC ĐỘNG | ⚠ làm cái nào trước thì tăng nhiều nhất | | ⚠ Theo dõi được theo thời gian | ⚠ thấy tiến bộ hay tụt lùi | | ⚠ So sánh giữa các subscription | |
Vì sao các phương án khác sai
-
E (Vulnerability Assessment) — ⚠ quét lỗ hổng trên máy và ảnh container, là MỘT phần đóng góp vào điểm.
-
B (External Attack Surface Management) — ⚠ khám phá tài sản phơi ra Internet, một chức năng riêng.
-
A (Secure Inventory) và D (Compliance Framework) — ⚠ không phải tên tính năng chính xác; ⚠ thứ gần nhất là Inventory và Regulatory Compliance.
Ghi nhớ
⚠ Ba trụ cột của Microsoft Defender for Cloud: | Trụ cột | Nội dung | |---|---| | ⚠ CSPM — quản lý tư thế bảo mật | ⚠ Secure Score, khuyến nghị, Regulatory Compliance | | ⚠ CWPP — bảo vệ khối lượng công việc | ⚠ các gói Defender cho Servers, Storage, SQL... | | ⚠ DevSecOps | ⚠ quét mã và pipeline |
Từ khoá nhận diện:
"điểm tổng hợp tư thế bảo mật" → ⚠ Secure Score "tuân thủ chuẩn ngành" → ⚠ Regulatory Compliance "quét lỗ hổng trên máy" → ⚠ Vulnerability Assessment "tài sản phơi ra Internet" → ⚠ External Attack Surface Management
| ⚠ Cách dùng Secure Score cho đúng | Cách |
|---|---|
| ⚠ Ưu tiên khuyến nghị có tác động cao | ⚠ không làm tràn lan từ trên xuống |
| ⚠ Theo dõi XU HƯỚNG, không chỉ con số | |
| ⚠ Đặt mục tiêu thực tế | ⚠ 100% gần như không đạt được |
| ⚠ Ghi lý do khi bỏ qua một khuyến nghị | ⚠ exempt có ghi chú |
| ⚠ Điểm cần hiểu đúng về Secure Score | Điều |
|---|---|
| ⚠ Là chỉ số ĐỊNH HƯỚNG, không phải chứng nhận | |
| ⚠ Điểm cao không có nghĩa là không bị tấn công | |
| ⚠ Điểm thấp thường chỉ ra lỗ hổng thật | |
| ⚠ Giá trị lớn nhất | ⚠ danh sách việc cần làm đã xếp sẵn theo mức tác động |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Secure Score hiện tại là bao nhiêu | | | Ba khuyến nghị tác động cao nhất chưa làm là gì | | | Ai chịu trách nhiệm theo dõi con số này | |
Và cách dùng Secure Score hiệu quả nhất: coi nó là danh sách việc cần làm đã sắp xếp sẵn, không phải một con số để khoe. Ba khuyến nghị tác động cao nhất thường đáng giá hơn ba mươi khuyến nghị nhỏ cộng lại.
You're responsible for ensuring that your organization's cloud infrastructure complies with industry standards.
Which of the following tasks can you accomplish with Microsoft Defender for Cloud? (Select three)
- A Monitor external assets for vulnerabilities
- B Add industry-specific regulatory standards
- C Connect to multi-cloud environments
-
D
Development and Deployment Automation
Xem giải thích
Đáp án
A, B và C.
- A — Giám sát tài sản bên ngoài để tìm lỗ hổng.
- B — Thêm các chuẩn quy định riêng của ngành.
- C — Kết nối tới môi trường đa đám mây.
Vì sao đúng
⚠ Ba khả năng phục vụ mục tiêu tuân thủ: | Khả năng | Nội dung | |---|---| | ⚠ External Attack Surface Management | ⚠ khám phá tài sản phơi ra Internet và tìm lỗ hổng trên đó | | ⚠ Regulatory Compliance | ⚠ thêm chuẩn ngành — PCI DSS, HIPAA, ISO 27001, NIST | | ⚠ Multi-cloud | ⚠ kết nối AWS và Google Cloud, đánh giá cùng một bảng điều khiển |
Vì sao các phương án khác sai
- D (tự động hoá phát triển và triển khai) — ⚠ đó là Azure DevOps hoặc GitHub Actions; ⚠ Defender for Cloud có phần DevSecOps để QUÉT pipeline, nhưng không tự động hoá việc triển khai.
Ghi nhớ
⚠ Regulatory Compliance của Defender for Cloud: | Đặc điểm | Nội dung | |---|---| | ⚠ Chuẩn mặc định | ⚠ Microsoft Cloud Security Benchmark | | ⚠ Thêm được chuẩn ngành | ⚠ PCI DSS, HIPAA/HITRUST, ISO 27001, NIST SP 800-53, SOC 2 | | ⚠ Hiển thị mức tuân thủ theo từng kiểm soát | | | ⚠ Xuất báo cáo cho kiểm toán | | | ⚠ Nền tảng | ⚠ Azure Policy initiative |
Từ khoá nhận diện:
"tài sản phơi ra Internet" → ⚠ External Attack Surface Management "chuẩn ngành, báo cáo tuân thủ" → ⚠ Regulatory Compliance "AWS và GCP trong cùng bảng điều khiển" → ⚠ multi-cloud connector "điểm tổng hợp" → ⚠ Secure Score
| ⚠ Kết nối đa đám mây làm được gì | Việc |
|---|---|
| ⚠ Đánh giá tư thế bảo mật AWS và GCP | |
| ⚠ Khuyến nghị theo chuẩn của từng nền tảng | ⚠ CIS benchmark tương ứng |
| ⚠ Một Secure Score chung | |
| ⚠ Bảo vệ workload trên đó | ⚠ Defender for Servers cho EC2 chẳng hạn |
| ⚠ Kết nối bằng | ⚠ native connector, không cần agent trung gian |
| ⚠ Phân biệt Defender for Cloud với các công cụ tuân thủ khác | Công cụ |
|---|---|
| ⚠ Defender for Cloud | ⚠ tư thế bảo mật của TÀI NGUYÊN đám mây |
| ⚠ Purview Compliance Manager | ⚠ tuân thủ của cả TỔ CHỨC, gồm cả quy trình và con người |
| ⚠ Azure Policy | ⚠ cơ chế BUỘC tài nguyên tuân theo |
| ⚠ Service Trust Portal | ⚠ chứng nhận của chính MICROSOFT |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuẩn ngành cần tuân thủ đã được thêm vào chưa | | | Có tài khoản AWS hoặc GCP nào chưa kết nối không | | | Mức tuân thủ hiện tại theo từng chuẩn là bao nhiêu | |
Và điều làm Defender for Cloud hữu ích hơn một bảng kiểm thủ công: nó ánh xạ từng kiểm soát của chuẩn ngành sang tình trạng thật của từng tài nguyên. Thay vì tự đối chiếu hàng trăm mục, bạn thấy ngay mục nào chưa đạt và tài nguyên nào gây ra điều đó.
You're setting up Microsoft Defender for Cloud to enhance the security posture of your organization's Azure services. Which of the following can you directly enable workload protection for? (Select five)
- A Azure Storage
- B Azure Resource Manager
- C Entra ID
- D Azure DNS
-
E
Databases
-
F
Servers
Xem giải thích
Đáp án
A, B, D, E và F — Azure Storage, Azure Resource Manager, Azure DNS, Databases, và Servers.
Vì sao đúng
⚠ Các gói Defender bảo vệ workload — bật riêng cho từng loại tài nguyên: | Gói | Bảo vệ gì | |---|---| | ⚠ Defender for Servers | ⚠ máy ảo, máy tại chỗ qua Azure Arc — EDR, quét lỗ hổng, JIT | | ⚠ Defender for Storage | ⚠ phát hiện tải lên mã độc, truy cập bất thường | | ⚠ Defender for Databases | ⚠ SQL, MySQL, PostgreSQL, Cosmos DB — phát hiện SQL injection | | ⚠ Defender for Resource Manager | ⚠ phát hiện thao tác quản lý đáng ngờ | | ⚠ Defender for DNS | ⚠ phát hiện truy vấn tới miền độc hại, DNS exfiltration | | ⚠ Defender for Containers, Key Vault, App Service | ⚠ các gói khác |
Vì sao các phương án khác sai
- C (Entra ID) — ⚠ KHÔNG có gói "Defender for Entra ID" trong Defender for Cloud; ⚠ bảo vệ định danh thuộc về Entra ID Protection và Microsoft Defender for Identity — hai sản phẩm khác.
Ghi nhớ
⚠ Phân biệt các sản phẩm mang tên "Defender": | Sản phẩm | Bảo vệ | |---|---| | ⚠ Defender for Cloud | ⚠ tài nguyên đám mây — tư thế và workload | | ⚠ Defender for Identity | ⚠ Active Directory TẠI CHỖ | | ⚠ Entra ID Protection | ⚠ định danh trên ĐÁM MÂY | | ⚠ Defender for Endpoint | ⚠ máy trạm và máy chủ, EDR | | ⚠ Defender for Office 365 | ⚠ email và cộng tác | | ⚠ Tất cả gom trong | ⚠ Microsoft Defender XDR |
Từ khoá nhận diện:
"bảo vệ tài nguyên Azure theo loại" → ⚠ các gói Defender for Cloud "bảo vệ định danh đám mây" → ⚠ Entra ID Protection "bảo vệ AD tại chỗ" → ⚠ Defender for Identity "EDR trên máy trạm" → ⚠ Defender for Endpoint
| ⚠ Defender for DNS bắt được gì | Bắt được |
|---|---|
| ⚠ Truy vấn tới miền chỉ huy của mã độc | |
| ⚠ Rò rỉ dữ liệu qua DNS | ⚠ DNS exfiltration |
| ⚠ Đào tiền mã hoá | |
| ⚠ Đây là | ⚠ một trong những tín hiệu sớm nhất khi máy bị nhiễm |
| ⚠ Chi phí các gói Defender | Chi phí |
|---|---|
| ⚠ Tính theo tài nguyên được bảo vệ | ⚠ theo máy, theo giao dịch, theo CSDL |
| ⚠ Bật hết mọi gói có thể rất tốn | |
| ⚠ Nên ưu tiên theo mức rủi ro | ⚠ Servers và Databases thường đáng nhất |
| ⚠ Có bản dùng thử 30 ngày | ⚠ để ước lượng chi phí thật |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gói nào đang bật và tốn bao nhiêu mỗi tháng | | | Tài nguyên nhạy cảm nhất đã được bảo vệ chưa | | | Cảnh báo Defender có ai xử lý không | ⚠ không có người trực thì mọi gói đều vô ích |
Và tín hiệu sớm thường bị bỏ qua nhất khi một máy trong hệ thống bị nhiễm mã độc: truy vấn DNS tới miền lạ. Máy vẫn chạy, dịch vụ vẫn bình thường, chỉ có nhật ký DNS là bất thường — và Defender for DNS bắt đúng điều đó.
- A Microsoft Defender for Storage
- B Microsoft Defender for Containers
-
C
Microsoft Defender for Server
- D Microsoft Defender for Key Vault
Xem giải thích
Đáp án
C — Microsoft Defender for Servers.
Vì sao đúng
⚠ Defender for Servers bảo vệ máy ảo và máy chủ: | Khả năng | Nội dung | |---|---| | ⚠ Đánh giá lỗ hổng | ⚠ tích hợp Microsoft Defender Vulnerability Management | | ⚠ EDR | ⚠ qua Microsoft Defender for Endpoint | | ⚠ Just-in-Time VM Access | ⚠ mở cổng quản trị có thời hạn | | ⚠ Adaptive application controls | ⚠ danh sách trắng ứng dụng | | ⚠ File Integrity Monitoring | ⚠ phát hiện thay đổi tệp hệ thống | | ⚠ Bảo vệ cả máy TẠI CHỖ | ⚠ qua Azure Arc |
Vì sao các phương án khác sai
-
A (Defender for Storage) — ⚠ bảo vệ tài khoản lưu trữ.
-
B (Defender for Containers) — ⚠ bảo vệ cụm Kubernetes và ảnh container.
-
D (Defender for Key Vault) — ⚠ phát hiện truy cập bất thường vào vault.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23822 trong lô này liệt kê các loại tài nguyên bật được workload protection. ⚠ Câu này chọn đúng gói cho một tình huống cụ thể. Hai câu bổ sung nhau.
⚠ Hai bậc của Defender for Servers: | Bậc | Nội dung | |---|---| | ⚠ Plan 1 | ⚠ chỉ Defender for Endpoint — EDR | | ⚠ Plan 2 | ⚠ thêm đánh giá lỗ hổng, JIT, FIM, adaptive controls, nhật ký miễn phí 500 MB | | ⚠ Với tình huống đánh giá lỗ hổng | ⚠ cần Plan 2 |
Từ khoá nhận diện:
"quét lỗ hổng trên máy chủ" → ⚠ Defender for Servers "quét lỗ hổng ảnh container" → ⚠ Defender for Containers "tải lên tệp độc hại" → ⚠ Defender for Storage "truy cập bất thường vào vault" → ⚠ Defender for Key Vault
| ⚠ Quy trình xử lý một lỗ hổng được báo | Bước |
|---|---|
| ⚠ 1. Xác nhận lỗ hổng có thật và áp cho máy này không | |
| ⚠ 2. Đánh giá mức khai thác được | ⚠ máy có phơi ra Internet không |
| ⚠ 3. Kiểm tra có bản vá chưa | |
| ⚠ 4. Vá, hoặc giảm nhẹ tạm thời | ⚠ đóng cổng, hạn chế truy cập |
| ⚠ 5. Kiểm chứng lại sau khi vá |
| ⚠ Vá lỗi trên Azure — công cụ | Công cụ |
|---|---|
| ⚠ Azure Update Manager | ⚠ quản lý bản vá cho VM Azure và máy qua Arc |
| ⚠ Defender Vulnerability Management | ⚠ phát hiện và xếp hạng lỗ hổng |
| ⚠ Azure Policy | ⚠ buộc máy phải cài agent và tuân thủ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào đang có lỗ hổng mức nghiêm trọng chưa vá | | | Máy đó có phơi ra Internet không | ⚠ quyết định mức ưu tiên | | Chu kỳ vá lỗi hiện tại là bao lâu | |
Và yếu tố quyết định mức ưu tiên khi xử lý một lỗ hổng: máy đó có tiếp cận được từ bên ngoài không. Một lỗ hổng nghiêm trọng trên máy chỉ nằm trong mạng nội bộ thường ít cấp bách hơn một lỗ hổng trung bình trên máy phơi thẳng ra Internet.
You are managing a hybrid cloud environment with Entra ID and an on-premises Active Directory. You need to ensure that highly privileged Entra ID roles are only assigned when necessary and are automatically revoked after a specific period.
Which Azure service or feature should you use to achieve this?
-
A
Entra Privileged Identity Management (PIM)
-
B
Entra Conditional Access Policies
-
C
Entra Identity Protection
-
D
Entra Role-Based Access Control (RBAC)
Xem giải thích
Đáp án
A — Entra Privileged Identity Management (PIM).
Vì sao đúng
⚠ PIM đúng hai yêu cầu của đề: | Yêu cầu | PIM đáp ứng | |---|---| | ⚠ Chỉ gán vai trò khi CẦN | ⚠ eligible — đủ điều kiện nhưng chưa có quyền; kích hoạt khi cần dùng | | ⚠ TỰ ĐỘNG thu hồi sau một khoảng | ⚠ hết thời hạn kích hoạt là quyền tự mất |
⚠ Áp cho cả hai loại vai trò: | Loại | Ví dụ | |---|---| | ⚠ Vai trò Entra ID | ⚠ Global Administrator, User Administrator | | ⚠ Vai trò tài nguyên Azure | ⚠ Owner, Contributor trên subscription | | ⚠ Nhóm có thể gán vai trò | ⚠ PIM for Groups |
Vì sao các phương án khác sai
-
D (Entra RBAC) — ⚠ gán quyền THƯỜNG TRỰC, không có khái niệm thời hạn hay tự thu hồi.
-
B (Conditional Access) — ⚠ khai điều kiện ĐĂNG NHẬP, không quản lý vòng đời của quyền.
-
C (Identity Protection) — ⚠ phát hiện rủi ro định danh.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23791 trong CÙNG lô.
| Câu | Đề bài | Khoá |
|---|---|---|
| ⚠ #23791 | ⚠ "quản lý và cấp quyền CÓ THỜI HẠN cho vai trò Entra ID và tài nguyên Azure" | ⚠ D — PIM |
| ⚠ #23824 (câu này) | ⚠ "vai trò đặc quyền chỉ gán khi cần và tự thu hồi sau một khoảng" | ⚠ A — PIM |
| ⚠ Nội dung | ⚠ cùng một ý | |
| ⚠ Chữ cái | ⚠ KHÁC nhau vì bộ đề xáo thứ tự | |
| ⚠ Không mâu thuẫn | ⚠ giữ nguyên cả hai khoá |
⚠ Lô này đã có sáu cặp gần trùng — Bastion, Service Endpoint, Private Endpoint, mã hoá hạ tầng, PIM, và Identity Protection.
⚠ Cấu hình PIM nên đặt: | Cấu hình | Giá trị gợi ý | |---|---| | ⚠ Thời hạn kích hoạt tối đa | ⚠ 1 đến 8 giờ | | ⚠ Bắt buộc MFA khi kích hoạt | ⚠ luôn bật | | ⚠ Bắt buộc ghi lý do | | | ⚠ Cần người duyệt cho vai trò nhạy cảm | ⚠ Global Administrator | | ⚠ Thông báo khi có kích hoạt | | | ⚠ Đánh giá quyền định kỳ | |
Từ khoá nhận diện:
"quyền tạm thời, tự thu hồi" → ⚠ PIM "quyền thường trực" → ⚠ RBAC thông thường "điều kiện đăng nhập" → ⚠ Conditional Access "phát hiện tài khoản bị lộ" → ⚠ Identity Protection
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu tài khoản giữ quyền quản trị thường trực | ⚠ Microsoft khuyến nghị dưới 5 Global Admin | | Vai trò có bị buộc MFA khi kích hoạt không | | | Có tài khoản khẩn cấp được loại trừ chưa | |
Và điều PIM thay đổi về mặt vận hành: có quyền không còn là một trạng thái mà là một hành động có ghi nhận. Mỗi lần dùng quyền quản trị đều có thời điểm, lý do, và người duyệt — thứ mà kiểm toán viên luôn hỏi tới.