Drupal Kullanıcı Rolleri ve Yetkilendirme: Üniversitede Kim Neyi Düzenleyebilir?

Bir üniversite web platformunda yüzlerce editör çalışabilir: Fakülte sekreterleri, bölüm görevlileri, basın ve halkla ilişkiler birimi, kütüphane personeli ve öğrenci asistanları aynı sistemi kullanır. Drupal bu kişilerin yapabileceklerini rollerde toplar ve izni kişiye değil role verir. Bu yazımızda kampüs yapısına uygun bir rol modelini, her birime kendi düzenleme alanını vermenin yolunu, adı dar görünse de aslında her şeyi veren izinleri ve görevi biten kişinin yetkisinin nasıl geri alınacağını anlatıyoruz.

Konuyla ilgili çoğu kaynak rol ve izin mantığını doğru aktarıyor, sonra genel bir örnekle bitiriyor. Üniversite web ekibinin asıl sorusu ise daha zor. Fakülteleri, bölümleri, araştırma merkezleri ve her dönem değişen öğrenci asistanları olan bir kurum, küçük bir merkezi ekibin sürdürebileceği bir izin şemasına nasıl dönüşür? Aşağıda bu soruyu adım adım ele alıyor, her adımda hangi çekirdek iznin ve hangi modülün devreye girdiğini belirtiyoruz.

Drupal'da roller ve izinler nasıl çalışır?

Drupal'da sitedeki her işlem bir izne bağlıdır. Her izin tek bir işlemi ya da birbirine yakın birkaç işlemi kapsar ve izinler, o işlemi sağlayan modüller tarafından tanımlanır. Drupal izinleri hesaplara tek tek vermez; rollerde toplar ve rolü hesaba atar.

Bu ayrım üniversite ölçeğinde işi kolaylaştırır. Bir fakülte sekreteri görevden ayrıldığında o hesabın izinlerini tek tek incelemek yerine rolü kaldırırsınız. Basın birimi editörlerin artık sayfa silmemesine karar verdiğinde tek bir rolü değiştirirsiniz ve karar o rolü taşıyan herkes için geçerli olur.

Her sitede hazır gelen üç rol

Yeni kurulan bir Drupal sitesinde üç rol hazır bulunur. Anonim kullanıcı rolü oturum açmamış ziyaretçiler için, kimliği doğrulanmış kullanıcı rolü ise oturum açan her hesap için geçerlidir. Üçüncüsü, sitedeki tüm izinlere sahip olan yönetici rolüdür ve kurulum profiline göre gelir.

Buradan iki alışkanlık çıkar. Kimliği doğrulanmış kullanıcı rolüne verilen izin, açacağınız her hesap için geçerli olur; bu yüzden yüzlerce editörün bulunduğu bir platformda o rol neredeyse boş kalmalıdır. Yönetici rolü de acele işi olan herkese verilen bir kolaylık değil, adı belli birkaç kişiden oluşan küçük bir grup olarak ele alınmalıdır.

User 1 hesabı ve günlük işte neden kullanılmaması gerektiği

Kurulum sırasında oluşturulan ilk hesabın sistemdeki kimlik numarası 1'dir ve bu hesap diğerlerinden farklı çalışır. Hangi rolü taşıdığından bağımsız olarak sitedeki her işlemi yapabilir. Tüm içeriği görüntüler ve düzenler, her hesabı değiştirir, yapılandırmayı değiştirir, modül kurar ve kaldırır, güncelleme betiğini çalıştırır. Drupal'ın kendi belgeleri bu hesabı Linux sunucudaki root hesabına benzetiyor. Yönetim arayüzünden silinmesi de mümkün değil.

Drupal belgeleri, bu hesabı ortak kullanmak yerine ayrı yönetici hesapları açmak için dört gerekçe sıralıyor. Dördü de üniversitede küçük bir siteye göre daha ağır basıyor.

• Sitedeki işlemler kayda geçer. Web ekibinin tamamı aynı hesabı kullanıyorsa, ana sayfayı kimin değiştirdiği kayıtlardan anlaşılmaz.
• Yönetici rolü, User 1'e göre daha sınırlı yapılandırılabilir. Böylece yanlış bir tıklama modül kaldırmaya kadar gitmez.
• Kişilerin görevleri zamanla değişir. Sıradan bir hesaptan rol eklenip çıkarılabilir, ortak kullanılan bir parola ise tek bir kişiden geri alınamaz.
• İçeriğin yazarı sistemde tutulur ve çoğu zaman sayfada görünür. Ortak hesapla çalışıldığında sayfayı kimin hazırladığı izlenemez.

Uygulamadaki karşılığı şudur: User 1 bilgilerini kurumun parola kasasında tutun, hesabı yalnızca kurtarma ve platform bakımı için kullanın, her yöneticiye yönetici rolü atanmış kendi adına bir hesap açın.

Roller birbirinin üstüne eklenir

Bir kullanıcı aynı anda birden fazla rol taşıyabilir ve bu rollerin izinleri toplanır. Çekirdekte, bir rolün başka bir rolün verdiği izni geri alması diye bir mekanizma bulunmaz.

Bu ayrıntı sık sık gözden kaçar. Sitede içerik silebilen bir editör rolü vardır; yeni gelen personelin silme yetkisi olmasın diye kısıtlı editör adında ikinci bir rol açılır ve kişiye ikisi birden atanır. Kişi iki rolü de taşıdığı için silme izni hâlâ yerinde durur. Bir izni vermemenin tek yolu, o izni hiç içermeyen bir rol kurmaktır. Şema çıkarma mantığına ihtiyaç duymaya başladıysa, yeni rol eklemek yerine rolleri baştan tasarlamak gerekir.

Kampüs yapısına uygun bir rol modeli

Üniversitelerde rol yapısı genellikle iki yönden birinde bozulur. Ya dört rol vardır ve her fakülte kendi işini yapamamaktan şikâyet eder, ya da her talep üzerine bir tane açılmış altmış rol vardır ve yarısının ne verdiğini kimse hatırlamaz.

Uzun ömürlü bir yapı, birbirine karışan iki soruyu ayırır. Bu kişi ne tür bir iş yapıyor, ve bu işi sitenin hangi bölümünde yapıyor? Drupal rolleri birinci soruyu iyi, ikincisini zayıf cevaplar. Aşağıdaki düzenleme alanı bölümü tam olarak bu yüzden var.

Birinci soru için beş kademe çoğu kurumun ihtiyacını karşılar.

• Platform yöneticisi. Bilgi işlemde iki ila dört kişiden oluşan, yönetici rolünü taşıyan ve yapılandırma, modül ve güncellemelerden sorumlu olan gruptur.
• Merkezi editör. Basın ve halkla ilişkiler biriminde çalışan, ana sayfa dahil kurum düzeyindeki tüm sayfaları yayımlayabilen personeldir.
• Birim editörü. Fakülte ve bölümlerde kendi alanındaki içeriği oluşturan ve yayımlayan personeldir. Sayıca en kalabalık grup budur.
• Katkı veren. Akademisyenleri, öğrenci asistanlarını ve ara sıra içerik hazırlayan kişileri kapsar. Taslağı bu kişiler hazırlar, yayımlama yetkisi başkasındadır.
• Görüntüleyen. Düzenleme için değil, yalnızca sınırlı sayfalara erişmek için açılan hesaplardır. Personele özel yönerge sayfaları buna örnektir.

Bu ayrım yalnızca bir öneri değil, büyük platformlarda gözlenen bir düzen. Yale, Stanford ve Princeton'ın merkezi Drupal platformlarında da aynı bölünme görülüyor. Merkezi ekip altyapıyı, güvenliği ve tasarım standardını yönetiyor, birimler ise kendi içeriklerini kendileri düzenliyor.

Altıncı bir kademe eklemeden önce iki soruyu sormak işe yarar. Yeni rol, mevcut bir rolden iki izinden fazlasıyla ayrılıyor mu? Ve bu rolü talep eden kişi dışında taşıyacak biri olacak mı? Tek kişi için açılan rol, aslında dolambaçlı yoldan verilmiş bir izindir ve o kişi ayrıldıktan yıllar sonra bile sistemde durur.

Her birime kendi düzenleme alanını vermek

Roller bir kişinin ne yapabileceğini belirler, nerede yapabileceğini belirlemez. Sayfa düzenleme izni veren bir birim editörü rolü, mühendislik fakültesindeki görevlinin öğrenci işleri sayfalarını da düzenlemesine izin verir. Bunu çözmek için ikinci bir katman gerekir ve Drupal'da bunun iki yerleşik yolu vardır.

Workbench Access ile bölüm bazlı erişim

Workbench Access modülü, kurumda zaten var olan bir hiyerarşiyi temel alarak düzenleme erişimi kurar. Bu hiyerarşi genellikle fakülte ve bölümlerden oluşan bir sınıflandırma ağacı ya da sitenin menü yapısıdır. İçerik oluşturulurken bir düzenleme alanına yerleştirilir, kullanıcılar hesap ya da rol üzerinden alanlara atanır ve herkes yalnızca kendi alanındaki ve altındaki içeriğe dokunabilir. Modülün 2.0.5 sürümü Eylül 2026'da yayımlandı ve Drupal 9, 10 ile 11 üzerinde çalışıyor. Sekiz bin civarında site kullandığını bildiriyor. Ayrıntılar için modülün drupal.org sayfasına bakabilirsiniz.

Modülün kendi belgelerindeki iki sınır, kurulumdan önce dikkatle okunmalı. Modül düzenleme yetkisi vermez, yalnızca kullanıcının işlem yapabileceği içeriği daraltır; oluşturma ve düzenleme izinleri yine rol üzerinden verilir. Ayrıca sadece düzenleme erişimini yönetir, yayımlanmış içeriği kimin görüntüleyebileceğini belirlemez.

Bu yapıyı yüksek öğretime uygun kılan şey hiyerarşinin kendisidir. Fakülte düzeyine atanan bir basın görevlisi, altındaki tüm bölümleri devralır. Tek bir bölüme atanan sekreter ise yalnızca o bölümü görür. Yeni bir araştırma merkezi kurulduğunda yeni rol açmak gerekmez, merkez hiyerarşiye eklenir.

Group modülü ne zaman daha uygun olur?

Group modülü farklı bir yol izler. İçeriği bir hiyerarşiye yerleştirmek yerine, kendi üyeliği ve kendi iç rolleri olan topluluklar oluşturur. Bir kişi bir grupta yönetici, başka bir grupta sıradan üye olabilir ve grup rolleri site genelindeki rollerden ayrı tutulur. Modül yaklaşık on sekiz bin sitede kullanılıyor.

Group, sınırın kurumsal konuma değil üyeliğe dayandığı durumlara uyar. Üç ayrı fakülteden araştırmacının yer aldığı bir proje, bir kongre düzenleme kurulu ya da özel içerik barındıran bir mezun topluluğu bu tarife girer. Sınır organizasyon şemasını izliyorsa, düzenleme alanlarıyla çalışmak daha kolay olur.

Sürüm seçiminde 2026 sonu itibarıyla dikkat gerekiyor. 2.x ve 3.x dalları Drupal 10 ve 11 ile çalışıyor, 8.x-1.x dalı Drupal 10 ile birlikte 2026 ortasında destek dışı kaldı, Drupal 11.4 ve üzeri için hazırlanan 4.x dalı ise alfa aşamasında. Yeni kurulan bir platform en eski daldan başlamamalı.

Multisite kurulumda roller

Her fakültenin tek kod tabanından kendi sitesini çalıştırdığı bir platformda roller ve kullanıcılar siteler arasında paylaşılmaz. Her sitenin kendi hesapları ve kendi rol yapılandırması olur. Bu durum birim özerkliği açısından avantaj, tutarlılık açısından yüktür. Bir sitede iyileştirilen rol tanımı diğerlerine kendiliğinden yansımaz. Rol yapılandırmasını dışa aktarıp siteler arasında dağıtmak, hesaplar ayrı kalsa bile tanımları aynı tutar. Bu mimarinin genel dengesini Drupal multisite ile üniversite web sitelerinin yönetimi yazısında ele aldık.

