Akses yang Didelegasikan

Berikan akses yang benar-benar dibutuhkan orang — dan tidak lebih

Ajak pengembang, serahkan penagihan ke akuntan Anda, beri klien akses hanya-baca ke situs mereka sendiri, atau izinkan tim dukungan kami memeriksa suatu masalah. Setiap pemberian akses adalah peran dengan izin yang ditentukan, terbatas pada suatu organisasi, ditegakkan di basis data, dan dicatat ke dalam log audit hanya-tambah.

Beberapa orang yang terhubung ke satu akun, masing-masing dengan izin cakupan tersendiri.
  • 94Izin terperinci
  • 12Peran bawaan
  • 8Departemen staf
  • 700.000+situs yang di-hosting di seluruh dunia

Akses adalah keanggotaan, bukan kata sandi bersama

Berbagi satu info masuk adalah penyebab terjadinya masalah pada akses akun. Di Zinn Digital®, setiap orang memiliki identitasnya sendiri, dan akses merupakan keanggotaan — pengguna, organisasi, dan peran — yang dapat Anda berikan, ubah, atau cabut secara tersendiri.

Identitas Anda sendiri, selalu

Setiap kolaborator masuk sebagai diri mereka sendiri melalui Keycloak, lapisan identitas kami. Tidak ada yang mengetikkan kata sandi Anda, tidak ada yang membagikan sesi peramban, dan menghapus seseorang hanyalah satu tindakan, bukan penggantian kata sandi serta kepanikan untuk mencari tahu siapa lagi yang mengetahuinya.

Organisasi membentuk struktur pohon

Akun bersifat hierarkis — organisasi reseller menaungi organisasi klien, dan organisasi klien menaungi situs. Keanggotaan berlaku untuk suatu organisasi dan semua yang ada di bawahnya, sehingga Anda dapat memberikan kendali atas organisasinya sendiri kepada klien agensi tanpa pernah mengekspos klien Anda yang lain.

Isolasi diberlakukan di basis data

Pemisahan tenant bukanlah filter dalam kode aplikasi yang dapat dilewati oleh suatu bug. Postgres Row-Level Security membatasi cakupan setiap kueri ke subpohon organisasi pemanggil, sehingga permintaan di luar cakupan Anda tidak menghasilkan apa pun untuk dikembalikan.

Ketiadaan tidak terlihat

Jika Anda meminta organisasi atau situs di luar cakupan Anda, API akan merespons dengan pesan 'tidak ditemukan' sederhana, bukan kesalahan izin. Kesalahan izin akan mengonfirmasi bahwa data tersebut ada; respons 'tidak ditemukan' sama sekali tidak memberi tahu apa pun kepada pihak luar.

Empat peran pelanggan, tiga puluh lima izin

Izin adalah kunci terperinci — modul ditambah tindakan, seperti sites.restart atau billing.refund — dan peran membundelnya. Empat peran mencakup struktur yang dibutuhkan tim nyata, dan masing-masing adalah data yang kami masukkan, bukan logika yang tertanam dalam kode.

Pemilik

Kontrol penuh: buat organisasi turunan, undang dan hapus anggota, ubah peran, kelola kunci API, buat, mulai ulang, bersihkan, tangguhkan, dan hapus situs, jalankan penagihan dan faktur, buat tiket, serta baca log audit. Peran yang Anda simpan untuk diri Anda sendiri.

Manajer Penagihan

Melihat organisasi, anggotanya, dan katalog paket, serta mengelola faktur, metode pembayaran, dan tagihan. Tidak memiliki akses untuk membuat, mengubah, atau menghapus satu situs pun — persis seperti yang dibutuhkan oleh akuntan eksternal.

Pengembang

Melihat dan membuat situs, memulai ulang layanan, membersihkan cache, mengelola kunci API, dan menangani tiket. Sengaja dikecualikan: penagihan, faktur, metode pembayaran, manajemen anggota, penangguhan situs, dan penghapusan situs. Kontraktor dapat membangun tanpa bisa menagih Anda atau merusak apa pun.

Hanya baca

Melihat organisasi, anggotanya, situsnya, penagihannya, katalog paket, tiket, status terjemahan, dan log audit — dan tidak dapat mengubah apa pun dari hal tersebut. Izin yang tepat untuk klien yang menginginkan visibilitas, auditor, atau pemangku kepentingan yang hanya perlu melihat.

Proses masuk yang tidak dapat diperlemah secara diam-diam oleh tim Anda

