4 เฟสสู่การทำ Cloud Management ให้เป็นอัตโนมัติ

เส้นทางสู่ cloud automation ของผู้เชี่ยวชาญด้านความปลอดภัย

หากคุณเจอผมในงานสัมมนา คุณมีโอกาสสูงที่จะได้ยินผมพูดว่า “ความปลอดภัยบนคลาวด์เริ่มต้นที่สถาปัตยกรรม และจบลงที่ระบบอัตโนมัติ” และผมมักพูดต่อทันทีว่าการปรับมุมมองแบบ cloud native นั้นสำคัญเพียงใด แม้ในวันที่คุณยังจมอยู่กับงาน lift and shift ที่ไม่สวยงามนัก ก่อนสัญญาศูนย์ข้อมูลจะหมดอายุและต้องปิดไฟลาจากกันไป ประโยคนี้ฟังดูคมคาย แต่ก็ไม่ได้อธิบายเลยว่าผมเปลี่ยนจากคนทำงานความปลอดภัยสายพื้นฐาน (firewall และ patch management) มาเป็นสาย cloud native ที่เน้นสถาปัตยกรรมและระบบอัตโนมัติได้อย่างไร แทนที่จะเทศนาจากบนภูเขา ผมคิดว่าการเล่าเส้นทางส่วนตัวและสิ่งที่ผมค้นพบในเชิงเทคนิคระหว่างทางน่าจะมีประโยชน์มากกว่า หากคุณทำงานด้านความปลอดภัย หรือกำลังพยายามยกระดับทักษะคลาวด์ให้ทีมความปลอดภัย มีแนวโน้มสูงว่าคุณจะเดินมาบนเส้นทางที่คล้ายกันมาก

เฟสที่ 1: การทำ configuration ให้เป็นอัตโนมัติ

สำหรับผม ทุกอย่างเริ่มขึ้นเมื่อราวเก้าปีก่อน ตอนที่ผมได้รับมอบหมายให้สร้างหลักสูตรฝึกอบรมหลักสูตรแรกให้กับ Cloud Security Alliance ตั้งแต่ช่วงต้นผมก็รู้ว่าเราต้องมีแล็บที่ทำซ้ำได้ รันได้ทุกที่ทั่วโลก โดยที่ทั้งผู้เรียนและผู้สอนมีทักษะหลากหลายตั้งแต่ระดับ “นักพัฒนา” ไปจนถึง “ผู้ตรวจสอบที่ทำงานกับเอกสารเป็นหลัก” ในยุคนั้น Amazon Web Services ยังไม่ได้เปิดตัว IAM อย่างจริงจัง และ VPC ยังเป็นเครือข่ายส่วนตัวเท่านั้น ส่วนแนวคิดอย่าง Infrastructure as Code ก็เพิ่งจะเริ่มเป็นไปได้

ผมจึงต้องหาวิธีสร้างแล็บ application stack แบบลงมือปฏิบัติจริงบนคลาวด์สำหรับผู้เรียนหลายพันคน ให้ได้ผลสม่ำเสมอ *และ* อัปเดตได้ตามที่ AWS พัฒนาเทคโนโลยีไปเรื่อย ๆ ตอนนั้นการสร้าง AMI ของตัวเองยังเป็นงานที่ยุ่งยาก แต่แล้วผมก็ได้รู้จักความมหัศจรรย์ของ `cloud-init` สคริปต์ง่าย ๆ ที่ผมโฮสต์ไว้ใน S3 bucket พร้อมโค้ดสองบรรทัดสั้น ๆ ที่ผู้เรียนวางลงในฟิลด์ User Data ของอินสแตนซ์ แล้วอินสแตนซ์นั้นก็จะถูกตั้งค่าตามที่ต้องการทันทีตอนเปิดใช้งาน และเมื่อการอัปเดตซอฟต์แวร์ทำให้บางอย่างพัง ผมเพียงแก้สคริปต์ที่ URL ที่เผยแพร่ไว้ แล้วอินสแตนซ์ใหม่ทุกตัวก็จะใช้การตั้งค่าใหม่ทันที - น่าทึ่งมาก แม้วิธีนี้จะไม่ช่วยเรื่องการแพตช์ระบบที่กำลังทำงานอยู่ แต่ก็ช่วยให้ผมรักษาประสบการณ์การใช้งานครั้งแรกที่ดีไว้ได้ ง่ายกว่าการอัปเดตและเผยแพร่ AMI ใหม่มาก และด้วยความไม่ยั้งคิดต่อชื่อเสียงของตัวเอง คุณยังสามารถดูเวอร์ชันหลังจากนั้นได้ที่นี่บน S3

ก้าวแรกของผมคือ `cloud-init` ทุกวันนี้ผมไม่ได้ใช้มันแล้ว แต่มันเปิดตาผมว่าผมสามารถเขียนสคริปต์คุมเซิร์ฟเวอร์ทั้งเครื่องและให้ทุกอย่างทำงานได้ ด้วยการคัดลอกวางและไฟล์ที่โฮสต์ไว้เพียงไฟล์เดียว

