Mengenkripsi Cadangan Kami: Mencapai Garis Finish itu

Catatan: Posting teknik ini ditulis oleh Administrator Basis Data kami, Silvia Botros. Lihat beberapa posting DBA lainnya di sini.

Setahun yang lalu, SendGrid bekerja keras menuju sertifikasi SOC2. Semua orang terlibat. Ada cerita di hampir setiap papan tim pengiriman dengan tag SOC2 karena kami semua ingin disertifikasi pada akhir kuartal ketiga. Seperti yang dapat Anda bayangkan, sebagai penanggung jawab database, pasti ada beberapa pekerjaan yang harus dilakukan untuk bagian tumpukan itu.

Dalam daftar tugas saya untuk upaya bisnis ini adalah memastikan bahwa cadangan kami dienkripsi. Karena bidang keakraban saya adalah alat DBA dan mengetahui bahwa xtrabackup Percona sudah memiliki dukungan untuk enkripsi, dapat diprediksi bahwa saya akan melakukannya sebagai upaya pertama dalam tugas ini.

Beberapa hal penting yang saya lihat dalam menguji pendekatan ini:

• Jelas, cadangan perlu dienkripsi
• Overhead untuk membuat cadangan perlu diketahui dan dapat diterima
• Overhead untuk mendekripsi cadangan pada waktu pemulihan perlu diketahui dan dapat diterima

Itu berarti pertama-tama, saya harus dapat melacak berapa lama waktu yang diperlukan untuk pencadangan saya.

Melacak waktu cadangan

SendGrid menggunakan Graphite untuk metrik infrastrukturnya dan sementara sebagian besar dikirim melalui Sensu, Graphite cukup mudah untuk mengirim metrik secara langsung melalui bash lines–sangat nyaman karena skrip cadangan ada di bash. Perhatikan bahwa mengirim metrik di Graphite secara langsung tidak dapat diskalakan, tetapi karena pencadangan ini berjalan paling banyak sekali dalam satu jam, itu baik-baik saja untuk kebutuhan saya.

Bagian itu ternyata relatif mudah.

Untuk menjelaskan apa yang terjadi di baris terakhir itu, saya mengirim Graphite jalur metrik yang saya kirim (pastikan itu unik), nilai metrik, lalu waktu saat ini dalam format epoch. Netcat adalah apa yang saya putuskan untuk digunakan untuk kesederhanaan, dan saya memberikan batas waktu 1 detik karena, jika tidak, itu tidak akan pernah keluar. `graphite url` adalah titik akhir DNS kami untuk Graphite di pusat data.

Sekarang setelah saya memiliki dasar untuk dibandingkan, kami siap untuk mulai menguji metode enkripsi.

Mengikuti dokumentasi terperinci dari Percona tentang cara melakukan ini, saya memulai dengan membuat kunci. Jika Anda membaca halaman dokumentasi itu dengan cermat, Anda mungkin menyadari sesuatu.

Kunci ini akan diteruskan ke alat pencadangan secara langsung, dan merupakan kunci yang sama yang dapat mendekripsi snapshot. Itu disebut enkripsi simetris dan, pada dasarnya kunci yang sama di kedua arah, kurang aman daripada enkripsi asimetris. Saya memutuskan untuk melanjutkan pengujian untuk melihat apakah kesederhanaan masih menjadikan ini pendekatan yang layak.

Pengujian dengan DB yang sangat kecil, beberapa ratus MB, berhasil. Alat ini berfungsi seperti yang diharapkan dan didokumentasikan, tetapi itu lebih merupakan tes fungsional dan pertanyaan sebenarnya adalah "berapa ukuran penalti enkripsi pada DB kami yang lebih besar?" Instans lama yang lebih banyak di SendGrid telah berkembang menjadi ukuran dari 1-2 TB menjadi monster 18 TB tunggal. Apa yang akan saya gunakan untuk instance kecil juga harus dapat diterima secara operasional pada instance yang lebih besar.

Di sinilah pengujian dan benchmark menjadi menarik

Subjek pengujian pertama saya dengan ukuran yang cukup besar adalah database yang kami miliki yaitu 1 TB pada disk. Sangat cepat saya mengalami masalah yang tidak terduga. Dengan pengaturan enkripsi minimal (1 utas, ukuran potongan default), saya melihat pencadangan gagal dengan kesalahan ini:

Pada saat itu, database ini menggunakan 512MB sebagai ukuran file log transaksi, dan ini adalah cluster yang cukup sibuk, sehingga file-file itu berputar hampir setiap menit. Biasanya, ini akan terlihat dalam kinerja DB, tetapi sebagian besar ditutupi oleh keajaiban solid state drive. Sepertinya tidak menyetel utas enkripsi paralel (baca: gunakan satu) berarti kami menghabiskan begitu banyak waktu untuk mengenkripsi file `.ibd` sehingga innodb redo log roll dari bawah kami membuat cadangan istirahat.

Jadi, mari kita coba lagi dengan sejumlah utas enkripsi. Sebagai upaya pertama, saya mencoba dengan 50 utas. Triknya di sini adalah menemukan sweet spot enkripsi cepat tanpa bersaing dengan CPU. Saya juga meningkatkan ukuran `ib_logfiles` masing-masing menjadi 1 GB.

Ini adalah tes yang lebih sukses yang dengan senang hati saya biarkan diseduh dalam semalam. Untuk beberapa malam pertama, segalanya tampak baik-baik saja. Sudah waktunya untuk membuat cadangan yang tidak tumbuh terlalu banyak, tetapi rata-rata beban kotak selama proses pencadangan pasti menunjukkan langkah-langkah tambahan.

Namun, ketika saya beralih ke pengujian pemulihan, saya menemukan bahwa proses pemulihan dari cadangan yang sama, setelah menambahkan enkripsi, telah meningkat dari 60 menjadi 280 menit – yang berarti hukuman berat untuk waktu pemulihan yang kami janjikan jika terjadi bencana.

Kami perlu mengembalikannya ke jangka waktu yang lebih masuk akal.

Di sinilah kerja tim dan solusi sederhana untuk masalah bersinar. Salah satu anggota tim InfoSec kami memutuskan untuk melihat apakah solusi ini dapat disederhanakan. Jadi dia melakukan beberapa pengujian lagi dan kembali dengan sesuatu yang lebih sederhana dan lebih aman. Saya belum belajar tentang gpg2 dan jadi ini menjadi latihan pembelajaran bagi saya juga.

Hal yang baik tentang gpg2 adalah mendukung enkripsi asimetris. Kami membuat pasangan kunci di mana ada bagian pribadi dan publik. Bagian publik digunakan untuk mengenkripsi aliran atau file apa pun yang Anda putuskan untuk diberi makan gpg2 dan rahasia pribadi dapat digunakan untuk mendekripsi.

Perubahan pada skrip cadangan kami untuk menambahkan enkripsi yang disaring untuk ini. Beberapa argumen dihapus untuk membuatnya lebih mudah dibaca:

Di sisi lain, saat memulihkan cadangan, kita hanya perlu memastikan kunci rahasia yang dapat diterima ada di gantungan kunci host dan kemudian gunakan perintah ini:

Karena saya juga baru mengenal gpg2, ini menjadi kesempatan belajar bagi saya. Colin, anggota tim InfoSec kami yang luar biasa, terus menguji pencadangan dan pemulihan menggunakan gpg2 sampai dia memastikan bahwa menggunakan gpg2 memiliki banyak keuntungan menggunakan kompresi bawaan xtrabackup termasuk:

• Itu asimetris
• Manajemen rahasianya untuk dekripsi relatif mudah diputar (lebih lanjut tentang ini di bawah)
• Ini adalah alat agnostik, yang berarti semua jenis cadangan lain yang tidak menggunakan xtrabackup dapat menggunakan metode yang sama
• Itu menggunakan banyak inti pada dekripsi yang memberi kami waktu pemulihan yang lebih baik

Selalu ada ruang untuk perbaikan

Satu tempat di mana saya masih melihat ruang untuk perbaikan adalah bagaimana kami menangani rahasia yang dapat mendekripsi file-file ini. Saat ini, kami memilikinya dalam solusi manajemen kata sandi perusahaan kami, tetapi mendapatkannya dari sana, kemudian menggunakannya untuk menguji cadangan adalah proses manual. Selanjutnya dalam rencana kami adalah mengimplementasikan Vault oleh Hashicorp dan menggunakannya untuk secara mulus, dan pada host yang ditunjuk, menarik kunci rahasia untuk dekripsi, lalu menghapusnya dari ring lokal sehingga mudah tersedia untuk pengujian otomatis dan tetap terlindungi.

Pada akhirnya, kami mendapatkan semua cadangan basis data kami untuk memenuhi kebutuhan SOC2 kami tepat waktu tanpa mengorbankan kinerja pencadangan atau SLA pemulihan bencana. Saya sangat senang mengerjakan tugas ini dengan tim InfoSec kami dan dari situ saya mempelajari alat-alat baru. Plus, selalu menyenangkan ketika solusi paling sederhana akhirnya menjadi yang paling cocok untuk tugas seseorang.