The Grand Unified Theory of Cloud Governance

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

เพราะเส้นทางที่นำไปสู่ความล้มเหลวเร็วที่สุดคือการกำกับดูแลคลาวด์แบบเดียวกับการกำกับดูแล IT ที่ไม่ใช่คลาวด์

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

ข้อดีอย่างหนึ่งของบทบาทนักวิจัยและที่ปรึกษาคือการได้เห็นเบื้องหลังขององค์กรที่หลากหลายในขณะที่พวกเขาจัดการกับประเด็นเหล่านี้ และผมได้เห็นทั้งความสำเร็จและความล้มเหลว เมื่อเวลาผ่านไป รูปแบบบางอย่างก็ปรากฏขึ้น และในเรื่องการกำกับดูแล ผมเห็นแนวคิดไม่กี่ข้อที่ดูจะร้อยเรียงทุกอย่างเข้าด้วยกัน ผมเรียกสิ่งนี้ว่า The Grand Unified Theory of Cloud Governance:

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

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

• การกำกับดูแล IT แบบเดิมเป็นผลลัพธ์ตามธรรมชาติของความขาดแคลน อันเกิดจากการทำงานภายในสถานที่ทางกายภาพ เราจึงพัฒนาทีมแยกส่วนขึ้นมาเพื่อดูแลเทคโนโลยีที่ซับซ้อนและแตกต่างกัน เช่น เครือข่าย เซิร์ฟเวอร์ และความปลอดภัยในแง่มุมต่าง ๆ
  • ข้อจำกัดทางกายภาพและทรัพยากรที่มีจำกัดของดาต้าเซ็นเตอร์บังคับให้หน่วยธุรกิจและทีมแอปพลิเคชัน/ทีมพัฒนาต้องประสานกับเจ้าของแพลตฟอร์ม เช่น ทีมเครือข่าย เพื่อขอรับทรัพยากร
  • กระบวนการกำกับดูแลจำนวนมากของเราพึ่งพาความขาดแคลนตามธรรมชาติและความเป็นเจ้าของแพลตฟอร์มนี้ นักพัฒนาคนหนึ่งไม่สามารถจัดสรร public IP address ให้ตัวเองได้ เพราะไม่มีสิทธิ์ควบคุมเครือข่ายในระดับผู้ดูแลระบบ
• คลาวด์คอมพิวติ้งขจัดความขาดแคลน ขอบเขต และผู้เฝ้าประตูออกไป เครือข่าย class-B เต็มรูปแบบอยู่ห่างออกไปเพียงบัตรเครดิตหนึ่งใบกับ API call ไม่กี่ครั้ง ผู้ให้บริการคลาวด์ยังใช้ระบบอัตโนมัติเพื่อลดความยุ่งยากของการจัดการโครงสร้างพื้นฐานในหลายด้าน (อย่างน้อยก็ในระดับผิวเผิน)
  • ข้อได้เปรียบหลายประการของคลาวด์คอมพิวติ้งเป็นผลโดยตรงจากการกำจัดความขาดแคลนของทรัพยากร ผู้เฝ้าประตู และการกำหนดค่าด้วยมือ ระบบอัตโนมัติ infrastructure as code และ CI/CD สร้างข้อได้เปรียบด้านการปฏิบัติงานอย่างมหาศาล แต่โดยพื้นฐานแล้วเข้ากันไม่ได้กับการกำกับดูแลแบบเดิมที่ตั้งอยู่บนความขาดแคลนและผู้เฝ้าประตู
• อย่างไรก็ตาม คลาวด์รวมการควบคุมด้านการดูแลระบบทั้งหมดไว้ที่คอนโซล/พอร์ทัลเดียว.
  • ซึ่งเปิดสู่อินเทอร์เน็ตและป้องกันด้วยชื่อผู้ใช้กับรหัสผ่าน
• ดังนั้น คลาวด์จึงทำลายโมเดลการกำกับดูแลแบบเดิม และผลักให้องค์กรต้องหันมาใช้การกำกับดูแลแบบกระจายมากขึ้น พร้อมโยกทรัพยากรไปสู่การควบคุมที่ยึดอัตลักษณ์เป็นศูนย์กลาง แทน
• นี่คือการเปลี่ยนผ่านที่เจ็บปวด เพราะการนำเทคโนโลยีคลาวด์มาใช้นั้นเร็วและง่ายกว่าการเปลี่ยนโมเดลการกำกับดูแลเทคโนโลยี

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

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

• รวมศูนย์มาตรฐาน การมองเห็น และการเฝ้าระวัง แต่กระจายการปฏิบัติงานออกไปด้วยเครื่องมืออย่าง ChatOps
• ให้ความยืดหยุ่นแบบไร้แรงเสียดทานในขั้นตอนการพัฒนา แต่ใช้การจัดการที่เข้มงวดในโปรดักชัน ด้วยเครื่องมืออย่าง CI/CD และ infrastructure as code เพื่อความสม่ำเสมอและความสามารถในการตรวจสอบ
• ควบคุมการเข้าถึงข้อมูลสำคัญ/ข้อมูลที่อยู่ภายใต้กฎระเบียบ เพื่อจำกัดขอบเขตที่ต้องให้ความสำคัญเป็นพิเศษ
• จัดการขอบเขต IAM ก่อน ไม่ใช่เครือข่าย