Zero Trust di Cloud: Arsitektur, Komponen, dan Penerapan
Oleh
Adisty C. Putri
Lingkungan cloud membuat aplikasi, data, dan pengguna tidak lagi berada di satu jaringan yang mudah dibatasi. Satu organisasi dapat memakai beberapa akun cloud, layanan SaaS, container, API, server virtual, serta sistem lama di data center secara bersamaan. Fleksibilitas tersebut membantu bisnis berkembang, tetapi juga memperluas jalur akses yang harus dikendalikan.
Zero Trust di cloud adalah strategi untuk memastikan bahwa setiap akses ke aplikasi, workload, API, dan data diberikan berdasarkan identitas, konteks, kondisi perangkat, serta kebutuhan aktual. Lokasi jaringan tidak lagi digunakan sebagai satu-satunya tanda bahwa sebuah permintaan dapat dipercaya.
Artikel ini berfokus pada arsitektur dan tahapan penerapan Zero Trust dalam lingkungan cloud. Untuk definisi, prinsip dasar, dan komponen Zero Trust secara menyeluruh, baca terlebih dahulu artikel apa itu Zero Trust.
Apa yang Membedakan Zero Trust di Cloud?
Penerapan Zero Trust pada jaringan kantor biasanya dimulai dari pengguna, perangkat, dan aplikasi internal. Di cloud, ruang lingkupnya menjadi lebih luas karena identitas tidak hanya dimiliki manusia. Workload, container, service account, fungsi serverless, pipeline otomatis, dan API juga saling berkomunikasi.
Artinya, kebijakan akses harus menjawab dua jenis alur utama:
- User-to-application: pengguna mengakses dashboard, aplikasi internal, panel administrasi, atau data.
- Workload-to-workload: aplikasi, service, container, atau API saling bertukar data tanpa interaksi pengguna langsung.
Zero Trust di cloud juga harus mempertimbangkan sumber daya yang dapat dibuat dan dihentikan dengan cepat. Alamat IP, instance, atau container dapat berubah, sehingga kebijakan yang hanya bergantung pada lokasi jaringan menjadi sulit dipertahankan. Identitas workload dan atribut yang dapat diverifikasi perlu menjadi dasar keputusan.
Risiko Akses yang Perlu Dikendalikan
Sebelum menyusun kebijakan, organisasi perlu memahami risiko yang muncul dari pola penggunaan cloud. Penjelasan umum mengenai perlindungan data dan sistem dapat dibaca pada pembahasan keamanan cloud.
1. Hak Akses Terlalu Luas
Role yang terlalu permisif membuat pengguna atau service account memiliki kemampuan melebihi kebutuhannya. Jika kredensial tersebut bocor, penyerang dapat menjangkau lebih banyak sumber daya.
2. Kredensial dan Secret Tersebar
API key, token, password database, dan private key dapat tersimpan di repositori, file konfigurasi, atau pipeline. Secret yang tidak dikelola dengan baik meningkatkan risiko penyalahgunaan.
3. Workload Tidak Terinventarisasi
Tim dapat membuat instance, container, bucket, atau endpoint baru tanpa dokumentasi yang konsisten. Sumber daya yang terlupakan tetap dapat menjadi permukaan serangan.
4. Akses Antar-Lingkungan Tidak Tersegmentasi
Development, staging, dan production sering kali terhubung terlalu bebas. Insiden di lingkungan berisiko rendah kemudian dapat menjadi jalur menuju sistem yang lebih sensitif.
5. Visibilitas Terpecah
Log identitas, jaringan, aplikasi, dan cloud provider dapat berada di tempat berbeda. Tanpa korelasi, aktivitas mencurigakan sulit dikenali secara cepat.
Komponen Arsitektur Zero Trust di Cloud
1. Identity sebagai Control Plane
Identitas menjadi titik awal keputusan akses. Organisasi perlu memiliki sumber identitas yang jelas, autentikasi berlapis, lifecycle akun, serta proses pencabutan akses. Pengguna, perangkat, dan workload harus dapat dibedakan agar kebijakan tidak menggunakan satu jenis kredensial untuk semua kebutuhan.
2. Device dan Session Context
Identitas yang benar belum tentu menggunakan perangkat yang aman. Sistem perlu menilai status pembaruan, kepemilikan perangkat, konfigurasi keamanan, lokasi, waktu akses, serta perubahan perilaku. Session berisiko tinggi dapat diminta melakukan verifikasi tambahan atau ditolak.
3. Application dan Workload Identity
Setiap aplikasi atau service sebaiknya memiliki identitas terpisah dengan akses minimum. Hindari penggunaan satu akun bersama pada banyak workload. Kredensial jangka pendek dan rotasi otomatis lebih mudah dikendalikan dibanding secret statis yang digunakan tanpa batas waktu.
4. Microsegmentation
Segmentasi memisahkan aplikasi dan data berdasarkan fungsi serta sensitivitas. Tujuannya bukan sekadar membuat banyak subnet, tetapi membatasi komunikasi agar setiap service hanya dapat berhubungan dengan tujuan yang benar-benar diperlukan.
5. Data Protection
Kontrol akses harus mengikuti data. Klasifikasi data, enkripsi, pengelolaan kunci, backup, serta pembatasan ekspor perlu disesuaikan dengan tingkat sensitivitas. Data publik tidak memerlukan kebijakan yang sama dengan data pelanggan atau kredensial administrasi.
6. Telemetry dan Policy Enforcement
Keputusan akses membutuhkan data yang cukup. Log autentikasi, perubahan role, akses API, aktivitas workload, dan transfer data perlu dikumpulkan. Policy enforcement point harus mampu menolak, membatasi, atau meminta verifikasi tambahan ketika risiko berubah.
Cara Menentukan Protect Surface
Zero Trust tidak harus dimulai dengan memetakan seluruh jaringan sekaligus. Pendekatan yang lebih terukur adalah menentukan protect surface, yaitu kumpulan data, aplikasi, aset, dan service paling penting yang harus dilindungi.
- Daftar data dengan dampak terbesar jika bocor atau berubah.
- Identifikasi aplikasi yang membaca atau mengubah data tersebut.
- Petakan pengguna dan workload yang membutuhkan akses.
- Dokumentasikan alur komunikasi normal.
- Tentukan kebijakan minimum yang masih memungkinkan proses bisnis berjalan.
Hasil pemetaan ini membantu tim membangun segmentasi berdasarkan alur kerja nyata, bukan hanya berdasarkan struktur organisasi atau alamat IP.
Langkah Implementasi Zero Trust di Cloud
1. Inventarisasi Identitas, Aset, dan Alur Data
Mulai dari akun pengguna, akun administrator, service account, aplikasi, API, database, object storage, serta pipeline otomatis. Catat siapa pemiliknya, data apa yang diakses, dan hubungan antar-sistem.
2. Klasifikasikan Tingkat Risiko
Kelompokkan aset menjadi publik, internal, sensitif, dan kritis. Semakin besar dampaknya, semakin ketat autentikasi, session duration, approval, dan monitoring yang diperlukan.
3. Terapkan Least Privilege
Ganti role luas dengan role yang lebih spesifik. Pisahkan tugas administrasi, operasi, pengembangan, dan audit. Hak istimewa sebaiknya diberikan hanya ketika diperlukan dan dicabut setelah tugas selesai.
4. Pisahkan Human Identity dan Machine Identity
Jangan menggunakan akun manusia untuk proses otomatis. Setiap workload perlu memiliki identitas, scope, dan masa berlaku kredensial sendiri. Dengan begitu, pencabutan satu kredensial tidak menghentikan seluruh sistem.
5. Segmentasikan Berdasarkan Aplikasi
Batasi komunikasi antar-workload. Frontend hanya perlu mengakses API tertentu, API hanya perlu mengakses database yang relevan, dan lingkungan staging tidak perlu memiliki akses langsung ke database production.
6. Lindungi API dan Jalur Otomatisasi
API perlu autentikasi, otorisasi, rate limiting, validasi input, dan logging. Untuk lingkungan yang tersebar, gunakan strategi yang konsisten sebagaimana dibahas dalam panduan mengamankan API multi-cloud.
7. Aktifkan Monitoring Berkelanjutan
Buat baseline aktivitas normal, lalu pantau kegagalan login, perubahan role, pembuatan token, akses lintas wilayah, serta transfer data yang tidak biasa. Logging harus mendukung investigasi, bukan sekadar memenuhi checklist.
8. Uji Kebijakan Sebelum Diperluas
Terapkan pada satu aplikasi dengan risiko terukur. Uji skenario pengguna sah, pengguna tanpa izin, perangkat tidak memenuhi syarat, kredensial kedaluwarsa, dan kegagalan identity provider. Setelah stabil, perluas ke protect surface berikutnya.
Untuk lingkungan yang membutuhkan kontrol konfigurasi server, kamu dapat melihat pilihan Cloud VPS DomaiNesia. Pastikan pemilihan infrastruktur tetap disertai hardening, pembaruan, segmentasi, dan pemantauan yang sesuai.
Contoh Kebijakan Akses yang Lebih Presisi
| Sumber Daya | Subjek | Kondisi | Akses |
|---|---|---|---|
| Dashboard keuangan | Tim keuangan | MFA aktif, perangkat terkelola, jam kerja | Diizinkan |
| Database production | Administrator tertentu | Approval, session terbatas, aktivitas direkam | Diizinkan sementara |
| API pembayaran | Service checkout | Machine identity valid dan scope sesuai | Hanya endpoint tertentu |
| Object storage pelanggan | Aplikasi analitik | Read-only dan jaringan yang disetujui | Baca tanpa hapus |
| Lingkungan production | Akun developer umum | Tidak ada approval | Ditolak |
Penerapan pada Hybrid Cloud dan Multi-Cloud
Hybrid dan multi-cloud menambah tantangan karena setiap platform dapat memiliki istilah role, policy, dan logging berbeda. Solusinya bukan memaksa semua platform menjadi identik, melainkan menetapkan prinsip kontrol yang sama:
- Satu sumber identitas dan lifecycle akses yang konsisten.
- Klasifikasi data yang sama di setiap lingkungan.
- Standar minimum untuk autentikasi dan perangkat.
- Pemisahan akun atau project berdasarkan fungsi dan risiko.
- Format logging yang dapat dikorelasikan.
- Proses pengecualian yang tercatat dan memiliki batas waktu.
Artikel cloud computing dan cara kerjanya dapat membantu tim nonteknis memahami konteks infrastruktur sebelum membahas kontrol keamanan yang lebih rinci.
Kesalahan Umum yang Perlu Dihindari
- Menganggap Zero Trust sama dengan MFA. MFA penting, tetapi tidak menggantikan otorisasi, segmentasi, dan monitoring.
- Memindahkan kebijakan lama tanpa evaluasi. Role lama yang terlalu luas tetap berisiko meskipun dipindahkan ke cloud.
- Hanya mengamankan pengguna manusia. Machine identity dan service account juga perlu dikendalikan.
- Membuat terlalu banyak aturan sekaligus. Kebijakan yang rumit sulit diuji dan dapat mengganggu proses bisnis.
- Tidak menyiapkan emergency access. Tim tetap memerlukan prosedur akses darurat yang terbatas, diaudit, dan diuji.
- Mengabaikan pengalaman pengguna. Verifikasi yang tidak proporsional dapat mendorong pengguna mencari jalan pintas.
Cara Mengukur Keberhasilan
Keberhasilan Zero Trust tidak cukup dinilai dari jumlah kebijakan yang dibuat. Gunakan indikator yang menunjukkan penurunan risiko dan peningkatan kontrol, seperti:
- Persentase akun yang memakai MFA.
- Jumlah role dengan hak akses berlebihan.
- Waktu pencabutan akses setelah perubahan status pengguna.
- Persentase workload yang memiliki identitas terpisah.
- Jumlah secret statis dan usia kredensial.
- Cakupan log pada aplikasi kritis.
- Waktu deteksi dan respons terhadap akses anomali.
- Jumlah jalur komunikasi yang tidak diperlukan.
Hubungan dengan Artikel Zero Trust Lainnya
Artikel ini khusus membahas arsitektur cloud. Gunakan sumber berikut sesuai kebutuhan:
- Untuk definisi dan prinsip umum, baca panduan Zero Trust.
- Untuk memilih pendekatan keamanan, baca Zero Trust vs Traditional Security.
- Untuk tutorial perlindungan aplikasi, ikuti implementasi Zero Trust dengan Cloudflare Access.
FAQ Zero Trust di Cloud
Apakah Zero Trust hanya diperlukan untuk multi-cloud?
Tidak. Satu lingkungan cloud pun memiliki identitas, aplikasi, workload, dan data yang perlu dikendalikan. Multi-cloud hanya menambah kompleksitas penerapan.
Apakah firewall masih diperlukan?
Masih. Firewall tetap menjadi lapisan pembatas trafik, tetapi keputusan akses tidak boleh hanya bergantung pada lokasi jaringan. Identitas, konteks, dan hak akses tetap perlu diverifikasi.
Apakah semua akses harus meminta MFA setiap saat?
Tidak selalu. Frekuensi verifikasi dapat disesuaikan dengan risiko, sensitivitas sumber daya, kondisi perangkat, dan perubahan konteks. Akses berisiko tinggi membutuhkan kontrol lebih ketat.
Mana yang harus diamankan lebih dulu?
Mulai dari data dan aplikasi dengan dampak terbesar, lalu petakan identitas serta alur aksesnya. Pendekatan bertahap lebih mudah diuji daripada mencoba mengubah seluruh lingkungan sekaligus.
Bangun Zero Trust Berdasarkan Alur Akses
Zero Trust di cloud bekerja efektif ketika kebijakan mengikuti identitas dan alur akses nyata. Organisasi perlu mengetahui siapa atau apa yang mengakses sumber daya, mengapa akses dibutuhkan, kondisi apa yang harus dipenuhi, dan bagaimana aktivitas tersebut dipantau.
Mulailah dari protect surface yang kecil, terapkan least privilege, pisahkan human identity dan machine identity, lalu ukur hasilnya. Dengan proses bertahap, Zero Trust dapat berkembang menjadi arsitektur keamanan yang konsisten tanpa menghambat penggunaan cloud.