เฟสที่ 2: การทำ workflow ให้เป็นอัตโนมัติ

แต่ก้าวถัดมาส่งผลกระทบมากกว่ามาก หลังจากจัดอบรมเชิงปฏิบัติการและสร้าง workload ของตัวเองอยู่สองสามปี ผมเริ่มลองเล่นกับแนวคิด Software Defined Security ตรงหน้าผมคือ cloud API มากมายที่คอยกระซิบว่า “เรียกใช้ฉันสิ” ผมเริ่มมองหาตัวอย่าง แล้วก็พบว่า… ไม่มีเลย แม้แต่ Security Monkey ก็ยังไม่ถูกเผยแพร่สู่สาธารณะ

ผมมีคลาสที่ต้องสอนในงานสัมมนาความปลอดภัย Black Hat และตัดสินใจใช้โอกาสนี้เป็นข้ออ้างในการเรียน Ruby และ AWS API (ผ่าน Ruby SDK) สุดท้ายผมเขียนเดโมออกมาสามตัว:

• แอปพลิเคชันตอบสนองเหตุการณ์ที่กักกันอินสแตนซ์ วิเคราะห์ metadata ทั้งหมด ล็อกดาวน์ด้วย AWS IAM ทำอิมเมจของสตอเรจทั้งหมด และเปิดเซิร์ฟเวอร์วิเคราะห์ทางนิติวิทยาศาสตร์ที่พร้อมตรวจสอบ snapshot ที่แนบมา งานที่เคยใช้เวลา 30 นาที เหลือเพียง 3 วินาที
• แอปเล็ก ๆ ที่เชื่อมต่อกับ AWS และ Chef เพื่อระบุอินสแตนซ์ทั้งหมดที่ไม่ได้รัน Chef (เซิร์ฟเวอร์ที่ ‘ไม่ได้บริหารจัดการ’) กระบวนการที่อาจใช้เวลาหลายสัปดาห์ในศูนย์ข้อมูลแบบดั้งเดิม
• อีกแอปหนึ่งที่เปิด security group ให้กับเครื่องสแกน Qualys สั่งเริ่มการสแกน แล้วปิด security group เมื่อสแกนเสร็จ

ผมไม่เคยเขียน Ruby มาก่อน ทั้งสามตัวจึงใช้เวลาราวสองเดือนแบบทำงานนอกเวลาจึงจะใช้งานได้ ทุกอย่างค่อนข้างเรียบง่าย แต่ผมได้บทเรียนที่มีค่าหลายข้อ

• การจัดการ credential เป็นเรื่องสำคัญอย่างยิ่ง และยังทำให้การแชร์โค้ดและให้คนอื่นตั้งค่าสภาพแวดล้อมของตนอย่างถูกต้องยากขึ้นด้วย การดึงค่าจากไฟล์ configuration นั้น… น่ารำคาญ โดยเฉพาะเรื่องอย่างการเลือกว่าจะใช้ security group ใดในภูมิภาคใดเป็นกลุ่มสำหรับกักกัน
• Ruby บนเครื่องผมทำงานได้ดี แต่พอรันโค้ดในอินสแตนซ์บน AWS ผมกลับชน service limit จนต้องใส่ตัวหน่วงเวลาเข้าไป API service limit ไม่ใช่เพื่อนของคุณ
• ทั้งหมดนี้ยังเป็นงานแบบ static ต่อให้ดูดีแค่ไหนในการสาธิต สุดท้ายก็ยังต้องรันโค้ดด้วยมือจากเดสก์ท็อปหรืออินสแตนซ์อยู่ดี ซึ่งไม่ได้อยู่ยงคงกระพันนัก

ผมรวมทั้งหมดนี้ไว้ในชื่อ “SecuritySquirrel” และคุณสามารถดูเวอร์ชันปี 2014 ได้บน GitHub เชื่อหรือไม่ว่านั่นยังไม่ใช่เวอร์ชันดั้งเดิมที่ผมใช้มาสองสามปีก่อนจะเผยแพร่ด้วยซ้ำ

เฟสที่ 3: การทำให้คลาวด์เองเป็นอัตโนมัติ

เมื่อ AWS ปล่อย Rules สำหรับ CloudWatch ผมใช้เวลาเช้าวันเสาร์ถัดมาราว 2 ชั่วโมงเขียนโค้ด Python ให้พอใช้งานได้ เพื่อย้อนกลับการเปลี่ยนแปลง security group ใด ๆ ภายใน 10-15 วินาที รวมถึงตัวกรองเพื่อกำหนดขอบเขตการป้องกันตาม tag, VPC หรือผู้ที่ร้องขอการเปลี่ยนแปลง คุณสามารถดาวน์โหลดโค้ดและคำแนะนำได้ และต่างจากโค้ด Ruby ของผม โค้ดชุดนี้ยังทำงานได้ดีพอสมควรสำหรับโค้ดคลาวด์อายุ 3 ปี

