Kron PAM Nedir? Ayrıcalıklı Erişim Yönetimi (PAM) Nasıl Çalışır

Her kurumda birkaç hesap, sıradan kullanıcı hesaplarından çok daha geniş yetki taşır: sunucuların yönetici hesapları, veritabanı yöneticisi hesapları, ağ cihazlarının yerel hesapları ve uygulamaların birbirine bağlanırken kullandığı servis hesapları. Bu hesaplardan biri kötüye kullanıldığında zarar tek bir kullanıcıyla sınırlı kalmaz.

Sorun çoğu zaman teknik değil, alışkanlıktır. Aynı yönetici parolası ekipte elden ele dolaşır ve biri ayrıldığında değiştirilmez; bakım için dış firmaya açılan hesap iş bitince unutulur. Paylaşılan hesapla yapılan bir işlemin kime ait olduğu da sonradan bulunamaz, çünkü hedef sistemin günlüğünde yalnız ortak hesabın adı görünür.

Ayrıcalıklı erişim yönetimi bu alışkanlığı teknik bir kurala çevirir. Kullanıcı ile kritik sistem arasına bir denetim katmanı girer ve dört iş bu katmanda yapılır:

• Kimlik: Bağlanan kişi kendi hesabıyla, gerekiyorsa çok faktörlü doğrulamayla tanınır.
• Yetki: Kimin hangi sisteme, ne zaman ve hangi onayla bağlanabileceği politikada tanımlanır.
• Parola: Ayrıcalıklı hesabın parolası kasada durur ve kullanıcıya gösterilmez.
• Kayıt: Oturumda yapılanlar kaydedilir, gerektiğinde oturum kesilir.

Türkiye'de bu alan çoğunlukla İngilizce adıyla, "privileged access management" ya da kısaca PAM olarak aranır. Çözüm alanının genel çerçevesi ayrıcalıklı erişim yönetimi sayfamızda yer alıyor.

Kron PAM proxy mimarisiyle çalışır. Kullanıcı hedef sisteme doğrudan bağlanmaz; önce platformda kimliğini doğrular, erişim talebi politikaya göre değerlendirilir ve bağlantı platformun ilgili katmanından geçerek açılır. Kabuk bağlantıları SSH proxy'sinden, uzak masaüstü bağlantıları RDP katmanından, veritabanı bağlantıları ise ayrı bir SQL proxy'sinden geçer.

Bu tasarımın pratik sonucu şudur: ana kullanım senaryolarında hedef sunuculara, veritabanlarına ya da ağ cihazlarına ajan kurulmaz. Sistem ekipleri kritik sunuculara yeni bir yazılım eklenmesine sıklıkla direnç gösterir ve ajansız yaklaşım bu tartışmayı baştan küçültür. İstisna, makine kimliklerinin yönetildiği Kubernetes senaryolarıdır; orada bir ajan kullanılır.

Platformun çevresindeki bileşenler şöyle ayrılır:

Platformun kendisi kurum içinde, fiziksel ya da sanal bir sunucuda çalışır; üreticinin belgelerine göre Red Hat Enterprise Linux 8.8 ve üzeri ile yerel bir PostgreSQL veri tabanı kullanır. Active Directory entegrasyonu bulunur ama zorunlu değildir; 3.8.1 sürümüyle Entra ID'den kullanıcı içe aktarılabiliyor. Yüksek erişilebilirlik için birden çok örnek kurulur ve ana düğüm düştüğünde görev önceliğe göre devredilir. Kron'un bulut tarafındaki hizmeti ise kurum içi ürünün buluta taşınmış hâli değil, ayrı bir hizmet modelidir.

Desteklenen protokoller arasında RDP, SSH, Telnet, SFTP, HTTP/S, SMB2 ve WinRM ile ağ cihazları için TACACS+ ve RADIUS bulunur.

Projeyi başlatan şey çoğu zaman tek bir somut sorundur. Kron PAM'in karşılık geldiği tipik durumlar şunlardır:

