Tweet
Azure Policy – “luật chơi” để quản trị tài nguyên Azure ở quy mô lớn
Khi doanh nghiệp mới sử dụng Azure, Administrator có thể kiểm tra từng Virtual Machine, Storage Account hay Resource Group bằng tay. Nhưng khi hệ thống tăng lên hàng trăm hoặc hàng nghìn resource, cách quản trị thủ công gần như không còn khả thi.
Ví dụ doanh nghiệp đặt ra các quy định:
Làm thế nào để Azure tự động kiểm tra và thực thi những quy định này?
Đó chính là vai trò của Azure Policy. Azure Policy là gì?
Azure Policy là dịch vụ Governance của Microsoft Azure cho phép tổ chức tạo, gán và quản lý các chính sách đối với Azure resources.
Azure Policy có thể liên tục đánh giá tài nguyên để xác định:
Compliant – đáp ứng chính sách
hoặc
Non-compliant – vi phạm chính sách
Tùy loại policy và effect được cấu hình, Azure còn có thể ngăn resource không hợp lệ được triển khai, tự động bổ sung cấu hình hoặc hỗ trợ remediation cho các resource chưa đáp ứng yêu cầu.
Điểm quan trọng là Azure Policy không chỉ dùng để “xem báo cáo”. Nó giúp doanh nghiệp biến các tiêu chuẩn quản trị thành những quy tắc có thể được Azure thực thi ở quy mô lớn. Những tình huống sử dụng Azure Policy
Một use case rất phổ biến là Allowed resource types.
Ví dụ doanh nghiệp chỉ cho phép triển khai Virtual Machine, Storage Account và Virtual Network. Azure Policy có thể hạn chế việc triển khai những resource type không được phê duyệt.
Trường hợp thứ hai là Allowed virtual machine SKUs.
Không phải Administrator nào cũng nên được phép tạo VM 64 hoặc 128 vCPU. Doanh nghiệp có thể quy định chỉ cho phép một số VM SKU nhằm kiểm soát chi phí và chuẩn hóa hạ tầng.
Trường hợp thứ ba là Allowed locations.
Ví dụ:
Allowed locations = Southeast Asia, East Asia
Nếu người dùng cố triển khai resource sang một Region không được phép, Policy có thể đánh dấu vi phạm hoặc từ chối deployment tùy effect được cấu hình.
Điều này đặc biệt quan trọng khi doanh nghiệp có yêu cầu về data residency, compliance hoặc governance.
Bắt buộc sử dụng Tag
Tag rất quan trọng khi quản lý Azure ở quy mô lớn.
Ví dụ doanh nghiệp yêu cầu:
Department = IT
Environment = Production
CostCenter = CC1001
Azure Policy có thể kiểm tra hoặc bắt buộc resource phải có các tag cần thiết.
Nhờ đó, doanh nghiệp dễ dàng:
Nếu chỉ “nhắc mọi người nhớ gắn tag”, sớm hay muộn sẽ có người quên. Policy giúp biến quy định thành cơ chế kiểm soát kỹ thuật.
Kiểm tra Azure Backup
Một use case khác là:
Azure Backup should be enabled for Virtual Machines.
Azure Policy có thể đánh giá các VM để phát hiện những máy chưa đáp ứng yêu cầu bảo vệ dữ liệu.
Administrator từ đó có được cái nhìn tập trung về mức độ Compliance thay vì phải mở từng VM để kiểm tra.
Policy Definition là gì?
Một Policy Definition mô tả điều kiện cần kiểm tra và hành động tương ứng.
Có thể hiểu đơn giản:
IF điều kiện xảy ra → THEN Azure áp dụng Effect
Một số effect thường gặp gồm:
Audit
Phát hiện và ghi nhận resource không tuân thủ nhưng không ngăn deployment.
Deny
Từ chối thao tác tạo hoặc cập nhật resource nếu vi phạm policy.
Modify
Thêm, cập nhật hoặc loại bỏ một số thuộc tính hoặc tag phù hợp với policy.
DeployIfNotExists
Có thể triển khai cấu hình liên quan khi tài nguyên chưa đáp ứng điều kiện xác định.
Vì vậy, cùng là Azure Policy nhưng mức độ tác động có thể rất khác nhau.
Policy Initiative là gì?
Trong thực tế, doanh nghiệp hiếm khi chỉ có một Policy.
Ví dụ bộ tiêu chuẩn dành cho Production có thể yêu cầu:
Thay vì quản lý từng Policy riêng lẻ, chúng ta có thể gom nhiều Policy Definitions thành một:
Initiative Definition
Sau đó gán Initiative cho phạm vi cần quản lý.
Ngay cả khi ban đầu chỉ có vài Policy Definitions, việc tổ chức chúng thành Initiative cũng giúp hệ thống dễ quản lý và mở rộng hơn về sau. Scope – Policy sẽ áp dụng ở đâu?
Sau khi tạo Policy Definition hoặc Initiative, Administrator phải xác định Scope.
Azure Policy có thể được assign ở các cấp như:
Management Group → Subscription → Resource Group → Resource
Điểm rất quan trọng là policy ở scope phía trên có thể ảnh hưởng đến các resource nằm bên dưới scope đó.
Ví dụ:
Nếu một Policy được assign tại Subscription:
Allowed Locations = Southeast Asia
thì các Resource Group và resource thuộc Subscription đó sẽ nằm trong phạm vi đánh giá, trừ những trường hợp được cấu hình exclusion phù hợp.
Đây là lý do Azure Policy có khả năng quản trị ở quy mô rất lớn.
Quy trình triển khai Azure Policy
Có thể ghi nhớ bằng ba bước:
1. Define and Create
Xác định yêu cầu quản trị, sau đó sử dụng Built-in Policy hoặc tạo Custom Policy Definition. Nhiều Policy có thể được gom thành Initiative.
2. Scope and Assign
Xác định Policy sẽ áp dụng cho Management Group, Subscription, Resource Group hay resource cụ thể, sau đó tạo Policy Assignment.
3. Assess Compliance
Azure Policy đánh giá các tài nguyên và hiển thị trạng thái:
Compliant / Non-compliant
Administrator có thể tiếp tục phân tích nguyên nhân và thực hiện remediation khi phù hợp.
Luồng tổng thể:
Policy Definition(s) → Initiative → Assignment → Scope → Evaluation → Compliance → Remediation Azure Policy khác Azure RBAC ở điểm nào?
Đây là phần rất dễ nhầm khi học AZ-104.
Azure RBAC trả lời:
“User này được phép làm gì?”
Ví dụ:
User A có quyền tạo Virtual Machine.
Trong khi đó, Azure Policy trả lời:
“Resource được tạo ra phải tuân theo những quy định nào?”
Ví dụ:
User A được RBAC cho phép tạo VM, nhưng Azure Policy quy định VM chỉ được triển khai tại Southeast Asia.
Nếu User A cố tạo VM tại một Region bị Policy Deny, deployment vẫn có thể bị từ chối.
Có thể nhớ ngắn gọn:
RBAC kiểm soát quyền của Identity.
Azure Policy kiểm soát tính tuân thủ của Resource.
Hai công nghệ không thay thế nhau mà thường được triển khai cùng nhau. Từ “quản trị bằng con người” sang Governance as Code
Giá trị lớn nhất của Azure Policy không nằm ở việc tạo ra thêm các quy định.
Nó nằm ở khả năng biến những tiêu chuẩn của doanh nghiệp thành các kiểm soát kỹ thuật có thể đánh giá và thực thi tự động.
Thay vì:
Administrator nhớ quy định → kiểm tra bằng tay → phát hiện sai → yêu cầu sửa
chúng ta chuyển sang:
Policy → Assignment → Continuous Evaluation → Compliance → Remediation
Đó chính là một trong những nền tảng quan trọng của Cloud Governance.
Khi hệ thống chỉ có 10 resource, Azure Policy có thể chưa cho thấy nhiều khác biệt.
Nhưng khi doanh nghiệp có 10 Subscription, 100 Resource Group và hàng nghìn Azure resources, việc quản trị bằng policy không còn chỉ là tiện ích nữa mà trở thành một phần quan trọng của kiến trúc Cloud.
Tài liệu Microsoft Learn:
#AzurePolicy #AzureGovernance #AZ104 #MicrosoftAzure #CloudGovernance #AzureRBAC #Compliance #CloudSecurity MCSA vnpro #MCSAAzureAWS
Khi doanh nghiệp mới sử dụng Azure, Administrator có thể kiểm tra từng Virtual Machine, Storage Account hay Resource Group bằng tay. Nhưng khi hệ thống tăng lên hàng trăm hoặc hàng nghìn resource, cách quản trị thủ công gần như không còn khả thi.
Ví dụ doanh nghiệp đặt ra các quy định:
- Chỉ được triển khai tài nguyên tại Southeast Asia và East Asia.
- Chỉ được sử dụng một số VM SKU đã phê duyệt.
- Mọi resource bắt buộc phải có tag Department và CostCenter.
- Azure VM phải được kiểm tra việc bật Azure Backup.
- Không được triển khai một số loại resource ngoài danh sách cho phép.
Làm thế nào để Azure tự động kiểm tra và thực thi những quy định này?
Đó chính là vai trò của Azure Policy. Azure Policy là gì?
Azure Policy là dịch vụ Governance của Microsoft Azure cho phép tổ chức tạo, gán và quản lý các chính sách đối với Azure resources.
Azure Policy có thể liên tục đánh giá tài nguyên để xác định:
Compliant – đáp ứng chính sách
hoặc
Non-compliant – vi phạm chính sách
Tùy loại policy và effect được cấu hình, Azure còn có thể ngăn resource không hợp lệ được triển khai, tự động bổ sung cấu hình hoặc hỗ trợ remediation cho các resource chưa đáp ứng yêu cầu.
Điểm quan trọng là Azure Policy không chỉ dùng để “xem báo cáo”. Nó giúp doanh nghiệp biến các tiêu chuẩn quản trị thành những quy tắc có thể được Azure thực thi ở quy mô lớn. Những tình huống sử dụng Azure Policy
Một use case rất phổ biến là Allowed resource types.
Ví dụ doanh nghiệp chỉ cho phép triển khai Virtual Machine, Storage Account và Virtual Network. Azure Policy có thể hạn chế việc triển khai những resource type không được phê duyệt.
Trường hợp thứ hai là Allowed virtual machine SKUs.
Không phải Administrator nào cũng nên được phép tạo VM 64 hoặc 128 vCPU. Doanh nghiệp có thể quy định chỉ cho phép một số VM SKU nhằm kiểm soát chi phí và chuẩn hóa hạ tầng.
Trường hợp thứ ba là Allowed locations.
Ví dụ:
Allowed locations = Southeast Asia, East Asia
Nếu người dùng cố triển khai resource sang một Region không được phép, Policy có thể đánh dấu vi phạm hoặc từ chối deployment tùy effect được cấu hình.
Điều này đặc biệt quan trọng khi doanh nghiệp có yêu cầu về data residency, compliance hoặc governance.
Bắt buộc sử dụng Tag
Tag rất quan trọng khi quản lý Azure ở quy mô lớn.
Ví dụ doanh nghiệp yêu cầu:
Department = IT
Environment = Production
CostCenter = CC1001
Azure Policy có thể kiểm tra hoặc bắt buộc resource phải có các tag cần thiết.
Nhờ đó, doanh nghiệp dễ dàng:
- Phân loại tài nguyên.
- Theo dõi chi phí.
- Xác định chủ sở hữu.
- Tách Production/Development.
- Hỗ trợ automation.
Nếu chỉ “nhắc mọi người nhớ gắn tag”, sớm hay muộn sẽ có người quên. Policy giúp biến quy định thành cơ chế kiểm soát kỹ thuật.
Kiểm tra Azure Backup
Một use case khác là:
Azure Backup should be enabled for Virtual Machines.
Azure Policy có thể đánh giá các VM để phát hiện những máy chưa đáp ứng yêu cầu bảo vệ dữ liệu.
Administrator từ đó có được cái nhìn tập trung về mức độ Compliance thay vì phải mở từng VM để kiểm tra.
Policy Definition là gì?
Một Policy Definition mô tả điều kiện cần kiểm tra và hành động tương ứng.
Có thể hiểu đơn giản:
IF điều kiện xảy ra → THEN Azure áp dụng Effect
Một số effect thường gặp gồm:
Audit
Phát hiện và ghi nhận resource không tuân thủ nhưng không ngăn deployment.
Deny
Từ chối thao tác tạo hoặc cập nhật resource nếu vi phạm policy.
Modify
Thêm, cập nhật hoặc loại bỏ một số thuộc tính hoặc tag phù hợp với policy.
DeployIfNotExists
Có thể triển khai cấu hình liên quan khi tài nguyên chưa đáp ứng điều kiện xác định.
Vì vậy, cùng là Azure Policy nhưng mức độ tác động có thể rất khác nhau.
Policy Initiative là gì?
Trong thực tế, doanh nghiệp hiếm khi chỉ có một Policy.
Ví dụ bộ tiêu chuẩn dành cho Production có thể yêu cầu:
- Allowed Locations.
- Allowed VM SKUs.
- Required Tags.
- Backup.
- Logging.
- Security configuration.
Thay vì quản lý từng Policy riêng lẻ, chúng ta có thể gom nhiều Policy Definitions thành một:
Initiative Definition
Sau đó gán Initiative cho phạm vi cần quản lý.
Ngay cả khi ban đầu chỉ có vài Policy Definitions, việc tổ chức chúng thành Initiative cũng giúp hệ thống dễ quản lý và mở rộng hơn về sau. Scope – Policy sẽ áp dụng ở đâu?
Sau khi tạo Policy Definition hoặc Initiative, Administrator phải xác định Scope.
Azure Policy có thể được assign ở các cấp như:
Management Group → Subscription → Resource Group → Resource
Điểm rất quan trọng là policy ở scope phía trên có thể ảnh hưởng đến các resource nằm bên dưới scope đó.
Ví dụ:
Nếu một Policy được assign tại Subscription:
Allowed Locations = Southeast Asia
thì các Resource Group và resource thuộc Subscription đó sẽ nằm trong phạm vi đánh giá, trừ những trường hợp được cấu hình exclusion phù hợp.
Đây là lý do Azure Policy có khả năng quản trị ở quy mô rất lớn.
Quy trình triển khai Azure Policy
Có thể ghi nhớ bằng ba bước:
1. Define and Create
Xác định yêu cầu quản trị, sau đó sử dụng Built-in Policy hoặc tạo Custom Policy Definition. Nhiều Policy có thể được gom thành Initiative.
2. Scope and Assign
Xác định Policy sẽ áp dụng cho Management Group, Subscription, Resource Group hay resource cụ thể, sau đó tạo Policy Assignment.
3. Assess Compliance
Azure Policy đánh giá các tài nguyên và hiển thị trạng thái:
Compliant / Non-compliant
Administrator có thể tiếp tục phân tích nguyên nhân và thực hiện remediation khi phù hợp.
Luồng tổng thể:
Policy Definition(s) → Initiative → Assignment → Scope → Evaluation → Compliance → Remediation Azure Policy khác Azure RBAC ở điểm nào?
Đây là phần rất dễ nhầm khi học AZ-104.
Azure RBAC trả lời:
“User này được phép làm gì?”
Ví dụ:
User A có quyền tạo Virtual Machine.
Trong khi đó, Azure Policy trả lời:
“Resource được tạo ra phải tuân theo những quy định nào?”
Ví dụ:
User A được RBAC cho phép tạo VM, nhưng Azure Policy quy định VM chỉ được triển khai tại Southeast Asia.
Nếu User A cố tạo VM tại một Region bị Policy Deny, deployment vẫn có thể bị từ chối.
Có thể nhớ ngắn gọn:
RBAC kiểm soát quyền của Identity.
Azure Policy kiểm soát tính tuân thủ của Resource.
Hai công nghệ không thay thế nhau mà thường được triển khai cùng nhau. Từ “quản trị bằng con người” sang Governance as Code
Giá trị lớn nhất của Azure Policy không nằm ở việc tạo ra thêm các quy định.
Nó nằm ở khả năng biến những tiêu chuẩn của doanh nghiệp thành các kiểm soát kỹ thuật có thể đánh giá và thực thi tự động.
Thay vì:
Administrator nhớ quy định → kiểm tra bằng tay → phát hiện sai → yêu cầu sửa
chúng ta chuyển sang:
Policy → Assignment → Continuous Evaluation → Compliance → Remediation
Đó chính là một trong những nền tảng quan trọng của Cloud Governance.
Khi hệ thống chỉ có 10 resource, Azure Policy có thể chưa cho thấy nhiều khác biệt.
Nhưng khi doanh nghiệp có 10 Subscription, 100 Resource Group và hàng nghìn Azure resources, việc quản trị bằng policy không còn chỉ là tiện ích nữa mà trở thành một phần quan trọng của kiến trúc Cloud.
Tài liệu Microsoft Learn:
#AzurePolicy #AzureGovernance #AZ104 #MicrosoftAzure #CloudGovernance #AzureRBAC #Compliance #CloudSecurity MCSA vnpro #MCSAAzureAWS
Attached Files