Bayangkan hari pertama kerja di sebuah perusahaan besar. Untuk absen, Anda pakai satu aplikasi dengan email kantor. Untuk mengajukan reimbursement (klaim penggantian biaya), aplikasi lain, dengan akun terpisah. Dan untuk membuka sistem keuangan inti yang sudah berjalan sejak sebelum sebagian karyawan baru lahir, Anda diberi selembar kertas berisi username dan password yang wajib diganti manual setiap tiga bulan.

Tim IT, singkatan dari information technology, unit yang mengurus semua sistem dan aplikasi kantor, tahu ini berantakan. Solusinya, di atas kertas, terdengar sederhana: satu pintu masuk untuk semua aplikasi, yang dikenal sebagai single sign-on, disingkat SSO. Login sekali, semua aplikasi terbuka, satu kata sandi yang perlu diingat, satu tempat untuk mematikan akses begitu karyawan resign (berhenti kerja). Tapi kalau sesederhana itu, kenapa hampir semua perusahaan besar yang masih mengandalkan server milik sendiri, bukan disewa dari penyedia cloud seperti Amazon atau Microsoft (kondisi yang disebut on-premise), tetap berkutat dengan puluhan sistem login terpisah, bertahun-tahun setelah SSO jadi standar industri?

Jawabannya ada pada satu kata yang sering diremehkan orang di luar IT: legacy, istilah untuk aplikasi lama yang masih dipakai karena menggantinya berarti mengganti proses bisnis yang sudah berjalan puluhan tahun. Risiko mengganti aplikasi jauh lebih besar daripada risiko login yang berantakan. Jadi aplikasi itu tetap dipakai, dan ikut terbawa juga cara lamanya memverifikasi identitas pengguna.

Aplikasi lama bicara bahasa yang berbeda-beda

Sistem modern biasanya bicara dalam dua bahasa yang sudah jadi standar. Yang pertama SAML, kependekan dari Security Assertion Markup Language. Yang kedua OIDC, kependekan dari OpenID Connect. Keduanya adalah protokol, semacam aturan main baku yang disepakati banyak pihak, yang memungkinkan satu aplikasi memverifikasi identitas seseorang lewat satu pusat, tanpa perlu menyimpan password orang itu sendiri. Masalahnya, aplikasi yang dibangun 10, 15, bahkan 20 tahun lalu tidak mengenal bahasa itu sama sekali, karena aturan main ini belum ada waktu aplikasi tersebut dibuat.

Ada aplikasi yang memverifikasi user langsung ke direktori perusahaan lewat LDAP, kependekan dari Lightweight Directory Access Protocol: protokol untuk membaca semacam buku alamat digital berisi daftar karyawan beserta hak aksesnya, atau lewat produk sejenis buatan Microsoft bernama Active Directory. Ada yang mengandalkan komputer yang sudah “kenal” jaringan kantor lewat Kerberos, protokol autentikasi yang memberi “tiket” terenkripsi ke komputer begitu penggunanya login ke jaringan, sehingga tidak perlu login ulang setiap kali membuka aplikasi baru. Ada yang punya halaman login sendiri dengan basis data pengguna sendiri, dibuat manual oleh tim yang mengembangkan aplikasi itu dulu. Ada aplikasi desktop lawas semacam SAP GUI, program yang dipasang langsung di komputer untuk mengakses perangkat lunak keuangan dan logistik SAP, atau Oracle E-Business Suite, paket perangkat lunak sejenis buatan Oracle, yang bukan aplikasi web sama sekali sehingga tidak bisa dibuka lewat browser. Dan yang paling ekstrem, sistem mainframe, komputer pusat berukuran besar yang masih dipakai bank dan institusi besar untuk mengolah transaksi dalam jumlah sangat banyak, diakses lewat emulator layar hijau (tampilan berbasis teks ala komputer tahun 1980-an) dan diamankan mekanisme keamanan bernama RACF, kependekan dari Resource Access Control Facility, yang usianya sudah lebih tua dari sebagian besar karyawan yang memakainya hari ini.

Titik krusialnya: hampir semua mekanisme lama ini tidak mendukung MFA, kependekan dari multi-factor authentication atau autentikasi berlapis, yaitu verifikasi tambahan setelah password (misalnya kode sekali pakai yang dikirim ke ponsel) yang sekarang jadi standar keamanan minimum. Artinya, selama aplikasi itu belum tersentuh proyek SSO, ia jadi celah keamanan yang nyaris tidak kelihatan, sampai suatu hari dipakai orang yang salah untuk masuk lewat pintu belakang.

