Arsitektur Referensi Keamanan Awan Hibrida

Arsitektur referensi keamanan cloud hibrida adalah kerangka kerja yang netral terhadap vendor, yang menggambarkan bagaimana kontrol keamanan terintegrasi di seluruh infrastruktur lokal, cloud pribadi, SaaS, dan cloud publik. Arsitektur ini digunakan untuk merencanakan implementasi, membandingkan vendor, menjelaskan desain keamanan kepada auditor, serta mengukur kemajuan menuju model Zero Trust.

Artikel ini menyajikan model referensi yang lengkap: prinsip-prinsip desain yang mendasarinya, diagram logis dan diagram penerapan, daftar komponen, enam aliran lalu lintas, batas-batas kontrol, pertimbangan desain terkait identitas, pencatatan, kapasitas, dan ketahanan, pemetaan terhadap kontrol CISA dan NIST, lima contoh penerapan, serta jalur kematangan yang dilengkapi dengan uji validasi.

Artikel ini merupakan bagian dari panduan Keamanan Awan Hibrida. Untuk gambaran umum mengenai infrastruktur lingkungan hibrida, lihat Arsitektur Awan Hibrida: Komponen dan Model Penerapan.

Prinsip-prinsip desain yang mendasari model referensi

Model acuan ini didasarkan pada empat prinsip yang diambil dari pedoman zero trust yang dikeluarkan oleh NIST dan CISA.

1. Pisahkan keputusan dari penegakan kebijakan. NIST SP 800-207 membedakan titik keputusan kebijakan (PDP), yang menentukan apakah akses diperbolehkan, dari titik penegakan kebijakan (PEP), yang mengaktifkan, memantau, atau memutus koneksi. Satu PDP, banyak PEP.
2. Jangan memberikan kepercayaan hanya berdasarkan lokasi jaringan. Berada di dalam jaringan LAN perusahaan bukanlah alasan untuk mengabaikan proses otentikasi atau pemeriksaan. NIST SP 800-215 menggambarkan hilangnya batas perimeter yang berarti sebagai ciri khas jaringan perusahaan saat ini.
3. Lindungi data berdasarkan klasifikasi, bukan lokasi. Pengendalian akan mengikuti kelas data tersebut ke mana pun data tersebut berpindah.
4. Anggaplah setiap ketergantungan dapat mengalami kegagalan. Penyedia identitas, layanan cloud, dan koneksi WAN semuanya mengalami gangguan. Arsitektur tersebut menentukan apa yang akan terjadi jika hal itu terjadi.

Panduan praktik NIST SP 1800-35, “Menerapkan Arsitektur Zero Trust”, yang diterbitkan pada Juni 2025 dengan melibatkan 24 vendor, memaparkan 19 contoh penerapan prinsip-prinsip tersebut di lingkungan on-premises dan cloud, serta merupakan referensi yang berguna untuk model ini.

Diagram arsitektur

Ada dua sudut pandang yang menggambarkan arsitektur referensi: sudut pandang logis mengenai lapisan-lapisannya dan sudut pandang implementasi mengenai lokasi di mana komponen-komponen tersebut dijalankan.

Arsitektur logis

Arsitektur logis ini memiliki tiga lapisan: lapisan kontrol terpusat, lapisan penegakan terdistribusi, dan lapisan visibilitas bersama.

Rencana kontrol menetapkan kebijakan sekali saja. Rencana penegakan menerapkan kebijakan tersebut di mana pun lalu lintas data mengalir. Rencana visibilitas mengumpulkan data telemetri dari setiap titik penegakan dan mengirimkan sinyal risiko kembali ke kebijakan.

Topologi penerapan

Tampilan penyebaran menunjukkan lokasi fisik setiap titik penegakan di kantor pusat, cabang, wilayah cloud, dan pengguna jarak jauh.

Referensi komponen

Setiap komponen memiliki peran, penempatan, dan serangkaian persyaratan khusus untuk sistem hibrida yang telah ditetapkan.

