Dua tahun OneIdP: Membangun kepercayaan nol di luar identitas

Ada satu pertanyaan yang pada akhirnya berhenti ditanyakan oleh setiap administrator TI karena mereka telah menerima bahwa pertanyaan itu tidak memiliki jawaban yang jelas.

“Mengapa saya tahu segalanya tentang perangkat ini — dan hampir tidak tahu apa pun tentang siapa yang sebenarnya duduk di depannya saat ini?”

Anda memiliki status patch, postur kepatuhan, inventaris aplikasi, dan lokasi. Anda dapat menghapusnya dari jarak jauh pada pukul 2 pagi dari ponsel Anda. Tetapi orang yang masuk pada pukul 9 pagi? Itu sebagian besar masih berupa kesepakatan lisan dan kata sandi yang mungkin digunakan kembali oleh seseorang dari tiga akun lain.

Kesenjangan itulah yang menjadi alasan OneIdP ada. Dan setelah dua tahun, berikut adalah kisah jujur ​​tentang apa yang dibutuhkan untuk menutup kesenjangan tersebut.

Dunia nyata yang dialami oleh tim IT.

Jawaban konvensional sudah mapan: beli alat IAM, pasangkan ke UEM Anda, konfigurasikan SSO di suatu tempat di antaranya. 

Vendor yang berbeda, dasbor yang berbeda, dan tempat yang berbeda bagi kebijakan Anda untuk secara diam-diam saling bertentangan begitu kasus khusus muncul.

Masalah yang lebih mendasar adalah bahwa Penggabungan skala Lingkungan TI perusahaan yang diakui tidak dibangun berdasarkan skenario yang bersih — melainkan berdasarkan pengecualian. Perangkat bersama, orientasi jarak jauh, kontraktor yang menggunakan laptop pribadi, dan tim yang tersebar di lima zona waktu, hanyalah beberapa contohnya.

Ini bukanlah kasus-kasus khusus yang perlu diatasi. Ini adalah kondisi operasional yang sebenarnya.

Namun sebagian besar strategi akses masih dirancang untuk dunia di mana setiap orang datang ke kantor yang sama, menggunakan perangkat terkelola yang sama, setiap hari. Jadi, otentikasi menjadi pengganti untuk segalanya. Otentikasi diperlakukan sebagai masalah yang sudah terpecahkan. Verifikasi kata sandi, berikan akses sesi. Selesai.

Sebagian besar keputusan akses masih dibuat hanya dengan sebagian informasi. Karena mengetahui siapa seseorang hampir tidak memberi tahu Anda apa yang mereka gunakan untuk masuk. Apakah perangkat tersebut telah diperbarui. Apakah perangkat tersebut milik organisasi. Apakah itu mesin yang terdaftar dari kuartal lalu atau laptop pribadi di lobi hotel.

Itulah kesenjangan yang ingin kami tutup.

Apa yang kami luncurkan di hari pertama — dan mengapa itu hanyalah permulaan

Saat OneIdP diluncurkan, kami membuat pilihan yang disengaja yang tidak dilakukan oleh sebagian besar tim produk. Kami meluncurkan sebuah fondasi, bukan daftar fitur.

Direktori berbasis cloud. Akses bersyarat melalui kartu akses. MFA (Multi-Factor Authentication) yang terintegrasi dalam dasbor yang sama yang sudah digunakan tim TI setiap hari. Fondasinya sengaja dibuat kokoh sebelum kaya akan fitur. 

Kartu kunci Memungkinkan tim TI untuk menetapkan kondisi akses nyata — lokasi yang disetujui, rentang IP tepercaya, jaringan Wi-Fi tertentu, dan jendela waktu tertentu. Bagi tim yang masih menggunakan kata sandi bersama dan login tanpa konteks, bahkan versi pertama pun merupakan cara kerja yang berbeda.

Tanah yang kokoh, sebelum kita mulai membangun.

Lalu terjadilah sesuatu yang memberi tahu kami bahwa fondasinya benar-benar telah kokoh. Dan dalam beberapa bulan, pelanggan tidak lagi bertanya apakah OneIdP berfungsi. Mereka sudah memikirkan langkah selanjutnya. 