• Ortak yönetici parolaları. Parola kasada durur ve kullanıcıya gösterilmez; ekipten ayrılan kişi bilmediği bir parolayı yanında götüremez.
• Kapanmayan dış firma erişimleri. Bakım erişimi onaydan geçer, süreyle sınırlanır ve süre dolunca kendiliğinden kalkar.
• Kalıcı yetki birikimi. Bir kez verilip geri alınmayan yetkinin yerini rol tabanlı tanım ve ihtiyaç anında verilen süreli yetki alır.
• Denetimde kanıt istenmesi. "Bu sunucudaki değişikliği kim yaptı?" sorusu farklı sistemlerin günlüklerinden derlenmek yerine oturum kaydından cevaplanır.
• Gereğinden fazla veri gören ekipler. Database Access Manager, destek ekibinin kart numarası ya da kimlik bilgisi gibi alanları maskeli görmesini sağlar; maskeleme veritabanında değişiklik yapılmadan sorgu sonucunda uygulanır. Maskelenecek alanları seçmek için önce hassas verinin nerede durduğunu bilmek gerekir: hassas veri keşfi.
• Yetkili ama olağandışı davranış. Teknik olarak izinli bir işlem kurala takılmaz. Davranış analizi olağan saatlerin dışındaki girişleri ya da alışılmadık komutları risk puanıyla işaretler, gerekirse erişimi otomatik olarak kısıtlar ya da oturumu sonlandırır.

Kron PAM bir kuruma tek başına uyum kazandırmaz; uyum yükümlülüğü kurumdadır. Ürünün katkısı, denetçinin istediği kanıtı sürekli ve tek bir yerden üretmesidir. Türkiye'de sık karşılaşılan çerçevelerle ilişkisi şöyledir:

Kamu alımlarında bir konu daha öne çıkar. Üreticinin 2025 faaliyet raporuna göre yedi ürünü için Yerli Malı Belgesi bulunuyor; bu belge kamu ihalelerinde fiyat değerlendirmesinde avantaj sağlar. 7545 sayılı Siber Güvenlik Kanunu da temel esasları arasında yerli ve millî ürünlere öncelik vermeyi sayar.

Ancak aynı Kanun, kamu kurumlarında ve kritik altyapılarda kullanılacak ürünler için ayrı bir yetkilendirme ve belgelendirme düzenlemesi öngörür ve Yerli Malı Belgesi bunun yerine geçmez. Bir ihalede hangi belgenin arandığı şartnameden okunmalı, gerekli belgeler ihaleden önce üreticiden yazılı olarak istenmelidir.

Evet. Kron PAM, önceki sürümlerde ve kurulu tabanda Single Connect adıyla biliniyordu; bugünkü ticari adı Kron PAM'dir. Eski ad Türkiye'de ihale şartnamelerinde ve BT ekiplerinin dilinde hâlâ geçer, teknik tarafta da yaşar: yama paketlerinin dosya adı bugün de singleconnect-x.xx.xx-patch.tar biçimindedir.

Uzun süredir Single Connect kullanan bir kurum için asıl soru ad değil, sürümün durumudur. Kron uzun dönem destekli (LTS) sürümler yayımlar ve her biri için destek bitiş tarihi açıklar. Bu yazının hazırlandığı tarihte güncel LTS sürümü Şubat 2026'da çıkan 3.8.1'dir; üretici bu sürüm için geliştirme sonu (EoD) olarak Şubat 2027'yi, destek sonu (EoS) olarak Ağustos 2027'yi açıklamış. Önceki LTS sürümü 3.8.0, Ekim 2025'te yayımlanmıştı.

Üreticinin sürüm notlarına göre 3.8.1 ile gelen yenilikler arasında şunlar var:

• MongoDB ve Redis parolalarının yönetimi
• su ve sudo komutları için kimlik bilgisi enjeksiyonu
• Endüstriyel kontrol sistemlerinde (OT/ICS) oturum sonlandırma
• RADIUS üzerinden dış çok faktörlü doğrulama sağlayıcısı bağlama
• TACACS+ için TLS 1.3 desteği