Arus lalu lintas

Enam aliran lalu lintas mencakup sebagian besar kawasan perumahan hibrida, dan masing-masing harus memiliki satu titik penegakan yang terdokumentasi serta satu titik dekripsi.

Alur 1: Pengguna kantor terhubung ke internet atau SaaS

Pengguna melakukan otentikasi melalui penyedia identitas. Lalu lintas data dikirim ke gateway lokal, yang kemudian mendekripsi data, memeriksa adanya ancaman, dan menerapkan kebijakan web serta akses, lalu meneruskan sesi yang tunduk pada ketentuan perlindungan data ke cloud vendor untuk diperiksa sesuai kebijakan yang sama. Dokumentasikan penghentian TLS dan enkripsi ulang di sepanjang jalur ini serta hindari pemeriksaan berlebihan, sesuai dengan pedoman NSA mengenai pengelolaan risiko pemeriksaan TLS.

Alur 2: Pengguna jarak jauh ke SaaS

Agen titik akhir atau kontrol peramban mengarahkan lalu lintas ke titik kehadiran cloud terdekat yang telah disetujui. Kumpulan kebijakan yang berlaku sama seperti pada Alur 1. CASB menambahkan kontrol khusus SaaS, seperti pembatasan penyewa dan DLP berbasis aktivitas.

Alur 3: Pengguna ke aplikasi pribadi

Akses dilakukan melalui ZTNA, bukan melalui VPN tingkat jaringan. Layanan akses memeriksa identitas, kondisi perangkat, dan kebijakan, kemudian menghubungkan pengguna hanya ke aplikasi yang diizinkan. Dalam implementasi, dapat digunakan broker cloud untuk pengguna jarak jauh dan gateway lokal untuk sesi di lokasi yang didukung. Pastikan penempatan broker, protokol aplikasi, visibilitas sesi, dan jalur data yang sebenarnya. Lihat ZTNA di Lokasi Sendiri untuk Aplikasi Pribadi.

Alur 4: Dari satu beban kerja ke beban kerja lainnya

Lalu lintas antar-layanan antara pusat data dan beban kerja IaaS menggunakan identitas beban kerja, TLS timbal balik, dan aturan segmentasi. Sumber kebijakan yang sama menentukan layanan mana saja yang diperbolehkan untuk berkomunikasi.

Alur 5: Data yang tersimpan di layanan cloud

Integrasi API CASB dan pemindaian DSPM memeriksa penyimpanan awan dan layanan SaaS yang disetujui untuk mendeteksi data sensitif, praktik berbagi yang berisiko, dan izin yang berlebihan, kemudian melakukan perbaikan dengan menggunakan klasifikasi yang sama yang diterapkan secara langsung. Lihat Cara Kerja DSPM dan SSE Secara Bersama-sama.

Alur 6: Agen AI dan akun layanan

Agen AI dan otomatisasi sering kali memiliki akses tingkat pengguna dan memanggil API internal melalui koneksi jangka panjang, termasuk WebSockets, yang berasal dari dalam jaringan. Berikan setiap agen identitasnya sendiri dan hak akses per aplikasi, alirkan lalu lintasnya melalui titik penegakan lokal, dan terapkan DLP pada data yang dikirimkannya ke layanan AI eksternal.

Batas-batas kendali

Batas-batas pengendalian harus ditetapkan di sekeliling apa yang harus dilindungi, bukan di sekeliling lokasi peralatan tersebut berada.

Batas yurisdiksi sering kali terabaikan. Jika lalu lintas data yang telah didekripsi, log pemeriksaan, atau salinan insiden DLP keluar dari yurisdiksi, arsitektur tersebut dapat melanggar komitmen residensi meskipun data yang disimpan tidak pernah dipindahkan. Lihat bagian “Kedaulatan Data” dalam Keamanan Awan Hibrida.

Keamanan jaringan untuk cloud hibrida

Keamanan jaringan dalam lingkungan hibrida bergeser dari melindungi perbatasan menjadi melindungi koneksi individu.

