Keamanan dan Izin Azure Lighthouse: Cara Mengelola Akses Cloud Multi-Penyewa dengan Aman

By Mirko Peters · 2026-10-21

Pelajari cara kerja keamanan Azure Lighthouse, cara menerapkan prinsip hak akses minimum lintas penyewa, dan cara pelanggan mempertahankan kendali penuh atas cloud mereka.

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

Keamanan Azure Lighthouse bertumpu pada prinsip hak akses minimum, proyeksi sumber daya logis, dan batas yang sepenuhnya dikendalikan pelanggan, sehingga penyedia layanan terkelola dapat menangani lingkungan cloud multi-penyewa tanpa perlu memegang kata sandi administrator, dengan memanfaatkan peran Azure bawaan serta jejak audit yang permanen.

Poin Penting

• Pelanggan tetap memegang kendali penuh atas penyewa Azure mereka dengan menentukan cakupan yang presisi dan peran bawaan.
• Definisi dan penetapan registrasi berfungsi sebagai jabat tangan berkelanjutan yang diverifikasi Azure pada setiap tindakan.
• Peran Owner penuh dan akses bidang data sama sekali tidak didukung dalam delegasi Azure Lighthouse.
• Penyedia beroperasi melalui proyeksi logis di portal mereka sendiri tanpa membagikan kata sandi atau kredensial pengguna.
• Log aktivitas mencatat setiap perubahan di penyewa pelanggan, memberikan jejak audit yang transparan.

Arsitektur Keamanan Azure Lighthouse

Mengelola beberapa lingkungan cloud secara tradisional mengharuskan pembuatan akun admin khusus di setiap penyewa pelanggan. Cara lama ini menimbulkan risiko keamanan besar, spreadsheet berisi kata sandi sementara yang terus bertambah, dan kredensial terlupakan yang tertinggal di sistem eksternal. Azure Lighthouse secara mendasar mengubah dinamika ini dengan menghadirkan pintu yang aman dan terikat secara kriptografis di antara dunia cloud yang terpisah.

Alih-alih menggabungkan penyewa atau membagikan kredensial, Lighthouse menggunakan proyeksi logis. Sumber daya pelanggan tetap sepenuhnya berada di dalam lingkungan cloud mereka sendiri, yaitu penyewa, langganan, dan grup sumber daya mereka. Penyedia layanan terkelola melihat sumber daya tersebut melalui gerbang aman dari penyewa manajemen mereka sendiri. Setiap permintaan yang dikirim penyedia melewati lapisan validasi inti Azure, yang terus-menerus memeriksa dokumen otorisasi sebelum mengizinkan perintah apa pun dijalankan.

Jabat Tangan Dua Bagian

Keamanan di Azure Lighthouse tidak didasarkan pada kepercayaan buta; keamanan itu ditopang oleh dua file konfigurasi berbasis JSON yang tidak dapat diubah dan diterapkan langsung oleh administrator tingkat atas pelanggan.

Bagian pertama adalah definisi registrasi. Dokumen ini berada di dalam akun pelanggan dan secara eksplisit merinci organisasi eksternal mana yang dipercaya serta peran bawaan spesifik apa yang diberikan kepadanya. Bagian kedua adalah penetapan registrasi, yang berfungsi sebagai alamat dengan mengarahkan definisi tersebut ke langganan atau grup sumber daya tertentu.

Karena komponen ini berada di penyewa pelanggan, pelanggan memegang kendali penuh. Jika kontrak berakhir, pelanggan dapat menghapus penetapan registrasi, sehingga akses langsung terkunci tanpa memerlukan kerja sama dari penyedia layanan.

Menerapkan Hak Akses Minimum di Lingkungan Multi-Penyewa

Prinsip dasar keamanan cloud modern adalah prinsip hak akses minimum, yaitu hanya memberikan pengguna dan sistem izin seminimal mungkin yang diperlukan untuk menjalankan tugas mereka. Azure Lighthouse memudahkan penerapan prinsip ini dengan memetakan izin ke grup keamanan, service principal, dan akun otomatisasi, bukan ke pengguna manusia secara individual.

Sebagai contoh, penyedia layanan terkelola dapat menyusun akses tim mereka ke dalam beberapa tingkatan yang berbeda:

• Tim Dukungan: Diberi peran Reader untuk memeriksa kondisi virtual machine dan log diagnostik tanpa melakukan perubahan.
• Insinyur Migrasi: Diberi peran Contributor pada grup sumber daya tertentu untuk menerapkan beban kerja dan memasang pembaruan.
• Skrip Otomatisasi: Diberi akun layanan kustom dengan cakupan terbatas untuk menjalankan pencadangan malam hari dan pengumpulan telemetri.

