WordPress Kurulumunda MySQL Kullanıcısı ve Veritabanı Yetkileri

Yeni bir WordPress kurulumunda veritabanı bağlantısını hızla doğrulamak için yönetici hesabını kullanmak cazip gelebilir. Bir kurulumda bu geçici tercih kalıcı hale gelmiş, uygulama yapılandırmasında gereğinden geniş yetkili bir hesap bırakılmıştı. Site çalışıyordu; fakat uygulama ele geçirilirse aynı sunucudaki diğer veritabanları ve yönetim işlemleri de gereksiz biçimde risk altındaydı.

21-23 Temmuz 2026 arasında ele alınan çözümde WordPress’e özel veritabanı ve servis kimliği oluşturduk. Buradaki komutlar örnek adlar kullanır; gerçek parola, sunucu adresi veya topoloji içermez. Hedef yalnızca bağlantıyı çalıştırmak değil, hesabın nereden bağlanabileceğini ve hangi nesnede hangi işi yapabileceğini anlaşılır biçimde sınırlandırmaktır.

Sorunun ortaya çıkışı

WordPress kurulum ekranı veritabanına bağlanamıyor ve ekip farklı kullanıcılarla tekrar deniyordu. Root hesabıyla bağlantı sağlanınca sorun çözülmüş sayıldı. Oysa hata uygulama kullanıcısının yanlış host tanımı, eksik grant veya farklı kimlik doğrulama yöntemi olabilirdi. Geniş yetki kullanmak kök nedeni gizledi ve güvenlik borcu yarattı. Önce bağlantı kimliğinin tam olarak nasıl eşleştiğini anlamak gerekiyordu.

MySQL kullanıcıları yalnızca kullanıcı adından değil kullanıcı ve host birleşiminden oluşur. Aynı makinedeki `localhost`, bir konteyner ağı veya uzak uygulama sunucusu farklı hesap eşleşmeleri yaratabilir. Her yerden bağlantıya izin veren geniş host tanımı kolaylık sağlar; fakat ağ ve kimlik kısıtlarını zayıflatır. Uygulamanın gerçek çalışma konumuna uygun en dar kaynak seçilmeliydi.

İlk belirtiler ve yanlış varsayımlar

“Access denied” mesajı çoğu zaman yalnızca yanlış parola olarak yorumlanır. Gerçekte kullanıcı-host eşleşmesi, grant, parola eklentisi veya bağlantı soketi farklı olabilir. Diğer belirti komut satırından bağlantı başarılıyken WordPress’in başarısız olmasıydı. Test farklı işletim sistemi kullanıcısı, farklı host adı veya TCP yerine yerel soket kullanıyorsa uygulamanın yolunu temsil etmeyebilir.

Bir başka yanlış varsayım `GRANT ALL` ifadesinin sunucu genelinde verilmesi gerektiğiydi. WordPress kendi veritabanında kurulum ve güncelleme sırasında tablo yönetimi yapar; bunun için tüm MySQL sunucusunda yönetici olmasına gerek yoktur. Yetki kapsamı `uygulama_veritabani.*` ile sınırlandırılabilir. Üretim politikası daha sıkıysa eklenti ve çekirdek güncelleme yöntemi ayrıca planlanmalıdır.

Teknik analiz

Önce veritabanı adı, karakter seti ve collation seçimi doğrulandı. Ardından uygulamanın MySQL’e hangi host üzerinden bağlandığı belirlendi. Hesap yalnızca bu kaynaktan erişecek biçimde oluşturuldu ve yetkiler ilgili veritabanıyla sınırlandı. `SHOW GRANTS` çıktısı beklenen kapsamı doğrulamak için kullanıldı. Bağlantı testi WordPress servisinin kullandığı ağ yolu ve kimlikle yapıldı.

