Большинство системных администраторов осознают риск выполнения хакерами деструктивных команд, таких как DROP или DELETE, для баз данных SQL, которыми они управляют. Есть ли способ полностью отключить выполнение таких команд, возможно, настроив MySQL / MS SQL / PostgreSQL или изменив исходный код, если они имеют открытый исходный код, удалив эти опасные функции.
Once you have your webapp online,
would someone with honorable intentions
ever need to DROP a table?!
Это может быть святым Граалем для «первичной» безопасности БД, вместо того, чтобы пытаться предотвратить эти совершенно ненужные команды. Конечно, в период разработки или обслуживания они могут быть повторно включены, а затем отключены, когда в них нет необходимости.
Триггеры DDL в SQL Server 2005 могут запрещать удаление или изменение таблиц.
Если вы ограничиваете свое взаимодействие с базой данных хранимыми процедурами, вам не о чем беспокоиться. Учетная запись приложения может запускать только сохраненные процессы, поэтому не будет разрешений для внедрения sql.
Если вы не можете этого сделать, вы можете удалить права на удаление и выполнить любой тип DDL. Это лучше, чем ничего. Но если кто-то хочет обновить все ваши данные нулевыми значениями, они могут.
Вы воля иметь резервную копию, которая постоянно обновляется, если у вас есть ценные данные, или вы окажетесь без работы / бизнеса.
Похоже, вы могли бы захотеть проверить брандмауэр базы данных. GreenSQL имеет открытый исходный код: http://www.greensql.net/
Ура
Вам не нужно изменять код БД, потому что он уже существует. Просто люди этим не пользуются. Большинству веб-приложений требуется самое большее возможность вставки, выбора, обновления, удаления и создания. Многие процессы установки проводят вас через процесс использования привилегированного пользователя для создания необходимых учетных записей и баз данных с минимальными привилегиями. IIRC mediawiki делает это очень хорошо.
Однако я не могу сосчитать количество найденных мной веб-приложений, в которых пользователь db веб-приложения имеет полные привилегии для своей базы данных или, что еще хуже, для всей установки db. Кроме того, некоторые приложения созданы таким образом, что для их создания требуется слишком много привилегий. Или не используйте внутренние привилегированные и непривилегированные учетные записи для функций администратора.
Это ничем не отличается от доступа к файлам. Учетная запись пользователя должна иметь абсолютный минимум прав, необходимых для выполнения работы. Такие разрешения, как удаление, должны быть предоставлены только учетной записи уровня администратора, если это не является абсолютно неизбежным, и в этом случае дизайн приложения, возможно, следует пересмотреть. Удаление часто требуется, но его следует ограничивать только теми таблицами, где это необходимо.
Код не следует изменять, если при предоставлении разрешений используются осторожность и здравый смысл. Полное удаление потенциально опасных команд может привести к тому, что система базы данных станет неподдерживаемой.
Да, когда моя база данных является производственной, мне может потребоваться удалить созданные мной временные таблицы.
Если вы действительно параноик, вам, вероятно, следует, чтобы ваши разработчики использовали представления и хранимые процедуры, чтобы учетная запись, которая обычно имеет доступ к таблицам, не могла напрямую манипулировать ими, а вместо этого должна была обращаться к ним через представление / процедуру.
По крайней мере, с mysql вам не нужно давать учетным записям возможность создавать и удалять таблицы. Найдите время и посмотрите на разрешения системе и просто правильно ограничьте свои учетные записи.
Другой вариант, который вы могли бы использовать за счет производительности, - это запустить весь доступ через Прокси MySQL с параноидальным фильтром, блокирующим все, что вам не нравится.
Что мы сделали, так это добавили всех к роли db_denydatawriter (только SQLServer), которая удаляет все разрешения на вставку, обновление и удаление.
Затем мы контролируем весь наш доступ к базе данных для наших веб-пользователей с помощью хранимых процедур. При условии, что вы не дадите им разрешение на создание собственных хранимых процедур и при условии, что вы не разрешите им выполнять произвольный SQL внутри хранимых процедур, вы довольно хорошо заблокированы.
Это выходит за рамки невозможности отбрасывать таблицы, но если вы не используете хранимые процедуры повсюду, вы можете столкнуться с большой битвой при преобразовании вашего кода.