Я ищу чистый способ ведения контрольных журналов в MS SQL Server по соображениям соответствия, желательно полностью на стороне базы данных без участия веб-приложения.
Говоря о журналах аудита, я имею в виду полный журнал изменений в базе данных на уровне данных. Итак, кто что и когда изменил?
У меня есть установка с активным каталогом в качестве серверной части аутентификации, и мне нужно разработать веб-приложение на основе Java.
Итак, чтобы получить действительный контрольный журнал, мне нужна информация о том, кто что и когда изменил. AFAIK есть функция под названием SQL Server Audit, которая может предоставить именно это.
Мой вопрос касается управления пользователями и аутентификации на стороне MS SQL. Веб-приложение должно использовать пользователей AD, а затем обращаться к базе данных. Таким образом, я согласен с тем, что пользователи AD должны быть перенаправлены в базу данных MS SQL через веб-приложение, чтобы они отображались в журнале аудита.
Это, похоже, подтверждается этим документом MS: https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/getting-started-with-database-engine-permissions?view=sql-server-2017.
Это предполагает, что в типичном сценарии можно попытаться управлять пользователями и группами через AD, а MS SQL просто сопоставит эти группы с ролями в базе данных. Этим ролям, в свою очередь, будут предоставлены привилегии.
С другой стороны, некоторые из моих коллег говорят, что мы должны использовать одну общую учетную запись приложения для доступа к базе данных и самостоятельно создавать контрольный журнал в приложении. Они ссылаются на расплывчатые соображения безопасности.
Что правильно (тм) делать?
Итак, вы планируете предоставить доступ к вашей базе данных большому количеству пользователей, просто чтобы не вести контрольный журнал там, где он должен быть? У ваших коллег есть не «расплывчатые опасения по поводу безопасности», а простой здравый смысл. Журнал аудита базы данных показывает такие вещи, как «этот пользователь обновил / вставил / удалил эту запись». Это не говорит что на самом деле произошло, например, «этот человек попросил отпуск 20-го числа» (для использования системы управления отпусками в качестве примера). Должен присутствовать аудит базы данных, чтобы видеть, кто вручную вносил изменения в данные. Веб-приложение должно иметь свой собственный контрольный журнал (который может быть поврежден в базе данных) для событий, происходящих в нем (веб-приложении).