• Bagaimana cara mengintegrasikan pengaturan Okta atau Entra yang sudah ada. 
• Bagaimana membuat keputusan akses yang mencerminkan kepatuhan perangkat, bukan hanya identitas. 
• Bagaimana cara agar sistem ini berfungsi untuk tim yang bekerja berdasarkan shift dan berbagi mesin selama seharian penuh.

Itulah petanya, dan kami mengikutinya.

Dua tahun membangun untuk mewujudkan kenyataan itu.

Sebagian besar alat identifikasi identitas dibangun berdasarkan asumsi.

Bahwa kredensial yang valid berarti sesi yang aman. Bahwa tim TI akan membangun kembali direktori mereka agar sesuai dengan platform baru. Bahwa seseorang dengan keahlian IAM yang mendalam akan tersedia untuk memelihara semuanya.

Asumsi-asumsi ini telah tertanam dalam manajemen akses perusahaan selama bertahun-tahun, karena, yah, tidak ada yang berhenti untuk mempertanyakannya.

Kami menanyai ketiganya.

1. Identitas saja sudah cukup untuk memberikan akses.

SSO, sebagaimana yang selalu diterapkan oleh industri, berhenti saat kredensial diverifikasi. Pengguna adalah orang yang mereka klaim. Sesi diberikan.

Yang tidak pernah ditanyakan adalah apa yang ada di balik kredensial tersebut. Apakah perangkat tersebut sudah diperbarui. Apakah permintaan tersebut berasal dari lokasi yang masuk akal. Apakah aplikasi yang diakses seharusnya dibuka di mesin tertentu pada saat itu.

Kami membangun Kebijakan Akses Diperluas (XAP) untuk menanyakan hal itu persis.

Setiap upaya login dievaluasi berdasarkan gambaran keseluruhan. Sinyal kepatuhan perangkat secara langsung dari Veltar langsung masuk ke dalam keputusan akses. Jika ada sesuatu yang tidak sesuai, akses akan dihentikan sebelum aplikasi dibuka. Tidak ada peninjauan manual. Tidak ada intervensi admin. Kebijakan ini langsung berfungsi.

Kemudian kami melihat sisi lain dari masalah yang sama.

Pada perangkat yang sudah dikenal dan dipercaya oleh OneIdP, meminta pengguna untuk mengetikkan kata sandi mereka lagi tidak memberikan manfaat apa pun. Hanya hambatan yang secara diam-diam memberi tahu orang di balik layar bahwa TI tidak mempercayai mereka. SSO yang disempurnakan pada Perangkat Terkelola menghilangkan hal itu sepenuhnya. Status kepatuhan perangkat menjadi kredensial. Pengalaman menjadi tidak terlihat — dengan cara terbaik.

2. Anda akan memulai kembali dengan identitas baru.

Setiap ajakan "beralih saja ke platform kami" memiliki titik buta yang sama.

Asumsi ini menganggap tim TI akan meninggalkan konfigurasi direktori, integrasi IdP, dan kebijakan akses yang telah mereka bangun selama bertahun-tahun, dan membangunnya kembali dari awal di dalam alat baru. Bagi tim yang mengelola 800 perangkat di dua benua, migrasi seperti itu bukanlah hal yang mudah.

Identity Federation dibangun untuk menghadapi realitas tersebut.

OneIdP bertindak sebagai lapisan kebijakan akses di atas fondasi apa pun yang sudah ada. Entra, Google Workspace, Okta, PingOne, atau pengaturan Active Directory lokal Semua pengaturan yang sudah ada sebelum tim TI saat ini — semuanya tetap di tempatnya. 

Kami melangkah lebih jauh lagi dengan SCIM Masuk dan Keluar. Saat seseorang bergabung, akses diberikan secara otomatis. Saat peran mereka berubah, akses pun beradaptasi. Saat mereka keluar, akun dihapus tanpa perlu membuat tiket atau melewatkan langkah manual. Representasi tenaga kerja di setiap aplikasi yang terhubung tetap akurat.

3. Akan selalu ada seseorang yang menjalankannya

Keputusan mengenai arsitektur adalah bagian yang mudah. ​​Namun, mengelola identitas biasanya menjadi rumit karena harus menggunakan platform tersebut sejak awal.

Kata sandi administrator lokal Ini adalah contoh bagus dari masalah yang diam-diam ada di latar belakang sampai akhirnya muncul. Kredensial identik di ratusan mesin, tidak berubah selama berbulan-bulan, karena rotasi manual adalah proyek yang tidak ada waktu untuk mengerjakannya. LAPS membuat hal itu otomatis. Rotasi terjadi sesuai jadwal. Setiap kredensial diaudit. Risiko hilang tanpa perlu tindakan apa pun.