Trik yang membuat aplikasi lama “berbicara” bahasa modern

Ini bagian yang menurut saya paling elegan dari seluruh riset: perusahaan tidak perlu menulis ulang kode aplikasi lama untuk membuatnya ikut SSO. Triknya adalah menaruh semacam penerjemah di depan aplikasi tersebut, disebut reverse proxy (server perantara yang berdiri di depan aplikasi lain) atau access gateway (gerbang akses).

Cara kerjanya mirip satpam gedung yang memeriksa KTP di pintu depan. Setiap orang yang mau masuk ke aplikasi lama, dialihkan dulu ke sistem SSO modern untuk login lengkap dengan MFA. Setelah lolos, satpam inilah yang “berbicara” ke aplikasi lama, memberi tahu lewat sinyal internal, yang disebut header HTTP, bahwa orang ini sudah terverifikasi, silakan masuk. HTTP sendiri kependekan dari HyperText Transfer Protocol, aturan dasar yang dipakai internet untuk mengirim halaman web dari server ke browser, dan header adalah semacam catatan tambahan yang menempel di setiap pengiriman data itu. Aplikasi lama tidak pernah tahu ada sistem modern di baliknya. Ia hanya percaya pada satpamnya, tanpa satu baris kode pun diubah. Satu syarat yang tidak boleh dilewatkan: jalur antara satpam dan aplikasi lama itu harus jalur tepercaya yang tidak bisa disusupi dari luar, misalnya lewat jaringan tertutup atau koneksi terenkripsi antar-server. Kalau syarat ini bocor, siapa pun yang bisa menjangkau aplikasi lama secara langsung juga bisa memalsukan header itu dan menyamar jadi pengguna sah tanpa perlu login sama sekali.

Pola inilah yang membuat proyek integrasi legacy ke SSO bisa dikerjakan bertahap, bukan sekali gebrak ganti semua sistem. Untuk aplikasi desktop yang bukan aplikasi web sama sekali, dan untuk sistem mainframe, trik penerjemah ini tidak berlaku karena tidak ada lalu lintas web yang bisa dicegat. Perusahaan biasanya memakai pendekatan yang disebut password vaulting: brankas kata sandi terenkripsi yang otomatis mengisikan password asli ke aplikasi lama begitu penggunanya lolos SSO, tanpa penggunanya sendiri pernah tahu apa isi password itu.

Tidak ada satu produk pemenang

Gartner, lembaga riset dan analis teknologi yang laporannya jadi acuan umum saat perusahaan besar memilih vendor, menerbitkan laporan tahunan bernama Magic Quadrant: peta yang menempatkan vendor ke dalam kuadran berdasarkan kelengkapan visi produk dan kemampuan eksekusinya. Riset pasar dari Gartner menempatkan empat pemain sebagai pemimpin di kuadran manajemen akses tahun 2024: Microsoft, Ping Identity, Okta, dan IBM. Pasar ini sendiri tumbuh 17,6 persen menjadi 5,85 miliar dolar AS pada 2023, didorong perusahaan yang mengganti sistem identitas buatan sendiri dengan produk komersial. Ping Identity, khususnya, jadi makin kuat setelah diakuisisi Thoma Bravo (perusahaan investasi yang membeli lalu menggabungkan perusahaan-perusahaan teknologi) senilai 2,8 miliar dolar AS, dan digabung dengan ForgeRock (perusahaan lain yang juga menjual perangkat lunak manajemen identitas) senilai 2,3 miliar dolar AS pada Agustus 2023.

Tapi tidak ada satu produk yang menang mutlak untuk semua situasi. Ini yang menurut saya sering dilewatkan tim IT yang buru-buru memilih vendor duluan, sebelum memetakan masalahnya sendiri. Perusahaan yang sudah bergantung penuh pada Microsoft 365 biasanya paling hemat memakai Entra ID, produk identitas milik Microsoft sendiri yang dulu bernama Azure Active Directory. Perusahaan yang ingin kendali penuh dan tidak mau terikat biaya lisensi, dengan tim teknis yang cukup kuat, cenderung memilih Keycloak: proyek perangkat lunak sumber terbuka (kode programnya terbuka dan bisa dipakai siapa saja secara gratis) yang awalnya dikembangkan Red Hat, perusahaan perangkat lunak yang berfokus pada produk sumber terbuka. Untuk perusahaan dengan tumpukan aplikasi lama paling rumit, Ping Identity, perusahaan penyedia perangkat lunak manajemen identitas, biasanya jadi pilihan paling matang untuk menangani situasi berantakan semacam ini.

