Должен ли модуль контроллера безопасности иметь собственную базу данных, в которой информация о пользователе хранится отдельно от бизнес-данных?
Зависит от контекста вашей системы:
- Если эта база данных используется только одним приложением И ваша настройка сервера приложений / сервера базы данных относительно безопасна и доступ уже контролируется - вам, вероятно, не нужна отдельная база данных, хотя вы захотите убедиться, что доступ к вашему пользователюдоступ к информации должным образом контролируется в базе данных.
- Если вы используете базу данных совместно с другими приложениями, вы можете рассмотреть возможность использования отдельного механизма хранения информации о пользователе / роли / привилегиях, которым вы можете управлять более тщательно.
Существует также соображение о том, что вы защищаете.Если вы в основном пытаетесь сохранить доступ к унылому реву и не работаете с финансовой информацией, информацией о здравоохранении или защитой - возможно, вы согласны с определенным риском того, где хранится информация пользователя.Если у вас есть приложение с высоким уровнем безопасности, вы можете даже подумать о коммерческих программных продуктах для управления доступом (например, о каталоге LDAP, который имеет собственные журналы аудита, сервер, административные процессы и т. Д.).
Когда вы думаете о хранилище данных, не ограничивайте себя только тем, как хранить и защищать данные.Также подумайте, как вы получаете доступ к данным (через зашифрованное соединение или в открытом виде?), Как регистрируются обращения (в системе с высоким уровнем безопасности проверка учетных данных пользователя - это событие, которое должно регистрироваться), как защищаются журналы (являются ли онизащищен от взлома?) и как данные защищены - не только от проверки, но и от модификации.
И будет ли для этого достаточен двоичный сериализованный файл, если пользовательские пароли (толькохэш) не сохраняются в указанном файле? Я бы предположил, однако, что для того, чтобы это работало, сериализованный файл должен быть доступен нескольким экземплярам приложения ...
Мой самый большой вопрос для этогоэто - как этот файл защищен от изменений?Поскольку двоичный искомый файл относительно легко анализировать из приложения, как вы контролируете способность других процессов записывать данные в файл?Самая простая атака - добавить собственную учетную запись с высокими привилегиями и хэш имени пользователя / пароля, а затем использовать поддельную учетную запись для взлома остальной системы.Насколько легко было бы это сделать и насколько легко было бы взять набор учетных данных с низкими привилегиями и преобразовать их в высокопривилегированные?
Это больше, чем просто механизм хранения файлов - это также означает, что вам необходимо иметь представление о контроле доступа в вашей операционной системе и о том, как им управлять.
Вещи, которые могут помочь: - поставить цифровую подпись в файле с помощью асимметричного ключа, хранящегося в другом месте, а затем проверить его на наличие взлома перед использованием файла.- сохраните файл в учетной записи, которую можно изменить, только если вы являетесь администратором.