Ngân hàng đề — Microsoft Azure Data Fundamentals

Đáp án

C — Interactive Reports (báo cáo tương tác).

Vì sao đúng

⚠ Ba yêu cầu của đề đều là đặc trưng của báo cáo tương tác: | Yêu cầu | Interactive Report | |---|---| | ⚠ Người dùng tự đổi bộ lọc | ⚠ slicer và filter pane | | ⚠ Đổi cột để sắp xếp | ⚠ bấm vào tiêu đề cột | | ⚠ Drill-through sang báo cáo khác | ⚠ có sẵn |

⚠ Interactive report
   ⚠ Nhiều trang
   ⚠ Trực quan lọc chéo lẫn nhau
   ⚠ Drill down và drill through
   ⚠ Xem trên desktop và web
        ↓
⚠ Người dùng KHÁM PHÁ dữ liệu

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

• B (Paginated Reports) — ⚠ bẫy đáng chú ý: ⚠ chúng dành cho ⚠ báo cáo IN ẤN cố định — ⚠ hoá đơn, bảng lương, báo cáo nhiều trang cần chuẩn từng pixel; ⚠ ⚠ không tương tác như đề yêu cầu.

• A (Dashboard) — ⚠ chỉ MỘT trang, ⚠ ghim các ô từ nhiều báo cáo, ⚠ ⚠ không có drill-through và lọc như báo cáo; ⚠ chỉ có trên dịch vụ Power BI, không có trong Desktop.

• D (PDF Reports) — ⚠ không phải loại báo cáo của Power BI; ⚠ PDF là ⚠ định dạng XUẤT, hoàn toàn tĩnh.

Ghi nhớ

⚠ Ba loại nội dung Power BI — bảng phân biệt: | Loại | Đặc điểm | |---|---| | ⚠ Interactive report | ⚠ nhiều trang, tương tác, drill-through | | ⚠ Dashboard | ⚠ một trang, ghim ô từ nhiều báo cáo, chỉ trên dịch vụ | | ⚠ Paginated report | ⚠ cố định để IN, nhiều trang, chuẩn từng pixel |

Từ khoá nhận diện:

"lọc, sắp xếp, drill-through, khám phá" → ⚠ Interactive report "in ra, xuất PDF nhiều trang, hoá đơn" → ⚠ Paginated report "tổng quan một màn hình, ghim từ nhiều nguồn" → ⚠ Dashboard "cảnh báo khi vượt ngưỡng" → ⚠ Dashboard tile alert

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng cần khám phá hay cần in ra | | | Cần drill-down hay drill-through | | | Dữ liệu có cần thời gian thực không | ⚠ quyết định Import hay DirectQuery |

Và phân biệt hay bị hỏi nhất trong nhóm câu Power BI: dashboard là một màn hình tổng quan, báo cáo là nơi để khám phá. Dashboard trả lời "có ổn không", báo cáo trả lời "vì sao lại thế".

Đáp án

A — Dynamic Data Masking (che dữ liệu động).

Vì sao đúng

⚠ Dấu hiệu nhận biết rõ ràng: dữ liệu bị che MỘT PHẦN trong kết quả truy vấn:

⚠ Dữ liệu THẬT trong bảng
   ⚠ 090-123-8866

⚠ Người dùng thường SELECT
   ⚠ XXX-XXX-8866
        ↓
⚠ Dữ liệu KHÔNG đổi trên đĩa
⚠ Chỉ che lúc TRẢ KẾT QUẢ

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

• D (Always Encrypted) — ⚠ mã hoá ở phía CLIENT: ⚠ dữ liệu trong CSDL là ⚠ chuỗi mã hoá không đọc được, ⚠ không phải chuỗi X che một phần.

• C (Row-level security) — ⚠ lọc theo DÒNG: ⚠ người dùng không thấy dòng đó, ⚠ chứ không phải thấy dòng với cột bị che.