Eski bir kurulumda bu yüzden iki şey kontrol edilir: mevcut sürümün destek durumu ve güncel sürüme yükseltme yolu.

Proje kapsamını doğru çizmek için platformun neyi yapmadığını baştan bilmek gerekir. Kron PAM için başlıca sınırlar şunlardır:

• Kimlik yönetişimi ürünü değildir. İşe giriş, görev değişikliği, ayrılış ve dönemsel erişim sertifikasyonu gibi çalışan yaşam döngüsü süreçleri başka bir ürün sınıfının işidir. İkisi birbirini tamamlar: biri hesabın yaşam döngüsünü yönetir, diğeri o hesabın kritik sistemlerdeki kullanımını denetler.
• Olay yönetimi (SIEM) ürünü değildir. Erişim, oturum ve politika olaylarını üretir ve kurumun olay yönetimi platformuna iletir; geniş kapsamlı günlük analizi yapmaz.
• Uç nokta ayrıcalık yönetimiyle karıştırılmamalıdır. Bu yazının konusu kritik sistemlere erişimdir. Çalışan bilgisayarlarındaki yerel yönetici haklarının kaldırılması ayrı bir çözüm alanıdır: uç nokta ayrıcalık yönetimi.
• Her veritabanında aynı derinlikte çalışmaz. Üreticinin belgelerine göre hassas veri keşfi Oracle, MSSQL, PostgreSQL ve MySQL için destekleniyor. Diğer veritabanlarında hangi özelliğin çalıştığı kavram doğrulamadan önce kontrol edilmelidir.
• Veri maskeleme tek başına PCI DSS uyumu sağlamaz. Maskeleme kart verisini kimin göreceğini sınırlar; kart verisinin korunmasına ilişkin 3. gerekliliği tek başına karşılamaz.
• Kapalı ağda çalışma ayrıca teyit ister. Kurum içi kurulum desteklenir; lisans etkinleştirme, güncelleme ve desteğin de internetsiz yürüdüğü bir işletim modeli ise üreticinin genel dokümantasyonunda açıkça tanımlanmamıştır. Kamu ve savunma projelerinde bu konu üreticiden yazılı olarak teyit edilmelidir.

Teknik kurulum kısa sürer, çünkü hedef sistemlere ajan dağıtılmaz: platform sunucusu hazırlanır, gerekli ağ erişimleri açılır ve yönetilecek sistemler tanımlanır. Projenin asıl emeği envanterde ve politika tasarımındadır.

1. Envanteri çıkarın. Hangi ayrıcalıklı hesaplar var, kimlerde ve hangileri hâlâ açık? Bu liste unutulmuş servis hesaplarını ve kapatılmamış dış firma erişimlerini de ortaya çıkarır.
2. Dar bir kapsamla başlayın. Veri merkezindeki kritik sunucular ya da tek bir kritik uygulama ilk grup için yeterlidir.
3. Onay akışlarını iş birimleriyle kurun. Kimin hangi sisteme hangi onayla bağlanacağına güvenlik ekibi tek başına karar veremez.
4. Depolamayı hesaplayın. Oturum kayıtlarının kapladığı alan, kaydedilen oturum saati ve saklama süresiyle büyür; bu hesap kurumun kendi oturum profiliyle yapılmalıdır.
5. Lisans kapsamını yazılı netleştirin. Hangi bileşenin çekirdek platformla geldiği, hangisinin ayrı lisanslandığı teklif aşamasında yazılı olarak sorulmalıdır.

Innoset, Kron'un Türkiye'deki iş ortağı olarak lisanslama, kurulum, kavram doğrulama ve Türkçe teknik destek süreçlerini yürütür. Ürün ailesinin tamamı ve hangi ihtiyacın hangi ürünle karşılandığı Kron sayfamızda yer alıyor.