Kurumsal Kullanıcı Yönetimi: Dinamik Grup ve RBAC | Qulak

İK operasyonunda kullanıcı yönetimi, yeni bir çalışanı sisteme eklemekten çok daha geniş bir süreçtir. Çalışanın departmanı, görevi, lokasyonu veya yöneticisi değiştiğinde hangi eğitimleri göreceği ve hangi işlemleri yapabileceği de değişir. Aynı anda yüz yüze bir sınıfın kontenjanı dolabilir, başka bir şubede boş salon kalabilir ya da bir yöneticinin yalnızca kendi ekibine ait raporlara erişmesi gerekebilir.

Bu nedenle kurumsal kullanıcı yönetimi üç ayrı soruyu aynı tasarımda buluşturmalıdır: Kullanıcı hangi gruba dahil olacak? Hangi yetkileri, hangi kapsamda kullanacak? Bir programa kaydolduğunda dijital veya fiziksel kaynak gerçekten uygun mu? İyi tasarlanmış bir akış, İK ekibinin her değişiklikte elektronik tablo düzenlemesine değil, tanımlı kuralları ve istisnaları yönetmesine yardımcı olur.

Qulak ile bu akışın nasıl kurulacağı; kurumun mevcut planına, kimlik altyapısına, HRIS alanlarına ve ihtiyaç duyulan modüllere göre doğrulanır. Aşağıdaki yaklaşım, belirli bir teknik sözleşme veya hazır entegrasyon vaadi değil, İK operasyon ekiplerinin birlikte değerlendirebileceği bir çözüm mimarisidir. API ve HRIS entegrasyonu rehberinde anlatılan veri akışı da bu değerlendirmenin teknik başlangıç noktalarından biri olabilir.

Kurumsal kullanıcı yönetimi neden kural motoru gerektirir?

Manuel kullanıcı yönetimi genellikle üç olayda zorlanır: işe giriş, görev veya organizasyon değişikliği ve işten ayrılış. Her olayda birden fazla kaydın güncellenmesi gerekir. Kullanıcı hesabı, grup üyeliği, zorunlu eğitim ataması, yönetici görünümü ve varsa salon kaydı aynı anda ele alınmazsa eski erişimler veya yanlış atamalar oluşabilir.

Kural tabanlı yaklaşımda insan kaynağının temel nitelikleri, operasyon kararlarına bağlanır. Örneğin “aktif çalışan + üretim lokasyonu + vardiya amiri” koşulu, amirlere özel bir eğitim grubunu tanımlayabilir. “İstanbul ofisi + yeni işe giriş” koşulu, ilk hafta oryantasyonu için ayrı bir programa yönlendirme sağlayabilir. Buradaki amaç, her kullanıcı için ayrı komut yazmak değil; kuralın hangi veriye dayanacağını, ne zaman çalışacağını ve istisnanın kim tarafından onaylanacağını görünür kılmaktır.

Microsoft Entra’nın dinamik üyelik dokümantasyonu, nitelik değiştiğinde kuralların yeniden değerlendirilerek kullanıcıların otomatik eklenip çıkarılabileceğini açıklar. Aynı doküman, kuralda kullanılan niteliklerin kimler tarafından değiştirilebildiğinin denetlenmesi gerektiğini de vurgular. Bu resmî örnek, kurumdan kuruma değişen ürün seçimi için değil, dinamik grup tasarımının güvenlik kontrolünü hatırlatmak için kullanılmalıdır.

Dinamik grup tasarımı: kural, veri ve istisna

Sağlam bir dinamik grup, “her şeyi kapsayan” tek bir koşuldan oluşmaz. Önce iş amacı yazılır, sonra bu amacı temsil eden en az gerekli veri alanları seçilir. İK operasyonu için şu akış pratik bir çerçeve sunar:

1. Kaynağı belirleyin. Çalışan statüsü, bölüm, pozisyon ve lokasyon gibi alanların hangi sistemde ana kayıt olduğunu netleştirin. Aynı alan iki sistemde farklı güncelleniyorsa öncelik ve hata akışı tanımlayın.
2. Kuralı okunabilir yazın. “Aktif çalışan ve satış bölümü” gibi sade bir koşul, istisnası belirsiz bir sorgudan daha kolay test edilir. Birden çok koşul varsa öncelik sırasını dokümante edin.
3. Çakışmayı ölçün. Bir kullanıcı hem yönetici hem eğitmen grubuna dahil olabilir. Bu durumda hangi rolün hangi izni verdiği ve çakışan atamanın nasıl çözüleceği önceden kararlaştırılmalıdır.
4. Değişiklik ve geri alma yolunu ekleyin. Veri hatası nedeniyle yanlış gruba giren bir kullanıcı için geçici düzeltme, onay ve denetim izi bulunmalıdır. Kalıcı kuralı istisna listesiyle sessizce bozmak yerine neden kaydı tutulmalıdır.

Örneğin lokasyon bilgisini yalnızca “İstanbul” olarak tutmak, aynı şehirde birden fazla salon ve çalışma düzeni varsa yetersiz kalabilir. Lokasyon kodu, bina, kat veya vardiya gibi alanlar iş kararını gerçekten değiştiriyorsa veri sözlüğüne eklenebilir. Ancak her yeni alan, erişim, doğruluk, saklama ve değişiklik yönetimi açısından ek bir sorumluluk getirir.

RBAC ile yetkiyi iş rolüne bağlayın

Rol tabanlı erişim kontrolü, izinleri tek tek kişilere bağlamak yerine iş rollerine bağlar. NIST’in RBAC tanımı da erişimi bireysel kimlikler yerine roller üzerinden kontrol eden bu modeli açıklar; roller bir veya birden fazla kişiye uygulanabilir ve rol hiyerarşisiyle miras alınabilir. NIST’in resmî tanımını modelin sınırlarını tartışırken referans almak mümkündür.

İK operasyonlarında en sık görülen hata, grup ile rolü aynı kabul etmektir. “Satış ekibi” bir üyelik kümesi olabilir; “eğitim yöneticisi” ise katalog düzenleme veya atama onayı gibi eylemleri tanımlayan bir roldür. Bir satış çalışanının satış grubunda olması, bütün eğitim kayıtlarını değiştirebileceği anlamına gelmez. Yetki matrisini şu üç boyutta kurmak daha güvenlidir:

Qulak ile rol ve kapsam matrisi tasarlanabilir; hangi rollerin mevcut planda bulunduğu, hangi eylemlerin desteklendiği ve kimlik kaynağından hangi bilgilerin geleceği uygulama öncesinde doğrulanır. Özellikle insan kaynakları yöneticisi, eğitmen, şube sorumlusu ve denetçi rollerini ayırmak; görevler ayrılığı, sınırlı erişim ve insan onayı gibi kontrolleri daha görünür hale getirir.

Mekân kontenjanı: kayıt olmadan önce kaynak planı

Fiziksel eğitimde kullanıcı yönetimi, salon yönetiminden ayrı düşünülemez. Bir çalışanın doğru gruba atanması, salonda yer olduğu anlamına gelmez. Mekânın tanımlı kapasitesi; oturum zamanı, bina veya şube, erişilebilirlik ihtiyacı, ekipman, eğitmen uygunluğu ve kurumun güvenlik kurallarıyla birlikte değerlendirilmelidir.

Bu tasarımda salon, yalnızca bir metin alanı değil, durumu olan bir kaynak olarak ele alınır. “Taslak”, “rezervasyona açık”, “doldu”, “bekleme listesi” ve “iptal edildi” gibi durumlar kayıt akışının hangi adımda duracağını görünür kılar. Kontenjan sınırına ulaşıldığında yeni kaydı engellemek, bekleme listesine almak veya alternatif oturuma yönlendirmek kurum politikasına göre seçilebilir.

Qulak ile mekân ve kontenjan akışı tasarlanabilir; salon rezervasyonu, yoklama veya bekleme listesi gibi ayrıntıların kullanılabilirliği kurumun mevcut planına göre teyit edilmelidir. İK ekibi için kritik kazanım, bir oturumun neden kapandığını ve kimin hangi kararla kapasiteyi değiştirdiğini izlenebilir hale getirmektir. Hibrit eğitim ve mekân yönetimi rehberinde bu envanter yaklaşımının fiziksel ve dijital akademiyle nasıl birlikte ele alınabileceğine bakabilirsiniz.

Veri yönetişimi: güvenli otomasyonun kontrol noktaları

