Загруженная база данных доступа - работает SSIS и вирусная уязвимость

Question

Я создал процесс, в котором (зарегистрированный) пользователь может загрузить (после проверки на стороне клиента и на стороне сервера) базу данных доступа (с очень редким расширением) на мой сервер через веб-форму asp.net, которая сидеть в хорошем безопасном месте, пока запланированный пакет служб SSIS не появится ночью, чтобы передавать соответствующие данные из базы данных access на сервер sql.

После этого мой доступ к БД удаляется. Там не будет никакого другого исполнения этого БД. Доступ не установлен на сервере.

Разумеется, я провел исследование, но представляю ли я уязвимость (например, сценарий внутри базы данных доступа?), Которую SSIS может вызвать?

Заранее спасибо.

Answer 1

SSIS, вероятно, использует ODBC или OLEDB для доступа к данным в базе данных Access / Jet / ACE, поэтому там нет ничего для выполнения какого-либо кода - ODBC и OLEDB ничего не знают ни о чем, кроме данных и всех опасных функций, которые могутбыть выполненным в SQL, операторы заблокированы.

Итак, без установленного Access нет никакой реальной опасности.Если вас это беспокоит, вы можете обработать файл с помощью DAO, прежде чем открыть его и удалить все в коллекции QueryDefs и в коллекции документов Modules.Или вы можете использовать буферную базу данных, куда вы импортируете только таблицы данных, а затем передаете это в SSIS.

Но я не думаю, что SSIS рассматривает что-то кроме таблиц данных для начала.

Кстати, еще никогда не было ни одного вируса или эксплойта, распространяемого через Access, поэтому проблемы с уязвимостями Access сильно преувеличены (в результате возникли серьезные неудобства для конечных пользователей, с заблокированными макросами, режим песочницы).а с A2007 - необходимость определения надежных расположений).

Answer 2

Я бы согласился с Дэвидом (хотя использование слова «никогда» всегда опасно!). Еще одна вещь, которую вы могли бы рассмотреть, - это чтобы человек, который заархивировал базу данных перед загрузкой, применил шифрование к zip-файлу с паролем, характерным для каждого пользователя.

Фактическое шифрование не обязательно должно быть особенно сильным, даже если оно поможет, если ваши сообщения были взломаны: дело в том, что оно служит для идентификации человека, который инициировал загрузку Access. Если процесс SSIS пытается открыть его с каждым известным паролем по очереди и завершается неудачно со всеми из них, то считается, что пакет был введен в систему неуполномоченным лицом и, следовательно, может быть подозрительным.

Это меньше для предотвращения вредоносного кода и больше для предотвращения ввода вредоносных данных в вашу систему.

НТН

Mike