Portal Pengguna memberi karyawan satu tempat untuk menemukan setiap aplikasi yang disetujui. Dikelola oleh TI, selalu terkini, tidak ada ambiguitas tentang apa yang disetujui. Hal semacam ini mungkin tidak mendapat pujian, tetapi secara permanen menghilangkan kategori tiket help desk tertentu.

SSO berbasis perangkat memecahkan masalah perangkat bersama yang belum terpecahkan sejak peluncuran. Setiap pengguna terdaftar pada mesin yang dikelola mendapatkan akses aplikasi mereka. Tidak perlu pendaftaran ulang antar shift. Akses mengikuti orang tersebut. Perangkat tetap siap untuk siapa pun yang akan menggunakannya selanjutnya.

Log Akses SSO memberi setiap CISO jejak audit yang mereka minta dalam tinjauan keamanan pertama mereka — secara otomatis, tanpa perlu dibuat di spreadsheet.

Tiga asumsi. Tiga keputusan yang disengaja untuk membangun secara berbeda.

Namun, keputusan di atas kertas dan keputusan dalam produksi adalah dua hal yang sangat berbeda.

Beginilah kejadian sebenarnya.

Garis waktu, jujur ​​saja

Akan sangat membantu jika kita melihat bagaimana hal ini terungkap — bukan sebagai peta jalan produk, tetapi sebagai serangkaian respons terhadap apa yang telah kita pelajari:

Beginilah tampilan OneIdP saat ini.

Saat peluncuran, pembicaraan berfokus pada membangun fondasi yang tepat. Menggabungkan kepercayaan dan identitas perangkat ke dalam lapisan kebijakan yang sama. Memastikan akses bersyarat benar-benar mencerminkan apa yang terjadi pada titik akhir secara real-time.

Saat ini, perbincangan berfokus pada apa yang dapat ditopang oleh fondasi tersebut. Integrasi yang lebih dalam, cakupan armada yang lebih luas, kebijakan akses yang menjangkau lebih jauh di seluruh infrastruktur — karena platform ini dibangun untuk mencapai hal tersebut.

Perkembangan dari fondasi hingga platform lengkap itulah yang memang ingin kami capai.

SatuIdP Saat ini, identitas, kepercayaan perangkat, dan kebijakan akses dievaluasi bersama-sama — pada setiap proses login, secara real-time, tanpa celah antara titik akhir yang Anda kelola dan akses yang Anda kendalikan. Perangkat dan orang di baliknya akhirnya berada dalam lingkup kebijakan yang sama.

Prinsip yang selalu kami pegang teguh adalah sesuatu yang terus diuji dalam pengembangan produk: “platform akses tercanggih sekalipun hanya akan berharga jika tim TI mampu menjalankannya dengan baik. Tim yang ramping yang mengelola armada terdistribusi seharusnya tidak memerlukan insinyur IAM khusus untuk menjaga agar semuanya tetap berfungsi.”

Setiap rilis selama dua tahun terakhir selalu berpegang pada prinsip itu — cukup andal untuk lingkungan yang kompleks, dan cukup mudah dioperasikan oleh orang-orang yang benar-benar berada di dalamnya.

Keseimbangan itulah yang paling kami banggakan.

Apa yang akan datang

Dua tahun bekerja sama dengan tim IT mengajarkan Anda sesuatu yang berguna: masalah yang dihadapi selalu lebih besar daripada masalah yang baru saja Anda selesaikan.

Kepercayaan perangkat memunculkan pertanyaan tentang akses jaringan. Akses jaringan memunculkan pertanyaan tentang infrastruktur. Dukungan RADIUS berbasis cloud dan akses SSH berbasis identitas adalah jawaban selanjutnya — yang sudah dalam pengerjaan, dibentuk oleh percakapan yang sama yang menghasilkan semua hal di atas. 

Cakupan hal-hal yang perlu diatur oleh akses zero trust terus meluas, dan kami bermaksud untuk berkembang seiring dengan perkembangan tersebut.

Siap untuk melihat perkembangan OneIdP saat ini?

Daftar untuk uji coba 14 hari.

Jelajahi platformnya