PEDM ile Yükseltilmiş Kalıcı Ayrıcalıklar Arasındaki Fark: Yardım Masasını Sürükleyecek Şekilde Erişimi Kontrol Edin.

Ani Khachatryan — Syteca’nın Baş Teknoloji Sorumlusu

Ekinizin yükseltilmiş ayrıcalıklara ihtiyacı var: yazılım kurma, uç noktalarda sorun giderme, onaylı araçları çalıştırma ve sunucuları yönetme gibi görevleri yerine getirmek için. Ancak bu ayrıcalıklara tüm süre boyunca ihtiyaçları var mı?

Sorun şudur ki, kalıcı erişim işleri kolaylaştırır ama gereksiz ayrıcalıkları yerinde bırakır. Bunu tamamen kaldırmak ise genellikle gecikmelere ve artan yükseltme isteklerine yol açar.

PEDM farklı bir yaklaşım sunar: belirli bir işlem için, sınırlı bir süre boyunca, güvenlik ekibinizin belirlediği kurallar altında zamanında yükseltme. Bu makale, böyle bir modelin nasıl işlediğini ve kalıcı ayrıcalıkları helpdesk’inizi aşırı yüklemeden nasıl azaltabileceğinizi açıklar.

Neden kalıcı ayrıcalıklar gereksiz maruz bırakır#

Kalırcı ayrıcalıklar, kullanıcıların buna ihtiyaç duyup duymadıklarından bağımsız olarak etkin kalır. Windows istasyonundaki yerel yönetici hakları yaygın bir örnektir; ancak aynı sorun geniş sunucu erişimi, ortak yönetici hesapları ya da “belki lazım olur” diye saklanan yükseltilmiş haklarla da karşılaşıldığında ortaya çıkar.

Sorun, erişimin amacını aşıp ömrünü tamamladığında başlar.

Bir kullanıcı, onaylı bir uygulamanın kurulması için yükseltilmiş haklara bir kez ihtiyaç duyabilir. Aylar sonra bu haklara hala sahip olup güvenlik ayarlarını değiştirebilir, yazılım kurabilir, hizmetleri düzenleyebilir ve betik çalıştırabilir. Bu varsayılan yönetici hakları riski, orijinal görev tamamlandıktan çok sonra da sürer. Uç nokta ya da hesap ele geçirilirse, yükseltilmiş ayrıcalıklar saldırgana saldırıyı genişletmesi için daha çok yol açabilir.

Ransomware ve diğer uç nokta saldırılarında, yükseltilmiş erişim kontrolleri devre dışı bırakmak, kalıcılık kurmak ya da daha değerli sistemlere doğru daha ileri gitmek için kullanılabilir. Yanal hareket yine kimlik bilgilerine, ağ erişimine ve exploitable açıklara dayanır; ancak ayrıcalıkları azaltmak saldırganların seçeneklerini kısıtabilir.

Neden plansız ayrıcalık kaldırma sürtüşme yaratır#

Sorun, kullanıcı iş akışlarını haritalandırmadan erişimi kaldırdığınızda başlar:

Kullanıcılar engellenir. İstekler birikir. IT, tekrarlayan onay istekleriyle uğraşmaya zaman harcar. Bazı kişiler farklı bir güvenlik sorunu yaratan işe yarar geçiş yolları arar. Şunları görebilirsiniz:

• Geciken yazılım kurulumları ve güncellemeleri
• Rutin işlemler için sürekli “yönetici olarak çalıştır” talepleri
• Onayların sohbet, e-posta veya gayrîresmî istekler üzerinden yürütülmesi
• Erişimi kimin, neden ve ne için istediğine dair net bir kayıt bulunmaması
• İşlerin akışını sürdürmek için geniş ayrıcalıkların geri verilmesi baskısı

Bu sürtüşme, birçok ekibin ayrıcalıklı erişimi yerinde tutmasının nedenini açıklar. Güvenlik daha az erişim ister. Helpdesk daha az talep ister. İş birimi kesintisiz iş akışı ister.

Bunlardan birini seçmek zorunda değilsiniz. Yükseltilmiş erişimin ne zaman uygun olduğuna karar veren otomatik bir yönteme ihtiyacınız var.

PEDM neyi değiştirir: Eylemi yükselt, kullanıcıyı değil#

