ผลกระทบของ AuthN/AuthZ Gap

เป็นที่รู้กันทั่วไปแล้วว่าบนคลาวด์นั้น "identity คือ perimeter รูปแบบใหม่" เป็นวลีที่ฟังดูดีและหยิบไปใส่ในสไลด์นำเสนอหรือบทความได้ง่าย แต่การแปลงให้เป็นแนวทางที่ปฏิบัติได้จริงนั้นยากกว่ามาก วันนี้ผมขอโฟกัสเพียงแง่มุมเดียวของ cloud IAM ซึ่งผมเรียกว่า "AuthN/AuthZ Gap" อันที่จริงปัญหานี้เกิดขึ้นได้ทุกครั้งที่คุณใช้ federation แต่บนคลาวด์มีความเสี่ยงสูงกว่า เพราะ cloud management plane เปิดสู่อินเทอร์เน็ตอยู่ตลอดเวลา

ก่อนอื่น ขออธิบายสั้น ๆ ถึงความต่างระหว่าง AuthN กับ AuthZ:

• AuthN คือการพิสูจน์ตัวตน (authentication) คือการยืนยันว่าคุณคือเอนทิตีนั้นจริง สำหรับคนทั่วไปอย่างเรา ๆ มักหมายถึงชื่อผู้ใช้ รหัสผ่าน และอาจมี MFA ด้วย
• AuthZ คือการให้สิทธิ์ (authorization) คือการตรวจสอบว่าการกระทำหนึ่ง ๆ ได้รับอนุญาตหรือไม่ สำหรับคลาวด์แบบ IaaS เรื่องนี้แทบจะโยงกลับไปที่ API call เสมอ แม้ว่าคุณจะใช้งานผ่านเว็บคอนโซลหรือพอร์ทัลก็ตาม

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

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

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

แล้วจะแก้ไขอย่างไร

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

• เพิ่มเงื่อนไขเพื่อจำกัด IP ต้นทางของ API call
• ปฏิเสธทุกเซสชันที่ถูกสร้างขึ้นก่อนวันที่หรือเวลาที่กำหนด

คุณมีโอกาสเจอปัญหานี้มากกว่าเมื่อทำ federation เข้าสู่ผู้ให้บริการคลาวด์ มากกว่ากรณีที่อยู่ภายในผู้ให้บริการนั้นเอง ผมเพิ่งทดสอบใน AWS และสูญเสียการเข้าถึงในเซสชันที่เปิดอยู่ค่อนข้างเร็วหลังลบผู้ใช้ IAM อย่างไรก็ตาม ผลลัพธ์เดียวกันไม่จำเป็นต้องเกิดขึ้นเมื่อทำ federation เข้ามาจาก identity provider ภายนอก และแม้แต่ภายใน AWS เอง บางบริการก็ไม่ตรวจสอบ credential ซ้ำระหว่างที่เซสชันยังทำงานอยู่ (เช่น เซสชัน Session Manager ของผมยังใช้งานได้อีกราว 15 นาทีขึ้นไปหลังจากลบ role ที่ให้สิทธิ์เข้าถึงไปแล้ว)

นี่ไม่ใช่ช่องโหว่ใหญ่ที่ไม่มีใครรู้จัก แต่เป็นสิ่งที่ควรคำนึงถึงเมื่อออกแบบมาตรการควบคุมความปลอดภัยบนคลาวด์และ playbook สำหรับ incident response ของคุณ credential แต่ละประเภทมีอายุการใช้งานต่างกัน ทั้งระหว่างผู้ให้บริการคลาวด์และภายในผู้ให้บริการรายเดียวกัน identity provider ของคุณก็เป็นอีกปัจจัยหนึ่ง รวมถึงจุดที่คุณพยายามเพิกถอน credential ด้วย ตัวอย่างเช่น หากคุณมีผู้ใช้ใน Active Directory ที่ทำ federation เข้าสู่ AWS และผู้ใช้นั้น assume role ใน AWS แล้วรับ session credential ของ role ดังกล่าว คุณจำเป็นต้องเพิกถอนหรือจำกัด credential ของ assumed role นั้นด้วย แม้ว่าคุณจะจำกัดสิทธิ์ผู้ใช้ใน AD แล้วก็ตาม AWS จะไม่รับรู้เลยว่าเซสชันของผู้ใช้จาก AD ใช้ไม่ได้แล้ว จนกว่าจะถึงปลายเซสชันเมื่อระบบกลับไปตรวจสอบ authentication ซ้ำ

ภายในองค์กรของเราเอง เราเปลี่ยนมาใช้เครื่องมือ Authorization Control ของเรา ซึ่งรองรับการสร้างเซสชันพร้อมข้อจำกัดผ่าน ChatOps โดยไม่เพิ่มความยุ่งยากที่อาจทำให้นักพัฒนาของเราทำงานช้าลง แม้จะยังไม่เปิดให้ใช้งานทั่วไป แต่หากคุณสนใจทดลองใช้ในช่วง early access เพียงส่งอีเมลถึงผมโดยตรงที่ rich.mogull@firemon.com.