การเข้ารหัสข้อมูลสำรองของเรา: ไปให้ถึงเส้นชัย

หมายเหตุ: โพสต์ทางวิศวกรรมนี้เขียนโดย Silvia Botros ผู้ดูแลฐานข้อมูลของเรา ตรวจสอบโพสต์ DBA อื่น ๆ ของเธอที่นี่

ปีที่แล้ว SendGrid ทำงานอย่างหนักเพื่อการรับรอง SOC2 ทุกคนมีส่วนร่วม มีเรื่องราวในบอร์ดทีมจัดส่งเกือบทุกแห่งที่มีแท็ก SOC2 เนื่องจากเราทุกคนต้องการได้รับการรับรองภายในสิ้นไตรมาสที่สาม อย่างที่คุณสามารถจินตนาการได้ ในฐานะที่เป็นผู้รับผิดชอบฐานข้อมูล มีงานบางอย่างที่ต้องทำสำหรับส่วนนั้นของสแต็กอย่างแน่นอน

ในรายการงานของฉันสำหรับความพยายามทั่วทั้งธุรกิจนี้คือการทำให้แน่ใจว่าข้อมูลสำรองของเราได้รับการเข้ารหัส เนื่องจากความคุ้นเคยของฉันคือเครื่องมือ DBA และรู้ว่า xtrabackup ของ Percona รองรับการเข้ารหัสอยู่แล้ว คาดเดาได้เลยว่าฉันจะลองใช้วิธีนี้ในครั้งแรกที่งานนี้

สิ่งสำคัญสองสามอย่างอยู่ในสายตาของฉันในการทดสอบแนวทางนี้:

• เห็นได้ชัดว่าการสำรองข้อมูลจำเป็นต้องได้รับการเข้ารหัส
• ค่าใช้จ่ายในการสร้างข้อมูลสำรองจำเป็นต้องเป็นที่รู้จักและยอมรับได้
• ค่าโสหุ้ยในการถอดรหัสข้อมูลสำรองในเวลากู้คืนจำเป็นต้องรู้และยอมรับได้

นั่นหมายความว่าก่อนอื่น ฉันต้องสามารถติดตามว่าการสำรองข้อมูลของฉันใช้เวลานานเท่าใด

ติดตามเวลาสำรอง

SendGrid ใช้ Graphite สำหรับตัวชี้วัดโครงสร้างพื้นฐาน และในขณะที่ส่วนใหญ่ส่งผ่าน Sensu แต่ Graphite นั้นง่ายพอที่จะส่งตัวชี้วัดโดยตรงผ่าน bash Line ซึ่งสะดวกมากเนื่องจากสคริปต์สำรองอยู่ใน bash โปรดทราบว่าการส่งตัววัดที่ Graphite โดยตรงนั้นไม่สามารถปรับขนาดได้อย่างมาก แต่เนื่องจากการสำรองข้อมูลเหล่านี้ทำงานมากที่สุดหนึ่งชั่วโมงต่อชั่วโมง นั่นก็ใช้ได้ดีสำหรับความต้องการของฉัน

ส่วนนั้นกลับกลายเป็นว่าค่อนข้างง่าย