• B (Azure Data Encryption) — ⚠ thường ám chỉ TDE, ⚠ mã hoá dữ liệu ⚠ khi lưu trữ; ⚠ hoàn toàn trong suốt với truy vấn.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ dữ liệu SQL — phân biệt bằng NƠI tác động: | Cơ chế | Tác động ở đâu | |---|---| | ⚠ TDE | ⚠ tệp trên đĩa — chống lấy cắp file | | ⚠ Always Encrypted | ⚠ client mã hoá, DBA cũng không đọc được | | ⚠ Dynamic Data Masking | ⚠ kết quả trả về — che một phần | | ⚠ Row-level security | ⚠ lọc bớt DÒNG |

Từ khoá nhận diện:

"XXX-XXX-8866, che một phần" → ⚠ Dynamic Data Masking "DBA cũng không được đọc" → ⚠ Always Encrypted "chỉ thấy dữ liệu chi nhánh của mình" → ⚠ Row-level security "chống lấy cắp file .mdf và bản sao lưu" → ⚠ TDE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần che cột hay ẩn dòng | | | Người có quyền truy vấn có được phép suy ra không | | | DBA có được phép đọc dữ liệu này không | ⚠ nếu không thì cần Always Encrypted |

Và hiểu lầm nguy hiểm nhất về Dynamic Data Masking, khiến nó bị dùng sai chỗ: nó là lớp giảm rủi ro vô ý, không phải hàng rào bảo mật. Một người có quyền chạy truy vấn tuỳ ý vẫn có thể dò ra giá trị thật bằng các mệnh đề lọc khéo léo.

Đáp án

B — Data Manipulation Language (DML).

Vì sao đúng

⚠ DML là nhóm câu lệnh làm việc với DỮ LIỆU bên trong bảng: | Nhóm | Câu lệnh | Tác động lên | |---|---|---| | ⚠ DDL | ⚠ CREATE, ALTER, DROP, TRUNCATE | ⚠ CẤU TRÚC | | ⚠ DML | ⚠ SELECT, INSERT, UPDATE, DELETE | ⚠ DỮ LIỆU | | ⚠ DCL | ⚠ GRANT, REVOKE, DENY | ⚠ QUYỀN | | ⚠ TCL | ⚠ COMMIT, ROLLBACK | ⚠ GIAO DỊCH |

⚠ CREATE TABLE  → ⚠ DDL: tạo cái BÌNH
⚠ INSERT / SELECT → ⚠ DML: đổ nước vào và múc ra
⚠ GRANT        → ⚠ DCL: ai được chạm vào bình

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

• A (DDL) — ⚠ định nghĩa CẤU TRÚC: ⚠ tạo bảng, thêm cột, xoá bảng; ⚠ SELECT không đụng gì tới cấu trúc.

Ghi nhớ

⚠ Lưu ý về cách phân loại SELECT: ⚠ một số tài liệu tách SELECT thành nhóm riêng gọi là ⚠ DQL (Data Query Language), ⚠ nhưng ⚠ chuẩn ANSI và tài liệu Microsoft xếp SELECT vào DML — ⚠ và đề thi theo cách này.

⚠ Bốn nhóm câu lệnh SQL — bảng phải thuộc: | Nhóm | Đặc điểm | Rollback được không | |---|---|---| | ⚠ DDL | ⚠ cấu trúc | ⚠ TRUNCATE thì được, DROP tuỳ hệ | | ⚠ DML | ⚠ dữ liệu | ⚠ CÓ, trong giao dịch | | ⚠ DCL | ⚠ quyền | | | ⚠ TCL | ⚠ giao dịch | |

Từ khoá nhận diện:

"SELECT, INSERT, UPDATE, DELETE" → ⚠ DML "CREATE, ALTER, DROP" → ⚠ DDL "GRANT, REVOKE" → ⚠ DCL "COMMIT, ROLLBACK" → ⚠ TCL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu lệnh này đụng cấu trúc hay dữ liệu | | | Có nằm trong giao dịch không | | | WHERE hay HAVING mới đúng chỗ lọc | |

Và điều giải thích được rất nhiều lỗi cú pháp SQL của người mới, đáng nhớ hơn cả việc phân nhóm câu lệnh: SELECT được xử lý gần CUỐI cùng. Đó là lý do bí danh đặt trong SELECT không dùng được ở mệnh đề WHERE.

Đáp án

C — Always Encrypted.

Vì sao đúng

⚠ Từ khoá quyết định: "không bao giờ ở trạng thái GIẢI MÃ bên ngoài máy CLIENT":

⚠ Máy client
   ⚠ Driver mã hoá TRƯỚC khi gửi
        ↓ ⚠ đường truyền: đã mã hoá
⚠ SQL Server
   ⚠ Lưu chuỗi mã hoá
   ⚠ KHÔNG có khoá để giải mã
        ↓
⚠ DBA, quản trị viên đám mây
   ⚠ đều KHÔNG đọc được

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

• D (Dynamic Data Masking) — ⚠ chỉ che khi HIỂN THỊ: ⚠ dữ liệu trong bảng vẫn nguyên bản rõ.

• B (Row-level security) — ⚠ lọc DÒNG, không mã hoá gì.

• A (Azure Threat Detection) — ⚠ phát hiện hành vi bất thường, không mã hoá.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng bộ phương án với #19492 trong cùng lô nhưng ⚠ hỏi khác nên khoá khác.

⚠ Bốn cơ chế bảo vệ — bảng đầy đủ: | Cơ chế | Bảo vệ khỏi ai | |---|---| | ⚠ TDE | ⚠ người lấy được FILE dữ liệu hoặc bản sao lưu | | ⚠ TLS | ⚠ người nghe lén đường truyền | | ⚠ Always Encrypted | ⚠ chính DBA và quản trị viên đám mây | | ⚠ Data Masking | ⚠ lộ dữ liệu vô ý cho người dùng nội bộ | | ⚠ RLS | ⚠ người dùng xem dòng không thuộc về mình |

Từ khoá nhận diện:

"DBA cũng không đọc được" → ⚠ Always Encrypted "che một phần khi hiển thị" → ⚠ Data Masking "mã hoá file trên đĩa" → ⚠ TDE "chỉ thấy dòng của mình" → ⚠ RLS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai là người bạn muốn ngăn không cho đọc | ⚠ quyết định cơ chế | | Cột đó có cần truy vấn phức tạp không | ⚠ ảnh hưởng Always Encrypted | | Khoá chủ được lưu ở đâu và ai giữ | |

Và câu hỏi định hình toàn bộ lựa chọn bảo vệ dữ liệu, nên đặt trước khi bàn tới công nghệ: bạn đang muốn ngăn ai đọc dữ liệu này? Kẻ trộm file, người nghe lén đường truyền, và chính quản trị viên của bạn cần ba cơ chế hoàn toàn khác nhau.

Đáp án

C — Bật thuộc tính "Secure transfer required" cho storage account.

Vì sao đúng

⚠ Cờ này ép mọi kết nối phải dùng HTTPS:

⚠ Tắt: chấp nhận cả HTTP và HTTPS
        ↓ ⚠ dữ liệu có thể đi trên đường không mã hoá

⚠ Bật: từ chối mọi kết nối HTTP
        ↓
⚠ Mọi dữ liệu VÀO và RA đều được mã hoá đường truyền

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

• D (tạo lại khoá truy cập chính) — ⚠ là việc LUÂN CHUYỂN khoá, ⚠ tốt cho vệ sinh bảo mật nhưng ⚠ không mã hoá đường truyền.

• A (Dynamic Data Masking) và B (Always Encrypted) — ⚠ là tính năng của SQL Database, ⚠ không áp dụng cho Storage Account.

Ghi nhớ

⚠ Bảo vệ Storage Account — các lớp: | Lớp | Nội dung | |---|---| | ⚠ Secure transfer required | ⚠ ép HTTPS — đề này | | ⚠ Mã hoá khi lưu | ⚠ BẬT sẵn, không tắt được | | ⚠ Phiên bản TLS tối thiểu | ⚠ nên đặt 1.2 trở lên | | ⚠ Tường lửa và mạng ảo | ⚠ giới hạn IP và subnet | | ⚠ Private endpoint | ⚠ truy cập qua IP riêng, không qua Internet | | ⚠ Tắt truy cập bằng KHOÁ | ⚠ buộc dùng Entra ID — mạnh nhất | | ⚠ Chặn truy cập ẩn danh vào blob | |

Từ khoá nhận diện:

"mã hoá dữ liệu đi và đến" → ⚠ secure transfer / HTTPS "chỉ cho một mạng ảo truy cập" → ⚠ private endpoint hoặc service endpoint "cấp quyền tạm thời có hạn" → ⚠ SAS token "không dùng khoá nữa" → ⚠ xác thực bằng Entra ID và RBAC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Secure transfer đã bật chưa | | | Còn dùng khoá tài khoản ở đâu không | | | SAS đang phát hành có hạn bao lâu | |

Và thay đổi cấu hình đơn lẻ có tác dụng bảo mật lớn nhất trên một storage account, thường bị bỏ qua vì sợ ảnh hưởng ứng dụng cũ: tắt hẳn truy cập bằng khoá tài khoản. Sau đó mọi truy cập đều có danh tính, có nhật ký và thu hồi được từng cái một.

Đáp án

D — Cosmos DB Table API, Azure Cache for Redis và Table Storage.

Vì sao đúng

⚠ Cả ba đều là kho KHOÁ-GIÁ TRỊ phi quan hệ: | Dịch vụ | Đặc điểm | |---|---| | ⚠ Table Storage | ⚠ khoá-giá trị rẻ, PartitionKey + RowKey | | ⚠ Cosmos DB Table API | ⚠ cùng mô hình, thêm toàn cầu và SLA | | ⚠ Azure Cache for Redis | ⚠ khoá-giá trị TRONG BỘ NHỚ, cực nhanh |

⚠ Khoá  →  Giá trị
⚠ "user:1024" → {tên, email, hạng}
        ↓
⚠ Tra cứu theo KHOÁ: cực nhanh
⚠ Truy vấn theo trường khác: kém hoặc không có

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

• A (Azure SQL Database, SQL trên VM, Managed Instance) — ⚠ đều là QUAN HỆ.

• C (MySQL, PostgreSQL, MariaDB) — ⚠ cũng đều QUAN HỆ.

• B (chỉ Cosmos DB) — ⚠ quá chung: ⚠ Cosmos DB có ⚠ nhiều API — ⚠ tài liệu, đồ thị, cột rộng; ⚠ chỉ Table API mới là khoá-giá trị.

Ghi nhớ

⚠ Năm mô hình dữ liệu phi quan hệ — bảng phải thuộc: | Mô hình | Dịch vụ Azure | |---|---| | ⚠ Khoá-giá trị | ⚠ Table Storage, Redis, Cosmos Table API | | ⚠ Tài liệu | ⚠ Cosmos DB NoSQL, MongoDB API | | ⚠ Cột rộng | ⚠ Cosmos DB Cassandra API | | ⚠ Đồ thị | ⚠ Cosmos DB Gremlin API | | ⚠ Đối tượng | ⚠ Blob Storage |

Từ khoá nhận diện:

"khoá-giá trị, tra theo khoá" → ⚠ Table Storage, Redis "cache, tăng tốc, trong bộ nhớ" → ⚠ Redis "JSON, truy vấn theo nhiều trường" → ⚠ Cosmos NoSQL "MySQL, PostgreSQL" → ⚠ quan hệ, KHÔNG phải NoSQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn chính có dùng khoá không | ⚠ quyết định mô hình khoá-giá trị có hợp không | | Dữ liệu có được phép mất không | ⚠ quyết định Redis có phù hợp không | | Có cần toàn cầu và SLA không | ⚠ Table Storage hay Cosmos |

Và giới hạn cần chấp nhận khi chọn kho khoá-giá trị, thường lộ ra khi yêu cầu nghiệp vụ mở rộng: truy vấn không theo khoá sẽ rất chậm. Nếu bạn đã bắt đầu muốn lọc theo ba bốn trường khác nhau, mô hình tài liệu mới là chỗ đúng.

Đáp án

D — Dữ liệu BÁN CẤU TRÚC (semi-structured).

Vì sao đúng

⚠ Dấu hiệu quyết định: KHÔNG phải bản ghi nào cũng có đủ mọi trường:

⚠ Nhân viên A
   ⚠ {ho, ten, tenDem, email}
⚠ Nhân viên B
   ⚠ {ho, ten, email, soDienThoaiPhu}
        ↓
⚠ Có cấu trúc rõ ràng
⚠ Nhưng KHÔNG cố định giữa các bản ghi
        ↓
⚠ BÁN CẤU TRÚC

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

• C (có cấu trúc) — ⚠ SAI: ⚠ dữ liệu có cấu trúc đòi ⚠ mọi bản ghi cùng bộ cột; ⚠ với dữ liệu này sẽ có rất nhiều ô NULL.

• B (phi cấu trúc) — ⚠ SAI: ⚠ dữ liệu này ⚠ có trường có tên rõ ràng.

• A (tệp CSV) — ⚠ là ĐỊNH DẠNG chứ không phải LOẠI dữ liệu; ⚠ CSV còn có schema cứng nên không phù hợp với trường thiếu.

Ghi nhớ

⚠ Ba loại dữ liệu và kho phù hợp: | Loại | Ví dụ | Kho Azure | |---|---|---| | ⚠ Có cấu trúc | ⚠ bảng kế toán, danh mục | ⚠ Azure SQL | | ⚠ Bán cấu trúc | ⚠ JSON, XML, log | ⚠ Cosmos DB | | ⚠ Phi cấu trúc | ⚠ ảnh, video, PDF | ⚠ Blob Storage |

Từ khoá nhận diện:

"không phải bản ghi nào cũng có đủ trường" → ⚠ bán cấu trúc "schema thay đổi theo thời gian" → ⚠ bán cấu trúc "mọi dòng cùng cột, ràng buộc chặt" → ⚠ có cấu trúc "ảnh, video, tài liệu tự do" → ⚠ phi cấu trúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi bản ghi có cùng bộ trường không | | | Schema có thay đổi thường xuyên không | | | Cần ràng buộc chặt hay cần linh hoạt | |

Và đánh đổi thật sự khi chọn kho dữ liệu linh hoạt, không nằm ở công nghệ mà ở trách nhiệm: việc kiểm tra tính đúng đắn của dữ liệu chuyển từ cơ sở dữ liệu sang ứng dụng. Linh hoạt lúc ghi đổi lấy cẩn thận lúc đọc.

Đáp án

C — Chi phí mỗi thao tác đọc-ghi chỉ khoảng 25–33% so với gói Hot, nhưng giá lưu trữ mỗi GB đắt gấp đôi; tiết kiệm cho dữ liệu được truy cập nhiều.

Vì sao đúng

⚠ Đây là bài toán đánh đổi giữa giá LƯU và giá THAO TÁC: | Gói Azure Files | Giá lưu | Giá thao tác | |---|---|---| | ⚠ Premium (SSD) | ⚠ cao nhất | ⚠ không tính riêng | | ⚠ Transaction Optimized | ⚠ cao hơn Hot | ⚠ THẤP NHẤT trong nhóm HDD | | ⚠ Hot | ⚠ trung bình | ⚠ trung bình | | ⚠ Cool | ⚠ thấp nhất | ⚠ cao nhất |

