IAM'de Görevlerin Ayrılığı (Segregation of Duties - SoD): Çakışan Erişimler Nasıl Tespit Edilir, Nasıl Önlenir?

29 Eyl

7 dakikada okunur

Erişim yönetiminde yaygın soru nettir: "Kim, hangi sisteme erişebiliyor?" Ama bu soru, resmin sadece bir kısmını gösterir. Çünkü gerçek risk bu sorunun cevabında değil, cevapların birleştiği yerde saklıdır. Bir kullanıcının elindeki yetkiler tek tek incelendiğinde çoğu zaman tamamen uygun görünür. Sorun, bu yetkiler aynı kişide bir araya geldiğinde oluşabilir.

Bir sistem yöneticisinin yeni bir kullanıcı hesabı oluşturabilmesi işinin doğal bir parçasıdır. Başka bir yöneticinin bu hesaba ayrıcalıklı yetkiler atayabilmesi de öyle. Ancak aynı kişi hem hesabı oluşturabiliyor hem de kendisine veya oluşturduğu hesaba kritik sistemler üzerinde yönetici yetkisi verebiliyorsa, bağımsız kontrol mekanizması ortadan kalkar.

SoD, tek tek bakıldığında meşru olan bu yetkilerin riskli kombinasyonlar oluşturacak şekilde aynı kişide toplanmasını engeller veya kontrol altına alır.

Görevlerin Ayrılığı (Segregation of Duties – SoD)

Görevleri Ayrılığı ilkesi, tek bir kişide gereğinden fazla yetkinin toplanmasını engelleyen temel bir yönetişim ilkesidir. Bir işlemin başlatılması, değiştirilmesi, onaylanması ve denetlenmesi gibi kritik adımların, farklı kişiler arasında dağıtılmasını amaçlar.

Uzun yıllardır finansal süreçlerin klasik bir iç kontrol prensibi olan SoD, artık çok daha geniş bir alanı kapsıyor. Kullanıcıların erişimlerini birden fazla uygulamadan, gruptan, rolden veya doğrudan atamadan aldığı günümüz kurumsal yapılarında, aynı soru artık BT operasyonlarından İnsan Kaynaklarına, satın almadan ayrıcalıklı erişimlere kadar her alanda karşımıza çıkıyor:

Bir kullanıcının sahip olduğu erişimler birlikte değerlendirildiğinde, normalde birbirinden bağımsız olması gereken görevler aynı kişide mi birleşiyor?

Bu soruya doğru cevap verebilmek, yalnızca rol isimlerine bakmakla mümkün değil. Kullanıcının gerçekte neye erişebildiğini, bu erişimi nasıl kazandığını ve bunun iş sürecindeki karşılığını birlikte okumak gerekiyor.

SoD Neden Identity Governance'ın Ayrılmaz Bir Parçası?

Bir kullanıcının çok fazla sayıda siteme erişebilir. Aynı çalışan bir uygulamada doğrudan atanmış bir role sahipken, başka bir sistemde bir Active Directory grubu üzerinden yetki kazanabilir. Buna bir de proje bazlı geçici erişimleri, manuel verilmiş rolleri ve organizasyon yapısından gelen yetkileri eklediğinizde, tek bir kullanıcının erişimleri bile başlı başına bir bulmacaya dönüşür.

Bir kullanıcı bir sistemde yeni hesap oluşturma, başka bir sistemde ise ayrıcalıklı yetki atama yetkisine sahip olabilir. Her iki erişim ayrı ayrı değerlendirildiğinde tamamen normal görünebilir. Ancak sistemler birlikte değerlendirildiğinde, aynı kişinin hem hesabı oluşturabildiği hem de bu hesaba kritik yetkiler verebildiği görülür. SoD açısından risk, tek tek yetkilerden değil, bu yetkilerin aynı kişide oluşturduğu kombinasyondan kaynaklanır.

Identity Governance tam bu noktada işe yarar: erişimin var olup olmadığını değil; neden verildiğini, nereden geldiğini, ne kadar süreceğini, kime ait olduğunu ve ne risk taşıdığını sorar.

