deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

MySQL'un genel sorgu log'u sessizce düz metin parolaları kaydediyor

Bir dev.to yazısı, general_log açık olduğunda MySQL ve MariaDB'nin genel sorgu log'unun CREATE USER ve ALTER USER komutlarındaki parolalar dahil her ifadeyi kelimesi kelimesine kaydettiği konusunda uyarıyor.

MySQL'un genel sorgu log'u sessizce düz metin parolaları kaydediyor

dev.to'da yayımlanan bir yazı, rutin bir MySQL ve MariaDB tanılama ayarındaki sessiz bir güvenlik sorununa dikkat çekiyor: genel sorgu log'unun açılması, sunucunun aldığı her ifadenin kelimesi kelimesine düz metin kaydını üretiyor ve CREATE USER ... IDENTIFIED BY 'password' gibi hesap yönetimi ifadeleri parola tamamen korunmuş halde bu kayda düşüyor.

Genel sorgu log'u varsayılan olarak kapalıdır. dev.to yazısına göre general_log = 1 ayarlanınca her bağlantı, her ifade ve her bağlantı kesme işlemi log_output tarafından seçilen hedefe kaydediliyor; bu hedef bir dosya, bir tablo veya ikisi olabilir ve dosya yolu general_log_file ile belirlenir. İfadeler alındıkları haliyle, hiç değiştirilmeden yazılır.

Diske ne düşüyor

Yazıya göre CREATE USER'ın yanı sıra ALTER USER ... IDENTIFIED BY, GRANT ... IDENTIFIED BY ve değişmez (literal) bir sır içeren herhangi bir uygulama sorgusu da gönderildiği gibi çıktıda yer alıyor. Oturum değerleri, tek kullanımlık token'lar veya kişisel veri taşıyan ifadeler de yakalanıyor.

Bu değişken, yapılandırma dosyasına dokunulmadan, SYSTEM_VARIABLES_ADMIN yetkisine sahip herhangi bir hesap tarafından runtime'da da açılabilir. Yazar bunun denetimler için önemli olduğunu savunuyor: önemli sorular log'u kimin açabildiği ve çıktının gerçekte nereye gittiği haline geliyor; yapılandırma dosyasını incelemek bu ikisine de cevap vermiyor çünkü dinamik bir ayar dosyayı geçersiz kılıyor.

Açık bırakmanın riskli olmasının nedeni

Yazı, log'un sınırlı bir inceleme dışında çalıştırılmasının üç sorununu sıralıyor:

  • Kimse böyle sınıflandırmadığı halde bir kimlik bilgisi deposuna dönüşüyor. Loglanan bir ifadedeki parola, dosyayı okuyabilen herkese açığa çıkıyor ve bir veri dizinindeki izinler normalde içeriğin gizliliği için değil, sunucu süreci için ayarlanmıştır.
  • Genişlik. Log, izleme, raporlama ve uygulama hesapları dahil her hesaptan gelen her sorguyu tutuyor; dolayısıyla dosyayı okuyan tek biri fiilen sunucunun tamamını görmüş oluyor.
  • Saklama süresi. Döndürülen log'lar operatörün yapılandırdığı hedefe kopyalanıyor ve bir yedekleme biriminde duran bir kopya, onu üreten incelemeden daha uzun süre yaşıyor.

Komşu log'lar

Yazıya göre slow query log ve binary log, tanımlı koşullar altında ifadeleri kaydediyor ve ifadeye ve replikasyon formatına bağlı olarak değişmez değerleri de yakalayabiliyor. Genel log üçünün en genişi ve aceleyle birisi tarafından en çok açılması muhtemel olanı.

Bir inceleme kontrol listesi

Yazı şu önerileri sıralıyor:

  • Dinamik bir değişken ayarlandığında yapılandırma dosyası bağlayıcı olmadığı için her sunucuda general_log, log_output ve general_log_file'ın runtime değerlerini kontrol edin.
  • Kullanımı sınırlandırın: log'u tanımlı bir süre için açın, çıktıyı kontrollü bir konuma yönlendirin, sonra devre dışı bırakıp döndürün ve ikisini de kimin yaptığını kaydedin.
  • Fiilen bir ifşa yeteneği olan SYSTEM_VARIABLES_ADMIN yetkisini kısıtlayın.
  • Çıktıyı bir sır olarak koruyun; dosya izinleri, içindeki ifadelerin hassasiyetine uygun, genellikle veri dizini varsayılanından daha katı olmalı.
  • Değişmez değer içeren ifadeler için yedekleri ve log iletimini inceleyin ve saklamadan önce temizlemeyi düşünün.
  • Süregelen tanılama için performans şemasını ve iş yüküne göre ayarlanmış long_query_time ile slow query log'u tercih edin; çünkü ikisi de varsayılan olarak daha az kaydeder.

Neden önemli

Genel sorgu log'u tam tasarlandığı gibi çalışan, belgelenmiş bir özellik ve yazı, gerçek maruziyetin log'un açık olup olmamasına, çıktıyı kimin okuyabildiğine ve iş yükünün hangi ifadeleri gönderdiğine bağlı olduğunu özenle belirtiyor. Onu pratik bir tuzak yapan da tam bu: baskı altında birisinin uzandığı anahtar, dinamik olduğu için yapılandırma dosyası denetimlerinden kaçıyor ve rutin yönetimi sessizce, kopyaları döndürme ve yedekler yoluyla yayılan kalıcı bir kimlik bilgisi deposuna dönüştürüyor. Log dosyasına sır muamelesi yapmak ve onu açma ayrıcalığını bir ifşa yeteneği olarak görmek, yazının veritabanı yöneticilerinden istediği operasyonel değişimdir.

  • #mysql
  • #mariadb
  • #database-security
  • #logging
  • #sysadmin