Kebijakan Conditional Access Tidak Diterapkan: Cara Mendiagnosis dan Memperbaiki Masalah di Microsoft Entra

By Mirko Peters · 2026-04-23 · Updated 2026-07-28

Automatically translated with AI from the original post. Read the English original

Cover: Fix Microsoft Entra ID Conditional Access and Identity Debt

Kebijakan Conditional Access yang tidak diterapkan memerlukan skenario bisnis yang jelas, batasan keamanan dan data yang tervalidasi, serta kepemilikan yang bertanggung jawab. Mulailah dari hasil yang dituju, uji konfigurasi dan dampak kebijakan dengan pengguna yang representatif, dokumentasikan keputusan dan proses dukungan, lalu tinjau pendekatan ini secara berkala seiring berubahnya kebutuhan dan kemampuan Microsoft 365.

Kebijakan Conditional Access tidak diterapkan: daftar periksa praktis

Tentukan skenario, pemilik, dan kriteria keputusan.
Validasi izin, kebijakan, keamanan, dan dampak bagi pengguna.
Uji dengan percontohan, dan dokumentasikan keputusan dukungan serta peninjauan.

Gunakan Microsoft Learn untuk panduan terkini.

Terakhir ditinjau: Juli 2026.

Conditional Access adalah tulang punggung perlindungan identitas di Microsoft Entra (sebelumnya Azure AD). Namun ketika Anda melihat status "NotApplied" yang ditakutkan itu di log Anda, artinya kontrol akses tidak berfungsi sebagaimana mestinya, dan organisasi Anda bisa terbuka lebar bagi pihak yang salah. Masalah ini tersembunyi diam-diam hingga audit kepatuhan, respons insiden, atau pengguna yang sulit diatur mengungkap celahnya.

Bagian yang sulit? Jarang sekali hanya ada satu alasan mengapa kebijakan Conditional Access tidak diterapkan. Bisa jadi ada pengaturan yang terlewat, service principal yang lolos dari celah, atau sprawl kebijakan yang mengaburkan keadaan. Ketika Conditional Access tidak bekerja, proses pemecahan masalah dengan cepat menjadi rumit. Karena itu, memahami cara Microsoft Entra mengevaluasi dan melewati kebijakan sangatlah penting. Dengan pemahaman ini, Anda dapat menutup celah yang tak terlihat, mengurangi keluhan pengguna, dan membuat tim keamanan Anda tenang.

Dengan panduan ini, Anda akan mendapatkan jalur yang jelas untuk mendiagnosis mengapa sebuah kebijakan tidak ditegakkan, menghindari jebakan yang paling umum, serta mulai membangun kebijakan Conditional Access yang benar-benar menjalankan apa yang Anda maksudkan, tidak kurang dan tidak lebih.

Memahami Evaluasi Conditional Access di Azure dan Alasan Kebijakan Menampilkan Not Applied

Conditional Access di Microsoft Entra mungkin terlihat hitam-putih, yaitu terapkan aturan, dapatkan hasilnya. Namun di balik layar, prosesnya cepat menjadi rumit. Sebelum Anda memperbaiki masalah "NotApplied", Anda perlu memahami bagaimana Entra memproses setiap kebijakan begitu seseorang mencoba masuk. Tidak setiap kebijakan akan cocok atau terlewat hanya berdasarkan apa yang Anda periksa di pusat admin.

Ketika kebijakan ditandai "NotApplied", artinya Entra telah mengevaluasi sign-in terhadap kebijakan tersebut, tetapi memutuskan bahwa aturan itu tidak sesuai dengan situasinya. Mungkin pengguna, perangkat, aplikasi, atau konteks sign-in tidak cocok dengan cakupan kebijakan, atau mungkin ada kebijakan lain dengan prioritas lebih tinggi yang lebih dulu memberikan hasil yang diwajibkan.

Semua ini berkaitan dengan urutan evaluasi dan cara Entra menentukan kebijakan mana yang menang ketika terjadi tumpang tindih. Belum lagi pengecualian kebijakan, alur service principal, keunikan named location, serta sejumlah layanan Microsoft 365 yang punya perilakunya sendiri. Banyak kebijakan terlewati, kadang karena alasan yang tidak jelas, dan tanda "NotApplied" menjadi satu-satunya petunjuk bahwa ada sesuatu yang tidak beres.

