ยกระดับ Grand Unified Theory of Cloud Governance

เมื่อปีกว่า ๆ ที่ผ่านมา ผมได้เขียนเรื่องGrand Unified Theory of Cloud Governance เอาไว้ เป็นแนวคิดที่ผมลองขบคิดมาราว 5 ถึง 6 ปี เพื่อสรุปให้เห็นต้นตอของปัญหาที่ทำให้องค์กรปรับตัวเข้าสู่คลาวด์ได้ยาก ชื่อเรื่องอาจฟังดูอหังการไปบ้าง แต่ผมเคยเป็นนักวิเคราะห์ของ Gartner มาก่อน ก็คงต้องขออภัย

เช่นเดียวกับทฤษฎีที่ดี (ซึ่งผมหวังว่าจะเป็นเช่นนั้น) ผมพัฒนามันอย่างต่อเนื่องตามประสบการณ์การทำงานกับองค์กรที่มากขึ้นและการพูดคุยกับผู้คนที่หลากหลายขึ้น ในช่วงสองสามปีที่ผ่านมาผมหยิบทฤษฎีนี้มาใช้บ่อยมากทั้งในการบรรยายและการฝึกอบรม โดยเฉพาะเมื่อผมถูกดึงเข้าไปอยู่ในโจทย์ด้าน governance มากขึ้นเรื่อย ๆ และครั้งแล้วครั้งเล่า ปัญหาใหญ่ที่ผมเจอไม่ใช่เรื่องเทคนิค แต่เป็นเรื่องขององค์กร ใช่ ความซับซ้อนเชิงเทคนิคของความปลอดภัยบนคลาวด์นั้นมีมากมายมหาศาล และมันนำไปสู่การรั่วไหลของข้อมูลได้จริง แต่จากประสบการณ์ของผม ปัญหาด้าน governance มีน้ำหนักมากกว่าปัญหาเชิงเทคนิคอย่างเทียบกันไม่ติด

governance ที่ดีไม่สามารถแพตช์ zero day ได้ แต่ governance ที่แย่ทำให้ผู้โจมตีไม่จำเป็นต้องใช้ zero day เลย

แก่นของทฤษฎีนี้แทบไม่เปลี่ยนไป ผมเพียงพยายามหาวิธีอธิบายให้ดีขึ้นเรื่อย ๆ และตัดสินใจตัดทอนให้กระชับลงเล็กน้อย ปัจจุบันผมนำเสนอบนสไลด์แบบนี้

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

เมื่อย้อนกลับไปดูเวอร์ชันก่อนหน้า สิ่งที่เปลี่ยนไปนั้นดูเล็กน้อย แต่ก็สำคัญมาก

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

ผมยังคงใช้คำว่า “ไม่มีจุดบีบคอขวดและไม่มีผู้เฝ้าประตู” ในการบรรยายอยู่ แต่ผมพบว่ามันก็คือวิธีพูดที่ยาวกว่าของคำว่า “กระจายศูนย์” นั่นเอง ประเด็นพื้นฐานคือการควบคุมสแตกทั้งหมดอย่างเป็นอิสระนอกเหนือโครงสร้างพื้นฐานแบบรวมศูนย์ ทีมพัฒนาหรือทีมแอปสามารถสร้างและบริหารโครงสร้างพื้นฐานของตนเองในสภาพแวดล้อมของตนเองได้ด้วยบัตรเครดิตเพียงใบเดียว แน่นอนว่ายังคงมีการพึ่งพาและการควบคุมอยู่บ้าง โดยเฉพาะในระดับ data plane หรือเมื่อต้องเชื่อมต่อกลับเข้าสู่เครือข่าย แต่นั่นก็ไม่ได้เปลี่ยนประเด็นหลักแต่อย่างใด

การพยายามรวมศูนย์กลับมาทั้งหมดนั้นแทบไม่เคยได้ผล

