สารพัดวิธีป้องกันภัยบนคลาวด์

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

ยกตัวอย่าง บริษัท Pfizer Inc. ที่เอาต์ซอร์สบริการรักษาความปลอดภัยบางส่วนให้ D3 Security Management Systems Inc. ดูแล และมีความสนใจใช้โปรแกรม Access Manager ของออราเคิลที่ฝังอยู่ในแอพพลิเคชันจัดการ Incident ของ D3 “แต่ D3 แสดงความกังวลในเรื่องติดตั้งเอเจ็นต์ของออราเคิลบนระบบของเขา” Kurt Anderson ผู้จัดการฝ่ายเทคโนโลยีปฏิบัติการทางธุรกิจของบริษัทเวชภัณฑ์แห่งนี้ระบุ

Anderson จึงแก้ปัญหาด้วยการใช้ผลิตภัณฑ์ SinglePoint Cloud Access Manager จากค่าย Symplified ซึ่งสามารถติดต่อกับ API ของ D3 ได้โดยไม่ต้องใช้เอเจ็นต์

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

หนึ่งในผลิตภัณฑ์เหล่านี้ได้แก่ Trend Micro Deep Security 7 เมื่อติดตั้งลงในโครงสร้างพื้นฐานพับลิกหรือไพรเวทคลาวด์ เอเจ็นต์ก็จะสามารถตรวจสอบแพ็กเก็ตแบบ Deep Inspection ตรวจสอบอีเว็นต์ล็อก ตลอดจนเฝ้าติดตามกิจกรรมในระบบ เช่น ติดตามการเปลี่ยนแปลงของไฟล์ เพื่อตรวจสอบการเข้าถึงโดยไม่ได้รับอนุญาต เป็นต้น

ส่วน Shavlik ในฐานะผู้ให้บริการจัดการระบบไพรเวทคลาวด์ เลือกใช้วิธีต่อสู้ปัญหาการรักษาความปลอดภัยพับลิกคลาวด์จากมุมที่ต่าง โดยขายลิขสิทธิ์การใช้ซอฟต์แวร์บริหารแพตช์และคอนฟิกูเรชันของตัวเองแก่ผู้ ให้บริการคลาวด์เจ้าอื่น รวมถึงบริษัทที่ให้บริการ IaaS แก่ Shavlik เองด้วย

ผู้ให้บริการคลาวด์ทั้งหลาย เริ่มจับกระแสได้ว่าการใช้ผลิตภัณฑ์รักษาความปลอดภัยเชิงพาณิชย์ที่น่าเชื่อ ถือในตลาดสามารถดึงดูดลูกค้าได้มาก อย่างการที่ BlueLock เลือกใช้ซอฟต์แวร์จากค่าย Shavlik ก็เป็นจุดที่ทำให้ Logiq³ ตัดสินใจเข้ามาใช้บริการ “เพราะผมเองคุ้นเคยกับซอฟต์แวร์ของ Shavlik อยู่แล้ว ผมใช้มันบริหารจัดการแพตช์และคอนฟิกูเรชันในบริษัทมานานแรมปี”

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

ยกตัวอย่างกรณี Pfizer จะเลือกใช้ผลิตภัณฑ์ Single Point Cloud Access Manager จากค่าย Symplified จัดการระบบ SSO (Single Sign-On) ข้ามผ่านระหว่างแอพพลิเคชันกับผู้ให้บริการ SaaS รายต่างๆ เมื่อไรก็ตามที่ผู้ใช้ปลายทางย้ายจากโดเมนที่จัดการโดยออราเคิลไปยังโดเมน ที่จัดการโดย Symplified (หรือกลับกัน) ผู้ใช้จะต้องล็อกออนอีกครั้ง แต่ยังคงใช้บัญชีชุดเก่าได้เหมือนเดิม

Symplified และ Ping Identity เป็นบริษัทเจ้าของผลิตภัณฑ์สองรายที่เสนอระบบ SSO สำหรับใช้กับแอพพลิเคชันภายในองค์กร และคลาวด์แอพพลิเคชันของผู้ให้บริการ SaaS โดยอาศัยเทคโนโลยีแบบ Federated Identity ที่คอยบริหารจัดการเอกลักษณ์ของผู้ใช้ และระบบควบคุมการเข้าถึงข้ามระบบต่างๆ อย่างไรก็ตาม Anderson รู้สึกว่าควรเป็นหน้าที่ของผู้ให้บริการ SaaS ที่จะต้องหาวิธีควบคุมการเข้าถึงที่เป็นมาตรฐานและน่าเชื่อถือ เพื่อที่ลูกค้าจะไม่ต้องแบกรับภาระนั้น

