Kurumsal ortamlarda sık karşılaşılan sorunlardan biri bazı uygulamaların düzgün çalışabilmek için yönetici (administrator) yetkisine ihtiyaç duymasıdır.
Bu durum özellikle eski mimariyle yazılmış veya sistem kaynaklarına doğrudan erişen yazılımlarda ortaya çıkar. Kamera izleme yazılımları (örneğin SmartPSS), bazı endüstriyel kontrol uygulamaları, sürücü tabanlı araçlar ya da “Program Files” altına yazma işlemi yapan eski uygulamalar bu kategoriye girer.
Sorunun en kolay görünen çözümü kullanıcıya yerel yönetici yetkisi vermek ya da yönetici parolasını paylaşmaktır. Ancak bu yaklaşım güvenlik açısından ciddi riskler doğurur kullanıcı yalnızca o uygulamayı değil sistemdeki her şeyi yönetebilir hâle gelir. En az ayrıcalık (least privilege) ilkesiyle de doğrudan çelişir.
Bu makalede, kullanıcıya kalıcı yönetici yetkisi vermeden belirli bir uygulamayı yükseltilmiş haklarla çalıştırmaya yarayan runas /savecred yöntemi detaylı olarak açıklanmakta yöntemin nasıl çalıştığı hangi durumlarda işe yaradığı, taşıdığı güvenlik riskleri ve daha güvenli alternatifleri ele alınmaktadır.
Yöntemin Temel Mantığı
Windows’ta runas komutu bir programı oturum açmış kullanıcıdan farklı bir hesabın kimlik bilgileriyle başlatmaya yarar. Normalde her çalıştırmada hedef hesabın parolası istenir. Bu da otomasyon veya standart kullanıcı senaryoları için pratik değildir.
İşte burada /savecred parametresi devreye girer. Bu parametre ilk çalıştırmada girilen kimlik bilgilerini Windows Credential Manager (Kimlik Bilgileri Yöneticisi) içinde saklar.
Sonraki çalıştırmalarda parola tekrar sorulmaz; uygulama doğrudan kayıtlı kimlik bilgileriyle açılır.
Böylece kullanıcı:
- yönetici parolasını bilmeden,
- yönetici hesabıyla oturum açmadan,
- yalnızca ilgili kısayola tıklayarak uygulamayı yükseltilmiş haklarla çalıştırabilir.
Kullanılan Komut
Aşağıdaki komut, belirli bir uygulamanın yönetici hesabı üzerinden çalıştırılması için kullanılabilecek yöntemlerden biridir;
C:\Windows\System32\runas.exe /user:BILGISAYAR_ADI\Administrator /savecred "cmd /c cd /d \"C:\Program Files\Program Klasörü\" && start \"\" Program.exe"Komutun bölümleri ne işe yarar?
| Bölüm | Açıklama |
|---|---|
runas.exe | Programı farklı bir kullanıcı bağlamında başlatan Windows aracı. |
/user:BILGISAYAR_ADI\Administrator | Uygulamanın çalıştırılacağı hesap. BILGISAYAR_ADI cihazın adıyla değiştirilir. Etki alanı (domain) hesabı kullanılacaksa DOMAIN\kullanici biçimi yazılır. |
/savecred | Kimlik bilgilerini Credential Manager’a kaydeder; parolanın yalnızca bir kez girilmesini sağlar. |
cmd /c | Devamındaki komutu çalıştırıp kapanan bir komut satırı başlatır. |
cd /d "..." | Uygulamanın bulunduğu klasöre, gerekirse sürücü değiştirerek geçiş yapar. |
start "" Program.exe | Uygulamayı başlatır. İlk boş "", start komutunun pencere başlığı beklentisini karşılamak için konur. |
Adım Adım Uygulama
- Cihaz adını öğrenin. Komut isteminde
hostnameyazarak bilgisayar adınızı görebilir komuttakiBILGISAYAR_ADIalanını bununla değiştirebilirsiniz. - Uygulama yolunu düzenleyin.
Program KlasörüveProgram.exealanlarını çalıştırmak istediğiniz uygulamaya göre uyarlayın. Örneğin SmartPSS için bu yol genellikleC:\Program Files (x86)\...\SmartPSSbiçimindedir. - Komutu kaydedin. Komutu bir
.batdosyasına yazın veya masaüstünde bir kısayol oluşturun. Kısayol kullanacaksanız, hedef alanına yukarıdaki tam komutu girebilirsiniz. - İlk çalıştırmada parolayı girin. Dosyayı/kısayolu ilk kez çalıştırdığınızda belirtilen hesabın (örneğin Administrator) parolası istenir. Bu, kimlik bilgilerinin kaydedilmesi için yalnızca bir kez gereklidir.
- Sonraki çalıştırmalarda otomatik açılır. Bundan sonra uygulama kayıtlı kimlik bilgileriyle parola sorulmadan açılacaktır.
İpucu: Kimlik bilgilerinin kaydedilip kaydedilmediğini kontrol etmek için
cmdkey /listkomutunu kullanabilirsiniz. Kayıtlı bir girişi silmek için isecmdkey /delete:<hedef>komutu kullanılır.
Bu Yöntem Hangi Durumlarda Uygundur?
runas /savecred, hızlı ve düşük maliyetli bir çözüm olarak şu senaryolarda pratik olabilir:
- Tek bir kullanıcının, tek bir bilgisayarda, tek bir uygulamaya erişmesi gereken küçük ölçekli durumlar.
- Etki alanına bağlı olmayan, izole çalışan cihazlar.
- Kalıcı bir altyapı yatırımı (PAM, GPO vb.) yapmanın orantısız kaçacağı geçici çözümler.
Bununla birlikte bu yöntemin kurumsal ölçekte standart bir uygulama olmadığını ve önemli güvenlik etkileri taşıdığını unutmamak gerekir.
Güvenlik Etkileri – Dikkatle Değerlendirilmesi Gerekenler
/savecred parametresinin sunduğu kolaylık beraberinde önemli bir risk getirir. Bu riski net olarak anlamak, yöntemi kullanıp kullanmama kararını sağlıklı vermek açısından kritiktir.
1. Kaydedilen kimlik bilgisi yalnızca o uygulamaya özel değildir
/savecred ile saklanan kimlik bilgileri ilgili kullanıcı profiline bağlanır ve o kullanıcının başlattığı tüm runas /savecred komutları için yeniden kullanılabilir.
Yani uygulamayı çalıştırması için yetki verdiğiniz standart kullanıcı, kayıtlı kimlik bilgileri var olduğu sürece şu komutu çalıştırarak tam yetkili bir yönetici komut istemi açabilir.
runas /user:BILGISAYAR_ADI\Administrator /savecred cmdBu, yöntemin en kritik açığıdır: niyetiniz yalnızca bir uygulamaya erişim vermekken, pratikte kullanıcıya fiilen yönetici düzeyinde erişim açmış olabilirsiniz. Dolayısıyla “kullanıcıya yönetici yetkisi vermedik” varsayımı, bu senaryoda gerçeği tam yansıtmaz.
2. Paylaşılan/yerleşik Administrator hesabı kullanımı sakıncalıdır
Yerleşik Administrator gibi paylaşılan bir hesabın kimlik bilgilerini cihazlarda saklamak, izlenebilirliği (auditability) zayıflatır. Hangi işlemi gerçekte kimin yaptığı belirsizleşir. Bu hesabın parolası değiştiğinde de kayıtlı kimlik bilgileri geçersiz hâle gelir ve sürecin yeniden yapılandırılması gerekir.
3. Saldırı yüzeyi ve yetki yükseltme riski
Cihaz ele geçirilirse veya kötü amaçlı bir yerel kullanıcı söz konusuysa, kayıtlı yönetici kimlik bilgileri bir yetki yükseltme (privilege escalation) aracına dönüşebilir. Bu nedenle güvenlik denetimlerinde cmdkey ile saklanan yönetici kimlik bilgileri genellikle bir bulgu olarak işaretlenir.
4. Politika uyumu
Birçok kurumun güvenlik politikası, paylaşılan yönetici parolalarının istemci cihazlarda saklanmasını yasaklar. Yöntemi uygulamadan önce kurumun bilgi güvenliği politikalarıyla uyumun doğrulanması gerekir.
Daha Güvenli Alternatifler
Pek çok durumda, bir uygulamanın gerçekte neden yönetici yetkisi istediği incelendiğinde, sorunu kök nedeninden çözen ve kimlik bilgisi saklamayı gerektirmeyen alternatifler bulunabilir.
1. Uygulamanın gerçek ihtiyacını gidermek (en temiz çözüm)
Birçok uygulama, aslında tüm sistemde değil, yalnızca belirli bir klasöre, kayıt defteri anahtarına veya servise yazma izni olmadığı için yönetici ister. Bu durumda:
- İlgili klasöre (
Program Filesaltındaki uygulama dizini,ProgramDataveya log klasörleri) standart kullanıcı için NTFS yazma izni vermek, - Uygulamanın eriştiği kayıt defteri anahtarına okuma/yazma izni tanımlamak,
çoğu zaman yönetici ihtiyacını tamamen ortadan kaldırır. Bu yaklaşım, en az ayrıcalık ilkesine en uygun olanıdır.
2. Görev Zamanlayıcı (Task Scheduler) yöntemi
Uygulama, “En yüksek ayrıcalıklarla çalıştır” seçeneği işaretli bir zamanlanmış görev olarak tanımlanır. Ardından standart kullanıcı için, bu görevi tetikleyen yükseltilmemiş bir kısayol oluşturulur (schtasks /run /tn "GorevAdi"). Bu yöntemin avantajı, herhangi bir yönetici parolasının istemcide saklanmamasıdır; görev, tanımlandığı yetki bağlamında çalışır.
3. RunAsInvoker / uygulama uyumluluk ayarları
Bazı uygulamalar yönetici yetkisini fiilen kullanmaz, yalnızca manifest dosyalarında öyle talep eder. __COMPAT_LAYER=RunAsInvoker ortam değişkeni ya da Application Compatibility Toolkit (ACT) shim’leri ile bu talebi devre dışı bırakıp uygulamayı standart kullanıcı bağlamında çalıştırmak mümkün olabilir. Her uygulamada işe yaramaz, ancak denenmeye değerdir.
4. Grup İlkesi (GPO) ve merkezi yönetim
Etki alanı ortamlarında, dosya/kayıt izinleri ve uygulama dağıtımı Grup İlkesi üzerinden merkezî ve denetlenebilir biçimde yönetilebilir. Bu, tek tek cihazlara kimlik bilgisi gömmekten çok daha sürdürülebilir bir yaklaşımdır.
5. Ayrıcalık yönetimi (PAM / EPM) çözümleri
Daha olgun ortamlarda, endpoint privilege management (örneğin uygulama bazlı yükseltme sağlayan ticari/yerleşik çözümler) ile yalnızca belirli uygulamalara, denetim kayıtları tutularak, geçici (just-in-time) yükseltme verilebilir. Yönetici parolası için ise Windows LAPS, her cihaza benzersiz ve düzenli rotasyona giren bir yerel yönetici parolası atayarak paylaşılan parola riskini ortadan kaldırır.
runas /savecred yöntemi, kullanıcıya kalıcı yönetici yetkisi vermeden belirli bir uygulamayı çalıştırmak için hızlı ve uygulaması kolay bir çözüm sunar. Küçük ölçekli, izole ve geçici senaryolarda pratik olabilir.
Ancak bu kolaylığın gizli bir maliyeti vardır: /savecred ile saklanan kimlik bilgileri yalnızca hedeflenen uygulamayla sınırlı kalmaz ve istemeden kullanıcıya geniş bir yönetici erişimi açabilir. Bu nedenle yöntem, “kullanıcıya yönetici yetkisi vermeden” başlığı altında sunulsa da, fiilen taşıdığı risk dikkatle değerlendirilmelidir.
Mümkün olan her durumda, uygulamanın gerçek ihtiyacını gidermek (klasör/kayıt izinleri), Görev Zamanlayıcı tabanlı tetikleme veya merkezî ayrıcalık yönetimi gibi daha güvenli ve sürdürülebilir alternatifler tercih edilmelidir.
