เมื่อ MFA ยังไม่เพียงพอ

กฎข้อแรกของความปลอดภัยบนคลาวด์คือ "ต้องใช้ MFA ตลอดเวลา" เพราะเหตุใด เมื่อองค์กรย้ายไปใช้ public cloud computing สิ่งที่เกิดขึ้นคือการนำอินเทอร์เฟซสำหรับการบริหารจัดการทั้งหมดมารวมไว้ในพอร์ทัลหรือ API เดียว แล้ว... เปิดออกสู่อินเทอร์เน็ตโดยมีเพียงชื่อผู้ใช้ รหัสผ่าน และ (อาจจะ) MFA เป็นเกราะป้องกัน แม้จะใช้ federation ก็ตาม

แต่ในความเป็นจริง แม้แต่ MFA ก็ยังไม่เพียงพอเสมอไป ดังที่เห็นได้จากเหตุการละเมิดข้อมูลครั้งใหญ่หลายกรณี รวมถึงกรณีที่เกิดขึ้นกับ Uber

นี่คือหนึ่งในความแตกต่างที่สำคัญที่สุดระหว่างคลาวด์กับโครงสร้างพื้นฐานแบบดั้งเดิมที่ต้องทำความเข้าใจ และเป็นเหตุผลที่ท่านได้ยินวลี "identity คือ perimeter ใหม่" อยู่เสมอ ก่อนยุคคลาวด์ เราบริหารจัดการศูนย์ข้อมูลจากภายในเครือข่ายส่วนตัว (หรือผ่านจุดเข้าถึงที่ควบคุมไว้ เช่น VPN และ jump box) แต่บนคลาวด์ ทุกอย่างอยู่บนอินเทอร์เน็ตโดยค่าเริ่มต้น และการปิดกั้นให้รัดกุมนั้นทำได้ยาก โดยเฉพาะในปัจจุบันที่เรารองรับพนักงานและผู้ดูแลระบบที่ทำงานจากระยะไกลมากขึ้น

MFA เป็นวิธีที่ได้ผลในการปกป้องการยืนยันตัวตนของผู้ใช้และผู้ดูแลระบบ เรามีตัวเลือกมากมายตั้งแต่ระดับที่ปลอดภัยขึ้นเล็กน้อย (MFA ผ่านข้อความ) ไปจนถึงระดับที่ปลอดภัยสูงมาก (hardware key) แต่ปัญหาของ MFA คือผู้ใช้ยังคงมีสิทธิ์เข้าถึงแบบถาวรพร้อมสิทธิ์การใช้งานแบบถาวร หากท่านกำหนด role ให้ผู้ใช้คนหนึ่ง ผู้ใช้คนนั้นสามารถใช้สิทธิ์เหล่านั้นได้ทุกเมื่อหลังยืนยันตัวตนสำเร็จ ผู้โจมตีรู้ดีในเรื่องนี้ และได้พัฒนาเทคนิคหลากหลายเพื่อให้ได้มาซึ่งการเข้าถึงที่ผ่านการยืนยันตัวตน โดย:

• ใช้ประโยชน์จาก static credential ในทางที่ผิด โดยเฉพาะเมื่อไม่มีการใช้ MFA
• เจาะผ่าน MFA บางรูปแบบ ตัวอย่างเช่น การทำ SIM swap เพื่อดักข้อความที่ส่งไปยังโทรศัพท์
• ใช้วิศวกรรมสังคมกับผู้ดูแลระบบเพื่อให้ปิดการใช้งาน MFA หรือรีเซ็ตไปยังอุปกรณ์ที่ผู้โจมตีควบคุมอยู่
• ใช้วิศวกรรมสังคมกับผู้ใช้เพื่อล้วงรหัส MFA
• ขโมย session credential จากเครื่องของผู้ใช้หลังจากที่ผู้ใช้ยืนยันตัวตนไปแล้ว จากนั้นนำไปใช้จากเครื่องที่ผู้โจมตีควบคุมอยู่

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

Least Privilege เป็นเพียงภาพลวงตา

