Ý nghĩa về bảo mật và hiệu suất của Chế độ xem máy chủ của Bang View


13

Câu hỏi này chỉ ra rằng phải có quyền "Trạng thái máy chủ" đối với nhiều DMV (chế độ xem quản lý động) khác nhau, nhưng tôi không thể tìm thấy bất cứ điều gì về những người bạn làm và không muốn cấp quyền cho.

Bây giờ tất nhiên tôi hiểu "quyền hạn tối thiểu" và tại sao bạn không muốn cấp nó cho bất kỳ ai, nhưng tôi không thể tìm thấy bất kỳ hướng dẫn nào về cách đánh giá liệu nó có nên được cấp hay không.

Vì vậy, câu hỏi của tôi: ý nghĩa bảo mật và hiệu suất của việc cấp quyền cho người dùng "Xem trạng thái máy chủ" là gì. Họ có thể làm gì mà có lẽ họ không được phép làm ...

Cập nhật : một hàm ý là người dùng sẽ có thể sử dụng DMV để xem xét các truy vấn. Nếu các truy vấn hoặc tham số truy vấn có thể chứa thông tin bí mật mà người dùng không thể nhìn thấy, thì cho phép VIEW SERVER STATE sẽ cho phép họ làm như vậy (ví dụ dob = hoặc ssn =).

Câu trả lời:


5

Không có vấn đề hiệu suất đáng kể nào mà tôi có thể nghĩ đến từ việc cấp quyền này. Từ góc độ bảo mật, bạn có nguy cơ cho phép người dùng thấy những gì bạn biết chi tiết nhất về các điểm yếu của mình, vì vậy, ví dụ, người dùng độc hại có thể xem các số liệu thống kê chờ phổ biến nhất của bạn, điều này có thể giúp họ nhắm mục tiêu tấn công DoS vào máy chủ của bạn .

Điều này có thể không? Chắc chắn rồi. Đây có phải là khả năng? Tôi buộc phải nói Không, nhưng hãy nhớ rằng ước tính 90% các cuộc tấn công chống lại các công ty là từ những kẻ tấn công nội bộ.


3

Là quản trị viên, bạn sẽ xem thông tin này như trong miền của mình (hiệu suất / chỉ số sử dụng / v.v.) nhưng có những lý do có khả năng thuyết phục rằng tổ chức phát triển sẽ muốn thông tin này cho một hệ thống di sản lớn mà họ hỗ trợ - xác định các bảng zombie chỉ được chạm vào bởi các quy trình bảo trì chẳng hạn.

Cuối cùng, nó luôn luôn là một vấn đề của "may mắn và hào phóng" vì lời kêu gọi liệu có bất kỳ yêu cầu cụ thể nào được kết thúc hay không là một lựa chọn mềm mại và không phải là một công thức rõ ràng. Việc sử dụng các mô hình thực hành tốt nhất mà không cần nhìn vào bối cảnh tự nó là một mô hình chống đối khá khó chịu và thực tế là nhiều người tiếp cận vị trí của họ với "nói chuyện bằng tay" như một điểm khởi đầu.


1

Về ý nghĩa hiệu suất, tôi không biết về bất kỳ sự cho phép này hay bất kỳ sự cho phép nào khác.

Về:

Họ có thể làm gì mà có lẽ họ không được phép làm

Nói một cách đơn giản, họ có thể thấy những thứ mà có lẽ họ không nên nhìn thấy. Và đừng nghĩ về điều này trong điều khoản của SQL Server. Quyền đặc biệt này cũng chi phối các DMV như sys.dm_os_sys_info và một số người khác cung cấp cái nhìn sâu sắc về máy chủ (phần cứng, dịch vụ, v.v.). Bạn không phải lúc nào cũng biết thông tin nào có thể được sử dụng chống lại bạn. Và, ngay cả khi bạn ổn với việc ai đó nhìn thấy mọi thứ được cho phép bởi quyền này, đôi khi DMV được thêm vào Gói dịch vụ / Cập nhật tích lũy, và do đó, có thể một thông tin mới bị lộ mà bạn không biết.

