Какие события безопасности выполняет один аудит для бизнес-приложения?

Question

Я уже проверяю успешность авторизации, сбой и выход из системы.

Я рассмотрел аудит (ведение журнала) каждого вызова метода и сохранение версии каждой строки и столбца, которые когда-либо были изменены, но оба эти варианта значительно увеличат сложность аудита. Аудит случайного подмножества видит слишком случайным.

Юридические спецификации (FISMA, C & A) просто говорят, что нужно что-то проверять.

Существуют ли какие-либо другие стратегии аудита, не относящиеся к конкретной области, которые я забыл?

Answer 1

Учитывая, что аудит часто подразумевает ответственность , вы можете занести в журнал те действия, которые могут способствовать любому событию, когда кто-то / что-то должно быть подотчетно ..

1. Изменение клиентских записей
2. Изменение конфигурации
3. Удаление данных

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

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

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

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

Но я не эксперт.

Answer 2

Я согласен со многим из того, что сказал Эйден, но я твердо верю, что аудит должен быть на уровне базы данных. Слишком много баз данных доступны с помощью динамического sql, поэтому разрешения находятся на уровне таблицы (по крайней мере, в SQL Server). Таким образом, лицо, совершившее мошенничество, может ввести или удалить данные в базе данных, минуя все правила. В хорошо спроектированной системе только пара человек (dba и резервная копия) будут иметь права изменять триггеры аудита в prod, и, таким образом, большинство людей могут быть пойманы, если они изменяют данные, которые они не имеют права изменять. Аудит через приложение никогда не поймает этих людей. Конечно, нет почти никакого способа предотвратить мошенничество со стороны dbas, если они захотят это сделать, но кто-то должен иметь права администратора для базы данных, поэтому вы должны быть очень осторожны при выборе таких людей.

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

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