Multisite ile düzenleme alanı arasındaki tercih de burada netleşir. Birimlerin ayrı siteye ihtiyacı varsa roller site başına kurulur. Tek site içinde ayrı alana ihtiyaç varsa işi düzenleme alanları görür.

Göründüğünden fazlasını veren izinler

Bazı izinler dar birer yönetim kolaylığı gibi okunur, uygulamada ise sitenin tamamını devretmekle aynı kapıya çıkar. Drupal en riskli olanları kendisi işaretler. Bir izin, modül tanımında kısıtlı erişim bayrağıyla tanımlanabilir ve izin sayfasında yanında standart bir güvenlik uyarısı görünür. Çekirdek bunu metin biçimlerini ve filtreleri yönetme izninde kullanıyor.

Yüzlerce onay kutusunun bulunduğu bir sayfada bu uyarıyı kaçırmak kolay olduğu için izinleri adıyla saymakta yarar var.

• İzinleri yönetme. Bu izne sahip olan kişi, bu izin dahil sitedeki her izni kendisine veya başkasına verebilir.
• Kullanıcıları yönetme. Her hesabı düzenleme imkânı tanır. Yukarıdaki izinle birleştiğinde ya da yönetici hesabının düzenlenebildiği bir sitede tam kontrole açılan bir yol olur.
• Metin biçimlerini ve filtreleri yönetme. Hangi HTML etiketlerine izin verildiğini ve hangi rolün hangi biçimi kullanabileceğini belirler. Bir biçimin gevşetilmesi, editör üzerinden siteye zararlı betik girmesinin yoludur.
• İçerik erişim denetimini atlama. Diğer tüm içerik izinlerinin, Workbench Access ve Group modüllerinin uyguladığı kısıtların üzerine geçer.
• Site yapılandırmasını yönetme. Tek bir bölümü değil, platformun tamamını etkileyen ayarlara ulaşır.
• Modülleri yönetme. Sunucuya kod kurma yetkisi verir ve sunucuda kod çalıştırmanın en doğrudan yolu budur.

Buradan çıkan kural kısa. Bu izinler platform yöneticisi rolüne aittir, başka hiçbir role verilmez. İzinlerden biri için talep geldiğinde sorulacak soru, kişinin aslında hangi işi yapmaya çalıştığıdır. Cevap neredeyse her zaman daha dar bir izne ya da bir alan atamasına çıkar.

Bu konuda dolaşan bir bilgiyi de düzeltmekte yarar var. Katkı modüllerinin çekirdeğe göre doğası gereği daha az güvenli olduğu söylenir. Oysa kararlı sürümü bulunan katkı modülleri Drupal güvenlik bildirimi politikası kapsamındadır ve bu yazıda adı geçen modüllerin tamamı bu kapsamdadır. Asıl değişken bakım durumudur ve her modülün proje sayfasında açıkça yazar.

Birimlerin kendi kullanıcılarını yönetebilmesi

Birkaç yüz editöre ulaşıldığında her hesap değişikliğinin bilgi işlemden geçmesi kuyruk oluşturur. Bölüm eylül ayında yeni bir görevli işe alır ve düzenleme yetkisi için bir hafta bekler. İlk akla gelen çözüm, bölüm sorumlusuna kullanıcı yönetme yetkisi vermektir. Bu da kullanıcıları yönetme ve izinleri yönetme izinlerini vermek anlamına gelir, yani bölüm sorumlusu artık kendisine istediği izni verebilir.

Role Delegation modülü tam bu sorun için geliştirilmiş. Modül, sitedeki her rol için ayrı bir atama izni oluşturur. Böylece bir fakülte görevlisine yalnızca katkı veren rolünü atama yetkisi verilebilir. Bu kişi hesap formlarında rol atama alanını ve kullanıcı listesinde toplu işlemleri görür, ancak izinleri yönetme iznini hiç taşımaz. Modül elli binden fazla sitede kullanılıyor ve güncel sürümü Drupal 10.3 ile 11'i destekliyor.

