Magento 2 yönetim panelini güvenli hâle getirme: 2026 kontrol listesi

Magento yönetim paneline erişen saldırganlar ödeme sayfasına kart bilgilerini çalan bir kod (skimmer) ekleyebilir, müşteri verilerini dışa aktarabilir ya da daha sonra kullanmak üzere gizli bir yönetici hesabı oluşturabilir. Başarılı saldırıların çoğu, bir kontrol listesinin yakalayabileceği zayıf bir noktadan başlar: başka yerlerde de kullanılan bir şifre, eski bir eklenti, atlanmış bir güvenlik yaması ya da unutulmuş bir test hesabı.

Aşağıdaki listeyi bir denetim listesi olarak kullanın. Her maddede neyin kontrol edileceği ve gerektiğinde kullanılacak komutun kendisi yer alıyor. Komutları Magento kök dizininde, dosya sistemi sahibi kullanıcıyla çalıştırın ve önce test ortamında (staging) deneyin.

1. Her yönetici kullanıcı için iki faktörlü kimlik doğrulamayı zorunlu kılın

2.4.0'dan bu yana Magento_TwoFactorAuth modülü varsayılan olarak etkindir ve bir yönetici kullanıcının arayüz veya web API üzerinden oturum açabilmesi için 2FA ister. Desteklenen sağlayıcılar arasında Google Authenticator, Duo Security ve YubiKey gibi U2F donanım anahtarları bulunur. 2.4.9'da yönetici kullanıcıların giriş yapabilmesi için etkin sağlayıcılardan yalnızca birini yapılandırması yeterlidir.

Modülün devre dışı bırakılmadığını kontrol edin; bunu çoğu zaman yerel testler sırasında bir geliştirici yapar:

bin/magento module:status Magento_TwoFactorAuth
bin/magento security:tfa:providers
# Force specific providers (comma-separated codes)
bin/magento config:set twofactorauth/general/force_providers google,u2fkey

Birisi cihazını kaybederse modülü devre dışı bırakmak yerine yalnızca o kişinin sağlayıcısını sıfırlayın:

bin/magento security:tfa:reset <admin_username> google

2. Varsayılandan farklı bir yönetim paneli yolu kullanın

Adobe, admin, backend veya yaygın herhangi bir kelimenin kullanılmamasını önerir. Rastgele bir yol hedefli bir saldırganı durdurmaz, ancak sizi otomatik giriş denemelerinin büyük bölümünün dışında bırakır.

bin/magento info:adminuri
bin/magento setup:config:set --backend-frontname="ops_7k2m9x"
bin/magento cache:flush

Yönetim paneli URI'si yalnızca harf, rakam ve alt çizgi kabul eder.

3. Yönetim paneli erişimini IP ile kısıtlayın

Adobe’un güvenlik önerileri (best practices) IP izin listesi kullanılmasını tavsiye eder. Magento'da yerleşik bir yönetim paneli IP filtresi bulunmadığından bunu web sunucusu, yük dengeleyici, CDN veya WAF düzeyinde yapın. Örnek bir Nginx yapılandırması:

location ~* ^/(index\.php/)?ops_7k2m9x {
    allow 203.0.113.10;     # office
    allow 198.51.100.0/24;  # VPN range
    deny all;
    try_files $uri $uri/ /index.php$is_args$args;
}

Bunu dikkatle test edin. Nginx yapılandırmanızdaki PHP handler bloğu, izin verilen istekleri işlemeye devam etmelidir. Ekibiniz uzaktan çalışıyorsa, ev IP adreslerinden oluşan uzun bir liste tutmak yerine yönetim paneline erişimi VPN üzerinden sağlayın.

4. Yönetim paneli güvenlik ayarlarını sıkılaştırın

Şu bölümde: Stores > Configuration > Advanced > Admin > Security, oturum süresini, hesap kilitlemeyi, şifre geçerlilik süresini ve hesap paylaşımını gözden geçirin. Bu ayarları CLI'dan da yapabilirsiniz; böylece şu dosyalar aracılığıyla sürüm kontrolünde tutulurlar: config.php veya env.php:

bin/magento config:set admin/security/session_lifetime 900
bin/magento config:set admin/security/lockout_failures 5
bin/magento config:set admin/security/lockout_threshold 30
bin/magento config:set admin/security/password_lifetime 90
bin/magento config:set admin/security/password_is_forced 1
bin/magento config:set admin/security/admin_account_sharing 0
bin/magento config:set admin/security/use_form_key 1

