Czy sys.sql_logins.is_policy_checked oznacza, że ​​polityka została sprawdzona?

Kiedy zaglądam do sys.sql_loginsśrodka, widzę kolumnę o nazwie is_policy_checked. Czy mogę ufać, że moja polityka haseł została sprawdzona dla wszystkich loginów, w których znajduje się ta wartość kolumny 1?

Nie.

Chociaż dokumentacja zawiera obecnie prawdopodobnie dwuznaczne stwierdzenie na temat znaczenia tej flagi:

Polityka haseł jest sprawdzana.

To, co naprawdę oznacza i powinno powiedzieć, to, że flaga służy dwóm celom:

1. Zasady haseł mogły zostać sprawdzone, ale tylko wtedy, gdy (a) zasady haseł były włączone w momencie ostatniego ustawiania hasła, i (b) hasło zostało określone zwykłym tekstem (bez skrótu).
2. Zasady haseł zostaną sprawdzone przy następnym ustawieniu zasad, ale tylko wtedy, gdy (a) zasady haseł zostaną włączone w tym czasie i (b) hasło zostanie określone w postaci zwykłego tekstu (bez skrótu).

(I zauważ, że „zasada” odnosi się również do wymuszania wygaśnięcia i faktu, że użytkownik musi zmienić hasło przy następnym logowaniu, ale ponieważ złożoność jest zwykle przedmiotem operacji kontrolnych, skupię się tylko na tym aspekcie. )

is_policy_checkedBit jest ustawiony 1, jeśli CHECK_POLICY = ONpodczas CREATE LOGINlub ALTER LOGINwydarzenia, nawet jeśli polityka nie jest sprawdzany w czasie. Jak zapewne można zebrać z góry, ta kontrola nie występuje w następujących scenariuszach:

• Hasło jest określane za pomocą HASHEDsłowa kluczowego (bardzo powszechna taktyka podczas migracji loginów między serwerami lub kopiowania loginów do logów wysyłanych / dublowanych / AG drugorzędnych). Oczywiście nie jest możliwe sprawdzenie złożoności hasła, jeśli nie masz wstępnie zakodowanej wartości.
• Lokalne zasady złożoności haseł nie są włączone w momencie wystąpienia zdarzenia.
• Nie zostało to uwzględnione w moim proponowanym przeredagowaniu powyżej, ale możesz to zrobić ALTER LOGINbez ustawiania nowego hasła i nadal zmieniać flagę ( dzięki @AMtwo za zilustrowanie tego ). Podejrzewam, że mogły to zrobić sprytni ludzie próbujący oszukać audytora.

Wszystkie te problemy można łatwo wykazać.

Ponieważ większość osób, z którymi rozmawiałem na ten temat, zawsze zakładało, że is_policy_checkedfaktycznie oznacza to, że bieżące hasło jest zgodne z obecną polityką haseł, myślę, że ważne jest, aby coś się tutaj zmieniło, aby użytkownicy mieli odpowiednie oczekiwania i zrozumieli, że ta flaga niekoniecznie oznacza wszystko dobrze. Dokumentacja powinna przynajmniej zostać zaktualizowana, aby odzwierciedlić rzeczywistość, podobnie jak wskazałem powyżej. Ale są też inne rzeczy, które można zrobić.

• Można podać ostrzeżenie, jeśli CHECK_POLICY = ONjest określone, ale zasady nie można w rzeczywistości sprawdzić (albo dlatego, że hasło zostało określone za pomocą skrótu, albo dlatego, że zasada hasła została wyłączona, lub ponieważ polecenie jest prostą próbą obejścia lub ustaw flagę, np ALTER LOGIN blat WITH CHECK_POLICY = ON;.).
• CHECK_POLICYmoże być przestarzałe, na korzyść ACTIVELY_CHECK_POLICYi być może CHECK_POLICY_ON_NEXT_CHANGE. Kolumny w sys.sql_loginspowinny być policy_has_been_checkedi policy_will_be_checked. Nie jestem żonaty z tymi nazwiskami, ale są one o wiele dokładniejsze niż obecne sformułowanie.
• Jeśli wybiorę, ACTIVELY_CHECK_POLICY = ONa zasady nie będzie można sprawdzić podczas wykonywania polecenia, powinienem otrzymać komunikat o błędzie, a flaga nie powinna być ustawiona na 1(lub nawet tworzenie logowania lub zmiana hasła nie powinny się powieść).
• Nie sądzę, aby w tym przypadku miało sens kontynuowanie obecnego zachowania, w którym mogę określić, że chcę sprawdzić zasady, ale nawet jeśli nie, hasło jest dozwolone, a login jest tworzony / zmieniany (jest to złe, IMHO, niezależnie od stanu flagi po fakcie - ale przynajmniej jeśli byłoby ustawione 0, takie bypassy mogłyby zostać zidentyfikowane).

Obecnie nie ma niezawodnego sposobu - bez ręcznej zmiany haseł na coś, co wiesz, że jest bezpieczne - do audytu twoich loginów SQL i upewnienia się, że wszystkie spełniają twoje zasady złożoności. W dobie coraz większej ilości danych, coraz większej liczby naruszeń danych i oczywistej potrzeby coraz mocniejszego zabezpieczania systemów, jest to problem, którym należy się zająć. Napisałem o tym na blogu i utworzyłem na ten temat element Connect:

• Pomóż mi naprawić poważną lukę w zabezpieczeniach
• Connect # 1250342: CHECK_POLICY to brak operacji z CREATE LOGIN ... HASŁO ... HASHED

Zachęcam do głosowania na element Connect i, co ważniejsze, upewnij się, że nie kontrolujesz swoich systemów pod kątem fałszywych poglądów na temat działania tej opcji DDL i metadanych.

Proszę nie odsuwać tego na bok jako „bez problemu”, ponieważ doskonale czujesz się z jego działaniem i już wiesz, że flagi nie można ufać - nie jesteś użytkownikiem, o którego się martwię; to wszyscy inni.