ข้อแนะนำด้าน Cloud Security สำหรับปี 2021 ของคุณ

ข้อแนะนำด้าน Cloud Security สำหรับปี 2021 ของคุณ (ถ้าปี 2020 จะจบลงสักที)

ปี 2020 เรื่องทั้งหมดนั้นเพิ่งเกิดขึ้นจริง ๆ

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

ดังที่ Terry Pratchett นักเขียนผู้ยิ่งใหญ่เคยกล่าวไว้ว่า “ก่อไฟให้ใครสักคน เขาจะอบอุ่นได้หนึ่งวัน จุดไฟใส่ใครสักคน เขาจะอบอุ่นไปตลอดชีวิต” ปี 2021 คือเรื่องของการบริหารจัดการไฟเหล่านี้ให้เป็นเชื้อเพลิงของการเติบโต โดยไม่เผาบ้านตัวเองทิ้ง

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

เริ่มต้นด้วยการแก้ไข cloud governance

ในปี 2020 ผมทำงานร่วมกับองค์กรหลายสิบแห่งและพูดคุยกับอีกหลายร้อยแห่ง การกำกับดูแลที่อ่อนแอคือปัญหาที่พบได้สม่ำเสมอที่สุดบนคลาวด์อย่างไม่ต้องสงสัย ปัญหานี้ปรากฏในหลายรูปแบบ สิ่งที่ผมเห็นบ่อยที่สุดคือสองขั้วตรงข้าม ไม่องค์กรปล่อยให้นักพัฒนาทำอะไรก็ได้โดยไม่มีข้อจำกัดใด ๆ ก็ทีมความปลอดภัยล็อกทุกอย่างไว้กับรูปแบบมาตรฐานที่ไม่เหมาะกับคลาวด์ ผมแนะนำให้เดินทางสายกลาง กำหนดให้ผู้ให้บริการและบริการใหม่ทุกรายต้องผ่านการอนุมัติด้านความปลอดภัย และให้อำนาจทีมความปลอดภัยในการปฏิเสธได้ แต่ต้องอธิบายเหตุผลประกอบได้เท่านั้น จากนั้นกำหนดให้ทีมความปลอดภัยสร้างนโยบายและกระบวนการแบบ cloud-native ที่สะท้อนแนวปฏิบัติของคลาวด์จริง แทนที่จะยกเครื่องมือความปลอดภัยแบบดาต้าเซ็นเตอร์ที่ช้าและสวนทางกับประสิทธิภาพมาใช้ทั้งหมด ดึงทุกฝ่ายมานั่งโต๊ะเดียวกันใน Cloud Center of Excellence ความล้มเหลวด้านความปลอดภัยบนพับลิกคลาวด์ส่วนใหญ่ที่เราเห็น มีรากมาจากการกำกับดูแลที่ล้มเหลว ไม่ใช่เทคโนโลยีที่ล้มเหลว

เมื่อพูดถึงการกำกับดูแล นี่คือจังหวะที่ดีในการนำแนวคิด “security champion” มาใช้

Security champion ไม่ใช่ BISO (business information security officer) แต่คือนักพัฒนาหรือผู้ดูแลระบบในทีมโครงการที่ได้รับการอบรมเพิ่มเติมเล็กน้อย ได้พิซซ่าฟรี (สั่งเดลิเวอรีได้จนกว่ามาตรการกักตัวช่วง COVID จะสิ้นสุด) ระหว่างการประชุมคณะทำงาน และทำหน้าที่เป็นผู้ประสานงานระหว่างโครงการกับทีมความปลอดภัย มองพวกเขาเป็นทั้งจุดติดต่อและผู้สนับสนุนแนวทางด้านความปลอดภัย

ยกระดับการมองเห็นด้าน cloud security

อีกหนึ่งปัญหาการกำกับดูแลที่พบบ่อยคือการกันทีมความปลอดภัยออกจากบัญชีคลาวด์ โดยเปิดให้เข้าถึงเพียงบาง log เท่านั้น แก้ปัญหานี้ในปี 2021 ด้วยการให้ทีมความปลอดภัยมีเครื่องมือและสิทธิ์เข้าถึงแบบอ่านอย่างเดียวในทุกการใช้งานคลาวด์ (รวมถึงสภาพแวดล้อม dev/test/sandbox) พร้อมสิทธิ์อ่านและเขียนแบบ break glass สำหรับการตอบสนองต่อเหตุการณ์ ในทางกลับกัน ทีมความปลอดภัยต้องกำหนดนโยบายให้ตนเองลงมือเปลี่ยนแปลงฉุกเฉินเฉพาะในกรณีเลวร้ายที่สุดที่ติดต่อทีมผู้ดูแลระบบให้ดำเนินการ remediation ไม่ได้ การมองเห็นควรครอบคลุมทั้งสถานะการตั้งค่าที่เป็นปัจจุบันของระบบ (CSPM) และ feed ของ event และ log ที่สะท้อนการเปลี่ยนแปลงแบบเรียลไทม์ (CDR)

หากยังไม่ได้ใช้หลายบัญชีเพื่อจำกัดรัศมีความเสียหายจากการโจมตี ให้เริ่มตั้งแต่วันนี้