PCI DSS v4.0.1 Gereksinim 8.3.6, en az 12 karakterli şifre ister (sistem 12'yi desteklemiyorsa 8). Magento’nun yönetim paneli için öteden beri uyguladığı minimum şifre uzunluğu 7'dir. Adobe Commerce 2.4.9, bu minimum uzunluğu aynı Security bölümünden ayarlanabilir hale getiriyor; bu da sürüm yükseltmeyi planlamak için bir neden daha.

Ayrıca yönetim paneli girişi ve şifremi unuttum formları için reCAPTCHA'yı şu bölümden etkinleştirin: Stores > Configuration > Security > Google reCAPTCHA Admin Panel.

5. Roller ve entegrasyonlarda en az yetki ilkesini uygulayın

• Her kişiye kendi hesabını verin. Ortak “pazarlama” veya “ajans” girişleri kullanmayın.
• Rolleri System > Permissions > User Roles bölümünde, her ekibin yalnızca ihtiyaç duyduğu kaynakları kapsayacak şekilde oluşturun. İçerik editörlerinin şu bölümlere erişmesine gerek yoktur: System veya Stores > Configuration.
• Eski çalışanların ve ajansların hesaplarını, erişimin sona erdiği gün silin veya devre dışı bırakın.
• API entegrasyonlarını gereken en az kaynakla sınırlayın ve token'larını düzenli olarak yenileyin.

Yönetici kullanıcıları üç ayda bir gözden geçirin. Kimsenin tanımadığı hesapları bulmak için kısa bir sorgu işinize yarar:

SELECT user_id, username, email, is_active, created, logdate
FROM admin_user
ORDER BY created DESC;

Yakın zamanda oluşturulmuş ve kimsenin tanımadığı bir hesap, sisteme sızıldığının güçlü bir işaretidir. Bunu bir güvenlik olayı olarak ele alın ve müdahale planınızı devreye alın.

6. Ödeme sayfalarında Content Security Policy'yi zorunlu tutun

Adobe, 2.4.7'den bu yana hem mağaza ön yüzündeki hem de yönetim panelindeki ödeme sayfalarında CSP'yi varsayılan olarak restrict modunda, diğer tüm sayfalarda ise report-only modunda yapılandırıyor. Adobe bu değişikliği, Subresource Integrity desteğiyle birlikte, mağaza sahiplerinin PCI DSS 4.0 gereksinimlerini karşılamasına yardımcı olmak için yaptı. Gereksinim 6.4.3, ödeme sayfalarındaki her script'in envanterinin çıkarılmasını, yetkilendirilmesini ve bütünlüğünün kontrol edilmesini ister; Gereksinim 11.6.1 ise ödeme sayfalarında değişikliklerin ve yetkisiz müdahalelerin tespit edilmesini şart koşar. Her ikisi de 31 Mart 2025'te yürürlüğe girdi.

Sık yapılan hata, bir eklentinin satır içi (inline) script'i çalışmaz hale geldi diye ödeme sayfasını yeniden report-only moduna almaktır. Bunun yerine script'i düzeltin: izin listesine ekleyin, SecureHtmlRenderer kullanın ya da şuradan bir nonce alın: CspNonceProvider. Hiçbir modülün varsayılan ayarı geçersiz kılmadığını kontrol edin:

grep -rn "report_only" app/code vendor/*/*/etc/config.xml | grep -v "vendor/magento"

Referans olarak, mağaza ön yüzündeki ödeme sayfası için restrict modu bir modülün şu dosyasında böyle görünür: config.xml:

<csp>
  <mode>
    <storefront_checkout_index_index>
      <report_only>0</report_only>
    </storefront_checkout_index_index>
  </mode>
</csp>

7. Yamaları sabit bir takvimle uygulayın

Adobe düzenli güvenlik sürümleri yayımlar (örneğin 2.4.8, Haziran 2025 ile Mayıs 2026 arasında -p1'den -p5'e kadar yamalar aldı) ve gerektiğinde takvim dışında bağımsız güvenlik yamaları da çıkarır. Eylül 2026'da Adobe, aktif olarak istismar edildiğini belirttiği bir güvenlik açığı için kritik bir düzeltme olan APSB26-146'yı yayımladı ve mağaza sahiplerine hotfix'i uygulamanın yanı sıra kimlik bilgilerini de yenilemelerini önerdi.

Uygulanabilir bir rutin:

• Adobe güvenlik bültenlerine ve Commerce Security Scan bildirimlerine abone olun.
• Kritik düzeltmeleri birkaç gün içinde uygulayın.
• Hangi yamaların uygulandığını Quality Patches Tool ile kontrol edin:

vendor/bin/magento-patches status
composer audit

Desteklenen bir sürüm hattında kalın. Adobe’un yaşam döngüsü politikasına göre 2.4.6'nın standart desteği 11 Ağustos 2026'da sona erdi.

8. Canlı ortamda kodu salt okunur yapın

Mağazayı canlı modda (production mode) çalıştırın ve kod dizinlerindeki yazma iznini kaldırın; böylece web üzerinden yapılan bir saldırı sunucuya kolayca dosya bırakamaz. Adobe’un iki kullanıcılı kurulum için dokümante ettiği komut:

bin/magento deploy:mode:show
find app/code lib pub/static app/etc generated/code generated/metadata var/view_preprocessed \
  \( -type d -or -type f \) -exec chmod g-w {} + && chmod o-rwx app/etc/env.php

Yazma iznini yalnızca yayına alma (deploy) sırasında geri verin, ardından yeniden kapatın.

9. Kullanmadığınız her şeyi kapatın

Etkin olan her modül ve uç nokta, saldırı yüzeyini büyütür. Nelerin etkin olduğunu listeleyin, ardından bağımlılıkları kontrol ederek kullanmadığınız modülleri devre dışı bırakın:

bin/magento module:status --enabled
bin/magento module:disable Vendor_UnusedModule
bin/magento setup:upgrade && bin/magento setup:di:compile

Ayrıca REST kaynaklarına anonim erişimin kapalı kaldığını doğrulayın:

bin/magento config:show webapi/webapisecurity/allow_insecure   # expect 0 or empty

Kullanılmayan üçüncü taraf eklentileri devre dışı bırakıp bekletmek yerine Composer ile kaldırın. Devre dışı bırakılmış kod da sürümünüzle birlikte yayına çıkar ve yine yama gerektirir.

10. İzleyin, loglayın ve yedekleyin

• Zararlı yazılım ve bütünlük taraması. Adobe’un ücretsiz Commerce Security Scan aracı siteleri bilinen risklere ve zararlı yazılımlara karşı tarar. Sansec eComscan gibi sunucu tarafı tarayıcılar ise dosyalarda ve veritabanında zararlı yazılım, güvenlik açığı bulunan eklentiler ve yetkisiz yönetici hesapları arar.
• Yönetim paneli etkinliği. Adobe Commerce, Admin Action Log özelliğini içerir. Magento Open Source'ta web sunucusu ve var/log loglarını merkezi bir sisteme gönderin ve yeni IP'lerden yapılan yönetim paneli girişlerinde uyarı alın.
• Değişiklik tespiti. Ödeme sayfası şablonlarında, CMS bloklarında ve script içeren core_config_data kayıtlarında yapılan değişikliklerde uyarı alın.
• Yedekleme. Şifrelenmiş veritabanı ve medya yedeklerini sunucunun dışında saklayın, app/etc/env.php dosyasını (şifreleme anahtarınızı içerir) ayrı ve güvenli bir kasada tutun ve en az üç ayda bir tam geri yükleme testi yapın.

Hızlı başvuru kontrol listesi

Sıkça sorulan sorular

Test ortamında geliştiriciler için 2FA'yı kapatabilir miyim?

Birçok ekip bunu yerel makinelerde yapıyor; ancak internete açık her ortamda 2FA açık kalmalı. Test ortamında genellikle canlı verilerin bir kopyası ve aynı yönetici kullanıcı adları bulunur; bu da onu cazip bir hedef yapar.

Özel bir yönetim paneli URL'si yeterli koruma sağlar mı?

Hayır. Yalnızca otomatik saldırı trafiğini azaltır. Bunu 2FA, IP izin listesi veya VPN, hesap kilitleme ayarları ve izleme ile birlikte kullanın.

CSP tek başına ödeme sayfamı PCI uyumlu hâle getirir mi?

Hayır. CSP restrict modu ve SRI, ödeme sayfalarındaki script yetkilendirmesine ve bütünlüğüne yardımcı olur; ancak PCI DSS çok daha fazlasını kapsar ve kapsamınız ödemeyi nasıl aldığınıza bağlıdır. Yükümlülüklerinizi çalıştığınız üye işyeri bankasıyla (acquirer) veya QSA'nızla teyit edin.

Adobe güvenlik yamalarını ne kadar hızlı uygulamalıyız?

Kritik bültenlerde, özellikle Adobe'nin aktif olarak istismar edildiğini belirttiği açıklarda, hedefiniz birkaç gün olmalı. Düzenli güvenlik sürümleri ise test ve yayın döngünüz en az ayda bir işlediği sürece bu normal döngüyle uygulanabilir.

Kaynaklar

• Adobe Experience League: Commerce sitenizi ve altyapınızı güvenli hâle getirin
• Adobe Experience League: İki faktörlü kimlik doğrulama
• Adobe Experience League: Admin URI'sini görüntüleme veya değiştirme
• Adobe Experience League: Admin güvenliğini yapılandırma
• Adobe Developer: Content Security Policies
• Adobe Commerce 2.4.7 sürüm notları
• Adobe Commerce 2.4.9 sürüm notları
• Adobe Experience League: Yayınlanan sürümler
• Adobe Experience League: Yazılım yaşam döngüsü politikası
• Adobe: Kritik güvenlik güncellemesi APSB26-146
• Adobe Experience League: Dosya sistemi erişim izinleri
• PCI SSC: Ödeme sayfası güvenliği ve e-skimming'in önlenmesi (6.4.3 ve 11.6.1)
• SecurityMetrics: PCI DSS 4.0.1'de parola gereksinimleri
• Sansec eComscan