Principle of Least Privilege, Explained

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

ความหมายจริง ๆ

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

นี่ใช้ได้ทุกชั้น: สิทธิ์ระบบไฟล์ บทบาทฐานข้อมูล API scopes นโยบาย cloud IAM กฎ firewall การเข้าใช้ sudo บริการ web ที่อ่านไฟล์คงที่ไม่จำเป็นต้องมีสิทธิ์เขียน /etc สคริปต์รายงานที่เรียกใช้เฉพาะ SELECT queries ไม่จำเป็นต้องมีบทบาทฐานข้อมูลที่มีสิทธิ์ DROP TABLE นักศึกษาฝึกงานการตลาดไม่จำเป็นต้องเป็น domain admin เพราะมันง่ายกว่าการคิดหาคณะที่ถูกต้อง

เหตุผลที่สำคัญมากกว่าเสียงดู

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

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

สถานที่ที่มันปรากฏในทางปฏิบัติ

Cloud IAM. AWS Azure และ GCP ทั้งหมดตั้งค่าเป็นพฤติกรรมแบบอนุญาตโดยค่าเริ่มต้นหากคุณไม่ระมัดระวัง — นโยบาย IAM ที่มี "Action": "*" และ "Resource": "*" จะผ่านการตรวจสอบและทำงานได้ดี จนกระทั่ง access key ที่รั่วไหลมอบสิทธิ์ควบคุมบัญชีทั้งหมดให้กับผู้โจมตี กำหนดนโยบายให้กับการกระทำเฉพาะและ resource ARNs แทนที่จะใช้ wildcards

Service accounts. สิ่งเหล่านี้มักเป็นผู้ก่ออาชญากรรมที่แย่ที่สุดเพราะไม่มีใครตรวจสอบพวกเขาเช่นที่พวกเขาตรวจสอบบัญชีมนุษย์ CI/CD pipeline ที่ปรับใช้ไปยังหนึ่ง S3 bucket ไม่ควรเก็บข้อมูลประจำตัวที่สามารถอ่าน bucket ทุกตัวในบัญชี

Database roles. แยก read-only reporting roles ออกจาก application roles ที่ต้องการ INSERT/UPDATE และแยกสิ่งเหล่านั้นออกจาก DBA role ที่สามารถเปลี่ยนแปลง schema PostgreSQL และ MySQL ทั้งคู่รองรับ GRANT statements ที่มีรายละเอียด — ใช้แทนการให้การเชื่อมต่อแอปทุกตัวเทียบเท่าของ root

Sudo and local admin. Just-in-time elevation (ขออนุญาต ได้รับในช่วงเวลาจำกัด สูญหายโดยอัตโนมัติ) เอาชนะสิทธิ์ admin ที่ยืนอยู่ได้ทุกครั้ง เครื่องมือเช่น sudo พร้อมกฎที่มีระยะเวลาจำกัด หรือ PAM solutions ในสภาพแวดล้อมองค์กร มีอยู่เพื่อจุดประสงค์นี้เท่านั้น

ความตึงเครียดกับ