Erişim Kontrol Politikası Nasıl Yazılır? Bölüm Bölüm Rehber

Ayrılan çalışanın hesabı hâlâ açıksa ya da yıllar içinde yetki biriktirmiş bir kullanıcı her paylaşıma erişebiliyorsa, sorun çoğu zaman teknik değil, politikadadır. Erişim kontrol politikası BGYS’de en çok atıf alan konu bazlı politikadır: hesap açma, yönetici yetkisi, parola kuralları, yetki gözden geçirme ve ayrılış süreçlerinin hepsi bu metne dayanır. Buna rağmen birçok kurumda politika ya üç cümlelik bir niyet beyanıdır ya da Group Policy ayarlarının listesine dönmüştür. İkisi de işe yaramaz. Aşağıda ISO/IEC 27001:2022 Annex A kontrollerini karşılayan bir erişim kontrol politikasının bölümlerini, her bölüme ne yazılacağını ve ne yazılmayacağını örnek maddelerle veriyoruz.

Politikanın karşılaması gereken kontroller

Erişim kontrol politikası tek bir kontrole değil, birbirine bağlı bir kontrol grubuna dayanak sağlar. Yazmaya başlamadan önce hangi kontrollerin bu dokümanla karşılanacağını SoA üzerinde işaretleyin; kapsam kaymasını baştan önlersiniz.

Kontrol	Konu	Politikadaki karşılığı
5.15	Erişim kontrolü	İlkeler, iş ve güvenlik gerekliliklerine dayalı kurallar
5.16	Kimlik yönetimi	Kimliklerin tam yaşam döngüsü, paylaşılan hesap kuralı
5.17	Kimlik doğrulama bilgisi	Parola ve doğrulama bilgisinin tahsisi ve korunması
5.18	Erişim hakları	Yetki verme, değiştirme, gözden geçirme, kaldırma
8.2	Ayrıcalıklı erişim hakları	Yönetici yetkisinin kısıtlanması ve yönetimi
5.3	Görevlerin ayrılığı	Çatışan görevlerin aynı kişide birleşmemesi
8.5	Güvenli kimlik doğrulama	Çok faktörlü doğrulama gerektiren durumlar

ISO/IEC 27002:2022, 5.15 rehberliğinde erişim kontrol kurallarının konu bazlı bir politikayla tanımlanmasını ve kuralların iş ve bilgi güvenliği gerekliliklerine dayanmasını önerir. Üst politika ile bu konu bazlı politika arasındaki ilişki için bilgi güvenliği politikası yazım rehberine bakabilirsiniz.

Temel ilkeler: en az yetki, bilmesi gereken, görevler ayrılığı

İlk bölüm, sonraki bütün maddelerin yorumlanacağı ilkeleri koyar. Kısa yazın ama bağlayıcı yazın. “Mümkün olduğunca” gibi yumuşatıcılar ilkeyi tartışmaya açar ve ilk istisna talebinde ilke çöker.

• Bilmesi gereken (need-to-know): Kullanıcı yalnız görevini yapmak için ihtiyaç duyduğu bilgiye erişir.
• Kullanması gereken (need-to-use) ve en az yetki: Kullanıcıya görevi için gereken en düşük yetki seviyesi, yalnız gereken süre boyunca verilir.
• Varsayılan ret: Açıkça izin verilmeyen erişim yasaktır. Yeni sistem devreye alındığında erişim açık değil, kapalı başlar.
• Görevlerin ayrılığı: Talep eden, onaylayan ve uygulayan roller ayrılır; çatışan görevler aynı kişide birleşmez, birleşmesi kaçınılmazsa telafi edici kontrol tanımlanır.
• Bireysel hesap: Her erişim tek bir kişiye izlenebilir olmalı. Paylaşılan hesap yalnız teknik zorunlulukta ve onaylı istisnayla kullanılır.

Erişim modeli de bu bölümde yazılır: kurum yetkileri rol bazlı (RBAC) mı veriyor, belirli sistemlerde öznitelik bazlı (ABAC) kurallar mı kullanıyor? Rol tanımlarının kendisi politikaya değil, sistem bazlı rol matrislerine girer.

Kimlik yaşam döngüsü: işe giriş, değişiklik, ayrılış

Bu bölüm, İK süreçleri ile BT işlemlerini birbirine bağlar. Sahada en sık bulduğumuz iki zafiyet buradan çıkar: ayrılan çalışanın açık kalan hesabı ve görev değişikliğinde biriken yetkiler. İkisinin de kökü, İK’dan BT’ye giden bildirimin tanımsız olmasıdır. Politika her olay için tetikleyiciyi, sorumluyu ve süre hedefini belirler; işlem adımlarını prosedüre bırakır.

