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

Tìm thấy 100 câu.

Câu 1 Secure networking (20-25%)
You want to secure the communication between users and your Azure App Service application. Which security protocol should be implemented to encrypt data in transit?
  1. A HTTP
  2. B SFTP
  3. C

    SSL/TLS
  4. D UDP
Xem giải thích

Đáp án

C — SSL/TLS.

Vì sao đúng

⚠ TLS là giao thức mã hoá dữ liệu khi truyền trên web: | Đặc điểm | Nội dung | |---|---| | ⚠ Mã hoá nội dung | ⚠ kẻ nghe lén không đọc được | | ⚠ Xác thực máy chủ | ⚠ bằng chứng chỉ, chống giả mạo | | ⚠ Bảo đảm toàn vẹn | ⚠ dữ liệu không bị sửa trên đường | | ⚠ HTTPS = HTTP chạy trên TLS | |

⚠ Lưu ý về tên gọi: ⚠ "SSL" là tên cũ và mọi phiên bản SSL đều đã lỗi thời và không an toàn; ⚠ thứ dùng thực tế hôm nay là TLS 1.2 và TLS 1.3.

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

  • A (HTTP) — ⚠ KHÔNG mã hoá; dữ liệu đi ở dạng rõ.

  • B (SFTP) — ⚠ giao thức truyền TỆP có mã hoá, không dùng cho lưu lượng web của App Service.

  • D (UDP) — ⚠ giao thức vận chuyển ở tầng 4, tự nó không mã hoá gì.

Ghi nhớ

⚠ Cấu hình TLS cho App Service — việc nên làm: | Việc | Nội dung | |---|---| | ⚠ Bật "HTTPS Only" | ⚠ tự chuyển hướng mọi yêu cầu HTTP sang HTTPS | | ⚠ Đặt TLS version tối thiểu là 1.2 | ⚠ tốt hơn nữa là 1.3 | | ⚠ Dùng App Service Managed Certificate | ⚠ miễn phí, tự gia hạn | | ⚠ Hoặc chứng chỉ trong Key Vault | ⚠ cho tên miền tuỳ chỉnh | | ⚠ Bật HSTS | ⚠ buộc trình duyệt luôn dùng HTTPS |

Từ khoá nhận diện:

"mã hoá dữ liệu khi TRUYỀN" → ⚠ TLS "mã hoá dữ liệu khi LƯU" → ⚠ encryption at rest, ví dụ TDE hay SSE "chứng chỉ tự gia hạn miễn phí" → ⚠ App Service Managed Certificate "quản lý chứng chỉ tập trung" → ⚠ Key Vault

⚠ Hai loại mã hoá — đừng lẫn Loại
⚠ In transit ⚠ TLS — trên đường truyền
⚠ At rest ⚠ mã hoá khi lưu trên đĩa
⚠ Azure Storage và SQL ⚠ mã hoá at rest BẬT SẴN, không tắt được
⚠ Cần cả hai ⚠ để bảo vệ dữ liệu trọn vòng đời
⚠ End-to-end TLS là gì Nghĩa
⚠ Mã hoá cả chặng từ gateway tới backend
⚠ Khác với chỉ dừng TLS ở gateway
⚠ Cần khi dữ liệu nhạy cảm và mạng nội bộ không được coi là tin cậy
⚠ Đánh đổi ⚠ tốn CPU hơn, cấu hình phức tạp hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | "HTTPS Only" đã bật chưa | | | Phiên bản TLS tối thiểu là bao nhiêu | ⚠ 1.0 và 1.1 đã lỗi thời | | Chứng chỉ còn hạn bao lâu | ⚠ hết hạn là sự cố toàn phần |

Và sự cố có thể phòng tránh dễ nhất nhưng vẫn xảy ra thường xuyên: chứng chỉ TLS hết hạn. Dùng chứng chỉ tự gia hạn, hoặc đặt cảnh báo trước ngày hết hạn ít nhất ba mươi ngày.

Câu 2 Chọn nhiều đáp án Secure networking (20-25%)

Which of the following Azure services offers built-in Distributed Denial of Service (DDoS) protection to secure your applications? (Select three)

  1. A Azure Firewall
  2. B Azure Application Gateway
  3. C

    Azure DDoS Protection
  4. D Azure Front Door
Xem giải thích

Đáp án

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

Vì sao đúng

⚠ Ba dịch vụ này có khả năng chống DDoS gắn liền với chính chúng: | Dịch vụ | Khả năng | |---|---| | ⚠ Azure DDoS Protection | ⚠ dịch vụ chuyên trách — bảo vệ tầng 3 và 4 | | ⚠ Azure Front Door | ⚠ hấp thụ ở biên toàn cầu, kèm WAF chống tấn công tầng 7 | | ⚠ Azure Application Gateway | ⚠ kèm WAF, có luật giới hạn tần suất chống tấn công tầng 7 |

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

  • A (Azure Firewall) — ⚠ không có tính năng chống DDoS riêng; nó lọc theo luật và threat intelligence, chứ không thiết kế để hấp thụ lưu lượng tấn công quy mô lớn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ MỌI dịch vụ Azure, kể cả Azure Firewall, đều được bảo vệ bởi lớp DDoS Infrastructure Protection MIỄN PHÍ bật sẵn ở nền tảng.

