Azure Policy Initiatives

Prerequisites

Memahami Azure Policy

Azure Policy Initiatives adalah kumpulan dari beberapa Azure Policy definitions yang dikelompokkan pada suatu organisasi dalam :

Mengelola dan menegakkan kebijakan secara terpusat pada Azure resources.
Mempercepat compliance terhadap standar dan regulasi (nasional maupun regional).
Menyederhanakan audit dan mempercepat penerapan kebijakan.
Melakukan otomasi terhadap deployment untuk memastikan konsistensi dan efisiensi pada manajemen resources.
Membentuk solusi kebijakan yang disesuaikan dengan kebutuhan spesifik organisasi.

Cloud Adoption Framework pada Azure

Cloud Adoption Framework (CAF) adalah panduan teknis menyeluruh dari Microsoft untuk membantu organisasi dalam mengadopsi teknologi Azure cloud secara efisien dan aman, mencakup strategi bisnis dan teknologi.

Berikut merupakan diagram Cloud Adoption Framework dalam menjelaskan fase dari siklus penerapan cloud.

Docusaurus logo

Pertimbangan dalam menerapkan policy untuk cloud governance

Terdapat dua hal penting yang menjadi pertimbangan dalam menerapkan policy untuk cloud governance:

Docusaurus logo

1. Mendefinisikan Corporate Policy

Risiko bisnis – Melakukan dokumentasi risiko bisnis secara berkala berdasarkan klasifikasi data dan tingkat kepentingan aplikasi.
Kebijakan dan kepatuhan – Menerapkan kebijakan berdasarkan resiko dengan menetapkan aturan adopsi cloud secara efisien.
Keberlangsungan – Melakukan monitoring terhadap pelanggaran dan kepatuhan terhadap kebijakan organisasi.

2. Penerapan 5 disiplin dari cloud governance

Manajemen biaya – Mengevaluasi dan memantau biaya serta memastikan penggunaan resources berdasarkan kebutuhan yang di perlukan.
Standar keamanan – Memastikan comliance terhadap standar keamanan IT dengan menerapkan standar keamanan pada seluruh upaya adopsi cloud.
Konsistensi – Menjamin konsistensi dalam konfigurasi resources.
Standar identitas – Memastikan standar identitas dan akses berlangsung secara konsisten dengan menerapkan definisi dan penugasan peran.
Percepatan deployment – Mempercepat penerapan kebijakan melalui sentralisasi, konsistensi, dan standarisasi pada template.

Konklusi

Cloud Adoption Framework mencakup praktik terbaik, dokumentasi, dan alat-alat yang dikontribusikan oleh Microsoft, mitra, dan pelanggan untuk merumuskan dan menerapkan strategi bisnis dan teknologi yang efektif untuk cloud.

Prinsip Desain Azure Policy

Dalam penerapan governance, kita harus mengetahui hirarki dari Manajemen Infrastuktur pada Azure untuk menerapkan policy guna memastikan keamanan dan manajemen cost berdasarkan resources yang di perlukan.

Hubungan antara Azure Policy dan Azure Resource Management

Azure Resource Management (ARM) adalah layanan manajemen dan deployment pada Azure resources. Terdapat dua area dimana Azure Resource Management beroperasi:

Docusaurus logo

1. Control Plane

Azure Policy beroperasi di control plane untuk menerapkan aturan dan kepatuhan pada resources. Azure Resource Manager mengelola semua operasi di control plane Azure dan mencakup berbagai komponen terpusat. Azure Policy terintegrasi dengan Azure Resource Manager.

2. Data Plane

Data plane adalah tempat interaksi langsung terhadap resources, dan Azure Policy memastikan bahwa resource yang menerima interaksi pada data plane sesuai dengan kebijakan yang telah diterapkan.

Alur operasi pada Azure Resource Management

