Grid'de Veritabanlarını Denetleme

SendGrid kısa süre önce halka açık bir şirket haline geldiğinden, veritabanlarımızın bir alt kümesindeki tüm değişikliklerin tam denetim günlüklerine sahip olmamız gerekiyordu. Bu alt küme, büyük hacimli trafik görmeyen bazı küçük örneklerin yanı sıra müşteri portalı çalışma süremiz ve kayıt akışımız için kritik olan bazı eski kümelerimizi de içeriyordu.

Bu aynı zamanda yüksek çalışma süresi talepleri olan bazı veri depolarını da etkiledi ve çevrimiçi kullanıma sunma (yazma için kapalı kalma süresi olmadan) arzu edilen bir durumdu. Elimizde harici bir son teslim tarihi ve projenin kapsamını bilerek bir plan yapmak için yola çıktık.

Planlama aşamasında, yanıtlanması gereken birkaç açık soru belirledik:

1. Bunu yapabilen yazılım olarak ne gibi seçeneklerimiz var?
2. Hangi performans etkisi bekleniyor ve bunu önceden ne kadar test edebiliriz?
3. Yazma kullanılabilirliği için kesinti olmadan bunu yapabilir miyiz?

Seçimler, seçimler

SendGrid'de, herhangi bir büyük veya ekipler arası proje için bir tasarım planı süreci izliyoruz. Bu proje, aşağıdakiler de dahil olmak üzere paydaşlar olarak bir dizi ekibi içeriyordu:

• Bu uygunluk kontrolü için hangi veri deposunun kapsam dahilinde olduğunu belirlemekten ve kanıt toplamaktan sorumlu ekip olarak İç Denetim , denetim zamanı gelir.
• InfoSec , bu veritabanı denetim günlüklerinden elde edilen olay yanıtını analiz edecek ve ele alacak ekip olarak
• Kapsam dahilindeki veritabanlarına bu yeni özelliği dağıtan, yöneten ve ayarlayan kodu yazan ekip olarak DB Ops

Bu planı yazmaya ve tüm paydaşlar tarafından incelenip mimari ekibimiz tarafından onaylandığından emin olmak için yola çıktım. Birkaç yıl önce MySQL'de denetim günlüğü konusunda biraz araştırma yapmış olmama ve seçenekler için ortamın nasıl göründüğüne dair bir fikrim olmasına rağmen, projeye önyargılarla yaklaşmak istemedim ve yine de birden fazla araştırma yapmak istedim. seçeneği ve herkese neden bir çözümü diğerine tercih edeceğimiz konusunda sağlam bir örnek sunun.

Bu plan olağandışıydı, çünkü aynı anda onu iş ihtiyacına yönelik çözümün ne olacağını araştırırken yazıyordum. Bu yüzden biraz araştırma yaptıkça birçok detayın doldurulacağını biliyordum.

Seçeneklerimiz şunlardı:

• Percona denetim eklentisi
• Mcafee MySQL Denetimi

Bunlar piyasadaki tek seçenek olmasa da, gerçek pişirmeye dahil edilmeyi garanti etmek için ölçeğimize ve devops uygulamalarımıza en yakın olduklarını hissettik. Piyasadaki diğer ticari seçenekler, kıyaslama ölçütüne dahil edilmek için bu çıtayı geçmedi.

İkincisi, Mcafee kaynaklı daha yeni bir çözümdü ve Percona eklentisinin desteklemediği tablo düzeyinde filtrelemeyi desteklediğini iddia ettiği için araştırılması yeterince ilgi çekiciydi. Kapsam içi kümelerimizden birinin toplam 300 tablonun yaklaşık 24 tablosunu gerçekten denetlemesi gerektiğini bildiğimizden, bu Mcafee eklentisini bir yarışmacı yapmak için yeterince değerli bir özellik gibi görünüyordu.

Öte yandan, Percona Audit eklentisi bu özellik için en yaygın kullanılan açık kaynak çözümüydü. Zaten kullandığımız Percona Sunucusunda yerleşik olarak gelir ancak devre dışı bırakılır. Ancak, olayların tablo düzeyinde filtrelenmesini sağlamaz, bu da bunu veritabanı katmanının dışında yapmamız gerektiği anlamına gelir.

pişirme