Sebagai gambaran skala, Keycloak dipakai portal layanan publik pemerintah Austria yang melayani lebih dari 650 ribu organisasi terdaftar dan dua juta pengguna, dengan sekitar 50 ribu proses login per hari. Okta, penyedia layanan identitas berbasis cloud, dalam laporan resminya ke SEC (Securities and Exchange Commission, regulator pasar modal Amerika Serikat) akhir Oktober 2024, mencatat lebih dari 19.450 pelanggan di platformnya. Produk-produk ini sudah terbukti bekerja di skala besar. Jadi pertanyaannya bukan lagi soal apakah teknologinya siap, melainkan mana yang paling cocok dengan kondisi perusahaan masing-masing.

Kalau mau jalur sumber terbuka sepenuhnya

Tiga bagian berikut ini agak lebih teknis dari sisanya. Kalau Anda cuma butuh gambaran besar, boleh langsung lompat ke bagian “Kenapa tidak bisa sekali gebrak” di bawah, tanpa kehilangan alur utama artikel ini.

Satu pertanyaan yang sering muncul setelah membaca perbandingan vendor di atas: apakah harus bayar lisensi komersial, atau ada jalur sumber terbuka (open source, kode programnya terbuka dan gratis dipakai siapa saja) yang cukup matang untuk perusahaan sebesar ini? Jawabannya iya, dan Keycloak, yang sudah saya sebut sebelumnya, adalah jantungnya.

Istilah teknis untuk “sistem SSO modern” yang saya sebut berkali-kali di atas adalah IdP, kependekan dari Identity Provider: pusat tunggal yang menerbitkan bukti identitas untuk semua aplikasi lain. Keycloak berlisensi Apache 2.0, salah satu jenis lisensi sumber terbuka yang paling longgar, artinya boleh dipakai untuk kebutuhan komersial tanpa membayar royalti sepeser pun ke pembuatnya.

Supaya IdP ini tidak jadi titik kegagalan tunggal, pola standarnya adalah HA, kependekan dari high availability atau ketersediaan tinggi. Beberapa salinan Keycloak (disebut node) dijalankan bersamaan di belakang load balancer (contohnya Nginx atau HAProxy), alat yang membagi lalu lintas masuk ke beberapa server sekaligus supaya kalau satu server mati, yang lain tetap melayani. Node-node ini saling “menemukan” satu sama lain lewat metode bernama JDBC_PING, yaitu mereka saling mengecek keberadaan lewat basis data bersama, bukan lewat siaran ke seluruh jaringan yang sering diblokir firewall perusahaan (firewall: penjaga lalu lintas jaringan yang memblokir akses mencurigakan atau tidak dikenal).

Basis data ini biasanya PostgreSQL, sistem manajemen basis data sumber terbuka yang jadi tempat penyimpanan utama dan rujukan paling benar (disebut source of truth) untuk seluruh data pengguna. Sesi login pengguna sendiri disimpan lewat Infinispan, teknologi cache (penyimpanan sementara di memori supaya diakses lebih cepat) yang tersebar di semua node, sehingga pengguna tidak perlu login ulang meski permintaannya kebetulan dilayani node yang berbeda-beda.

Kalau perusahaan butuh tahan terhadap satu lokasi server (disebut data center) mati total, Keycloak juga bisa dijalankan lintas beberapa data center sekaligus, asalkan jeda pengiriman data antar-lokasi (latensi) dan proses penyalinan data otomatis antar-basis data (replikasi) memenuhi syarat teknisnya.

Untuk aplikasi legacy yang tidak bisa bicara SAML atau OIDC, yaitu sebagian besar aplikasi yang saya bahas di bagian atas, Keycloak dipasangkan dengan reverse proxy identity-aware yang sudah saya jelaskan konsepnya lewat analogi satpam tadi. Dua pilihan sumber terbuka yang paling matang untuk peran satpam ini adalah oauth2-proxy dan Authelia. Cara kerjanya sama persis: proxy memverifikasi pengguna ke Keycloak, lalu meneruskan ke aplikasi lama lewat header HTTP atau JWT, kependekan dari JSON Web Token, sejenis “kartu identitas digital” yang ditandatangani secara kriptografis sehingga tidak bisa dipalsukan. Aplikasi lama tidak perlu diubah kodenya sama sekali, cukup dikonfigurasi supaya percaya pada header yang dikirim si proxy.