Azure Resource Management memiliki dua skenario dalam menangani request terhadap resources yaitu Greenfield dan Brownfield. Saat kita mendeploy resources, Azure Resource Management memahami kapan pembuatan resource baru atau update terhadap resources yang sudah ada.

Docusaurus logo

- Greenfield : Mengacu pada skenario dimana terdapat sebuah policy saat membuat atau melakukan update pada resource.

- Brownfield : Mengacu pada skenario dimana sudah terdapat resource sebelum sebuah policy baru diterapkan dan resource tersebut akan di kategorikan sebagai non-compliance.

Azure Policy resources

Azure Policy mengevaluasi resources dan interaksi pada Azure dengan membandingkan nilai properties terhadap policy yang sudah di terapkan. Terdapat enam konsep Azure policy resources sebagai berikut :

Docusaurus logo

Definitions – Menentukan kondisi compliance dan efeknya jika sesuai dengan policy yang diterapkan pada scope.
Initiatives – Kumpulan beberapa definisi kebijakan dalam satu set atau group untuk menyederhanakan manajemen dan penerapannya. Terdapat Built-in policy dan Built-in initiatives yang secara default disediakan oleh Azure Resource Providers.
Assignments – Menetapkan resource yang akan di evaluasi terhadap sebuah definition atau initiative.
Exemptions – Pembebasan resource dari evaluasi definition atau initiative.
Attestations – Pengesahan terhadap Azure manual-policy (bukan built-in policy / built-in initiatives) yang dibuat berdasarkan aturan dan ketentuan organisasi.
Remediations – Tindakan untuk menetapkan resource yang non-compliance terhadap definisi dengan tipe modify atau deployIfNotExist dapat menjadi compliance dan termasuk resource yang baru dibuat secara otomatis menjadi compliance.

Azure Policy definition

Definisi Azure Policy menjelaskan kondisi compliance resource dan tindakan atau efek yang terjadi jika kondisi tersebut terpenuhi. Kebijakan ini terdiri dari dua bagian:

Kondisi yang membandingkan properti atau nilai suatu resource, yang diakses menggunakan alias, dengan nilai yang ditentukan.
Efek menentukan apa yang terjadi ketika policy dievaluasi dan cocok dengan kondisi tersebut. Untuk setiap resource baru, resource yang diperbarui, atau resource yang sudah ada, efeknya berbeda.

Struktur dari sebuah policy definition

JSON merupakan format yang digunnakan untuk policy definition.

Elemen	Deskripsi	Properti atau Nilai
`displayName` (string, maks. 128 karakter)	Digunakan untuk mengidentifikasi definisi kebijakan.	—
`description` (string, maks. 512 karakter)	Memberikan konteks mengenai kapan definisi digunakan.	—
`policyType` (string, hanya baca)	Menunjukkan asal dari definisi kebijakan. Properti ini tidak dapat diatur, tetapi SDK mengembalikan tiga nilai yang terlihat di portal.	● Built-in: Disediakan dan dikelola oleh Microsoft. ● Custom: Definisi kustom yang dibuat oleh pengguna. ● Static: Kebijakan Kepatuhan Regulasi milik Microsoft.
`mode` (string)	Dikonfigurasi tergantung pada target kebijakan: properti Azure Resource Manager atau Resource Provider.	Mode Resource Manager: • On All • Indexed Mode Resource Provider (Built-in dan didukung penuh): • Microsoft.Kubernetes.Data • Microsoft.KeyVault.Data • Microsoft.Network.Data Mode Resource Provider (Built-in, pratinjau): • Microsoft.ManagedHSM.Data • Microsoft.DataFactory.Data
`version` (string, opsional)	Definisi kebijakan bawaan dapat memiliki beberapa versi dengan `definitionID` yang sama. Jika tidak ada versi, versi terbaru yang digunakan.	—
`metadata` (objek, opsional, maks. 1.024 karakter)	Menyimpan informasi tentang definisi kebijakan.	Properti umum: • `version` (string) • `category` (string) • `preview` (boolean) • `deprecated` (boolean) • `portalReview` (string)
`parameters` (objek, opsional)	Membantu menyederhanakan manajemen kebijakan dengan mengurangi jumlah definisi.	Properti: • `name` • `type` (String, Array, Object, Boolean, Integer, Float, DateTime) • `metadata` (description, displayName, strongType, assignPermissions) • `defaultValue` • `allowedValues` • `schema`
`policyRule` (objek)	Efek dari kebijakan didefinisikan dalam `policyRule`. Terdiri dari blok `if` dan `then`.	• if: Kondisi kapan kebijakan berlaku • then: Efek jika kondisi `if` terpenuhi