Yetki devri, hangi rollerin devredilebileceğine dair bir kuralla birlikte iyi çalışır. Birim editörü ve katkı veren rolleri devredilebilir, merkezi editör ve platform yöneticisi devredilmez. Böylece günlük işe alım yerelde kalır, gerçek yetki taşıyan roller merkezi ekipte durur.

Rolleri kampüs kimlik sisteminden atamak

Kampüste elle rol atama ölçeklenmez ve buna gerek de yoktur. Personel kurumun kimlik sağlayıcısı üzerinden oturum açtığında, o oturumda gelen öznitelikler doğrudan rol atamasını yürütebilir. Bir dizin grubuna üyelik, kimse hesaba dokunmadan Drupal rolüne dönüşür. Kimlik doğrulama tarafını SAML, Shibboleth, LDAP ve CAS ile SSO entegrasyonu yazısında anlattık. Burada kimlik geldikten sonrasını ele alıyoruz.

Bunu sağlayan iki modül ailesi var. simpleSAMLphp Authentication modülü, SAML özniteliklerinden hesap oluşturma ve otomatik rol atama sunuyor ve hâlâ yaygın kullanılıyor. Proje sayfası artık asgari düzeyde bakım yapıldığını belirtiyor ve modülün bakımcısı, bağımlılık zinciri çok daha kısa olan SAML Authentication modülünün değerlendirilmesini öneriyor. İkinci modül rol atamasını kullanıcı rolleri alt modülüyle yapıyor. Ayrı bir modül de SAML özniteliklerini Group üyeliğine eşliyor.

Hangi yol seçilirse seçilsin, modül tercihinden daha belirleyici üç karar var. İlki, hangi özniteliğin esas alınacağıdır; bu genellikle unvan alanı değil dizin grubudur. İkincisi, her oturum açılışında ne olacağıdır. Roller her seferinde yeniden hesaplanırsa yetki geri alma kendiliğinden işler, yalnızca hesap açılışında atanırsa işlemez. Üçüncüsü, küçük bir rol grubunu otomatik eşlemenin dışında tutmaktır. Platform yöneticisi rolü, dizindeki bir değişikliğin sonucu değil bilinçli bir karar olmalıdır.

Görevi biten kişinin yetkisi nasıl geri alınır?

İzin şemaları kurulum aşamasında tasarlanır, sonra yalnızca üzerine eklenir. Erişim birikir. Mezun olan öğrenci asistanı, başka fakülteye geçen görevli, üç yıl önce siteyi kuran ajans; bunların her birinin hesabı hâlâ açık durur.

Üniversitede bu sorunun kendine özgü bir hâli var, çünkü personel değişimi dönemseldir ve önceden bellidir. Öğrenci asistanları her dönem değişir. Akademik idari görevler her yıl el değiştirir. Bölümler birleşir. Bunların hiçbiri web ekibine bildirim olarak ulaşmaz.

Üç alışkanlık riskin büyük kısmını karşılar.

• Hesap kapatmayı kimlik sistemine bağlayın. Hesaplar dizinden açılıyor ve roller her oturumda yeniden hesaplanıyorsa, dizin grubundan çıkan kişi düzenleme yetkisini kimse talep açmadan kaybeder.
• Rol incelemesini akademik takvime göre planlayın. Dönem başında yapılan kontrol, öğrenci personel değişimini değişiklik henüz tazeyken yakalar.
• Hesapları silmek yerine bloklayın. Bloklama erişimi kaldırır ama yazarlık kaydını korur, böylece sayfayı kimin hazırladığı bilgisi kaybolmaz.

Platform yöneticisi ve merkezi editör rollerini kimlerin taşıdığını gösteren kısa bir liste, dönemde bir kez adı belli bir kişi tarafından gözden geçirilirse, uzun politika belgelerinden daha çok iş görür.

Kişisel veri ve KVKK açısından izin katmanı

Site başvuru formu, etkinlik kaydı ya da başka bir sistemden çekilen öğrenci verisi barındırmaya başladığında, izin şeması editoryal bir kolaylık olmaktan çıkar ve kişisel veri koruma önlemine dönüşür.