Ayrıcalıklı erişim ve devretme yönetimi (PEDM), kararı “Bu ayrıcalıklı bir kullanıcı mı?” sorusundan “Bu belirli eylem yükseltilmiş haklar almalı mı?” sorusuna taşır.

Bu ayrım, ayrıcalıklı işleri nasıl yönettiğiniz değiştirir.

Bir kullanıcının onaylı tek bir kurulum programını çalıştırması gerekebilir. Bu, kalıcı yerel yönetici ayrıcalıklarına sahip olması gerektiği anlamına gelmez. Benzer şekilde, bir destek teknisyeninin bir cihazı sorun gidermesi gerekebilir. Bu, her yönetici ayarına sınırsız erişimi olması gerektiği anlamına gelmez.

“Ayrıcalıklı erişim ve devretme yönetimi (PEDM) araçlarını kullanarak uç noktalarda kalıcı yerel yönetici ayrıcalıklarını kaldırın ve belirli süreçleri, uygulamaları ve komutları sorunsuz şekilde yükseltin. Bu granüler kontrol, yeterli düzeyde erişim sağlayarak güvenlik durumunu iyileştirir.”

Gartner, How to Manage Admin Privileges on Endpoints (abonelik gerekli)

PEDM, görevi kişinin günlük erişiminden ayırır:

• Kapsam: Hangi uygulama, komut, betik veya görev yükseltilbilir?
• Süre: Yükseltme ne zaman izin verilir ve ne kadar sürer?
• Şartlar: Eylemin onay, gerekçe veya ek doğrulama gerekip gerekmediği?
• Sorumluluk: Kim istedi, kim onayladı ve hangi karar verildi?

Bir kullanıcı bir eylem başlattığında, politika üç sonuçtan birini üretir:

1. Otomatik olarak izin ver: Tanımlanmış kuralları karşılayan güvenilir işlemler için.
2. Onay iste: Hassas veya istisnai talepler için.
3. Reddet: Politikanın izin vermediği işlemler için.

Bu şekilde PEDM, uç noktalarda duran ayrıcalıksız (zero standing privileges) modeli destekler. Amaç, ayrıcalıklı çalışmayı imkânsız kılmak değildir. Yükseltilmiş erişimin yalnızca meşru bir işlemin gerektiği durumlarda mevcut olmasını sağlamaktır.

PEDM ile duran ayrıcalıklar: İşletim modellerinin karşılaştırılması#

Fark, basitçe “daha fazla güvenlik” ile “daha fazla kolaylık” arasındaki fark değildir. Ayrıcalığın atanması, kullanımı ve gözden geçirilmesi biçimindeki farktır.

Temel işletim noktası şudur: PEDM, rutin çalışmanın, her görev için birinin onayını gerektirmeden akmasını sağlamalıdır.

Politikanızın IT biriminin her meşru kurulumu veya güncellemeyi onaylamasını zorlaması, duran ayrıcalıkları yeni bir darboğazla değiştirmek olur. Etkili PEDM, öngörülebilir olanı otomatikleştirir. İnsan değerlendirmesini gerçekten yargı gerektiren işlemler için saklar.

Duran ayrıcalıkları helpdeski boğmadan nasıl kaldırırız#

Duran ayrıcalıkları, meşru çalışmayı kesintiye uğratmadan azaltabilirsiniz; ancak önce gerçekten hangi çalışmanın yükseltme gerektirdiğini anlamış olmanız gerekir.

1. Ayrıcalıklı erişimin gerçekten nerede gerektiğini keşfedin#

Öncelikle, şu anda yükseltilmiş erişime sahip olanların kimler olduğunu ve bunu neden yaptığını belirleyin. Açık yerel yöneticilerin ötesine bakın. Destek personeli, geliştiriciler, teknisyenler ve düzenli olarak kurulum programları, tanı araçları veya yönetici betiklerini çalıştıran herkesi dahil edin.

Ardından faaliyeti gruplandırın:

• Onaylı yazılım kurulumları ve güncellemeleri
• IT desteği ve sorun giderme görevleri
• Yükseltilmiş çalıştırma gerektiren eski (legacy) uygulamalar
• Tek seferlik veya nadir yönetici işlemleri
• Hiçbir şekilde yükseltme almaması gereken işlemler

Bu size bir taban (baseline) sağlar. Bu olmadan, kullanıcıların ihtiyaç duyduğu erişimi kaldırma ya da onları tekrar aşırı ayrıcalıklı hale getiren istisnalar verme riski taşırsınız.

