Yetkilendirme, kullanıcılara atanmış roller ve profillerle erişim yetkisi verilmesi anlamına gelir. Yetkilendirme ile kullanıcıya sahip olduğu izinler verilir ve bu izinler yönetilir.
SAP Sistemlerinde Yetkilendirme Dizaynı
Yetkilendirme çalışmalarına, genellikle şirketlerin S/4HANA dönüşümlerinde ya da yönetilemeyen yetki yapılarına sahip olduklarında ihtiyaç duyulur. Peki yetkilendirme dizaynı nasıl başlar?
Öncelikle yetkilendirmeyi etkileyecek olan temel faktörlerin tespiti yapılmalı;
- Aktivite farklılıkları: Hangi kullanıcı neyi yapabilir? Kim değişiklik yapma ve yaratma iznine sahip? Kim sadece görüntüleyebilir? Kimin izni olmayacak?
- Organizasyonel yapı farklılıkları: Kullanıcı hangi konumda? Hangi şirket kodunu kullanması gerekiyor?
- Görev ve sorumluluklar: Organizasyonun hiyerarşisi ve görev yapısı nasıl?
Temel ayrımlar belirlendikten sonra, SAP sistemlerde yapılacak ilk iş veri analizleri. Kullanıcıların kullanım örnekleri ve alışkanlıklarına göre, kabul görmüş Görevler Ayrılığı (SoD) standartları ve IT riskleri de hesaba katılarak bir model ortaya çıkarılır.
Sıfırdan bir yetkilendirme yapısı kurmak çok zahmetli, karmaşık ve tecrübe isteyen bir süreçtir. Bu süreci hızlandırmak ve kolaylaştırmak için geniş kapsamlı Solvia RS Risk Kütüphanesindeki hazır yetki riskleri, kural setleri ve geçmişteki projelerimizden referans alarak yetkilendirme çalışmalarına ihtiyaç duyan organizasyonlar için en iyi çözümleri sunuyoruz.
Rol Dizaynı Konseptleri
1. Single Rol Dizaynı ve Rol Türetme (Role Derivation)
Genellikle görev, sorumluluk veya pozisyonlara göre sınıflandırılmış tek rol, gereken tüm işlem kodlarını, yetkilendirme nesnelerini, organizasyonel veya fonksiyonel alanların hepsini içerir.
Bir kullanıcının fazladan bir görevi ya da sorumluluğu daha varsa, birden fazla single role sahip olur. Örneğin bir satış sorumlusu depo süreçlerinden birinde işlem yapmaya ihtiyaç duyuyor ve bu isteği rol sahibi tarafından onaylanıyor. Bu durumda satış sorumlusu rolünün dışında gereken depo rolü ek olarak kullanıcıya tayin edilir. Depo ile ilgili roldeki işlem kodları ayrı bir rolde değil de mevcut satış sorumlusu rolüne dahil edilseydi, bütün satış sorumluları bu depo rolüne sahip olurdu ki bu durum kuruluş güvenliği adına önemli bir risk oluştururdu.
Çoğunlukla kullanıcıların ana rolü yeterli olmaz. Bazı çalışanların kendisi ile aynı pozisyondaki çalışanlardan farklı ek yetkileri olabilir. Bunlar için de bu özel görevleri içeren kullanıcıya özel ekstra bir rol açılabilir.
Gelelim Rol Türetme (Derivation) kavramına. Bu yapı, organizasyonel yetkiler verilmemiş halde bulunan master roller ve bu rollerden türetilmiş child rollerden oluşur. Rol türetme işlemi yapılırken, rolün tayin edileceği kullanıcının ihtiyaçlarına göre gerekli organizasyonel yetkilendirmeler yapılır.
Bir örnekle bu yapıyı somutlaştırmak gerekirse; Bir kuruluşun A ve B şehirlerinde 2 ayrı şubesi olduğunu düşünelim. Bu şirketin A şehrindeki muhasebe çalışanı, muhasebe çalışanları için oluşturulmuş master rol’den, A şehri için gerekli yetkiler verilmiş şekilde türetilen rolün sahibi olacaktır. B şehrindeki muhasebe çalışanı ise yine aynı master rolden kendi şehrine göre türetilmiş role sahip olacaktır.
Yapının kuruluşu aşaması başta olmak üzere tüm aşamalarda Rol Türetme yaklaşımı daha hızlı ve kolay kullanılır. Örneğin yeni başlayan çalışanlara çok hızlı şekilde rol tayini yapılabilir. Bu yaklaşımın dezavantajı, ilerleyen süreçlerde çok fazla sayıda single rol bulunması ve bu rollerin bakımını yapmanın zorluğunun giderek artmasıdır. Ayrıca master rollerde yapılabilecek bir hata, çok fazla sayıda kullanıcıyı etkileyebilir.
2. Bileşik (Composite) Rol Dizaynı
Bileşil Rol yaklaşımı, birden fazla single rolün bir araya gelerek toplu halde tek bir rol oluşturmasıdır. Genellikle bileşik rolün adı organizasyondaki bir pozisyonun adı olur. İçindeki single roller de bu pozisyonun gerektirdiği işlem kodlarını barındırır. Tabii ekstra sorumlulukları bulunan kullanıcılar, gerekli durumlarda birden fazla bileşik role de sahip olabilirler.
Bileşik Rol dizaynını rol atamasının en hızlı şekilde yapılacağı rol modeli olarak gösterebiliriz. Ancak, dikkatli yönetilmemesi durumunda kontrolden çıkmaya müsait, karmaşık bir yapı olduğunu da söylemek gerek.
3. Etkinleştirici (Enabler) Rol Dizaynı
Etkinleştirici Rol yaklaşımında, kurumsal yetki değerleri fonksiyonel yetkilerden ayrılır. Sonuç olarak, kullanıcıların bir işlemi başarıyla yürütmek için en az iki role ihtiyacı olur. Fonksiyonel yetki değerleri fonksiyonel etkinleştirici rolüne, organizasyonel yetki değerleri ise organizasyonel etkinleştirici rolüne yerleştirilir.
Bu yapı, organizasyonel ve fonksiyonel ayrımları kuvvetlendirmek ve basitleştirmek için kullanılır. Yerinde ve dikkatli kullanımda bu dizayn amacına ulaşabilirken, aksi durumda kuruluş içerisindeki değişiklikler veya sürece göre değişiklik gösterebilen yetkiler bu model için zorluk çıkarabilir.
Belirtmekte fayda var ki bu 3 farklı yaklaşımın yalnızca birini kullanmak gibi bir zorunluluk yoktur. Yani şirketler kendilerine uygun en iyi yetkilendirme yöntemi için bu yaklaşımları harmanlayarak yeni bir rol yapısı oluşturabilirler.
Erişim Kontrolü Yaklaşımları;
Yetkilendirme ve rol yapısı kurulurken bu yapının hangi erişim kontrolü yaklaşımına göre tasarlanacağı da önemli bir konudur.
- Rol Tabanlı Erişim Kontrolü (RBAC)
RBAC yaklaşımı, kullanıcıların bağlı oldukları rollere göre izinlerin atandığı bir yapıdır. Bu roller kullanıcıların sorumluluklarına, kıdem seviyelerine ve/veya coğrafi konumlarına göre kategorilere ayrılır ve tanımlanır.
Örneğin bir teknoloji müdürü şirketin tüm sunucularına erişebilirken, yazılım mühendisi uygulama sunucularının yalnızca küçük bir alt kümesine erişim sağlayabilir.
Tabi burada konu sadece erişim değildir. Bu erişim ile o alanda neler yapılabileceği de rollere göre farklılık gösterebilir. Örneğin bazı kullanıcılar o alanı sadece görüntüleyebilirken, daha yetkili kullanıcılar yeni eklemeler ve değişiklikler yapabilirler.
Erişim süresi de rollere göre kullanıcıları ayıran bir diğer unsurdur. Mesela, şirket dışı kaynaktan belirli bir süre kullanım için yaratılan rol, kullanıcıya o süre tamamlandığında erişim izni vermeyebilir. Ayrıca, konumuna ve sorumluluklarına göre bir kullanıcıya birden fazla rol atanabilir. Örnek olarak farklı projelerde sorumlulukları bulunan çalışanları gösterebiliriz.
Avantajları
- Rolleri tanımlamak ve uygulamak çok daha hızlıdır.
- Bir erişim hiyerarşisinin oluşmasına olanak tanır.
- Çok fazla rol açılmasının önüne geçilebilirse, düşük maliyetli bir rol yapısıdır.
Dezavantajları
- Bazı durumlarda rollerin ayrıntılarının farklı olması gerekebilir, bu da aşırı sayıda rol açılmasına sebep olabilir.
2. Öznitelik (Karakteristik) Tabanlı Erişim Kontrolü (ABAC)
ABAC, kullanıcı giriş yaptığında sistemin kullanıcı özniteliklerine dayalı olarak erişim izni vermesi veya erişimi engellemesi üzerine geliştirilmiş yaklaşımdır. Peki bu öznitelikler tam olarak neler olabilir?
- Kullanıcı: İş sorumlulukları, kıdem, departman veya güvenlik izinleri
Örneğin, bir muhasebe çalışanının muhasebe ile ilgili bir bölüme giriş yapmaya çalıştığını düşünelim. Sistem departmanını ve sorumluluklarını kontrol eder ve bu kullanıcı giriş yapabilir. Ancak bir depo görevlisi aynı bölüme girmeyi denerse, öznitelikleri karşılamadığından izin verilmeyecektir.
- Erişilen Kaynak: Kaynağın adı, belge türü ya da hassasiyet düzeyi
Örneğin, bir şirketteki herkes, şirketin doğum politikasını tanımlayan dosyalara erişebilirken, belirli bir projenin önemli sayılabilecek dosyaları yalnızca o projede sorumlu kişiler tarafından görüntülenebilir.
- Aktivite: Kaynak üzerinde neler yapılabileceği
Bir projedeki yöneticiler ya da sorumlular, dosyalar üzerinde yaratmak, değiştirmek ya da silmek gibi geniş yetkilere sahip olabilirken, daha tecrübesiz ya da farklı projede çalışanlar yalnızca görüntüleme yetkisine sahip olabilir.
- Çevresel faktörler: Zaman, kullanıcı konumu, kaynak konumu
Bir kullanıcı, bir işlemi bugün yapabilirken, tanımlanan yetkilerin süresine göre 1 ay sonra yapamayabilir. Ya da A şehrindeki çalışan bir siparişi değiştirebilirken B şehrindeki çalışanın bunu yapmaya yetkisi olmayabilir.
ABAC yaklaşımına örnek olarak SAP UI Masking verilebilir. Bu ürün, SAP sistemlerinde hassas bilgileri tanımlamaya, korumaya ve kimlerin erişimi olduğunu kontrol etmeye yönelik olarak tasarlanmıştır.
Avantajları
- Ayrıntılı bir rol yapısı kurulabilir. Bu sayede rollere spesifik yetkiler atamak çok daha kolay olacaktır.
- Yeni kullanıcılar açılırken mevcut kuralları değiştirmek gerekmez. Gereken öznitelikler tayin edilir.
- Değişiklik yaparken öznitelikleri değiştirmek, rolleri değiştirmekten daha kolay ve sorunsuz bir yoldur.
Dezavantajları
- Özniteliklerin tanımlanması ve kullanıcılara atanması uzun zaman alabilir.
- Uygulamak genellikle ilk kurulum için daha fazla zaman ve kaynak gerektirir.
Özet
Özetlemek gerekirse, kuruluşun büyüklüğüne, bütçesine ve güvenlik ihtiyaçlarına bağlı olarak doğru yapı veya yaklaşım değişebilir. Ancak veri ihlallerinin her geçen gün arttığı ve şirketlere büyük bedeller ödettiği bu günlerde, bu yaklaşımların ve kontrollerin şirketler tarafından doğru uygulanmasının hayati önem taşıdığı şüphesiz bir gerçektir. Geniş kapsamlı Solvia RS Risk Kütüphanesindeki hazır yetkilendirme risklerimiz, kural setlerimiz ve geçmiş projelerimizden referans alarak yetkilendirme çalışmalarına ihtiyaç duyan kuruluşlar için en iyi çözümleri sunabileceğimize inanıyoruz.