Lớp Áp cho Ghi chú
⚠ DDoS Infrastructure Protection ⚠ MỌI dịch vụ Azure ⚠ miễn phí, luôn bật, bảo vệ chính nền tảng
⚠ DDoS IP Protection ⚠ từng IP công cộng được chọn ⚠ trả phí
⚠ DDoS Network Protection ⚠ toàn bộ mạng ảo ⚠ trả phí
⚠ Vì thế ⚠ hiểu theo nghĩa rộng thì Azure Firewall cũng "được bảo vệ"
⚠ Nhưng đề hỏi ⚠ dịch vụ nào CÓ khả năng chống DDoS như một tính năng của nó
⚠ Khoá ⚠ giữ nguyên B, C, D

⚠ Chống DDoS cần nhiều lớp: | Lớp | Công cụ | |---|---| | ⚠ Tầng 3–4 | ⚠ DDoS Protection | | ⚠ Tầng 7 | ⚠ WAF trên Front Door hoặc Application Gateway | | ⚠ Hấp thụ ở biên | ⚠ Front Door, CDN | | ⚠ Giới hạn tần suất | ⚠ rate limit rule của WAF | | ⚠ Bảo vệ chi phí | ⚠ trần tự co giãn, và cost protection của bậc trả phí |

Từ khoá nhận diện:

"chống lưu lượng tấn công khổng lồ" → ⚠ DDoS Protection "tấn công tầng 7, HTTP flood" → ⚠ WAF kèm rate limit "hấp thụ ở biên toàn cầu" → ⚠ Front Door "lọc theo luật và tên miền" → ⚠ Azure Firewall, không phải chống DDoS

⚠ Bậc trả phí cho thêm gì Thêm
⚠ Điều chỉnh ngưỡng theo lưu lượng thật của bạn
⚠ Báo cáo và nhật ký giảm nhẹ chi tiết
⚠ Đội ứng cứu nhanh khi bị tấn công
⚠ Bảo vệ chi phí ⚠ hoàn tín dụng cho phần co giãn do bị tấn công
⚠ Thiệt hại thật của DDoS trên đám mây Thiệt hại
⚠ Không nhất thiết là sập dịch vụ
⚠ Mà là HOÁ ĐƠN ⚠ hệ thống tự co giãn để phục vụ chính cuộc tấn công
⚠ Vì thế ⚠ đặt trần co giãn là biện pháp chống DDoS về mặt tài chính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng công khai có WAF chưa | | | Có trần số thể hiện tối đa khi co giãn không | | | Có cảnh báo khi lưu lượng tăng bất thường không | |

Và điều cần nhớ khi cân nhắc mua bậc DDoS trả phí: phần "bảo vệ chi phí" có thể tự trả tiền cho chính nó. Một cuộc tấn công vào hệ thống tự co giãn sinh ra hoá đơn còn đau hơn thời gian ngừng dịch vụ.

Câu 3 Secure compute, storage, and databases (20-25%)
To allow secure and seamless Remote Desktop Protocol (RDP) connectivity to your Azure virtual machines directly from the Azure portal without any exposure of the public IPs on your virtual machines, which service should you use?
  1. A Azure API Management
  2. B Azure Bastion
  3. C Azure Kubernetes Service (AKS)
  4. D Azure Disk Encryption (ADE)
Xem giải thích

Đáp án

B — Azure Bastion.

Vì sao đúng

⚠ Azure Bastion cho phép RDP và SSH ngay trong trình duyệt: | Đặ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 | | | ⚠ Bastion nằm trong chính VNet của bạn | ⚠ subnet tên AzureBastionSubnet | | ⚠ Truy cập từ Azure Portal hoặc client gốc | | | ⚠ Có nhật ký phiên ở bậc Premium | |

⚠ Quản trị viên  →  ⚠ HTTPS 443  →  ⚠ Azure Bastion
                                        ↓ ⚠ IP nội bộ
                                  ⚠ VM không có IP công cộng

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

  • A (API Management) — ⚠ cổng quản lý API, không liên quan tới truy cập máy ảo.

  • C (Azure Kubernetes Service) — ⚠ dịch vụ điều phối container.

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

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23129 ở lô 170 hỏi cách bảo vệ giao thức quản trị RDP và SSH (đáp án: dùng Bastion thay vì mở cổng ra Internet). ⚠ Câu này hỏi chính tên dịch vụ. Hai câu nhất quán.

