Avoid the Schrödinger Backup (หลีกเลี่ยง Backup แบบ Schrödinger)

เมื่อ สร้าง backup คุณควรหลีกเลี่ยงสิ่งที่ผมเรียกว่า Schrödinger backup 9 นี่คือ backup ที่อาจจะเป็นหรือไม่เป็น backup จริงๆ ก็ได้ จนกว่าคุณจะลอง restore มันจริงๆ คุณจะไม่มีทางรู้เลยว่ามันเป็น backup ที่ใช้งานได้จริง 10 หรือมันเป็นแค่กลุ่มของเลข 1 กับ 0 ที่เขียนลงดิสก์เฉยๆ วิธีที่ดีที่สุดในการหลีกเลี่ยงปัญหานี้คือการมั่นใจว่า backup นั้นเป็นของจริงด้วยการ restore มันจริงๆ หาวิธีสร้างการ restore backup แบบสม่ำเสมอเข้าไปเป็นส่วนหนึ่งของกระบวนการพัฒนาซอฟต์แวร์ของคุณ—ตัวอย่างเช่น การใช้ production backup มาสร้างข้อมูลทดสอบ performance ของคุณ

คำแนะนำ “แบบเก่า” เกี่ยวกับ backup คือควรเก็บไว้นอกสถานที่ (off-site) โดยแนวคิดคือเหตุการณ์ไม่พึงประสงค์ที่ออฟฟิศหรือ data center ของคุณจะไม่กระทบ backup ของคุณ ถ้าพวกมันอยู่ที่อื่น แต่ “off-site” หมายความว่าอะไรกันแน่ ถ้าแอปพลิเคชันของคุณ deploy อยู่บน public cloud? สิ่งที่สำคัญคือ backup ของคุณถูกเก็บในลักษณะที่แยกออกจากระบบหลักของคุณให้มากที่สุดเท่าที่จะเป็นไปได้ เพื่อให้การถูกโจมตีในระบบหลักไม่ทำให้ backup ของคุณตกอยู่ในความเสี่ยงด้วย Code Spaces ที่เรากล่าวถึงก่อนหน้านี้ มี backup อยู่—แต่ถูกเก็บไว้บน AWS ในบัญชีเดียวกับที่ถูกโจมตี ถ้าแอปพลิเคชันของคุณรันอยู่บน AWS คุณก็ยังสามารถเก็บ backup ของคุณไว้ที่นั่นได้เช่นกัน แต่คุณควรทำมันในบัญชีที่แยกออกไปบน cloud resource ที่แยกออกไป—คุณอาจต้องการพิจารณาเก็บมันไว้ใน cloud region ที่แตกต่างกันไปเลยด้วยซ้ำ เพื่อลดความเสี่ยงจากปัญหาระดับภูมิภาค หรือคุณอาจเก็บมันไว้กับผู้ให้บริการรายอื่นเลยก็ได้

ดังนั้นอย่าลืมสำรองข้อมูลสำคัญของคุณ เก็บ backup เหล่านั้นไว้ในระบบที่แยกออกจากสภาพแวดล้อม production หลักของคุณ และมั่นใจว่า backup นั้นใช้งานได้จริงด้วยการ restore มันเป็นประจำ

Rebuild (การสร้างใหม่)