• Gantilah hubungan kepercayaan antar-situs yang bersifat datar dengan segmentasi dan akses per-aplikasi.
• Pertahankan terowongan terenkripsi (IPsec, GRE, atau interkoneksi privat) antara lokasi dan wilayah cloud, tetapi jangan menganggap keanggotaan dalam terowongan tersebut sebagai otorisasi.
• Arahkan lalu lintas secara terencana: gunakan proxy eksplisit atau berkas PAC untuk jaringan kantor yang dikelola, agen atau pengaturan peramban untuk pengguna yang berpindah-pindah, serta terowongan untuk kantor cabang.
• Tentukan komponen mana yang akan mendekripsi setiap aliran, sehingga tidak ada aliran yang didekripsi dua kali.
• Catat data di setiap titik penegakan dan lakukan korelasi secara terpusat.

NIST SP 800-215 membahas opsi-opsi ini, termasuk ZTNA, mikrosegmentasi, perimeter berbasis perangkat lunak, serta model Secure Access Service Edge (SASE) yang menggabungkan layanan jaringan dan keamanan.

Pertimbangan desain

Empat aspek desain menentukan apakah arsitektur tersebut berfungsi dengan baik dalam praktiknya: identitas, pencatatan, kapasitas, dan perilaku saat terjadi kegagalan.

Arsitektur identitas

Identitas merupakan masukan pertama dalam setiap keputusan akses, sehingga arsitektur referensi memperlakukan empat jenis identitas sebagai subjek utama.

• Pengguna tenaga kerja. Satu penyedia identitas yang tepercaya, yang terintegrasi dengan setiap penyedia layanan cloud dan aplikasi SaaS, dilengkapi dengan otentikasi multi-faktor (MFA) yang tahan terhadap serangan phishing serta akses bersyarat. Data grup dan peran harus bersumber dari satu sumber agar hak akses tidak berbeda-beda di antara berbagai lingkungan.
• Perangkat. Identitas dan kondisi perangkat (status pengelolaan, tingkat patch, enkripsi disk, perlindungan titik akhir) harus dievaluasi baik untuk pengguna di lokasi maupun pengguna jarak jauh.
• Beban kerja dan layanan. Aplikasi dan layanan saling melakukan otentikasi menggunakan identitas beban kerja dan TLS timbal balik, bukan dengan rahasia bersama atau lokasi jaringan.
• Agen AI dan otomatisasi. Setiap agen memiliki identitas tersendiri, hak akses yang terbatas, dan pemilik manusia yang bertanggung jawab, sehingga tindakannya dapat disetujui, dicatat, dan dicabut secara terpisah.

Ada dua detail desain yang mudah terlewatkan. Pertama, sesi harus dievaluasi ulang ketika konteks berubah—misalnya, ketika perangkat tidak lagi memenuhi persyaratan—bukan hanya dianggap tepercaya hingga masa berlakunya habis. Kedua, tetapkan akses darurat bagi administrator yang dapat digunakan saat penyedia identitas tidak tersedia, disertai dengan kontrol yang ketat dan sistem peringatan terkait penggunaannya.

Pencatatan dan telemetri

Pencatatan dalam arsitektur hibrida harus mendukung proses deteksi, investigasi, dan kepatuhan, sekaligus mematuhi batasan mengenai ke mana data diperbolehkan dikirim.