ผมไม่ได้หมายถึงแค่การแยก prod กับ non-prod แต่หมายถึงการใช้หลายบัญชีต่อหนึ่ง application stack เพราะเหตุใด เพราะ identity คือ perimeter ใหม่ และยิ่งคุณยัดทุกอย่างไว้ในสภาพแวดล้อมขนาดใหญ่ไม่กี่แห่ง การบังคับใช้การควบคุมแบบ least-privilege ก็ยิ่งยากขึ้น ยากจนแทบเป็นไปไม่ได้ ในปี 2021 คุณเริ่มได้ด้วยกฎ “ของใหม่ไปอยู่บัญชีใหม่” ผมยอมรับว่ากำลังซ่อนความซับซ้อนไว้พอสมควร โดยเฉพาะฝั่งเน็ตเวิร์กเมื่อคุณต้องเชื่อมต่อ app stack เข้าด้วยกัน แต่ปัญหาเหล่านั้นแก้ไขได้เมื่อคุณเริ่มใช้รูปแบบ cloud native และผลลัพธ์ที่ได้นั้นคุ้มค่าอย่างมหาศาล

ยกระดับการตอบสนองต่อเหตุการณ์แบบ cloud-native

ผมเห็นงาน IR ตามไม่ทันอยู่สองด้าน ด้านแรก รูปแบบการทำ logging ตามค่าเริ่มต้นในเอกสารของผู้ให้บริการคลาวด์มักไม่ใช่ทางเลือกที่ดีที่สุด เพราะมีความล่าช้ายาวนานระหว่างเวลาที่ event เกิดขึ้นกับเวลาที่การแจ้งเตือนปรากฏ เรื่องนี้เห็นได้ชัดที่สุดใน AWS แต่ผู้ให้บริการทุกรายก็เจอปัญหานี้เช่นกัน หากคุณพึ่งพาการเชื่อมต่อ SIEM แบบมาตรฐาน คุณอาจกำลังเปิดช่องเวลาให้ผู้โจมตีอย่างกว้างขวาง ด้านที่สอง กระบวนการตอบสนองเองก็ยังไม่ได้ถูกนิยามและวางเครื่องมือไว้อย่างเหมาะสม การตอบสนองด้วยมือต่อการโจมตีแบบอัตโนมัติคือเกมที่แพ้ตั้งแต่ต้น ในปี 2021 ให้ฝึกอบรมทีม IR ของคุณ ปรับการแจ้งเตือนที่อิงกับ event ให้เหมาะสม และเริ่มลดช่องเวลาการตอบสนองด้วยการกำหนดเส้นทางของ incident และระบบอัตโนมัติ และใช่ ผมกำลังแนะนำผลิตภัณฑ์ของตัวเอง แต่เราก็ไม่ได้สร้างมันขึ้นมาเล่น ๆ หากคุณยังไม่พร้อมสำหรับเครื่องมือเชิงพาณิชย์ คุณทำหลายอย่างเหล่านี้ได้เองด้วยโอเพนซอร์สและการเขียนโค้ด

ทบทวนการใช้งาน IAM/RBAC ตั้งแต่ต้นจนจบและรัดกุมให้มากขึ้น

ลดสิทธิ์ที่ไม่จำเป็นและเพิ่มการจำกัดระดับ resource ให้มากที่สุดเท่าที่ทำได้ เปิดใช้งานเครื่องมือวิเคราะห์และแจ้งเตือนที่เกี่ยวข้องกับ identity ทุกตัวที่ผู้ให้บริการคลาวด์ของคุณมีให้ เริ่มใช้ attribute และนโยบายแบบมีเงื่อนไข ลองดูให้ดี ความล้มเหลวด้านความปลอดภัยบนพับลิกคลาวด์ครั้งใหญ่ทุกกรณีในปี 2020 ล้วนเกี่ยวข้องกับความล้มเหลวของ IAM ไม่ว่าจะเป็นข้อมูลรับรองที่หลุด สิทธิ์ที่มากเกินไป หรือการไม่มี MFA และข้อจำกัดแบบมีเงื่อนไขเพื่อควบคุม IAM perimeter หากต้องมีเรื่องใดที่ทำให้คุณนอนไม่หลับในปี 2021 เรื่องนี้คือเรื่องนั้น

การกำกับดูแล บริการพื้นฐานที่ใช้ร่วมกัน และการอัปเกรดเชิงยุทธวิธีอีกไม่กี่อย่าง เราผ่านพ้นยุคที่คลาวด์คอมพิวติงดูเหมือนจะต้องการโปรแกรมและเครื่องมือใหม่ทั้งหมดในทุก ๆ ปีไปแล้ว ปี 2021 คือการทำพื้นฐานให้แน่น พร้อมยกระดับให้ขยายขนาดได้ดีขึ้น มีประสิทธิผลมากขึ้น และคุ้มค่าใช้จ่ายมากขึ้น วันนี้เรารู้ดีกว่าเมื่อไม่กี่ปีก่อนมากว่าแนวปฏิบัติใดได้ผลที่สุด และกุญแจสำคัญคือการมองหาโอกาสในการปรับให้ทันสมัย พร้อมตัดส่วนที่เป็น legacy ซึ่งใช้งานได้ไม่ดีจริง ๆ ออกไป