Kalau perusahaan belum punya direktori pengguna terpusat sama sekali, FreeIPA, proyek sumber terbuka buatan Red Hat, bisa menggabungkan fungsi direktori dan KDC (Key Distribution Center, “kantor pusat” penerbit tiket Kerberos yang sudah saya jelaskan tadi) dalam satu paket untuk lingkungan Linux. Keycloak lalu tinggal difederasikan ke sana, atau ke Active Directory kalau perusahaan sudah lebih dulu punya. Untuk kebutuhan yang lebih spesifik, federasi SAML murni antar-institusi seperti yang biasa dipakai kampus dan lembaga riset, ada Shibboleth IdP sebagai pilihan lain. Dan kalau tim internal tidak punya keahlian bahasa pemrograman Java yang dalam (Keycloak dibangun di atas Java), ada pemain yang lebih baru bernama Authentik, dengan tampilan admin yang dianggap lebih ramah dan makin banyak dipakai belakangan ini, meski jam terbangnya di skala sangat besar belum sematang Keycloak.

“Gratis” bukan berarti murah

Ini bagian yang menurut saya paling jujur dari opsi sumber terbuka: lisensi Keycloak memang gratis, tapi biayanya tidak hilang, hanya pindah tempat. Biaya sebenarnya ada di operasional: server, basis data yang tahan gagal, dan yang paling mahal, tenaga ahli.

Ada satu analisis TCO (Total Cost of Ownership, atau total biaya kepemilikan: seluruh biaya sesuatu selama masa pakainya, bukan cuma harga beli di awal) yang beredar, membandingkan biaya operasional Keycloak selama tiga tahun sekitar 142.200 dolar AS (dengan asumsi lebih dari 3 jam kerja perawatan per minggu) melawan sekitar 19.500 dolar AS untuk alternatif komersial yang dikelola pihak lain (managed service, jasa berlangganan di mana penyedia lain yang mengurus operasionalnya) dalam skenario setara. Saya perlu jujur di sini: saya tidak bisa menelusuri sumber asli analisis ini sampai ke publikasi aslinya, jadi perlakukan dua angka itu sebagai ilustrasi pola, bukan angka final untuk keputusan anggaran nyata. Yang lebih bisa saya pertanggungjawabkan adalah polanya sendiri, yang konsisten muncul dari beberapa sumber berbeda yang saya baca: Keycloak butuh keahlian Java, jaringan, dan DevOps (gabungan istilah development dan operations, peran yang mengurus penyebaran dan pemeliharaan sistem secara terus-menerus) yang cukup spesifik. Ini dianggap sebagai proyek rekayasa berskala penuh, bukan sesuatu yang tinggal dipasang lalu dilupakan.

Untuk gambaran kasar saja, 40 jam pelatihan awal per pengembang diperkirakan sekitar 4.800 dolar AS dengan tarif 60 dolar AS per jam, dan tim berisi lima engineer (insinyur perangkat lunak) bisa menghabiskan 12.000 sampai 24.000 dolar AS hanya untuk pelatihan selama tiga tahun.

Kapan jalur sumber terbuka ini masuk akal

Dari semua yang saya baca, jalur ini paling masuk akal kalau kondisinya begini:

  • Perusahaan sudah punya, atau mampu membentuk, tim DevOps/IAM (Identity and Access Management, manajemen identitas dan akses) internal dengan kapasitas Java dan Linux yang memadai.
  • Prioritas utama adalah kendali penuh atas data dan keengganan bergantung pada vendor asing, misalnya karena kewajiban kepatuhan seperti UU Pelindungan Data Pribadi (UU PDP), yang membuat sebagian institusi Indonesia, terutama yang diregulasi ketat seperti perbankan, lebih nyaman menjaga data tetap di server sendiri.
  • Skala kebutuhannya besar: ribuan pengguna dengan banyak aplikasi legacy berbasis header atau Kerberos, sesuatu yang sudah terbukti ditangani kombinasi Keycloak dengan oauth2-proxy atau Authelia.

Sebaliknya, kalau tim IT terbatas, tidak ada spesialis identity atau DevOps, dan sistemnya harus cepat jalan, opsi yang lebih realistis adalah Keycloak yang dikelola pihak ketiga (managed Keycloak, misalnya dari Red Hat atau vendor lain), atau tetap membandingkannya dulu dengan Entra ID maupun Okta yang beban operasionalnya jauh lebih ringan.

Petanya kira-kira begini: aplikasi modern langsung bicara ke Keycloak lewat SAML atau OIDC. Aplikasi legacy berbasis web masuk lewat oauth2-proxy atau Authelia dulu, baru diteruskan ke Keycloak. Keycloak sendiri difederasikan ke FreeIPA, Active Directory, atau OpenLDAP (implementasi sumber terbuka dari protokol LDAP yang sudah saya jelaskan di atas) sebagai sumber data pengguna. Semua catatan login itu lalu dikirim ke SIEM (Security Information and Event Management, sistem yang mengumpulkan dan menganalisis log keamanan dari banyak sumber di satu tempat), yang juga ada versi sumber terbukanya, misalnya Wazuh.

Satu catatan jujur yang menurut saya penting di sini: untuk aplikasi desktop lawas dan mainframe, yang di bagian atas saya jelaskan butuh brankas kata sandi atau gateway web-enablement (gerbang yang mengubah tampilan mainframe jadi bisa diakses lewat web), opsi sumber terbuka jauh lebih terbatas dibanding dunia komersial, misalnya Imprivata (salah satu vendor komersial ternama untuk pengelolaan kata sandi otomatis semacam ini). Sumber terbuka sangat kuat untuk lapisan IdP dan aplikasi web, tapi belum punya jawaban semurah itu untuk aplikasi lawas yang paling keras kepala.

Kenapa tidak bisa sekali gebrak

Terlepas dari vendor komersial atau jalur sumber terbuka yang akhirnya dipilih, ada satu tantangan berikutnya yang sama besarnya: caranya berpindah. Ini bukan cuma masalah perusahaan multinasional. Dari yang saya amati, BUMN dan bank-bank besar di Indonesia menghadapi versi masalah yang sama, kadang malah lebih berat, karena sebagian sistem inti mereka berjalan di atas platform mainframe atau ERP yang dipasang belasan bahkan puluhan tahun lalu, jauh sebelum SAML atau OIDC jadi standar.

Semua sumber yang saya baca, dari Microsoft sampai praktisi lapangan, sepakat pada satu hal: migrasi ke SSO terpusat tidak boleh dikerjakan sekaligus. Analoginya seperti merenovasi rumah yang masih ditinggali. Anda tidak bisa membongkar semua ruangan bersamaan, karena penghuninya, dalam hal ini karyawan yang harus tetap bisa kerja setiap hari, butuh tempat tinggal yang berfungsi sepanjang proses.

Praktik yang disarankan adalah migrasi bertahap per gelombang, dimulai dari sepuluh aplikasi yang paling banyak dipakai untuk membangun momentum, sambil sistem lama dan baru berjalan berdampingan untuk sementara. Setiap gelombang diukur dari angka konkret: tingkat keberhasilan login dan jumlah tiket keluhan ke helpdesk (meja bantuan IT), sebelum lanjut ke gelombang berikutnya. Untuk perusahaan dengan sekitar seribu dua ratus karyawan dan banyak aplikasi lama, perkiraan waktu penyelesaian menurut riset ini adalah tiga tahun atau lebih. Untuk perusahaan dengan ribuan karyawan dan lebih banyak lagi aplikasi warisan, angka itu realistis bisa lebih panjang lagi.

Satu kunci yang gampang dilupakan

Ada satu detail kecil dalam riset ini yang, menurut saya, sering luput dari presentasi vendor mana pun: break-glass account, secara harfiah berarti “akun pecahkan kaca”, meniru kotak alat pemadam kebakaran yang kacanya baru dipecahkan saat benar-benar darurat. Ini adalah akun darurat dengan kredensial standar (username dan password biasa, di luar sistem SSO), disimpan aman, dan hanya dipakai kalau sistem SSO pusat sendiri lumpuh. Ironisnya, semakin berhasil sebuah perusahaan memusatkan semua login ke satu sistem, semakin besar juga kerugian kalau sistem pusat itu mati. SSO menyelesaikan masalah password yang tercecer di mana-mana, tapi menciptakan satu titik kegagalan baru yang harus punya rencana cadangan sendiri.

Satu langkah yang bisa dimulai besok

