Означает ли sys.sql_logins.is_policy_checked, что политика была проверена?

Когда я смотрю внутрь sys.sql_logins, я вижу столбец с именем is_policy_checked. Могу ли я доверять тому, что моя политика паролей была проверена для всех входов в систему, где указано значение этого столбца 1?

— Аарон Бертран
источник

Нет.

В то время как документация в настоящее время имеет следующее неоднозначное утверждение о том, что означает этот флаг:

Политика паролей проверена.

Что это действительно означает и должно сказать, так это то, что флаг служит двум целям:

Политика паролей могла быть проверена, но только если (а) политика паролей была включена во время последней установки пароля, и (б) пароль был задан в виде обычного текста (без хеша).

Политика паролей будет проверена при следующей настройке политики, но только в том случае, если (а) политика паролей включена в это время и (б) пароль указан в виде обычного текста (без хеша).

(И обратите внимание, что «политика» также относится к принудительному истечению срока действия и к тому факту, что пользователь должен изменить пароль при следующем входе в систему, но, поскольку сложность обычно является целью аудита операций, я собираюсь сосредоточиться только на этом аспекте. )

is_policy_checkedБит устанавливается , 1если CHECK_POLICY = ONво время CREATE LOGINили ALTER LOGINсобытия, даже если политика не проверяются в то время. Как вы, вероятно, можете увидеть сверху, эта проверка не происходит в следующих сценариях:

Пароль указывается с помощью HASHEDключевого слова (очень распространенная тактика при переносе логинов между серверами или копировании логинов в журналы отправленных / зеркальных / AG вторичных серверов). Очевидно, что невозможно проверить сложность пароля, если у вас нет предварительно хешированного значения.
Локальная политика сложности паролей не включена в момент возникновения события.
Не рассматривается в предложенной мной редакции выше, но вы можете ALTER LOGINбез установки нового пароля и все равно изменить флаг ( спасибо @AMtwo за иллюстрацию ). Я подозреваю, что это могли сделать умные люди, пытающиеся одурачить одитора.

Все эти проблемы легко продемонстрировать.

Поскольку большинство людей, с которыми я говорил об этом, всегда предполагали, что на is_policy_checkedсамом деле это означает, что текущий пароль соответствует текущей политике паролей, я думаю, что важно что-то изменить здесь, чтобы пользователи имели правильные ожидания и понимали, что этот флаг не обязательно означает все хорошо. По крайней мере, документацию следует обновить, чтобы она отражала реальность, как я уже говорил выше. Но есть и другие вещи, которые можно сделать тоже.

Предупреждение может быть выдано, если CHECK_POLICY = ONоно указано, но политика не может быть проверена (либо потому, что пароль указан с помощью хэша, либо потому, что политика паролей отключена, либо потому, что команда является простой попыткой обойти или установите флаг, например ALTER LOGIN blat WITH CHECK_POLICY = ON;).
CHECK_POLICYмогут быть устаревшими, в пользу ACTIVELY_CHECK_POLICYи , возможно CHECK_POLICY_ON_NEXT_CHANGE. Столбцы в sys.sql_loginsдолжны быть policy_has_been_checkedи policy_will_be_checked. Я не женат на этих именах, но они намного точнее, чем нынешняя формулировка.
Если я выберу ACTIVELY_CHECK_POLICY = ONи политика не может быть проверена во время выполнения команды, я должен получить сообщение об ошибке, и флаг не должен быть установлен 1(или даже создание логина или смена пароля не должны быть успешными).
Я не думаю, что в этом случае имеет смысл продолжать текущее поведение, где я могу указать, что я хочу, чтобы политика проверялась, но даже если это невозможно, пароль разрешен, а логин создан / изменен. (это плохо, ИМХО, независимо от состояния флага после факта - но, по крайней мере, если бы он был установлен 0, такие обходы могли бы быть идентифицированы).

Сегодня нет надежного способа - без изменения вручную их паролей на те, которые, как вы знаете, безопасны, - проверять свои имена входа SQL и быть уверенными в том, что все они соответствуют вашей политике сложности. В наши дни, в эпоху постоянно растущих данных, все большего числа утечек данных и очевидной необходимости все более надежной защиты систем, эта проблема требует решения. Я написал об этом в блоге и создал элемент Connect:

Я рекомендую вам проголосовать за элемент Connect и, что более важно, убедиться, что вы не проводите аудит своих систем с ложными представлениями о том, как работают этот параметр DDL и метаданные.

Пожалуйста, не отбрасывайте это как «не проблема», потому что вы совершенно уверены, как он работает, и уже знаете, что флагу нельзя доверять - вы не тот пользователь, о котором я беспокоюсь; это все остальные.

— Аарон Бертран
источник