Rủi ro của Đoàn Kerberos

Tôi đã dành hàng giờ đồng hồ để cố gắng tìm hiểu và hiểu về Xác thực Windows, Kerberos, SPN và Phân quyền bị ràng buộc trong IIS 7.5. Một điều tôi không nhận được là tại sao "rủi ro" khi cho phép ủy quyền được kích hoạt (nghĩa là không vô hiệu hóa ủy quyền cho các tài khoản nhạy cảm) cho Quản trị viên, Giám đốc điều hành, v.v. Vui lòng đóng khung câu trả lời của bạn đối với môi trường mạng nội bộ.

Lý do của tôi là nó không phải là một mối quan tâm, bởi vì ủy quyền chỉ đơn giản cho phép một máy chủ web mặt trước, ví dụ, hành động thay mặt cho người được xác thực Windows khi giao tiếp với các máy chủ khác. Nếu người đó có quyền truy cập, họ có quyền truy cập, tôi không hiểu tại sao điều này nên là một mối quan tâm.

Xin hãy tha thứ cho sự thiếu hiểu biết của tôi. Tôi chủ yếu là một nhà phát triển, nhưng công ty của tôi đang hoạt động rất gầy trong những ngày này và tôi buộc phải đội chiếc mũ quản trị máy chủ ... thật không may, nó vẫn không phù hợp lắm, lol.

Hai ví dụ:

1. Phân quyền hạn chế cho phép mạo danh mà không cần thông tin xác thực hoặc mã xác thực của người dùng. Ví dụ, xem câu trả lời này .

2. Trong một kịch bản ủy nhiệm không ràng buộc thịt và khoai tây điển hình hơn, cho dù đó là xác thực tích hợp cửa sổ hoặc xác thực mẫu, có quyền truy cập ủy quyền vào mã thông báo xác thực của người dùng là rất mạnh mẽ. Điều đó có nghĩa là mã thông báo có thể được sử dụng để mạo danh người dùng đó để truy cập bất kỳ tài nguyên mạng nào. Bất cứ ai tham gia vào quá trình đó, chẳng hạn như một nhà phát triển, đều có thể sử dụng điều đó một cách bất chính để có được quyền truy cập trái phép.

Trong cả hai ví dụ, nếu hộp được chọn cho "tài khoản nhạy cảm và không thể ủy thác" thì đây không phải là vấn đề bảo mật. Cũng có thể kiến ​​trúc một hệ thống / tính năng nơi các khả năng này tồn tại, nhưng được kiểm soát chặt chẽ.

Hộp đó phải được kiểm tra cho các tài khoản quản trị, chẳng hạn như các thành viên của nhóm Quản trị viên doanh nghiệp, bởi vì (hy vọng) những tài khoản đó hiếm khi cần sử dụng các ứng dụng yêu cầu mạo danh. Nó cũng là một ý tưởng tốt cho các giám đốc điều hành cấp cao có quyền truy cập vào thông tin nhạy cảm, chẳng hạn như CIO, COO, người đứng đầu Tài chính / Kho bạc, v.v.

Vì vậy, điểm mấu chốt là, Microsoft đã cung cấp hộp kiểm đó và cảnh báo kèm theo vì một lý do rất chính đáng và không nên bỏ qua hoặc xem nhẹ trừ khi có thể chứng minh rằng một kịch bản cụ thể không có rủi ro không mong muốn hoặc kiểm soát bù trừ. Điều này thường liên quan đến việc kiểm tra bởi một số người đủ điều kiện không liên quan đến việc triển khai hoặc phát triển thực tế của một ứng dụng hoặc hệ thống.

Tôi đã thiết lập 1000 khách hàng với hầu hết các nhóm không bị ràng buộc. Tôi nghĩ điều quan trọng cần lưu ý là nếu bạn không tin tưởng vào ứng dụng của mình (giả sử đã triển khai trên IIS) hoặc bạn đang cung cấp thông tin tài khoản dịch vụ được ủy quyền của chúng tôi cho người khác sử dụng một cách tự do, thì ủy quyền bị hạn chế có lẽ là một ý tưởng tốt. Tuy nhiên, nếu bạn không mong đợi bất kỳ ai có khả năng viết lại ứng dụng của mình, bạn sẽ giữ thông tin đăng nhập tài khoản dịch vụ của mình an toàn và bạn tin rằng các ứng dụng của bạn sẽ chỉ ủy quyền cho (các) dịch vụ mà chúng được thiết kế cho, sau đó thường không có gì phải lo lắng. Tôi đã thấy một số khách hàng "có ý thức bảo mật" tập trung rất nhiều vào các vấn đề như thế này trong khi tài nguyên của họ có thể được chi tiêu tốt hơn khi làm việc với các mối đe dọa bảo mật thực sự ...