⚠ Ba cách bảo vệ cổng quản trị — nên kết hợp: | Cách | Nội dung | |---|---| | ⚠ Azure Bastion | ⚠ không cần IP công cộng, truy cập qua trình duyệt | | ⚠ Just-in-Time VM Access | ⚠ của Defender for Cloud — mở cổng CÓ THỜI HẠN khi cần | | ⚠ NSG chặt | ⚠ chỉ cho phép dải IP nội bộ hoặc văn phòng |

Từ khoá nhận diện:

"RDP/SSH không mở cổng ra Internet" → ⚠ Bastion "mở cổng tạm thời có phê duyệt" → ⚠ Just-in-Time VM Access "kết nối riêng tới dịch vụ PaaS" → ⚠ Private Endpoint "mã hoá đĩa máy ảo" → ⚠ Azure Disk Encryption

⚠ Các bậc của Azure Bastion Bậc
⚠ Developer ⚠ miễn phí, chia sẻ, cho môi trường thử nghiệm
⚠ Basic ⚠ cơ bản, hai instance
⚠ Standard ⚠ co giãn, kết nối bằng client gốc, IP-based connection
⚠ Premium ⚠ ghi nhật ký phiên, private-only deployment
⚠ Điều cần chuẩn bị Điều
⚠ Subnet tên đúng AzureBastionSubnet ⚠ tối thiểu /26
⚠ Một IP công cộng cho chính Bastion ⚠ máy ảo thì không cần
⚠ NSG của subnet phải mở đúng bộ cổng bắt buộc
⚠ Với peering ⚠ một Bastion phục vụ được máy ở VNet đã peering

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 | ⚠ kiểm tra ngay | | Máy ảo còn IP công cộng nào không cần thiết không | | | Có ghi nhật ký ai đã kết nối vào máy nào không | |

Và con số đáng nhớ về việc phơi cổng quản trị: một máy ảo mới tạo với RDP mở sẽ bị bot dò trong vòng vài phút. Bastion loại bỏ hoàn toàn bề mặt tấn công đó mà không làm khó việc quản trị.

Câu 4 Chọn nhiều đáp án Secure compute, storage, and databases (20-25%)

Which of the following solutions can help enhance the security of the Azure Kubernetes Service (AKS) cluster? (Select two)

  1. A Just-in-Time VM access
  2. B Azure Disk Encryption (ADE)
  3. C

    Defender for Containers
  4. D

    Kubernetes RBAC
Xem giải thích

Đáp án

C và D — Defender for Containers và Kubernetes RBAC.

Vì sao đúng

⚠ Hai biện pháp ở hai tầng khác nhau của cụm AKS: | Biện pháp | Bảo vệ gì | |---|---| | ⚠ Defender for Containers | ⚠ quét lỗ hổng ảnh, phát hiện mối đe doạ khi chạy, đánh giá cấu hình | | ⚠ Kubernetes RBAC | ⚠ ai được làm gì TRONG cụm — namespace, pod, secret |

⚠ Defender for Containers làm gì cụ thể: | Chức năng | Nội dung | |---|---| | ⚠ Quét lỗ hổng ảnh trong ACR | ⚠ cả khi đẩy lên lẫn khi đang chạy | | ⚠ Phát hiện mối đe doạ thời gian chạy | ⚠ hành vi bất thường trong pod | | ⚠ Đánh giá cấu hình cụm | ⚠ so với chuẩn bảo mật | | ⚠ Khuyến nghị khắc phục | |

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

  • A (Just-in-Time VM access) — ⚠ dành cho máy ảo, không áp cho node của AKS theo cách hữu ích.

  • B (Azure Disk Encryption) — ⚠ mã hoá đĩa máy ảo; ⚠ với AKS, đĩa node đã được mã hoá sẵn bằng Azure Storage encryption.

Ghi nhớ

⚠ Hai lớp phân quyền của AKS — đừng lẫn: | Lớp | Kiểm soát | |---|---| | ⚠ Azure RBAC | ⚠ ai được quản lý TÀI NGUYÊN AKS — tạo, xoá, đọc cấu hình cụm | | ⚠ Kubernetes RBAC | ⚠ ai được làm gì BÊN TRONG cụm — pod, service, secret | | ⚠ Tích hợp tốt nhất | ⚠ Entra ID kèm Azure RBAC for Kubernetes Authorization |

Từ khoá nhận diện:

"quét lỗ hổng ảnh, phát hiện đe doạ trong container" → ⚠ Defender for Containers "ai được làm gì trong cụm" → ⚠ Kubernetes RBAC "ai được quản lý tài nguyên cụm" → ⚠ Azure RBAC "lưu trữ ảnh container an toàn" → ⚠ Azure Container Registry