Jika Anda tidak menggali alasan-alasan ini dan mengenali "NotApplied" apa adanya, Anda berisiko membiarkan celah keamanan terlewat atau menimbulkan masalah login bagi pengguna yang sah. Di sinilah log sign-in membantu, memungkinkan Anda membedakan kebijakan yang diterapkan, dilewati, dan diabaikan, serta memberi gambaran nyata tentang apa yang sebenarnya terjadi. Untuk pembahasan yang lebih mendalam tentang Conditional Access dan risiko, episode podcast ini tentang sprawl kebijakan dan tata kelola menawarkan strategi yang telah teruji untuk organisasi berskala besar.

Cara Log Sign-In Microsoft Entra Membantu Mengidentifikasi Celah Penerapan Kebijakan

Log sign-in Microsoft Entra adalah detektif utama Anda dalam mengurai misteri Conditional Access. Setiap entri log merinci kebijakan mana yang dievaluasi untuk sebuah sign-in, dan Anda akan melihat status yang eksplisit seperti "Applied", "NotApplied", "Failure", atau "Success". "NotApplied" tidak berarti Entra mengabaikan kebijakan tersebut. Artinya, kondisinya tidak terpenuhi, atau ada kebijakan lain yang lebih diutamakan.

Buka tab "Conditional Access" di sign-in logs. Di sini, Anda dapat menghubungkan konteks pengguna, perangkat, dan aplikasi untuk mengetahui mengapa sebuah kebijakan tidak terpicu. Perhatikan artefak seperti sign-in service principal atau alur app-only, karena sering muncul sebagai "NotApplied" sebab CA tidak memproses token non-interaktif. Kemampuan membaca log ini sangat penting untuk menemukan celah dan memastikan tidak ada salah konfigurasi. Untuk informasi lebih lanjut tentang kebijakan dasar dan pelacakan masalah kepercayaan, lihat panduan ini tentang celah kepercayaan Conditional Access.

Kesalahan Konfigurasi Conditional Access yang Paling Umum dan Menghambat Penerapan Kebijakan

Mari jujur—Conditional Access adalah salah satu alat di mana kesalahan kecil bisa berubah menjadi masalah keamanan yang besar. Penyebab paling umum dari status "NotApplied"? Kesalahan konfigurasi, sesederhana itu. Pengecualian yang keliru, ambang risiko yang terlalu longgar, atau protokol lama yang terlewat dapat membuat pintu keamanan terbuka, padahal semua orang mengira pintunya sudah terkunci rapat.

Ketidaksesuaian cakupan dan kondisi sering terjadi, terutama pada pengaturan lokasi atau logika sign-in berisiko. Baik pengguna yang berada di lokasi tak terduga maupun aplikasi yang menggunakan autentikasi usang, penerapan kebijakan bisa gagal dengan cara yang tidak mudah diprediksi. Ditambah lagi dengan kerumitan kontrol akses, misalnya keliru menganggap "require all" sama dengan "require any", dan Anda akan melihat betapa mudahnya aturan yang dimaksudkan justru terlewat.

Selain itu, autentikasi lama berfungsi seperti jalan belakang yang melewati Conditional Access dan MFA. Celah ini sering dilupakan banyak organisasi, sampai tinjauan kepatuhan menyampaikan kabar buruk. Admin terbaik tetap waspada dengan memeriksa ulang pekerjaan mereka dan terus mengikuti celah baru seiring berkembangnya Microsoft 365. Jika Anda ingin melihat bagaimana drift konfigurasi yang halus dapat mengubah hasil kepatuhan bahkan pada layanan Microsoft sendiri, podcast tentang compliance drift Microsoft 365 ini sangat membuka wawasan.

Jebakan Kondisi Lokasi dan Risiko dalam Kebijakan Conditional Access

Named Location yang Salah Konfigurasi: Jika named location memiliki rentang IP yang keliru, alamat tepercaya yang hilang, atau daftar negara yang tidak lengkap, sebagian sign-in dapat lolos dari kebijakan Anda tanpa peringatan.
Tingkat Risiko yang Tidak Tepat: Jika ambang risiko pengguna atau sign-in berisiko Anda ditetapkan terlalu tinggi (atau terlalu rendah), risiko yang sebenarnya dapat lolos begitu saja, atau pengguna justru terblokir karena alarm palsu.
Lokasi yang Terlewat atau Terlalu Luas: Lupa menyertakan semua rentang IP, cloud app yang diperlukan, atau membiarkan wilayah "tepercaya" lama tetap ada akan menghasilkan penerapan kebijakan yang tidak merata.
Titik Buta Status Perangkat: Tidak memperhitungkan kepatuhan perangkat atau hybrid Azure AD join akan membuat sign-in dari endpoint yang tidak dikelola luput dari pengawasan.