Mendelegasikan akses hanya aman jika akun yang Anda delegasikan sulit diambil alih. Autentikasi berjalan melalui Keycloak untuk setiap orang di akun, di setiap permukaan.

  • Kunci sandi dan WebAuthn untuk proses masuk yang tahan terhadap phishing, ditambah autentikasi dua faktor TOTP yang diberlakukan untuk semua orang berdasarkan kebijakan — bukan pengaturan opsional yang dapat dilewati oleh anggota tim.
  • Masuk melalui email dengan magic-link sebagai default, dengan email dan kata sandi sebagai cadangan, serta masuk melalui akun sosial menggunakan Google, Microsoft, GitHub, dan lainnya.
  • Single sign-on SAML untuk pelanggan perusahaan dan agensi, sehingga proses penambahan dan penonaktifan pengguna ditangani oleh penyedia identitas Anda, bukan secara manual.
  • Satu sesi di dasbor pelanggan, situs publik dan pusat pengetahuan, serta tiket bantuan — masuk sekali, dan cabut akses sekali.
  • Kebijakan sesi, autentikasi bertahap pada tindakan sensitif, dan daftar izin IP opsional per organisasi untuk akun yang ingin membatasi akses hanya ke jaringan yang dikenal.
  • Setiap email pendaftaran divalidasi sebelum akun dibuat, sehingga alamat yang tidak dapat dikirimi email, sekali pakai, dan berbasis peran terjaring di awal daripada nantinya menjadi anggota tanpa induk.

Saat tim kami memerlukan akses, cakupannya dibatasi dan dicatat

Pekerjaan dukungan terkadang memerlukan pemeriksaan ke bagian dalam akun Anda. Akses tersebut diatur oleh model izin yang sama seperti hal lainnya — staf cukup berada dalam organisasi staf, yang diatur ke dalam departemen-departemen dengan izin terbatas.

Departemen, bukan admin menyeluruh

Staf dikelompokkan ke dalam Dukungan, Penagihan dan Keuangan, Penyalahgunaan dan Kepercayaan-serta-Keamanan, Penjualan, Orientasi, Rekayasa dan Operasi, Pemasaran, dan Manajemen. Setiap peran memberikan modul dan tindakan tertentu, sehingga agen hanya melihat bagian konsol admin yang diperlukan oleh pekerjaannya dan bukan yang lainnya.

Batas kemampuan nyata seorang agen dukungan

Peran Agen Dukungan memberikan hak tepatnya ini: melihat pelanggan, melihat dan membalas tiket, melihat situs, memulai ulang situs, dan membersihkan cache-nya. Peran ini tidak menyertakan konfigurasi penagihan, pengembalian dana, pengeditan paket, dan pengelolaan armada. Tindakan perbaikan yang dapat dilakukan agen dibatasi oleh peran tersebut, bukan oleh niat baik.

Masuk sebagai pelanggan dikontrol dengan ketat

Izin customer.impersonate bukan bagian dari peran Manager — izin ini hanya dimiliki oleh Super Admin. Saat sebuah sesi berjalan atas nama Anda, dasbor menampilkan spanduk peniruan identitas yang persisten sehingga tidak pernah ada keraguan tentang siapa yang sedang bertindak.

Segala hal yang bersifat istimewa dicatat secara tertulis

Setiap tindakan berhak istimewa dan administratif ditambahkan ke log audit khusus penambahan yang mencatat pelaku, tindakan, target, metadata pendukung, alamat IP, dan stempel waktu — dipartisi berdasarkan waktu di lingkungan produksi. Pemilik dan anggota dengan akses hanya-baca dapat membaca log organisasi mereka sendiri.

Gerbang persetujuan untuk tindakan destruktif

Tindakan staf yang sensitif dan destruktif dapat memerlukan autentikasi bertingkat atau persetujuan dua orang sebelum dijalankan, dan departemen serta peran baru merupakan konfigurasi alih-alih perubahan kode.

Mesin juga mendapatkan akses yang didelegasikan

Skrip, pipeline CI, CLI, penyedia Terraform, dan agen AI semuanya diautentikasi melalui model izin yang sama seperti manusia — tidak ada kredensial manusia yang dibagikan, tidak ada rahasia jangka panjang yang ditempelkan ke dalam build.

Kunci API berlaku per organisasi dan memiliki cakupan terbatas

Kunci adalah milik organisasi dan membawa cakupan terperinci yang terikat pada izin RBAC yang sama — hanya-baca, penagihan, penyediaan. Berikan pipeline cakupan terbatas yang dibutuhkannya daripada seluruh akun anggota.

Kunci sandbox terpisah dari produksi

Kunci mode uji dan mode langsung berbeda, sehingga integrasi yang sedang dikembangkan tidak dapat mengakses data produksi secara tidak sengaja atau melalui variabel lingkungan yang disalin.

Hanya hash yang disimpan

Kami menyimpan hash SHA-256 dari rahasia dan awalan pencarian — tidak pernah kunci mentah. Anda melihat kunci sekali saja saat pembuatan. Setiap kunci melacak kapan terakhir kali digunakan dan dapat dicabut secara terpisah tanpa mengganggu hal lainnya.

Alat AI terhubung berdasarkan izin Anda

Server MCP kami memungkinkan agen berkemampuan MCP mana pun mengelola hosting Anda dalam bahasa alami, diautentikasi dengan OAuth 2.1 dan dicakupkan pada organisasi serta peran RBAC Anda, dengan token yang dapat dicabut per alat, konfirmasi untuk tindakan destruktif, batas pengeluaran, dan pencatatan audit lengkap.

Akses ke situs itu sendiri

Akses akun dan akses server adalah masalah yang berbeda. Kredensial tingkat situs dikelola di dasbor, diterbitkan dengan hak istimewa paling minimal, dan diisolasi agar shell milik satu kolaborator adalah shell untuk satu situs.

  • SSH dengan jailed shell, plus SFTP dan FTP — isolasi CageFS memastikan setiap pengguna hanya melihat berkas milik mereka sendiri.
  • wp-cli dari terminal panel dan melalui SSH, untuk operasi yang benar-benar ingin diskripkan oleh para pengembang.
  • Editor VS Code lengkap di browser melalui code-server, dengan git, mengedit file situs langsung di dasbor.
  • phpMyAdmin dan Adminer tersemat untuk basis data, serta pengelola file tersemat, keduanya menggunakan akses sekali masuk (single sign-on) langsung dari dasbor alih-alih memerlukan kredensial sekunder.
  • Kunci akses dan kredensial dibuat, dicantumkan, dirotasi, dan dicabut di dasbor, diterbitkan dengan hak istimewa paling rendah, dan penggunaannya dicatat dalam log audit.
  • Staging dengan kloning dan push-to-live menjauhkan pekerjaan berisiko dari lingkungan produksi, sehingga perubahan pertama dari kolaborator baru tidak akan pernah langsung diterapkan pada situs aktif.

Cara menyusun struktur akses sesuai dengan cara kerja Anda yang sebenarnya

Seorang operator tunggal mempertahankan satu organisasi dan satu keanggotaan pemilik, lalu menambahkan peran Pengembang ketika kontraktor masuk untuk sebuah proyek. Saat proyek berakhir, keanggotaan dihapus dan akses masuk mereka langsung berhenti berfungsi — tidak ada kredensial bersama yang tertinggal untuk dirotasi.

Sebuah agensi menggunakan bagan organisasi. Setiap klien mendapatkan organisasi turunannya sendiri, yang memuat situs web klien tersebut, dan staf klien itu sendiri mendapatkan keanggotaan di sana — hanya-baca bagi pemangku kepentingan yang menginginkan visibilitas, pemilik bagi klien yang ingin mengelola sendiri. Staf Anda memiliki keanggotaan di posisi yang lebih tinggi dalam bagan dan melihat portofolio; klien hanya melihat cabang mereka sendiri, dan Row-Level Security adalah hal yang menjadikannya kenyataan dan bukan sekadar janji.

Reseller bekerja dengan cara yang sama, satu tingkat lebih tinggi: organisasi reseller menaungi organisasi klien, masing-masing dengan anggota, tampilan penagihan, dan situsnya sendiri. Primitif yang sama mendukung sub-akun, tim agensi, dan hierarki reseller — tidak ada mekanisme terpisah yang lebih lemah untuk salah satu dari mereka.

Semua fitur tersedia pada uji coba 14 hari tanpa kartu kredit. Daftar tanpa rincian pembayaran, undang rekan kerja, amati apa saja yang dapat dan tidak dapat diakses oleh setiap peran, serta tinjau kembali log audit Anda.

Pertanyaan yang Sering Diajukan

Bisakah saya memberikan akses hanya ke satu situs kepada seseorang?

Saat ini, keanggotaan memberikan perannya di seluruh organisasi dan semua yang ada di bawahnya dalam struktur pohon, sehingga cara untuk memisahkan kumpulan situs adalah dengan memisahkan organisasi — tempatkan situs-situs tersebut di organisasi turunan mereka sendiri dan berikan keanggotaan di sana. Ini adalah model yang rapi bagi agensi dan reseller, di mana setiap klien sudah menginginkan batasannya sendiri. Cakupan sumber daya per keanggotaan, yaitu menyematkan satu keanggotaan ke situs tertentu dalam satu organisasi, merupakan penyempurnaan yang direncanakan dan bukan sesuatu yang tersedia saat ini.

Bisakah pengembang yang saya undang menghapus situs atau menerapkannya ke produksi langsung?

