Журналы аудита и реализующий SOX/HIPAA/etc, лучшие практики для уязвимых данных

Oracle имеет продукт под названием Хранилище Аудита Oracle - DB2, вероятно, имеет эквивалент.

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

Если Вы хотите сделать что-то в своей базе данных, можно изучить передачу журналов (терминология могла бы отличаться от RDBMS до RDBMS). В основном любая операция DML зарегистрирована в файл. Можно использовать эту информацию для резервных копий и восстановления момента времени, даже для репликации/HA/обработки отказа/и т.д. Если Вы поставляете свои журналы в отдельную, "доверяемую" систему в "только добавлении" (т.е. процесс передачи журналов имеет полномочия создать новые файлы журнала, но не изменить существующую информацию) вид, у Вас уже есть примитивная функциональность аудита. Если Вы делаете это безопасным способом (т.е. аутентификация, неотказуемость), Вы, вероятно, даже вполне близко к "соответствию" :-p

Конечно, отсеивание через партии и много из ВСТАВЛЯТЬ/ОБНОВЛЯТЬ/ОПЕРАТОРЫ УДАЛЕНИЯ, не самый сложный способ работать.

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

Следующая вещь понять - то, что Вы хотите контролировать. В случае HIPAA и SOX, например, Вы, вероятно, смотрите на PII - Персональная информация об Идентификации. Помните суету, сделанную о людях, получающих доступ к телефонным записям Obama или различной медицинской документации знаменитостей, или... Они были пойманы, потому что система контролировала, кто считал те записи, и контрольный аналитический чиновник (AAO) определил это, к записям знаменитости получили доступ люди, которые не были конкретно разрешены сделать так. Так, те системы должны регистрироваться, кто получает доступ к каждой записи и определению, когда у пользователя, который делает так, нет подлинной бизнес-причины сделать так. В этих случаях кажется, что пользователи считали полномочия для записей, поэтому если бы их обычные обязанности потребовали, чтобы они посмотрели на записи, то они могли бы сделать так. Но, когда они не были обязаны делать так, затем они злоупотребляли своим питанием и соответственно санкционированные (до и включая проигрывающие задания по нему).

То, что это означает, - то, что Вы, вероятно, не хотите отслеживать, кто получает доступ к таблице состояний, которая записывает кодовое название состояния и полное имя (и сортировал другие биты информации о состоянии). Нет ничего конфиденциального о том списке - не имеет значения, кто читает его. Конечно, почти никто не должен писать в него; список состояний не изменяется очень часто - но это может, вероятно, быть обработано путем отмены обновления и удалить разрешение на таблице от всех.

OTOH, Вы, вероятно, хотите записать, кто получает доступ к записям в историях болезни (HIPAA), или кто изменяет данные в системах учета (SOX). Вы могли бы или, возможно, не должны были бы волноваться о том, кто считывает бухгалтерские данные; с большим количеством этого могут иметь дело основные полномочия (у бухгалтерских сотрудников есть разрешение; сотрудники IT не делают). Однако аудит всегда является дополнительной линией обороны.

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