Satu pengakuan jujur sebelum menutup: artikel ini tidak membahas semua vendor yang ada, tidak membahas secara spesifik bagaimana regulasi seperti UU PDP memengaruhi pilihan on-premise versus cloud secara hukum (itu ranah tim legal, bukan tulisan ini), dan sebagian besar angka pasar serta biaya yang saya kutip berasal dari konteks Amerika Serikat, jadi perlu disesuaikan dulu ke kondisi lokal sebelum dipakai untuk keputusan nyata.

Membangun arsitektur SSO yang benar, baik lewat vendor komersial maupun jalur sumber terbuka, butuh waktu tahunan dan anggaran yang tidak kecil. Tapi langkah pertamanya sama untuk kedua jalur itu, tidak butuh vendor, tidak butuh proyek besar, dan bisa dimulai besok pagi: buat daftar sederhana. Untuk setiap aplikasi yang dipakai lebih dari lima puluh karyawan, catat satu hal saja, bagaimana cara aplikasi itu memverifikasi identitas penggunanya sekarang. Ini juga bukan langkah yang saya karang sendiri: Microsoft, dalam kerangka migrasinya sendiri untuk klien besar, menyarankan urutan yang sama, mulai dari inventarisasi dan prioritisasi, bukan dari pemilihan vendor duluan.

Daftar itu kedengarannya remeh, tapi itu peta harta karun yang menentukan arah seluruh proyek. Perusahaan yang langsung memilih vendor sebelum tahu isi daftar ini, hampir selalu berakhir membeli alat yang tidak cocok dengan masalah yang sebenarnya mereka punya.

Referensi

  1. Microsoft, Ping, Okta Dominate Access Management Gartner MQ Novinson, M. (3 Januari 2025). BankInfoSecurity. Liputan Gartner Magic Quadrant for Access Management 2024: Microsoft, Ping Identity, Okta, dan IBM sebagai Leaders; Ping Identity dinilai memiliki visi paling lengkap setelah Thoma Bravo menggabungkannya dengan ForgeRock; pasar tumbuh 17,6% menjadi USD 5,85 miliar pada 2023. Baca di BankInfoSecurity

  2. BRZ Migrated the Austrian Business Service Portal with 2M Users to Keycloak Cloud Native Computing Foundation. Studi kasus Keycloak di portal layanan publik federal Austria (USP), dikelola Bundesrechenzentrum (BRZ): lebih dari 650.000 organisasi terdaftar, dua juta pengguna terdaftar, sekitar 50.000 login per hari, akses ke lebih dari 130 layanan publik digital. Baca studi kasus di CNCF

  3. Infosys Ltd. Client (Perusahaan Farmasi Jepang) Cloud Native Computing Foundation / Infosys. Studi kasus Keycloak SSO untuk ekosistem aplikasi lebih dari 2 juta pengguna di perusahaan farmasi Jepang, mendukung platform e-pharmacy yang melayani lebih dari 750 apotek dan 200.000+ pengguna dalam empat tahun. Baca studi kasus di CNCF

  4. Okta, Inc. Form 10-Q (Kuartal Berakhir 31 Oktober 2024) US Securities and Exchange Commission (SEC). Laporan triwulanan resmi Okta: lebih dari 19.450 pelanggan pada platformnya per 31 Oktober 2024. Baca arsip SEC EDGAR

  5. Legacy Authentication: The Forgotten Back Door of Organizations CYE. Analisis risiko keamanan protokol autentikasi lama yang tidak mendukung MFA, termasuk kerentanan terhadap password spray dan brute-force. Baca di CYE

  6. Migrating from On-Prem Active Directory to Microsoft Entra ID TechnologyMatch. Analisis timeline migrasi identitas on-premise ke cloud: organisasi ~1.200 pengguna dengan infrastruktur NTLM-dependent perlu merencanakan tiga tahun atau lebih; eliminasi NTLM saja 18-22 bulan. Baca di TechnologyMatch

FD Iskandar menulis tentang tata kelola teknologi dan arsitektur sistem enterprise. Kontak: [email protected] .

Disclaimer: Tulisan ini adalah pandangan pribadi penulis sebagai praktisi profesional dan tidak mewakili sikap atau kebijakan resmi dari institusi/perusahaan tempat penulis bekerja. Bukan nasihat hukum, kepatuhan, atau investasi yang mengikat; untuk keputusan arsitektur dan anggaran nyata, konsultasikan dengan tim internal dan penasihat yang memahami konteks organisasi Anda.