{
  "displayName": "Allowed locations", 
  "description": "This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region.",
  "policyType": "BuiltIn",
  "mode": "Indexed",
  "metadata": {
    "version": "1.0.0",
    "category": "General"
  },
  "parameters": {
    "listOfAllowedLocations": {
      "type": "Array",
      "metadata": {
        "description": "The list of locations that can be specified when deploying resources.",
        "strongType": "location",
        "displayName": "Allowed locations"
      }
    }
  },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "location",
            "notIn": "[parameters('listOfAllowedLocations')]"
          },
          {
            "field": "location",
            "notEquals": "global"
          },
          {
            "field": "type",
            "notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }

  }

Contoh di atas, b2cDirectories dikecualikan dari policy rule karena field lokasi-nya bukan merupakan wilayah (lokasinya bisa berupa "United States," "Europe," "Asia Pacific," atau "Australia").

Operator logika dan kondisinya (if blocks)

Bagian pertama dari policyRule dalam definisi Azure Policy adalah blok if. Blok ini mendefinisikan kondisi-kondisi yang digunakan rule untuk mengevaluasi resource. Sebuah definitin rule dapat berisi beberapa pernyataan kondisi. Tergantung pada evaluasi yang digunakan kemungkinan membutuhkan setiap pernyataan untuk bernilai benar, atau mungkin hanya beberapa di antaranya yang bernilai benar.

Operator	Tipe	Deskripsi
`not`	`{kondisi atau operator}`	Sintaks `not` membalikkan hasil dari kondisi.
`allOf`	`[{kondisi atau operator}, {kondisi atau operator}]`	Sintaks `allOf` (seperti operasi logika `and`) mengharuskan semua kondisi bernilai benar.
`anyOf`	`[{kondisi atau operator}, {kondisi atau operator}]`	Sintaks `anyOf` (seperti operasi logika `or`) mengharuskan satu atau lebih kondisi bernilai benar.

Mari kita cek kembali bagian logika pada policy definition sebelumnya :