Tôi không thể tìm thấy bất kỳ hướng dẫn nào về cách đánh giá liệu nó NÊN được cấp hay không.

Vì bạn đã đề cập đến việc cung cấp cho mọi người các quyền tối thiểu cần thiết, điều này thực sự xuất hiện là: ai đó có cần quyền này cho việc sử dụng ad hoc không? Có nghĩa là, ai đó cần sự linh hoạt để đưa ra các truy vấn của riêng họ? Việc tạo một hoặc nhiều thủ tục được lưu trữ và / hoặc TVF đa câu lệnh có hoạt động không? Nếu vậy, thì bạn không cần cấp quyền cho bất kỳ người dùng nào (người đó miễn phí đối với mọi thứ được cho phép bởi quyền đó), và thay vào đó bạn cấp quyền cho (chỉ thực hiện những gì được mã hóa để làm). Ký mô-đun là cách bạn thực hiện điều này. Khái niệm chung là:

  1. Tạo (các) thủ tục được lưu trữ và / hoặc TVF đa câu lệnh để thực hiện (các) hành động mong muốn.
  2. Cấp EXECUTEcho các mô-đun này cho bất kỳ người dùng và / hoặc vai trò nào cần thực hiện các hành động này
  3. Tạo chứng chỉ
  4. Ký (các) mô-đun bằng chứng chỉ đó (sử dụng ADD SIGNATURE)
  5. Sao chép chứng chỉ vào [master]cơ sở dữ liệu (nghĩa là tạo chứng chỉ [master]bằng cách sử dụng khóa chung của chứng chỉ được sử dụng để ký (các) mô-đun.
  6. Tạo một đăng nhập từ chứng chỉ được sao chép vào [master]
  7. Cấp bất kỳ quyền cấp độ cá thể nào là cần thiết cho thông tin đăng nhập dựa trên chứng chỉ đó (có thể bao gồm thêm nó vào vai trò cấp độ cá thể).

Đối với một số ví dụ, vui lòng xem:


0

Đó là một vấn đề bảo mật. Bạn không bao giờ có thể sai nếu bạn tuân theo Nguyên tắc tối thiểu đặc quyền . Nói cách khác, nếu một hiệu trưởng xác thực không cần sự cho phép cụ thể, thì đừng đưa nó cho họ. Bạn có cung cấp thông tin liên quan đến loại khóa trên cửa cho người khác mà bạn không cần biết về ngôi nhà của bạn không? Tôi hy vọng không. Họ có thể sẽ không làm gì cả, nhưng nó vẫn không thận trọng.

Nếu chúng ta dựa trên các nguyên tắc dữ liệu về sự may mắn và hào phóng, chúng ta sẽ gặp rắc rối lớn hơn thường xuyên hơn một chút. Bảo mật là một khía cạnh mà bạn chỉ nên cấp khi bạn có thể bảo vệ lý do tại sao bạn cấp. Bạn chỉ đơn giản là cung cấp cho ai đó nhiều thông tin hơn họ cần biết . Đừng làm điều đó. Trạng thái máy chủ vẫn còn nhạy cảm.


1
Ai nói họ đang cho đi không cần thiết? OP có thể cần phải cấp nó cho ai đó để điều tra một vấn đề cụ thể (ví dụ để xem xét sys.dm_db_missing_index_details) và họ muốn biết chính xác những rủi ro khi làm như vậy.
Martin Smith

Tôi đoán tôi đang thiếu dấu với câu hỏi này, tôi không thấy bất cứ điều gì trong câu hỏi cho thấy sự cần thiết phải có sự cho phép.
Thomas Stringer

4
@ThomasStringer: câu hỏi không phải là về sự cần thiết, đó là về rủi ro . Để đặt nó dưới dạng tiền tệ, bạn có thể biết những rủi ro bổ sung nào sẽ khiến máy chủ của bạn gặp phải và do đó có thể nói không với một xu, và có với một triệu đô la. Tôi không, nhưng tôi muốn.
jmoreno
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.