⚠ Các biện pháp bảo mật AKS khác Biện pháp
⚠ Private cluster ⚠ API server không có endpoint công cộng
⚠ Network policy ⚠ kiểm soát lưu lượng giữa các pod
⚠ Managed identity cho pod ⚠ Workload Identity, không lưu bí mật
⚠ Azure Policy for Kubernetes ⚠ buộc pod tuân theo chuẩn
⚠ Cập nhật node định kỳ ⚠ node image upgrade
⚠ Nguyên tắc bảo mật container Nguyên tắc
⚠ Ảnh từ registry TIN CẬY của mình ⚠ không kéo thẳng từ Docker Hub công cộng
⚠ Quét lỗ hổng trước khi triển khai
⚠ Không chạy container ở quyền root
⚠ Bí mật để trong Key Vault, không trong ảnh
⚠ Giới hạn tài nguyên cho từng pod

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh container có được quét lỗ hổng không | | | API server của cụm có công khai không | ⚠ cân nhắc private cluster | | Kubernetes RBAC có tích hợp Entra ID chưa | ⚠ thay vì dùng chứng chỉ quản trị cục bộ |

Và rủi ro lớn nhất trong vận hành AKS mà nhiều đội bỏ qua: dùng chung tệp kubeconfig quản trị cục bộ. Nó bỏ qua mọi kiểm soát của Entra ID và không để lại dấu vết ai đã làm gì — tắt local account và bắt buộc đi qua Entra ID là việc nên làm sớm.

Câu 5 Secure compute, storage, and databases (20-25%)
For storing and managing container images and Helm charts securely within the Azure instance, which Azure service should you use?
  1. A Azure Kubernetes Service (AKS)
  2. B Azure Container Apps (ACAs)
  3. C Azure Container Instances (ACIs)
  4. D Azure Container Registry (ACR)
Xem giải thích

Đáp án

D — Azure Container Registry (ACR).

Vì sao đúng

⚠ ACR là kho lưu trữ riêng cho tạo tác container: | Lưu được | Nội dung | |---|---| | ⚠ Ảnh container | ⚠ Docker image, OCI image | | ⚠ Helm chart | ⚠ gói triển khai cho Kubernetes | | ⚠ Các tạo tác OCI khác | ⚠ module IoT Edge, tệp cấu hình |

⚠ Tính năng bảo mật của ACR: | Tính năng | Nội dung | |---|---| | ⚠ Xác thực bằng Entra ID | ⚠ và RBAC theo vai trò AcrPull, AcrPush | | ⚠ Quét lỗ hổng | ⚠ qua Defender for Containers | | ⚠ Content trust | ⚠ ký ảnh để xác minh nguồn gốc | | ⚠ Private Endpoint | ⚠ truy cập qua IP riêng, bậc Premium | | ⚠ Geo-replication | ⚠ nhân bản ảnh sang nhiều vùng, bậc Premium | | ⚠ Customer-managed key | ⚠ mã hoá bằng khoá của bạn |

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

  • A (Azure Kubernetes Service) — ⚠ CHẠY container, không lưu trữ ảnh.

  • B (Container Apps) và C (Container Instances) — ⚠ cũng để CHẠY container, không phải kho lưu trữ.

Ghi nhớ

⚠ Bốn dịch vụ container của Azure — phân vai: | Dịch vụ | Việc | |---|---| | ⚠ Container Registry | ⚠ LƯU ảnh | | ⚠ Container Instances | ⚠ chạy MỘT container nhanh, không điều phối | | ⚠ Container Apps | ⚠ chạy ứng dụng container serverless, có co giãn và microservice | | ⚠ Kubernetes Service | ⚠ điều phối đầy đủ, kiểm soát cao nhất |

Từ khoá nhận diện:

"lưu ảnh và Helm chart" → ⚠ ACR "chạy nhanh một container" → ⚠ Container Instances "serverless container, tự co giãn về 0" → ⚠ Container Apps "điều phối đầy đủ, nhiều node" → ⚠ AKS

⚠ Ba bậc của ACR Bậc
⚠ Basic ⚠ cho học tập và dự án nhỏ
⚠ Standard ⚠ dung lượng và thông lượng cao hơn
⚠ Premium ⚠ geo-replication, private endpoint, content trust, CMK
⚠ Thực hành tốt với ACR Thực hành
⚠ Dùng managed identity để AKS kéo ảnh ⚠ không dùng admin account
⚠ TẮT admin account ⚠ nó là một cặp user/password dùng chung
⚠ Bật quét lỗ hổng
⚠ Đặt chính sách giữ ảnh ⚠ xoá ảnh cũ để tiết kiệm dung lượng
⚠ Private endpoint cho môi trường thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Admin account của ACR đã tắt chưa | ⚠ bật là một tài khoản dùng chung không kiểm soát được | | AKS kéo ảnh bằng managed identity hay bằng secret | | | Ảnh có được quét lỗ hổng trước khi triển khai không | |

Và cấu hình mặc định đáng sửa nhất của ACR: admin account. Nó tiện khi thử nghiệm nhưng là một cặp thông tin đăng nhập dùng chung, không gắn với ai cả — quản lý bằng managed identity và RBAC là cách đúng.

Câu 6 Secure compute, storage, and databases (20-25%)

