Kötü niyetli bir kullanıcı, bir kuruluşun MySQL veritabanından yararlanacak güvenlik açıkları bulabilir. Bu nedenle, veritabanı faaliyetlerinin izlenmesi her işletmenin temel bir uygulaması olmalıdır. Bilgisayar korsanları, gizli verileri çalmak için tasarlanmış saldırıları serbest bırakır ve birincil hedefleri bir kuruluşun MySQL veritabanı sunucularıdır. Veritabanlarının en çok risk altındaki varlıklardan biri olduğu bilinmektedir.
Veritabanı neden bu kadar sık hedefleniyor? Basit - Veritabanı, müşteri kayıtlarını ve diğer gizli iş verilerini depolayan herhangi bir kuruluşun kalbidir. Kuruluşlar, bu önemli varlıkları korumaya gelince en az önceliği verir.
Bilgisayar korsanları ve içerideki kötü niyetli kişiler hassas verilere eriştikten sonra, sonraki adımları hızla değer elde etmek, zarar vermek veya iş operasyonlarını etkilemektir. Mali kayıp veya itibar zararının yanı sıra, ihlaller ayrıca düzenleme ihlallerine, para cezalarına ve yasal ücretlere vb. Neden olur.
Bir müşterinin veritabanındaki kötü niyetli faaliyet nedeniyle milyonlarca dolar kaybettiği aşağıdaki vaka çalışmasına bir göz atalım:
vaka Çalışması
Şirket adı: Capital One
Bağlantı: https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
Sorun:
Capital One bankası, bir güvenlik açığı saldırısı nedeniyle 150 milyonluk en önemli kayıplardan birine uğradı.
Sonuç:
Bir yazılım mühendisi ve Capital One bankasından önceki bir çalışan şirket sunucusuna girerek müşteri verilerini tuttu ve 100 milyondan fazla kişinin kişisel verilerini ele geçirdi. Amazon Web Services, müşteri veritabanını barındırır ve tesadüfen, mühendis daha önce Amazon'da çalışıyordu.
Mahkeme ve Capital One'a göre, bilgisayar korsanı 140,000 Sosyal Güvenlik numarasını ve 80,000 banka hesap numarasını çaldı. On milyonlarca kredi kartı başvurusunun yanı sıra ihlal edildi. Hırsızlık, Amerikalılar için Sosyal Güvenlik numaralarına eşdeğer olan bir milyon Kanada sosyal sigorta numarasını tehlikeye attı. Çalınan veri aralığı, 2005 yılı kadar erken ve en sonuncusu 2019 yılıydı.
Banka, ihlalin, etkilenen müşteriler için kredi izleme için ödeme de dahil olmak üzere 150 milyon dolara kadar mal olacağını beklediğini açıkladı. Güvenlik duvarında açık bir güvenlik açığı olduğu ve bilgisayar korsanı AWS'de barındırılan veritabanına kolayca erişebildiği için ihlal olasıydı.
AWS'de eski bir çalışan olan güvenlik açığından, veritabanına sızmak ve müşteri verilerini manipüle etmek için iyi bir şekilde yararlanıldı. Güvenlik açığının nasıl kullanılmış olabileceğine dair olası bilgi birikimi.
Bildiğimiz gibi, veritabanları tüm müşteri ve işlem verilerini depolamak için kullanılır. Bilgisayar korsanı, Banka Veritabanından veri ekleyerek / çıkararak veya hatta veri çıkararak DB'yi manipüle etti.
Bu veritabanını izlemek için uygun güvenliğe sahiplerse, bu, zmanda ZRM ürünü, böyle bir tehdit tespit edilmiş ve proaktif olarak gerçekleşmesi engellenebilirdi. Banka güvenlik açığını giderdi ve artık bu tür dolandırıcılıkları kontrol etmek için daha katı yöntemler uyguluyor.
Kötü Amaçlı Algılama Zmanda Kullanarak MySQL Veritabanı Etkinliği
Kuruluşlar, çok katmanlı bir veritabanı güvenlik savunma stratejisi benimsemelidir. En iyi uygulamaların benimsenmesi, veri açığa çıkma riskini makul ölçüde azaltabilir. çeşitli saldırı vektörler. Örneğin Zmanda, veritabanı yedeklerinden kötü amaçlı etkinlikleri tespit edebilir
MySQL için ZRM MySQL ikili günlüklerini veritabanı yedeklemelerinin bir parçası olarak depolar. İkili günlükler, tüm veritabanı etkinliği için uygun bir denetim izi sağlar. MySQL için ZRM ikili dosyası, zaman kurtarmada belirli bir nokta için günlük ayrıştırma yeteneğini kullanır ve SQL denetimi kullanarak kötü amaçlı veritabanı etkinliklerini tespit eder.
MySQL için ZRM eklenti arayüzü, DBA'ların (Veritabanı Yöneticisi) belirli / tüm veritabanı etkinliklerini izlemek ve izlemek için günlük ayrıştırıcı eklenti komut dosyaları yazmasına olanak tanır. Örneğin, aşağıdaki kod, veritabanındaki ÜRÜNLER tablosundan verilerin silinmesini algılayabilir. Bu komut dosyası, ÜRÜNLER tablosundaki silinmiş satır öğelerinin tüm örneklerini yazdırır.
@fields = bölme (/ \ | /, $ ARGV [0]);
benim $ SQL_VERB = ”SİL”;
$ TABLE_NAME = ”ÜRÜNLERİM”;
eğer (($ alanlar [3] == "Sorgu") && \
($ alanlar [4] = ~ / $ SQL_VERB * FROM. * `$ TABLE_NAME` /)) {
“$ alanları [2] $ alanları [4] \ n” yazdır;
}
Mysql-zrm komutu, tüm yedeklemeler veya belirli bir yedek imaj için özelleştirilmiş eklenti komut dosyasını çalıştırır. Aşağıdaki komut, 9 Aralık 2019 tarihli bir yedek görüntüde ÜRÜNLER tablosundan silinmeyi arar.
# mysql-zrm –action ayrıştırma binlogları \
–Kaynak dizini / var / lib / mysql-zrm / fiyat defteri / 20061205142103 \
–Parse-binlogs-plugin /usr/share/mysql-zrm/plugins/detect_deletion.pl
Komutun çıktısı, kötü amaçlı veritabanı silme işlemlerinin yanı sıra geçerli silmeleri de içerecektir.
Benzer şekilde, müşteriler kendi komut dosyasını kurabilir ve ihtiyaca göre yedeklemeden önce ve sonra yedeklemeden önce ve sonra çalıştırıp doğrulatabilir ve bunlar için göze çarpan bir özelliktir. MySQL için ZRM.
Aşağıda verilen ekran görüntüsü, eklenti adını, yolunu ve yürütmeyi yapılandırabileceğiniz ZRM'deki Yedekleme | Nasıl sayfasına atıfta bulunmaktadır.
Pre and Post backup-plugin parametresi, eklentinin adını ve tam yolunu içermelidir. "/ Usr / share / mysql-is database / plugins" dizinindeki eklentiler için önerilen konum.
Sarmak!
Çeşitli güvenlik açığı tehditlerine ilişkin yüksek bilinç düzeyine rağmen, son yıllarda olayların sayısı artmıştır. Bu olayların mağdurlarının maruz kaldıkları maliyetler neticesinde veri ihlallerinin artması nedeniyle işletme maliyetini çok önemli bir seviyeye çıkarmıştır. Bu olayların etkisini azaltmak için, bir kuruluşun veri ihlali nedeniyle oluşan toplam maliyeti en aza indirmek için uygun prosedürleri benimsemesi ve etkin bir izleme ve tespit aracına sahip olmaması gerekir.
Ayrıca şunu kontrol ettiğinizden emin olun: Felaket Kurtarma Planınıza Dahil Edilecek Noktalar
