QueryProxy

Parola paylaşmadan üretim veritabanı erişimi

Paylaşılan veritabanı parolasının neden sahibi olmadığı, neye mal olduğu ve kimlik bilgisi dağıtmadan geliştiricilere üretim verisine nasıl erişim verileceği.

3 dk okuma

Geliştiricilere parola paylaşmadan üretim verisine erişim vermenin yolu, onlarla veritabanı arasına bir broker koymaktır: kimlik bilgisi tek yerde durur, insanlar bağlanmak yerine ifade gönderir ve bir şey çalışmadan önce ikinci bir kişi onaylar. Bunca zahmete girmenin sebebi derli toplu olmak değil. Paylaşılan bir parola, “bunu kim yaptı?” sorusuna cevap veremeyen tek denetimdir.

Paylaşılan parolanın nesi yanlış?

Üç şey ve her biri ekip büyüdükçe daha da kötüleşir.

  • Sahibi yoktur. İki mühendis biliyorsa veritabanı tek bir kullanıcı görür. app_rw’nin bir DELETE çalıştırdığını söyleyen bir denetim kaydı, bunu hangi kişinin yazdığı hakkında hiçbir şey söylemez. Veritabanı erişim denetiminin ne olduğu bunu bir ilke olarak koyar: her eylem bir kişiye kadar izlenebilmelidir.
  • Kullanıldığı an bir kopyadır. Bir istemciye, bir kabuk geçmişine, bir .pgpass dosyasına, bir sohbet dizisine yapıştırılır. Bastion host karşılaştırması aynı etkiyi anlatır: kimlik bilgisi biri onu değiştirene kadar geçerli kalır; pratikte bu, birinin ayrıldığı andır.
  • Değiştirmek ya hep ya hiçtir. Değiştirmek, onu kullanan her kişiyi ve her betiği aynı anda bozar; bu yüzden değiştirilmez.

Bir bastion host ya da vault bunu çözer mi?

Başka bir sorunu çözerler. Bastion, veritabanına ulaşmayı önce bir atlama sunucusuna ulaşmak haline getirir; bu da bir anahtar ve adı konabilir bir kişi demektir. Vault, parolayı bir wiki’den uzak tutar. İkisi de gerçek iyileştirmedir ve ikisi de oturumun başladığı yerde biter. Bağlantı yönlendirildikten sonra mühendis canlı bir oturumu ve kimlik bilgisini elinde tutar, ifadeyi kimse gözden geçirmez ve sonuç bütünüyle geri döner.

AWS IAM veritabanı kimlik doğrulaması kimlik konusunda daha ileri gider: parolanın yerine kişi başına kısa ömürlü bir token koyar. Yine de ifadeyi okumaz, ikinci bir kişiye de sormaz. Kimliği doğrulanmış olmak ile yetkili olmak farklı sorulardır. StrongDM ve just-in-time erişim ile PAM araçları gibi erişim platformları kimin içeri gireceğine ve ne kadar süreyle gireceğine karar verir; Hoop.dev ise veritabanının önüne bir guard koyar. Her birinin nereye oturduğunu karşılaştırma sayfaları söyler.

Bir broker neyi değiştirir?

Bir broker, kimlik bilgisini insanların elinden alır ve bağlantının eskiden durduğu yere bir iş akışı koyar. QueryProxy ile:

  1. Bir DBA hedef veritabanını kaydeder. Host, port, veritabanı, kullanıcı adı ve parola AES-256 ile şifreli saklanır; parola kaydedildikten sonra bir daha gösterilmez.
  2. Bir DBA bir geliştiriciye bağlantı yetkisi verir. Yetkisi verilmemiş bağlantılar editörde görünmez.
  3. Geliştirici SQL gönderir. İfade önce SQL korumalarına karşı parse edilir; böylece WHERE’siz bir UPDATE bir gözden geçirene hiç ulaşmaz.
  4. Bir DBA onaylar ya da reddeder. Kendi talebini onaylama engellenir ve bir yönetici geçersiz kılması denetim günlüğünde işaretlenir.
  5. İşçi saklanan kimlik bilgisiyle bağlanır, ifadeyi çalıştırır ve her adımı denetim günlüğüne yazar.

Her adımın referansı onay akışıdır. Önemli olan değişikliğin biçimi: geliştirici veritabanı için bir sır değil, portalda bir kimlik taşır.

Nerede yetersiz kalır?

  • Bir bileşen daha demektir. Portal artık veritabanı kimlik bilgilerinizi tutar; bu yüzden barındığı host, uygulama anahtarı ve HTTPS yapılandırması önem kazanır. Üretim güvenliği rehberi, portalı dışarı açmadan önce yapılacakları listeler.
  • Anlık işlerde daha yavaştır. Bekleyen bir istek biri karar verene kadar bekler; otomatik sona erme yoktur. Ekibiniz bütün gün üretimde hata ayıklıyorsa kuyruk tasarım gereği sürtünmedir.
  • Veritabanı tarafı sınırlar henüz yok. Salt okunur çalıştırma ve veritabanında uygulanan bir ifade zaman aşımı v0.3.0 için planlı. O zamana kadar yalnızca okuyanlara yalnızca SELECT yetkili bir bağlantı verin.
  • Bir break-glass yolu bulundurun. Gece 3’teki bir olay kuyruğa bağlı olmamalı.

Kimin zahmet etmesine gerek yok?

Tek veritabanı olan ve migration’ları CI’dan çalıştıran üç kişilik bir ekibin, bir portala değecek bir paylaşılan parola sorunu yoktur. Acı, üretime elle bakması gereken birkaç kişi olduğunda ve kimin neyi çalıştırdığını artık söyleyemediğinizde başlar. Bunun sizin yığınınızda nereye düştüğünü motor sayfaları gösterir: PostgreSQL ve MySQL ile MariaDB.

Sık sorulanlar

Geliştiriciler veritabanı parolasını bilmeden üretimi sorgulayabilir mi?
Evet, onlar adına başka bir şey bağlanıyorsa. QueryProxy'de bağlantı kimlik bilgisi portalda şifreli olarak saklanır. Geliştirici, bir DBA'nın yetki verdiği bağlantıya SQL gönderir; ikinci bir kişi onayladıktan sonra işçi (worker) bağlanır. Geliştirici parolayı hiç görmez.
Bir parola yöneticisi yeterli mi?
Saklamayı çözer, kullanımı çözmez. Birkaç kişinin okuduğu bir vault kaydı yine paylaşılan bir kimlik bilgisidir ve bir istemciye yapıştırıldığı an bir kopyadır. Vault ifadeyi okumaz, ikinci bir görüş istemez, hangi ifadenin çalıştığını da kaydetmez.
Doğrudan erişimi kaldırınca neyden vazgeçersiniz?
Anlık işlerdeki hızdan. Her ifade bir gözden geçirenin yolunu bekler ve QueryProxy bekleyen bir isteği, biri karar verene kadar, otomatik sona erme olmadan açık tutar. Olaylar için belgelenmiş bir break-glass yolu bulundurun.
Bu, IAM kimlik doğrulamasının ya da bir bastion host'un yerini alır mı?
Hayır. Onlar veritabanına kimin ulaşacağını denetler. QueryProxy bu adımın sonrasında durur ve hangi ifadenin çalışacağına ve buna kimin onay vereceğine karar verir. Ekipler çoğu zaman iki katmanı da korur.
Paylaş

İlgili yazılar

Gezinmek için ok tuşları, açmak için Enter.