ส่วนอีกหนึ่งข้อกังวล เกี่ยวกับระบบควบคุมการเข้าถึง เมื่อลูกค้าต้องยุ่งเกี่ยวกับบริการคลาวด์ หรือบริการเอาต์ซอร์สประเภทอื่นๆ ก็คือแน่ใจได้อย่างไรว่าผู้ดูแลระบบของผู้ให้บริการจะไม่ใช้บัญชีเข้าถึง ระบบในทางที่ผิดเสียเอง เช่นเดียวกัน ลูกค้าผู้ใช้บริการ SaaS ย่อมไม่มีทางควบคุมหรือสอดส่องว่าผู้ให้บริการมีวิธีจัดการความปลอดภัย อย่างไร แต่ในทางกลับกัน ผู้ให้บริการ IaaS มักจะยอมให้ลูกค้าติดตั้งซอฟต์แวร์ติดตามบันทึกเหตุการณ์ในส่วนของระบบที่ จัดสรรให้ได้

ยกตัวอย่าง Logiq³ จะใช้ผลิตภัณฑ์บริหารซีเคียวริตี้อีเว็นต์ของ Sentry Metrics ที่มีคุณสมบัติติดตามบันทึกเหตุการณ์ต่างๆ วิเคราะห์ความโน้มเอียงของปัญหา และรายงานพฤติกรรมที่ต้องสงสัยในระบบ เพราะฉะนั้น ระบบของ Sentry Metrics จึงสามารถแจ้งเตือน Logiq³ ให้ทราบเมื่อผู้ดูแลระบบของ BlueLock พยายามล็อกออนโดยไม่ขออนุญาตก่อนได้

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

“สัญญา SLA ที่ระบุโทษปรับก็ไม่ช่วยแก้ปัญหาอะไร” Anderson แห่ง Pfizer กล่าว “เนื่องจากเงินค่าปรับเพียงเล็กน้อย ไม่อาจเทียบได้เลยกับปริมาณความสูญเสียที่เกิดขึ้นเมื่อข้อมูลสำคัญโดนแฮ็ก”

“เพราะฉะนั้น การจ้างสำนักตรวจสอบข้างนอกเป็นกรณีพิเศษหรือ Due Diligence จึงเป็นเรื่องสำคัญ” Anderson กล่าว “Pfizer เลือกใช้มาตรฐานรับรอง SAS 70 Type 2 ซึ่งบังคับให้สำนักตรวจสอบข้างนอกเข้ามาตรวจสอบกระบวนการทำงานภายในของผู้ ให้บริการ รวมถึงการปฏิบัติตามกฎระเบียบ European Safe Harbor โดยเรียกใช้บริการตรวจสอบของ Dun & Bradstreet”

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

“ถึงแม้มาตรฐานเหล่านี้จะเป็นจุดเริ่มต้น ที่ดี แต่เนื้อหาส่วนใหญ่ยังคงเป็นเพียงการกล่าวโดยภาพรวมเท่านั้น ” Heiser แห่ง Gartner อธิบาย “บริษัทของคุณยังคงต้องระบุเจาะจงความต้องการที่เป็นแบบเฉพาะของคุณเอง”

ยกตัวอย่างกรณีของ Logiq³ หลังจากตรวจสอบความเข้ากันได้กับมาตรฐาน SAS 70 Type 2 ของ BlueLock แล้วทางเจ้าหน้าที่ไอทีของ Logiq³ ก็ยังตรวจประเมินเพิ่มเติมเพื่อให้แน่ใจว่า ส่วนควบคุมที่ต้องการใช้งานได้รับการสนับสนุนโดยระบบของผู้ให้บริการจริงๆ จากนั้นก็ตรวจเปรียบเทียบว่าฟังก์ชันใดที่ยังขาดอยู่บ้าง แล้วปรึกษาหารือกับผู้ให้บริการเพื่อหาทางแก้ไขต่อไป ซึ่ง Westgate เปิดเผยว่าบริษัทฯ มีแผนที่จะดำเนินการในลักษณะนี้ซ้ำกันปีละครั้ง

นำ เสนอวิธีการใช้งาน Saasที่ถูกต้องให้กับผู้ใช้
หลายบริษัทที่ต้องการลด ต้นทุนโดยใช้บริการคลาวด์ แต่ยังคงพะวงเรื่องความปลอดภัยจะเตือนให้ผู้ใช้อย่าใส่ข้อมูลที่มีความสำคัญ สูงไว้บนคลาวด์ ซึ่ง Heiser มองว่าไร้ประโยชน์ “ปัญหาคือผู้ใช้มักไม่ทราบว่าข้อมูลไหนที่เรียกว่าสำคัญ และไม่ยอมปฏิบัติตามกฎระเบียบอยู่ดี ให้คุณสันนิษฐานไว้ก่อนเลยว่าแอพพลิเคชันหรือบริการข้อมูลใดๆ ที่ผู้ใช้สามารถใส่ข้อมูลเข้าไปได้ถือว่าสำคัญหมด”

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

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