เรา สามารถพยายามอย่างเต็มที่เพื่อป้องกันไม่ให้ฝ่ายไม่หวังดีเข้าถึงระบบของเราได้ แต่จะเกิดอะไรขึ้นถ้าพวกเขาทำได้จริง? บ่อยครั้งสิ่งสำคัญที่สุดที่คุณทำได้ในช่วงแรกหลังเกิดเหตุคือการทำให้ระบบกลับมาทำงานได้อีกครั้ง แต่ในลักษณะที่คุณได้ตัดการเข้าถึงของฝ่ายที่ไม่ได้รับอนุญาตออกไปแล้ว แต่นี่ไม่ใช่เรื่องที่ตรงไปตรงมาเสมอไป ผมจำได้ว่าเครื่องหนึ่งของเราเคยถูกแฮ็กด้วย rootkit เมื่อหลายปีก่อน rootkit คือชุดซอฟต์แวร์ที่ถูกออกแบบมาเพื่อซ่อนกิจกรรมของฝ่ายที่ไม่ได้รับอนุญาต และเป็นเทคนิคที่ผู้โจมตีมักใช้เพื่อไม่ให้ถูกตรวจพบ ทำให้พวกเขามีเวลาสำรวจระบบ ในกรณีของเรา เราพบว่า rootkit ได้เปลี่ยนแปลงคำสั่งหลักของระบบ เช่น ls (แสดงรายการไฟล์) หรือ ps (แสดงรายการ process ) เพื่อซ่อนร่องรอยของผู้โจมตีจากภายนอก เราสังเกตเห็นสิ่งนี้ได้ก็ต่อเมื่อเราสามารถตรวจสอบ hash ของโปรแกรมที่รันอยู่บนเครื่องเทียบกับ package อย่างเป็นทางการเท่านั้น ในท้ายที่สุดเราต้องติดตั้งเซิร์ฟเวอร์ทั้งเครื่องใหม่ตั้งแต่ต้น

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

ความสามารถในการ rebuild microservice ใดหนึ่ง หรือแม้แต่ทั้งระบบ ขึ้นอยู่กับคุณภาพของ automation และ backup ของคุณ ถ้าคุณสามารถ deploy และ configure แต่ละ microservice ขึ้นมาใหม่จากศูนย์ โดยอิงจากข้อมูลที่เก็บไว้ใน source control ได้ คุณก็เริ่มต้นได้ดีแล้ว แน่นอนว่าคุณต้องรวมสิ่งนี้เข้ากับกระบวนการ restore backup ที่แข็งแกร่งสำหรับข้อมูลด้วย เช่นเดียวกับ backup วิธีที่ดีที่สุดในการมั่นใจว่าการ deploy และ configure microservice ของคุณแบบอัตโนมัติทำงานได้จริง คือการทำมันบ่อยๆ—และวิธีที่ง่ายที่สุดในการทำแบบนั้นคือใช้กระบวนการเดียวกันสำหรับการ rebuild microservice เหมือนกับที่คุณใช้สำหรับทุกๆ การ deploy นี่คือวิธีที่กระบวนการ deploy แบบ container-based ส่วนใหญ่ทำงาน คุณ deploy container ชุดใหม่ที่รันเวอร์ชันใหม่ของ microservice ของคุณ และปิด container ชุดเก่าลง การทำให้สิ่งนี้กลายเป็นขั้นตอนปฏิบัติงานปกติทำให้การ rebuild แทบจะกลายเป็นเรื่องไม่มีอะไรพิเศษเลย

มีข้อควรระวังอยู่ข้อหนึ่งที่นี่ โดยเฉพาะถ้าคุณกำลัง deploy บน container platform อย่าง Kubernetes คุณอาจกำลังลบและ redeploy container instance บ่อยๆ แต่แล้ว container platform ที่อยู่เบื้องหลังล่ะ? คุณมีความสามารถในการ rebuild มันจากศูนย์หรือไม่? ถ้าคุณใช้ managed Kubernetes provider แบบเต็มรูปแบบ การสร้าง cluster ใหม่ก็อาจไม่ยากนัก แต่ถ้าคุณติดตั้งและจัดการ cluster ด้วยตัวเอง นี่อาจเป็นงานจำนวนมากที่ไม่ธรรมดาเลย

Tip

ความสามารถในการ rebuild microservice ของคุณและกู้คืนข้อมูลของมันแบบอัตโนมัติ ช่วยให้คุณกู้คืนได้หลังเกิดการโจมตี และยังมีข้อดีที่ทำให้การ deploy ของคุณง่ายขึ้นในทุกด้าน ซึ่งส่งผลดีต่อกิจกรรมด้าน development, test และ production operations