ว่าด้วย Least Privilege, JIT และ Strong Authorization

ผมทำงานสายความปลอดภัยมากว่า 20 ปี และคงนับไม่ถ้วนว่าเอ่ยคำว่า “least privilege” ไปกี่ครั้ง มันกลายเป็นเหมือนคาถาประจำตัว อยู่กลุ่มเดียวกับ “defense in depth” และ “insider threat”

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

least privilege เป็นเรื่องจริงจังและสำคัญ ต่างจากการบังคับเปลี่ยนรหัสผ่านทุก 90 วัน เพราะมันส่งผลอย่างเป็นรูปธรรมต่อการยกระดับความปลอดภัยของคุณ

แต่ least privilege ก็ยากมากเช่นกัน โดยเฉพาะเมื่อต้องทำในระดับสเกลใหญ่ และมันใช้ไม่ได้ผลกับผู้ใช้ที่สำคัญที่สุดของคุณ

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

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

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

เช่นเดียวกับที่เรามี MFA สำหรับ strong authentication เราก็ต้องมีบางอย่างสำหรับstrong authorization

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

ผมแนะนำว่า least privilege เป็นแนวคิดที่ยอดเยี่ยมสำหรับการเข้าถึงของผู้ใช้ทั่วไป แต่ JIT เหมาะกว่าสำหรับการเข้าถึงระดับ admin/dev หรือการเข้าถึงที่อ่อนไหวทุกระดับบนคลาวด์

Just in Time

JIT คือรูปแบบหนึ่งของ PIM/PAM โดย Privileged Access Management และ Privileged Identity Management คือระบบที่ออกแบบมาเพื่อยกระดับสิทธิ์ของผู้ใช้ ผู้ใช้จะทำงานด้วยสิทธิ์ระดับต่ำจนกว่าจะต้องยกระดับ และระบบเหล่านี้ใช้หลายเทคนิคในการให้สิทธิ์เพิ่มเติม โดยทั่วไปเป็นเซสชันแบบจำกัดเวลา วันนี้คงไม่ใช่วันที่จะลงรายละเอียดปลีกย่อย แต่ข้อดีคือระบบเหล่านี้ให้ความยืดหยุ่นโดยยังคงรักษาความปลอดภัยไว้ได้ ผู้ใช้ต้องร้องขอสิทธิ์เพิ่มเติมเมื่อจำเป็น ดังนั้นแม้ credential จะถูกเจาะ ผู้โจมตีก็ยังถูกจำกัดขอบเขตอยู่ดี

“JIT” (Just in Time) เป็นหนึ่งในเทคนิคสำหรับ PAM/PIM (หรือจริง ๆ แล้วการเข้าถึงรูปแบบใดก็ได้) ผู้ใช้มี credential พื้นฐานที่อาจไม่มีสิทธิ์เข้าถึงอะไรเลย จากนั้นสิทธิ์จะถูกยกระดับเมื่อมีการร้องขอ เราเองก็ใช้ JIT (และมีให้ใช้งานในCloud Defense) และ Netflix ได้เปิดตัวเครื่องมือโอเพนซอร์สชื่อ ConsoleMe ซึ่งพัฒนาจากเครื่องมือภายในของตนเอง ส่วน Azure มีบริการในตัว (แต่มีค่าใช้จ่ายเพิ่มเติม) ชื่อ Entra ID Privileged Identity Management (Entra ID คือสิ่งที่เราเคยเรียกว่า Azure AD ก่อนที่จะมีใครบางคนตัดสินใจว่าการสร้างความสับสนให้ลูกค้าหลายล้านรายเพื่อเหตุผลด้านแบรนด์เป็นความคิดที่ดี) ยังมีตัวเลือกอื่นอีกมาก เหล่านี้เป็นเพียงตัวอย่าง

เพื่อเพิ่มความปลอดภัย JIT ต้องใช้ขั้นตอนอนุมัติแบบ out-of-band และให้สิทธิ์แบบจำกัดเวลา นี่คือพื้นฐาน การร้องขอและการอนุมัติควรวิ่งผ่านเส้นทางที่ต่างจากการยืนยันตัวตนปกติ คล้ายกับรูปแบบหนึ่งของ MFA ความแตกต่างคือ MFA เป็นปัจจัย out of band สำหรับการยืนยันตัวตน (พิสูจน์ว่าคุณคือคนที่คุณอ้างว่าเป็น) ส่วน JIT เป็นรูปแบบหนึ่งของการให้สิทธิ์ (คุณร้องขอและได้รับอนุญาตให้ทำบางอย่าง)

การบริหารจัดการแรงเสียดทาน

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

จากการใช้งานและศึกษาทั้ง least privilege และ JIT มาเป็นเวลานาน ผมได้เรียนรู้เทคนิคในการลดแรงเสียดทาน และในบางกรณีคุณจะได้กระบวนการที่เร็วขึ้นและดีขึ้นกว่าวิธีที่เราเคยทำกันมา

