Akses Pendelegasian

Berikan akses yang tepat kepada orang-orang sesuai kebutuhan mereka — dan tidak lebih dari itu

Bawa pengembang, serahkan penagihan ke akuntan Anda, berikan klien akses baca-saja ke situs mereka sendiri, atau biarkan tim dukungan kami melihat suatu masalah. Setiap pemberian akses adalah peran dengan izin yang ditentukan, dicakup ke organisasi, diberlakukan dalam basis data, dan dicatat ke dalam log audit khusus tambah.

  • 94izin terperinci
  • 12peran bawaan
  • 8departemen staf
  • 650.000+situs dihosting di seluruh dunia

Access adalah keanggotaan, bukan kata sandi bersama

Berbagi satu login adalah awal mula masalah akses akun. Di Zinn Digital®, setiap orang memiliki identitas mereka sendiri, dan akses adalah sebuah keanggotaan — pengguna, organisasi, dan peran — yang dapat Anda berikan, ubah, atau cabut secara mandiri.

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 berbagi sesi peramban, dan menghapus seseorang cukup dilakukan dengan satu tindakan alih-alih merotasi kata sandi serta kebingungan mencari tahu siapa lagi yang mengetahuinya.

Organisasi membentuk struktur hierarki

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

Isolasi ditegakkan dalam database

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

Absence tidak terlihat

Minta organisasi atau situs di luar cakupan Anda dan API akan menjawab dengan kesalahan tidak ditemukan yang sederhana alih-alih kesalahan izin. Kesalahan izin akan mengonfirmasi bahwa catatan tersebut ada; tidak ditemukan sama sekali tidak memberi tahu pihak luar.

Empat peran pelanggan, tiga puluh lima izin

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

Pemilik

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

Manajer Penagihan

Melihat organisasi, para anggotanya, serta katalog paket, dan mengelola tagihan, metode pembayaran, serta biaya. Tidak memiliki akses untuk membuat, mengubah, atau menghapus satu situs pun — persis seperti peran yang seharusnya dimiliki oleh seorang pemegang buku eksternal.

Pengembang

Melihat dan membuat situs, me-restart layanan, membersihkan cache, mengelola kunci API, dan menangani tiket. Sengaja dikecualikan: penagihan, faktur, metode pembayaran, pengelolaan anggota, penangguhan situs, dan penghapusan situs. Kontraktor dapat membangun tanpa dapat menagih Anda atau menghancurkan apa pun.

Hanya-baca

Melihat organisasi, para anggotanya, situs-situsnya, penagihannya, katalog paket, tiket, status terjemahan, dan log audit — serta tidak dapat mengubah apa pun darinya. Hak akses yang tepat untuk klien yang menginginkan visibilitas, auditor, atau pemangku kepentingan yang hanya perlu melihat.

Masuk agar tim Anda tidak dapat diam-diam melemahkannya

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

  • Passkeys dan WebAuthn untuk login yang tahan phishing, ditambah autentikasi dua faktor TOTP yang diberlakukan untuk semua orang berdasarkan kebijakan — bukan pengaturan opsional yang dapat dilewati oleh anggota tim.
  • Masuk email magic-link sebagai default, dengan email dan kata sandi sebagai cadangan, serta masuk sosial melalui Google, Microsoft, GitHub, dan lainnya.
  • Masuk tunggal SAML untuk pelanggan perusahaan dan agensi, sehingga karyawan baru dan yang keluar dikelola oleh penyedia identitas Anda alih-alih secara manual.
  • Satu sesi di seluruh dasbor pelanggan, situs publik dan basis pengetahuan, serta tiket dukungan — masuk sekali, dan cabut akses sekali.
  • Kebijakan sesi, autentikasi bertingkat pada tindakan sensitif, dan daftar izin IP opsional per organisasi untuk akun yang ingin aksesnya terikat pada jaringan yang dikenal.
  • Setiap email pendaftaran divalidasi sebelum akun dibuat, sehingga alamat yang tidak dapat dikirimkan, sekali pakai, dan peran dapat dicegah sejak awal daripada menjadi anggota terbengkalai di kemudian hari.

Saat tim kami memerlukan akses, akses tersebut dibatasi dan dicatat

Pekerjaan dukungan terkadang berarti melihat ke dalam akun Anda. Akses tersebut diatur oleh model izin yang sama seperti halnya yang lain — staf cukup berada dalam organisasi staf, yang diatur ke dalam departemen dengan izin akses yang terbatas.

Departemen, bukan admin umum

Staf dikelompokkan ke dalam Support, Billing and Finance, Abuse and Trust-and-Safety, Sales, Onboarding, Engineering and Ops, Marketing, dan Management. Setiap peran memberikan modul dan tindakan tertentu, sehingga agen hanya melihat bagian konsol admin yang diperlukan oleh pekerjaannya dan tidak yang lain.

Batas kemampuan sebenarnya dari seorang agen dukungan