Kullanıcı yönetimi, çalışan verilerini işlediği için otomasyonun yanında veri yönetişimi de gerektirir. KVKK’nın resmî açıklamasına göre aydınlatmada veri sorumlusunun kimliği, işleme amacı, aktarım amacı ve alıcıları, toplama yöntemi ile hukuki sebep ve ilgili kişinin hakları hakkında bilgi verilmelidir. Bu yükümlülük, veri işleme açık rızaya dayansa da başka bir hukuki sebebe dayansa da devam eder. KVKK aydınlatma yükümlülüğü açıklaması bu çerçeveyi açıklar.

Bu nedenle dinamik grup kuralı tasarlanırken yalnızca “hangi alan kullanılabilir?” sorusu sorulmamalıdır. “Bu alan hangi amaçla gerekli, kim görebilir, ne kadar süre tutulur, hangi sistemle paylaşılır ve yanlışsa nasıl düzeltilir?” soruları da aynı tasarım kaydında bulunmalıdır. Veri minimizasyonu, operasyonu zorlaştırmak için değil, karar üretmeyen alanların gereksiz yere çoğalmasını önlemek için uygulanır.

Erişim tasarımında en az ayrıcalık ilkesi pratik bir kontrol noktasıdır. İK operatörü gerekli kullanıcı alanlarını görebilir; eğitmen yalnızca kendi oturumunun katılımcı bilgilerine erişebilir; denetçi ise raporları değiştirmeden inceleyebilir. Kural, rol, kapasite veya istisna değiştiğinde kim tarafından, ne zaman ve hangi gerekçeyle değişiklik yapıldığını gösteren kayıtlar tutulmalı; bu kayıtların saklama süresi kurum politikası ve ilgili mevzuata göre belirlenmelidir. Hukuki değerlendirme, kurumun veri işleme envanteri ve yetkili danışmanlarıyla doğrulanmalıdır.

İK operasyonu için uygulanabilir çalışma modeli

Kurumsal kullanıcı yönetimini bir kerelik kurulum yerine yaşayan bir operasyon olarak ele almak gerekir. Qulak ile tasarlanabilecek akışın kapsamını netleştirmek için İK, BT ve eğitim operasyonlarının birlikte yürütebileceği beş adımlı bir çalışma modeli kullanılabilir:

1. Veri sözlüğünü çıkarın. Kullanıcı kimliği, çalışan durumu, departman, pozisyon, lokasyon ve yönetici gibi alanların anlamını, kaynağını ve güncelleme sahibini yazın.
2. Grup ve rol matrisini ayırın. Her grup için üyelik koşulunu, her rol için eylem ve kapsamı tanımlayın. Aynı koşulun farklı iş kararlarında kullanılmasına dikkat edin.
3. Mekân envanterini bağlayın. Salon kapasitesi, zaman çakışması, ekipman ve alternatif oturum kurallarını kayıt akışından önce tasarlayın.
4. İstisnaları test edin. Görev değişikliği, geçici görevlendirme, uzun izin, işten ayrılış, çift rol ve dolu salon gibi senaryolarda beklenen sonucu kontrol edin.
5. İnceleme döngüsü kurun. Kural sahiplerini belirleyin; erişim, grup üyeliği, bekleme listesi ve değişiklik loglarını kurumun belirlediği aralıklarla gözden geçirin.

Bu model, “otomatik” kelimesini kontrolsüz işlem anlamına getirmez. Otomasyonun değeri, tekrar eden kararları tutarlı hale getirirken istisnaları insana görünür kılmasıdır. Qulak için teknik keşif yapılırken mevcut HRIS, kimlik sağlayıcı, şube yapısı, salon envanteri ve raporlama ihtiyacı birlikte ele alınabilir; kesin kapsam ve entegrasyon yöntemi kurumun mevcut planına göre doğrulanır.

Sıkça Sorulan Sorular

İlgili Qulak rehberleri

Resmî kaynaklar

• Microsoft Learn — Manage rules for dynamic membership groups in Microsoft Entra ID
• NIST CSRC — Role-Based Access Control (RBAC) tanımı
• Kişisel Verileri Koruma Kurumu — Aydınlatma Yükümlülüğü
• Kişisel Verileri Koruma Kurumu — Açık Rıza Alırken Dikkat Edilecek Hususlar
• Kişisel Verileri Koruma Kurumu — Kişisel Veri Güvenliği Rehberi