You are setting up a new Azure Storage account and need to ensure that only specific virtual networks and IP addresses can access it.

Which feature of the storage account should you configure?

  1. A

    Application Security Groups (ASGs)
  2. B

    Storage Account Key Access
  3. C

    Storage firewalls and virtual networks
  4. D Azure Blob Storage versioning
Xem giải thích

Đáp án

C — Storage firewalls and virtual networks (tường lửa và mạng ảo của tài khoản lưu trữ).

Vì sao đúng

⚠ Đây là mục cấu hình mạng của Storage Account: | Cấu hình được | Nội dung | |---|---| | ⚠ Cho phép từ mạng ảo được chọn | ⚠ qua service endpoint hoặc private endpoint | | ⚠ Cho phép từ dải IP công cộng cụ thể | | | ⚠ Chặn mọi truy cập công cộng khác | | | ⚠ Ngoại lệ cho dịch vụ Azure tin cậy | ⚠ trusted Microsoft services |

⚠ Mặc định: ⚠ "Enabled from all networks"  →  ⚠ ai có khoá cũng vào được
⚠ Nên đổi: ⚠ "Enabled from selected virtual networks and IP addresses"
⚠ Chặt nhất: ⚠ "Disabled" + ⚠ chỉ private endpoint

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

  • B (Storage Account Key Access) — ⚠ về việc CÓ cho phép xác thực bằng khoá hay không, không giới hạn được theo mạng.

  • A (Application Security Groups) — ⚠ nhóm card mạng của MÁY ẢO, không áp cho dịch vụ PaaS.

  • D (Blob versioning) — ⚠ giữ nhiều phiên bản của blob, thuộc về bảo vệ dữ liệu chứ không phải kiểm soát mạng.

Ghi nhớ

⚠ Ba lớp kiểm soát truy cập Storage — nên dùng cả ba: | Lớp | Câu hỏi nó trả lời | |---|---| | ⚠ Tường lửa và mạng | ⚠ truy cập được TỪ ĐÂU | | ⚠ Xác thực | ⚠ AI truy cập — Entra ID hoặc khoá | | ⚠ Uỷ quyền | ⚠ được làm GÌ — RBAC hoặc SAS |

Từ khoá nhận diện:

"chỉ VNet và IP nhất định" → ⚠ storage firewall "dịch vụ có IP riêng trong VNet" → ⚠ private endpoint "tắt xác thực bằng khoá" → ⚠ disable shared key access "cấp quyền tạm thời cho một tệp" → ⚠ SAS token

⚠ Thứ tự tăng dần độ an toàn Cấu hình
⚠ Mở cho mọi mạng, dùng khoá ⚠ kém nhất
⚠ Giới hạn theo IP và VNet ⚠ khá hơn
⚠ Private endpoint, tắt truy cập công cộng ⚠ tốt
⚠ Thêm: tắt shared key, chỉ Entra ID ⚠ TỐT NHẤT
⚠ Ngoại lệ "trusted Microsoft services" Nội dung
⚠ Cho phép một số dịch vụ Azure đi qua tường lửa ⚠ Backup, Site Recovery, Monitor...
⚠ Cần thiết để nhiều tính năng hoạt động
⚠ Nhưng cũng là một lỗ hổng nếu bật bừa
⚠ Kết hợp ⚠ resource instance rules để giới hạn đúng tài nguyên cụ thể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản lưu trữ có đang mở cho mọi mạng không | ⚠ mặc định là mở | | Shared key access đã tắt chưa | | | Có SAS token nào hạn quá dài không | |

Và cấu hình mặc định nguy hiểm nhất của Azure Storage: "Enabled from all networks". Nghĩa là bất kỳ ai ở bất kỳ đâu có được khoá — kể cả khoá lọt vào một kho mã nguồn — đều truy cập được ngay, và tường lửa là lớp chặn duy nhất đứng giữa.

Câu 7 Secure compute, storage, and databases (20-25%)

Your organization stores sensitive files on Azure Blob Storage. To enhance the security of this data, you're asked to implement an extra layer of encryption in addition to the default encryption provided by Azure Storage.

Which feature will you enable?

  1. A

    Infrastructure Encryption
  2. B

    Customer-Managed Key (CMK)
  3. C

    Bring Your Own Key (BYOK)
  4. D Azure Queue storage protection
Xem giải thích

Đáp án

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

Vì sao đúng

⚠ Infrastructure encryption là lớp mã hoá THỨ HAI, chồng lên lớp mặc định: | Lớp | Nội dung | |---|---| | ⚠ Lớp 1 — mặc định | ⚠ Storage Service Encryption, AES-256, LUÔN bật, không tắt được | | ⚠ Lớp 2 — infrastructure encryption | ⚠ mã hoá THÊM một lần nữa ở tầng hạ tầng |

⚠ Dữ liệu
   ↓ ⚠ mã hoá lần 1 (service-level, luôn có)
   ↓ ⚠ mã hoá lần 2 (infrastructure, tuỳ chọn)