Peran Support Agent memberikan tepat hal ini: melihat pelanggan, melihat dan membalas tiket, melihat situs, me হোur ulang situs, dan membersihkan cache-nya. Peran ini tidak memiliki konfigurasi penagihan, pengembalian dana, pengeditan paket, dan manajemen armada. Perbaikan yang dapat dilakukan oleh seorang agen dibatasi oleh peran tersebut, bukan oleh niat baik.

Masuk sebagai pelanggan dijaga ketat

Izin customer.impersonate bukan bagian dari peran Manager — izin tersebut hanya dimiliki oleh Super Admin. Saat sesi berjalan atas nama Anda, dasbor menampilkan spanduk peniruan identitas permanen sehingga selalu jelas siapa yang bertindak.

Semua yang berhak istimewa dicatat

Setiap tindakan 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 baca-saja dapat membaca log organisasi mereka sendiri.

Gerbang persetujuan untuk pekerjaan destruktif

Tindakan staf yang sensitif dan merusak mungkin memerlukan autentikasi tingkat lanjut 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 melakukan autentikasi melalui model izin yang sama seperti manusia — tanpa kredensial manusia bersama, tanpa rahasia berumur panjang yang ditempel ke dalam build.

Kunci API bersifat per organisasi dan memiliki cakupan

Kunci milik organisasi dan memiliki cakupan terperinci yang terikat pada izin RBAC yang sama — hanya-baca, penagihan, penyediaan. Berikan cakupan sempit yang dibutuhkannya kepada alur alih-alih seluruh akun anggota.

Kunci sandbox terpisah dari produksi

Kunci mode uji dan mode langsung bersifat terpisah, 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 secret dan lookup prefix — tidak pernah raw key-nya. Anda hanya dapat melihat key satu kali saat pembuatan. Setiap key melacak kapan terakhir kali digunakan dan dapat dicabut secara mandiri tanpa memengaruhi hal lainnya.

Alat AI terhubung di bawah izin Anda

Server MCP kami memungkinkan agen yang kompatibel dengan MCP untuk mengelola hosting Anda dalam bahasa alami, diautentikasi dengan OAuth 2.1 dan dibatasi untuk organisasi serta peran RBAC Anda, dengan token yang dapat dicabut per alat, konfirmasi untuk tindakan destruktif, batasan anggaran, dan pencatatan audit penuh.

Akses ke situs itu sendiri

Akses akun dan akses server adalah dua masalah yang berbeda. Kredensial tingkat situs dikelola di dasbor, diterbitkan dengan hak istimewa terendah, dan diisolasi agar shell satu kolaborator hanya menjadi shell satu situs.

  • SSH dengan *jailed shell*, ditambah SFTP dan FTP — isolasi CageFS berarti setiap *tenant* hanya melihat file mereka sendiri.
  • wp-cli dari terminal panel dan melalui SSH, untuk operasi yang benar-benar ingin diskripkan oleh pengembang.
  • Editor VS Code lengkap di browser melalui code-server — ekstensi, terminal terintegrasi, dan git, untuk mengedit file situs secara langsung di dasbor.
  • phpMyAdmin dan Adminer tersemat untuk database, serta pengelola file tersemat, keduanya menggunakan akses tunggal (single-sign-on) dari dasbor alih-alih dilindungi di balik kumpulan kredensial kedua.
  • Kunci akses dan kredensial dibuat, dicantumkan, dirotasi, dan dicabut di dasbor, diterbitkan dengan hak istimewa terendah, dan penggunaannya dicatat dalam log audit.
  • Staging dengan clone dan push-to-live menjauhkan pekerjaan berisiko dari produksi, sehingga perubahan pertama kolaborator baru tidak akan pernah langsung tayang di situs live.

Cara menstrukturkan akses sesuai dengan cara kerja Anda sebenarnya

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

Sebuah agensi menggunakan pohon organisasi. Setiap klien mendapatkan organisasi turunannya sendiri yang menampung situs klien tersebut, dan orang-orang klien itu sendiri mendapatkan keanggotaan di sana — akses lihat saja untuk pemangku kepentingan yang menginginkan visibilitas, atau pemilik untuk klien yang ingin mengelola sendiri. Staf Anda memiliki keanggotaan yang lebih tinggi di pohon tersebut dan dapat melihat portofolio; klien hanya melihat cabang mereka sendiri, dan Keamanan Tingkat Baris adalah hal yang membuat hal tersebut menjadi nyata, bukan sekadar janji.

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

Semuanya tersedia dalam uji coba 14 hari bebas kartu. Daftar tanpa detail pembayaran, undang rekan kerja, lihat apa yang dapat dan tidak dapat diakses oleh setiap peran, dan baca kembali log audit Anda sendiri.

FAQ

Bisakah saya memberi seseorang akses ke satu situs saja?

