Bedeutet sys.sql_logins.is_policy_checked, dass die Richtlinie überprüft wurde?

Wenn ich hineinschaue sys.sql_logins, sehe ich eine Spalte mit dem Namen is_policy_checked. Kann ich darauf vertrauen, dass meine Kennwortrichtlinie für alle Anmeldungen überprüft wurde, für die dieser Spaltenwert gilt 1?

— Aaron Bertrand
quelle

Nein.

Während die Dokumentation zur Zeit hat die folgende wohl mehrdeutige Aussage darüber , was dieses Flag bedeutet:

Die Kennwortrichtlinie wird überprüft.

Was es wirklich bedeutet und sagen sollte, ist, dass die Flagge zwei Zwecken dient:

Möglicherweise wurde die Kennwortrichtlinie überprüft, jedoch nur, wenn (a) die Kennwortrichtlinie zum Zeitpunkt der letzten Kennworteinstellung aktiviert war und (b) das Kennwort im Klartext (ohne Hash) angegeben wurde.

Die Kennwortrichtlinie wird beim nächsten Festlegen der Richtlinie überprüft, jedoch nur dann, wenn (a) die Kennwortrichtlinie zu diesem Zeitpunkt aktiviert ist und (b) das Kennwort im Klartext (nicht mit einem Hash) angegeben wird.

(Und beachten Sie, dass sich "die Richtlinie" auch auf das Erzwingen des Ablaufs und die Tatsache bezieht, dass der Benutzer das Kennwort bei der nächsten Anmeldung ändern muss. Da die Komplexität jedoch in der Regel im Mittelpunkt von Überwachungsvorgängen steht, werde ich mich nur auf diesen Aspekt konzentrieren. )

Das is_policy_checkedBit wird gesetzt, 1wenn CHECK_POLICY = ONwährend eines CREATE LOGINoder ALTER LOGINEreignisses, auch wenn die Richtlinie zu diesem Zeitpunkt nicht überprüft wird. Wie Sie wahrscheinlich oben sehen können, findet diese Überprüfung in den folgenden Szenarien nicht statt:

Das Kennwort wird mithilfe des HASHEDSchlüsselworts angegeben (eine sehr verbreitete Taktik beim Migrieren von Anmeldungen zwischen Servern oder beim Kopieren von Anmeldungen in das Protokoll "Ausgeliefert / Gespiegelt / AG-Sekundär"). Es ist offensichtlich nicht möglich, die Komplexität des Passworts zu überprüfen, wenn Sie nicht den vorab gehashten Wert haben.
Die lokale Kennwortkomplexitätsrichtlinie ist zum Zeitpunkt des Ereignisses nicht aktiviert.
In meiner vorgeschlagenen Umformulierung oben nicht behandelt, aber Sie können ALTER LOGINdas Flag ändern, ohne ein neues Passwort festzulegen ( danke an @AMtwo für die Veranschaulichung ). Ich vermute, dass dies von klugen Leuten getan wurde, die versuchten, einen Auditor zum Narren zu halten.

Diese Probleme sind alle leicht zu demonstrieren.

Da die meisten Leute, mit denen ich darüber gesprochen habe, immer davon ausgegangen sind, is_policy_checkeddass das aktuelle Kennwort tatsächlich der aktuellen Kennwortrichtlinie entspricht, halte ich es für wichtig, dass sich hier etwas ändert, damit die Benutzer die richtigen Erwartungen haben und verstehen, dass dieses Flag nicht unbedingt bedeutet Alles ist gut. Zumindest sollte die Dokumentation aktualisiert werden, um die Realität widerzuspiegeln, wie ich oben ausgeführt habe. Aber es gibt auch andere Dinge, die getan werden können.

Wenn CHECK_POLICY = ONangegeben, kann eine Warnung ausgegeben werden , die Richtlinie kann jedoch nicht überprüft werden (entweder weil das Kennwort mit einem Hash angegeben wurde oder weil die Kennwortrichtlinie deaktiviert wurde oder weil der Befehl ein einfacher Versuch zur Umgehung ist oder setzen Sie die Flagge, zB ALTER LOGIN blat WITH CHECK_POLICY = ON;).
CHECK_POLICYkönnte veraltet sein, zugunsten ACTIVELY_CHECK_POLICYund vielleicht CHECK_POLICY_ON_NEXT_CHANGE. Die Spalten in sys.sql_loginssollten policy_has_been_checkedund sein policy_will_be_checked. Ich bin nicht mit diesen Namen verheiratet, aber sie sind viel genauer als der aktuelle Wortlaut.
Wenn ich wähle ACTIVELY_CHECK_POLICY = ONund die Richtlinie während der Ausführung des Befehls nicht überprüft werden kann, sollte ich eine Fehlermeldung erhalten und das Flag sollte nicht auf gesetzt sein 1(oder sogar die Anmeldung oder Kennwortänderung sollte nicht erfolgreich sein).
Ich halte es in diesem Fall nicht für sinnvoll, mit dem aktuellen Verhalten fortzufahren, in dem ich angeben kann, dass die Richtlinie überprüft werden soll. Wenn dies jedoch nicht möglich ist, wird das Kennwort zugelassen und die Anmeldung erstellt / geändert (Dies ist schlecht, IMHO, unabhängig vom Zustand der Flagge nach der Tatsache - aber zumindest wenn es auf gesetzt wäre 0, könnten solche Umgehungen identifiziert werden).

Heutzutage gibt es keine verlässliche Möglichkeit, Ihre SQL-Anmeldungen zu überwachen und sicher zu sein, dass sie alle Ihre Komplexitätsrichtlinien erfüllen, ohne die Kennwörter manuell in sichere Kennwörter zu ändern. In der heutigen Zeit von immer mehr Daten, immer mehr Datenverletzungen und der offensichtlichen Notwendigkeit, Systeme immer enger abzusichern, ist dies ein Problem, das angegangen werden muss. Ich habe darüber gebloggt und einen Connect-Artikel darüber erstellt:

Ich empfehle Ihnen, über das Connect-Element abzustimmen und, was noch wichtiger ist, sicherzustellen, dass Sie Ihre Systeme nicht mit falschen Vorstellungen über die Funktionsweise dieser DDL-Option und der Metadaten überwachen.

Schieben Sie dies bitte nicht als "Nicht-Problem" beiseite, da Sie mit der Funktionsweise der Funktion vertraut sind und bereits wissen, dass der Flagge nicht vertraut werden kann - Sie sind nicht der Benutzer, um den ich mir Sorgen mache. es sind alle anderen.

— Aaron Bertrand
quelle