Apa yang dimaksud dengan Zero Trust?

Zero Trust menggantikan prinsip kepercayaan berdasarkan lokasi dengan verifikasi berkelanjutan. Jika model perimeter menganggap segala sesuatu di dalam jaringan sebagai tepercaya secara default, Zero Trust mengevaluasi setiap permintaan seolah-olah berasal dari sumber yang tidak tepercaya, terlepas dari asal sebenarnya permintaan tersebut atau izin apa yang telah diberikan kepada pengguna yang sama satu jam sebelumnya.

Tiga gagasan menjadi landasan penerapan model ini dalam praktik:

• Tidak ada kepercayaan implisit. Posisi dalam jaringan itu sendiri tidak menjamin apa pun, dan berada di dalam firewall bukanlah bukti bahwa suatu permintaan itu sah.
• Verifikasi berkelanjutan. Tingkat kepercayaan dievaluasi pada setiap permintaan, bukan ditetapkan sekali saat login dan berlaku selama sesi berlangsung.
• Prinsip hak akses minimal. Akses dibatasi hanya pada apa yang dibutuhkan oleh permintaan tertentu dan tidak melampaui batas tersebut.

Zero Trust bukanlah produk yang dapat dibeli oleh organisasi. Ini adalah strategi yang mencakup identitas, perangkat, jaringan, aplikasi, dan data, bukan sekadar teknologi yang berada di salah satu lapisan tersebut. Vendor yang mempresentasikannya sebagai produk umumnya hanya menjelaskan satu komponen dari arsitektur tersebut.

Istilah tersebut sendiri pertama kali muncul pada tahun 1994, ketika Stephen Paul Marsh menggunakannya dalam tesis doktoralnya mengenai kepercayaan komputasional di Universitas Stirling. Istilah ini mulai dikenal luas di kalangan keamanan pada tahun 2010, ketika analis Forrester, John Kindervag, menerbitkan artikel berjudul “No More Chewy Centers: Introducing the Zero Trust Model of Information Security” dan mengemukakan bahwa kepercayaan itu sendiri merupakan kerentanan. Proyek BeyondCorp milik Google, yang dimulai pada tahun 2009, merupakan salah satu implementasi berskala besar pertama.

NIST SP 800-207 menetapkan tujuh prinsip yang harus dipenuhi oleh setiap arsitektur zero-trust.

1. Semua sumber data dan layanan komputasi merupakan sumber daya. Baik basis data, aplikasi, layanan SaaS, perangkat IoT, maupun workstation pengguna semuanya memerlukan perlindungan, tanpa ada pengecualian yang diberikan berdasarkan lokasi atau tingkat kepentingan yang dianggap.
2. Seluruh komunikasi dilindungi, terlepas dari lokasi jaringan. Lalu lintas data yang melintasi jaringan internal diotentikasi dan dienkripsi sesuai standar yang sama dengan lalu lintas data yang masuk dari internet publik.
3. Akses diberikan berdasarkan setiap sesi. Tingkat kepercayaan dievaluasi khusus untuk sesi yang sedang berlangsung dan tidak berlaku untuk sesi berikutnya; oleh karena itu, keberhasilan mengakses satu sumber daya tidak menjamin akses ke sumber daya lainnya.
4. Akses ditentukan oleh kebijakan dinamis. Keputusan-keputusan tersebut mempertimbangkan identitas klien, status aplikasi, kondisi aset, serta atribut perilaku dan lingkungan, alih-alih hanya mengacu pada seperangkat aturan statis.
5. Perusahaan memantau status keamanan semua aset. Tidak ada aset yang dianggap tepercaya secara default, dan integritas perangkat terus-menerus dipantau agar dapat menjadi pertimbangan dalam pengambilan keputusan akses.
6. Otentikasi dan otorisasi bersifat dinamis dan diterapkan secara ketat sebelum akses diberikan. Verifikasi berjalan sebagai siklus berkelanjutan yang terdiri dari pemberian izin, pemindaian, penyesuaian, dan evaluasi ulang, bukan sebagai tahap tunggal di awal sesi.
7. Perusahaan tersebut mengumpulkan informasi sebanyak mungkin dan memanfaatkannya untuk meningkatkan postur. Data telemetri yang dikumpulkan dari aset, infrastruktur, dan saluran komunikasi digunakan sebagai masukan untuk kebijakan yang mengatur akses.