Hata incelemesinde uygulama logları geçici ve kontrollü biçimde etkinleştirildi; üretimde kullanıcıya ayrıntılı veritabanı hatası gösterilmedi. DNS, TCP bağlantısı, TLS gereksinimi, kullanıcı-host eşleşmesi ve veritabanı seçimi sırayla kontrol edildi. Başarılı testten sonra root kimliği yapılandırmadan çıkarıldı. Kullanılmayan deneme hesapları ve geniş grant’ler envanterden temizlendi.

-- Örnek adları ve güçlü parolayı kurumun secret süreciyle değiştirin.
CREATE DATABASE wp_app
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER 'wp_service'@'localhost'
  IDENTIFIED BY '<secret-manager-tarafindan-uretilen-parola>';

GRANT ALL PRIVILEGES ON wp_app.* TO 'wp_service'@'localhost';
SHOW GRANTS FOR 'wp_service'@'localhost';

-- FLUSH PRIVILEGES, CREATE USER ve GRANT ile yapılan modern değişikliklerde gerekmez.

Uygulanan çözüm veya önerilen mimari

Her WordPress örneği için ayrı veritabanı ve ayrı servis hesabı oluşturuldu. Hesap sunucu yönetimi, başka veritabanlarına erişim veya kullanıcı oluşturma yetkisi almadı. Uygulama ile veritabanı farklı sistemlerdeyse ağ güvenlik duvarı yalnızca gerekli kaynaktan veritabanı hizmetine erişime izin verdi. Veritabanı yönetim hesabı WordPress yapılandırmasında veya otomatik dağıtım çıktısında tutulmadı.

`wp-config.php` değerleri en dar dosya izinleriyle korundu ve dağıtım sürecinde gerçek sırların kaynak kod deposuna girmemesi sağlandı. Parola üretimi, dağıtımı, rotasyonu ve acil iptali için sahip belirlendi. Rotasyon çift hesap veya kontrollü bakım penceresiyle test edildi. Yedeklerin yapılandırma ve veritabanı sırlarını içerebileceği kabul edilerek aynı erişim standardı yedek ortamına uygulandı.

Alternatifler ve karar gerekçesi

Yerel MySQL aynı sunucuda basit işletim ve düşük ağ bağımlılığı sağlar; web sunucusu olayı veritabanı hizmetini de etkileyebilir. Ayrı veya yönetilen veritabanı yedekleme, ölçek ve görev ayrımı sunabilir; ağ, TLS, maliyet ve sağlayıcı işletimi getirir. Seçim site kritikliğine ve ekip kapasitesine bağlıdır. Her iki modelde de uygulamaya özel kimlik değişmeyen ilkedir.

WordPress’in çalışma zamanında daha dar SQL yetkileriyle işletilmesi teorik olarak saldırı yüzeyini azaltabilir. Ancak çekirdek ve eklenti güncellemeleri şema değişikliği gerektirdiğinde operasyon karmaşıklaşır. Kontrollü dağıtım hattı olan kurumlar kurulum ve runtime rollerini ayırabilir; küçük yapılarda ilgili tek veritabanıyla sınırlı yetki, güçlü dosya ve güncelleme kontrolleriyle daha sürdürülebilir olabilir.

Güvenlik ve operasyonel riskler

Parolanın terminal geçmişine, ticket’a, sohbet mesajına veya kaynak depoya yazılması en yaygın risklerdendir. Örnek komut gerçek sırla doğrudan ortak oturumda çalıştırılmamalı; kurumun güvenli secret yöntemi kullanılmalıdır. Hata ayıklama çıktıları bağlantı ayrıntısı gösterebilir ve iş bitince kapatılmalıdır. Veritabanı hizmeti gereksiz yere genel ağa açılmamalıdır.

