WordPress Editör ve Yönetici Rolü: Eksiksiz Teknik Kılavuz

WordPress, doğrudan çekirdeğine yerleştirilmiş ayrıntılı bir rol tabanlı erişim kontrolü (RBAC) sistemiyle birlikte gelir. Tüm varsayılan roller arasında Administrator ve Editor, en kritik olan ve en sık yanlış atanan iki roldür. Administrator, her WordPress nesnesi üzerinde sınırsız yetkiye sahipken, Editor geniş içerik yetkisine sahip olmakla birlikte temalar, eklentiler veya site ayarları gibi altyapı düzeyindeki kontrollere sıfır erişime sahiptir.

Bu ayrımı yanlış yapmak küçük bir rahatsızlık değildir. Bir içerik yazarına canlı bir sitede Administrator erişimi vermek doğrudan bir saldırı yüzeyi oluşturur: ele geçirilen tek bir hesap kötü amaçlı bir eklenti yükleyebilir, veritabanını dışarı sızdırabilir veya diğer tüm kullanıcıları kilitleyebilir. Bu kılavuz, her seferinde doğru kararı vermeniz için gereken teknik derinliği sunar.

WordPress Rolleri ve Yetenekleri Gerçekte Nasıl Çalışır

İki rolü karşılaştırmadan önce, temel mimarisini anlamak faydalı olacaktır. WordPress, rolleri bir kullanıcı hesabının sabit bir özelliği olarak saklamaz. Bunun yerine, wp_usermeta tablosunda wp_capabilities anahtarı altında (wp_ tablo önekinizdirdir) serileştirilmiş bir yetenek dizisi saklar. Her rol, WP_Roles sınıfında kayıtlı, adlandırılmış bir yetenek paketidir.

Bir kullanıcı bir eylem gerçekleştirmeye çalıştığında — bir gönderi yayımlamak, bir eklentiyi silmek, başka bir kullanıcının profilini düzenlemek — WordPress, kullanıcının saklanan yeteneklerini istenen ilkel ile karşılaştıran current_user_can() işlevini çağırır. Bu, yeteneklerin eklemeli olduğu ve kritik olarak, Members veya User Role Editor gibi eklentiler kullanılarak rolleri ne olursa olsun kullanıcı bazında özelleştirilebildiği anlamına gelir.

Pratik sonuç: Bir Editor’ın yapabildiği her şeyi *neredeyse* yapabilen ancak aynı zamanda belirli bir eklentiyi yönetebilen bir kullanıcıya ihtiyacınız varsa, onları Administrator’a yükseltmeniz gerekmez. Tek bir ek yetenek verebilirsiniz. Bunu anlamak, WordPress ekip yönetimindeki en yaygın aşırı yetkilendirme hatasını önler.

Administrator Rolü: Tam Yetenek Dökümü

Administrator rolü, WordPress’in sunduğu neredeyse her ilkel yeteneğe karşılık gelir. Tek siteli bir kurulumda bu yetenekler şunları içerir ancak bunlarla sınırlı değildir:

Temel site yönetimi yetenekleri:

manage_options — site URL’si, yönetici e-postası, kalıcı bağlantı yapısı ve saat dilimi dahil olmak üzere wp-admin/options-general.php aracılığıyla tüm ayarları okuma ve yazma
install_plugins, activate_plugins, update_plugins, delete_plugins — tam eklenti yaşam döngüsü kontrolü
install_themes, switch_themes, edit_themes, delete_themes — yerleşik tema düzenleyicisi aracılığıyla doğrudan dosya düzenleme dahil tam tema yaşam döngüsü kontrolü (önemli bir saldırı vektörü)
edit_files — hem temalar hem de eklentiler için yerleşik kod düzenleyicisine erişim (bu yetenek, wp-config.php dosyasında DISALLOW_FILE_EDIT değeri true olarak ayarlandığında devre dışı bırakılır)

Kullanıcı yönetimi yetenekleri:

create_users, edit_users, delete_users, promote_users, list_users — diğer Administrator’ları düşürme veya silme yeteneği dahil sitedeki her kullanıcı hesabı üzerinde tam yetki
remove_users — kullanıcıları Multisite ağından kaldırma

İçerik yetenekleri:

edit_others_posts, edit_published_posts, delete_others_posts, delete_published_posts, delete_private_posts

Gelişmiş yetenekler:

import — WordPress içe aktarıcı aracılığıyla içerik içe aktarma (büyük ölçekte rastgele içerik enjekte etmek için kullanılabilir)
export — tüm kullanıcı verileri dahil sitenin tüm içeriğini XML dosyası olarak dışa aktarma
update_core — WordPress çekirdek güncellemelerini tetikleme
manage_categories, moderate_comments, unfiltered_html — sanitizasyon olmadan <script> etiketleri dahil ham HTML gönderme

unfiltered_html yeteneği özel dikkat gerektirir. Standart tek siteli bir kurulumda, hem Administrator’lar hem de Editor’lar bu yeteneği alır. WordPress Multisite’da ise yalnızca Super Admin’ler bu yeteneği korur. Bu anlamlı bir güvenlik sınırıdır: unfiltered_html olmadan, wp_kses_post() filtresi kaydedilen içerikten JavaScript ve diğer potansiyel olarak tehlikeli işaretlemeyi kaldırır.
Administrator Rolü Ne Zaman Atanmalı

Hosting hesabına sahip olan ve sitenin teknik bütünlüğünden sorumlu olan kişi
Tema geliştirme, eklenti yapılandırması veya sunucu tarafı entegrasyon çalışması gerçekleştiren güvenilir bir geliştirici veya DevOps mühendisi
Tek seferlik içe/dışa aktarma işlemi sırasında bir geçiş uzmanı (rolü sonradan iptal etmeyi düşünün)

Kritik operasyonel not: Paylaşılan veya genel bir hesaba Administrator atamayın. Her Administrator, benzersiz, güçlü bir parolaya ve etkin iki faktörlü kimlik doğrulamaya sahip, adı bilinen bir kişi olmalıdır. WordPress’i bir VPS Hosting ortamında çalıştırıyorsanız, WordPress düzeyindeki Administrator hijyenini işletim sistemi düzeyindeki kullanıcı ayrımıyla eşleştirin — web sunucusu işleminiz asla root olarak çalışmamalı ve WordPress dosya sahipliğiniz web sunucusu kullanıcınızdan farklı olmalıdır.
Editor Rolü: Yetenek Dökümü
Editor rolü, içerik operasyonları için özel olarak tasarlanmıştır. Gönderiler, sayfalar, medya, yorumlar ve taksonomi üzerinde kapsamlı yetki verir — ancak kasıtlı olarak her altyapı düzeyindeki yeteneği dışarıda bırakır.
Bir Editor’ın sahip olduğu içerik yetenekleri:

edit_posts, edit_others_posts, edit_published_posts, edit_private_posts

Bir Editor’ın açıkça yapamadıkları:

• wp-admin/options-general.php veya herhangi bir ayar ekranına erişme
• Eklenti veya tema yükleme, etkinleştirme, devre dışı bırakma veya silme
• Kendi profili dışında herhangi bir kullanıcı hesabını görüntüleme veya değiştirme
• WordPress çekirdek güncellemelerini çalıştırma
• Yerleşik tema veya eklenti dosya düzenleyicilerine erişme
• Site genelinde mevcut tüm URL’leri bozacak kalıcı bağlantı yapılarını değiştirme
• Site verilerini dışa veya içe aktarma

Editor Rolü Ne Zaman Atanmalı

• Editoryal takvime sahip olan ve birden fazla katkıda bulunanın taslak yazılarını onaylayan bir yönetici editör veya içerik direktörü
• Gönderi yayımlaması, zamanlaması ve optimize etmesi gereken ancak eklenti ayarlarına dokunma ihtiyacı olmayan bir SEO uzmanı
• Blogu aktif tutmaktan sorumlu bir sosyal medya veya pazarlama yöneticisi
• Siteyi yanlışlıkla bozma riski olmadan kendi sayfalarını güncellemesi gereken bir müşteri

Administrator ve Editor: Yan Yana Karşılaştırma

Rol Yanlış Atamasının Güvenlik Sonuçları

Aşırı Yetkili Editor Sorunu

Ajanslar arasında yaygın bir kalıp: bir içerik yazarına “daha kolay olduğu için” Administrator erişimi verilir. Bu durum birkaç somut risk oluşturur:

1. Kod yürütme vektörü olarak eklenti kurulumu. Herhangi bir Administrator bir eklenti yükleyebilir. Eklenti, sunucunuzda çalışan PHP kodudur. Ele geçirilmiş bir Administrator hesabı, uzaktan kod yürütme anlamına gelir.
2. Dışa aktarma yoluyla kimlik bilgisi toplama. WordPress dışa aktarma aracı, tüm gönderi içeriğini, yorumları ve yazar meta verilerini içeren bir XML dosyası üretir. Bir Administrator bunu sessizce tetikleyebilir.
3. Ayrıcalık yükseltme kalıcılığı. Administrator erişimi elde eden bir saldırgan yeni bir Administrator hesabı oluşturabilir, ardından kanıtları silebilir — meşru sahibi kilitleyebilir.
4. unfiltered_html kötüye kullanımı. Eklenti erişimi olmasa bile, bir Administrator doğrudan gönderi içeriğine <script> etiketleri enjekte edebilir ve bu durum site ziyaretçilerine karşı depolanmış XSS saldırılarına olanak tanır.

Administrator Rolünü Güçlendirme

Rol atamasının ötesinde, herhangi bir canlı sitede şu WordPress düzeyindeki kontrolleri uygulayın:

Yerleşik dosya düzenleyicisini devre dışı bırakmak için wp-config.php dosyasına aşağıdakileri ekleyin:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // Also blocks plugin/theme installation

WordPress yönetici alanını sunucu düzeyinde IP’ye göre kısıtlayın. Nginx için:

location /wp-admin/ {
    allow 203.0.113.0/24;
    deny all;
}

Apache için .htaccess dosyasına ekleyin:

<Files "wp-login.php">
    Require ip 203.0.113.0/24
</Files>

WP 2FA veya Wordfence Login Security gibi bir eklenti kullanarak güçlü parolalar ve iki faktörlü kimlik doğrulamayı zorunlu kılın. Siteniz bir Dedicated Server üzerinde çalışıyorsa, WordPress yöneticisini herkese açık internete tamamen açmak yerine bir VPN veya SSH tünelinin arkasına koymayı düşünün.

Editor Rolünü Kötüye Kullanımdan Koruma

Editor rolü, Administrator’a kıyasla önemli ölçüde daha güvenlidir, ancak risksiz değildir:

• unfiltered_html yeteneğine sahip bir Editor, gönderi içeriğine izleme pikselleri, bağlı kuruluş yönlendirmeleri veya kötü amaçlı komut dosyaları enjekte edebilir. Multisite’da bu yetenek kaldırılır — çok sayıda içerik katkıda bulunanınız olduğunda Multisite ağı çalıştırmak için güçlü bir argüman.
• Bir Editor, yazmadıkları gönderiler ve sayfalar dahil herhangi bir gönderiyi veya sayfayı kalıcı olarak silebilir. Sayfalar için yerleşik bir geri dönüşüm kutusu yoktur. Bunu azaltmak için bir revizyon veya yedekleme stratejisi kullanın.
• Bir Editor, spam bağlantıları içerenler dahil yorumları onaylayabilir; bu durum sitenizin SEO’sunu ve itibarını etkiler.

WordPress Multisite: Rollerin Değişimi

Bir WordPress Multisite ağında, rol hiyerarşisi ek bir katman kazanır: Super Administrator. Super Admin, tüm site düzeyindeki Administrator’ların üzerinde yer alır ve ağ genelindeki ayarları, tüm sitelerde eklenti etkinleştirmesini ve ağ düzeyinde kullanıcı oluşturmayı kontrol eder.

Multisite’da, site düzeyindeki bir Administrator, eklenti yükleme yeteneği (bunu yalnızca Super Admin’ler ağ genelinde yapabilir) ve unfiltered_html yeteneği dahil olmak üzere tek siteli kurulumda mevcut olan çeşitli yetenekleri kaybeder. Bu, Multisite’ı müşteri sitelerini yöneten ajanslar veya birden fazla editoryal mülkü yöneten yayıncılar için daha savunulabilir bir mimari haline getirir.

Çok kiracılı bir yayıncılık platformu oluşturuyorsanız, cPanel’li VPS, WordPress Multisite uygulama katmanı rol ayrımını yönetirken sunucu tarafı yönetim katmanını basitleştirebilir.

Özel Roller: Ne Administrator Ne de Editor Uygun Olmadığında

WordPress’in add_role() ve add_cap() işlevleri, iş akışınızın gerektirdiği tam yeteneklere sahip roller tanımlamanıza olanak tanır. Örneğin, bir Editor’ın yapabildiği her şeyi yapabilen ancak aynı zamanda kullanıcıları yönetebilen (eklentileri değil) bir Kıdemli Editor programatik olarak oluşturulabilir:

add_role(
    'senior_editor',
    'Senior Editor',
    array(
        // Inherit all standard Editor capabilities
        'read'                   => true,
        'edit_posts'             => true,
        'edit_others_posts'      => true,
        'edit_published_posts'   => true,
        'publish_posts'          => true,
        'delete_posts'           => true,
        'delete_others_posts'    => true,
        'delete_published_posts' => true,
        'edit_pages'             => true,
        'edit_others_pages'      => true,
        'edit_published_pages'   => true,
        'publish_pages'          => true,
        'delete_pages'           => true,
        'manage_categories'      => true,
        'moderate_comments'      => true,
        'upload_files'           => true,
        // Extended capability
        'list_users'             => true,
        'edit_users'             => true,
    )
);

Bu kodu, rolün tema değişikliklerinde kalıcı olması için bir tema’nın functions.php dosyasına değil, siteye özgü bir eklentiye yerleştirin. Roller ilk kayıttan sonra veritabanında saklanır, bu nedenle add_role() yalnızca bir kez çalıştırılması gerekir — register_activation_hook() kullanarak bir eklenti etkinleştirme kancasına sarın.

Pratik Rol Atama Karar Matrisi

Herhangi bir rol atamadan önce bu kontrol listesini kullanın:

Yalnızca kullanıcı şu durumlarda Administrator atayın:

• Sitenin sahibi veya teknik işletiminden sözleşmesel sorumluluğu olan kişi
• Eklenti ve temaları yüklemesi, yapılandırması veya güncellemesi gerekiyor
• Diğer kullanıcı hesaplarını yönetmesi veya kullanıcı rollerini değiştirmesi gerekiyor
• WordPress ayarlarına, kalıcı bağlantı yapısına veya site URL’sine erişim gerekiyor
• İki faktörlü kimlik doğrulama etkin ve benzersiz, paylaşılmayan bir hesap kullanıyor
• Üretimde DISALLOW_FILE_MODS değerinin true olarak ayarlanacağını anlıyor

Kullanıcı şu durumlarda Editor atayın:

• İçerik kalitesinden, yayın programlarından veya editoryal incelemeden sorumlu
• Diğer ekip üyeleri tarafından yazılan gönderi ve sayfaları yönetmesi gerekiyor
• Yorumları denetleyebilmeli ve medyayı yönetebilmeli
• Herhangi bir eklenti, tema veya ayar ekranına erişime ihtiyacı yok — ve olmamalı
• Hesap güvenliğini tam olarak kontrol edemeyeceğiniz bir müşteri, serbest çalışan veya yüklenici olabilir

Şu durumlarda özel bir rol düşünün:

• Yerleşik Editor çok kısıtlayıcı (örneğin, kullanıcının bir editoryal iş akışı eklentisi için list_users yeteneğine ihtiyacı var)
• Yerleşik Administrator çok izin verici (örneğin, eklenti erişimine ihtiyaç duyan ancak kullanıcı hesaplarına dokunmaması gereken bir geliştirici)
• Siteler arasında farklılaştırılmış sorumluluklara sahip bir Multisite ağı çalıştırıyorsunuz

WordPress’i işlemsel e-postayla birlikte yöneten ekipler için, rol stratejinizi özel bir E-posta Hosting kurulumla eşleştirmeyi düşünün; böylece WordPress bildirim e-postaları (parola sıfırlama, yeni kullanıcı kayıtları, yorum uyarıları) hosting sunucusunun varsayılan sendmail’i yerine güvenilir, kimliği doğrulanmış bir posta sunucusu üzerinden yönlendirilir — her rolün iş akışını etkileyen yaygın bir teslim edilebilirlik başarısızlık noktası.

WordPress siteniz e-ticaret, üyelik veya herhangi bir kullanıcı verisi işliyorsa, SSL Sertifikalarınızın güncel ve doğru yapılandırılmış olduğundan emin olun. Süresi dolmuş bir sertifika yalnızca SEO’yu etkilemez — transit sırasında Administrator giriş kimlik bilgilerini koruyan tarayıcı güvenlik bağlamını da bozar.

Temel Teknik Çıkarımlar