KVKK açısından belirleyici olan ilke, kişisel verinin amaçla sınırlı ve ölçülü işlenmesidir. Pratikte bu, herkesin işinin gerektirdiği veriye ulaşması ve fazlasına ulaşmaması demektir. Uluslararası öğrencisi bulunan kurumlar için GDPR de aynı ilkeyi getiriyor.

Uygulamada üç nokta öne çıkıyor. Alan düzeyinde izin denetimi, bir formun topladığı alanı editörlerin çoğunun geri okuyamamasını mümkün kılar; iletişim bilgisi barındıran başvuru formları için doğru yapı budur. Form gönderimlerini görme yetkisi, formun bulunduğu sayfayı düzenleme yetkisinden ayrı bir rol olmalıdır, çünkü program sayfasını güncelleyen kişinin başvurulara erişmesi genelde gerekmez. Yayımlanmamış içeriği görme izni de göründüğünden geniştir, çünkü taslaklar çoğu zaman henüz paylaşılmasına karar verilmemiş bilgiyi taşır.

Konunun genel çerçevesini Drupal'da KVKK ve GDPR uyumu yazısında ele aldık. İzin katmanı, oradaki yükümlülüklerin birçoğunun somutlaştığı yerdir.

İzin şemasını gözden geçirmek ve test etmek

İzin şeması bir yapılandırmadır. Dışa aktarılabilir, kod gibi gözden geçirilebilir ve canlı sitede tıklanarak değil dağıtımla uygulanabilir. Bu şekilde çalışan kurumlar, aylar sonra neyin ne zaman değiştiği sorusuna cevap verebiliyor.

Atlanan adım testtir. Güvenilir tek kontrol, her rol için bir test hesabı tutmak, o hesapla oturum açmak ve rolün yapamaması gereken şeyleri denemektir. İzin sayfası size neyi yapılandırdığınızı gösterir, hesapla gezmek ise neyi kurduğunuzu gösterir. Platformda her rol için bekleyen birer test hesabı bulundurmak tam olarak bu işe yarar.

Karışıklığa yol açtığı için bir sınırı açıkça belirtmekte yarar var. İzinler bir kişinin neye yetkili olduğunu belirler. İçerik onay iş akışı ise içeriğin hangi durumda olduğunu ve bir sonraki duruma kimin geçireceğini belirler. Sayfa oluşturabilen ama yayımlayamayan bir katkı veren, izin kararıdır. Editör onaylayana kadar incelemede bekleyen bir sayfa ise iş akışı kararıdır. İkisi birlikte çalışır ve ikincisini üniversiteler için Drupal içerik onay iş akışı yazısında anlattık.

Rol yapısını planlarken

İzin şemasının ayakta kalıp kalmayacağını belirleyen şey yapılandırma değildir. Hangi birimin sitenin hangi bölümüne sahip olduğuna, kimin incelemeden yayımlayabileceğine, bir fakültenin hangi rolleri kendi başına atayabileceğine ve biri ayrıldığında ne olacağına karar vermektir. Bu cevaplar kurumun kendisinden çıkar, Drupal ise onları sonradan uygular.

Makul bir sıra şöyle işler. Önce mevcut içerik sahipliği çıkarılır, işi karşılayan en küçük rol kümesi tanımlanır, rollerin yalnızca kendi biriminde geçerli olması için bir alan hiyerarşisi kurulur, en alttaki iki rol fakültelere devredilir, atama kimlik sistemine bağlanır ve inceleme tarihi akademik takvime platform yayına girmeden önce yazılır.

Drupart bünyesindeki Drupal4edu ekibinin Sabancı Üniversitesi, ODTÜ ve Yıldız Teknik Üniversitesi gibi kurumlar için geliştirdiği Drupal platformları tam da bu katman etrafında tasarlanır. Küçük bir merkezi ekip platformu tutarlı tutarken her fakülte kendi sayfalarını düzenler. Yaklaşımımızın ayrıntılarını eğitimde Drupal sayfasında bulabilirsiniz.

Drupal rolleri ve yetkilendirme hakkında sık sorulan sorular

Son güncelleme: 18.09.2026 15:03