Aşırı dar yetki güncelleme sırasında kesinti, aşırı geniş yetki ise olay etkisinin büyümesine yol açar. Değişiklikler test ortamında WordPress kurulum, eklenti güncelleme, medya kullanımı ve geri yükleme senaryolarıyla doğrulanmalıdır. Kullanılmayan hesaplar kapatılmalı, başarısız oturumlar izlenmeli ve yedekten dönüş düzenli denenmelidir. Hesap silmeden önce uygulama bağımlılığı envanterden kontrol edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Bir WordPress bağlantı sorunu incelenirken en hızlı yöntem olarak yapılandırma dosyasını açıp veritabanı parolasını ekip sohbetine göndermek önerilmişti. Bu yöntem sorunu kısa süreli çözebilirdi, fakat kalıcı bir sır birden fazla kontrolsüz kopyaya dönüşecekti. Asıl ihtiyaç parolayı “bulmak” değil, yetkili kişinin güvenli biçimde doğrulaması ve gerekiyorsa izlenebilir şekilde yenilemesiydi.

21 Temmuz 2026 tarihli çalışmada `wp-config.php` dosyasını yalnızca bağlantı ayarı olarak değil, WordPress güven sınırlarından biri olarak ele aldık. Dosya yolu, web sunucusu kullanıcısı, dağıtım yöntemi, yedek ve destek süreçleri birlikte incelendi. Aşağıdaki yaklaşım gerçek parola veya altyapı ayrıntısı paylaşmadan savunmacı işletim prensiplerine odaklanır.

Sorunun ortaya çıkışı

Site veritabanına bağlanamıyor, ancak ekipte hangi hesabın kullanıldığına dair güncel kayıt bulunmuyordu. Dosyaya erişebilen herkes parolayı okuyabiliyor, bazı eski yedeklerde de yapılandırmanın kopyaları yer alıyordu. Önceki bir hata ayıklama sırasında debug kayıtları web dizininde bırakılmıştı. Tek bağlantı sorunu, sır yaşam döngüsü ve dosya yönetişimi eksiklerini görünür hale getirdi.

Dosyanın sahipliği geçmiş kurulumlardan dolayı belirsizdi. Web sunucusunun yazma yetkisi bulunması güncellemeyi kolaylaştırıyor gibi görünse de uygulama açığında yapılandırmanın değiştirilmesi riskini artırıyordu. Öte yandan izinleri düşünmeden aşırı daraltmak siteyi erişilemez yapabilirdi. Doğru model işletim sistemi kullanıcısı, PHP çalışma biçimi ve dağıtım sorumluluğuna göre kurulmalıydı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım dosyanın web tarayıcısından normalde görüntülenememesinin yeterli koruma olduğuydu. Yanlış sunucu yapılandırması, yedek uzantısı, dizin listeleme, yerel kullanıcı veya ele geçirilmiş eklenti farklı erişim yolları oluşturabilir. İkinci varsayım dosya izninde tek bir sayısal değerin her sunucu için doğru olduğuydu. Sahiplik ve servis modeli bilinmeden kopyalanan izin önerileri kesinti ya da gereksiz açıklık yaratabilir.

Salt anahtarlarının veritabanı parolasıyla aynı işlevi gördüğü de karıştırılıyordu. WordPress authentication salts mevcut oturum çerezlerinin güvenliğini etkiler; değiştirilmeleri kullanıcı oturumlarını geçersiz kılar. Veritabanı parolasının rotasyonu ise MySQL hesabı ile yapılandırmanın eş zamanlı güncellenmesini gerektirir. İki işlem farklı etki ve geri dönüş planlarıyla yürütülmelidir.

Teknik analiz

Dosyanın gerçek konumu, sembolik bağlantıları, sahibi, grubu ve erişim listeleri doğrulandı. Web sunucusunun dosyayı okuması gerekiyor, fakat olağan çalışma sırasında değiştirmesi gerekmiyordu. Üst dizin izinleri de kontrol edildi; yalnızca dosyayı daraltıp dizini geniş bırakmak yeterli değildir. Web sunucusu yapılandırmasının `.bak`, `.old` veya editör geçici dosyalarını sunmadığı doğrulandı.

Yapılandırmada veritabanı kimliği, salt anahtarları, debug ayarı ve tablo öneki gibi alanlar envantere alındı; değerler rapora kopyalanmadı. Kaynak kod deposu geçmişi ve dağıtım paketi sır sızıntısı açısından kontrol edildi. Debug logunun konumu, erişimi ve saklama süresi belirlendi. Yedeklerin dosyayı içerip içermediği ve kimlerin yedek ortamına erişebildiği ayrıca değerlendirildi.

