เจาะลึก Inventory แบบเรียลไทม์

ในช่วงแรกของ FireMon (ที่จริงคือก่อนที่เราจะมาเป็น FireMon) เราพบว่าการพยายามประเมินบัญชีคลาวด์ของลูกค้าแบบสดๆ (รวมถึง subscription/project) นั้น... เป็นปัญหา การรันการประเมินจำนวนมากขนาดนั้นจะชน service limit อย่างรวดเร็ว และอาจรบกวนการเรียก API ภายในของลูกค้าได้ โปรดทราบว่าเราเริ่มทำสิ่งนี้เมื่อประมาณ 7 ปีที่แล้ว ก่อนที่ CSPM จะเกิดขึ้นเสียอีก และทุกคนต่างก็กำลังเรียนรู้บทเรียนเดียวกัน

แนวทางแรกที่เราคิดขึ้นคือการเก็บข้อมูล configuration เพียงครั้งเดียว นำเข้าสู่ inventory ของเราเอง แล้วจึงทำการประเมินที่นั่น วิธีนี้ทำให้เราลดการเรียก API ลงเหลือเพียงเท่าที่จำเป็นต่อการดึง metadata จากนั้นเราจึงรันการประเมินได้หลายรายการบนชุดข้อมูลเดียวกัน แนวทางนี้ใช้ได้ดีอยู่ระยะหนึ่ง เรายังคงสแกน configuration ตามรอบเวลา แต่สามารถกระจายรอบการสแกนได้สม่ำเสมอยิ่งขึ้น และปรับให้การเรียก API ไม่หนาแน่นเกินไป อย่างไรก็ตาม แนวทางนี้ก็มีปัญหาในตัวเอง จะเกิดอะไรขึ้นหากมีการเปลี่ยนแปลงในช่วงระหว่างการสแกนกับเวลาที่มีคนเข้ามาจัดการ alert นั้นจริงๆ นอกจากนี้ การกวาดข้อมูลทั้งบริการของ AWS เพื่อดึงทรัพยากรทั้งหมดในบริการนั้น ก็ยังคงเบียดกับ API limit ซึ่งกำหนดตามบริการและภูมิภาค

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

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

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

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

วิธีที่ดีที่สุดในการสัมผัสประสบการณ์นี้คือชมวิดีโอแนะนำความยาว 90 วินาทีของเรา และนี่คือภาพหน้าจอสำคัญบางส่วน:

หน้าหลัก แสดงข้อมูลสำคัญจำนวนมากในมุมมองเดียว:

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

มุมมอง History นี้ติดตามการเปลี่ยนแปลงตามลำดับเวลา พร้อมกราฟแสดงแนวโน้มกิจกรรม คลิกที่ไทม์ไลน์เพื่อข้ามไปยังวันที่นั้น:

คุณเคยต้องการทราบหรือไม่ว่าทรัพยากรคลาวด์ชั่วคราวตัวใดเป็นเจ้าของ IP address ที่ปรากฏใน log ณ เวลาหนึ่งๆ ทีม incident response ชอบฟีเจอร์นี้มาก...

ทั้งหมดนี้คือภาพรวมโดยย่อ ในบทความต่อๆ ไป เราจะเจาะลึกเรื่องสถาปัตยกรรมและวิธีที่เรารองรับสิ่งนี้ในสภาพแวดล้อมแบบ multi-cloud