Yedeklemelerimizi Şifrelemek: Bu Bitiş Çizgisine Ulaşmak

Not: Bu mühendislik yazısı Veritabanı Yöneticimiz Silvia Botros tarafından yazılmıştır. Diğer DBA gönderilerinden bazılarına buradan göz atın.

Bir yıl önce SendGrid, SOC2 sertifikası için çok çalışıyordu. Herkes dahil oldu. Hepimiz üçüncü çeyreğin sonuna kadar sertifika almak istediğimizden, neredeyse her teslimat ekibi panosunda bir SOC2 etiketi olan hikayeler vardı. Tahmin edebileceğiniz gibi, veritabanlarından sorumlu kişi olarak, yığının bu kısmı için kesinlikle yapılacak bazı işler vardı.

Bu işletme çapındaki çaba için görev listemde, yedeklerimizin şifrelendiğinden emin olmak vardı. Aşina olduğum alan DBA araçları olduğundan ve Percona'nın xtrabackup'ının zaten şifreleme desteğine sahip olduğunu bildiğimden, bu görevde ilk girişim olarak buna gideceğim tahmin edilebilirdi.

Bu yaklaşımı test ederken gözümde birkaç önemli şey vardı:

• Açıkçası, yedeklemenin şifrelenmesi gerekiyordu
• Bilinmesi ve kabul edilebilir olması için gereken yedeklemeyi oluşturmaya yönelik ek yük
• Kurtarma zamanında yedeğin şifresini çözmeye yönelik ek yükün bilinmesi ve kabul edilebilir olması gerekiyordu.

Bu, öncelikle yedeklemelerimin ne kadar sürdüğünü takip edebilmem gerektiği anlamına geliyordu.

Yedekleme süresini izleme

SendGrid, altyapı metrikleri için Graphite kullanır ve büyük çoğunluğu Sensu aracılığıyla gönderilirken, Graphite, metrikleri doğrudan bash satırları yoluyla göndermek için yeterince kolaydır - yedekleme komut dosyaları bash içinde olduğundan çok uygundur. Graphite'te doğrudan ölçüm göndermenin süper ölçeklenebilir olmadığını unutmayın, ancak bu yedeklemeler saatte en fazla bir kez çalıştığından, bu benim ihtiyaçlarım için iyi oldu.

Bu kısmın nispeten kolay olduğu ortaya çıktı.

Bu son satırda ne olduğunu açıklamak için Graphite'e gönderdiğim metriğin yolunu (benzersiz olduğundan emin olun), metrik değerini, ardından şimdiki zamanı epoch formatında gönderiyorum. Netcat'i sadelik için kullanmaya karar verdim ve 1 saniyelik bir zaman aşımı süresi veriyorum çünkü aksi halde asla çıkmayacak. "Grafit url", veri merkezindeki Graphite için DNS uç noktamızdır.

Artık karşılaştıracak bir temelim olduğuna göre, şifreleme yöntemlerini test etmeye hazırdık.

Bunun nasıl yapılacağına dair Percona'nın ayrıntılı belgelerini takiben, bir anahtar yaparak başladım. Bu dokümantasyon sayfasını dikkatlice okursanız, bir şeyler fark edebilirsiniz.

Bu anahtar, doğrudan yedekleme aracına iletilmelidir ve anlık görüntünün şifresini çözebilen aynı anahtardır. Buna simetrik şifreleme denir ve aynı anahtarın doğası gereği her iki yönde de asimetrik şifrelemeden daha az güvenlidir. Sadeliğin bunu hala geçerli bir yaklaşım yapıp yapmadığını görmek için test etmeye devam etmeye karar verdim.

Birkaç yüz MB'lık çok küçük DB'lerle yapılan testler başarılı oldu. Araç beklendiği ve belgelendiği gibi çalışıyor, ancak bu daha çok işlevsel bir testti ve asıl soru "daha büyük DB'lerimizde şifreleme cezasının boyutu nedir?" idi. SendGrid'deki daha eski örnekler 1-2 TB'den tek bir 18 TB canavara kadar büyümüştü. Küçük örnekler için kullanacağım şeyin daha büyük olanlar için de operasyonel olarak kabul edilebilir olması gerekiyordu.

Test ve kıyaslamaların ilgi çekici hale geldiği yer burasıdır.

Oldukça büyük boyuttaki ilk test nesnem, diskte 1 TB olan bir veritabanımız. Çok hızlı bir şekilde beklenmedik bir sorunla karşılaştım. Minimum şifreleme ayarlarıyla (1 iş parçacığı, varsayılan yığın boyutları), yedeklemelerin şu hatayla başarısız olduğunu gördüm:

O zamanlar, bu veritabanları işlem günlüğü dosyası boyutu olarak 512 MB kullanıyordu ve bu oldukça yoğun bir küme olduğundan, bu dosyalar neredeyse her dakika dönüyordu. Normalde bu, DB performansında fark edilirdi, ancak çoğunlukla katı hal sürücülerinin harikası tarafından maskelendi. Görünüşe göre herhangi bir paralel şifreleme dizisi ayarlamıyor (okuyun: birini kullanın), '.ibd' dosyalarını şifrelemek için o kadar çok zaman harcıyoruz ki, innodb redo log ruloları altımızdan yedekleme kesintisi yapıyor.

Öyleyse, bunu bir dizi şifreleme iş parçacığıyla tekrar deneyelim. İlk deneme olarak 50 thread ile denedim. Buradaki hile, CPU ile rekabet etmeden hızlı şifrelemenin tatlı noktasını bulmaktır. Ayrıca 'ib_logfiles' boyutunun her birini 1 GB'a çıkardım.

Bu, bir gecede demlenmesine izin verdiğim için mutlu olduğum daha başarılı bir testti. İlk birkaç gece her şey yolunda görünüyordu. Çok fazla büyümeyen bir yedekleme yapmanın zamanı gelmişti ancak yedekleme işlemi sırasında kutu yük ortalaması kesinlikle eklenen adımları gösteriyordu.

Ancak, geri yüklemeleri test etmeye başladığımda, şifreleme ekledikten sonra aynı yedeklerin geri yükleme işleminin 60 dakikadan 280 dakikaya çıktığını gördüm; bu, felaket durumunda söz verdiğimiz kurtarma süremize ciddi bir ceza anlamına geliyordu.

Bunu daha makul bir zaman dilimine geri getirmemiz gerekiyordu.

Takım çalışmasının ve sorunlara daha basit çözümlerin parladığı yer burasıdır. InfoSec ekip üyelerimizden biri, bu çözümün basitleştirilip basitleştirilemeyeceğini görmeye karar verdi. Bu yüzden biraz daha test yaptı ve daha basit ve daha güvenli bir şeyle geri döndü. Henüz gpg2'yi öğrenmemiştim ve bu benim için de bir öğrenme alıştırması oldu.

gpg2 ile ilgili iyi olan şey, asimetrik şifrelemeyi desteklemesidir. Özel ve genel bölümlerin olduğu bir anahtar çifti oluşturuyoruz. Genel kısım, gpg2'yi beslemeye karar verdiğiniz herhangi bir akışı veya dosyayı şifrelemek için kullanılır ve özel sır, şifresini çözmek için kullanılabilir.

Buna damıtılmış şifreleme eklemek için yedekleme komut dosyalarımızdaki değişiklik. Bunun okunmasını kolaylaştırmak için bazı argümanlar kaldırılmıştır:

Diğer taraftan, bir yedeği geri yüklerken, ana bilgisayarın anahtarlığında kabul edilebilir bir gizli anahtarın olduğundan emin olmamız ve ardından şu komutu kullanmamız yeterlidir:

Ben de gpg2'de yeni olduğum için bu benim için bir öğrenme fırsatı oldu. Harika InfoSec ekip üyemiz Colin, gpg2 kullanarak yedeklemeleri ve geri yüklemeleri test etmeye devam etti, ta ki gpg2 kullanmanın xtrabackup'ın yerleşik sıkıştırmasını kullanmanın aşağıdakiler dahil birçok avantajı olduğunu onaylayana kadar:

• asimetrikti
• Şifre çözme için gizli yönetimi nispeten kolay bir şekilde döndürülür (daha fazlası aşağıdadır)
• Bu, araçtan bağımsızdır, yani xtrabackup kullanmayan diğer herhangi bir yedekleme türü aynı yöntemi kullanabilir
• Şifre çözmede birden fazla çekirdek kullanıyordu, bu da bize daha iyi geri yükleme süreleri sağladı.

Her zaman iyileştirme için yer

Hala iyileştirilebilecek bir yer olduğunu gördüğüm yerlerden biri, bu dosyaların şifresini çözebilecek sırrı nasıl ele aldığımız. Şu anda, kurumsal parola yönetimi çözümümüzde bunlara sahibiz, ancak oradan almak, ardından yedeklemeleri test etmek için kullanmak manuel bir işlemdir. Planımızdaki bir sonraki adım, Vault by Hashicorp'u uygulamak ve bunu sorunsuz bir şekilde ve belirlenmiş ana bilgisayarlarda, şifre çözme için gizli anahtarı çekmek ve ardından otomatik testler için kolayca erişilebilir ve hala korunacak şekilde yerel halkadan çıkarmaktır.

Sonuç olarak, tüm veritabanı yedeklerimizi, yedekleme performansından veya olağanüstü durum kurtarma SLA'sından ödün vermeden zamanında SOC2 ihtiyaçlarımıza uyacak şekilde aldık. InfoSec ekibimizle bu görev üzerinde çalışırken çok eğlendim ve yeni araçlar öğrenerek çıktım. Ayrıca, en basit çözümün kişinin görevine en uygun çözüm olması her zaman güzeldir.