⚠ Truy cập NHIỀU, dữ liệu ít
        ↓
⚠ Transaction Optimized rẻ hơn

⚠ Dữ liệu NHIỀU, ít truy cập
        ↓
⚠ Cool rẻ hơn

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

• A (hiệu năng bằng Premium với nửa giá) — ⚠ SAI: ⚠ Premium chạy trên SSD, ⚠ độ trễ thấp hơn hẳn; ⚠ Transaction Optimized vẫn thuộc nhóm HDD.

• B (giá bằng Hot nhưng nhanh hơn với tệp nhỏ) — ⚠ SAI: ⚠ giá lưu trữ ⚠ cao hơn Hot.

• D (lưu tệp trong bộ nhớ) — ⚠ SAI hoàn toàn: ⚠ đó là mô tả của Redis.

Ghi nhớ

⚠ Nguyên tắc chung của mọi tầng lưu trữ Azure: | Nguyên tắc | Nội dung | |---|---| | ⚠ Lưu càng rẻ → truy cập càng đắt | | | ⚠ Lưu càng đắt → truy cập càng rẻ | | | ⚠ Chọn theo | ⚠ TỈ LỆ giữa dung lượng và số lần truy cập | | ⚠ Áp dụng cho | ⚠ cả Blob (Hot/Cool/Cold/Archive) lẫn Files |

Từ khoá nhận diện:

"truy cập rất nhiều lần" → ⚠ tầng nóng, Transaction Optimized "lưu trữ lâu dài, hiếm đọc" → ⚠ Cool hoặc Archive "cần độ trễ thấp, IOPS cao" → ⚠ Premium SSD "khôi phục mất hàng giờ" → ⚠ Archive

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu này được đọc bao nhiêu lần mỗi tháng | | | Đã tính cả phí thao tác chưa | ⚠ không chỉ phí lưu | | Có bật lifecycle management chưa | |

Và cách tính chi phí lưu trữ đám mây dẫn tới quyết định sai nhiều nhất: chỉ so sánh giá mỗi GB. Với dữ liệu được đọc liên tục, phí thao tác hoàn toàn có thể lớn hơn phí lưu trữ và đảo ngược mọi phép so sánh.

Đáp án

B — Có, kết nối sẽ thành công.

Vì sao đúng

⚠ Azure SQL xét tường lửa theo THỨ TỰ, và luật cấp database được xét TRƯỚC:

⚠ Kết nối từ 123.123.124.25 tới DB1
        ↓
⚠ 1. Kiểm luật cấp DATABASE của DB1
   ⚠ dải 123.123.123.0 - 123.123.124.255
   ⚠ → 123.123.124.25 NẰM TRONG
        ↓
⚠ CHO PHÉP ngay, KHÔNG cần xét tiếp
        ↓
⚠ Kết nối thành công

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

• A (Không) — ⚠ hiểu nhầm phổ biến: ⚠ nghĩ rằng tường lửa server là ⚠ hàng rào ngoài cùng phải qua trước; ⚠ thực tế Azure SQL ⚠ kiểm luật database TRƯỚC.

Ghi nhớ

⚠ Tường lửa Azure SQL — nguyên tắc phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Luật database được xét TRƯỚC luật server | | | ⚠ Khớp bất kỳ luật nào là CHO PHÉP | | | ⚠ Không khớp luật nào là TỪ CHỐI | | | ⚠ Luật database KHÔNG bị luật server giới hạn | ⚠ điểm mấu chốt của câu này | | ⚠ Luật database chỉ áp cho ĐÚNG database đó | |

Từ khoá nhận diện:

"luật cấp database rộng hơn" → ⚠ vẫn cho phép, vì được xét trước "chỉ áp cho một database" → ⚠ luật cấp database "áp cho mọi database trên server" → ⚠ luật cấp server "chặn hoàn toàn truy cập công cộng" → ⚠ private endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang có luật cấp server nào quá rộng không | | | "Allow Azure services" có đang bật không | | | Có thể chuyển sang private endpoint không | |

Và cài đặt có tên gây hiểu lầm nhất trên Azure SQL, đáng kiểm tra ngay trên mọi máy chủ đang chạy: "Allow Azure services to access this server". Nó không giới hạn trong tài nguyên của bạn — nó mở cửa cho toàn bộ Azure.

Đáp án

A — Trách nhiệm CHUNG giữa Azure và khách hàng.

Vì sao đúng

⚠ Trong mô hình chia sẻ trách nhiệm, bảo mật dữ liệu là hạng mục HAI BÊN cùng gánh: | Bên | Phần việc | |---|---| | ⚠ Microsoft | ⚠ mã hoá khi lưu, bảo vệ trung tâm dữ liệu, vá hạ tầng | | ⚠ Khách hàng | ⚠ phân loại dữ liệu, phân quyền, quản lý khoá, cấu hình đúng |

⚠ Microsoft cung cấp CÔNG CỤ
   ⚠ mã hoá, tường lửa, RBAC, nhật ký
        ↓
⚠ Khách hàng phải DÙNG chúng đúng cách
        ↓
⚠ Cấu hình sai → dữ liệu lộ
⚠ Đó là phần của khách hàng

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

• D (hoàn toàn của Microsoft) — ⚠ hiểu lầm nguy hiểm nhất: ⚠ Microsoft ⚠ không chịu trách nhiệm nếu bạn để container blob ở chế độ công khai.

• B (hoàn toàn của khách hàng) — ⚠ cũng sai: ⚠ Microsoft chịu trách nhiệm mã hoá khi lưu và bảo vệ vật lý.

• C (không của ai) — ⚠ vô nghĩa.

Ghi nhớ

⚠ Mô hình chia sẻ trách nhiệm — bảng phải thuộc: | Hạng mục | IaaS | PaaS | SaaS | |---|---|---|---| | ⚠ Dữ liệu và danh tính | ⚠ KHÁCH | ⚠ KHÁCH | ⚠ KHÁCH | | ⚠ Ứng dụng | ⚠ khách | ⚠ chung | ⚠ Microsoft | | ⚠ Hệ điều hành | ⚠ khách | ⚠ Microsoft | ⚠ Microsoft | | ⚠ Mạng | ⚠ chung | ⚠ chung | ⚠ Microsoft | | ⚠ Hạ tầng vật lý | ⚠ Microsoft | ⚠ Microsoft | ⚠ Microsoft |

⚠ Ghi nhớ then chốt: ⚠ dữ liệu, thiết bị đầu cuối, tài khoản và quản lý truy cập LUÔN thuộc về khách hàng — ⚠ ở mọi mô hình dịch vụ.

Từ khoá nhận diện:

"dữ liệu, danh tính, phân quyền" → ⚠ LUÔN là khách hàng "trung tâm dữ liệu, phần cứng" → ⚠ LUÔN là Microsoft "hệ điều hành" → ⚠ tuỳ IaaS hay PaaS "bảo mật dữ liệu nói chung" → ⚠ chia sẻ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có container hay database nào đang mở công khai không | | | Ai đang có quyền đọc dữ liệu nhạy cảm | | | Nhật ký truy cập đã bật chưa | |

Và hiểu lầm đắt giá nhất khi chuyển lên đám mây, đứng sau phần lớn các vụ rò rỉ dữ liệu được công bố: cho rằng nhà cung cấp lo hết phần bảo mật. Họ khoá cửa trung tâm dữ liệu; việc ai được cầm chìa khoá phòng của bạn thì vẫn do bạn quyết.