Güvenlik · SQL Server

SQL Server Least Privilege: Açıklanabilir Bir Yetki Modeli

2 dk okuma

Least privilege, güçlü loginleri bir kez temizlemek değildir. Dört soruyu sürekli yanıtlayabilen bir işletim modelidir: Kimin erişimi var, ne yapabiliyor, nerede yapabiliyor ve bu erişime neden hâlâ ihtiyaç duyuluyor?

[company_article_image src=”articles/least-privilege.svg” alt=”Kimlikten rol ve kapsama, oradan audit kanıtına SQL Server least privilege akışı” caption=”Sürdürülebilir erişim; doğrulanmış kimliği iş rolü, dar kapsam ve incelenebilir kanıtla birleştirir.”]

Kimlik doğrulama ile yetkilendirmeyi ayırın

Authentication kimliği doğrular; authorization izin verilen aksiyonları belirler. İnsan kullanıcılar için kişiye özgü, servisler için ayrılmış kimlikler kullanın. Paylaşılan administrator hesapları izlenebilirliği ve güvenli iptali zayıflatır.

Yetkiyi kullanıcıya değil role verin

İş fonksiyonlarını database role yapılarına eşleyip kullanıcıları bu rollere ekleyin. Direct grant zamanla görünmez bir borca dönüşür. Daha dar bir user-defined role yeterliyken db_owner gibi geniş fixed role kullanmayın.

CREATE ROLE reporting_reader AUTHORIZATION dbo;
GRANT SELECT ON SCHEMA::Reporting TO reporting_reader;
ALTER ROLE reporting_reader ADD MEMBER app_reporting;

Schema seviyesindeki grant yüzlerce object grant değerinden daha anlaşılır olabilir; ancak schema ownership ve içine taşınan objeler kontrol edilmelidir.

Execution context’i mimari karar olarak ele alın

Stored procedure, ownership chaining, module signing ve EXECUTE AS geniş tablo yetkisi vermeden kontrollü operasyon sunabilir. Her yaklaşımın ownership ve key-management etkisi farklıdır. Cross-database davranışı geniş instance ayarları açmadan önce test edin.

Yükseltilmiş yetkiyi süreli tutun

  • İş ve teknik gerekçe isteyin.
  • Server, database, permission ve bitiş zamanını açıkça tanımlayın.
  • Mümkünse ayrı privileged identity kullanın.
  • Onay ve emergency kullanım kanıtını saklayın.
  • Yetkiyi otomatik kaldırıp kaldırıldığını doğrulayın.

Effective permission sonucunu test edin

EXECUTE AS USER = N'app_reporting';
SELECT * FROM sys.fn_my_permissions(NULL, 'DATABASE');
SELECT * FROM sys.fn_my_permissions(N'Reporting', 'SCHEMA');
REVERT;

Catalog sorguları tanımlı grantleri gösterir; gerçek execution context testi role, ownership, deny ve grant birleşiminin sonucunu ortaya çıkarır.

Her erişim yolunun sahibi, amacı, gözden geçirme tarihi ve kaldırma mekanizması olmalıdır. Güçlü model yalnızca yetkisiz erişimi engellemez; meşru erişimi güvenle değiştirilebilecek kadar anlaşılır kılar.

İlgili Makaleler