Sys.sql_logins.is_policy_checked significa che la politica è stata controllata?

Quando guardo dentro sys.sql_logins, vedo una colonna chiamata is_policy_checked. Posso fidarmi che la mia politica password è stata verificata per tutti gli accessi in cui si trova questo valore di colonna 1?

No.

Mentre la documentazione attualmente contiene la seguente affermazione discutibilmente ambigua sul significato di questo flag:

La politica password è selezionata.

Ciò che significa veramente, e dovrebbe dire, è che la bandiera ha due scopi:

1. La politica password potrebbe essere stata verificata, ma solo se (a) la politica password era abilitata al momento dell'ultima impostazione della password e (b) la password è stata specificata in testo semplice (non con un hash).
2. La politica della password verrà controllata alla successiva impostazione della politica, ma solo se (a) la politica della password è abilitata in quel momento e (b) la password è specificata in testo semplice (non con un hash).

(E nota che "la politica" si riferisce anche al rispetto della scadenza e al fatto che l'utente deve cambiare la password al prossimo accesso, ma poiché la complessità è in genere al centro delle operazioni di controllo, mi concentrerò solo su quell'aspetto. )

Il is_policy_checkedbit è impostato su 1if CHECK_POLICY = ONdurante uno CREATE LOGINo un ALTER LOGINevento, anche se la politica non è controllata al momento. Come probabilmente puoi raccogliere dall'alto, questo controllo non si verifica in questi scenari:

• La password viene specificata utilizzando la HASHEDparola chiave (una tattica molto comune durante la migrazione degli accessi tra server o la copia degli accessi per accedere ai secondari spediti / con mirroring / AG). Ovviamente non è possibile verificare la complessità della password se non si dispone del valore con hash.
• Il criterio di complessità della password locale non è abilitato al momento in cui si verifica l'evento.
• Non trattato nella mia riformulazione proposta sopra, ma puoi ALTER LOGINsenza impostare una nuova password e cambiare ancora il flag ( grazie a @AMtwo per averlo illustrato ). Sospetto che ciò possa essere stato fatto da persone intelligenti che cercano di ingannare un revisore dei conti.

Questi problemi sono tutti facili da dimostrare.

Dal momento che la maggior parte delle persone con cui ho parlato di questo ha sempre assunto che is_policy_checkedciò significhi in realtà che la password corrente soddisfa l'attuale politica delle password, penso che sia importante che qualcosa cambi qui in modo che gli utenti abbiano le giuste aspettative e capiscano che questo flag non significa necessariamente tutto bene. Per lo meno, la documentazione dovrebbe essere aggiornata per riflettere la realtà, un po 'come ho sottolineato sopra. Ma ci sono anche altre cose che possono essere fatte.

• Se CHECK_POLICY = ONviene specificato, potrebbe essere generato un avviso, ma in realtà la politica non può essere verificata (o perché la password è specificata con un hash o perché la politica della password è stata disabilitata o perché il comando è un semplice tentativo di bypassare o impostare la bandiera, ad es ALTER LOGIN blat WITH CHECK_POLICY = ON;.).
• CHECK_POLICYpotrebbe essere deprecato, a favore ACTIVELY_CHECK_POLICYe forse CHECK_POLICY_ON_NEXT_CHANGE. Le colonne in sys.sql_loginsdovrebbero essere policy_has_been_checkede policy_will_be_checked. Non sono sposato con questi nomi, ma sono molto più precisi dell'attuale formulazione.
• Se scelgo ACTIVELY_CHECK_POLICY = ONe la politica non può essere verificata durante l'esecuzione del comando, dovrei ricevere un messaggio di errore e il flag non dovrebbe essere impostato su 1(o anche la creazione dell'accesso o la modifica della password non dovrebbero avere esito positivo).
• Non credo che in questo caso abbia senso continuare con il comportamento attuale, in cui posso specificare che desidero verificare la politica, ma anche se non è possibile, la password è consentita e l'accesso / la creazione vengono / modificati (questo è negativo, IMHO, indipendentemente dallo stato della bandiera dopo il fatto - ma almeno se fosse impostato su 0, tali bypass potrebbero essere identificati).

Oggi non esiste un modo affidabile - senza cambiare manualmente le loro password in qualcosa che si sa sia sicuro - per controllare i tuoi accessi SQL ed essere sicuri che soddisfino tutti i tuoi criteri di complessità. In questi tempi di dati in costante aumento, sempre più violazioni dei dati e l'ovvia necessità di rendere i sistemi sempre più serrati, questo è un problema che deve essere affrontato. Ho scritto un blog su questo e ho creato un elemento Connect al riguardo:

• Aiutatemi a risolvere una grande lacuna di sicurezza
• Connect # 1250342: CHECK_POLICY è una no-op con CREATE LOGIN ... PASSWORD ... HASHED

Ti incoraggio a votare la voce Connect e, cosa più importante, assicurati di non controllare i tuoi sistemi con false percezioni sul funzionamento di questa opzione DDL e dei metadati.

Per favore, non considerare questo come un "non-problema" perché sei perfettamente a tuo agio nel modo in cui funziona e sai già che la bandiera non può essere attendibile - non sei l'utente di cui sono preoccupato; sono tutti gli altri.