• Apa yang perlu dicatat. Setiap titik penegakan harus mencatat informasi mengenai pengguna, perangkat, aplikasi, atau tujuan, keputusan kebijakan, aturan yang sesuai, serta klasifikasi data yang terlibat. Gunakan kunci korelasi umum (ID pengguna, ID perangkat, ID sesi) agar peristiwa dari penegakan lokal dan di cloud dapat digabungkan.
• Di mana data tersebut dikumpulkan. Petugas pengumpul lokal di setiap lokasi utama menyimpan data peristiwa terlebih dahulu, kemudian meneruskannya ke SIEM pusat. Hal ini memastikan log tetap tersimpan selama gangguan jaringan WAN dan memungkinkan penerusan data secara selektif.
• Apa yang harus diteruskan. Teruskan metadata yang diperlukan untuk proses deteksi. Simpan bukti DLP secara lengkap beserta kutipan konten di yurisdiksi tempat bukti tersebut diperoleh, dengan akses yang dibatasi hanya bagi penyelidik yang berwenang.
• Retensi. Sesuaikan kebijakan retensi dengan persyaratan regulasi sesuai dengan kelas data dan yurisdiksi masing-masing, serta dokumentasikan hal tersebut.
• Integritas. Lindungi log dari manipulasi dan berikan peringatan jika terdapat celah, yang dapat menandakan adanya kegagalan maupun serangan.

Kapasitas dan penentuan ukuran

Titik penegakan lokal harus dirancang dengan kapasitas yang memadai untuk menangani lalu lintas yang telah didekripsi pada jam-jam puncak, yang merupakan penyebab paling umum dari masalah kinerja dalam implementasi hibrida.

• Ukur throughput puncak dan laju koneksi per lokasi, serta porsi lalu lintas yang akan didekripsi. Dekripsi TLS membutuhkan daya komputasi yang tinggi.
• Atur ukuran kluster dengan margin yang cukup untuk failover, sehingga jika satu node mengalami kegagalan, node lainnya tidak akan kelebihan beban.
• Pertimbangkan peningkatan lalu lintas terenkripsi, transfer file berukuran besar, serta sesi AI dan kolaborasi yang berlangsung lama.
• Rencanakan cara penambahan kapasitas. Perangkat virtual dan berbasis kontainer dapat diskalakan lebih cepat daripada perangkat keras khusus.
• Untuk titik kehadiran (PoP) cloud, pastikan kapasitas regional dan opsi failover dengan penyedia layanan, terutama jika ketentuan lokasi membatasi wilayah yang dapat Anda gunakan.

Ketahanan dan perilaku saat mengalami kegagalan

Arsitektur referensi tidak akan lengkap sebelum mendefinisikan apa yang terjadi jika setiap ketergantungan mengalami kegagalan.

• Layanan cloud penyedia tidak tersedia: penerapan kebijakan web dan aplikasi pribadi secara lokal tetap berlanjut menggunakan kebijakan yang tersimpan dalam cache, sementara layanan yang disediakan dari cloud—termasuk perlindungan data, remote browser isolation, kontrol keamanan AI, CASB, dan manajemen postur keamanan data—tidak diterapkan hingga koneksi pulih; pengguna jarak jauh akan dialihkan ke titik kehadiran lainnya.
• Penyedia identitas tidak tersedia: tentukan apakah sesi yang sedang berjalan akan dilanjutkan dan apakah ada opsi cadangan lokal.
• Jaringan WAN atau koneksi internet terputus: ZTNA lokal memastikan akses di lokasi ke aplikasi lokal tetap berfungsi.
• Kegagalan gateway lokal: sebuah peer dalam kluster atau titik kehadiran (PoP) di cloud akan mengambil alih sesuai dengan kebijakan yang sama.
• Fail-open atau fail-closed: tentukan berdasarkan kelas lalu lintas, dan pastikan statusnya dapat dilihat oleh tim operasi.

Lihat “Ketahanan SSE Hibrida: Failover dan Pemulihan” untuk mengetahui rencana pengujian.

Pemetaan kontrol ke CISA dan NIST

Dengan memetakan setiap komponen ke kerangka kerja yang telah diakui, arsitektur referensi tersebut menjadi bukti bagi para auditor dan daftar periksa bagi para pelaksana.

Tabel ini memetakan komponen-komponen ke dalam pilar-pilar Model Kematangan Zero Trust CISA serta ke dalam kelompok-kelompok pengendalian yang representatif dalam NIST SP 800-53 Rev. 5.