⚠ Lưu xuống đĩa

⚠ Điều kiện quan trọng: ⚠ phải BẬT LÚC TẠO tài khoản lưu trữ; ⚠ không bật được cho tài khoản đã có.

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

  • B (Customer-Managed Key) và C (Bring Your Own Key) — ⚠ đổi AI QUẢN LÝ KHOÁ, không thêm lớp mã hoá; dữ liệu vẫn chỉ mã hoá một lần.

  • D (bảo vệ Azure Queue storage) — ⚠ không phải một tính năng có tên như vậy.

Ghi nhớ

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

Từ khoá nhận diện:

"thêm một lớp mã hoá nữa" → ⚠ infrastructure encryption "tôi muốn tự quản khoá" → ⚠ customer-managed key "khoá phải nằm trong HSM của tôi" → ⚠ Managed HSM hoặc BYOK "mã hoã khi truyền" → ⚠ TLS, khác hẳn

⚠ Customer-managed key — được gì, mất gì Điều
⚠ ĐƯỢC: kiểm soát vòng đời khoá ⚠ xoay vòng, thu hồi, kiểm toán
⚠ ĐƯỢC: thu hồi khoá là dữ liệu không đọc được nữa
⚠ MẤT: bạn chịu trách nhiệm giữ khoá
⚠ RỦI RO: xoá nhầm khoá là MẤT DỮ LIỆU VĨNH VIỄN
⚠ Bắt buộc kèm ⚠ purge protection trên Key Vault
⚠ Khi nào cần infrastructure encryption Khi nào
⚠ Quy định ngành đòi mã hoá nhiều lớp
⚠ Dữ liệu cực kỳ nhạy cảm
⚠ Chấp nhận chi phí tính toán tăng nhẹ
⚠ Nhớ ⚠ phải quyết định LÚC TẠO tài khoản

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á đó | ⚠ càng ít càng tốt |

Và rủi ro nghiêm trọng nhất khi tự quản khoá mã hoá, nghiêm trọng hơn cả việc bị lộ khoá: xoá nhầm khoá. Dữ liệu mã hoá bằng nó sẽ không bao giờ đọc lại được — nên purge protection là bắt buộc, không phải tuỳ chọn.

Câu 8 Chọn nhiều đáp án Secure compute, storage, and databases (20-25%)

To ensure data resiliency and protection against accidental deletion in Azure Blob Storage, which of the following features can be enabled? (Select four)

  1. A Soft delete
  2. B Immutable storage
  3. C Blob versioning
  4. D

    Customer-Managed Key (CMK)
  5. E

    Locally Redundant Storage (LRS)
  6. F

    Immutable Blobs
Xem giải thích

Đáp án

A, C, E và F.

  • A — Soft delete (xoá mềm).
  • C — Blob versioning (phiên bản blob).
  • E — Locally Redundant Storage (LRS).
  • F — Immutable Blobs (blob bất biến).

Vì sao đúng

⚠ Bốn tính năng, hai nhóm mục đích: | Nhóm | Tính năng | Bảo vệ khỏi | |---|---|---| | ⚠ Chống xoá nhầm | ⚠ soft delete | ⚠ xoá nhầm — khôi phục trong thời gian giữ | | ⚠ Chống ghi đè nhầm | ⚠ blob versioning | ⚠ giữ mọi phiên bản cũ tự động | | ⚠ Chống sửa và xoá có chủ đích | ⚠ immutable blobs | ⚠ WORM — ghi một lần, đọc nhiều lần | | ⚠ Chống hỏng phần cứng | ⚠ LRS | ⚠ giữ ba bản sao trong một trung tâm dữ liệu |

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

  • D (Customer-Managed Key) — ⚠ về MÃ HOÁ và quản lý khoá, không liên quan tới chống mất dữ liệu; ⚠ thậm chí làm tăng rủi ro nếu xoá nhầm khoá.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án B — "Immutable storage" và phương án F — "Immutable Blobs" ⚠ mô tả gần như CÙNG MỘT tính năng.

Phương án Nội dung Trong khoá
⚠ B — Immutable storage ⚠ tên chung của tính năng bất biến ⚠ KHÔNG
⚠ F — Immutable Blobs ⚠ cùng tính năng đó, gọi theo đối tượng ⚠ CÓ
⚠ Vì sao chọn F ⚠ đề hỏi về Blob Storage, F bám sát ngữ cảnh hơn
⚠ Ghi chú ⚠ hai phương án này lẽ ra không nên cùng xuất hiện
⚠ Khoá ⚠ giữ nguyên A, C, E, F