• ขั้นตอนการร้องขอและอนุมัติต้องเกิดขึ้นแบบเรียลไทม์ นั่นหมายถึงการอนุมัติผ่าน ChatOps ข้อความ หรือชิป 5G ที่ฝังมากับวัคซีนโควิดของคุณ
• สำหรับการเข้าถึงที่มีสิทธิ์ต่ำ เช่น การอ่าน log บางประเภท คุณสามารถและควรรองรับการอนุมัติด้วยตนเอง ทำไมจึงช่วยได้ เพราะยังคงใช้กระบวนการ out of band และลดโอกาสที่ผู้โจมตีจะใช้ประโยชน์จาก credential ที่สูญหาย ถูกขโมย หรือรั่วไหล
• คุณยังสามารถรองรับการอนุมัติอัตโนมัติ ซึ่งไม่ต้องกดอนุมัติเองด้วยซ้ำ ทำไมจึงช่วยได้ เพราะคุณอนุมัติอัตโนมัติได้ แต่ยังใช้ช่องทาง out of band แจ้งเตือนว่ามีการยกระดับสิทธิ์เกิดขึ้น คุณน่าจะเคยเห็นรูปแบบนี้เวลาเพิ่มอุปกรณ์ใหม่เข้าบัญชี Netflix หรือ Hulu แค่การรับรู้อย่างเดียวก็ได้ผลอย่างน่าทึ่งแล้ว
• หากทำเพื่อนักพัฒนา คุณต้องรองรับ command line และเครื่องมืออื่นที่พวกเขาใช้ จงเข้าไปหาพวกเขา ทำให้ใช้งานง่ายที่สุด หากคุณบังคับให้พวกเขาต้องล็อกอินเข้าเครื่องมือด้านความปลอดภัย โครงการนั้นจะล้มเหลว
• หากผู้อนุมัติไม่ตอบสนองทันที คุณจะล้มเหลว อย่าให้ Bob เป็นผู้อนุมัติเพียงคนเดียว

นำความสามารถนี้ไปไว้ในเครื่องมือที่ทีม dev/admin ของคุณใช้อยู่แล้ว ทำให้เร็วและไร้แรงเสียดทาน ในอุดมคติควรง่ายและเร็วกว่าการเปิด password manager หรือคลิกหาใน SSO portal ที่ยัดบัญชีคลาวด์ไว้ให้เลือกถึง 374 บัญชี แล้วก็ซื้อคุกกี้ให้ Bob สักหน่อย แบบช็อกโกแลตชิป (เดี๋ยวนะ นั่นมันผมเอง)

คุณยังใช้ระบบอัตโนมัติเพื่อลดแรงเสียดทานของการเข้าถึงแบบ least privilege ได้ด้วย Duckbill Group ได้สร้างระบบ least privilege อัตโนมัติในเวอร์ชันของตนเองด้วยเทคโนโลยีที่ต่างออกไป โดยมี Chris Farris ช่วยสนับสนุน เครื่องมืออย่าง AWS Access Advisor มีไว้ช่วยคุณตรวจสอบสิทธิ์ที่ถูกใช้งานจริงและลดขอบเขตลง ส่วนระบบอัตโนมัติมีไว้ช่วยคุณนำ least privilege ไปใช้ในระดับสเกลใหญ่ และยังใช้เสริมกับ JIT ได้อีกด้วย

ควรเลือกใช้แบบไหนเมื่อใด

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

• สิทธิ์อ่านข้อมูลใน production ของนักพัฒนา
• สิทธิ์เปลี่ยนแปลง production ของนักพัฒนา (นอกเหนือจาก CI/CD) ซึ่งจำกัดเข้มงวดกว่ามากและต้องการผู้อนุมัติหลายคน
• สิทธิ์ admin สำหรับบัญชี production
• สิทธิ์เข้าถึงสำหรับการตอบสนองต่อเหตุการณ์
• สิทธิ์เข้าถึงบัญชี dev บางส่วน เพราะเร็วกว่าการย้อนกลับไปที่ SSO portal โดยเฉพาะเมื่อทำงานผ่าน command line

ผมไม่เชื่อแล้วว่า least privilege เพียงลำพังเป็นแนวคิดที่ใช้ได้กับการเข้าถึงที่มีสิทธิ์สูงในระดับที่มีนัยสำคัญบนคลาวด์ (IaaS/PaaS) แม้เราจะใช้ MFA ที่แข็งแกร่งก็ตาม เพราะการกำหนดขอบเขตสิทธิ์ให้เหมาะสมในระดับสเกลใหญ่และคงไว้ตลอดเวลานั้นยากเกินไป JIT เป็นทางเลือกที่ดีกว่ามากในกรณีการใช้งานเหล่านี้ ส่วน least privilege ยังใช้ได้ดีเมื่อจำเป็นต้องมีสิทธิ์ที่คงที่ต่อเนื่อง โดยเฉพาะเมื่อผนวกกับการบันทึก log การเข้าถึงที่ดีและ MFA JIT คือคู่หูของ MFA มันคือstrong authorization ที่จับคู่กับ strong authentication ของคุณ และเมื่อเรายังคงย้ายงานสำคัญเข้าสู่ management plane ที่เปิดออกสู่อินเทอร์เน็ตมากขึ้นเรื่อย ๆ JIT คือคำตอบ