Cloud Security Alliance แนะวิธีการป้องกันความเสี่ยงจากเทคโนโลยี Serverless

เทคโนโลยี Serverless ถือเป็นสิ่งที่อำนวยความสะดวกให้แก่การพัฒนาแอปพลิเคชันมากมาย อย่างไรก็ดีหลายท่านอาจไม่ได้\ตระหนักถึงความเสี่ยงต่างๆที่ตามมา ด้วยเหตุนี้เอง Cloud Security Alliance จึงได้ออกรายงานแนะนำที่ชี้ให้เหล่า CISO และ CIO เห็นว่าประโยชน์และความท้าทายเป็นอย่างไร พร้อมแนวทางการป้องกันเพื่อลดความเสี่ยง โดยทีมงาน TechTalkthai ได้สรุปรายงานไว้ให้ในบทความนี้ครับ

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

1.) รวดเร็ว ความรวดเร็วนี้เกิดขึ้นกับทุกส่วนของการพัฒนาโปรแกรมจากการที่นักพัฒนาไม่จำเป็นต้องสร้าง Infrastructure เอง แต่ Serverless ทำให้ท่านสามารถมองข้ามเรื่อง Hardware ไปได้อย่างแท้จริง ชิ้นงานก็ออกสู่การใช้จริงได้เร็วเข้าแข่งขันกับตลาดได้ การใช้งานก็ทำผ่าน API จากบทผู้ใช้องค์กรอาจผันตัวเป็นผู้สร้าง API ต่อยอดทางธุรกิจอย่างเฉพาะทาง แถมการออก Release ก็เป็นเรื่องทำได้บ่อยขึ้น

2.) ตอบโจทย์ด้านนวัตกรรม เพราะทำให้จัดสรรค์ปันส่วนระบบออกเป็นระบบย่อยได้ (Modular) ทำให้เกิดระบบระเบียบความคล่องตัว และการใช้ซ้ำ

3.) ลดต้นทุนเพราะการลูกค้าสามารถจ่ายตามการใช้งานจริงๆที่เกิดขึ้นราย Transaction จะเพิ่มหรือลดก็ได้ 

4.) เกิดความเป็นอัติโนมัติ ในมุมของการปฏิบัติการจะทำให้การ Provision และการเชื่อมต่อกับ Third party หรืองานที่ไม่เกิดขึ้นบ่อยเป็นไปได้อัตโนมัติ เช่น การสำรองข้อมูลเป็นต้น อีกมุมหนึ่งในด้านความมั่นคงปลอดภัย Serverless ช่วยลดการพึ่งพาคนจึงลดข้อผิดพลาด เกิดการทำงานเป็นช่วงเวลาอย่างสม่ำเสมอ อีกทั้งการลื่นไหลข้อมูลอย่างเป็นระบบก็ทำให้ติดตามพฤติกรรมและแก้ปัญหาแอปทำได้ง่ายขึ้น

ก่อนที่จะเข้าสู่เนื้อหาด้วยความมั่นคงปลอดภัยเรื่องสำคัญที่ทุกท่านต้องทราบก็คือ Serverless ได้เปลี่ยนภาพของโมเดลความรับผิดชอบ (Shared Responsibility Model) โดยผู้ให้บริการ Serverless มีหน้าที่ต้องบริหารจัดการ ฮาร์ดแวร์ ซอฟต์แวร์ Runtime และแพตช์ อีกด้านผู้ใช้งานต้องพิจารณาเรื่องการจัดการตัวตนและการเข้าถึงข้อมูลที่ถูกใช้งานและแอปพลิเคชันเอง ต่างไปจากเดิมที่ต้องลงลึกถึงเรื่องฮาร์ดแวร์และซอฟต์แวร์ต่างๆ