⚠ Bảo vệ dữ liệu Blob theo lớp: | Lớp | Tính năng | |---|---| | ⚠ Chống xoá nhầm blob | ⚠ blob soft delete | | ⚠ Chống xoá nhầm cả container | ⚠ container soft delete | | ⚠ Chống ghi đè | ⚠ versioning | | ⚠ Chống sửa có chủ đích | ⚠ immutability policy — time-based hoặc legal hold | | ⚠ Chống hỏng phần cứng | ⚠ LRS, ZRS, GRS, GZRS | | ⚠ Chống thảm hoạ vùng | ⚠ GRS hoặc GZRS | | ⚠ Chống ransomware | ⚠ immutability là biện pháp mạnh nhất |

Từ khoá nhận diện:

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

⚠ Hai loại immutability policy Loại
⚠ Time-based retention ⚠ khoá trong N ngày, không sửa không xoá được
⚠ Legal hold ⚠ khoá vô thời hạn cho tới khi gỡ thẻ
⚠ Khi policy đã LOCKED ⚠ kể cả chủ tài khoản cũng không gỡ được trước hạn
⚠ Vì thế ⚠ đây là biện pháp mạnh nhất chống ransomware và chống nội gián

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 là quá ngắn | | Dữ liệu tuân thủ có cần immutability không | |

Và điều nên cân nhắc khi đặt thời gian giữ của soft delete: bao lâu thì bạn phát hiện ra một vụ xoá nhầm? Nếu câu trả lời là "có khi cả tháng", thì thời gian giữ bảy ngày mặc định không cứu được gì.

Câu 9 Secure compute, storage, and databases (20-25%)

What Azure database does not support Microsoft Entra ID authentication for database logins?

  1. A Azure SQL Database
  2. B

    Azure Database for MariaDB
  3. C

    Azure SQL Managed Instance
  4. D

    SQL Server on Windows Azure VMs
  5. E

    Azure Cosmos DB for PostgreSQL
Xem giải thích

Đáp án

B — Azure Database for MariaDB.

Vì sao đúng

⚠ Đối chiếu khả năng xác thực bằng Microsoft Entra ID: | Dịch vụ | Hỗ trợ Entra ID | |---|---| | ⚠ Azure SQL Database | ⚠ CÓ | | ⚠ Azure SQL Managed Instance | ⚠ CÓ | | ⚠ SQL Server trên VM Azure | ⚠ CÓ — qua Entra ID kèm cấu hình phù hợp | | ⚠ Azure Cosmos DB for PostgreSQL | ⚠ CÓ | | ⚠ Azure Database for MariaDB | ⚠ KHÔNG |

⚠ MariaDB chỉ hỗ trợ xác thực gốc của MySQL/MariaDB — tên đăng nhập và mật khẩu, không tích hợp định danh đám mây.

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

  • A, C, D, E — ⚠ đều hỗ trợ xác thực bằng Entra ID.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ Azure Database for MariaDB đã NGỪNG HOÀN TOÀN từ tháng 9/2025. ⚠ Microsoft khuyến nghị chuyển sang Azure Database for MySQL — Flexible Server, ⚠ dịch vụ này CÓ hỗ trợ Microsoft Entra ID.

Dịch vụ Tình trạng Entra ID
⚠ Azure Database for MariaDB ⚠ ĐÃ NGỪNG 9/2025 ⚠ không
⚠ Azure Database for MySQL — Flexible Server ⚠ đang dùng ⚠ CÓ
⚠ Khoá đáp án B ⚠ vẫn ĐÚNG và giữ nguyên — đúng với thời điểm ra đề
⚠ Trong lô trước đã ghi nhận ⚠ câu #19637 cũng nhắc MariaDB ngừng dịch vụ
⚠ Bài học ⚠ đề thi có độ trễ so với vòng đời dịch vụ thật

⚠ Vì sao nên dùng Entra ID cho CSDL: | Lợi ích | Nội dung | |---|---| | ⚠ Không lưu mật khẩu trong chuỗi kết nối | ⚠ dùng managed identity | | ⚠ MFA và Conditional Access áp được | | | ⚠ Tắt một tài khoản là chặn mọi CSDL | | | ⚠ Nhật ký đăng nhập tập trung | | | ⚠ Quản lý quyền theo NHÓM | |

Từ khoá nhận diện:

"không lưu mật khẩu nào" → ⚠ managed identity kèm Entra ID "MariaDB" → ⚠ đã ngừng, chuyển sang MySQL Flexible Server "mã hoá khi lưu cho SQL" → ⚠ Transparent Data Encryption "che dữ liệu nhạy cảm khi truy vấn" → ⚠ Dynamic Data Masking

⚠ Vòng đời các dịch vụ CSDL của Azure Dịch vụ
⚠ MariaDB ⚠ ngừng 9/2025
⚠ MySQL Single Server ⚠ ngừng 9/2024, chuyển sang Flexible Server
⚠ PostgreSQL Single Server ⚠ cũng đã ngừng, chuyển sang Flexible Server
⚠ Xu hướng chung ⚠ Microsoft hợp nhất về mô hình Flexible Server

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn CSDL nào chạy trên dịch vụ đã ngừng không | ⚠ kiểm tra Service Health advisories | | CSDL có dùng Entra ID để xác thực không | | | Chuỗi kết nối có chứa mật khẩu dạng rõ không | ⚠ nên chuyển sang managed identity |