Pythian'daki ortak ekibimizin yardımıyla, hazır karşılaştırmaya başladık. İlk başta, her seçeneğin nasıl kurulacağını ve ayarlanacağını karşılaştırdık. Ekip çabucak elimizde bir takas olduğuna karar verdi. Mcafee eklentisi tablo filtrelerini yerel olarak desteklerken, olaylarını akış yöntemi olarak rsyslog kullanmayı desteklemiyordu. Bu, eğer onu kullanacak olsaydık, dosyaları yerel olarak diske yazmamız ve onları izleme yığınına göndermeyi yönetmemiz gerektiği anlamına geliyordu.

Bu, büyük olasılıkla denetim eklentisini kullanmanın performans cezasını artıracağından arzu edilmez olarak kabul edildi. Denetim olaylarını yerel olarak yazmak ve ardından bunları ayrı bir işlemle yeniden okumak, gerçek üretim trafiğimizden IOPS kapasitesini alır ve veritabanı örneklerine yönelik riski artırır, çünkü bu dosyaların boyutunu şişip veritabanına neden olmamaları için diskte yönetmemiz gerektiği anlamına gelir. kapalı kalma süresi.

Öte yandan uzlaşma Percona eklentisi oldu. Olayları yerel olarak syslog'a göndermeyi destekler, ancak herhangi bir tablo filtresi sunmaz. Bunun, kapsamdaki daha yoğun kümelerin, çoğu aslında denetlemek istediğimiz tablolardan olmayan çok sayıda olay göndereceği anlamına geldiğini biliyorduk. Bu, InfoSec'in izleme yığınının syslog-receive/logstash katmanı için bir risk oluşturuyordu. DB operasyonlarının buna erişimi olmadığından, bu projenin başarısının ortak bir mülkiyet çabası olduğu anlamına geliyordu.

Sonuç olarak, çözümü daha az hareketli parça ile kullanmaya karar verdik ve dağıtımımızı, logstash'in saniyede binlerce olayı filtrelemek için ölçeğinin genişletilmesi gerekip gerekmediğini mümkün olduğunca erken öğrenecek şekilde planladık. Böylece Percona'nın denetim eklentisi ile ilerlemeye karar verildi.

Dağıtım planlaması

Kurulum kapsamı

Eklentiyi belirli bir kümedeki tüm düğümlerde yükleyerek ve etkinleştirerek bu dağıtımı basit tutmaya karar verdik; bu, kümedeki yazar düğümü değiştiğinde denetim olanağını açıp kapatarak düzenleme ihtiyacını ortadan kaldırdığımız anlamına geliyordu. Eklenti, tasarım gereği, çoğaltma akışı değişikliklerini kaydetmediğinden, bir değişiklik uygulandığında yinelenen olaylara neden olan çoğaltma akışı hakkında herhangi bir endişemiz olmadı.

Kesinti yok

Bunun, etkilenen kümelerde kesinti süresi olmadan sorunsuz bir dağıtım olmasını istedik. Bu, bu kümeleri kullanan dağıtım ekipleriyle yapmamız gereken planlama ve düzenleme miktarını büyük ölçüde azaltacak ve müşteri etkisini büyük ölçüde azaltacaktır. Ancak eklentinin, olayları InfoSec ekibinin sistem günlüğü toplama sunucusuna gönderecek özel bir yapılandırmayla belirli bir tesiste rsyslog'a göndermesini de istedik. Bu yapılandırmalardan bazıları Percona tarafından dinamik değil olarak belgelenmiştir ve bu, mysql örneğini gerekli denetim eklentisi yapılandırmasıyla yeniden başlattığımızda, bu proje kapsamındaki her örneğin bir süre kesintiye uğraması olasılığını sundu.

Hazırlama ortamımızda özel bir test örneği ile eklentiyi dağıtmada farklı işlem sıralarını test etmeye başladık ve konfigürasyon yönetimimiz olsaydı, önce gerekli tüm konfigürasyonları yerleştirirsek, ardından load plugin komutunu çalıştırırsak, komutun olacağını gösterebildik. istediğiniz konfigürasyonla başlayın.

Bu, hem bu projeyi tamamlama planını basitleştirmede hem de üretimde yayınlama süresini kısaltmada, olay filtrelemede ince ayar yapmak için bize zaman kazandırma ve güvenlik ekibiyle analiz ve algılama üzerinde çalışma konusunda etkili oldu.

Yapılandırma yönetimini kullanın

