Cho phép người dùng Quản trị viên đăng nhập như những người dùng khác

11

Bạn có nghĩ rằng đó là một cách thực hành tốt để thực hiện một khả năng cho phép người dùng quản trị viên đăng nhập như một người dùng khác, bằng cách chuyển mật khẩu? Điều này có thể được thực hiện bằng mật khẩu chính hoặc một chức năng trong quản trị người dùng, "Đăng nhập với tư cách người dùng này".

Các quản trị viên đang yêu cầu một chức năng như vậy để có thể cố gắng tái tạo một vấn đề được báo cáo hoặc để kiểm tra xem các khoản tài trợ có ổn không, chẳng hạn.

security problem-solving

— Dan McGrath
nguồn

9

Nói chung, kỹ thuật bảo mật không cho phép mọi người đăng nhập như một tài khoản dùng chung (hoặc tài khoản của người khác, cho vấn đề đó) ngay cả khi quyền của họ giống hệt nhau. Xác thực phải là một quá trình riêng biệt từ ủy quyền. Nếu các tác vụ được thực hiện dưới các tài khoản người dùng riêng biệt, họ chịu trách nhiệm về nó.

— xmm0

1

+1 cho Mehrdad Afshari. Tôi co rúm mỗi khi nghe mọi người nói về admin như thế này.

— Dan McGrath

2

@Mehrdad Afshari và @Dan McG, điều đó hoàn toàn tốt và đúng, nhưng bạn đề xuất làm gì khi quản trị viên cần truy cập vào tài khoản người dùng trong tình huống hàng ngày? Hỏi người dùng để nhập thông tin đăng nhập của họ? Điều này xảy ra rất thường xuyên là để xác minh hoặc tái tạo sự cố, bạn cần kiểm tra các cài đặt cụ thể của người dùng, đặc biệt khi các tài khoản được gắn với các quyền phức tạp và các cài đặt khác không thể được sao chép 1: 1 bằng tài khoản trung lập.

— Pekka

4

Nhìn bạn sai cách. Nếu quản trị viên cần kiểm tra cài đặt người dùng, chúng tôi cần phát triển các công cụ tốt hơn để có được thông tin chẩn đoán này từ người dùng. Ví dụ: Nếu ứng dụng trên windows của bạn gặp sự cố, bạn có muốn một số quản trị viên MS trong Redmond RDPing vào tài khoản người dùng của bạn để kiểm tra nội dung không, hoặc bạn có muốn một phương thức tự động cao gửi lại thông tin cần thiết cho họ (theo quyết định của người dùng) ?

— Dan McGrath

2

@Dan: Khách hàng có thể không sẵn sàng trả tiền cho điều đó.

15

Không hoàn toàn không. Điều này vi phạm sự phân biệt nhiệm vụ.

Nó cũng gây ra sự tàn phá dựa vào nhật ký để hiển thị hành động của người dùng.

Nếu bạn thực sự cần kiểm tra những thứ như thế này, quản trị viên cũng nên có một tài khoản kiểm tra giả được thiết lập giống như người dùng. Bằng cách này, họ có thể xác nhận các khoản tài trợ, vv hoạt động chính xác trên người dùng thử trước tiên.

Ngoài ra, người dùng quản trị không nên luôn luôn được cung cấp tất cả các quyền mà người dùng có. Ví dụ: người dùng có thể có lý do hợp lệ để xem số thẻ tín dụng trong hệ thống. Một quản trị viên không nên; dữ liệu này không phải là một phần công việc của họ. Một lần nữa, điều này đi xuống để phân biệt nhiệm vụ.

Giảm thiểu tiếp xúc của bạn bằng cách giảm thiểu cấp quyền không phù hợp. Điều này cũng bao gồm quản trị viên ...

— Dan McGrath
nguồn

1

Mặc dù bạn có điểm hợp lệ, tôi không nghĩ câu trả lời khá rõ ràng - trong một số trường hợp, đó là giải pháp tốt nhất.

— sleske

11

Từ quan điểm nguyên tắc lập trình bảo mật và sạch sẽ, đó không phải là một ý tưởng tốt. Nhưng nó có thể là một thuận tiện lớn trong công việc hàng ngày cho quản trị viên, đó là lý do tại sao tôi cho nó nếu được thực hiện tốt.

Đối với tôi, một triển khai ok sẽ phải đáp ứng các yêu cầu sau:

Hệ thống đăng nhập bạn với tư cách là người dùng được đề cập, nhưng bỏ qua xác thực mật khẩu nếu bạn đăng nhập với tư cách quản trị viên.
Hệ thống nhận biết thông qua một cờ rằng đây không phải là người dùng x, mà là quản trị viên đăng nhập với tên người dùng x. Bất kỳ cơ sở khai thác sẽ phản ánh sự khác biệt.
Không có cách nào để "thoát ra" từ người dùng đăng nhập trở lại cấp quản trị viên.