# Değerleri ekrana dökmeden yalnızca sahiplik ve izinleri inceleyin.
stat /guvenli/yol/wp-config.php

# PHP sözdizimini kontrol edin; dosya içeriğini paylaşmayın.
php -l /guvenli/yol/wp-config.php

# İzin değişikliği vermeden önce web/PHP çalışma kullanıcısını doğrulayın.
# Ortama özel sahiplik bilinmeden körlemesine chmod/chown uygulamayın.

Uygulanan çözüm veya önerilen mimari

Dosyanın sahibi dağıtım sorumluluğundaki ayrı kullanıcı, okuma grubu ise yalnızca PHP servisinin gerekli kimliği olacak şekilde tasarlandı. Web sürecine yazma verilmedi. Kesin izin değeri ortama göre test edilerek belirlendi ve yapılandırma web kökü dışında desteklenen konuma taşınabiliyorsa bu seçenek değerlendirildi. Sunucu, yedek ve geçici uzantılı yapılandırma dosyalarını yayınlamayacak biçimde sertleştirildi.

Parolalar kurumun secret yönetim sürecinde üretildi; dosyaya dağıtım sırasında güvenli kanaldan verildi ve depoya yazılmadı. Rotasyonda yeni sınırlı hesap oluşturma, yapılandırmayı atomik güncelleme, sağlık testi ve eski hesabı iptal etme adımları uygulandı. Salt yenilemesi ayrı değişiklik olarak kullanıcı oturum etkisiyle planlandı. Erişim ve değişiklikler kişisel sırları göstermeden denetim kaydına alındı.

Alternatifler ve karar gerekçesi

Sırları doğrudan `wp-config.php` içinde tutmak WordPress’in yaygın ve basit modelidir; dosya güvenliği kritik hale gelir. Ortam değişkenleri veya harici secret manager merkezi rotasyon ve dağıtım sağlayabilir, fakat PHP sürecinde değerin nasıl sunulduğu, hata çıktıları ve eklenti uyumluluğu incelenmelidir. Yalnızca farklı yere taşımak, erişim kontrolleri değişmiyorsa sihirli bir koruma sağlamaz.

Dosyayı tamamen değişmez yapmak izinsiz değişikliği azaltabilir; otomasyon, güncelleme ve acil müdahale sürecini zorlaştırabilir. Web sunucusuna yazma vermek ise kolaylık karşılığında olay etkisini büyütür. Kontrollü dağıtım hesabı, salt okunur uygulama erişimi ve izlenen değişiklik süreci kurumun işletim biçimine daha uygun bulundu. Karar, geri dönüş testiyle doğrulandı.

Güvenlik ve operasyonel riskler

Dosya içeriğini ticket, ekran görüntüsü veya sohbetle paylaşmak geri alınması zor kopyalar üretir. Bir sırın açığa çıktığından şüpheleniliyorsa mesajı silmek yeterli değildir; parola ve ilgili anahtarlar planlı biçimde yenilenmelidir. Kaynak depo geçmişindeki sır da yalnızca son commit’ten kaldırılınca yok olmaz. Erişim anahtarları önce iptal edilmeli, geçmiş temizliği kontrollü yürütülmelidir.

Yanlış sahiplik ya da izin değişikliği site kesintisine yol açabilir. Önce mevcut durum kaydedilmeli, ikinci yönetim oturumu korunmalı ve sağlık testi hazırlanmalıdır. Debug açık kalırsa kişisel veri, sorgu veya dosya yolu loglara düşebilir. Yedekler şifrelenmeli, erişimleri sınırlandırılmalı ve saklama sonlarında güvenli silinmelidir. Dosya bütünlüğü uyarıları yetkili dağıtımlarla ilişkilendirilmelidir.

Çıkarılan Dersler

Kontrol Listesi