Peran Developer tidak mencakup penghapusan situs atau penangguhan situs — kunci tersebut milik peran Owner. Peran ini memberikan izin untuk melihat dan membuat situs, memulai ulang layanan, membersihkan cache, mengelola kunci API, serta menangani tiket. Izin penerapan (deployment) dan push-to-live juga bukan bagian dari pemberian peran Developer, sehingga proses rilis ke produksi tetap berada di tangan pemilik akun. Padukan hal tersebut dengan staging agar pekerjaan build dilakukan di luar situs live sejak awal.

Apa yang dapat dilihat oleh staf Zinn Digital® di akun saya?

Hal ini sepenuhnya bergantung pada peran staf, dan setiap peran merupakan serangkaian kunci izin yang terbatas. Agen Dukungan, misalnya, dapat melihat akun dan situs Anda, melihat serta membalas tiket Anda, memulai ulang situs, dan membersihkan cache-nya — serta tidak dapat menyentuh konfigurasi penagihan, pengembalian dana, paket, atau armada. Masuk sebagai pelanggan adalah izin terpisah yang hanya dimiliki oleh Super Admin, dan ketika hal itu terjadi, dasbor akan menampilkan banner peniruan identitas yang persisten. Setiap tindakan berhak istimewa dicatat dalam log audit beserta pelaku, tindakan, target, IP, dan stempel waktu, dan Anda dapat membaca log organisasi Anda sendiri.

Bagaimana cara mencabut akses dengan cepat jika seseorang keluar?

Hapus keanggotaan maka akses mereka ke organisasi tersebut akan berakhir — mereka tetap memiliki identitas sendiri, tetapi tanpa peran dan oleh karena itu tidak memiliki izin di akun Anda. Kunci API dicabut satu per satu, sehingga kunci pipeline dapat diputus tanpa mengganggu hal lainnya. Jika Anda menggunakan sistem masuk tunggal (single sign-on) SAML, pembatalan penyediaan di penyedia identitas Anda akan menangani proses masuk secara terpusat. Kredensial tingkat situs seperti kunci SSH dicabut di dasbor, dan penghapusan itu sendiri dicatat dalam audit.

Apakah anggota tim membagikan kunci API saya?

Tidak — tetapi penting untuk memperjelas alasannya. Kunci API adalah milik organisasi, bukan milik anggota individu, dan kunci tersebut membawa cakupan terperinci masing-masing yang terikat pada katalog izin yang sama. Jadi, alih-alih memberikan kunci kepada seseorang, Anda membuat kunci untuk pekerjaan yang dilakukannya dengan cakupan tersempit yang dibutuhkan pekerjaan tersebut, lalu mencabut kunci tersebut saat pekerjaan selesai. Hanya hash dari rahasia yang disimpan, dan setiap kunci mencatat kapan terakhir kali digunakan sehingga kunci yang tidak terpakai mudah ditemukan dan dinonaktifkan.

Dapatkah saya menghubungkan agen AI tanpa memberikannya kunci ke semuanya?

Ya. Server MCP kami mengautentikasi agen dengan OAuth 2.1 dan membatasi cakupannya ke organisasi Anda dan peran RBAC Anda, dengan token yang dapat dicabut per alat, sehingga Anda memberikan kemampuan khusus alih-alih akses menyeluruh. Tindakan yang merusak memerlukan konfirmasi, batas pengeluaran berlaku, dan setiap tindakan masuk ke log audit yang sama dengan aktivitas manusia.

Apa yang mencegah satu penyewa mengakses data penyewa lain?

Postgres Row-Level Security membatasi cakupan kueri ke subhierarki organisasi pemanggil di dalam basis data itu sendiri, dengan filter tingkat aplikasi sebagai pertahanan berlapis alih-alih satu-satunya benteng pertahanan. Permintaan untuk data di luar cakupan menghasilkan respons tidak ditemukan dan bukan kesalahan izin, sehingga keberadaan data tidak akan terungkap. Di sisi server, isolasi per situs melalui CageFS membatasi shell dan berkas setiap penyewa hanya pada situs mereka sendiri.

Dapatkah saya mencoba ini sebelum membayar?

Ya. Uji coba 14 hari tidak memerlukan kartu — tanpa rincian pembayaran, tanpa komitmen — dan mencakup hosting Footprint-Free hingga lima situs. Ini cukup untuk mengundang rekan kerja, menetapkan peran, dan memastikan batasan berfungsi sesuai kebutuhan Anda sebelum berkomitmen.

Delegasikan dengan batasan yang dapat Anda tunjuk

Mulai dengan uji coba 14 hari tanpa kartu kredit, undang seseorang, dan saksikan model izin bekerja sebagaimana mestinya — peran yang dapat Anda beri nama, cakupan yang dapat Anda cabut, serta log audit yang mencatat secara tepat siapa melakukan apa.

Mulai gratis