2. Güvenilir uygulamalar için dar kapsamlı kurallar oluşturun#

Yükseltmeyi yalnızca kullanıcının unvanına dayandırmayın. Kuralları eylemin kendisi etrafında tanımlayın.

Örneğin, bir politika belirli bir kurulumcının yükseltilmiş haklarla çalışmasına izin verebilirken, tanımlanmayan bir çalıştırılabilir dosyaya aynı muameleyi reddedebilir. Kurallar dosya özeti, dijital imza, çalıştırılabilir dosya adı, yol öneki veya komut satırı parametreleri gibi öznitelikleri kullanabilir.

İsabet önemlidir: güvenilir bir imza veya yol bir uygulamanın tanımlanmasına yardımcı olur, ancak bunun her eylemin güvenli olduğunun kanıtı olarak ele alınması gerekir. Her kuralın izin verdiklerini sınırlayın, böylece onaylanmış bir güncelleme ilgisiz yazılıma kapı açmasın.

3. Onayları gerçek istisnalar için saklayın#

Bazı eylemler otomatik olarak yükseltilmemeli. Tanımlanmayan bir yazılımı kurma talebi, kritik bir ayarı değiştirme veya normal çalışma saatleri dışında bir betik çalıştırma gibi durumlar insan değerlendirmesi gerektirebilir.

Bu tür durumlar için şunları isteyin:

• İsteyiciden açık bir gerekçe
• Atanmış bir onaylayıcı
• Verilen erişime zaman sınırı
• Yükseltmeden önce isteğe bağlı MFA

Onaylayıcıların neyi onayladığını bildiğinden emin olun. “Yönetici haklarına ihtiyacım var” yeterli bağlam değildir. Uzmanlaşan bir uygulamanı, yükseltme nedenini ve beklenen süreyi belirleyen bir talep böyledir.

4. Genişlemeden önce küçük başlayın#

Günü birinci gün tüm filo genelinde duran ayrıcalıkları kaldırmayın.

Temsili bir uç nokta ve kullanıcı grubuyla başlayın. Dayandıkları uygulamaları, güncellemeleri, betikleri ve destek iş akışlarını test edin. Meşru bir görev başarısız olduğunda, derhal geniş erişim vermektense politikanı ayarlayın.

Ayrıca bir acil durum yolu tanımlayın. Normal saatler dışında bir şey bozulduğunda, ekibinizin politikanı terk etmeden tepki verebilmesi için kontrollü bir yola ihtiyacı vardır.

5. İstisnaları gözden geçirin ve politikaları iyileştirin#

PEDM ayarla-unut bir kontrol olmadığından, verili düzenli olarak gözden geçirmeniz gerekir:

• Dar tanımlı kurallarla halledilebilen tekrarlayan istekleri belirleyin.
• Kullanımı kaldırılan uygulamalar için kuralları kaldırın.
• Sıra dışı reddetme kalıplarını araştırmın.
• Geniş erişime hâlâ sahip olup artık buna ihtiyaçları olmayan kullanıcıları yeniden değerlendirin.

Amaç, kuruluşunuzun gerçekten nasıl işlediğini yansıtan; ilk kurulum sırasında oluşturulan statik bir liste değil, bir politika kümesidir.

Syteca yükseltmeyi nasıl yönetilen bir iş akışına dönüştürüyor#

Syteca Inside Security Platformu, duran yönetici haklarını Windows istasyonları ve sunucularında politika tabanlı yükseltme ile değiştiren bir PEDM modülü sağlar:

Güvenilen uygulamalar farklı özniteliklere dayanarak sessizce yükseltilebilir, hassas istekler için gerekçe ve süre sınırlı onay gerektirilebilir veya yükseltme özel bir mesajla reddedilebilir. Onaylanan işlemler vaulted (kasa) Windows veya AD kimlik bilgileri altında çalışabilir. Her karar kaydedilir. İsteğe bağlı oturum kaydı, soruşturmalar için ekran etkinliğini, girdiyi ve komutları yakalar.

Yükseltme kontrolü tüm uç nokta risklerini çözmez. Syteca ERCC, PEDM’i tamamlayarak uç nokta sağlığını, yapılandırma sapmasını ve gölge AI’ı izler ve aynı hafif ajan ve konsol üzerinden rehberli düzeltme sağlar.

Ani Khachatryan — Syteca’nın Teknoloji Direktörü