Saat ini keanggotaan memberikan perannya di seluruh organisasi dan semua hal di bawahnya dalam struktur hierarki, jadi cara untuk memisahkan kumpulan situs adalah dengan memisahkan organisasi — tempatkan situs-situs tersebut di organisasi anak mereka sendiri dan berikan keanggotaan di sana. Ini adalah model yang bersih bagi agensi dan reseller, di mana setiap klien sudah menginginkan batas mereka sendiri. Cakupan sumber daya per-keanggotaan, menyematkan satu keanggotaan ke situs tertentu dalam satu organisasi, adalah penyempurnaan yang direncanakan alih-alih sesuatu yang tersedia saat ini.

Dapatkah pengembang yang saya undang menghapus situs atau mendorong ke langsung?

Peran Pengembang tidak memiliki hak penghapusan situs atau penangguhan situs — kunci tersebut merupakan milik peran Pemilik. Peran ini memberikan izin untuk melihat dan membuat situs, memulai ulang layanan, membersihkan tembolok, mengelola kunci API, dan menangani tiket. Izin penerapan dan dorong ke langsung juga bukan bagian dari hak istimewa Pengembang, sehingga promosi ke produksi tetap berada di tangan pemilik akun. Padukan hal tersebut dengan penahapan agar pekerjaan pembangunan dilakukan di luar situs langsung sejak awal.

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

Itu sepenuhnya bergantung pada peran staf, dan setiap peran adalah serangkaian kunci izin yang terbatas. Agen Dukungan, misalnya, dapat melihat akun dan situs Anda, melihat dan membalas tiket Anda, memulai ulang situs, serta menghapus singgahannya — dan tidak dapat mengubah konfigurasi penagihan, pengembalian dana, paket, atau armada. Masuk sebagai pelanggan adalah izin terpisah yang hanya dimiliki oleh Super Admin, dan saat itu terjadi, dasbor akan menampilkan banner penyamaran secara terus-menerus. Setiap tindakan istimewa dicatat dalam log audit beserta pelaku, tindakan, target, IP, dan stempel waktu, serta Anda dapat membaca log organisasi Anda sendiri.

Bagaimana cara mencabut akses dengan cepat jika seseorang keluar?

Hapus keanggotaan dan akses mereka ke organisasi tersebut akan berakhir — mereka tetap memiliki identitas mereka sendiri, tetapi tidak memiliki peran dan oleh karena itu tidak memiliki izin di akun Anda. Kunci API dicabut secara individual, sehingga kunci *pipeline* dapat diputus tanpa mengganggu hal lainnya. Jika Anda menggunakan masuk tunggal (SSO) SAML, pencabutan ketentuan (*deprovisioning*) di penyedia identitas Anda akan mengelola proses masuk secara terpusat. Kredensial tingkat situs seperti kunci SSH dicabut di dasbor, dan proses penghapusan itu sendiri dicatat dalam audit.

Apakah anggota tim membagikan kunci API saya?

Tidak — tetapi ada baiknya kita memperjelas alasannya. Kunci API adalah milik organisasi, bukan anggota perorangan, dan kunci tersebut memiliki cakupan terperinci tersendiri yang terikat pada katalog izin yang sama. Jadi, alih-alih memberikan kunci kepada seseorang, Anda membuat kunci untuk tugas yang dikerjakan dengan cakupan sempit yang diperlukan oleh tugas tersebut, lalu mencabut kunci itu saat tugas selesai. Hanya hash dari rahasia tersebut yang disimpan, dan setiap kunci mencatat kapan terakhir kali digunakan sehingga kunci yang tidak digunakan mudah ditemukan dan dinonaktifkan.

Bisakah saya menghubungkan agen AI tanpa memberikan akses penuh ke semuanya?

Ya. Server MCP kami mengautentikasi agen dengan OAuth 2.1 dan membatasinya pada organisasi Anda serta peran RBAC Anda, dengan token yang dapat dicabut per alat, sehingga Anda memberikan kemampuan tertentu alih-alih akses menyeluruh. Tindakan destruktif memerlukan konfirmasi, batasan anggaran berlaku, dan setiap tindakan masuk ke dalam log audit yang sama seperti aktivitas manusia.

Apa yang mencegah satu penyewa mengakses data penyewa lain?

Keamanan Tingkat Baris Postgres membatasi kueri ke subpohon organisasi pemanggil di dalam database itu sendiri, dengan filter tingkat aplikasi sebagai pertahanan berlapis, bukan satu-satunya garis pertahanan. Permintaan untuk catatan di luar cakupan akan mengembalikan status tidak ditemukan alih-alih error izin, sehingga tidak ada informasi yang terungkap tentang apa yang ada. Di sisi server, isolasi per situs melalui CageFS menjaga agar shell dan file setiap penyewa tetap berada di situs mereka sendiri.

Bisakah saya mencobanya sebelum membayar?

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

Delegasikan dengan batas yang dapat Anda tunjuk

Mulai uji coba 14 hari bebas kartu, undang seseorang, dan saksikan model izin bekerja — peran yang dapat Anda beri nama, ruang lingkup yang dapat Anda cabut, dan log audit yang menunjukkan secara tepat siapa yang melakukan apa.

Mulai gratis