arrow_backQuay lại ghi chép lĩnh vực
BLUE TEAM Đã đăng 9 Aug 2026

Nguyên tắc Quyền truy cập tối thiểu, Giải thích

Phân tích thực tiễn về nguyên tắc quyền truy cập tối thiểu: nó có nghĩa là gì, tại sao vi phạm lan rộng mà không có nó, và cách thực hiện nó.

Quyền truy cập tối thiểu nghe có vẻ hiển nhiên khi bạn nói nó ra: chỉ cấp cho một tài khoản, quy trình, hoặc người dùng những quyền truy cập cần thiết để thực hiện công việc của họ, không có gì thêm. Khoảng cách giữa việc nói điều đó và thực sự chạy hệ thống của bạn theo cách đó là nơi hầu hết các vi phạm biến từ một sự cố nhỏ thành xâm phạm toàn bộ miền.

Nó thực sự có nghĩa là gì

Nguyên tắc quyền truy cập tối thiểu (PoLP) nói rằng mọi chủ thể trong hệ thống — một người dùng, một tài khoản dịch vụ, một ứng dụng, một container — nên hoạt động với tập hợp quyền tối thiểu cần thiết để hoàn thành chức năng của nó. Không phải những quyền mà thuận tiện. Không phải những quyền mà ai đó cấp ba năm trước và quên thu hồi. Tập hợp tối thiểu.

Điều này áp dụng ở mọi lớp: quyền hệ thống tệp, vai trò cơ sở dữ liệu, phạm vi API, chính sách IAM đám mây, quy tắc tường lửa, quyền sudo. Một quy trình máy chủ web đọc các tệp tĩnh không cần quyền ghi vào /etc. Một tập lệnh báo cáo chỉ chạy truy vấn SELECT không cần vai trò cơ sở dữ liệu với quyền DROP TABLE. Một thực tập sinh tiếp thị không cần quyền admin miền vì nó dễ dàng hơn là tìm ra nhóm đúng.

Tại sao nó quan trọng hơn nó nghe có vẻ

Khi một kẻ tấn công xâm phạm một tài khoản hoặc quy trình, họ kế thừa bất cứ điều gì mà tài khoản đó có thể làm. Nếu laptop của một nhân viên bị lừa chỉ có quyền truy cập vào các chia sẻ tệp liên quan đến nhóm của họ, bán kính tác động của cuộc lừa đó bị giới hạn. Nếu tài khoản đó xảy ra có quyền admin miền vì IT thiết lập nó theo cách đó một lần để khắc phục sự cố và không bao giờ khôi phục lại, thì kẻ tấn công bây giờ sở hữu mạng.

Đây là logic đằng sau hầu hết các báo cáo pháp y sau vi phạm: truy cập ban đầu có giá trị thấp, nhưng di chuyển bên cạnh thông qua các tài khoản có quá nhiều quyền biến nó thành ransomware trên toàn bộ môi trường. Quyền thừa không gây ra xâm phạm ban đầu, nhưng nó gần như luôn là những gì làm cho xâm phạm tốn kém.

Nơi nó xuất hiện trong thực tế

Cloud IAM. AWS, Azure, và GCP đều mặc định có hành vi cho phép nếu bạn không cẩn thận — một chính sách IAM với "Action": "*""Resource": "*" sẽ vượt qua xác thực và hoạt động tốt, cho đến khi một khóa truy cập bị rò rỉ trao cho kẻ tấn công quyền kiểm soát tài khoản đầy đủ. Giới hạn chính sách cho các hành động cụ thể và ARN tài nguyên thay vì sử dụng ký tự đại diện.

Tài khoản dịch vụ. Những cái này thường là những thủ phạm tồi tệ nhất vì không ai xem xét chúng theo cách họ xem xét các tài khoản của con người. Một đường ống CI/CD triển khai vào một nhóm S3 không nên lưu giữ thông tin xác thực có thể đọc mọi nhóm trong tài khoản.

Vai trò cơ sở dữ liệu. Tách các vai trò báo cáo chỉ đọc khỏi các vai trò ứng dụng cần INSERT/UPDATE, và tách chúng khỏi vai trò DBA có thể thay đổi lược đồ. PostgreSQL và MySQL đều hỗ trợ các câu GRANT chi tiết — sử dụng chúng thay vì cấp cho mọi kết nối ứng dụng tương đương với root.

Sudo và quyền admin cục bộ. Nâng cao just-in-time (yêu cầu quyền truy cập, nhận được cho một cửa sổ hạn chế, mất nó tự động) luôn tốt hơn quyền admin đứng. Các công cụ như sudo với quy tắc giới hạn thời gian, hoặc các giải pháp PAM trong môi trường doanh nghiệp, tồn tại đặc biệt cho mục đích này.

Căng thẳng với

Viết với hỗ trợ của AI, được xem xét và đăng bởi Michal Pilch (CISSP), Korra Studio.

Sẵn sàng đi xa hơn?

Đây là một ghi chép từ cơ sở kiến thức Korra Studio — nền tảng kết hợp mỗi chủ đề với phiên hỗ trợ 1-kèm-1.

Bắt đầu miễn phíarrow_forward