หากพูดถึง 3 แกนหลักของความมั่นคงปลอดภัยอย่าง Confidentiality(C), Integrity(I) และ Availability (A) รายงานฉบับนี้ได้แนะนำให้ท่านกระทำดังนี้ 1.) ปฏิบัติตามหลัการ Least Privilege 2.) ลดผิวหน้าการโจมตีให้เหลือน้อยที่สุดเช่น ฟังก์ชันก็จะเผยแค่ HTTPS หรือ API เท่านั้นไม่มีอะไรนอกจากนี้ 3.) ออกแบบและบังคับใช้การป้องกันเป็นหลายระดับ (Defense in Depth) 4.) เข้ารหัสทุกอย่างเป็นค่าพื้นฐาน

อย่างไรก็ดีแม้แนวทางปฏิบัติจะชัดเจนแต่สิ่งที่ไม่หยิ่งหย่อนไปกว่ากันคือการทำให้ CISO และ CIO อยู่ในวงของรายงานความมั่นคงปลอดภัยของ Serverless โดยทั้งสองไม่ควรเกี่ยงความรับผิดชอบที่เพราะต้องมีส่วนผลักดันให้เกิด Policy ที่ช่วยป้องกันภัยคุกคาม

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

• ช่วงเวลาที่เจ้าของแอปเริ่มตั้งค่า Infrastructure ที่จะใช้โฮสต์แอป
• การ Deploy แอปว่าเป็นอย่างไร
• บริการและ Infrastructure ของแอปเป็นอย่างไร อันที่จริงแล้ว Serverless มีคุณสมบัติด้านความมั่นคงปลอดภัยอยู่แล้วบ้างนั่นคือเรื่องความเป็น Stateless, การประมวลผลที่เกิดขึ้นชั่วคราว ข้อมูลที่ได้รับเป็นส่วนๆ และในบางครั้งทำให้การแพตช์เป็นเรื่องง่าย

ความท้าทายของบริการ Serveless 

1. การใช้งานต้องวิ่งผ่านระบบสาธารณะ สามารถแก้ไขได้ด้วยการใช้งานผ่าน Virtual Private Cloud (VPC) หรือจำกัดการเข้าถึงจาก Endpoint อย่างรัดกุม
2. ระบบเก็บ Log และติดตาม ต้องมีรูปแบบข้อมูล Log ที่เป็นระบบนำไปใช้ต่อได้ง่าย องค์กรยังต้องทราบถึง API ทั้งหมดเพื่อติดตามให้ได้และมีกระบวนการค้นหาและตอบสนองที่แพลตฟอร์มหากเกิดการละเมิด Policy รวมถึงต้องรวบ Log และการมอนิเตอร์สู่การรวมศูนย์ให้ได้
3. ขั้นตอนการคอนฟิค ต้องมีการตรวจสอบความมั่นคงปลอดภัยที่มีก่อนขึ้นระบบใช้จริงและ พึ่งพาค่าพื้นฐานให้น้อย
4. แนวทางการเก็บค่า Secret ให้ตรวจสอบดูว่าผู้ให้บริการมีทางเลือกใด หากไม่มีการป้องกันท่านต้องมีการเข้ารหัสระดับแอปเอง กรณีที่แอปมีความละเอียดอ่อนมาท่านสามารถใช้ VM ประเภท Confidential Compute Instance 
5. การบริหารจัดการ 3rd party ท่านต้องวิเคราะห์ว่ามีการใช้งานไลบรารีอะไรบ้าง หรือหาโซลูชันที่ช่วยค้นหาไลบรารีตอน Runtime ซึ่งถ้ามีไลบรารีที่ไม่ได้ใช้ก็ลบออกซะ

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

การทำ Identity และ Access management ที่พิจารณาจากบริบท (Context) เป็นเรื่องจำเป็นอย่างยิ่งเพราะอาจมีการสืบทอดอำนาจของฟังก์ชันต่อไปยังฟังก์ชันหรือบริการอื่นได้ เช่นเดียวกับการบริหารจัดการ API ของแพลตฟอร์มและความสามารถตรวจจับพฤติกรรมที่แพลตฟอร์มสามารถทำได้ก็สำคัญไม่ยิ่งหย่อนไปกว่ากัน

สำหรับผู้สนใจท่านสามารถติดตามรายงานฉบับเต็มได้ที่ https://cloudsecurityalliance.org/artifacts/c-level-guidance-to-securing-serverless-architectures/