Veritabanlarımızı yönetmek için şef yemek kitaplarını kullanıyoruz, bu yüzden denetim eklentisini dağıtmak, ayarlamak ve izlemek için şefi kullanmayı planladık. Ancak bunun kümelerimizin yalnızca bir alt kümesinde etkinleştirilmesi gerektiğinden, günlük depolamamızı buradaki iş hedefimize uygun olmayan verilerle doldurmamak için nerede etkinleştirildiğini kontrol etmenin bir yoluna ihtiyacımız olduğu anlamına geliyordu.

MySQL veritabanlarını yönetmek için yapılandırmayı yönetmek için bir sarmalayıcı yemek kitabı modeli kullanıyoruz. Bir çekirdek 'temel' yemek kitabı, veritabanı örneğinin nasıl görünmesi gerektiğinin büyük kısmını tanımlar, ardından küme başına bir yemek kitabı, nitelikleri değiştirmek veya belirli kümeyle ilgili olan yerlerde yapılandırma eklemek için bunu sarar. Bu tasarım, gerekli yapılandırma dosyalarını oluşturacak kodun büyük bir kısmını eklemeyi ve ardından eklentiyi bir şef niteliğine göre açıp kapatabileceğimiz yeni bir tarife yüklemeyi kolaylaştırdı. Ayrıca yaptığımız değişikliğin kapsamı göz önüne alındığında, bunun bu kodu yemek kitabının yeni bir küçük versiyonu olarak yayınlamayı garanti ettiğine karar verdik.

Ayrıca, öznitelik false olarak ayarlandığında şefin ilgili tüm sensu kontrollerini kaldırmasını ve denetim akışını kapatmasını sağladık. Bu, bir kümenin artık kapsamda olmadığı kabul edilirse veya kesintili bir nedenle durdurulması gerekiyorsa şefin doğru şeyi yapabilmesini sağlamak içindi, bu nedenle öznitelik değişikliğini yansıtmak için bir düğümü manuel olarak değiştirmemize gerek yok.

izleme

İzlemediğiniz bir şeyin başarısını ilan edemezsiniz. Ancak izleme, hangi başarısızlık durumlarını izlediğimizi ve bir gün başarısız olan bu kontrollere yanıt olarak hangi eylemi beklediğimizi düşünmeden bazı duyusal kontrolleri tokatlamaktan daha fazlasıdır. Bu yüzden bu boru hattındaki izlemeyi 2 şeyi göz önünde bulundurarak planlamaya başladım.

• Bu sistemdeki açık sahiplik kapsamı konusunda hepimizin hemfikir olması gerekiyor, özellikle de ayrı çağrı üzerine rotasyonlarla 2 ekibin sorumluluklarını karşıladığı için
• Bunun için eklenen tüm yeni kontrollerin, kontrolde bağlantı kurduğumuz ve bu kontrolün neden başarısız olduğunu ve nasıl düzeltileceğini açıklayan bir runbook ile gelmesi gerekir.

Bu 2 kural göz önüne alındığında, çok özel kontroller eklemeye devam ettim. Bu noktada, uçtan uca bir 'sentetik' kontrol eklemeyi de düşündüm, ancak o zamandan beri bunu yapmaktan kaçındım, çünkü burada uçtan uca bir kontrol, bize sistemin tam olarak hangi bölümünün başarısız olduğunu söylemede başarısız olur, bu da zor olacağımız anlamına gelir. Hatta onunla doğru takıma çağrı yapma zamanı. Ve geceleri 'her ihtimale karşı' insanlara çağrı yapılması taraftarı değilim.

Aşağıdakileri izlemeye karar verdik:

• Emin olmak için denetim eklentisinin canlı mysql yapılandırmasını kontrol edin.
  • Eklenti etkin durumdaydı
  • Audit_log_policy , QUERIES olarak ayarlandı

Bu kontrol, bu ayarlar dinamik olduğundan ve diskteki my.cnf dosyasının dışında değişebileceğinden, kapsamdaki bir DB'nin yapılandırmasının anında değiştirilmediğini doğrular .

• Verilerin aktığından emin olmak için izleme yığınına günlükleri gönderdiğimiz bağlantı noktasını kontrol edin. Temel olarak, sistem günlüğü akışının diğer ucunun çalıştığından emin olmak. Bu kontrol, toplu kontrol dediği anlamda ele alınır, bu nedenle InfoSec ekibine korkunç bir şekilde sayfa göndermez