Dolayısıyla SoD'yi "hangi iki rol bir arada bulunmamalı?" sorusuna indirgemek yetersiz kalır. Daha isabetli sorular şunlardır:

Bu erişimler hangi iş görevlerini temsil ediyor?
Kullanıcı bu erişimleri neden ve nasıl kazandı?
Bir araya geldiklerinde hangi kontrol riskini doğuruyorlar?
Bir ihlal bulunduğunda, hangi erişimin değiştirilmesi gerektiği net olarak görülüyor mu?

Kurumsal Ortamlarda SoD Çakışmaları Nerede Karşımıza Çıkar?

SoD kuralları kurumdan kuruma farklıdır. Riskli sayılan kombinasyonlar sektöre, kuruma ve organizasyon yapısına göre değişir. Ama bazı çatışma türleri, sektör ne olursa olsun hep karşımıza çıkar.

Finans, SoD'nin en köklü uygulama alanıdır. Finansal işlemlerin büyük kısmı doğası gereği birden fazla kontrol adımına sahiptir. Fatura oluşturma ile onaylama, tedarikçi kaydı açma ile ödeme adımı, muhasebe kaydı girme ile son kontrolü yapma gibi görevlerin aynı kişide birleşmesi, süreç denetiminini zayıflatır. Ödeme onaylama yetkisi veya tedarikçi oluşturma yetkisi tek başına riskli değildir. Risk, ikisinin aynı kişide toplanmasından kaynaklanır.

Bilgi Teknolojileri'nde görev ayrılığı çoğunlukla ayrıcalıklı yetkiler ve rol değişikliğinde görülür. Yeni bir kullanıcı hesabı açmak veya administrator rolü atamak sistem yöneticisinin görevlerindendir. Aynı kişi hem hesabı açıp hem de ona yüksek yetki verebiliyorsa, kurumda kontrol devre dışı kalır. Bir geliştiricinin kodunu hiçbir denetimden geçirmeden üretime taşıyabilmesi ya da kritik işlemleri yapan kişinin kendi audit kayıtlarını değiştirebilmesi de aynı kapsamda değerlendirilir.

İnsan Kaynakları'nda çalışan kaydı oluşturma, maaş veya banka bilgisi değiştirme, bordro yönetimi ve statü güncelleme birbirinden ayrılması gereken kontrol noktalarıdır. Risk burada İK uygulamasıyla sınırlı kalmaz: İK sistemi IAM için authoritative source olarak kullanılıyorsa, bir çalışanın pozisyon veya statü değişikliği başka sistemlerde otomatik olarak yeni erişimler doğurabilir. Yani İK tarafındaki yetki tasarımı, tüm kimlik yaşam döngüsünü etkileme gücüne sahiptir.

Satın Alma süreçlerinde talep oluşturma, tedarikçi seçimi, sipariş onayı, teslimat doğrulama ve ödeme gibi adımların çoğunun tek kullanıcıda toplanması, kontrol yapısını zayıflatır. Bir çalışanın hem tedarikçi oluşturup hem satın alma onayı verebilmesi, kurumun kontrol modeline göre doğrudan bir SoD ihlali sayılabilir.

Departmanlara Göre Örnek SoD Çakışmaları

Departman	Birinci Yetki	Çakışan Yetki
Finans	Tedarikçi oluşturma	Ödeme onaylama
Finans	Fatura oluşturma	Fatura onaylama
BT	Kullanıcı oluşturma	Ayrıcalıklı rol atama
BT	Sistem değişikliği yapma	Production'a alma
İK	Çalışan oluşturma	Maaş/banka bilgisi değiştirme
İK	Çalışan statüsü değiştirme	Bordro onaylama
Satın Alma	Tedarikçi oluşturma	Satın alma onayı
Satın Alma	Talep oluşturma	Sipariş onaylama