Và cách bảo vệ CSDL tốt nhất mà không cần thêm công cụ nào: bỏ hẳn mật khẩu khỏi chuỗi kết nối. Với managed identity và Entra ID, không còn bí mật nào để lộ, và việc thu hồi quyền chỉ là tắt một tài khoản.

Câu 10 Chọn nhiều đáp án Secure compute, storage, and databases (20-25%)

You have been assigned to enhance the security and compliance of your organization's Azure SQL Database.

Which of the following measures can you adopt to encrypt data and audit database operations? (Select four)

  1. A

    Transparent Data Encryption (Encryption-at-rest)
  2. B

    Transport Layer Security (Encryption-in-transit)
  3. C

    Soft Delete
  4. D

    Auditing
  5. E

    Advanced Threat Protection
Xem giải thích

Đáp án

A, B, D và E.

  • A — Transparent Data Encryption (mã hoá khi lưu).
  • B — Transport Layer Security (mã hoá khi truyền).
  • D — Auditing (kiểm toán).
  • E — Advanced Threat Protection (bảo vệ trước mối đe doạ nâng cao).

Vì sao đúng

⚠ Bốn biện pháp phủ đúng hai yêu cầu của đề — mã hoá và kiểm toán: | Biện pháp | Vai trò | |---|---| | ⚠ TDE | ⚠ mã hoá tệp dữ liệu, tệp nhật ký, và bản sao lưu — BẬT SẴN | | ⚠ TLS | ⚠ mã hoá kết nối giữa ứng dụng và CSDL | | ⚠ Auditing | ⚠ ghi lại mọi thao tác trên CSDL, gửi sang Log Analytics hoặc Storage | | ⚠ Advanced Threat Protection | ⚠ phát hiện SQL injection, đăng nhập bất thường, rò rỉ dữ liệu |

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

  • C (Soft Delete) — ⚠ là tính năng của Azure STORAGE và Key Vault, không phải của Azure SQL Database; ⚠ với SQL, cơ chế tương ứng là point-in-time restore và long-term retention.

Ghi nhớ

⚠ Bộ bảo mật đầy đủ của Azure SQL Database: | Lớp | Biện pháp | |---|---| | ⚠ Mạng | ⚠ firewall, Private Endpoint, tắt truy cập công cộng | | ⚠ Xác thực | ⚠ Entra ID, managed identity | | ⚠ Uỷ quyền | ⚠ quyền tối thiểu, row-level security | | ⚠ Mã hoá khi lưu | ⚠ TDE, bật sẵn | | ⚠ Mã hoá khi truyền | ⚠ TLS bắt buộc | | ⚠ Mã hoá khi DÙNG | ⚠ Always Encrypted — kể cả DBA cũng không đọc được | | ⚠ Che dữ liệu | ⚠ Dynamic Data Masking | | ⚠ Kiểm toán | ⚠ Auditing | | ⚠ Phát hiện đe doạ | ⚠ Defender for SQL |

Từ khoá nhận diện:

"mã hoá tệp dữ liệu khi lưu" → ⚠ TDE "kể cả quản trị viên CSDL cũng không đọc được" → ⚠ Always Encrypted "che số thẻ khi hiển thị" → ⚠ Dynamic Data Masking "ghi lại ai đã truy vấn gì" → ⚠ Auditing

⚠ Ba mức mã hoá — phân biệt Mức
⚠ At rest — TDE ⚠ bảo vệ khi đĩa bị đánh cắp; DBA vẫn đọc được dữ liệu
⚠ In transit — TLS ⚠ bảo vệ trên đường truyền
⚠ In use — Always Encrypted ⚠ mã hoá ngay ở phía CLIENT, máy chủ không có khoá
⚠ Always Encrypted ⚠ mạnh nhất, nhưng hạn chế khả năng truy vấn
⚠ Auditing — điều cần cấu hình Điều
⚠ Chọn đích: Log Analytics, Storage, hay Event Hub
⚠ Đặt thời gian giữ đủ dài cho yêu cầu tuân thủ
⚠ Bật ở cấp SERVER để áp cho mọi CSDL
⚠ Có người thật sự xem nhật ký ⚠ kiểm toán không ai đọc là vô nghĩa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Auditing đã bật ở cấp server chưa | | | Nhật ký giữ đủ lâu theo yêu cầu tuân thủ chưa | | | Defender for SQL có bật không | ⚠ phát hiện SQL injection tự động |

Và tính năng bảo mật SQL đáng bật nhất mà nhiều đội bỏ qua: Microsoft Defender for SQL. Nó phát hiện SQL injection và mẫu truy cập bất thường ngay ở tầng CSDL — lớp cuối cùng, khi mọi lớp phía trước đã bị vượt qua.