Pemetaan ini merupakan titik awal. Setiap organisasi harus memastikan kesesuaian pengendalian tersebut dengan tolok ukur dan ruang lingkup regulasi masing-masing.

Contoh penerapan

Model acuan yang sama dapat disesuaikan dengan berbagai industri dengan mengubah titik-titik penegakan, bukan dengan merancang ulang kebijakan.

Contoh 1: Bank regional

Kantor pusat dan pusat data mengoperasikan gateway SWG dan ZTNA lokal sehingga data pelanggan hanya didekripsi dan diperiksa di infrastruktur yang dikendalikan oleh bank. Lalu lintas data cabang menggunakan perangkat lokal atau terowongan ke pusat data terdekat. Staf jarak jauh menggunakan titik kehadiran (PoP) cloud yang dibatasi pada lokasi di dalam wilayah tersebut. Catatan pemeriksaan tetap berada di dalam negeri. Pola ini memenuhi persyaratan risiko TIK DORA dan persyaratan pihak ketiga bagi lembaga-lembaga Uni Eropa, sekaligus tetap memungkinkan penggunaan CASB berbasis cloud untuk layanan SaaS.

Contoh 2: Produsen dengan jaringan OT

Firewall segmentasi memisahkan jaringan OT pabrik dari jaringan IT perusahaan. Sistem OT hanya dapat mengakses tujuan pembaruan dan telemetri yang telah disetujui melalui SWG lokal. Para insinyur mengakses sistem pabrik melalui ZTNA lokal dengan pemeriksaan status perangkat. Jika jaringan WAN atau layanan cloud mengalami gangguan, akses dan pemeriksaan terhadap sistem pabrik tetap berlanjut secara lokal.

Contoh 3: Lembaga sektor publik

Jaringan yang diklasifikasikan atau terputus memerlukan komponen yang secara eksplisit didukung untuk beroperasi tanpa layanan eksternal. Jaringan yang tidak diklasifikasikan dapat menggunakan layanan cloud yang telah diberi otorisasi sesuai ketentuan untuk pekerja jarak jauh. Dokumentasikan sinkronisasi kebijakan, identitas, pembaruan, dan ketergantungan lisensi, serta pastikan pengecualian yang spesifik untuk lingkungan tertentu tetap berada di bawah pengendalian perubahan.

Contoh 4: Sistem kesehatan regional

Sistem rekam medis elektronik dan pencitraan beroperasi di pusat data sistem kesehatan. Workstation klinis di rumah sakit menggunakan gateway lokal, sehingga data pasien dalam lalu lintas web dan SaaS diperiksa di lokasi. Perangkat medis ditempatkan di zona-zona yang tersegmentasi dengan akses keluar yang sangat dibatasi. Tenaga medis yang bekerja dari jarak jauh mengakses EHR melalui broker ZTNA berbasis cloud dengan persyaratan perangkat yang dikelola, dan aturan DLP untuk informasi kesehatan yang dilindungi berlaku sama di kedua jalur tersebut, sehingga mendukung langkah-langkah pengamanan sesuai dengan Aturan Keamanan HIPAA.

Contoh 5: Perusahaan ritel global

Toko-toko menggunakan gerbang cabang kecil atau terowongan ke hub regional, dengan sistem titik penjualan (POS) yang berada dalam lingkungan data pemegang kartu yang tersegmentasi sehingga hanya dapat diakses oleh pemroses pembayaran. Aktivitas penelusuran oleh staf perusahaan dan toko dipantau di hub regional atau titik kehadiran (PoP) di cloud, dengan lalu lintas dari Eropa dibatasi hanya untuk wilayah Uni Eropa dan catatan log disimpan di dalam wilayah tersebut. Sistem toko tetap beroperasi selama gangguan jaringan WAN karena segmentasi lokal dan aturan akses tidak bergantung pada cloud. Hal ini mendukung persyaratan segmentasi dan pencatatan log sesuai PCI DSS.

Jalur pematangan dan validasi