Sebuah kerangka kerja yang lebih ringkas, terdiri dari tiga bagian, juga tersebar luas: verifikasi secara eksplisit, anggap terjadi pelanggaran, terapkan prinsip hak akses minimal. Rumusan tersebut berasal dari Microsoft dan cukup efektif sebagai ringkasan, namun bukan itulah yang sebenarnya ditetapkan dalam SP 800-207; oleh karena itu, organisasi yang menerapkan standar NIST harus mengikuti tujuh prinsip di atas.

Setiap permintaan akses disaring dan diputuskan secara real-time, mengikuti urutan yang tetap konsisten terlepas dari siapa yang membangun tumpukan teknologi yang mendasarinya:

1. Seorang pemohon mengajukan permohonan akses ke suatu sumber daya, di mana subjek tersebut dapat berupa seseorang, akun layanan, beban kerja, atau agen AI.
2. Sinyal-sinyal dikumpulkan, termasuk identitas, status perangkat, lokasi, waktu, perilaku sebelumnya, dan informasi ancaman.
3. Mesin kebijakan mengevaluasi permintaan tersebut bertentangan dengan kebijakan organisasi dan skor risiko yang telah dihitung.
4. Sebuah keputusan telah dikeluarkan dan dilaksanakan, memberikan akses, menolaknya, atau memperketatnya dengan faktor otentikasi tambahan.
5. Sesi ini diawasi, sehingga perubahan risiko memicu penilaian ulang dan akses dapat dicabut meskipun sesi tersebut masih terbuka.

Langkah terakhir itulah yang membedakan Zero Trust dari model-model yang mendahuluinya, karena keamanan perimeter hanya mengambil satu keputusan di perbatasan dan kemudian harus menanggung konsekuensinya, sedangkan Zero Trust terus melakukan evaluasi selama sesi tersebut berlangsung.

Cara paling jelas untuk memahami perbedaannya adalah bahwa VPN memperluas batas keamanan, sedangkan Zero Trust justru menghilangkan batas tersebut sama sekali.

Ketika seorang pengguna terhubung melalui VPN konvensional, ia akan dimasukkan ke dalam jaringan perusahaan dan memperoleh akses luas di tingkat jaringan berdasarkan satu kali verifikasi yang dilakukan pada saat koneksi. Apa pun yang dapat diakses dari posisi jaringan tersebut dapat diakses oleh pengguna tersebut, serta oleh siapa pun yang berhasil mencuri kredensialnya.

Zero Trust memberikan akses ke sumber daya tertentu, bukan ke jaringan, sehingga otorisasi untuk mengakses satu aplikasi tidak berlaku untuk sumber daya lainnya. Setiap permintaan dievaluasi ulang berdasarkan kondisi risiko terkini.

Publikasi Khusus NIST 800-207, yang diterbitkan pada Agustus 2020, merupakan arsitektur acuan yang menjadi landasan bagi sebagian besar organisasi dalam membangun sistem mereka. Publikasi ini secara tegas membedakan antara komponen-komponen yang membuat dan menerapkan keputusan akses dengan sumber data yang menjadi dasar keputusan tersebut.

Tiga komponen logis utama

Mesin Kebijakan (PE). Sistem ini mengambil keputusan akses dengan mengevaluasi kebijakan perusahaan berdasarkan masukan yang dijelaskan di bawah ini, menerapkan algoritma kepercayaan, dan kemudian memberikan, menolak, atau mencabut akses.

Administrator Kebijakan (PA). Melaksanakan keputusan tersebut dengan membuka atau menutup jalur komunikasi serta menerbitkan kredensial atau token yang digunakan subjek untuk mengakses sumber daya. Bersama-sama, PE dan PA membentuk apa yang oleh NIST disebut sebagai titik keputusan kebijakan.

Titik Penegakan Kebijakan (PEP). Memfasilitasi, memantau, dan memutus koneksi antara subjek dan sumber daya, dengan berada di jalur permintaan dan menerapkan apa pun yang ditentukan oleh titik pengambilan keputusan kebijakan.

Sumber data yang menjadi masukan bagi mesin kebijakan

Berikut ini adalah sinyal-sinyal yang dievaluasi oleh mesin kebijakan, tanpa mengambil keputusan sendiri:

• Sistem pengelolaan identitas. Akun, catatan identitas, peran, atribut, dan hak akses.
• Kebijakan akses data. Aturan yang menentukan siapa saja yang boleh mengakses sumber daya mana dan dalam kondisi apa.
• Diagnostik dan mitigasi berkelanjutan. Inventaris aset dan status perangkat.
• Intelijen ancaman. Indikator internal dan eksternal terkait serangan dan kerentanan yang baru terungkap.
• Catatan aktivitas dan SIEM. Data telemetri yang dikumpulkan digunakan untuk menyempurnakan kebijakan seiring berjalannya waktu.
• Sistem kepatuhan industri. Persyaratan regulasi yang wajib diterapkan oleh perusahaan.
• PKI. Penerbitan dan validasi sertifikat untuk subjek dan sumber daya.

Tim sering kali mengaburkan batas ini selama tahap implementasi, dengan memperlakukan sistem identitas atau umpan ancaman seolah-olah sistem tersebutlah yang mengambil keputusan akses, padahal dalam model NIST, sistem-sistem tersebut hanya memberikan masukan kepada mesin kebijakan yang sebenarnya mengambil keputusan. Perbedaan ini sangat penting ketika mengevaluasi bagian mana saja dari arsitektur yang benar-benar ditangani oleh vendor.

Sebagai sebuah konsep, Zero Trust cukup sederhana: jangan percaya pada siapa pun atau menyetujui tindakan apa pun sebelum Anda memverifikasi identitas orang tersebut dan mengotorisasi permintaannya. Penerapanlah yang menjadi kendala bagi sebagian besar organisasi, karena Zero Trust mencakup identitas, jaringan, titik akhir, aplikasi, dan data secara bersamaan, dan hanya sedikit tim keamanan yang memiliki anggaran atau dukungan politik untuk menangani kelima aspek tersebut sekaligus. Hal ini menimbulkan pertanyaan praktis tentang dari mana harus memulai, dan jawabannya hampir selalu adalah identitas.

Setiap keputusan Zero Trust pada akhirnya bermuara pada satu pertanyaan, yaitu apakah subjek ini benar-benar orang yang diklaimnya dan apakah ia seharusnya memiliki akses ini saat ini. Segmentasi dan enkripsi tidak dapat menjawab pertanyaan tersebut, sedangkan penilaian kondisi perangkat hanya mempersempit cakupan tanpa menyelesaikannya, sehingga identitas menjadi satu-satunya kontrol yang mampu menyelesaikannya. Ketika identitas lemah, setiap kontrol di hilir hanya menjalankan keputusan yang didasarkan pada premis yang belum terverifikasi.

Identitas memikul beban di tiga tempat:

• Otentikasi. Memverifikasi subjek melalui metode yang tahan terhadap phishing daripada rahasia bersama yang dapat dicuri, disalahgunakan, atau dimanipulasi melalui rekayasa sosial.
• Otorisasi. Menentukan apa yang berhak diperoleh oleh subjek yang telah diverifikasi, berdasarkan peran yang diatur daripada akses yang telah terakumulasi selama bertahun-tahun seiring dengan perubahan peran.
• Penilaian berkelanjutan. Melakukan evaluasi ulang terhadap keduanya seiring dengan perubahan sinyal risiko, serta mencabut akses jika sinyal-sinyal tersebut mengharuskannya.

Ada konsekuensi yang tidak menyenangkan yang tersembunyi di balik hal ini, yaitu Anda tidak dapat menerapkan standar hak akses minimal yang belum pernah Anda tetapkan, dan Anda tidak dapat menetapkan standar hak akses minimal tanpa mengetahui siapa saja yang memiliki akses ke apa saat ini. Sebagian besar organisasi tidak dapat menjawab pertanyaan tersebut dengan pasti, itulah sebabnya tata kelola identitas sebaiknya dilakukan pada tahap awal program Zero Trust, bukan pada tahap selanjutnya.

Manajemen identitas dan akses menyediakan komponen-komponen yang menjadi landasan arsitektur Zero Trust.

Ada dua persyaratan yang cenderung paling sering diremehkan dibandingkan yang lain.