Bu tablo hazır bir politika seti olarak okunmamalıdır. Sağlıklı bir SoD modeli, her kurumun kendi iş süreçleri ve kontrol yapısı üzerine inşa edilmelidir.

SoD İhlallerini Tespit Etmek Neden Söylendiği Kadar Kolay Değil?

Teoride SoD son derece basit gözükür: riskli iki yetkiyi tanımla, aynı kullanıcıya verilmesini engelle. Pratikte ise erişimler bu kadar düz bir çizgide ilerlemez.

Bir kullanıcı bir yetkiyi doğrudan almış olabilir; aynı yetki bir iş rolünden, bir grup üyeliğinden, rol hiyerarşisinden ya da tamamen farklı bir uygulamadaki bir ilişkiden de gelebilir. Bu yüzden yalnızca "kullanıcının rollerine" bakmak yetmez.

Sağlıklı bir SoD analizi üç farklı katmanı bir arada gerektirir:

Kullanıcı neye erişebiliyor? Mevcut erişimin fotoğrafı.
Bu erişim kullanıcıya nasıl ulaştı? Erişimin kaynağı.
Bu erişim diğer yetkilerle birlikte hangi işi yapmaya izin veriyor? Teknik erişimin gerçek iş riskine dönüşümü.

Bu üç katman birlikte değerlendirilmediğinde, SoD analizi yüzeysel kalmaya mahkumdur.

Erişimin Nereden Geldiğini Bilmek Neden Önemli?

Bir kullanıcının riskli bir yetkiye sahip olduğunu görmek önemlidir; ancak asıl kritik olan, bu yetkinin hangi ihtiyaç doğrultusunda ve hangi gerekçeyle verildiğini anlayabilmektir.

Diyelim ki bir kullanıcının ödeme onaylama yetkisinin kaldırılması gerekiyor. Bu yetki kullanıcıya doğrudan atanmışsa çözüm nispeten kolaydır. Ama erişim bir finans rolünden geliyorsa, sorun tek kullanıcıyla sınırlı olmayabilir. Aynı role sahip diğer kullanıcılar da benzer bir risk taşıyor olabilir. Bu durumda tek bir kullanıcının yetkisini kaldırmak yalnızca görünen problemi düzeltir; sorunun gerçek kaynağına çözüme kavuşmamış olabilir.

Bu nedenle erişim görünürlüğü, "kullanıcı bu erişime sahip mi?" sorusuyla yetinmemelidir; "bu erişim hangi rol, grup veya ilişki üzerinden oluştu?" sorusuna da cevap verebilmelidir. Bu fark, bir SoD ihlali düzeltilirken doğru aksiyonun alınmasını sağlamada önemli bir adımdır.

Hangi Identity Governance Yetkinlikleri SoD'yi Gerçekten Yönetilebilir Kılar?

SoD, tek başına bir kural motoruyla çözülecek bir problem değildir. Kimlik yönetişimi çözümünün; önleyici ve tespit edici SoD kontrollerini, farklı uygulamalardaki erişimleri birlikte analiz etme yeteneğini, kimlik ve hesap ilişkilendirmeyi, erişim gözden geçirmelerini ve düzeltici aksiyonları destekleyen iş akışlarını birlikte sunması gerekir:

SoD politika ve kural yönetimi — riskli erişim kombinasyonlarının tanımlanması
Identity ve account correlation — farklı sistemlerdeki hesapların aynı kimliğe bağlanması
Access visibility — erişimin kaynağının anlaşılması
Access Request ve Access Review — erişimin talep ve gözden geçirme aşamalarında değerlendirilmesi

Preventive SoD: Riski Erişim Verilmeden Önce Görmek

SoD açısından en değerli an, erişimin henüz verilmediği andır. Bir kullanıcı yeni bir rol talep ettiğinde sistem yalnızca "bu erişim onaylanmalı mı?" diye sormamalı; kullanıcının mevcut erişimleriyle birleştiğinde yeni bir risk doğurup doğurmadığını da kontrol etmelidir. Bu yaklaşıma Preventive SoD denir. Örneğin bir kullanıcı halihazırda tedarikçi oluşturma yetkisine sahipken ödeme onaylama yetkisi talep ediyorsa, bu iki yetkinin çakışıp çakışmadığı erişim verilmeden önce gösterilebilir.

Her çakışmayı otomatik olarak reddetmek de doğru bir yaklaşım değildir; bazı durumlarda ilgili erişim iş doğası nedeniyle gerçekten gereklidir. Böyle bir durumda sistem talebi ek onaya yönlendirebilir, risk sahibinin onayını isteyebilir, mevcut çakışan erişimin kaldırılmasını şart koşabilir ya da süreli, kontrollü bir istisna tanımlayabilir. Önemli olan, riskli kombinasyonun fark edilmeden oluşması yerine bilinçli ve kayıt altına alınmış bir karara dönüşmesidir.

Detective SoD: Zaten Var Olan Riski Görünür Kılmak

Preventive SoD yeni risklerin oluşmasını azaltır, ama tek başına yeterli değildir. Kullanıcıların görevleri değişir, yeni roller eklenir, bir yönetici manuel olarak yetki verir, eski erişimler zamanında kaldırılmaz. Erişim ilk verildiğinde doğru olsa bile, zamanla bir SoD ihlaline dönüşebilir. Detective SoD, mevcut kullanıcı, rol, grup ve entitlement bilgilerini tanımlı politikalarla düzenli olarak karşılaştırarak ortamda hâlihazırda var olan riskleri ortaya çıkarır.

SoD Aşaması	Amaç	Uygulanabilecek Aksiyon
Önleme	Çakışan yetkilerin kullanıcıya verilmeden önce tespit edilmesi	Talebi engellemek, ek onaya yönlendirmek veya mevcut erişimin kaldırılmasını şart koşmak
Tespit	Kullanıcının mevcut erişimleri içinde SoD ihlallerini bulmak	Rol, grup ve yetki verilerini tanımlı SoD politikalarıyla karşılaştırmak
Düzeltme	Tespit edilen çakışmanın kaynağını ortadan kaldırmak	Erişimi kaldırmak, rol veya grup üyeliğini değiştirmek ya da kontrollü istisna uygulamak

Bir SoD Çözümü Seçerken Neye Bakılmalı?

Bir çözümün "SoD desteği sunması" tek başına bir anlam ifade etmez. Asıl mesele, bu desteğin erişim yaşam döngüsünün hangi aşamalarında ne kadar derinlikli çalıştığıdır.

Değerlendirme Alanı	Sorulması Gereken Soru
Cross-Application Analiz	Farklı sistemlerdeki erişimler birlikte değerlendirilebiliyor mu?
Identity Correlation	Aynı kullanıcıya ait farklı hesaplar ilişkilendirilebiliyor mu?
Preventive SoD	Çakışma erişim verilmeden önce görülebiliyor mu?
Detective SoD	Mevcut ortamdaki ihlaller tespit edilebiliyor mu?
Access Visibility	Yetkinin kullanıcıya hangi yoldan geldiği anlaşılabiliyor mu?
Access Review	SoD riski erişim gözden geçirme kararına dahil edilebiliyor mu?
Exception Management	İş gereği zorunlu istisnalar kontrollü yönetilebiliyor mu?
Audit Trail	Verilen kararlar ve yapılan değişiklikler izlenebiliyor mu?

Securify Identity ile SoD Yönetimi

Securify Identity, SoD risklerinin erişim talebi sırasında önlenmesine, mevcut erişimler içindeki çakışmaların tespit edilmesine ve ihlalin kaynağına göre uygun düzeltici aksiyonun belirlenmesine yardımcı olur. SoD kontrolleri, bağımsız bir kontrol noktası olarak değil; erişim talepleri, erişim gözden geçirmeleri ve erişim görünürlüğü gibi Identity Governance süreçlerinin bir parçası olarak ele alınır.