{
  "if": {
    "allOf": [
      {
        "field": "location",
        "notIn": "[parameters('listOfAllowedLocations')]"
      },
      {
        "field": "location",
        "notEquals": "global"
      },
      {
        "field": "type",
        "notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Policy ini akan menolak (effect: deny) deployment jika semua kondisi terpenuhi (allOf):

Lokasi tidak termasuk pada (notIn) listOfAllowedLocations → Selain Lokasi yang sudah di definisikan.
Lokasi tidak sama dengan (notEquals) global → Lokasi selain global.
Tipe tidak sama dengan (notEquals) b2cDirectories → Resource tidak ada dalam B2C Directory.

Operator logika bertingkat

Operasi logika bersifat opsional dan dapat bertingkat (nested) untuk membuat skenario yang kompleks. Contoh berikut menunjukkan operator not bertingkat di dalam operator allOf:

"if": {
    "allOf": [
      {
        "not": {
          "field": "tags",
          "containsKey": "application"
        }
      },
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }

Policy ini akan menolak (effect: deny) deployment jika semua kondisi terpenuhi:

Tidak terdapat tags dengan containsKey application
Resource merupakan storageAccounts

Maka kondisi yang dihasilkan dari logika tersebut :

Deployment Allowed:

Resource storageAccounts yang memiliki tag dengan containsKey application.
Resource apapun (asal bukan storageAccounts), bahkan jika tidak memiliki tag.

Deployment Denied:

storageAccounts yang tidak memiliki tag.

Conditions

Properti seperti fields, values, atau counts dapat dievaluasi di dalam suatu kondisi.

Properti	Deskripsi
Fields	Kondisi yang mengevaluasi apakah nilai dari properti dalam payload permintaan resource memenuhi kriteria tertentu dapat dibentuk dengan menggunakan ekspresi field. Contoh: `Name`, `fullName`, `kind`, `type`, `location`, `ID`, `identity.type`, `tags`, `tags['tagName']`, alias properti
Value	Kondisi yang mengevaluasi apakah sebuah nilai memenuhi kriteria tertentu dapat dibentuk dengan menggunakan ekspresi nilai.
Count	Kondisi yang menghitung berapa banyak anggota dari sebuah array yang memenuhi kriteria tertentu dapat dibentuk dengan menggunakan ekspresi count. Contoh: • Jumlah field, jumlah nilai • Fungsi `current()` mengembalikan nilai dari anggota array yang sedang dievaluasi

Kondisi dalam sebuah Azure Policy mengevaluasi apakah nilai-nilai dari properti seperti Fields, Value, atau Count memenuhi kriteria tertentu. Jika hasil dari sebuah fungsi menghasilkan kesalahan, maka kebijakan tersebut akan menghasilkan efek deny. Hasil ini dapat dihindari saat pengujian dengan menonaktifkan enforcementMode pada penugasannya (assignment).

Kriteria Evaluasi	Tipe Nilai
`equals`	`stringValue`
`notEquals`	`stringValue`
`like`	`stringValue`
`notLike`	`stringValue`
`match`	`stringValue`
`notMatch`	`stringValue`
`matchInsensitively`	`stringValue`
`notMatchInsensitively`	`stringValue`
`contains`	`stringValue`
`notContains`	`stringValue`
`In`	`["stringValue1", "stringValue2"]`
`notIn`	`["stringValue1", "stringValue2"]`
`containsKey`	`keyName`
`notContainsKey`	`keyName`
`less`	`dateValue` / `stringValue` / `intValue`
`lessOrEquals`	`dateValue` / `stringValue` / `intValue`
`greater`	`dateValue` / `stringValue` / `intValue`
`greaterOrEquals`	`dateValue` / `stringValue` / `intValue`
`exists`	`bool`

Policy Functions

Fungsi dapat digunakan untuk menambahkan logika tambahan ke dalam policy. Fungsi-fungsi ini diselesaikan di dalam policy definition dan juga di nilai parameter yang ditetapkan ke policy initiative. Fungsi-fungsi dari Resource Manager template dapat digunakan dalam policy, kecuali beberapa fungsi buatan pengguna (user-defined functions).

Tabel berikut menjelaskan fungsi-fungsi yang hanya tersedia di dalam aturan kebijakan.

Fungsi	Deskripsi
addDays(dateTime, numberOfDaysToAdd)	● `dateTime`: [Wajib] string – String dalam format Universal ISO 8601 DateTime `'yyyy-MM-ddTHH:mm:ss.FFFFFFFZ'`. ● `numberOfDaysToAdd`: [Wajib] integer – Jumlah hari yang akan ditambahkan.
Field(fieldName)	● `fieldName`: [Wajib] string – Nama field yang ingin diambil. ● Mengembalikan nilai dari field tersebut dari resource yang dievaluasi oleh kondisi If. ● Fungsi `field` terutama digunakan dengan `auditIfNotExists` dan `deployIfNotExists` untuk mereferensikan field pada resource yang sedang dievaluasi.
requestContext().apiVersion	Mengembalikan versi API dari permintaan yang memicu evaluasi kebijakan. Nilai ini merupakan versi API yang digunakan dalam permintaan PUT/PATCH saat pembuatan atau pembaruan resource. Versi API terbaru selalu digunakan saat evaluasi kepatuhan pada resource yang sudah ada.
policy()	Mengembalikan informasi tentang kebijakan yang sedang dievaluasi. Properti dapat diakses dari objek yang dikembalikan. Contoh properti: - `assignmentId` - `definitionId` - `setDefinitionId` - `definitionReferenceId`
ipRangeContains(range, targetRange)	● `range`: [Wajib] string – String yang menentukan rentang alamat IP untuk memeriksa apakah `targetRange` termasuk di dalamnya. ● `targetRange`: [Wajib] string – String yang menentukan rentang alamat IP yang akan divalidasi apakah termasuk dalam `range`. Mengembalikan nilai boolean apakah rentang IP `range` mencakup rentang IP `targetRange`. Rentang kosong atau campuran antara keluarga IP tidak diperbolehkan dan akan menyebabkan kegagalan evaluasi.
current(indexName)	Fungsi khusus yang hanya dapat digunakan di dalam ekspresi `count`.

Tipe Efek **(then blocks)**

Bagian kedua dari policyRule dalam definisi Azure Policy adalah blok then. Blok ini menentukan efek yang akan diterapkan ketika aturan kebijakan dievaluasi dan cocok dengan resource yang sesuai dengan kondisi.

Lebih dari satu effect dapat berlaku untuk satu policy definition.
Parameter sering digunakan untuk menentukan nilai efek yang diperbolehkan, sehingga satu policy definition dapat menjadi lebih fleksibel.
Properti resource dan logika pada policy rule dapat menentukan apakah suatu efek dianggap valid terhadap definisi kebijakan tersebut.

Efek	Deskripsi	Tipe Evaluasi
disabled	Efek disabled digunakan untuk menonaktifkan kebijakan. Jika sebuah definisi kebijakan memiliki efek ini, maka semua penugasannya tidak akan aktif. Efek ini diperiksa pertama kali untuk menentukan apakah aturan kebijakan perlu dievaluasi. Memberikan fleksibilitas untuk menonaktifkan satu penugasan tanpa menonaktifkan semua penugasan dari kebijakan tersebut.	Evaluasi Sinkron (Synchronous)
append	Efek append digunakan untuk menambahkan field tambahan ke resource yang diminta saat dibuat atau diperbarui. Saat ini sebagian besar tidak digunakan lagi karena efek modify juga bisa menambahkan field.	Evaluasi Sinkron (Synchronous)
modify	Efek modify digunakan untuk menambahkan, memperbarui, atau menghapus properti atau tag pada subscription atau resource saat dibuat atau diperbarui. Memungkinkan Azure Policy untuk mengubah permintaan ke Azure Resource Manager guna memastikan kepatuhan.	Evaluasi Sinkron (Synchronous)
deny	Efek deny digunakan untuk mencegah permintaan resource yang tidak sesuai dengan standar yang didefinisikan dalam kebijakan, sehingga permintaan akan gagal.	Evaluasi Sinkron (Synchronous)
denyAction	Efek denyAction digunakan untuk memblokir permintaan berdasarkan tindakan yang dimaksud terhadap resource dalam skala besar. Saat ini, satu-satunya tindakan yang didukung adalah `DELETE`.	Evaluasi Sinkron (Synchronous)
audit	Efek audit digunakan untuk membuat peringatan di log aktivitas saat mengevaluasi resource yang tidak patuh, tanpa menghentikan permintaan.	Evaluasi Asinkron (Asynchronous)
auditIfNotExists	Efek auditIfNotExists memungkinkan audit terhadap resource yang terkait dengan resource yang cocok dengan kondisi `if`, tetapi tidak memiliki properti yang ditentukan dalam rincian kondisi `then`.	Evaluasi Asinkron (Asynchronous)
deployIfNotExists	Efek deployIfNotExists menjalankan template deployment saat kondisi terpenuhi. Dapat memicu penyebaran resource terkait berdasarkan status kepatuhan dari resource yang sedang dievaluasi.	Evaluasi Asinkron (Asynchronous)
manual	Efek manual memungkinkan Anda untuk menyatakan sendiri kepatuhan dari resource atau cakupan (scope). Ketika definisi kebijakan dengan efek ini ditugaskan, Anda dapat menetapkan status kepatuhan secara manual melalui custom attestations.	Pernyataan Manual (Manual Attestation)

Daftar berikut memberikan panduan umum mengenai efek-efek yang dapat saling dipertukarkan:

audit, deny, dan baik modify maupun append sering kali dapat saling dipertukarkan.
auditIfNotExists dan deployIfNotExists juga sering kali dapat saling dipertukarkan.
manual tidak dapat dipertukarkan.
disabled dapat dipertukarkan dengan efek apa pun.

Dipertukarkan disini dimaksud dapat digunakan sebagai pengganti satu sama lain, tergantung pada tujuan atau situasi kebijakannya dan hasil atau dampaknya akan relatif serupa terhadap evaluasi kebijakan tersebut.

Evaluasi resources melalui Azure Policy

Salah satu manfaat utama dari Azure Policy adalah insight dan kontrol yang diberikannya terhadap resource dalam sebuah subscription (subscription) atau grup manajemen dari beberapa subscription. Kontrol ini dapat digunakan untuk:

Mencegah resource dibuat di lokasi yang salah
Memaksakan penggunaan tag yang umum dan konsisten
Melakukan audit terhadap konfigurasi dan pengaturan resource yang sudah ada

Pemicu Evaluasi (Evaluation Triggers)

Evaluasi atas kebijakan atau inisiatif yang ditetapkan terjadi karena berbagai peristiwa, seperti:

Kebijakan atau inisiatif baru ditetapkan pada suatu cakupan (scope)
Kebijakan atau inisiatif yang sudah ada diperbarui
Resource dibuat atau diperbarui melalui Azure Resource Manager, REST API, atau SDK yang didukung
Subscription dibuat atau dipindahkan dalam hierarki grup manajemen yang memiliki kebijakan yang ditargetkan untuk jenis resource subscription
Pengecualian kebijakan dibuat, diperbarui, atau dihapus
Penyedia resource konfigurasi mesin diperbarui oleh resource yang dikelola
Pemindaian berdasarkan permintaan (on-demand scan)

Waktu Evaluasi (Evaluation Timing)

Saat bekerja dengan penetapan kebijakan di Azure, penting untuk memahami perilaku dan waktu dari pemindaian kepatuhan, terutama dalam skenario Brownfield (kebijakan baru diterapkan pada resource yang sudah ada):

Pemindaian otomatis penuh: Dilakukan setiap 24 jam
Pemindaian manual (Brownfield): Jalankan az policy state trigger-scan secara manual
Delay saat kebijakan baru ditetapkan: Hingga 30 menit. Cache Azure Resource Manager bisa menyebabkan keterlambatan
- Solusi: Logout dan login ulang untuk menyegarkan cache

Faktor yang mempengaruhi durasi pemindaian:

Ukuran dan kompleksitas definisi kebijakan
Jumlah kebijakan yang diterapkan
Ukuran cakupan resource
Beban sistem (pemindaian kepatuhan adalah operasi prioritas rendah)

Status Kepatuhan resource (Resource Compliance States)

Setelah kebijakan ditetapkan, Azure Policy menentukan resource yang relevan dan mengevaluasi resource tersebut (selain yang dikecualikan). Status kepatuhan:

Compliant (mematuhi)
Non-compliant (tidak mematuhi)
Error (gagal evaluasi)
Conflicting (kebijakan bertentangan)
Protected (terlindungi oleh kebijakan denyAction)
Exempted (dikecualikan)
Unknown (efek manual, status default)

Persentase kepatuhan = (Compliant + Exempted + Unknown) / Total resource

Enforcement Mode

enforcementMode adalah properti dari penetapan kebijakan untuk menonaktifkan efek kebijakan tertentu saat pengujian. Ini berbeda dari efek disabled, karena evaluasi tetap berjalan, tetapi efeknya tidak diterapkan.

Mode	JSON Value	Log Aktif	Efek Diterapkan	Manual Remediasi	Deskripsi
Enabled	`Default`	✅	✅	✅	Kebijakan dijalankan sepenuhnya
Disabled	`DoNotEnforce`	❌	❌	✅	Evaluasi tetap dilakukan, tetapi efek kebijakan tidak dijalankan

Enforcement Mode cocok untuk skenario "What If", karena memungkinkan uji coba kebijakan tanpa mempengaruhi sumber daya secara langsung.

Praktik Terbaik Penetapan Kebijakan (Safe Deployment)

Tanpa pengujian yang benar, menerapkan kebijakan di lingkungan produksi bisa menyebabkan masalah.

Kerangka kerja terbaik meliputi:

Mulai dengan enforcementMode: Disabled
- Evaluasi dulu sebelum efek dijalankan.
Terapkan secara bertahap (deployment rings)
- Mulai dari lingkungan uji, lalu bertahap ke produksi.

Langkah Umum:

Buat definisi kebijakan (scope: root)
Buat penetapan untuk ring tertentu (misal: Ring 5)
Cek Kepatuhan & Kesehatan Aplikasi
Ulangi di semua ring non-produksi
Setelah valid, terapkan ke produksi secara bertahap

Reaksi terhadap Perubahan Status Kebijakan

Azure Policy dapat memicu event yang memberi tahu aplikasi saat terjadi perubahan status. Event dikirim melalui Azure Event Grid ke Event Handlers, seperti:

Azure Functions
Azure Logic Apps
Webhook kustom

Event Grid menjamin pengiriman yang andal dengan retry otomatis dan pengelolaan error.

Cloud Adoption Framework pada Azure​

Pertimbangan dalam menerapkan policy untuk cloud governance

Prinsip Desain Azure Policy​

Hubungan antara Azure Policy dan Azure Resource Management​

Alur operasi pada Azure Resource Management​

Azure Policy resources​

Azure Policy definition​

Struktur dari sebuah policy definition​

Operator logika dan kondisinya (if blocks)​

Operator logika bertingkat​

Conditions​

Policy Functions​

Tipe Efek (then blocks)​

Evaluasi resources melalui Azure Policy​

Pemicu Evaluasi (Evaluation Triggers)​

Waktu Evaluasi (Evaluation Timing)​

Status Kepatuhan resource (Resource Compliance States)​

Enforcement Mode​

Praktik Terbaik Penetapan Kebijakan (Safe Deployment)​

Reaksi terhadap Perubahan Status Kebijakan​

Cloud Adoption Framework pada Azure

Prinsip Desain Azure Policy

Hubungan antara Azure Policy dan Azure Resource Management

Alur operasi pada Azure Resource Management

Azure Policy resources

Azure Policy definition

Struktur dari sebuah policy definition

Operator logika dan kondisinya (if blocks)

Operator logika bertingkat

Conditions

Policy Functions

Tipe Efek **(then blocks)**

Evaluasi resources melalui Azure Policy

Pemicu Evaluasi (Evaluation Triggers)

Waktu Evaluasi (Evaluation Timing)

Status Kepatuhan resource (Resource Compliance States)

Enforcement Mode

Praktik Terbaik Penetapan Kebijakan (Safe Deployment)

Reaksi terhadap Perubahan Status Kebijakan