• İşe giriş: Hesap, İK’nın onaylı işe giriş bildirimi olmadan açılmaz. Başlangıç yetkileri rolün standart yetki setiyle sınırlıdır; ek yetkiler ayrı talep ve onayla verilir.
• Görev değişikliği: Yeni rolün yetkileri verilirken eski rolün yetkileri devir süresi sonunda kaldırılır. Devir süresi politikada üst sınırla tanımlanır; üst sınırsız devir, kalıcı yetki demektir.
• Ayrılış: Hesaplar ayrılış tarihinde devre dışı bırakılır. Kurumla ilişkisi sorunlu biten ayrılışlarda devre dışı bırakma, bildirimle eş zamanlı yapılır.
• Uzun süreli izin ve pasif hesaplar: Belirli süre kullanılmayan hesaplar otomatik veya periyodik kontrolle devre dışı bırakılır. Süre kurumun kararıdır ve teknik standartta yer alır.
• Dış kullanıcılar: Tedarikçi, danışman ve misafir hesapları bir kurum içi sponsora bağlanır ve bitiş tarihiyle açılır. Bitiş tarihi olmayan tedarikçi hesabı, proje bittikten yıllar sonra da çalışır.

Ayrıcalıklı erişim bölümü

Annex A 8.2, ayrıcalıklı erişim haklarının tahsisinin ve kullanımının kısıtlanmasını ve yönetilmesini ister. Kapsam yalnız alan yöneticisi değildir; veritabanı yöneticileri, bulut abonelik sahipleri, ağ cihazı yönetim hesapları, yedekleme konsolu ve güvenlik araçlarının yönetici rolleri de buraya girer. Yedekleme konsolu sık unutulur. Fidye yazılımı saldırılarında yedekleri silen de çoğu zaman o konsoldaki yönetici hesabıdır. Politikada şu kararlar yer almalı:

• Ayrıcalıklı yetkiler, kişinin günlük kullanıcı hesabından ayrı bir yönetici hesabıyla kullanılır; yönetici hesabıyla e-posta ve genel internet kullanımı yapılmaz.
• Ayrıcalıklı yetki, mümkün olan sistemlerde kalıcı değil süreli olarak (tam zamanında erişim) verilir.
• Ayrıcalıklı hesaplar için çok faktörlü kimlik doğrulama zorunludur.
• Ayrıcalıklı hesapların kullanımı loglanır ve loglar, hesabı kullanan kişinin silemeyeceği bir ortamda tutulur.
• Acil durum (“break-glass”) hesapları ayrı listelenir; kullanımları olay olarak kaydedilir ve sonrasında gözden geçirilir.
• Ayrıcalıklı yetkiler, standart kullanıcı yetkilerinden daha sık gözden geçirilir.

Teknik uygulama platforma göre değişir; Microsoft ortamlarında süreli yönetici yetkisinin uygulama tarafını Entra ID PIM yapılandırması yazısı anlatıyor. Politika ise ürün adı vermeden kuralı koyar.

Periyodik gözden geçirme ve istisnalar

Annex A 5.18, erişim haklarının tahsis, değişiklik ve kaldırılmasının yanında gözden geçirilmesini de erişim kontrol kurallarına bağlar; ISO/IEC 27002:2022 rehberliği bu gözden geçirmenin düzenli aralıklarla ve rol değişikliklerinde yapılmasını önerir. Politika, gözden geçirmeyi kimin ve hangi sıklıkta yapacağını belirler. Gözden geçirmeyi BT değil, bilginin veya uygulamanın sahibi yapar. BT listeyi üretir ve kaldırılması istenen yetkileri uygular. Sıklık riske bağlanır: ayrıcalıklı hesaplar ve hassas veri içeren sistemler daha sık, düşük riskli sistemler daha seyrek gözden geçirilir.

Sahada tipik tablo şudur: uygulama sahibi kendisine gelen yüzlerce satırlık listeyi okumadan onaylar ve gözden geçirme imzaya dönüşür. Bunu önlemek için listeyi sahibin anlayacağı dille (teknik grup adı değil, iş rolü) üretin. Gözden geçirmenin denetimde nasıl kanıtlanacağı planlanan erişim gözden geçirme kanıtı rehberinde anlatılıyor. Politikanın burada yapması gereken, zorunlu çıktıyı tanımlamaktır: kim, hangi listeyi, hangi tarihte gözden geçirdi ve hangi değişiklikleri talep etti.

İstisnalar bölümü kısa tutulur: politikaya uyulamayan durumda istisna kimden talep edilir, kim onaylar, azami süresi nedir, nereye kaydedilir. İstisna sürecinin tasarımı politika istisnası yönetimi yazısının konusu; erişim politikası yalnız o sürece atıf yapar.

Politika–standart–prosedür ayrımı

Erişim kontrol politikalarının en sık bozulma nedeni, teknik parametrelerin politika metnine girmesidir. Parola uzunluğu değiştiği için üst yönetim onayı gerektiren bir politika revizyonu yapmak gereksiz yüktür. Sonuçta revizyon ertelenir. Metin ile sistem birbirinden kopar. Aşağıdaki ayrım, bir bilgi güvenliği politika paketi içinde hangi detayın hangi dokümana ait olduğunu gösterir.

