n8n Sunucuda Kimlik Bilgileri Nerede Durmalı?

n8n’i kendi sunucunuzda çalıştırırken en kritik konulardan biri, API anahtarları, OAuth token’ları, veritabanı şifreleri ve servis hesapları gibi hassas bilgilerin nerede ve nasıl tutulacağıdır. Yanlış konumlandırılmış bir kimlik bilgisi, yalnızca tek bir entegrasyonu değil; bağlı CRM, e-posta, ödeme, ERP veya bulut servislerini de riske açabilir. Bu nedenle yapılandırma, yalnızca “çalışıyor” seviyesinde değil, güvenlik ve sürdürülebilir operasyon açısından da doğru tasarlanmalıdır.

n8n Kimlik Bilgilerini Varsayılan Olarak Nerede Tutar?

Self-hosted n8n kurulumlarında credential verileri genellikle n8n’in kullandığı veritabanında saklanır. Bu bilgiler düz metin olarak tutulmaz; n8n, kimlik bilgilerini şifreleyerek kaydeder. Ancak bu güvenliğin temel şartı, şifreleme anahtarının doğru yönetilmesidir.

Kurumsal kurulumlarda n8n kimlik bilgileri güvenliği için en önemli değişkenlerden biri N8N_ENCRYPTION_KEY değeridir. Bu anahtar sabit, güçlü ve yalnızca yetkili sistem kullanıcılarının erişebileceği bir yerde tutulmalıdır. Anahtar kaybolursa mevcut credential kayıtlarını okumak mümkün olmayabilir; yetkisiz kişilerin eline geçerse şifreli verilerin güvenliği zayıflar.

Kimlik Bilgileri Workflow İçinde Tutulmamalı

En sık yapılan hatalardan biri, API anahtarlarını doğrudan node alanlarına, açıklama metinlerine, test verilerine veya workflow JSON çıktısına yazmaktır. Bu yaklaşım özellikle Git, yedekleme sistemleri veya ekip içi paylaşım kanalları kullanılıyorsa ciddi risk üretir.

Doğru yöntem, n8n’in credential yönetimini kullanmak ve workflow içinde yalnızca ilgili credential referansını seçmektir. Böylece iş akışı dışa aktarılsa bile hassas veriler doğrudan paylaşılmış olmaz.

Sunucuda Güvenli Saklama İçin Temel Yaklaşım

Veritabanı güvenliğini ayrı ele alın

n8n credential kayıtları veritabanında şifreli tutulsa bile veritabanı erişimi sınırsız bırakılmamalıdır. PostgreSQL veya SQLite kullanıyorsanız, dosya ve servis izinlerini minimum yetki prensibine göre düzenleyin. Veritabanı portunu gereksiz yere internete açmayın; mümkünse yalnızca uygulama ağı içinde erişilebilir tutun.

Şifreleme anahtarını ortam değişkeniyle yönetin

Üretim ortamında şifreleme anahtarı kod deposunda, paylaşılan notlarda veya workflow dosyalarında bulunmamalıdır. Docker kullanıyorsanız environment değişkenleri, Docker secrets veya sunucu taraflı güvenli secret yönetimi tercih edilmelidir. Basit kurulumlarda .env dosyası kullanılabilir; ancak bu dosyanın izinleri daraltılmalı ve asla Git deposuna eklenmemelidir.

Yedeklerde credential riskini unutmayın

Veritabanı yedekleri, n8n credential kayıtlarını da içerebilir. Bu nedenle yedek dosyaları da hassas veri kabul edilmelidir. Yedeklerin şifreli saklanması, erişim kayıtlarının izlenmesi ve gereksiz eski yedeklerin belirli periyotlarla temizlenmesi gerekir.

Docker, VPS ve Kubernetes Ortamlarında Dikkat Edilecekler

VPS üzerinde çalışan tek sunuculu yapılarda .env dosyası pratik bir çözüm olabilir; fakat dosya izinleri doğru verilmelidir. Sadece n8n servisini çalıştıran kullanıcı bu dosyayı okuyabilmelidir. Root dışındaki gereksiz kullanıcıların erişimi kapatılmalıdır.

Docker Compose kullanılan ortamlarda environment değişkenlerini açık şekilde compose dosyasına yazmak yönetim açısından kolay görünse de ekip içi paylaşım ve versiyonlama sırasında risk yaratabilir. Daha güvenli bir yapı için secret dosyaları, CI/CD değişkenleri veya sunucunun kendi gizli değişken yönetimi kullanılmalıdır.

Kubernetes tarafında ise Secret nesneleri tek başına yeterli kabul edilmemelidir. Etcd şifreleme, namespace izolasyonu, RBAC kuralları ve secret erişimlerinin sınırlandırılması birlikte değerlendirilmelidir.

Hangi Bilgi Nerede Durmalı?

• API anahtarları ve token’lar: n8n credential alanlarında tutulmalı, workflow içine düz metin yazılmamalıdır.
• N8N_ENCRYPTION_KEY: ortam değişkeni veya güvenli secret yönetiminde saklanmalıdır.
• Veritabanı şifresi: .env, secret manager veya container secret mekanizması ile yönetilmelidir.
• Workflow dosyaları: hassas veri içermeyecek şekilde dışa aktarılmalı ve paylaşılmalıdır.
• Yedekler: şifreli, erişimi sınırlı ve düzenli yaşam döngüsüne sahip olmalıdır.

Operasyonda Sık Yapılan Hatalar

Kimlik bilgilerini test amaçlı geçici olarak node içine yazıp daha sonra silmeyi unutmak, oldukça yaygın bir hatadır. Benzer şekilde, hata ayıklama çıktılarında token veya yanıt gövdelerinin loglara düşmesi de beklenmeyen veri sızıntılarına neden olabilir. Log seviyesini üretim ortamında kontrollü tutmak ve hassas yanıtları gereksiz yere kaydetmemek gerekir.

Bir diğer kritik nokta personel değişiklikleridir. Ekipten ayrılan kullanıcıların n8n, sunucu, veritabanı ve bağlı servis erişimleri aynı anda gözden geçirilmelidir. Sadece n8n hesabını kapatmak yeterli olmayabilir; ilgili API anahtarlarının da döndürülmesi gerekebilir.

Kurumsal Kullanım İçin Pratik Kontrol Listesi

n8n sunucuda kimlik bilgileri nerede saklanmalı sorusunun güvenli yanıtı; credential verisini n8n’in şifreli yapısında, şifreleme anahtarını ise uygulamadan ayrı ve erişimi sınırlı bir secret katmanında tutmaktır. Buna veritabanı izolasyonu, yedek güvenliği ve erişim denetimi eşlik etmelidir.

• N8N_ENCRYPTION_KEY sabit ve güçlü mü?
• .env veya secret dosyaları Git dışında mı?
• Veritabanı yalnızca gerekli servislerden erişilebilir mi?
• Yedekler şifreli ve erişimi sınırlı mı?
• Workflow dışa aktarımlarında düz metin credential bulunmadığı kontrol ediliyor mu?
• API anahtarları için periyodik rotasyon planı var mı?

Bu yapı kurulduğunda n8n, otomasyon süreçlerinde esnekliğini korurken hassas servis bağlantıları daha kontrollü, izlenebilir ve yönetilebilir bir güvenlik çerçevesi içinde çalışır.