Ayrıcalıklı erişim yönetimi neden gerekli?
Her kurumda her şeyi değiştirebilen birkaç kritik hesap bulunur: etki alanı yöneticisi, Linux sunucusundaki root hesabı, güvenlik duvarı yönetim hesabı veya veritabanının sahibi olan hesap. Bu hesaplar çoğunlukla paylaşılır, parolaları nadiren değiştirilir ve saldırganların ilk hedefidir.
Ayrıcalıklı erişim yönetimi bu hesapların önüne bir güvenlik katmanı koyar. İnsanlara parola değil, sisteme erişim yetkisi verilir. Platform parolayı saklar, oturumu açar ve yapılan her işlemin kaydını tutar.
| Kurumlar neden PAM kullanır? | |
|---|---|
| Kimin ne yaptığını kimse bilmiyor | Altı kişi aynı yönetici parolasını kullanıyor. Sunucu günlüğü hesabın bağlandığını gösteriyor ama klavyenin başında bu altı kişiden hangisinin olduğunu söylemiyor. |
| Parolalar yayılıyor ve kalıcılaşıyor | Aynı parola betiklere, yapılandırma dosyalarına, parola yöneticilerine ve insanların hafızasına giriyor. Parolayı bilen herkesle birlikte kurumun dışına çıkabiliyor. |
| Tek hesap yeterli oluyor | Bir yönetici parolasını ele geçiren saldırgan, aynı parolayı kabul eden tüm sunucularda kullanabiliyor. Çoğu ağda ikinci bir doğrulama da istenmiyor. |
| Denetim için kanıt gerekiyor | “Geçen çeyrekte bu sunucuya kim erişti, hangi komutları çalıştırdı?” sorusu hesap listesiyle değil; kişi, zaman ve komut bilgileriyle yanıtlanmalı. |
Parolayı kimse bilmez. Her işlemin bir sahibi vardır. Her oturum iz bırakır.
Nasıl çalışır?
-
Kullanıcı erişimi
Kullanıcı, PAM platformu üzerindeki tek bir merkezi noktadan erişim başlatır.
-
Kimlik doğrulama
Kimlik doğrulama MFA ile korunur. Yetki yükseltme denemelerinde de MFA otomatik olarak devreye girer.
-
Yetkilendirme kontrolü
Erişim talepleri tanımlı politikalar ve rol bazlı yetkilendirme (RBAC) üzerinden değerlendirilir; gerektiğinde onay akışı tetiklenir.
-
Güvenli erişim
Kullanıcı hedef sisteme izole ve ajansız bir mimari üzerinden bağlanır: yerel RDP/SSH ya da güvenli tarayıcı. Kimlik bilgilerini hiçbir zaman görmez.
-
Oturum güvenliği
Oturumdaki her işlem gerçek zamanlı izlenir ve kaydedilir. Şüpheli davranış oturumu otomatik sonlandırabilir; gerektiğinde yetkili bir kullanıcı oturuma canlı katılabilir.
Aynı sunucuya üç erişim yolu. Tek güvenlik politikası.
Windows veya Linux sunucusuna üç yöntemle de erişilebilir; uygulanan kontroller değişmez:
| Mirket’in izole tarayıcısından | Bilgisayara hiçbir şey kurmadan HTML5 üzerinden RDP ve SSH erişimi |
| Portalın oluşturduğu başlatıcıyla | Ek kurulum gerekmez. Mirket, yöneticinin çalıştıracağı bir dosya oluşturur: Windows ve macOS’ta RDP için Microsoft Remote Desktop; SSH için desteklenen SSH istemcisi: Windows’ta PuTTY, macOS’ta Terminal |
| Mirket ajanıyla | Ajan kendi RDP ve SSH araçlarını içerir; oturumu masaüstüne devretmek yerine kendi penceresinde yürütür |
Başlatıcı ayrıca açıklanmayı hak ediyor; çünkü bu tür mimarilerde oluşturulan bağlantı dosyası genellikle zayıf halka olabilir. Dosya oluşturulduktan sonraki bir dakika içinde çalıştırılmalıdır ve yalnızca bir kez kullanılabilir. İndirilenler klasöründe kalan dosya, yeniden erişim yolu değildir.
Web konsolları da aynı yöntemle açılır. Güvenlik duvarı, hipervizör, yedekleme konsolu veya terminal sunucusundan yayımlanan uygulama aynı izole tarayıcı içinde çalışır.
Hangi yöntem seçilirse seçilsin, aşağıdaki beş adım ve tutulan kayıtlar aynıdır.
- Keşif, envanteri oluşturur. Mirket’i etki alanına bağladığınızda yanıt veren sunucular; ana bilgisayar adı, IP, işletim sistemi, OU, erişilebilirlik ve yerel hesaplarıyla içe aktarılır. Birinin güncellemeyi bıraktığı tabloya değil, gerçek ortama bakarak başlarsınız.
- Hesap eşlemesi, hangi hesabın kullanılacağını belirler. Varlık veya varlık grubu bazında: Bu kullanıcı, bu sisteme, bu hesapla bağlanır. Kullanıcı parola değil, hedef seçer.
- Oturum politikası, oturumun açılıp açılmayacağını belirler. Kullanıcı veya grup, hedef veya hedef grubu ve zaman planı değerlendirilir. Sonuç: izin ver, reddet veya onaylayana yönlendir.
- Oturum, işe uygun üç yöntemden biriyle açılır. Kimlik bilgisi oturuma aktarılır; asla gösterilmez veya elle girilmez.
- Oturum video ve metin olarak kaydedilir. Bu kayıtlar her erişim yönteminde oluşturulur.
2, 3 ve 5. adımlar, 4. adımda seçilen erişim yöntemine bağlı değildir. Yöntem yalnızca kullanım kolaylığı sağlar; kontrol seviyesini belirlemez. Yöneticilerin bu kontrolleri aşacak alternatif yollar aramamasının nedeni de budur.
Oturumun içinde
Ayrıcalıklı bir oturumdaki her işlem ilk bakışta normal görünebilir
Ayrıcalıklı bir oturuma giren saldırganın güvenlik açığı kullanması gerekmez. Hesap gerçektir, giriş geçerlidir; sonrasında yapılanlar yalnızca birinin klavyede yazdıklarıdır.
Güvenlik duvarınız ve giriş kontrolleriniz görevini çoktan yapmıştır. Oturumun açıldığını söyleyebilirler; ancak içeride ne yapıldığını gösteremezler.
Bu nedenle denetim, oturumun içinde yapılmalıdır.
- Komut politikası kara liste veya beyaz liste modunda çalışır. Bir desen eşleştiğinde komut metin dökümünde işaretlenebilir, çalıştırılmadan engellenebilir veya oturum doğrudan sonlandırılabilir.
- Yetki yükseltme gerçekleştiği anda doğrulanabilir. RDP veya SSH oturumu içindeki yükseltme, devam etmeden önce yeniden çok faktörlü doğrulama veya yönetici onayı gerektirebilir.
- Tam zamanında erişim, talebin gerekçesini kaydeder. Her talepte gerekçe ve adı belirli bir onaylayan bulunur; bunlar olmadan açılan erişim hemen dikkat çeker.
- Oturum dökümleri metindir. Bir komutun çalıştırılıp çalıştırılmadığını öğrenmek saatlerce video izlemek değil, arama yapmaktır.
Yetenekler
Erişim ve kapsam
| Yerel RDP | Yönetici, Mirket’in oluşturduğu .rdp dosyasıyla kendi ayarlarını kullanarak Microsoft Remote Desktop üzerinden bağlanır. Pano, dosya aktarımı ve komut politikaları oturum içinde uygulanır. |
| Yerel SSH ve SFTP | Mirket’in oluşturduğu başlatıcı, desteklenen SSH istemcisini açar: Windows’ta PuTTY, macOS’ta Terminal. SFTP aynı yetkilendirme ve denetime tabidir; oturum kapanınca o da kapanır. |
| Tek kullanımlık başlatıcılar | Oluşturulan bağlantı dosyası bir dakika içinde çalıştırılmalıdır ve yalnızca bir kez kullanılabilir; saklanamaz, başkasına devredilemez veya sonradan yeniden kullanılamaz. |
| Mirket ajanı | Kendi RDP ve SSH araçlarını içerir; oturumu ajan penceresinde tutar. Böylece o bilgisayarda alınan ekran görüntüsünde de görünmez. Bu izolasyon ZTNA sayfasında ayrıntılı açıklanır. |
| Mirket’in izole tarayıcısı | Kurulum gerektirmeden HTML5 üzerinden aynı RDP ve SSH oturumları. İstemcisi olmayan, kullanmak istemeyen veya kurum dışından çalışan kişiler için uygundur. Kullanıcının cihazındaki değil, uzakta çalışan Mirket tarayıcısıdır. |
| Web uygulamaları | Güvenlik duvarı, hipervizör, yedekleme konsolu ve iç web uygulamaları kullanıcının değil, Mirket’in izole tarayıcısında açılır. Kimlik bilgilerini Mirket girer; kullanıcı bunları görmez veya kendi tarayıcısından çıkaramaz. |
| Masaüstü uygulamaları | Terminal sunucusu veya RemoteApp üzerinden yayımlanır ve diğer hedefler gibi yönetilir. |
Kimlik bilgileri
| Parola kasası | Ayrıcalıklı hesap parolalarını Mirket saklar ve sağlar. Kullanıcı hedefi seçer; kimlik bilgileri oturuma aktarılır. |
| Otomatik parola değiştirme | Hesap bazında, belirlenen takvime göre; gün aralığı ve saat tanımlanabilir. |
| Hesap eşlemesi | Varlık ve varlık grubu bazında tanımlanır; grup eşlemeleri gruptaki tüm varlıklara uygulanır. |
| Kontrollü parola gösterimi | Parolanın gerçekten bir kişiye gösterilmesi gerekiyorsa kimlerin görebileceği kullanıcı, grup veya harici kaynak bazında açıkça belirlenir. |
| SSH anahtar yönetimi | Ayrıcalıklı erişim anahtar çiftleri merkezi olarak saklanır ve değiştirilir; özel anahtar süresiz olarak bir dizüstü bilgisayarın .ssh klasöründe kalmaz. |
| Gizli bilgi kasası | Uygulama sırları için şifreli depolama, yaşam döngüsü ve API anahtarı yönetimi. |
| Kimlik bilgisi sağlayıcısı | Uygulamalar gerekli sırları yapılandırma dosyasında tutmak yerine çalışma anında ister; kimlik bilgileri yapılandırma ve kaynak kod depolarından çıkarılır. |
| Glass Break — acil durum erişimi | PAM hizmetinin kullanılamadığı durumlar için kontrollü acil erişim. Mirket; sistemlere doğrudan erişmek için gerekli hesap, varlık ve eşleme bilgilerini içeren şifreli bir kurtarma paketi oluşturur. Paket tek kullanımlık kurtarma parolasıyla korunur ve yapılandırma değiştikçe yeniden üretilir. |
Politika ve oturum güvenliği
| Oturum politikası | Kullanıcı veya grup, hedef veya hedef grubu ve zaman planına göre eşleşir. Eylem: izin, ret veya JIT onayı. |
| Komut politikası | Kapalı, kara liste veya beyaz liste. Eşleşmede yalnızca denetim kaydı oluşturma, komutu engelleme veya oturumu sonlandırma seçenekleri vardır. Yalnızca RDP ve SSH için değil, komut satırı bulunan her oturumda geçerlidir: cihazın web arayüzündeki CLI konsolu veya RemoteApp olarak yayımlanan veritabanı istemcisinin sorgu penceresi de aynı kurallarla filtrelenir. |
| Pano denetimi | Oturuma giriş ve oturumdan çıkış yönleri ayrı ayrı yetkilendirilir. |
| Dosya aktarımı denetimi | Yükleme ve indirme ayrı ayrı yetkilendirilir; izin verildiğinde sürükle-bırak kullanılabilir. |
| Yetki yükseltmede MFA | Oturum içindeki yetki yükseltme, fark edilmeden gerçekleşmek yerine yeniden doğrulama veya onay gerektirebilir. |
| Tam zamanında erişim | Kalıcı erişim yerine gerekçeli talep, belirli onaylayan ve başlangıç-bitiş zamanı kullanılır. İlk karar veren onaylayan sonucu belirler; kimse kendi talebini onaylayamaz ve verilen erişim süresi dolmadan iptal edilebilir. |
Görünürlük ve denetim
| Oturum kaydı | Yerel ve tarayıcı erişiminde oturumun tamamı video olarak kaydedilir. Oynatmada boşta geçen bölümler atlanır, hız ayarlanabilir. |
| Komut dökümü | Oturumun video oluşturulmadan okunabilen metin kaydı. Aranabilir, filtrelenebilir, CSV olarak dışa aktarılabilir; işaretlenen ve engellenen komutlar önceden belirtilir. |
| Doğrudan ilgili ana gitme | Komutu aradığınızda oynatıcı, yazıldığı ana gider. |
| Canlı oturum görünümü | Etkin oturumlarda kimin nereye bağlandığı ve ne kadar süredir bağlı olduğu görülür. Yönetici seçilen yetki seviyesinde oturuma katılabilir veya oturumu sonlandırabilir. |
| Oturum geçmişi | Kapanan tüm oturumlar; kimlerin hangi yetkiyle ve ne kadar süreyle katıldığı dahil. |
| Raporlar | Kullanıcı ve varlık bazında, seçilen tarih aralığı için oluşturulur; planlanabilir ve belirlenen alıcılara e-postayla gönderilebilir. |
Envanter ve erişim incelemesi
| Varlık keşfi | Etki alanına bağlı sunucular işletim sistemi, OU, ping ve WinRM erişilebilirliğiyle varlık olarak içe aktarılır; içe aktarmadan önce filtrelenebilir. |
| Hesap keşfi | Sunuculardaki yerel hesaplar, son oturum açma ve grup üyeliğiyle listelenir. Kimsenin oluşturduğunu hatırlamadığı yerel yönetici hesabı da burada görünür. |
| Zamanlanmış yeniden keşif | Günlük, haftalık, aylık, her N saat veya dakikada bir ya da cron ifadesiyle çalıştırılabilir. |
| Erişim matrisi | Hangi kullanıcının hangi sisteme hangi hesapla erişebildiğini tek ekranda gösterir; eski belgelere değil, mevcut yetkilere dayanır. |
Ayrıcalıklı oturumları kendi sunucularınızda görün
Yerel RDP ve SSH ile çalışan yöneticiler, görmedikleri kimlik bilgileri, video ve aranabilir metin kaydı, oturum içinde uygulanan komut politikaları.
Sonradan yanıtlamanız gereken sorular
Ayrıcalıklı erişim yönetiminde kontrol işin yarısıdır. Diğer yarısı aylar sonra, geçmişte olan bir işlem sorulduğunda ortaya çıkar. Yanıt, insanların hafızasından değil sistemin kayıtlarından gelmelidir.
Raporlar iki yönde çalışır. Belirli bir kullanıcının eriştiği sistemleri veya belirli bir varlığa kimlerin eriştiğini, istediğiniz tarih aralığında sorgulayabilirsiniz. Ayrıcalıklı oturumların başlangıç, bitiş ve süre bilgileri sayesinde yalnızca erişilip erişilmediğini değil, ne kadar süre erişildiğini de görürsünüz.
Raporlar, kimsenin sisteme girip oluşturmasına gerek kalmadan gelir. Rapor tanımında tarih aralığı, sıklık, gün, saat ve e-posta alıcıları belirlenir. Böylece inceleme, denetimden bir hafta önce birinin raporu çalıştırmayı hatırlamasına bağlı kalmaz.
Kimsenin kullanmadığı hesaplar da listelenebilir. Etkin ve ayrıcalıklı olmasına rağmen uzun süredir oturum açmamış bir hesabın bilinmesi önemlidir; raporlanmadıkça görünmez kalır.
Bugün kim, hangi sisteme erişebiliyor?
Erişim matrisi, hangi kullanıcıların hangi sistemlere hangi hesaplarla erişebildiğini tek görünümde gösterir.
Belgelerde yazanı veya son incelemede geçerli olanı değil, mevcut durumu gösterir. Erişim incelemesinin sistem sahiplerinden tek tek bilgi toplayarak oluşturmaya çalıştığı tablo budur; düzenleyicilerin soruları da genellikle buradan başlar. Envanterin nasıl oluşturulup güncel tutulduğunu Ayrıcalıklı Hesap Keşfi sayfasında bulabilirsiniz.
Kavram kanıtında mutlaka test edilmesi gereken iki şey
Üç oturum kaydı isteyin, bir tane değil
Her PAM ürünü kendi tarayıcısında yürüttüğü oturumu kaydedebilir. Oturum zaten üreticinin tarafında çalıştığı için kaydetmek nispeten kolaydır.
Bunun yerine üç kayıt isteyin: yerel RDP oturumu, yerel SSH oturumu ve bir web konsolu; örneğin güvenlik duvarı, hipervizör veya yedekleme sistemi. Kapsamın en sık bittiği yer üçüncüsüdür.
Mirket üçünü de kaydeder. Yönetici, oluşturulan .rdp dosyasını Microsoft Remote Desktop ile açar, Mirket ajanına yerleşik SSH araçlarını kullanır veya izole tarayıcıdan web konsoluna erişir. Kimlik bilgileri her yöntemde oturuma aktarılır, pano ve dosya aktarım kuralları her yöntemde geçerlidir ve her oturum aynı video ile aranabilir metin dökümünü üretir.
Arayamadığınız bir kayıt, kanıt değildir
Sekiz saatlik RDP kaydı tek başına denetim izi değildir. Sadece sekiz saatlik videodur.
Denetçi saat 14.40’ta ne olduğunu sorduğunda veya olay müdahale ekibi belirli bir komutun çalıştırılıp çalıştırılmadığını öğrenmek istediğinde, güvenlik kontrolüyle video arşivi arasındaki fark yanıtı bulabilmektir.
Mirket, videoyla birlikte metin dökümü de oluşturur. Komutu aradığınızda oynatıcı yazıldığı ana gider. Engellenen ve işaretlenen komutlar önceden belirtilir; önemli anları tek tek bulmanız gerekmez. Döküm, video oluşturulmadan okunabilir ve kanıtın platform dışına çıkarılması gerektiğinde dışa aktarılabilir.
Denetim ve uyumluluk
Mirket tek başına mevzuata uyum sağlamaz; hiçbir ürün sağlamaz. Aşağıda ayrıcalıklı erişimin genellikle değerlendirildiği gereksinimler ve platformun bunları karşılamak için sunduğu kanıtlar yer alıyor.
PCI DSS v4.x
Gereksinim 7 ve 8Erişimin rolün gerektirdiği düzeyle sınırlandırılması ve paylaşılan ayrıcalıklı hesapların bireysel kullanıcılarla ilişkilendirilmesi. Erişim matrisi, mevcut durumu elle birleştirmeden gösterir.
PCI DSS v4.x
Gereksinim 10Yönetici erişimi olan herkesin işlemleri kaydedilir. Oturum videosu ve komut dökümü yalnızca bağlantıyı değil, yapılan işlemi de belgeler.
ISO/IEC 27001:2022
A.8.2, A.8.15, A.8.18Ayrıcalıklı erişim hakları, günlük kaydı ve ayrıcalıklı yardımcı programların kullanımı.
NIS2
Madde 21Temel ve önemli kuruluşlar için erişim kontrolü, çok faktörlü kimlik doğrulama ve varlık yönetimi.
Kurulum Seçenekleri
Kurum içinde, Linux üzerinde. Kurulup yönetilmesi gereken ayrı Windows atlama sunucuları olmadan.
PAM ek işletim sistemi lisansı gerektirmez. Erişilen sistemlere de hiçbir şey kurulmaz: sunucularda veya uygulamalarda ajan yoktur.
Mirket Portal MFA, SSO veya Self-Servis için zaten çalışıyorsa PAM bu portalın bir modülüdür. İkinci sunucu veya ikinci yönetim konsolu gerekmez.
Kullanıcı tarafında yalnızca erişim yöntemi seçilir: Mirket’in izole tarayıcısı, portaldan alınan tek kullanımlık başlatıcı veya Mirket ajanı. Bunların yalnızca sonuncusu kurulum gerektirir.
Yüksek erişilebilirlik aktif-pasif çiftle sağlanır. Yedek düğüm aktif düğümle sürekli eşitlenir; aktif düğüm yanıt vermediğinde görevi otomatik devralır. Linux üzerinde çalışmak, tek bir sunucuya bağımlı olmak anlamına gelmez.
İki modelden birini seçersiniz. Kullanıcı bazlı lisanslama sabit ekipler için öngörülebilirdir; eşzamanlı lisanslama aynı anda aktif oturumları sayar ve ayrıcalıklı hesabı olan çok kişi olsa da aynı anda az kişi bağlanıyorsa daha ekonomiktir.
Varlık başına lisans yok: Yönetilen sunuculara değil, kullanıcılara ödeme yaparsınız. Kurum içi erişim için ZTNA lisansı gerekmez (Mirket Native Client, PAM’e dahildir).
