Последствия для безопасности восстановления резервной копии из неизвестного источника?

Сценарий : вы передали резервную копию базы данных и сказали восстановить ее на сервере (на котором уже размещены другие базы данных), но не получили никакой полезной информации о том, что содержит резервная копия или следует ли доверять источнику.

Вопрос 1 : Каковы потенциальные последствия восстановления резервной копии, которая вполне может быть вредоносной?

Вопрос 2 : Что вы можете сделать, чтобы защитить свой сервер / данные в других базах данных от воздействия восстановления потенциально вредоносной резервной копии? RESTORE VERIFYONLYКазалось бы, хороший первый шаг. Окончательный ответ, вероятно, заключается в «восстановлении базы данных в виртуальной машине с песочницей без доступа к внешнему миру», но давайте предположим, что эта опция не обсуждается. Что еще нужно сделать в этой ситуации?

База данных может содержать вредоносный код, возможно, процедуру, которая собирается изменить пароль для входа в систему «sa» или удалить каждую базу данных. Однако я вижу, что причиной проблемы является то, что отдельный человек восстанавливает базу данных, а затем вручную выполняет любой код в этой базе данных. Это не будет выполняться каким-либо автоматическим способом.

В базе данных нет параметров, которые можно было бы применить, чтобы SQL Server автоматически выполнял некоторый бит кода в базе данных после восстановления его на сервере. Если бы это произошло, я бы ожидал, что Microsoft утратит сертификат Common Criteria для этого продукта. Это большая ошибка, которую я допустил в СУБД.

Есть некоторые профилактические меры, которые вы могли бы сделать.

1. Убедитесь, что никто, кроме одного системного администратора, не имеет доступа к восстановленной базе данных.
2. Переведите БД в однопользовательский режим после завершения восстановления.
3. Проверьте код внутри всех хранимых процедур и функций и триггеров внутри этой базы данных.
4. Выполните dbcc checkdb, чтобы убедиться, что нет проблем с целостностью.
5. Проверьте пользователей, которые раньше имели доступ к базе данных, и удалите их всех.
6. Начните разрешать доступ, очень ограниченный определенными объектами, проверенными вами.

Как сказал Шон, код не будет выполняться сам по себе, если какая-то хранимая процедура, которая кажется vbalid, не имеет исполняемого кода другого вредоносного кода. Это причина проверки кода внутри каждого из них, прежде чем переходить в многопользовательский режим.

Я подхожу к этому, но могу вспомнить хотя бы один опасный сценарий: если вы восстанавливаете базу данных, в которой есть файловый файл , эти файлы теперь находятся в вашей сети по умолчанию (и особенно на вашем SQL Server). Вы можете восстановить вирус.

Конечно, это само по себе ничего не изменит - вирус вдруг не станет чувствительным, но если ваши пользователи попытаются получить доступ к файлу, они могут быть заражены. (Привет, я сказал, что достигал.) Я предполагаю сценарий, когда внешний хакер хочет получить вредоносное ПО в двери, и затем он отправляет электронное письмо Бобу в бухгалтерии, говоря: «Вот файл: \ sqlserver \ filetableshare \ myvirus.exe "- в этот момент он прошел через ваши брандмауэры без обнаружения, и теперь мы используем ваши внутренние антивирусные и антивирусные инструменты.

Восстановление VERIFYONLY может показаться хорошим первым шагом. Окончательный ответ, вероятно, заключается в «восстановлении базы данных в виртуальной машине с песочницей без доступа к внешнему миру», но давайте предположим, что эта опция не обсуждается. Что еще нужно сделать в этой ситуации?

Функция Restore verifyonly проверяет целостность базы данных, и НЕ БУДЕТ сообщать вам, содержит ли резервная копия вредоносный код или нет. RESTORE VERIFYONLY не пытается проверить структуру данных, содержащихся в томах резервных копий. Очень неприятно, что если резервное копирование происходит изнутри фирмы, где вы работаете, может быть злонамеренным, но если оно исходит от какой-то третьей стороны, вам нужно быть осторожным, как указал Шон.

Документация Microsoft Online гласит, что

• В целях безопасности мы не рекомендуем подключать или восстанавливать базы данных из неизвестных или ненадежных источников. Такие базы данных могут содержать вредоносный код, который может выполнять непреднамеренный код Transact-SQL или вызывать ошибки, изменяя схему или физическую структуру базы данных. Прежде чем использовать базу данных из неизвестного или ненадежного источника, запустите DBCC CHECKDB для базы данных на непроизводственном сервере, а также проверьте код, такой как хранимые процедуры или другой определенный пользователем код, в базе данных.

Вопрос в основном касается резервного копирования, содержащего вредоносное ПО, но также возможно получить нежелательное и потенциально вредоносное поведение от самой операции восстановления.

В прошлом я случайно обнаружил, что можно аварийно завершить работу SQL Server, попытавшись восстановить поврежденный файл резервной копии, в результате чего SQL Server попытается прочитать файл резервной копии после завершения и произойдет сбой. Я не уверен, какие версии восприимчивы или точно, что требуется для воспроизведения проблемы. Я документированы некоторые ограниченные детали здесь , когда я столкнулся с этой проблемой несколько лет назад.

Какой риск существует при восстановлении неизвестной базы данных из неизвестного источника? Никто.

Какой риск существует, если разрешить неизвестному приложению подключаться с использованием учетной записи sysadmin для подключения к этой базе данных и запуска кода? МНОГО! Если учетная запись приложения имеет права только в пределах базы данных и не имеет доступа на уровне сервера, то она ничего не может сделать вне базы данных. Это в основном сводится к правильной настройке инфраструктуры безопасности на сервере с самого начала.

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

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

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

Существует не так много опасностей, за исключением некоторых далеко идущих, предложенных здесь. Как уже упоминалось, трудно выполнить автозапуск материала в самой резервной копии базы данных. Нужен какой-то внешний механизм запуска.

Получите старый ноутбук / настольный компьютер и ознакомительную версию программного обеспечения для вашей базы данных (SQLExpress), если лицензирование является проблемой. Скопируйте файл резервной копии на устройство, отключите сеть / беспроводную сеть и выполните восстановление. Тогда начинай копать. Потратьте столько времени, сколько вам нужно, потому что есть много мест, которые можно скрыть, большинство из них уже освещены в других сообщениях в этой теме.

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