Стандарты мониторинга и отслеживания безопасности
Я работаю в системе, которая обрабатывает аутентификацию / авторизацию и должна отслеживать попытки отдельных пользователей войти в систему, внести изменения в разрешения / пользователей, неудачные попытки и т. Д. Мы хотим иметь возможность анализировать эту информацию в базе данных. для дальнейшего анализа / поиска в более позднее время.
В нашей текущей реализации мы используем стандарт домашнего производства, который регистрируется с использованием каркаса ведения журнала (в данном случае Log4j, но это не то, что важно). Является ли структура ведения журнала правильным механизмом для отслеживания этой информации? Мне кажется, что это не так; Я всегда понимал, что ведение журнала - это форма вскрытия для кода - больше для того, чтобы рассказать, что произошло, когда это было необходимо для целей отладки и т. Д. Для меня это больше похоже на механизм отчетности. Существуют ли стандарты для такого типа проблемы? Существуют ли стандартные решения / форматы, которые используют люди? Является ли использование каркаса логирования правильным решением для этого или есть лучший способ обработки данных такого типа? На какие источники я могу ссылаться, просматривая эту информацию и представляя ее заинтересованным сторонам?
Я должен отметить - данные, которые регистрируются, уже фильтруются на основе стандартов соответствия / безопасности (без паролей и т. Д.), И вся регистрация происходит в нашей внутренней среде. Я больше ищу способ, которым мы можем управлять информацией об изменениях в системе аутентификации и авторизации.
2 ответа
Похоже, вы используете log4J для аудита (и, вероятно, для регистрации диагностической или трассировочной информации). Чтобы ответить на ваш вопрос:
Является ли структура ведения журнала правильным механизмом для отслеживания этой информации?
прямой ответ - "Нет, каркас не является правильным механизмом". Существуют определенные атрибуты, которые, если они присутствуют в каркасе журналирования, предоставят ему возможность использования в качестве каркаса аудита.
Некоторые из этих требований представлены ниже, и log4j может использоваться для удовлетворения некоторых из них. Это не является исчерпывающим, и я бы порекомендовал вам взглянуть на реализацию структур аудита (например, LAUS), чтобы получить более полный список.
- Структура аудита должна обеспечивать отказоустойчивый аудит событий. Это может зависеть от того, как приложение использует платформу, но основное требование заключается в том, что, если аудит терпит неудачу, то и приложение должно. Приложение не должно пытаться обработать какой-либо запрос, если событие не может быть проверено. Каркас ведения журналов обычно не соответствует этому требованию.
- Платформа аудита в идеале должна предоставлять хранилище с однократной записью и только для чтения. Другими словами, события, записанные в журнал аудита, должны и не должны удаляться. Среда аудита обычно не реализует эту защиту сама по себе, вместо этого полагаясь на комбинацию других факторов, чтобы гарантировать, что журнал защищен от несанкционированного доступа.
- Структура аудита должна позволять хранить журналы аудита в другой системе. Это гарантирует, что компрометация одной системы не приведет автоматически к компрометации журналов аудита.
- Фреймворк также должен позволять собирать важную информацию и в идеале не должен оставлять ее программистам. Важная информация будет состоять из метки времени из синхронизированного источника времени, пользователя, ответственного за запрос (или любой информации, идентифицирующей пользователя), источника запроса, статуса запроса (был ли он успешным или неудачным), любых ошибок, обнаруженных во время обработка запроса и т. д.
Каркас ведения журналов не является плохой вещью для использования здесь. Регистрация в файл обычно быстрее, чем регистрация в базе данных. Тем не менее, с помощью Log4j вы можете внедрить или использовать существующее приложение JDBC, которое будет вставлять все ваши данные в базу данных по мере их регистрации. Для обеспечения надежности вы можете настроить приложение для файлов и базы данных для ведения журнала аудита, чтобы иметь резервные копии в случае сбоя базы данных журналов.
Другими альтернативами могут быть аспекты АОП вокруг вашей логики безопасности / бизнеса, которые будут вставлять данные непосредственно в базу данных журналов.
Я не думаю, что существует какой-либо общий стандарт для такого рода данных.