Защита от внутренних атак
7.3. Ограничение доступа к БД через внешние средства
Одним из видов внутренней атаки на систему является попытка прямой работы с СУБД, в которой хранятся данные системы не через легальные средства самой системы, а через внешние приложения. Для осуществления такой атаки необходимо получить логин и пароль к СУБД, а также обладать необходимыми правами на доступ к объектам СУБД.
Для защиты от подобных атак в системе "ДБО BS-Client" предусмотрено несколько механизмов. Часть из них используется в стандартной поставке, а часть может быть подключена к системе дополнительно при соответствующем пожелании банка. Данные механизмы включают в себя:
•использование каждым пользователем системы уникального логина в СУБД;
•использование операторами системы скрытого пароля к СУБД;
•использование механизма внешней аутентификации пользователей;
•использование механизмов СУБД для ограничения доступа к базе данных.
Рассмотрим далее эти механизмы подробнее.
Одним из простейших способов ограничить доступ злоумышленника к СУБД является парольная защита, которая присутствует во всех поддерживаемых СУБД. ДБО позволяет использовать парольную аутентификацию СУБД. Для этого каждому пользователю системы "ДБО BS-Client" выдается определенный логин в СУБД. При входе пользователя в систему он помимо пароля пользователя должен также ввести пароль в СУБД. Таким образом, злоумышленник не являющийся пользователем системы "ДБО BS-Client", не сможет получить доступ к базе данных.
Для упрощения процедуры аутентификации можно указать системе, что пароли пользователя в ДБО и СУБД совпадают. В этом случае у пользователя будет запрашиваться только один пароль.
Система "ДБО BS-Client" позволяет запретить прямой доступ внешними средствами к СУБД даже тем пользователям, которые являются пользователями "ДБО BS-Client". Для этого можно задействовать режим, при котором пароль к СУБД не запрашивается у пользователя, а вводится автоматически на основании информации в файле настроек default.cfg. В этом файле пароль в СУБД хранится в зашифрованном виде, что ограничивает возможности пользователя по его вскрытию. Таким образом, пользователь системы "ДБО BS-Client" вообще не знает пароль, с помощью которого происходит взаимодействие с СУБД и, следовательно, не может использовать внешние средства для работы с СУБД.
Самым защищенным способом аутентификации пользователей в СУБД является способ внешней аутентификации. Он не входит в стандартную поставку системы, но в случае необходимости может быть добавлен по требованию банка.
В этом случае пароль к СУБД не запрашивается у пользователя и не хранится на локальном компьютере пользователя и, следовательно, даже теоретически не может быть использован для доступа к СУБД через внешние средства.
28
Защита от внутренних атак
Подключение к СУБД в этом случае происходит следующем образом.
1.При входе пользователя в систему происходит обращение по DCOM к вешнему серверу аутентификации.
2.Далее этот сервер на основании стандартного механизма аутентификации Windows определяет пользователя домена, обратившегося к нему.
3.На основании этого имени сервер аутентификации определяет логин и пароль в СУБД для данного пользователя.
4.Полученные логин и пароль передаются (с использованием защищенного протокола) обратно в приложение оператора.
5.Далее происходит подключение в СУБД с использованием полученных параметров. В этом случае пользователь вообще не вводит и не знает свой пароль в СУБД. Схема данного механизма аутентификации изображена на следующей схеме:
Рис. 7.1. Схема внешней аутентификации приложений
Помимо встроенных в систему "ДБО BS-Client" механизмов защиты можно использовать и механизмы защиты, предоставляемые самими СУБД. Поскольку такие механизмы существенно зависят от используемой СУБД, то в стандартную поставку они не входят, но могут быть настроены самим банком или специалистами БСС в каждом конкретном случае. В частности те или иные СУБД поддерживают следующие механизмы (приведены только некоторые примеры):
•Использование механизма аутентификации Windows вместо парольной аутентификации доступа к СУБД.
•Разграничение прав пользователей на объекты СУБД (запрет просмотра или изменения отдельных таблиц, например).
•Ограничение списка компьютеров, с которых разрешен доступ к СУБД;
29
Защита от внутренних атак
•Применение криптографии.
Также в качестве дополнительного механизма защиты можно рекомендовать использовать запрет для рядовых пользователей возможности прямого доступа к СУБД на сетевом уровне путем межсетевого экранирования в ЛВС.
В совокупности описанные механизмы гарантируют невозможность взлома системы через доступ к СУБД внешними средствами.
7.4. Аудит действий пользователей
Аудит действий пользователей системы "ДБО BS-Client" осуществляется с использованием так называемого «журнала событий» (доступен в серверной части и «толстом» клиенте ДБО). Журнал событий, ведущийся в системе "ДБО BS-Client", соответствует следующим требованиям:
•наличие информации обо всех событиях произошедших в системе;
•периодическое обновление информации в «окне событий»;
•возможность оповещения администратора вызовом заданной операции, например, выводом предупреждения на экран или формированием сообщения MS-Exchange при появлении в журнале записи (записей), удовлетворяющих заданному условию.
Использование данного интерфейса позволяет получить информацию о:
•пользователях, зарегистрированных в системе;
•текущим статусе (подключен / не подключен) каждого из пользователей;
•последнем событии, произведенное пользователем и его время;
•полном списке действий выбранного пользователя за указанный период времени с возможностью фильтрации по типу событий.
7.5.Журналирование процессов, происходящих внутри системы
В процессе работы системы ведутся различные журналы (лог-файлы). Они отражают действия и операции, выполняемые системой. Есть журналы, которые ведутся всегда, создание других можно настроить. Создание журналов бывает полезно как для получения отладочной информации, так и для дополнительного аудита работы системы.
7.5.1. Фиксация смены статусов документов
Для всех финансовых документов, имеющих хождение в системе "ДБО BS-Client" предусмотрен механизм журнализации истории смены статусов документа. Данные о дате и времени смены статуса, значении исходного и конечного статуса при смене, а также имя пользователя, выполнявшего процедуру, приведшую к смене статуса документа доступны из визуального интерфейса «толстого» клиента и серверной части системы "ДБО BS-Client" (Системные поля документа—История).
30