Điều này thực sự có thể cải thiện bảo mật vì quản trị viên không phải tra cứu và sử dụng thông tin đăng nhập của người dùng, thực tế thường là vì lý do OP đề cập: Phải kiểm tra, kiểm tra, v.v. trên tài khoản của người dùng .

— Bắc Kinh
nguồn

8

Như mọi khi ... nó phụ thuộc. Không có câu trả lời dễ dàng và cả hai hệ thống đều được sử dụng trong thực tế (ví dụ: Windows: Quản trị viên không thể đăng nhập với tư cách người dùng mà không cần đặt lại mật khẩu so với Linux: Quản trị viên có thể đăng nhập với tư cách người dùng cục bộ bằng cách sử dụng su).

Rõ ràng, không cho phép quản trị viên đăng nhập với tư cách người dùng khác là tùy chọn an toàn hơn, do đó bạn phải quyết định xem sự thoải mái bổ sung (có thể gỡ lỗi các sự cố chỉ xảy ra đối với một người dùng nhất định) có vượt quá rủi ro hay không. Nếu bạn quyết định thực hiện một tùy chọn như vậy, hãy đảm bảo rằng có ghi nhật ký nghiêm ngặt, để quản trị viên (hoặc ai đó đã giữ mật khẩu quản trị viên) không thể ẩn dấu vết của mình.

Ngoài ra, bạn có thể sử dụng mẫu mà Windows đang sử dụng: Quản trị viên không thể đăng nhập với tư cách người dùng khác, nhưng quản trị viên có thể đặt lại mật khẩu của người dùng. Bằng cách đó, quản trị viên có thể có quyền truy cập, nhưng người dùng sẽ luôn biết rằng ai đó đã truy cập vào tài khoản của mình.

— Heinzi
nguồn

Nitpick: sudokhông đăng nhập bạn với tư cách là người dùng cục bộ, nó chỉ chạy một quy trình với tư cách là người dùng ("Chạy như người dùng" của Window). Để đăng nhập như một người dùng cục bộ, sử dụng su. Nếu không, tôi đồng ý.

— sleske

@sleske: Tất nhiên, cảm ơn vì đã phát hiện ra điều này. Đã sửa.

@sleske: không nhất thiết, nhìn vào sudo -i.

— liori

Ý tưởng về 'shell đăng nhập' có liên quan nhiều hơn đến cách shhành xử của người thực thi hơn là với quyền được cấp. su - uservà sudo -u user shcấp quyền truy cập tương tự; sự khác biệt là shchạy các kịch bản khởi động khác nhau.

— jpaugh

3

Chà, phpBB3 có chức năng "Kiểm tra quyền của người dùng" đối với quản trị viên, điều này thực sự hữu ích. Ngoài ra, nó không thực sự cho phép bạn can thiệp vào tài khoản người dùng đó mà thực sự chỉ cần có được trải nghiệm họ có, dựa trên quyền của họ.

Nhưng thực sự đăng nhập như một người khác đi kèm với một số vấn đề, như những người khác đã đề cập.

— back2dos
nguồn

1

Vâng, một chức năng như vậy có thể có vấn đề, nhưng đôi khi không có cách nào khác, vì vậy nó có thể là cần thiết.

Vài ví dụ:

Trên Unix / Linux, chức năng này tồn tại ( su - <username>, cho kết quả tương tự như đăng nhập với người dùng đó, nhưng không yêu cầu mật khẩu cho root)
ứng dụng tôi làm việc cũng có ứng dụng này và nó rất cần thiết để gỡ lỗi các cài đặt cá nhân của người dùng (trong đó ứng dụng của chúng tôi có nhiều)

Như đã chỉ ra, nếu các cài đặt phức tạp phụ thuộc vào người dùng đã đăng nhập (vars môi trường, đường dẫn, cài đặt cá nhân trong một ứng dụng) thì thường không có cách thực tế nào khác để gỡ lỗi cho người dùng.

Đối với đăng nhập / kiểm toán: Tất nhiên sử dụng chức năng này nên được ghi lại. Ngoài ra, bạn sẽ phải tin tưởng quản trị viên của mình không lạm dụng nó. Nhưng đó là hợp lệ cho quản trị viên nói chung.

Nếu bạn cần hạn chế quản trị viên của mình nhiều hơn, bạn cần một số loại hệ thống MAC (kiểm soát truy cập bắt buộc), quản trị viên "đúng". Điều đó là có thể, nhưng phức tạp hơn nhiều, vì vậy đó là một sự đánh đổi.

— sleske
nguồn