Untuk menghindari kesalahan ini, audit yang konsisten dan tata kelola yang jelas, sebagaimana dijelaskan dalam panduan tata kelola Azure ini, membuat perbedaan besar.

Kontrol Akses dan Aturan Grant yang Menyebabkan Conditional Access Gagal

Kontrol Grant yang Bertentangan ("require all" vs. "require any"): Mengatur kebijakan agar mewajibkan semua kontrol grant—seperti MFA plus perangkat yang patuh plus aplikasi yang disetujui—menciptakan situasi di mana satu persyaratan yang tidak terpenuhi menyebabkan "NotApplied" atau penolakan yang tidak diinginkan.
Logika Block Access yang Tidak Jelas: Secara tidak sengaja mengaktifkan kontrol "grant" dan "block" sekaligus dalam satu kebijakan dapat saling meniadakan, sehingga penerapannya sulit diprediksi (atau menghasilkan hasil "NotApplied" jika kondisi block tidak terpicu).
Grup Pengguna yang Tumpang Tindih atau Dikecualikan: Menyertakan grup yang luas dalam kebijakan berprioritas tinggi dapat menimpa kebijakan yang lebih spesifik, sehingga kebijakan tersebut tampak "NotApplied" karena kondisinya tidak pernah sempat terpicu.
Penargetan Cloud App yang Keliru: Menerapkan kebijakan pada cloud app yang salah, atau melewatkan satu aplikasi penting, berarti pembatasan yang dimaksud tidak pernah aktif.

Autentikasi Lama dan Celah Bypass MFA yang Menimbulkan Kerentanan

Protokol Lama: Protokol konvensional seperti POP, IMAP, dan SMTP melewati Conditional Access dan MFA, menyelinap melewati pertahanan Anda melalui Exchange Online dan endpoint klasik lainnya.
Pendaftaran Aplikasi yang Tidak Dikelola: Aplikasi yang didaftarkan sebelum Conditional Access diberlakukan (atau yang menggunakan alur kredensial klien) tidak tunduk pada pemeriksaan kebijakan modern, sehingga penyerang atau pengguna yang tidak sadar dapat mengakses sumber daya tanpa verifikasi.
Pengecualian MFA untuk Akun Layanan: Pengecualian menyeluruh untuk sistem lama atau kotak surat bersama menonaktifkan perlindungan inti dan menciptakan titik buta yang sangat diincar penyerang.
Celah Antar-Aplikasi: Integrasi yang keliru antaraplikasi klien dapat melewati permintaan MFA di tempat Anda justru mengharapkannya. Untuk informasi lebih lanjut tentang menutup celah Zero Trust ini, lihat panduan Zero Trust di Microsoft 365/Dynamics 365 ini.

Memecahkan Masalah Conditional Access di Aplikasi Microsoft 365, B2B, dan Platform Perangkat

Penegakan Conditional Access hanya sekuat mata rantai terlemahnya. Microsoft 365 memiliki keunikan layanannya sendiri, sign-in tamu/mitra B2B berperilaku berbeda, dan penerapan kebijakan untuk perangkat tidak selalu sesuai dengan perkiraan Anda. Nuansa-nuansa ini bisa menggagalkan kebijakan yang sudah dirancang dengan baik dan meninggalkan jejak "NotApplied".

Akun tamu, terutama yang sudah terlupakan setelah proyek mitra berakhir, adalah contoh utama. Batas kepercayaan dan siklus hidupnya tidak sama dengan pengguna internal, sehingga kebijakan bisa terlewat atau terpicu secara tidak konsisten. Perilaku khusus layanan di platform Microsoft 365, seperti Exchange Online atau SharePoint, menambah lapisan kompleksitas lain, mulai dari izin aplikasi hingga batas waktu sesi.