นับจากการสาธิตครั้งแรกนั้น ผมได้สร้างคลังระบบอัตโนมัติแบบ event-driven ที่รันบน Lambda ซึ่งบางส่วนคุณสามารถดาวน์โหลดได้ ในชุดนั้นตัวโปรดของผมคือ `identify_internet_facing_servers.py` ซึ่งเพื่อการสาธิต ผมเชื่อมให้มันทำงานเมื่อกดปุ่ม Amazon Dash เวอร์ชัน IoT ใช่แล้วครับ ผมพกปุ่ม Easy จริง ๆ ไว้ในกระเป๋า มันจะค้นหาอินสแตนซ์ใด ๆ ที่เปิดพอร์ต 22 สู่อินเทอร์เน็ต และเพียงกดปุ่มสองครั้ง ผมก็เพิกถอนกฎเหล่านั้นได้ พร้อมรับข้อความแจ้งเตือนบนมือถือเมื่อทุกอย่างเรียบร้อยปลอดภัย

บทเรียนสำคัญของผมตรงนี้เป็นสิ่งที่ไม่ได้คาดคิด ไม่ใช่ว่าระบบอัตโนมัติแบบ event-driven เหล่านี้มาแทนที่ workflow บนโฮสต์ของผม แต่มันทำหน้าที่คนละอย่าง ผมตระหนักว่าตัวเองได้ก้าวจากการสร้าง workflow เพื่อให้ทำงานได้เร็วขึ้น ไปสู่การสร้าง guardrail เพื่อรักษาความปลอดภัยอยู่เบื้องหลัง ทั้งสองอย่างล้วนมีคุณค่ามหาศาล

เฟสที่ 4: การทำทุกอย่างให้เป็นอัตโนมัติ

งานล่าสุดของผมคือการใช้ Jenkins และ Infrastructure as Code (ส่วนใหญ่เป็น CloudFormation) เพื่อยกระดับความปลอดภัย การผสานสองสิ่งนี้ทำให้ผมฝังความปลอดภัยแบบอัตโนมัติลงในโครงสร้างพื้นฐานและตัวแอปพลิเคชันเอง และพึ่งพาเครื่องมือภายนอกน้อยลง

ตัวอย่างเช่น ผมปล่อยเครื่องมือสแกน credential อย่างง่ายให้รันใน Jenkins เพื่อค้นหา access key ที่ถูกเก็บไว้ก่อนจะเริ่ม build ด้วยซ้ำ จะรอไปค้นหาทีหลังทำไม จากนั้นผมเขียน test harness อื่น ๆ เพื่อให้รันเครื่องมือประเมินใดก็ได้ที่ต้องการใน Jenkins และทำให้ build ล้มเหลวเมื่อไม่ผ่านการทดสอบด้านความปลอดภัย เช่น การสแกนเครือข่าย (เคล็ดลับ: Jenkins จะถือว่า build ล้มเหลวหากคุณส่ง exit code ใด ๆ ที่ไม่ใช่ 0 จากสคริปต์)

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

เส้นทางคลาวด์ของผมเริ่มขึ้นเมื่อราวเก้าปีก่อน และเส้นทางด้านระบบอัตโนมัติก็เริ่มในเวลาไล่เลี่ยกัน ผมเริ่มจากการสร้างสิ่งต่าง ๆ แล้วค่อยพยายามทำบางส่วนให้เป็นอัตโนมัติ แต่ทุกวันนี้ผมเริ่มต้นด้วยสมมติฐานว่าทุกอย่างต้องเป็นอัตโนมัติ งานยุคแรกของผมเกี่ยวกับการปฏิบัติการ แต่ทุกวันนี้แทบทั้งหมดมุ่งไปที่ความปลอดภัย มุ่งลดภาระงานปฏิบัติการให้หมดไป เพื่อให้สมองส่วนที่คิดเรื่องความปลอดภัยได้โฟกัสกับสิ่งที่มันถนัดที่สุด ระหว่างทางผมยังได้เรียนรู้ว่าระบบอัตโนมัติไม่ได้เท่าเทียมกันทั้งหมด มีที่ทางสำหรับ guardrail, workflow, การ orchestrate ข้ามแพลตฟอร์ม, infrastructure as code และการทำ pipeline ให้เป็นอัตโนมัติ ทั้งหมดนี้ให้ประโยชน์ด้านความปลอดภัยที่แทบจินตนาการไม่ถึง แต่เรายังอยู่ในช่วงเริ่มต้นมาก ช่วงที่คุณอาจเสียเวลาทั้งสัปดาห์ไปกับการแกะ API ที่มีเอกสารประกอบแย่ ๆ

หากคุณทำงานด้านความปลอดภัย ถึงเวลายกระดับทักษะการเขียนโค้ดแล้ว หากคุณเป็นนักพัฒนาหรือทีมปฏิบัติการ ก็ถึงเวลายกระดับทักษะด้านความปลอดภัย เพราะบทเรียนที่ใหญ่ที่สุดคือ ยุคที่ความปลอดภัยเป็นเพียงร่มคลุมได้สิ้นสุดลงแล้ว และยุคที่ความปลอดภัยถักทออยู่ในเนื้อผ้าได้มาถึงแล้ว