ต่อมา ผมแทบไม่ได้เปลี่ยนเรื่องการรวมอินเทอร์เฟซการบริหารจัดการไว้ด้วยกันเลย ขยายความได้ว่า เรากระจายศูนย์โครงสร้างพื้นฐานและการควบคุมทั้งหมดในระดับการ deploy แต่ทุกคนทั่วโลกกลับใช้เว็บคอนโซลและ API endpoint ชุดเดียวกัน

ผู้โจมตีมีประตูเพียงบานเดียวสู่เป้าหมายที่ไม่มีที่สิ้นสุด

จากนั้นผมนำหัวข้อย่อยจากเวอร์ชันแรกขึ้นมาเป็นข้อที่ 3 พอร์ทัลผู้ดูแลระบบเหล่านี้ล้วนอยู่บนอินเทอร์เน็ต และโดยค่าเริ่มต้นก็แทบไม่มีอะไรมากไปกว่าชื่อผู้ใช้และรหัสผ่าน ทรัพยากรทั้งหมดก็ห่างจากการถูกเปิดสู่อินเทอร์เน็ตเพียงแค่การตั้งค่าเดียว ลองถาม S3 bucket และคลัสเตอร์ ElasticSearch ทั้งหลายดูก็ได้

มันง่ายแค่นั้นจริง ๆ แต่ละทีมบริหารจัดการสิ่งของตนเองอย่างอิสระ ทุกทีมทั่วโลกใช้เว็บพอร์ทัลและ API endpoint ชุดเดียวกัน และใครก็ตามที่มีข้อมูลรับรองที่ถูกต้องก็สามารถเข้าไปลองผิดลองถูกกับเบื้องหลัง “ดาต้าเซ็นเตอร์” ของคุณได้

ส่วนที่น่าทึ่งคือ ทั้งหมดนี้ถูกอธิบายไว้ตั้งแต่ปี 2011 ในNIST 800-145 ซึ่งเป็นเอกสาร 2 หน้าชื่อ NIST Definition of Cloud Computing โดยเอกสารนั้นนิยามคุณลักษณะสำคัญ 5 ประการของคลาวด์คอมพิวติงไว้ดังนี้

• On-demand Self Service
• Broad Network Access
• Resource Pooling
• Rapid Elasticity
• Measured Service

หากหยิบสามข้อแรกมาพิจารณา เราจะได้ว่า

• แต่ละทีมบริหารจัดการสิ่งของตนเอง
• ทุกอย่างอยู่บนอินเทอร์เน็ต
• และทั้งหมดตั้งอยู่บนพูลทรัพยากรร่วมกัน

เอาล่ะ แล้วทั้งหมดนี้หมายความว่าอย่างไร และเราควรทำอย่างไร

ยอมรับความจริงข้อนี้

นั่นคือก้าวแรก ทำความเข้าใจปัญหาและใช้มันเป็นเลนส์ในการออกแบบทางแก้ ดังที่ผมเพิ่งเขียนไว้ในบทความเรื่อง Strong Authorizationว่า

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

เริ่มจากตรงนั้น ยอมรับความเป็นจริงพื้นฐานเสียก่อน แล้วเราจะทำอะไรได้บ้างเพื่อลดความเสี่ยงนั้น เพื่อลดการโจมตีเหล่านั้น ผมคิดว่าทางเลือกที่ส่งผลมากที่สุดคือการมุ่งไปที่ IAM และจุดบรรจบระหว่าง governance กับ IAM ใครเป็นผู้บริหารจัดการสิทธิ์ ใครดูแลการเข้าถึง มีมาตรการควบคุมด้านความปลอดภัยใดบ้างที่ป้องกัน ตรวจจับ และแก้ไขการโจมตีที่เกี่ยวข้องกับ IAM ได้ กระบวนการของคุณรอบ ๆ IAM เป็นอย่างไร ทีมตอบสนองต่อเหตุการณ์ของคุณเข้าใจรายละเอียดเชิงลึกของ IAM ของผู้ให้บริการคลาวด์ที่คุณใช้หรือไม่ คุณใช้ JIT/Strong Authorization หรือไม่ คุณบริหารจัดการ IAM สำหรับผู้รับเหมาและบริการภายนอกอย่างไร

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