ปัญหาหลักคือเรากำหนดสิทธิ์ไม่ได้อิงจากสิ่งที่ผู้ใช้ต้องทำ ณ ช่วงเวลาหนึ่ง แต่อิงจากสิ่งที่ผู้ใช้อาจต้องทำในอนาคต ผู้ใช้ โดยเฉพาะผู้ดูแลระบบ จึงได้รับสิทธิ์สูงสุดครอบคลุมทุกการกระทำที่เป็นไปได้ มาตรฐานด้านความปลอดภัยทุกฉบับบนโลกนี้ระบุว่า IAM ควรเป็น default deny และ least privilege แต่นั่นก็เป็นเรื่องลวงอยู่พอสมควร เพราะชุด "สิทธิ์ขั้นต่ำ" นั้นถูกนิยามด้วยชุดสิทธิ์สูงสุดที่ผู้ใช้จะต้องใช้ในบางช่วงเวลา ไม่ใช่ตลอดเวลา

แม้ในกรณีที่เราอนุญาตให้ผู้ใช้สลับ role และใช้สิทธิ์ที่ต่างกันในแต่ละ session ผู้ใช้ก็ยังเข้าถึง role เหล่านั้นได้เมื่อใดก็ตามที่ต้องการอยู่ดี ในความเป็นจริง least privilege ควรถูกจำกัดด้วยเวลา ไม่ใช่จำกัดเฉพาะตัวผู้ใช้เท่านั้น ที่ผ่านมาเราบริหารจัดการสิทธิ์ด้วยการกำหนด role และ role ก็มีสิทธิ์ตาม scope ที่กำหนด "ท่านเป็น admin ของ 5 บัญชีนี้ และเป็นผู้ใช้ทั่วไปของอีก 98 บัญชีที่เหลือ" บ่อยครั้งเรายังกำหนดหลาย role ให้ผู้ใช้คนเดียว ซึ่งอาจเป็นการรวมสิทธิ์เข้าด้วยกัน หรือให้สลับ role ไปมาเมื่อทำงานต่างประเภท

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

เสริมความปลอดภัยด้วย Dynamic Authorization

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

แทนที่จะให้ผู้ใช้เข้าถึงสิทธิ์ทั้งหมดที่อาจต้องใช้ได้อย่างถาวร เราให้สิทธิ์การเข้าถึงที่จำกัดกว่า แล้วให้ผู้ใช้ร้องขอการยกระดับสิทธิ์เมื่อจำเป็น แนวคิดนี้ไม่ใช่เรื่องใหม่ เป็นสิ่งที่ผลิตภัณฑ์ privileged user management ใช้มาหลายปีแล้ว แต่ผลิตภัณฑ์เหล่านั้นมักยังพึ่งพาเทคนิคที่เทอะทะ เช่น proxied session และการหมุนเวียนรหัสผ่านชั่วคราว ขณะที่คลาวด์ยืดหยุ่นกว่าโดยธรรมชาติ เพราะโมเดล IAM แบบ native นั้นอิงกับ session อยู่แล้ว และสิทธิ์ถูกนิยามไว้ในเอกสาร policy (โดยทั่วไปเขียนด้วย JSON)

นี่คือหลักการทำงานของเครื่องมืออย่าง FireMon Authorization Control ของเรา หรือลองดู Netflix ConsoleMe เป็นตัวอย่างของโอเพนซอร์ส ผู้ใช้ร้องขอสิทธิ์เมื่อจำเป็นต้องใช้ จากนั้นแพลตฟอร์มจะใช้ policy พิจารณาเงื่อนไขที่ต้องมีเพื่ออนุมัติ เมื่อเงื่อนไขครบถ้วน เช่น การอนุมัติจากผู้จัดการหรือเพื่อนร่วมงาน ผู้ใช้จะได้รับอนุญาตให้ใช้ role นั้นในช่วง session หนึ่ง แพลตฟอร์มยังสามารถแทรกเงื่อนไขเพิ่มเติมได้ เช่น "อนุญาต session นี้เฉพาะจาก IP address ที่ส่งคำขอเท่านั้น" คำขอเหล่านี้มักดำเนินการแบบ out-of-band ผ่านช่องทางเสริมอย่าง ChatOps เพื่อขออนุมัติ ทำให้กระบวนการมีเสียงแจ้งเตือนชัดเจนโดยเจตนา โดยเฉพาะกับการเข้าถึงระบบ production ที่มีความอ่อนไหว

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

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