Lalu ada sisi perangkat: cara endpoint pengguna digabungkan, didaftarkan, atau dikelola (misalnya: hybrid Azure AD join, kepatuhan Intune, platform perangkat seluler) menentukan kebijakan mana yang akan diterapkan atau dilewati. Jika Anda ingin memahami penegakan conditional access di berbagai lingkungan secara tuntas, susun daftar periksa khusus lingkungan yang memungkinkan Anda menemukan celah secara real time, sebelum celah tersebut menyebabkan panggilan dukungan larut malam. Untuk informasi lebih lanjut tentang jebakan tata kelola terkait pengguna tamu dan tata kelola Teams, lihat strategi mengelola risiko akun tamu dan perbaikan tata kelola Teams untuk gambaran risiko yang terus berkembang.

Keunikan Layanan Microsoft 365 yang Memengaruhi Conditional Access

Tidak semua beban kerja Microsoft 365 mengikuti aturan yang sama dalam hal Conditional Access. Layanan seperti Exchange Online, SharePoint, dan Teams memiliki API, endpoint, dan logika pengelolaan sesi yang unik. Beberapa protokol atau akses aplikasi seluler tidak selalu mematuhi pengaturan CA terbaru, terutama ketika endpoint lama atau aplikasi dengan persetujuan OAuth terlibat.

Anda mungkin melihat kebijakan berstatus "NotApplied" karena aplikasi menggunakan metode autentikasi yang berbeda, seperti Exchange Online PowerShell atau SharePoint Online melalui alur lama. Hal ini dapat membuka rantai serangan melalui phishing persetujuan atau pencurian token, sehingga diperlukan remediasi yang tepat sasaran di setiap beban kerja. Untuk informasi lebih lanjut tentang vektor serangan tingkat layanan ini dan perlindungannya, lihat remediasi rantai serangan Microsoft 365.

Conditional Access untuk Kolaborasi B2B dan Pengguna Tamu

Batas Kepercayaan B2B: Organisasi asal pengguna tamu mungkin memiliki aturan keamanan sendiri, dan CA Anda tidak selalu dapat mengesampingkannya, sehingga pemicu kebijakan bisa terjadi atau tidak terjadi secara tidak menentu.
Alur Undangan vs. Sign-In: Conditional Access berlaku saat sign-in, bukan saat undangan. Jika tamu tidak pernah sign-in, kebijakan Anda tidak akan pernah dijalankan.
Pemantauan dan Peringatan: Awasi anomali sign-in tamu dengan menyiapkan peringatan dan meninjau log Entra. Langkah ini memastikan bahwa berbagi eksternal atau akses tamu yang tertinggal tidak berujung pada risiko kepatuhan.
Tinjauan dan Kedaluwarsa: Tinjauan akses secara berkala dan undangan dengan batas waktu membantu menjaga lingkungan tetap rapi dan mengurangi permukaan serangan. Untuk hasil terbaik, jalankan proses audit berkelanjutan dengan cakupan yang lebih luas, sebagaimana diuraikan dalam panduan praktis tentang kontrol berbagi eksternal ini.

Tantangan Windows dan Kepatuhan Perangkat dalam Conditional Access

Pengecualian Platform Perangkat: Kebijakan yang diterapkan pada Windows, iOS, atau Android dapat melewati pengguna sepenuhnya jika perangkatnya tidak dikenali atau berada di luar kepatuhan.
Jebakan Hybrid Azure AD Join: Perangkat yang tidak tergabung dengan benar (hybrid maupun lainnya) tidak akan lolos pemeriksaan perangkat Akses Bersyarat, sehingga penegakan kebijakan terblokir.
Celah Integrasi Intune: Kebijakan kepatuhan berbasis Intune mungkin membutuhkan waktu untuk terdaftar, sehingga muncul periode ketika penerapan kebijakan terlihat tidak konsisten.
Perangkat Tidak Patuh atau Tidak Terverifikasi: Proses masuk dari perangkat yang di-jailbreak, usang, atau tidak dikelola biasanya tidak memicu kebijakan yang dijaga perangkat. Panduan lebih lanjut tentang mengintegrasikan kepatuhan dan perlindungan ancaman tersedia di ikhtisar Microsoft 365 Defender dan Purview ini.

Mengendalikan Penumpukan dan Tumpang Tindih Kebijakan yang Membuat Akses Bersyarat Tidak Dapat Diprediksi