Bu sayede ekipler yalnızca bir ihlalin varlığını görmekle kalmaz; ihlalin hangi erişim ilişkisinden kaynaklandığını ve düzeltmenin nereden başlaması gerektiğini de analiz edebilir. Risk doğrudan bir kullanıcı atamasından geliyorsa tek bir değişiklik yeterli olabilir; ama aynı problem rol veya grup yapısından kaynaklanıyorsa, çözüm çok daha geniş bir rol tasarım revizyonu gerektirebilir.

Sonuç

Görevler Ayrılığı'nda hedef, bir iş sürecinin kritik kontrol noktalarının tek bir kişide gereksiz yere toplanmasını önlemektir.

Bunu başarmak için kurumların yalnızca rollere değil; kullanıcıların gerçek erişimlerine, bu erişimlerin hangi yoldan geldiğine ve birbiriyle nasıl etkileştiğine bakması gerekir. Olgun bir SoD yaklaşımı üç aşamayı birlikte yürütür:

- Önlemek: Riskli kombinasyonları erişim verilmeden önce engellemek.

- Tespit Etmek: Mevcut ya da sonradan oluşmuş ihlalleri görünür kılmak.

- Düzeltmek: İhlalin kaynağını anlayarak doğru erişimi, rolü ya da süreci değiştirmek.

SoD'nin Identity Governance içindeki gerçek değeri de tam olarak burada ortaya çıkar. İyi bir yönetişim yaklaşımı yalnızca "kim neye erişiyor?" diye sormaz. Asıl sorduğu soru şudur: Bu erişimler bir araya geldiğinde, kullanıcıya gerçekte ne yapma gücü veriyor?

Sıkça Sorulan Sorular

SoD nedir? Segregation of Duties, bir iş sürecinde birbirini kontrol etmesi gereken kritik görevlerin tek bir kullanıcıda kontrolsüz biçimde birleşmesini önlemeyi amaçlayan bir yönetişim prensibidir.

SoD ihlali nedir? Bir kullanıcının, kurumun politikasında birlikte bulunması riskli sayılan iki veya daha fazla yetkiye aynı anda sahip olmasıdır.

SoD yalnızca finans süreçlerinde mi kullanılır? Hayır. Finans en yaygın uygulama alanı olsa da BT, İnsan Kaynakları, satın alma, ayrıcalıklı erişimler ve değişiklik yönetimi gibi birçok alanda kullanılır.

SoD ihlalleri erişim verilmeden önce önlenebilir mi? Evet. Preventive SoD, kullanıcının mevcut erişimlerini talep ettiği yeni erişimle birlikte değerlendirerek olası çakışmaları erişim verilmeden önce yakalar.

Mevcut SoD ihlalleri nasıl bulunur? Detective SoD kontrolleri, mevcut kimlik ve erişim verilerini tanımlı politikalarla karşılaştırarak ortamda bulunan riskli kombinasyonları tespit eder.

Access Review ile SoD arasındaki ilişki nedir? Access Review, mevcut erişimlerin hâlâ gerekli olup olmadığını değerlendirir; SoD bilgisi ise karar vericiye erişimin diğer yetkilerle birlikte yarattığı riski gösterir.

Her SoD ihlali otomatik olarak kaldırılmalı mı? Hayır. Bazı erişimler iş gereği zorunlu olabilir. Bu durumda ek onay, süreli istisna veya telafi edici kontroller uygulanabilir. Bu durumda önemli olan istisnanın kontrollü, kayıtlı ve tekrar gözden geçirilebilir olmasıdır.

Securify Identity, SoD ihlallerinin önlenmesi ve yönetilmesine nasıl yardımcı olur? Securify Identity, SoD risklerinin erişim talebi sırasında önlenmesine, mevcut erişimler içindeki çakışmaların tespit edilmesine ve ihlalin kaynağına göre uygun düzeltici aksiyonun belirlenmesine yardımcı olur. SoD kontrolleri, bağımsız bir kontrol noktası olarak değil; erişim talepleri, erişim gözden geçirmeleri ve erişim görünürlüğü gibi Identity Governance süreçlerinin bir parçası olarak ele alınır.