Proses otentikasi harus tahan terhadap serangan phishing. MFA yang didasarkan pada kode sandi sekali pakai Pemberitahuan yang dikirim melalui SMS atau email memang meningkatkan standar keamanan, namun tidak sepenuhnya menutup celah, karena serangan "adversary-in-the-middle" dan kampanye "MFA fatigue" cukup sering berhasil mengalahkan metode push dan OTP. FIDO2 dan kunci akses yang terikat pada perangkat mengaitkan kredensial tersebut baik ke perangkat maupun ke sumbernya; inilah mekanisme yang benar-benar menghentikan serangan, bukan sekadar memperlambatnya. RSA telah mengemukakan argumen ini jauh sebelum hal tersebut menjadi pandangan yang disepakati bersama, sebagai anggota dewan Aliansi FIDO dan wakil ketua Kelompok Kerja Enterprise.

Akses harus tetap berfungsi meskipun layanan cloud tidak berfungsi. Arsitektur yang mengarahkan setiap keputusan akses melalui mesin kebijakan cloud telah menciptakan titik kegagalan tunggal secara desain, dan ketika layanan tersebut tidak dapat diakses, tidak ada yang bisa bekerja. Bagi organisasi yang beroperasi di lingkungan on-premises, hybrid, air-gapped, atau dengan ketersediaan konstan—di mana gangguan operasional menimbulkan konsekuensi operasional, bukan sekadar ketidaknyamanan—itu adalah pertukaran yang merugikan. Zero Trust seharusnya mengurangi jumlah faktor yang berpotensi membuat organisasi offline, bukan justru memusatkannya; itulah sebabnya jalur penegakan kebijakan offline dan on-premises lah yang membuat model ini tetap bertahan di lingkungan-lingkungan tersebut.

Begitu sebuah organisasi berkomitmen pada model Zero Trust, pekerjaan sesungguhnya pun dimulai. Program ini dijalankan dalam jangka waktu bertahun-tahun, dan organisasi yang berhasil mencapainya cenderung mengatur urutan pekerjaan tersebut daripada mencoba melakukan semuanya secara bersamaan.

1. Identitas inventaris, sumber daya, dan akses saat ini. Prinsip hak akses minimal tidak dapat diterapkan jika tidak ada patokan yang diketahui, jadi mulailah dengan mengidentifikasi siapa dan apa saja yang saat ini dapat mengakses sumber daya mana saja, termasuk akun layanan, kontraktor, dan identitas mesin.

2. Perkuat otentikasi terlebih dahulu. Penerapan MFA yang tahan terhadap phishing pada jalur akses dengan nilai tertinggi memberikan pengurangan risiko terbesar per unit upaya, dan hal ini merupakan prasyarat bagi sebagian besar langkah selanjutnya.

3. Menetapkan dan menerapkan kebijakan akses. Ubah peran dan kebutuhan bisnis menjadi kebijakan yang jelas, kemudian hapus akses luas yang berlaku umum dan gantilah dengan hak akses yang memiliki cakupan tertentu dan dapat ditinjau.

4. Menambahkan konteks dalam pengambilan keputusan akses. Dengan menerapkan otentikasi berbasis risiko, permintaan berisiko rendah dapat diproses tanpa hambatan, sementara permintaan yang mencurigakan akan diminta verifikasi tambahan atau diblokir; hal ini juga merupakan cara untuk mencegah pengguna menemukan celah untuk mengelabui sistem.

5. Sumber daya segmen. Dengan membatasi apa saja yang dapat diakses oleh sesi yang telah disusupi, kita dapat membatasi dampak yang ditimbulkan pada saat—bukan “jika”, melainkan “saat”—suatu sistem kendali mengalami kegagalan.

6. Memantau, meninjau, dan mencabut. Peninjauan hak akses harus dilakukan sesuai jadwal, karena hak akses yang menumpuk tanpa ditinjau pada akhirnya akan menyebabkan penyebaran hak akses yang berlebihan—hal yang justru ingin dicegah oleh program tersebut.

Dalam hal ini, urutan lebih penting daripada kecepatan, karena segmentasi yang diterapkan tanpa identitas yang diatur di baliknya menghasilkan jaringan yang terbagi dengan baik namun tetap melindungi akun-akun yang memiliki hak istimewa berlebihan.