Konu	Politika	Teknik standart	Prosedür / talimat
Parola	Güçlü kimlik doğrulama zorunlu	Uzunluk, yasaklı parola listesi, kilitleme eşiği	Parola sıfırlama adımları
MFA	Uzaktan ve ayrıcalıklı erişimde zorunlu	İzin verilen yöntemler	Kayıt ve cihaz değişikliği
Pasif hesap	Kullanılmayan hesaplar kapatılır	Gün sayısı eşiği	Raporlama ve kapatma adımları
Yetki gözden geçirme	Sahip tarafından, riske göre periyodik	Sistem bazlı sıklık tablosu	Liste üretme ve onay akışı
Yönetici hesabı	Ayrı hesap, süreli yetki	Adlandırma kuralı, oturum kısıtları	Yetki yükseltme talimatı

Prosedür ve talimat yazımında dikkat edilecek noktalar için prosedür ve talimat yazımı rehberine bakabilirsiniz.

Örnek politika maddeleri

Aşağıdaki maddeler bir başlangıç taslağıdır; rol adlarını ve süreleri kurumun gerçek yapısına göre uyarlayın.

4.1 Bilgi sistemlerine erişim, iş gerekliliğine dayalı ve onaylı bir talep olmadan verilmez. Talebi, kullanıcının yöneticisi; erişilen sistemin veya bilginin sahibi onaylar.

4.2 Her kullanıcıya kişisel ve tekil bir hesap tanımlanır. Paylaşılan hesaplar, yalnız teknik zorunluluk halinde, bilgi güvenliği sorumlusunun onayladığı istisna kaydı ile kullanılır.

4.3 Ayrılan personelin tüm hesapları, İK’nın bildirdiği ayrılış tarihinde devre dışı bırakılır.

4.4 Ayrıcalıklı yetkiler, kullanıcının günlük hesabından ayrı bir hesapla ve çok faktörlü kimlik doğrulama ile kullanılır.

4.5 Sistem ve bilgi sahipleri, sorumlu oldukları sistemlerdeki erişim haklarını Erişim Kontrol Standardı’nda belirtilen aralıklarla gözden geçirir ve sonucu kayıt altına alır.

4.6 Bu politikaya aykırı erişim tespit edildiğinde yetki derhal kaldırılır ve olay, bilgi güvenliği olay yönetimi sürecine göre kaydedilir.

Yayın öncesi kontrol listesi

• SoA’daki ilgili kontrollerin her biri politikada en az bir maddeyle karşılanıyor.
• Teknik parametreler politikada değil, atıf yapılan standartta.
• Her maddenin sorumlusu rol adıyla belirtilmiş ve görev tanımlarıyla tutarlı.
• İK ayrılış ve görev değişikliği süreçleri politikadaki tetikleyicilerle uyumlu.
• İstisna ve ihlal durumları ilgili süreçlere bağlanmış.
• Politika kapsamdaki çalışanlara duyurulmuş ve duyuru kaydı tutulmuş.

Politikanın sahada gerçekten uygulanıp uygulanmadığını görmenin en hızlı yolu, mevcut hesap ve yetkilerin bağımsız gözden geçirmesidir. Dizinden alınan tek bir rapor, politikanın kaç maddesinin kâğıtta kaldığını gösterir. Bu çalışmayı erişim yetkileri ve kullanıcı hesabı denetimi kapsamında yapıyoruz. Kontrol rehberliğinin tam metni için ISO/IEC 27002:2022 esas alınmalıdır.

Sık sorulan sorular

Erişim kontrol politikası ile parola politikası ayrı mı olmalı?

Ayrı bir parola politikası zorunlu değildir. Erişim kontrol politikası güçlü kimlik doğrulama ilkesini koyar; uzunluk, kilitleme eşiği ve yasaklı parola listesi gibi parametreler daha kolay güncellenen bir teknik standartta tutulabilir.

Erişim hakları ne sıklıkla gözden geçirilmeli?

ISO 27001 belirli bir sıklık vermez; ISO 27002 rehberliği düzenli aralıklarla gözden geçirme önerir. Sıklık riske göre belirlenir: ayrıcalıklı hesaplar ve hassas veri içeren sistemler daha sık, düşük riskli sistemler daha seyrek gözden geçirilir ve bu sıklık standartta yazılır.

Küçük bir BT ekibinde görevler ayrılığı nasıl sağlanır?

Talep, onay ve uygulama rolleri tamamen ayrılamıyorsa telafi edici kontroller tanımlanır: işlemlerin loglanması, logların başka bir kişi veya yönetici tarafından periyodik gözden geçirilmesi ve kritik değişikliklerde ikinci onay.

Politikada ürün adı kullanmak doğru mu?

Genellikle hayır. Politika, ürün değişse de geçerli kalacak kuralları koyar. Ürün ve yapılandırma detayları teknik standart ve talimatlarda yer alır; böylece sistem değişikliği politika revizyonu gerektirmez.