Sys.sql_logins.is_policy_checked có nghĩa là chính sách đã được kiểm tra không?


16

Khi tôi nhìn vào sys.sql_logins, tôi thấy một cột được gọi is_policy_checked. Tôi có thể tin tưởng rằng chính sách mật khẩu của mình đã được kiểm tra cho tất cả các thông tin đăng nhập có giá trị cột này 1không?

Câu trả lời:


21

Không.

Trong khi tài liệu hiện có tuyên bố mơ hồ sau đây về ý nghĩa của lá cờ này:

Chính sách mật khẩu được kiểm tra.

Điều thực sự có nghĩa là gì, và nên nói, là cờ phục vụ hai mục đích:

  1. Chính sách mật khẩu có thể đã được kiểm tra, nhưng chỉ khi (a) chính sách mật khẩu được bật tại thời điểm mật khẩu được đặt lần cuối và (b) mật khẩu được chỉ định trong văn bản thuần túy (không phải bằng hàm băm).
  2. Chính sách mật khẩu sẽ được kiểm tra vào lần tiếp theo chính sách được đặt, nhưng chỉ khi (a) chính sách mật khẩu được bật tại thời điểm đó và (b) mật khẩu được chỉ định bằng văn bản thuần túy (không phải bằng hàm băm).

(Và lưu ý rằng "chính sách" cũng đề cập đến việc thực thi hết hạn và thực tế là người dùng phải thay đổi mật khẩu trong lần đăng nhập tiếp theo, nhưng vì sự phức tạp thường là trọng tâm của hoạt động kiểm toán, tôi sẽ chỉ tập trung vào khía cạnh đó. )

Các is_policy_checkedbit được thiết lập để 1nếu CHECK_POLICY = ONtrong một CREATE LOGINhoặc ALTER LOGINsự kiện, thậm chí nếu chính sách không được chọn vào thời điểm đó. Như bạn có thể thu thập từ trên, kiểm tra này không xảy ra trong các trường hợp sau:

  • Mật khẩu được chỉ định bằng cách sử dụng HASHEDtừ khóa (một chiến thuật rất phổ biến khi di chuyển thông tin đăng nhập giữa các máy chủ hoặc sao chép thông tin đăng nhập để đăng nhập vận chuyển / nhân đôi / AG). Rõ ràng là không thể kiểm tra độ phức tạp của mật khẩu nếu bạn không có giá trị được băm trước.
  • Chính sách phức tạp mật khẩu cục bộ không được kích hoạt tại thời điểm sự kiện xảy ra.
  • Không được đề cập trong phần viết lại đề xuất của tôi ở trên, nhưng bạn có thể ALTER LOGINkhông cần đặt mật khẩu mới và vẫn thay đổi cờ ( cảm ơn @AMtwo đã minh họa điều này ). Tôi nghi ngờ điều này có thể đã được thực hiện bởi những người thông minh đang cố gắng đánh lừa một kiểm toán viên.

Những vấn đề này đều dễ dàng để chứng minh.

Vì hầu hết mọi người tôi đã nói về điều này luôn cho rằng is_policy_checkedthực sự có nghĩa là mật khẩu hiện tại đáp ứng chính sách mật khẩu hiện tại, tôi nghĩ điều quan trọng là có gì đó thay đổi ở đây để người dùng có những kỳ vọng đúng đắn và hiểu rằng cờ này không nhất thiết phải có nghĩa tất cả đều tốt. Ít nhất, tài liệu nên được cập nhật để phản ánh thực tế, hơi giống như tôi đã chỉ ra ở trên. Nhưng có những thứ khác cũng có thể được thực hiện.

  • Một cảnh báo có thể được nêu ra nếu CHECK_POLICY = ONđược chỉ định nhưng trên thực tế, chính sách không thể được kiểm tra (vì mật khẩu được chỉ định bằng hàm băm hoặc do chính sách mật khẩu đã bị vô hiệu hóa hoặc do lệnh là một nỗ lực đơn giản để bỏ qua hoặc đặt cờ, ví dụ ALTER LOGIN blat WITH CHECK_POLICY = ON;).
  • CHECK_POLICYcó thể bị phản đối, ủng hộ ACTIVELY_CHECK_POLICYvà có lẽ CHECK_POLICY_ON_NEXT_CHANGE. Các cột trong sys.sql_loginsnên policy_has_been_checkedpolicy_will_be_checked. Tôi không kết hôn với những cái tên này, nhưng chúng chính xác hơn rất nhiều so với từ ngữ hiện tại.
  • Nếu tôi chọn ACTIVELY_CHECK_POLICY = ONvà chính sách không thể được kiểm tra trong quá trình thực thi lệnh, tôi sẽ nhận được thông báo lỗi và cờ không được đặt thành 1(hoặc thậm chí việc tạo đăng nhập hoặc thay đổi mật khẩu sẽ không thành công).
  • Tôi không nghĩ rằng trong trường hợp này sẽ tiếp tục với hành vi hiện tại, nơi tôi có thể chỉ định rằng tôi muốn kiểm tra chính sách, nhưng ngay cả khi không thể, mật khẩu được cho phép và đăng nhập được tạo / thay đổi (điều này là xấu, IMHO, bất kể trạng thái của cờ sau thực tế - nhưng ít nhất nếu nó được đặt thành 0, có thể xác định bỏ qua như vậy).

Ngày nay, không có cách nào đáng tin cậy - mà không thay đổi thủ công mật khẩu của họ thành thứ bạn biết là an toàn - để kiểm tra thông tin đăng nhập SQL của bạn và tự tin rằng tất cả chúng đều đáp ứng chính sách phức tạp của bạn. Trong thời đại dữ liệu ngày càng phát triển này, ngày càng có nhiều vi phạm dữ liệu và nhu cầu rõ ràng để bảo mật các hệ thống chặt chẽ và chặt chẽ hơn, đây là một vấn đề cần được giải quyết. Tôi đã viết blog về điều này và tạo một mục Kết nối về nó:

Tôi khuyến khích bạn bỏ phiếu cho mục Kết nối và quan trọng hơn là đảm bảo bạn không kiểm tra hệ thống của mình bằng nhận thức sai về cách tùy chọn DDL và siêu dữ liệu này hoạt động.

Xin đừng gạt điều này sang một bên là "không vấn đề" vì bạn hoàn toàn thoải mái với cách thức hoạt động của nó và đã biết rằng cờ không thể tin cậy được - bạn không phải là người dùng mà tôi lo lắng; đó là những người khác

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.