Yol boyunca engeller

Denetim eklentisi yapılandırması

Bu projenin ilk yinelemelerinden biri, yaydığımız olayları yalnızca veri veya şema manipülasyonuyla sınırlamak için audit_log_exclude_commands özelliğinden yararlanmayı amaçlıyordu. Bu konfigürasyonun dayandığı listenin beklenenden çok daha uzun olduğunu çabucak öğrendik.

rsyslog yapılandırması

İşte bu projeden önce bilmediğim bir şey. Rsyslog yapılandırması neredeyse kendi dilidir. Örneğin:

• Günlükleri UDP yerine TCP üzerinden göndermek için uzak hedefin önünde ikinci bir @ kullanın. Günlüklerin teslim edildiğini biraz daha garanti etmek için bu tesisi kullanmak istedik.
• rsyslog'un, benim gibi araca yeni başlayanlar için gerçekten yararlı olduğu kanıtlanan, güvenilir yönlendirme için nasıl yapılandırılacağına ilişkin özel bir sayfası vardır.
• rsyslog, varsayılan olarak, verilerini /var/log/messages dizinine de gönderir, bu benim durumumda istenmeyen bir durumdu çünkü bu çok sayıda olaydı. Kullanmakta olduğunuz tesisi YAPMAMANIZ gerekiyorsa, yapılandırmanızın sonuna local5.* ~ eklemeniz gerekir.

Yangın tatbikatı

Kapsamdaki veritabanları için performans sonuçları hakkında daha sonra konuşacağım, ancak rsyslog bu tasarım için çok önemli bir parça olarak kullanıldığından, rsyslog'un uzak hedefi mevcut olmadığında veya yanıt vermediğinde nasıl davranacağını da tatbik etme ihtiyacı duyduk. Bunu yapmanın en iyi yolu, yüksek işlem hacmine ve dolayısıyla saniyede çok sayıda denetim olayı olduğunu bildiğimiz kapsamdaki veritabanlarından birinde üretimde iptables kurallarını kullanarak bu iletişimde kesintiye neden olmaktı. İşte o yangın tatbikatı nasıl oynandı.

• Denetim olaylarının belirlenen TCP bağlantı noktası üzerinden aktığını doğrulayın
• Bu bağlantı noktasındaki tüm trafiği bırakmak için bir iptables kuralı kullanın /sbin/iptables -A OUTPUT -p tcp –dport {PORT-NUMBER-HERE} -j DROP
• rsyslog'un yapılandırmasında yapılandırılmış WorkDirectory'deki disk yazma etkinliğini ve dosyaları izleyin . Dosya adları, bu olayları alan tesisin ActionQueueFileName'ini temel alacaktır.

Beklendiği gibi, dosyalar bu dizinde biriktirilmeye başlandı. Disk IOPs etkinliğinde bir artış gördük. Kuyruk adını tanımlayan dosyaların sayısı, boyut olarak ActionQueueMaxDiskSpace değerine ulaştığında , rsyslog bu dosyaları oluşturmayı durdurdu, disk IOP'leri normalleşti ve artık olayları rsyslog katmanında yere bıraktığımız açıktı. İzlemesi daha etkileyici olan şey, içilebilirlik kuralını kaldırdıktan sonra, rsyslog'un diske biriktirdiği tüm olayları yeniden göndermesiydi, böylece biriktirme boyutunu aşmadığımız sürece analiz depomuz için olay kaybı yaşamadık. Bu deneye dayanarak birkaç şey öğrendik

• rsyslog belgelendiği gibi davranıyor. Bunu ilk elden deneylerle kanıtlamak her zaman daha iyidir
• Her birinin oluşturduğu olayların hacmine bağlı olarak küme başına büyük olasılıkla farklı bir kuyruk disk alanı tanımlamamız gerekecek. Diskte sıraya girmek, IOP'lerin kapasitesi ve disk kapasitesi için risk eklediğinden, periyodik olarak tekrar gözden geçirmemiz ve yeniden incelememiz gereken bir şeydir.

Bir sonraki yazıda, bu projeyi üretime yerleştirdikten sonra gözlemlerimizin neler olduğundan ve bunu mümkün olduğunca üretim için kesintiye uğratmayacak şekilde yapan şeylerden bahsedeceğim.