เพื่ออธิบายว่าเกิดอะไรขึ้นในบรรทัดสุดท้ายนั้น ฉันส่งเส้นทางของตัววัดที่ฉันกำลังส่งให้แกรไฟต์ (ตรวจสอบให้แน่ใจว่าไม่ซ้ำกัน) ค่าตัวชี้วัด จากนั้นเวลาปัจจุบันในรูปแบบยุค Netcat คือสิ่งที่ฉันตัดสินใจใช้เพื่อความเรียบง่าย และฉันให้เวลามัน 1 วินาที เพราะไม่เช่นนั้น มันจะไม่มีวันจบสิ้น `graphite url' คือจุดสิ้นสุด DNS ของเราสำหรับ Graphite ในศูนย์ข้อมูล

ตอนนี้ฉันมีข้อมูลพื้นฐานเปรียบเทียบแล้ว เราก็พร้อมที่จะเริ่มทดสอบวิธีการเข้ารหัสแล้ว

ตามเอกสารโดยละเอียดจาก Percona เกี่ยวกับวิธีการทำเช่นนี้ ฉันเริ่มต้นด้วยการสร้างคีย์ หากคุณอ่านหน้าเอกสารนั้นอย่างละเอียด คุณอาจเข้าใจบางอย่าง

คีย์นี้จะถูกส่งต่อไปยังเครื่องมือสำรองข้อมูลโดยตรง และเป็นคีย์เดียวกันกับที่สามารถถอดรหัสสแน็ปช็อตได้ นั่นเรียกว่าการเข้ารหัสแบบสมมาตร และโดยธรรมชาติของคีย์เดียวกันนั้นในทั้งสองทิศทาง มีความปลอดภัยน้อยกว่าการเข้ารหัสแบบอสมมาตร ฉันตัดสินใจทำการทดสอบต่อไปเพื่อดูว่าความเรียบง่ายยังคงทำให้แนวทางนี้เป็นไปได้หรือไม่

การทดสอบกับฐานข้อมูลขนาดเล็กมาก ไม่กี่ร้อย MB ประสบความสำเร็จ เครื่องมือทำงานตามที่คาดไว้และได้รับการจัดทำเป็นเอกสาร แต่นั่นเป็นการทดสอบการใช้งานมากกว่า และคำถามที่แท้จริงก็คือ “การลงโทษการเข้ารหัสในฐานข้อมูลขนาดใหญ่ของเรามีขนาดเท่าใด” อินสแตนซ์รุ่นเก่าที่ SendGrid มีขนาดเพิ่มขึ้นจาก 1-2 TB เป็นสัตว์ร้าย 18 TB ตัวเดียว สิ่งที่ฉันจะใช้สำหรับอินสแตนซ์ขนาดเล็กจะต้องเป็นที่ยอมรับในการปฏิบัติงานสำหรับอินสแตนซ์ขนาดใหญ่ด้วย

นี่คือจุดที่การทดสอบและการเปรียบเทียบมีความน่าสนใจ

หัวข้อทดสอบแรกของฉันที่มีขนาดพอสมควรคือฐานข้อมูลที่เรามีซึ่งมีขนาด 1 TB บนดิสก์ ฉันพบปัญหาที่ไม่คาดคิดอย่างรวดเร็วมาก ด้วยการตั้งค่าการเข้ารหัสขั้นต่ำ (1 เธรด ขนาดก้อนเริ่มต้น) ฉันเห็นว่าการสำรองข้อมูลล้มเหลวโดยมีข้อผิดพลาดนี้:

ในขณะนั้น ฐานข้อมูลเหล่านี้ใช้ 512MB เป็นขนาดไฟล์บันทึกธุรกรรม และนี่เป็นคลัสเตอร์ที่ค่อนข้างยุ่ง ดังนั้นไฟล์เหล่านั้นจึงหมุนเวียนเกือบทุกนาที โดยปกติ สิ่งนี้จะสังเกตเห็นได้ชัดเจนในประสิทธิภาพของ DB แต่ส่วนใหญ่ถูกปิดบังด้วยความมหัศจรรย์ของไดรฟ์โซลิดสเตต ดูเหมือนว่าไม่ได้ตั้งค่าเธรดการเข้ารหัสแบบขนานใด ๆ (อ่าน: ใช้หนึ่งอัน) หมายความว่าเราใช้เวลามากในการเข้ารหัสไฟล์ `.ibd` ที่ innodb ทำซ้ำบันทึกม้วนจากภายใต้เรากำลังทำให้ตัวแบ่งสำรอง

ลองทำใหม่อีกครั้งด้วยเธรดการเข้ารหัสจำนวนหนึ่ง ในครั้งแรกที่ฉันลองกับ 50 เธรด เคล็ดลับที่นี่คือการค้นหาจุดที่น่าสนใจของการเข้ารหัสที่รวดเร็วโดยไม่ต้องแข่งขันกับ CPU ฉันยังเพิ่มขนาดของ `ib_logfiles` เป็น 1 GB ต่อไฟล์

นี่เป็นการทดสอบที่ประสบความสำเร็จมากกว่าที่ฉันยินดีที่จะปล่อยให้ชงในชั่วข้ามคืน ในช่วงสองสามคืนแรก สิ่งต่างๆ ดูเหมือนจะดี ถึงเวลาแล้วที่จะทำการสำรองข้อมูลที่ไม่เติบโตมากเกินไป แต่กล่องโหลดเฉลี่ยระหว่างกระบวนการสำรองข้อมูลนั้นแสดงขั้นตอนที่เพิ่มเข้ามาอย่างแน่นอน

อย่างไรก็ตาม เมื่อฉันเปลี่ยนไปใช้การทดสอบการคืนค่า ฉันพบว่ากระบวนการกู้คืนของข้อมูลสำรองเดียวกัน หลังจากเพิ่มการเข้ารหัส ได้เพิ่มขึ้นจาก 60 เป็น 280 นาที ซึ่งหมายความว่าเป็นการลงโทษอย่างร้ายแรงต่อเวลาการกู้คืนที่สัญญาไว้ของเราในกรณีที่เกิดภัยพิบัติ

เราจำเป็นต้องนำสิ่งนั้นกลับไปสู่กรอบเวลาที่เหมาะสมยิ่งขึ้น

นี่คือจุดที่การทำงานเป็นทีมและแนวทางแก้ไขปัญหาที่ง่ายขึ้น หนึ่งในสมาชิกทีม InfoSec ของเราตัดสินใจว่าจะลดความซับซ้อนของโซลูชันนี้ได้หรือไม่ ดังนั้นเขาจึงทำการทดสอบเพิ่มเติมและกลับมาพร้อมกับสิ่งที่ง่ายกว่าและปลอดภัยกว่า ฉันยังไม่เคยเรียนรู้เกี่ยวกับ gpg2 มาก่อน ดังนั้นสิ่งนี้จึงกลายเป็นแบบฝึกหัดการเรียนรู้สำหรับฉันเช่นกัน

ข้อดีของ gpg2 คือรองรับการเข้ารหัสแบบอสมมาตร เราสร้างคู่คีย์ที่มีส่วนส่วนตัวและส่วนสาธารณะ ส่วนสาธารณะใช้เพื่อเข้ารหัสสตรีมหรือไฟล์ใดๆ ที่คุณตัดสินใจป้อน gpg2 และสามารถใช้ความลับส่วนตัวเพื่อถอดรหัสได้

การเปลี่ยนแปลงสคริปต์สำรองของเราเพื่อเพิ่มการเข้ารหัสที่กลั่นกรองสิ่งนี้ อาร์กิวเมนต์บางข้อจะถูกลบออกเพื่อให้อ่านง่ายขึ้น:

ในอีกด้านหนึ่ง เมื่อกู้คืนข้อมูลสำรอง เราเพียงแค่ต้องตรวจสอบให้แน่ใจว่ารหัสลับที่ยอมรับได้นั้นอยู่ในพวงกุญแจของโฮสต์ จากนั้นใช้คำสั่งนี้:

เนื่องจากฉันเพิ่งเริ่มใช้ gpg2 เช่นกัน นี่เป็นโอกาสการเรียนรู้สำหรับฉัน Colin สมาชิกทีม InfoSec ที่ยอดเยี่ยมของเรา ยังคงทดสอบการสำรองข้อมูลและกู้คืนโดยใช้ gpg2 ต่อไป จนกว่าเขาจะยืนยันว่าการใช้ gpg2 มีข้อดีหลายประการในการใช้การบีบอัดในตัวของ xtrabackup ได้แก่:

• มันไม่สมมาตร
• การจัดการความลับสำหรับการถอดรหัสนั้นค่อนข้างง่าย (เพิ่มเติมเกี่ยวกับสิ่งนี้ด้านล่าง)
• เป็นเครื่องมือไม่เชื่อเรื่องพระเจ้าซึ่งหมายความว่าการสำรองข้อมูลประเภทอื่นที่ไม่ได้ใช้ xtrabackup สามารถใช้วิธีการเดียวกันได้
• มันใช้หลายคอร์ในการถอดรหัสซึ่งทำให้เรากู้คืนเวลาได้ดีขึ้น

พื้นที่สำหรับการปรับปรุงเสมอ

ที่แห่งหนึ่งที่ฉันยังคงมองเห็นช่องว่างสำหรับการปรับปรุงคือวิธีที่เราจัดการกับความลับที่สามารถถอดรหัสไฟล์เหล่านี้ได้ ในขณะนี้ เรามีพวกเขาในโซลูชันการจัดการรหัสผ่านสำหรับองค์กรของเรา แต่การได้รับจากที่นั่น จากนั้นจึงใช้เพื่อทดสอบการสำรองข้อมูลเป็นกระบวนการที่ต้องทำด้วยตนเอง ต่อไปในแผนของเราคือการนำ Vault โดย Hashicorp มาใช้และใช้งานได้อย่างราบรื่น และบนโฮสต์ที่กำหนด ให้ดึงคีย์ลับเพื่อถอดรหัส จากนั้นนำออกจากวงแหวนในเครื่องเพื่อให้พร้อมสำหรับการทดสอบอัตโนมัติและยังคงได้รับการปกป้องอย่างง่ายดาย

ในที่สุด เราได้รับการสำรองข้อมูลฐานข้อมูลทั้งหมดของเราเพื่อให้สอดคล้องกับความต้องการ SOC2 ของเราในเวลาโดยไม่สูญเสียประสิทธิภาพการสำรองข้อมูลหรือ SLA การกู้คืนจากความเสียหาย ฉันสนุกมากที่ได้ทำงานมอบหมายนี้กับทีม InfoSec ของเรา และได้เรียนรู้เครื่องมือใหม่ๆ นอกจากนี้ มันจะดีเสมอเมื่อวิธีแก้ปัญหาที่ง่ายที่สุดกลายเป็นวิธีที่เหมาะสมที่สุดสำหรับงานของตัวเอง