Gunakan tahapan kematangan CISA untuk melaksanakan peluncuran secara bertahap, serta uji coba yang dapat diulang untuk membuktikan bahwa setiap tahapan berfungsi dengan baik.

Jalur jatuh tempo

Organisasi jarang menerapkan arsitektur referensi secara menyeluruh sekaligus; model CISA menggambarkan empat tahap (Tradisional, Awal, Lanjutan, dan Optimal) yang menjadi peta jalan yang berguna.

Gunakan selisih waktu antara tahap saat ini dan tahap berikutnya sebagai dasar untuk menyusun rencana bertahap.

Memvalidasi arsitektur

Kualitas suatu arsitektur ditentukan oleh seberapa baik perilakunya saat diuji; oleh karena itu, validasi setiap alur dan batas dengan pengujian yang dapat diulang.

• Kirimkan URL yang diketahui berbahaya, berkas malware uji coba, dan dokumen uji coba DLP melalui setiap titik penegakan, lalu pastikan hasilnya sama dengan jalur cloud yang tersedia. Catat perilaku yang diharapkan dari kontrol yang diterapkan melalui cloud ketika jalur tersebut terputus.
• Pastikan setiap aliran data didekripsi tepat satu kali.
• Cobalah mengakses aplikasi pribadi dari lokasi, jarak jauh, dan perangkat yang tidak dikelola, lalu pastikan hasilnya sesuai dengan yang diharapkan.
• Blokir akses dari suatu situs ke cloud vendor dan pastikan penerapan kebijakan di tingkat lokal tetap berjalan.
• Pastikan bahwa log dari setiap titik penegakan kebijakan sampai ke SIEM dan bahwa aturan residensi dipatuhi.

Bagaimana Skyhigh sesuai dengan arsitektur referensi

Skyhigh Hybrid SSE Mesh mencakup bidang kontrol (satu konsol dan mesin kebijakan dengan kebijakan yang diterapkan sebagai kode), penegakan lokal (perangkat SWG di lokasi dengan inspeksi TLS lokal dan ZTNA lokal), penegakan di cloud (SWG cloud, CASB, ZTNA, dan RBI), kontrol tingkat peramban, serta DSPM (Skyhigh Security).

Untuk perlindungan kunci inspeksi dan sandboxing di lokasi, pastikan integrasi yang didukung, versi produk, dan persyaratan penerapan dengan Skyhigh. Jangan berasumsi bahwa gateway atau layanan yang dipilih mendukung HSM.

Sumber

1. NIST. SP 800-207: Arsitektur Zero Trust (Agustus 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST. SP 800-215: Panduan untuk Lingkungan Jaringan Perusahaan yang Aman (November 2022). https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST NCCoE. SP 1800-35: Penerapan Arsitektur Zero Trust (Juni 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
4. NIST. SP 800-53 Rev. 5: Pengendalian Keamanan dan Privasi untuk Sistem Informasi dan Organisasi. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA. Model Kematangan Zero Trust, Versi 2.0. https://www.cisa.gov/zero-trust-maturity-model
6. NSA. Mengelola Risiko dari Pemeriksaan Keamanan Lapisan Transportasi (November 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. Uni Eropa. Peraturan (UE) 2022/2554 (Undang-Undang Ketahanan Operasional Digital). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
8. Departemen Kesehatan dan Layanan Kemanusiaan AS (HHS). Aturan Keamanan HIPAA. https://www.hhs.gov/hipaa/for-professionals/security/index.html
9. Dewan Standar Keamanan PCI. PCI DSS v4.0.1 (perpustakaan dokumen). https://www.pcisecuritystandards.org/document_library/
10. Skyhigh Security. “Memodernisasi Symantec Edge Secure Web Gateway Anda dengan Skyhigh Hybrid SSE Mesh” (15 Juli 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
11. Skyhigh Security. “Menerapkan Model Hybrid Kini Semakin Mudah Berkat Platform Skyhigh SSE” (3 Oktober 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html