ลอง ดูกรณีของ Cloud Compliance Inc. ที่ให้บริการเฝ้าติดตามระบบควบคุมการเข้าถึงสำหรับบริการคลาวด์ภายในองค์กร กันบ้าง บริษัทนี้มอบหมายให้ Amazon เป็นฝ่ายดูแลโครงสร้างพื้นฐาน เนื่องจากเล็งเห็นว่าเป็นผู้ให้บริการที่มีชื่อเสียง ตามคำบอกเล่าของ Robbie Forkish ผู้ก่อตั้ง Cloud Compliance แต่อย่างไรก็ตาม เขายอมรับว่ายังคงประสบปัญหาเรื่องความปลอดภัยอยู่ เพราะมีอยู่หลายประเด็นที่ Amazon ไม่สามารถตอบโจทย์ของ Cloud Compliance รวมถึงลูกค้าของ Cloud Compliance เองได้

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

ลูกค้าของ Cloud Compliance บางส่วนถามถึงระบบรักษาความปลอดภัยของ Amazon ซึ่งข้อกังวลที่หยิบยกขึ้นมาจะแปรเปลี่ยนไปเดือนต่อเดือน ขึ้นอยู่กับข่าวที่สื่อมวลชนประโคมเวลานั้น และสำหรับ Cloud Compliance หากไม่สามารถตอบปัญหาได้ ก็จะส่งคำถามให้ Amazon เป็นผู้ตอบแทน

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

คลาวด์กับกฎหมายข้อมูล
บริการ คลาวด์สาธารณะได้นำประเด็นใหม่มาสู่กฎหมายข้อมูล ซึ่งเป็นเรื่องที่ผู้ให้บริการ ผู้ใช้บริการ และฝ่ายบังคับใช้กฎหมายเองก็เพิ่งจะทำการพิจารณาอย่างจริงจัง อย่างเช่นข้อกำหนดในการรักษาความเป็นส่วนตัวข้อมูล หรือข้อกำหนดในการเก็บรักษาข้อมูลที่กฎหมาย HIPAA และ Sarbanes-Oxley ระบุไว้ก็ไม่ได้ออกแบบมาสำหรับคลาวด์เป็นทุนเดิมอยู่แล้ว

“เจ้า หน้าที่ไอทีจำเป็นต้องหาวิธีใหม่ในการวิเคราะห์และประเมินความเสี่ยง รวมถึงวิธีที่จะทำให้สอดคล้องกับกฎหมายข้อมูลที่บังคับใช้” Forkish กล่าว “มาตรฐานจำนวนมากกำหนดให้เราติดตามว่าข้อมูลอยู่ที่ไหน ซึ่งไม่มีทางเป็นไปได้เลยสำหรับคลาวด์ แถมยังมีเรื่อง e-Discovery ซึ่งเจ้าพนักงานจะต้องเข้าถึงข้อมูลได้ทันทีที่ต้องการ การค้นหาข้อมูลเหล่านี้จะกระทำโดยบุคคลที่สามโดยปราศจากความช่วยเหลือของคุณ ได้จริงหรือ เนื่องจากข้อมูลเหล่านั้นวางอยู่ในคลาวด์สตอเรจ? เหล่านี้คือตัวอย่างปัญหาที่ผมคิดว่าคนในอุตสาหกรรมนี้จะต้องหาทางแก้ไขให้ ได้ภายในสองสามปีข้างหน้า

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

และยัง มีหน่วยกล้าตายอย่าง Westgate แห่ง Logiq³ ที่เปรียบคลาวด์คอมพิวติงเป็นวิวัฒนาการตามธรรมชาติที่มนุษย์เราไม่อาจ เลี่ยง “โปรดอย่าถามผมว่าจะใช้คลาวด์ไปทำไม เพราะผมจะถามกลับว่า... ทำไมคุณถึงไม่ใช้ล่ะ?”

5 เคล็ดลับในการใช้คลาวด์อย่างปลอดภัย

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

เข้ารหัสลับข้อมูลทั้งที่ฝากไว้บนคลาวด์ และในระหว่างกระบวนการส่ง หรือมิฉะนั้นก็อย่าได้ฝากข้อมูลสำคัญไว้บนคลาวด์เด็ดขาด

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

ตรวจสอบว่า ผู้ให้บริการได้รับมาตรฐานรับรองความปลอดภัย SAS 70 Type 2 และ ISO 27001 หรือไม่ โดยเฉพาะถ้าคุณเป็นบริษัทข้ามชาติ ขอให้เรียกหามาตรฐานรับรอง European Safe Harbor ด้วย

เลือกใช้บริการจากผู้ให้บริการที่มีชื่อ เสียงโด่งดังในทางที่ดีเท่านั้น จำไว้ว่าคุณจะได้เท่าที่คุณมีปัญญาจ่าย

แหล่งที่มา
http://www.c4zone.com/main/index.php?option=com_content&view=article&id=445%3A2010-03-19-13-31-11&catid=40%3Aspecial-report&Itemid=80&limitstart=1