No.
Si bien la documentación actualmente tiene la siguiente afirmación posiblemente ambigua sobre lo que significa esta bandera:
La política de contraseña está marcada.
Lo que realmente significa, y debería decir, es que la bandera tiene dos propósitos:
- Es posible que se haya verificado la política de contraseña , pero solo si (a) la política de contraseña estaba habilitada en el momento en que se configuró por última vez, y (b) la contraseña se especificó en texto sin formato (no con un hash).
- La política de contraseña se verificará la próxima vez que se establezca la política, pero solo si (a) la política de contraseña está habilitada en ese momento y (b) la contraseña se especifica en texto sin formato (no con un hash).
(Y tenga en cuenta que "la política" también se refiere al cumplimiento de la caducidad y al hecho de que el usuario debe cambiar la contraseña en el próximo inicio de sesión, pero dado que la complejidad suele ser el foco de las operaciones de auditoría, me centraré solo en ese aspecto. )
El is_policy_checkedbit se establece en 1if CHECK_POLICY = ONdurante un evento CREATE LOGINo ALTER LOGIN, incluso si la política no se verifica en ese momento. Como probablemente pueda deducir de lo anterior, esta verificación no ocurre en estos escenarios:
- La contraseña se especifica utilizando la
HASHEDpalabra clave (una táctica muy común al migrar inicios de sesión entre servidores o copiar inicios de sesión en registros enviados / duplicados / secundarios de AG). Obviamente, no es posible verificar la complejidad de la contraseña si no tiene el valor pre-hash.
- La política de complejidad de contraseña local no está habilitada en el momento en que ocurre el evento.
- No está cubierto en mi redacción propuesta anteriormente, pero puede hacerlo
ALTER LOGIN sin establecer una nueva contraseña y aún así cambiar la bandera ( gracias a @AMtwo por ilustrar esto ). Sospecho que esto puede haber sido hecho por personas inteligentes que intentan engañar a un auditor.
Todos estos problemas son fáciles de demostrar.
Como la mayoría de las personas con las que he hablado sobre esto siempre han asumido que eso is_policy_checkedsignifica que la contraseña actual cumple con la política de contraseña actual, creo que es importante que algo cambie aquí para que los usuarios tengan las expectativas correctas y comprendan que esta bandera no necesariamente significa todo está bien. Por lo menos, la documentación debe actualizarse para reflejar la realidad, algo como lo he señalado anteriormente. Pero también hay otras cosas que se pueden hacer.
- Se puede generar una advertencia si
CHECK_POLICY = ONse especifica, pero la política no puede, de hecho, verificarse (ya sea porque la contraseña se especifica con un hash, o porque la política de contraseña se ha deshabilitado, o porque el comando es un simple intento de eludir o establecer la bandera, por ejemplo ALTER LOGIN blat WITH CHECK_POLICY = ON;).
CHECK_POLICYpodría ser obsoleto, a favor ACTIVELY_CHECK_POLICYy quizás CHECK_POLICY_ON_NEXT_CHANGE. Las columnas en sys.sql_loginsdeben ser policy_has_been_checkedy policy_will_be_checked. No estoy casado con estos nombres, pero son mucho más precisos que la redacción actual.- Si elijo
ACTIVELY_CHECK_POLICY = ONy la política no se puede verificar durante la ejecución del comando, debería recibir un mensaje de error y el indicador no debería estar configurado en 1(o incluso la creación de inicio de sesión o el cambio de contraseña no deberían tener éxito).
- No creo que tenga sentido en este caso continuar con el comportamiento actual, donde puedo especificar que quiero que se verifique la política, pero incluso si no puede, la contraseña está permitida y el inicio de sesión se crea / modifica (Esto es malo, en mi humilde opinión, independientemente del estado de la bandera después del hecho, pero al menos si se estableciera
0, tales bypass podrían identificarse).
Hoy en día no existe una manera confiable, sin cambiar manualmente sus contraseñas por algo que usted sabe que es seguro, para auditar sus inicios de sesión de SQL y tener la seguridad de que todos cumplen con su política de complejidad. En esta época de datos cada vez mayores, más y más violaciones de datos y la obvia necesidad de asegurar sistemas cada vez más estrictos, este es un problema que debe abordarse. He publicado un blog sobre esto y he creado un elemento de Connect al respecto:
Le recomiendo que vote sobre el elemento Connect y, lo que es más importante, asegúrese de que no está auditando sus sistemas con percepciones falsas sobre cómo funcionan esta opción DDL y metadatos.
Por favor, no se cepille esto a un lado como una "no-problema" porque usted está perfectamente cómodo con su funcionamiento y ya sabe que la bandera no se puede confiar - que no es el usuario que me preocupa; Son todos los demás.