Di lingkungan besar, mudah sekali membuat kebijakan Akses Bersyarat secara berlebihan. Anda menginginkan cakupan yang ketat, tetapi hal itu dapat dengan cepat menghasilkan begitu banyak aturan yang tumpang tindih atau bertentangan sehingga tidak ada yang bisa memprediksi kebijakan mana yang akan diterapkan. Terlalu banyak kebijakan meningkatkan kompleksitas, menciptakan celah bayangan, dan membuat pemecahan masalah menjadi sangat merepotkan.

Penumpukan kebijakan—ketika admin yang berniat baik terus menambahkan "satu kebijakan lagi"—menimbulkan titik buta penegakan yang tersembunyi, terutama saat Anda mengandalkan penyertaan grup, pengecualian, atau lupa membersihkan kebijakan uji coba. Ketergantungan layanan memperburuk keadaan: perubahan pada satu aplikasi cloud atau integrasi baru dapat merusak rangkaian kebijakan yang sebelumnya andal.

Langkah yang tepat adalah audit dan rasionalisasi kebijakan secara berkala. Fokus pada kebijakan dasar yang inklusif dan minimalkan pengecualian berjangka waktu. Pastikan setiap kebijakan memiliki tujuan yang jelas, hasil yang terdokumentasi, dan disertai pelaporan yang dapat ditindaklanjuti. Jangan pernah menganggap lingkungan Anda "pasang dan lupakan". Untuk pendekatan memantau celah kepercayaan dan menangani Shadow IT dalam Akses Bersyarat, lihat panduan praktis masalah kepercayaan CA ini dan panduan remediasi Shadow IT.

Mengelola Ketergantungan Layanan dan Mencegah Penumpukan Kebijakan

Audit Kebijakan Saat Ini: Secara berkala, inventarisasi dan dokumentasikan semua kebijakan CA yang aktif, dan perhatikan tumpang tindih yang tidak perlu atau aturan yang sudah usang.
Petakan Layanan yang Saling Terhubung: Identifikasi ketergantungan CA di seluruh Azure, Microsoft 365, dan aplikasi pihak ketiga untuk menangkap celah penegakan yang muncul dari integrasi baru.
Konsolidasi dan Rasionalisasi: Gabungkan kebijakan serupa dan pensiunkan kebijakan lama atau yang tidak terpakai, dengan fokus pada aturan yang luas dan terdokumentasi dengan baik serta disertai pengecualian yang tertarget.
Tinjau Risiko AI/Otomasi: Jangan lupakan proses latar belakang. Agen AI dan otomasi memerlukan kontrol terbatasnya sendiri untuk memblokir risiko Shadow IT, sebagaimana dijelaskan di sini: ancaman Shadow IT dari agen AI.

Menguji Dampak Kebijakan secara Aman Menggunakan Konsekuensi "Select All" dan Pelaporan

Aktifkan Mode Hanya Laporan Terlebih Dahulu: Sebelum menerapkan, gunakan mode hanya laporan untuk menyimulasikan dampak kebijakan tanpa memblokir pengguna yang sah. Analisis efeknya menggunakan dasbor pelaporan bawaan.
Gunakan Konsekuensi "Select All" dengan Hati-hati: Terapkan semua tindakan penegakan di lingkungan uji coba yang aman untuk menemukan hasil yang tidak terduga atau pengecualian yang tidak direncanakan sebelum peluncuran penuh.
Dokumentasikan Pengguna dan Aplikasi yang Terdampak: Simpan catatan setiap pengguna, grup, dan aplikasi yang terdampak perubahan, agar Anda dapat berkomunikasi dengan pemangku kepentingan dan membatalkan langkah jika keadaan memburuk.
Kumpulkan Umpan Balik Pengguna dan Sistem: Dorong pengguna untuk segera melaporkan masalah dan periksa log kesalahan sistem untuk mengetahui penguncian akibat kebijakan.
Andalkan Log Audit untuk Respons Insiden: Gunakan Microsoft Purview Audit dan log penyewa untuk melacak aktivitas pengguna dan memverifikasi hasil kebijakan. Untuk panduan audit, lihat pembahasan mendalam tentang Purview Audit ini.

Yang Harus Dilakukan Jika Terkunci atau Kebijakan Akses Bersyarat Tidak Diterapkan