• WordPress yetenekleri, sabit kodlanmış değil, wp_usermeta tablosunda kullanıcı başına saklanır — kullanıcının görüntülenen rolü değiştirilmeden özelleştirilebilir.
• wp-config.php dosyasındaki DISALLOW_FILE_EDIT ve DISALLOW_FILE_MODS ayarları, birden fazla Administrator’a sahip herhangi bir canlı sitede zorunludur.
• unfiltered_html yeteneği, tek siteli kurulumda hem Administrator’lar hem de Editor’lar için mevcuttur. Multisite, bunu Super Admin’in altındaki herkesten kaldırır.
• Bir Editor, diğer kullanıcıların içerikleri dahil herhangi bir gönderiyi veya sayfayı kalıcı olarak silebilir. Bu rolü temel ekibinizin dışındaki birine vermeden önce bir yedekleme veya revizyon stratejisi uygulayın.
• Paylaşılan bir Administrator hesabı kullanmayın. Kişi başına bir hesap, zorunlu iki faktörlü kimlik doğrulama ve WP Activity Log gibi bir eklenti aracılığıyla etkin denetim günlükleri.
• add_role() aracılığıyla özel roller, varsayılan rollerden hiçbiri uygun olmadığında doğru çözümdür — eksik bir yeteneği telafi etmek için aşırı yetkilendirme yapmayın.
• Multisite’da, site düzeyindeki Administrator’lar eklenti yükleyemez. Bu bir kısıtlama değil, bir özelliktir — yönetilen çok kiracılı ortamlar için doğru mimaridir.

Sıkça Sorulan Sorular

Bir Editor, WordPress’te başka bir kullanıcının gönderilerini silebilir mi?

Evet. Editor rolü delete_others_posts ve delete_others_pages yeteneklerini içerir. Bir Editor, kim tarafından yazıldığından bağımsız olarak sitedeki herhangi bir gönderiyi veya sayfayı kalıcı olarak silebilir. Sayfalar için yerleşik bir onay adımı veya geri dönüşüm kutusu yoktur, bu nedenle bu işlem bir yedek olmadan geri alınamaz.

WordPress’te Administrator ve Super Administrator arasındaki fark nedir?

Tek siteli bir WordPress kurulumunda, Administrator en yüksek roldür. Bir WordPress Multisite ağında, Super Administrator tüm site düzeyindeki Administrator’ların üzerinde yer alır ve ağ genelindeki ayarları, tüm sitelerde eklenti kurulumunu ve ağa site ekleme veya kaldırma yeteneğini kontrol eder. Multisite’daki site düzeyindeki bir Administrator eklenti yükleyemez veya unfiltered_html kullanamazlar.

Bir Editor’a, onları Administrator yapmadan belirli bir eklentinin ayarlarına erişim verebilir miyim?

Evet. Bireysel bir kullanıcıya belirli bir yetenek vermek için add_cap() kullanın veya Editor’ın varsayılan yeteneklerini artı eklentinin kaydettiği belirli yeteneği içeren özel bir rol oluşturun. İyi kodlanmış eklentilerin çoğu, ayar sayfaları için current_user_can( 'manage_options' ) veya özel bir yetenek kullanır — gereken tam yeteneği belirlemek için eklentinin kaynak kodunu kontrol edin.

Bir WordPress sitesinde birden fazla Administrator bulundurmak güvenli midir?

Bu tamamen operasyonel kontrollerinize bağlıdır. Birden fazla Administrator, saldırı yüzeyini çarpar — her hesap potansiyel bir giriş noktasıdır. Birden fazla Administrator gerekiyorsa, hepsi için iki faktörlü kimlik doğrulamayı zorunlu kılın, /wp-admin/ erişimini sunucu düzeyinde IP’ye göre kısıtlayın, DISALLOW_FILE_MODS değerini true olarak ayarlayın ve tüm yönetimsel eylemleri denetlemek için bir etkinlik günlüğü eklentisi kullanın.

Belirli bir WordPress kullanıcısının gerçekte hangi yeteneklere sahip olduğunu nasıl denetlerim?

Veritabanını doğrudan sorgulayın veya Members ya da User Role Editor gibi bir eklenti kullanın. Programatik bir kontrol için, özel bir komut dosyasında veya WordPress CLI’da get_user_meta( $user_id, $wpdb->prefix . 'capabilities', true ) kullanın:

wp user get <user_id> --field=roles
wp user list-caps <user_id>

wp user list-caps komutu, atanan rolleri dışında bireysel olarak verilen yetenekler dahil olmak üzere kullanıcının sahip olduğu her yeteneği çıktılar — bu, aşırı yetkilendirilmiş hesapları denetlemenin en güvenilir yoludur.