Моя статья поможет, если вы настроите ее заранее, но не тогда, когда событие произошло в прошлом, и у вас не было настроено никакого механизма аудита.
Однако надежда все еще есть. Допустим, я сделал это:
CREATE LOGIN flooberella WITH PASSWORD = N'x', CHECK_POLICY = OFF;
Эта информация содержится в трассировке по умолчанию в EventClass 104 (Audit Addlogin Event). Однако, если я изменю пароль одним из следующих способов:
ALTER LOGIN flooberella WITH PASSWORD = N'y';
EXEC sp_password N'y', N'z', N'flooberella';
Эти события не фиксируются трассировкой по умолчанию по очевидным причинам безопасности - у всех, кто имеет доступ к трассировке по умолчанию, не должно быть возможности выяснить, какой пароль у кого-то другого, и при этом они не хотят упростить даже обнаружение того, что пароль был изменен (например, опрос частоты этих событий может выявить некоторые свойства вашей стратегии безопасности).
Так что еще можно сделать? Хотя это зависит от информации, которая все еще находится в журнале, а также от использования недокументированной команды DBCC для системной базы данных (вы можете создать резервную копию master и восстановить ее в другом месте), вы можете получить некоторую информацию из журнала транзакций, например:
DBCC LOG(master, 1);
Это даст для двух вышеупомянутых команд строки со следующей (частичной) информацией:
Current LSN Description
====================== ======================================================================
000000f2:000001b8:0002 ALTER LOGIN;0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000
000000f2:000001b8:0004 Alter login change password;0x01050000000000 ... same sid as above ...
Не похоже много, но теперь возьмите ту часть описания 0x, а затем сделайте:
SELECT name FROM sys.server_principals
WHERE sid = 0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000;
Дымящийся пистолет! Это человек, ответственный за это событие.
Конечно, если они используют ALTER LOGIN
синтаксис для всех операций (которые они должны использовать вместо sp_password
), вы не сможете различить того, кто меняет базу данных по умолчанию, и того, кто меняет пароль. Вы же не можете сказать (по крайней мере , что я могу видеть) , что войти в этот пострадавших, только что этот человек изменил на вход в систему . Джон, кажется, думает, что эта информация также есть в журнале, но мне не удалось ее найти (в отличие от информации о времени, которую я как-то прокручивал в прошлом).
В SQL Server 2012 могут быть разные ответы для отдельных пользователей - хотя я подозреваю, что смена пароля все еще запутывается подобными способами. Оставим это для отдельного вопроса.