Küçük bir WordPress sitesi, bir ajans çalışanının hesabına bağlı Google uygulama parolasıyla e-posta gönderiyor. Daha büyük bir site OAuth kullanmayı planlıyor; ancak Cloud projesinin sahibi ve token yenilemesini izleyecek ekip belli değil. Her iki durumda da asıl risk, kimlik bilgilerinin yaşam döngüsüdür.
Seçim güncel Google ve kurum politikalarına göre yapılmalı; saklama, iptal ve hesap devri sorumlulukları bağlantı kurulmadan önce yazılı olmalıdır.
Bu konu ne anlama gelir?
Uygulama parolası, gerekli güvenlik koşullarını karşılayan Google hesaplarında kullanılabilen ayrı bir kimlik bilgisidir. OAuth ise tanımlı izinlere sahip access ve refresh token’ları üzerinden uygulamayı yetkilendirir. İki yöntem de onaylı bir gönderen kimliği ve kurumsal sorumluluk gerektirir.
Gerçekçi bir WordPress örneği
Kurum hesabı uzun vadeli yönetiliyor ve politika uygulama parolasına izin veriyorsa yalnız bu siteye ait, korumalı bir uygulama parolası kullanılabilir. Kurumun zaten yönettiği bir Google Cloud OAuth istemcisi varsa OAuth tercih edilebilir. Bir çalışanın kişisel hesabına bağlı olan iki seçenek de reddedilmelidir.
Neden önemlidir ve ne zaman kullanılır?
Doğru yöntem, sitenin ömrü boyunca güvenle yönetilebilen yöntemdir. Politika desteği, en az yetki, denetlenebilirlik, yenileme, iptal ve personel değişikliği; sabit parola ile token arasındaki yüzeysel farktan daha önemlidir.
Yeni başlayanlar için anlaşılır yol
- Güncel Google belgelerini ve Workspace politikasını kontrol edin.
- Kurumun yönettiği bir gönderen hesabı kullanın ve sorumlu ekibi belirleyin.
- Kimlik bilgisini veya OAuth istemcisini yalnız bu site için ve gerekli en dar yetkiyle oluşturun.
- Korumalı yapılandırmada saklayıp gerçek bir WordPress iletisi gönderin.
- İptal, yeniden bağlanma ve hesap devri adımlarını belgeleyin.
İleri teknik yol
OAuth için proje sahipliğini, consent ayarlarını, scope’ları, redirect URI’yi, token saklamayı, refresh hatalarını ve proje devrini inceleyin. Uygulama parolasında iki adımlı doğrulama durumunu, etiketi, tekil kullanımı, saklama yerini ve iptal yolunu doğrulayın. Kontrollü bir bakım aralığında etkin yöntemi iptal edin, beklenen hatayı görün, belgelenmiş hesap üzerinden yeniden bağlanın ve eski erişimin çalışmadığını kanıtlayın.
Riskler, sık hatalar, yedekleme ve geri alma
Uygulama parolasını birden fazla sitede kullanmayın, iki yöntemi gizli yedek olarak aynı anda açık bırakmayın ve Cloud projesini kişisel hesapta tutmayın. Sorumluluk, iptal veya güvenli saklama gösterilemiyorsa yapılandırmayı canlıya almayın. Geri dönüş gerekiyorsa önceki onaylı yöntemi yalnız sınırlı süre kullanın ve eski erişimi daha sonra kaldırın.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, etkin WordPress posta ayarlarını ve kontrollü testleri tek yerde tutar. Seçilen Google bağlantısının kimlik doğruladığını ve WordPress’in oluşturduğu gerçek bir iletinin sağlayıcıya ulaştığını doğrulamaya yardımcı olur.
Hesap için onaylanan tek yöntemi etkinleştirin. Yalnız genel bir test e-postasına güvenmeyin; parola sıfırlama, form ve sipariş akışlarını da sınayın. Yenileme ve iptalden sorumlu kurum hesabını ve ekibi kaydedin.
AIOWS Google politikasını belirlemez, OAuth projesi oluşturmaz, scope vermez ve Google hesabını kurtarmaz. Bunlar Google Workspace ve kurum güvenliği görevleridir. Kimlik doğrulama veya sahiplik doğrulanamıyorsa geçici bilgileri kaldırıp son onaylı ayara dönün.
AIOWS SMTP Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Gmail SMTP OAuth: Güvenli Kurulum Rehberi
- SMTP 25, 465 ve 587 Portlarından Hangisi WordPress İçin Doğru?
- WordPress İçin Google Workspace SMTP Nasıl Ayarlanır?
Sonuç ve önerilen yol
Seçimi güncel Google politikası, en az yetki, kurumsal sorumluluk ve güvenli iptal sürecine göre yapın. Onaylanan yöntemi yalnız bu site için kullanın, korumalı biçimde saklayın ve sorumlu ekibi belirleyin; gizli bir ikinci erişim yöntemi açık bırakmayın.
