Bilgi Bankası
GenelGüvenlik ve yetki 15 dk 14.06.2026

Destek erişimi ve acil erişim: canlı ortam veritabanına ne zaman, nasıl bakılır?

Canlı ortam verisine bakmak bazen gerçekten gerekir; ama “bir bakıp çıkacağım” cümlesi güvenlik modeli olamaz. Destek erişimi süreli, gerekçeli, mümkünse salt okunur ve denetimli olmalıdır.

Bu yazı sana şu durumda yardımcı olur
  • destek ekibi müşteri sorununu incelemek için canlı ortam verisine bakmak istiyor
  • kimin ne zaman eriştiği sonradan kanıtlanamıyor
  • admin kullanıcı günlük destek işleri için kullanılıyor
  • müşteri verisine erişim onay ve gerekçe olmadan ilerliyor
  • acil durumda yetki açılıyor ama kapatılması unutuluyor
Yazıyı bitirince

Destek erişimini normal destek, salt okunur inceleme ve acil erişim acil durum olarak ayırabilecek; erişimi kapatmayı da sürecin parçası yapabileceksiniz.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB’nin platform-admin ve denetim yaklaşımı bu tür aksiyonların izli yapılmasını hedefler. En sağlıklı kullanım, destek erişimini günlük admin parolasıyla değil, süreli ve gerekçeli akışlarla yönetmektir.

Her destek erişimi acil erişim değildir

Acil erişim, camı kırıp acil müdahale etmek demektir. Her destek talebi bu seviyede değildir. Çoğu inceleme salt okunur kullanıcı, maskelenmiş veri veya müşteriyle paylaşılan log/metric üzerinden yapılabilir.

Bu ayrımı yapmak önemlidir; çünkü her şeyi acil durum gibi yönetirseniz süreç gevşer. Gerçek acil durumda ise neyin istisna olduğu belirsizleşir.

  • Normal destek: log, metrik ve müşteri tarafından paylaşılan bilgiler.
  • Readonly inceleme: süreli, gerekçeli, sınırlı sorgu erişimi.
  • Acil erişim: ciddi olay veya veri bütünlüğü riski, onay ve denetim zorunlu.
  • Yazma yetkisi: çok istisnai, ayrı onay ve geri dönüş planıyla.

Readonly destek kullanıcısı varsayılan olmalı

Destek ekibinin canlı ortam verisine yazabilmesi normal bir varsayım olmamalıdır. İnceleme için çoğu zaman SELECT yeterlidir. Yazma gerekiyorsa bu artık destek değil, kontrollü operasyon aksiyonudur.

Geçici salt okunur kullanıcı fikri

support-readonly.sh
turkdb cluster users create app-pg --username support_readonly_20260614 --role readonly

# İnceleme bitince:
turkdb cluster users list app-pg
turkdb cluster users delete app-pg <support-user-id>
Bu TürkDB bloğu kavramsal ürün akışını anlatır; mevcut çalışan komut, garanti edilen özellik veya teslim tarihi vaadi olarak okunmamalıdır.

Kullanıcı adında tarih/amaç taşımak temizlik yapmayı kolaylaştırır. Kalıcı destek kullanıcıları düzenli gözden geçirilmelidir.

Gerekçe ve süre olmadan erişim açmayın

“Müşteri sorunu” tek başına yeterli gerekçe değildir. Hangi müşteri, hangi olay, hangi veri alanı, ne kadar süre, kim onayladı ve erişim ne zaman kapatılacak? Bu bilgiler yazılmalıdır.

Bu bilgiler denetim kaydıyla birleştiğinde hem ekip hem müşteri için güven üretir. Destek erişimi gizli bir arka kapı değil, denetlenebilir bir operasyon olur.

Destek erişimi karar notu

support-access.md
Müşteri: acme
Kaynak: app-pg
Amaç: ödeme sonrası sipariş kaydı gecikmesi incelemesi
Yetki: salt okunur
Süre: 30 dakika
Onay: olay sorumlusu + müşteri başarı sorumlusu
Kapanış: erişim silindi, denetim kaydı kontrol edildi

Erişimi kapatmak işin son adımı değil, kanıtıdır

Destek erişimi açıldıktan sonra kapatılması unutuluyorsa süreç güvenli değildir. Kapanış notu, erişimin ne zaman kaldırıldığını ve hangi bulgunun elde edildiğini içermelidir.

TürkDB tarafındaki kullanıcı listesi ve denetim kayıtları bu kapanış kontrolüne yardımcı olur. İyi destek süreci, müşteriye “baktık” değil, “şu kapsamda, şu süreyle, şu iz bırakarak baktık” diyebilir.

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler