เมื่อ Cloud Computing ได้ปฏิวัติวงการไอทีอย่างสิ้นเชิง ทำให้บริษัทไอทีน้อย ใหญ่ สามารถสร้างอินฟาสตรัคเจอร์และแอปพลิเคชั่นให้พร้อมส่งบริการถึงมือลูกค้าได้อย่างง่ายดาย ขณะที่ขั้นตอนการออกแบบและพัฒนาไอเดียให้เป็นรูปเป็นร่างกลับไม่ต้องใช้เงินเป็นล้านเหมือนเมื่อก่อนในการซื้ออุปกรณ์และวางโครงสร้างของการทดสอบ เหมือนการสร้างโฮสต์ศูนย์ข้อมูลภายในบริษัทเช่นในวันวาน และยังดึงดูดให้ตกเป็นเป้าหมายของผู้ไม่หวังดีอย่างแฮกเกอร์อยู่บ่อยครั้ง
แน่นอนว่าการย้ายระบบทั้งหมดขึ้นสู่คลาวด์นั้นจะต้องปลอดภัยกว่าเดิมถูกมั้ย ? ผู้ให้บริการคลาวด์ควรจะต้องให้ความปลอดภัยเราได้อย่างมั่นใจ ว่าแฮกเกอร์จะไม่มีโอกาสเจาะระบบเข้าไปทำอันตรายข้อมูลของเราได้ แต่นั่นเป็นเรื่องที่ไม่จริงเลย บ่อยครั้งที่ความเข้าใจผิดนี้ส่งต่อมาจากลูกค้าหลาย ๆ คน ความจริงที่สำคัญนอกเหนือจากการตั้งค่าที่ถูกต้องให้กับระบบคลาวด์แล้ว ทักษะความสามารถของผู้ดูแลระบบคลาวด์ ตลอดจนความสามารถในการรับมือการโจมตีที่เกิดขึ้นจากการให้บริการคลาวด์ ก็น่าจะเหมาะสมสำหรับการให้บริการคลาวด์นั้น ๆ
รูปแบบความรับผิดชอบร่วมกัน
ก่อนที่เราจะทำอย่างอื่น เราจะต้องหารูปแบบความรับผิดชอบร่วมกันระหว่างผู้ให้บริการคลาวด์และผู้ใช้บริการ ซึ่งเมื่อเราวางแผนการย้ายข้อมูลทั้งหมดไปที่คลาวด์ สิ่งหนึ่งที่เราจะตระหนักคือขั้นตอนการย้ายนั้นเป็นความรับผิดชอบของใคร ดังที่กล่าวมาตั้งแต่ต้นว่าผู้ใช้บริการคาดหวังที่จะให้ผู้ให้บริการคลาวด์ ซึ่งมีหน้าที่เพียงแค่การรักษาความปลอดภัยของคลาวด์อินฟาสตรัคเจอร์และความปลอดภัยทางกายภาพของการให้บริการคลาวด์เท่านั้น
แต่ในทางตรงกันข้าม ลูกค้าผู้ใช้บริการคลาวด์ ต่างคาดหวังที่จะให้ผู้ให้บริการคลาวด์รับผิดชอบไปถึงความเสียหายของข้อมูล ความปลอดภัยทั้งระบบของปริมาณงานที่ทำ ตลอดจนความปลอดภัยของระบบเครือข่ายเสมือนจริงของบริษัทอีกด้วย
สิ่งสำคัญอย่างหนึ่งนั่นคือ การเข้าถึงข้อมูลได้ของผู้ใช้บริการคลาวด์ ซึ่งใครจะสามารถเข้าถึงข้อมูลแบบไหนได้บ้าง ? นั้นเป็นเรื่องสำคัญ ซึ่งก็เป็นเรื่องที่ไม่แตกต่างจากระบบดาต้าเซ็นเตอร์ของบริษัทเองในอดีตที่ผ่านมา ยกเว้นในส่วนของการจัดการด้านความปลอดภัยของศูนย์ข้อมูลที่ผู้ให้บริการคลาวด์จะเป็นผู้ดูแลแทน ซึ่งนั่นหมายถึงแผนกไอทีหรือผู้เชี่ยวชาญไอทีของบริษัทจะเป็นผู้รับผิดชอบในการเก็บล็อคข้อมูลของบริษัทเองให้มีความปลอดภัยสูงสุด ที่แม้แต่ผู้ให้บริการคลาวด์เองก็ไม่สามารถเข้าถึงข้อมูลเหล่านั้นได้
บ่อยครั้งที่ข้อตกลงความรับผิดชอบร่วมกันเหล่านี้ถูกมองข้าม จนทำให้เกิดความสับสนขึ้นเมื่อเกิดสถานการณ์การโจมตีขึ้นในครั้งแรก ๆ ดังนั้นเราจึงได้สร้างแบบจำลองความรับผิดชอบร่วมกันขึ้นมา และลูกค้าจะต้องรับผิดชอบดูแลข้อมูลของตนเองให้มีความปลอดภัย เราลองมาดูตัวอย่างปัญหาทั่วไปที่อาจจะส่งผลต่อระบบคลาวด์ได้
Amazon S3
Amazon S3 เป็นระบบบริการคลาวด์ที่ใหญ่ของอะเมซอน เว็บเซอร์วิสต์ มีความสามารถในการจัดเก็บข้อมูล โฮสต์เว็บไซต์ หรือสร้างพื้นที่การทำงานให้กับแอปพลิเคชั่นที่ให้บริการแบบคลาวด์ ขณะเดียวกันพื้นที่ของ S3 ก็ยังเป็นเป้าหมายที่น่าสนใจของเหล่านักโจมตีทั้งหลาย หากพบว่ามีการตั้งค่าระบบผิดพลาดเกิดขึ้น
ตัวอย่างหนึ่งที่เกิดขึ้นในปี 2560 เมื่อ Booz Allen Hamilton บริษัทที่ปรึกษาด้านความมั่นคงของสหรัฐ เกิดทำข้อมูลรั่วไหลไปอยู่บนโลกออนไลน์ ซึ่งมีทั้งข้อมูลการปล้นสะดมในสนามรบและข้อมูลประจำตัวของผู้ดูแลระบบที่ละเอียดอ่อนของกองทัพรวมอยู่ด้วย ขณะที่อีกหนึ่งตัวอย่างที่เกิดขึ้นในปีเดียวกัน นั่นคือการที่ Amazon S3 มีการตั้งค่าความปลอดภัยไม่ถูกต้อง ส่งผลให้ข้อมูลการลงคะแนนเสียงของชาวอเมริกันกว่า 198 ล้านรายถูกเปิดเผย
ช่องโหว่ล่าสุดของ Amazon S3 ที่เกิดขึ้น (เหตุที่ใช้คำว่า “ช่องโหว่” เนื่องจากบ่อยครั้งการรั่วของข้อมูลเกิดจากความผิดพลาดในการตั้งค่าความปลอดภัยจนทำให้ข้อมูลถูกเข้าถึงได้แบบสาธารณะ ซึ่งไม่ได้เกิดจากการใช้ความสามารถขั้นสูงของแฮกเกอร์แต่อย่างใด) ทำให้ผู้ให้บริการคลาวด์รายนี้เป็นแค่เพียงผู้ให้บริการ “กล่องรับฝากข้อมูล” เท่านั้น ด้วยความที่ Amazon S3 เป็นเพียงแค่พื้นที่รับฝากข้อมูล จึงทำให้เกิดปัญหาของการตั้งค่าการป้องกันของผู้ใช้งานไม่รัดกุมมากพอ จนเป็นเหตุให้ข้อมูลส่วนบุคคลกว่า 2.7 แสนไฟล์ ซึ่งรวมทั้งข้อมูลส่วนบุคคลของผู้ใช้งานเกิดการรั่วไหลออกสู่สาธารณะ
สิ่งหนึ่งที่เราต้องทำความเข้าใจเมื่อต้องการที่จะส่งข้อมูลขึ้นไปจัดเก็บบนคลาวด์ของผู้ให้บริการคลาวด์สาธารณะ นั่นคือมีหลายบริษัทมากที่ใช้บริการ Amazon S3 เพื่ออัปโหลดข้อมูลขึ้นไปเก็บและดึงไปใช้กับแอปพลิเคชั่นที่ต้องการประมวลผลบางอย่างจากข้อมูลนั้น ปัญหาก็คือเราจะรู้ได้อย่างไรว่า ข้อมูลที่แต่ละบริษัทอัปโหลดขึ้นไปนั้นจะไม่ปนเปื้อนโปรแกรมไม่พึงประสงค์รวมอยู่ด้วย ? คำถามเหล่านี้ถูกถามและพูดถึงกันมากขึ้นในแวดวงไอที
API
APIs (โค้ดเชื่อมต่อระหว่างโปรแกรมประยุกต์ต่าง ๆ) เป็นสิ่งที่ดีแล้ว ซึ่งจะช่วยเชื่อมต่อระหว่างโปรแกรมและบริการของระบบอัตโนมัติทำงานได้อย่างราบรื่น และเมื่อพูดถึงระบบคลาวด์ API บนคลาวด์จะช่วยให้ผู้ดูแลระบบสามารถโต้ตอบกับบริการได้ในทันที และยังช่วยให้เข้าถึงบริการหลักของคลาวด์ได้ทั้งระบบ อีกทั้งยังเปิดโอกาสให้สร้างบริการที่แตกต่างกันได้อย่างง่ายดายเหมือนเป็นทุกสิ่งบนโลกของคลาวด์ แต่นั่นก็ทำให้เปิดโอกาสให้สิ่งอันตรายกล้ำกลายเข้ามาได้เช่นกัน
เริ่มต้นด้วยเกตเวย์ API ซึ่งเป็นโครงสร้างทั่วไปในระบบคลาวด์ เพื่อช่วยให้เกิดการสื่อสารระหว่างแอปพลิเคชั่นหลังบ้าน ทำให้เกตเวย์ API ตกเป็นเป้าหมายที่สำคัญ เพื่อช่วยให้แฮกเกอร์สามารถควบคุมและอนุญาตให้มีการรับ-ส่งไฟล์ที่ไม่พึงประสงค์ได้ดังใจ ไม่เพียงเท่านั้น API เกตเวย์ ยังถูกออกแบบมาให้เป็นช่องทางการเข้าถึงส่วนลึกของแอปพลิเคชั่น ซึ่งไม่ได้ถูกออกแบบมาเพื่อความปลอดภัย เพราะจะทำให้เกิดการเข้าถึงได้ยากของผู้ดูแล และนั่นก็หมายถึงการเปิดโอกาสให้มีการเชื่อมต่อที่ไม่น่าเชื่อถือเกิดขึ้น และบางครั้งอาจจะมีการรับ-ส่งข้อมูลโดยที่ผู้ดูแลมองไม่เห็น นอกจากนั้นแล้วการสื่อสารของ API เกตเวย์ ยังอาจจะมาพร้อมกับข้อมูลที่เป็นอันตรายได้เช่นเดียวกัน
การโจมตีอีกรูปแบบหนึ่งที่จะส่งผลต่อ API เกตเวย์ และระบบแอปพลิเคชั่นหลังบ้าน นั่นก็คือการโจมตีแบบ DDOS ซึ่งวิธีการทั่วไปของการป้องกันปัญหานี้ก็คือการใช้ Web Application Firewall (WAF) แต่ปัญหาก็คือ WAFs จะทำงานได้ช้า ในการชะลอการทำงานของการโจมตีแบบ DDOS ถ้าหากการ DDOS นั้นมีการร้องขอที่ดูเหมือนเป็นทราฟฟิกปกติ สิ่งที่ดีที่สุดในการแก้ปัญหาการโจมตีแบบ DDOS จึงอยู่ที่ API เกตเวย์ ซึ่งจะช่วยจำกัดจำนวนการร้องขอตามค่าที่ตั้งไว้
แน่นอนว่าสิ่งที่ช่วยปกป้องการโจมตี API ก็คือการตั้งค่าการเข้าถึง การปฏิเสธการเข้าถึงแบบไม่ระบุชื่อกับไฟล์ที่มีขนาดใหญ่ นอกจากนั้นการเปลี่ยนโทเค็น รหัสผ่านและจำกัดโอกาสในการใช้ข้อมูลรับรองที่มีประสิทธิภาพ สุดท้ายคือการปิดระบบการรับรองที่มีลักษณะเป็นข้อความที่ชัดเจนเกินไป นอกจากนี้ยังต้องบังคับใช้การเข้ารหัส SSL/TLS และรวมถึงการใช้ MFA ซึ่งเป็นการใช้หลายปัจจัยในการตรวจสอบและยืนยันการรับรองที่แตกต่างกัน
การคำนวณ
บริการคลาวด์จะไม่สมบูรณ์หากไม่มีการคำนวนทรัพยากร ซึ่งเมื่อองค์กรต้องการสร้างเซิร์ฟเวอร์เสมือนสำหรับการบริการหรือทำงานแอปพลิเคชั่น ส่วนนี้เองที่จะตกเป็นช่วงโหว่ให้เกิดการโจมตีจากผู้ไม่ประสงค์ดี และก็เป็นอีกครั้งที่ผู้ให้บริการคลาวด์ไม่ได้คุ้มครองความปลอดภัยในส่วนของตรงนี้เช่นกัน ทำให้ความรับผิดชอบตกเป็นของลูกค้าผู้ใช้บริการโดยตรง
หลายครั้งที่มีการปรึกษาเรื่องที่จะย้ายศูนย์ข้อมูลของบริษัทขึ้นไปสู่ระบบคลาวด์ หนึ่งในวิธีการทั่วไปก็คือการ ‘ยกและย้าย’ นั่นเอง ซึ่งหมายถึงการที่ลูกค้าจะสร้างระบบเสมือนขึ้นมาในศูนย์ข้อมูลของบริษัทและย้ายระบบเสมือนทั้งหมดขึ้นสู่คลาวด์แบบง่ายๆ ซึ่งเมื่อถึงตอนนี้ก็ต้องถามลูกค้าว่า ได้มีการประเมินความปลอดภัยในเครื่องเสทลมือนที่สร้างขึ้น ก่อนที่จะย้ายข้อมูลไปแล้วหรือยัง ? เครื่องเหล่านั้นได้ถูกแพตช์เพื่อแก้ไขข้อบกพร่องหรือทำให้ทันสมัยแล้วหรือไม่ ? พบข้อบกพร่องด้านความปลอดภัยแล้วแก้ไขแล้วหรือไม่ ?
ซึ่งจากประสบการณ์ส่วนตัวแล้ว คำตอบคือไม่ ดังนั้นองค์กรเหล่านี้เพียงแค่นำปัญหาที่มีอยู่ย้ายไปที่ใหม่ก็เท่านั้น ทำให้ช่องโหว่ด้านความปลอดภัยยังมีอยู่คงเดิมและอาจจะถูกโจมตีได้มากขึ้น หากเลือกใช้เซิร์ฟเวอร์แบบสาธารณะหรือกำหนดนโยบายด้านการเข้าถึงเครือข่ายที่ไม่เหมาะสม ซึ่งเราแนะนำว่าการวางแผนย้ายระบบขึ้นสู่คลาวด์นั้นจะต้องเริ่มจาก “แก้ไข-ยกและย้าย” น่าจะเป็นวิธีที่ดีกว่าเดิม
และเมื่อองค์กรต่าง ๆ เริ่มมีสถานะเป็นคลาวด์แล้ว พวกเขาจะเริ่มปรับการใช้ทรัพยากรใหม่ ซึ่งจะหมายถึงการพัฒนา ปรับปรุง หรือการสร้างโซลูชั่นสำเร็จรูปที่พร้อมจะติดตั้งได้ทันที สิ่งสำคัญต้องอย่าลืมว่าการจะทำเช่นนั้นได้จะต้องใช้คอมพิวเตอร์ และนั่นก็ยังมีความเสี่ยงต่อมัลแวร์อยู่เช่นเดิม ดังนั้นไม่ว่าจะอยู่ในระบบคลาวด์หรือไม่ก็ตาม จำเป็นจะต้องมีระบบการควบคุมความปลอดภัยที่มีประสิทธิภาพแบบเดียวกัน รวมถึงการป้องกันมัลแวร์ ระบบตรวจสอบการบุกรุกแบบ IPS การตรวจสอบความสมบูรณ์ของระบบ และการควบคุมแอปพลิเคชั่น ซึ่งทั้งหมดนี้ควรจะทำได้ภายในโซลูชั่นเดียวกัน
ระบบเครือข่าย
บริการคลาวด์ ช่วยให้การปรับใช้เครือข่ายเป็นเรื่องง่ายอย่างไม่น่าเชื่อ และยังสามารถแบ่งระดับการใช้งานตามความสำคัญ รวมทั้งความสามารถในการรวมรูปแบบการสื่อสารต่างเครือข่ายมาไว้ด้วยกันได้อีกด้วย นอกจากนี้ยังสามารถปิดกั้นประเภทของทราฟฟิกเฉพาะส่วนที่ได้รับอนุญาตให้สามารถเข้าถึงทรัพยากรที่กำหนดได้อีกด้วย ซึ่งเมื่อกลุ่มที่มีความปลอดภัยจะเข้าระบบ กลุ่มความปลอดภัยเหล่านี้ก็จะถูกกำหนดค่าโดยบุคคล จุดนี้เองที่มีโอกาสที่พอร์ตจะเปิดเกินความจำเป็นจนกลายเป็นช่องโหว่ที่ถูกโจมตีได้ โดยสิ่งที่สำคัญที่สุดจากมุมมองนี้คือความสามารถในการคำนวนทรัพยากรทั้งหมดที่จะเกิดขึ้น เพื่อให้สามารถเข้าใจความผิดปกติและสาเหตุที่เกิดขึ้น จึงจะสามารถเลือกใช้มาตรการด้านความปลอดภัยของระบบได้อย่างเหมาะสม
ท้ายที่สุดระบบคลาวด์จะปลอดภัยจากแฮกเกอร์จริง ๆ หรือไม่ปลอดภัยมากไปกว่าระบบอื่น ๆ ก็ขึ้นอยู่กับองค์กรว่ามีความมั่นใจมากแค่ไหนในการวางแผนด้านความปลอดภัยมาเพียงพอหรือยัง และมีความเข้าใจว่าจะเริ่มต้นรับผิดชอบจากจุดใด รวมทั้งเข้าใจขอบเขตความรับผิดชอบของผู้ให้บริการคลาวด์เป็นอย่างดี แน่นอนว่าการห้ำหั่นกันระหว่างแฮกเกอร์และผู้เชี่ยวชาญการป้องกันการโจมตีจะยังคงเกิดขึ้นต่อไปเช่นเดิม แม้ว่ารูปแบบของสมรภูมิจะเปลี่ยนไปอยู่บนคลาวด์แล้วก็ตาม
บทความโดย Rob Maynard Solutions Architect, Trend Micro