Organisasi tidak pernah benar-benar mencapai atau mewujudkan Zero Trust. Mereka harus terus-menerus mengevaluasi posisi keamanan mereka dan meninjau setiap keputusan akses.

Hambatan pengguna. Proses verifikasi yang terlalu ketat justru memicu munculnya solusi alternatif, penggunaan teknologi di luar pengawasan (shadow IT), dan peningkatan volume permintaan bantuan, meskipun aksesibilitas dan keamanan sebenarnya tidak harus saling bertentangan. Otentikasi berbasis risiko menyesuaikan tingkat tantangan dengan risiko yang ditimbulkan oleh setiap permintaan individu, alih-alih menerapkan hambatan yang sama bagi semua orang.

Sistem lama. Aplikasi yang dikembangkan sebelum adanya standar otentikasi modern seringkali tidak dapat beroperasi tanpa gateway, proxy, atau penggantian total, sehingga hal ini menjadi kendala terbesar dalam sebagian besar program dan aspek yang paling sering diremehkan pada tahap perencanaan.

Ketergantungan ketersediaan. Memusatkan keputusan akses pada satu layanan cloud saja akan menciptakan ketergantungan kritis baru, dan jika mesin kebijakan tidak dapat diakses, maka semua orang tidak akan bisa mengakses apa pun. Sebaiknya tanyakan langsung kepada penyedia layanan mana pun apa yang akan terjadi pada proses otentikasi jika layanan mereka mengalami gangguan.

Ruang lingkup organisasi. Karena Zero Trust mencakup tim-tim yang menangani identitas, jaringan, titik akhir, aplikasi, dan data, program yang dijalankan sepenuhnya oleh satu fungsi tertentu cenderung terhenti di batas fungsi tersebut.

Penggabungan vendor. Tidak ada satu pun produk yang benar-benar menerapkan konsep Zero Trust, sehingga vendor sebaiknya dievaluasi berdasarkan komponen arsitektur mana saja yang benar-benar mereka sediakan, dan “platform Zero Trust” sebaiknya dipandang sebagai klaim yang perlu diverifikasi, bukan sebagai kategori produk yang harus dibeli.

Penyebaran data identitas. Identitas merupakan masalah data yang terus berkembang, bukan masalah yang statis, dan hak akses bertambah lebih cepat daripada kemampuan sebagian besar tim untuk memeriksanya secara manual; pada titik inilah otomatisasi dan analitik tidak lagi bersifat opsional.

Zero Trust kini telah berkembang dari sekadar praktik terbaik menjadi suatu persyaratan di berbagai lingkungan yang diatur.

• Perintah Eksekutif 14028 mengarahkan Lembaga sipil federal AS menuju arsitektur Zero Trust.
• Model Kematangan Zero Trust CISA menyediakan kerangka kerja yang digunakan lembaga-lembaga federal untuk melaporkan tingkat kematangan mereka, yang disusun berdasarkan lima pilar: identitas, perangkat, jaringan, aplikasi dan beban kerja, serta data.
• Strategi Zero Trust Departemen Pertahanan AS menjabarkan kegiatan Zero Trust untuk komponen pertahanan.
• CMMC 2.0 menerapkan persyaratan pengendalian akses dan otentikasi multi-faktor (MFA) di seluruh basis industri pertahanan.
• DORA dan NIS2 menerapkan persyaratan pengendalian akses, ketahanan, dan kelangsungan operasional pada Layanan keuangan Uni Eropa dan infrastruktur kritis yang sejalan dengan prinsip-prinsip Zero Trust, terlepas dari apakah istilah tersebut disebutkan dalam teks atau tidak.

Identitas muncul sebagai pilar atau kelompok pengendalian dalam setiap aspek tersebut, dan inilah juga hal yang biasanya pertama kali diminta buktinya oleh auditor, sekaligus hal yang paling jarang dapat disiapkan oleh organisasi.

Persyaratan ketahanan dan arsitektur berbasis cloud saja juga saling bertentangan dalam hal-hal yang perlu dipertimbangkan sejak dini. Harapan akan kelangsungan operasional berdasarkan DORA, bersama dengan ketentuan ketersediaan konstan di sektor pertahanan dan infrastruktur kritis, sulit dipenuhi dengan menggunakan model akses yang berhenti berfungsi setiap kali layanan penyedia tidak dapat diakses.