Setiap admin Conditional Access pernah mengalami mimpi buruk ini: Anda men-deploy kebijakan baru, lalu tiba-tiba Anda, atau seluruh tim Anda, terkunci dari penyewa, atau kebijakan yang Anda kira akan menyelesaikan masalah justru sama sekali tidak berfungsi. Panggilan eskalasi terus berdatangan, dan Anda menyadari bahwa Anda memerlukan strategi pemulihan yang solid hanya untuk menjaga bisnis tetap berjalan.

Kabar baiknya? Ada panduan untuk mendapatkan kembali akses dengan cepat tanpa memperburuk keadaan. Anda sebaiknya menyiapkan akun break-glass, menerapkan taktik rollback dan pengecualian, lalu melakukan eskalasi ke Microsoft Support atau tim keamanan Anda jika diperlukan.

Tapi mari kita tidak berhenti di pemulihan. Jika Anda tidak menangani akar masalahnya, Anda akan kembali terjebak dalam masalah yang sama setiap kali Anda mengubah kebijakan. Itulah sebabnya tinjauan pascainsiden, pembaruan kepada pemangku kepentingan, pengujian berkelanjutan, dan dokumentasi pembelajaran sama pentingnya dengan menekan tombol yang tepat untuk memulihkan layanan. Untuk memahami mengapa kepemilikan alat yang terfragmentasi merusak tata kelola, lihat pembahasan mendalam tentang kegagalan tata kelola ini.

Pemulihan Langkah demi Langkah Saat Conditional Access Gagal

Gunakan Akun Break-Glass: Simpan setidaknya satu akun darurat dengan hak global admin tetapi tanpa kebijakan Conditional Access yang diterapkan. Masuk dengan akun ini untuk mendapatkan kembali akses kapan saja.
Terapkan Kebijakan Pengecualian Sementara: Jika Anda terkunci, buat atau aktifkan kebijakan pengecualian untuk akun atau grup yang terdampak, sehingga Anda dapat kembali mengakses layanan secara normal dan memperbaiki akar masalahnya.
Eskalasi untuk Override Admin: Jika langkah-langkah di lini depan gagal, hubungi Microsoft Support atau tim keamanan Anda untuk intervensi langsung atau pembukaan kunci penyewa.
Rollback Perubahan Kebijakan Terbaru: Kembalikan aturan Conditional Access yang baru dibuat atau baru diubah ke konfigurasi terakhir yang diketahui berfungsi baik, lalu periksa log sign-in untuk memastikan perbaikannya berhasil.

Langkah Selanjutnya dan Tinjauan Kebijakan Efektif Setelah Mengidentifikasi Masalah Tidak Diterapkan

Dokumentasikan Pelajaran yang Dipetik: Catat dengan jelas apa yang salah, apa yang berhasil sebagai perbaikan, dan di mana kontrol atau audit di masa depan diperlukan.
Uji dalam Mode Report-Only: Sebelum mengaktifkan kembali kebijakan, gunakan mode report-only di Entra untuk memastikan Anda mendeteksi masalah tanpa menimbulkan gangguan baru.
Kumpulkan dan Terapkan Umpan Balik: Minta umpan balik dari pengguna terdampak dan log sistem, lalu gunakan wawasan tersebut untuk menutup celah yang tersisa.
Berkomunikasi dengan Pemangku Kepentingan: Perbarui semua tim terdampak, pimpinan TI, mitra eksternal, dan pengguna mengenai insiden, penyelesaian, dan rencana pencegahan jangka panjang.
Berkomitmen pada Tata Kelola Secara Berkala: Jadwalkan tinjauan, pelaporan, dan pembaruan berkelanjutan terhadap kebijakan Conditional Access Anda, karena tata kelola yang baik, seperti yang diingatkan oleh podcast tentang ilusi tata kelola ini, adalah praktik yang berkelanjutan, bukan sekadar centang kotak sekali pasang.

🎧 Anda Juga Sebaiknya Mendengarkan

Identity Governance in Microsoft Entra
Pelajari kontrol akses dan siklus hidup.
Microsoft Purview – Simply Explained
Jelajahi konteks perlindungan dan kepatuhan.
Microsoft 365 Governance Operating Model
Pahami kepemilikan dan pengambilan keputusan yang berkelanjutan.