Pendekatan yang terperinci ini memastikan bahwa kesalahan manusia atau kredensial yang disusupi di sisi penyedia tidak dapat merambat menjadi kerusakan besar di seluruh lingkungan pelanggan yang dikelola.

Batasan Peran Bawaan sebagai Pagar Pengaman Keamanan

Untuk melindungi organisasi dari pemberian izin yang berlebihan, Azure Lighthouse menerapkan pagar pengaman yang ketat atas apa yang boleh dan tidak boleh didelegasikan. Yang paling menonjol, peran Owner tingkat atas sama sekali tidak didukung dalam delegasi Lighthouse. Penyedia layanan tidak akan pernah diberi kemampuan untuk menetapkan izin kepada pihak lain atau mengambil kepemilikan penuh atas langganan pelanggan.

Selain itu, peran yang memberikan akses ke data plane, seperti membaca file di dalam kontainer Azure Blob Storage atau melihat catatan database, tidak dapat didelegasikan melalui Lighthouse. Lighthouse mengelola control plane infrastruktur, sehingga pengawasan administratif tidak pernah melampaui batas dan berubah menjadi pelanggaran privasi data.

Jejak Audit dan Pelacakan Kepatuhan

Petugas kepatuhan sering kali khawatir ketika vendor eksternal mengakses infrastruktur cloud inti perusahaan. Azure Lighthouse meredakan kekhawatiran ini dengan menyimpan jejak tertulis yang rinci dan tahan manipulasi di sisi pelanggan.

Setiap tindakan yang dilakukan oleh pengguna penyedia, baik itu me-restart virtual machine, mengubah aturan firewall, maupun memperbarui pengaturan jaringan, dicatat langsung ke Azure Activity Log milik pelanggan. Karena log ini berada di penyewa pelanggan, log tersebut tidak dapat diubah atau dihapus oleh penyedia eksternal. Administrator TI dapat menjalankan audit berkala untuk menjawab pertanyaan keamanan yang krusial: Siapa yang mengakses sumber daya ini? Kapan sumber daya ini diubah? Perintah persis apa yang dijalankan?

Lebih lanjut, perusahaan dapat memadukan Azure Lighthouse dengan Privileged Identity Management (PIM) untuk mewajibkan elevasi hak akses just-in-time. Alih-alih memegang hak Contributor secara permanen, insinyur penyedia hanya dapat meminta akses ketika insiden terjadi, dengan persetujuan yang tercatat dan batas waktu yang diterapkan secara otomatis.

Kesimpulan

Azure Lighthouse menjawab ketegangan abadi antara keamanan cloud yang kuat dan pengelolaan multi-penyewa yang efisien. Dengan menggantikan praktik berbagi kata sandi dengan pengelolaan sumber daya yang didelegasikan, terverifikasi secara kriptografis, dan dikendalikan oleh pelanggan, para pemimpin TI dapat memperluas operasional mereka tanpa mengorbankan postur keamanan. Untuk memahami konsep dasar di balik arsitektur ini, pastikan Anda Dengarkan episode lengkapnya dari M365 FM Podcast untuk pembahasan manajemen cloud modern yang mudah dipahami tanpa istilah teknis yang berlebihan.

Pertanyaan Umum

Apakah penyedia Azure Lighthouse dapat melihat kata sandi organisasi saya?

Tidak. Azure Lighthouse tidak pernah menampilkan, mentransfer, atau membagikan kata sandi maupun kredensial pengguna antar-penyewa. Penyedia melakukan autentikasi menggunakan sistem identitas perusahaan mereka sendiri, sementara operasi pada sumber daya Anda dilakukan melalui proyeksi logis.

Apa yang terjadi pada akses Azure Lighthouse jika penyedia mengalami pembobolan?

Karena akses dibatasi secara ketat pada peran bawaan dan sumber daya tertentu yang didefinisikan dalam penetapan registrasi, dan tidak termasuk peran Owner, dampak kerusakannya tetap terkendali. Selain itu, pelanggan dapat langsung mencabut akses dengan menghapus penetapan registrasi dari portal mereka sendiri.

Apakah Azure Lighthouse mendukung peran RBAC kustom?

Tidak. Azure Lighthouse hanya mendukung peran Azure bawaan yang disediakan oleh Microsoft. Peran kustom yang dibuat di dalam penyewa penyedia maupun penyewa pelanggan tidak dapat digunakan dalam definisi registrasi.

Siapa yang berwenang untuk menyiapkan Azure Lighthouse di penyewa pelanggan?

Hanya pengguna dengan akses hak istimewa tinggi—khususnya akun yang memiliki izin untuk menetapkan peran di tingkat langganan atau grup sumber daya, seperti User Access Administrator atau Owner—yang dapat menerapkan templat pendaftaran dan membangun koneksi.