Безопасность базы данных

Выключите его и протрите диски .... несколько раз. Чуть менее экстремальный

Во-первых, защитите сервер, хранилище, сеть и уровень ОС.

1. Сервер базы данных должен иметь минимальное количество открытых портов (например, только SSH на 22-м порте и приемник на 1521-м). Также остерегайтесь исходящих соединений. База данных может делать HTTP-запросы, отправлять электронные письма и все такое ... что вам, вероятно, не нужно в безопасной среде.
2. Никто не должен иметь доступа к серверу базы данных. На самом деле, возможно, самый старший администратор базы данных нуждается в доступе, и один заместитель на случай, если старший администратор базы данных болен или недоступен по иным причинам. Вы можете проверить весь доступ. Вы можете заставить администраторов баз данных запрашивать доступ у системного администратора, прежде чем они получат доступ к серверу. Вы, вероятно, захотите заблокировать то, с чего они могут получить к нему доступ (например, конкретный рабочий компьютер), а также, возможно, время.
3. Следует использовать прозрачное шифрование данных, чтобы все данные в базе данных были зашифрованы до попадания в файлы. Таким образом, даже если кто-то получит диски или резервные копии, он не сможет их прочитать.
4. Возможно, вы захотите зашифровать сетевой трафик между базой данных и приложением.

Затем вы хотите заблокировать доступ к базе данных пользователей

1. Обычно доступ владельцев схемы должен требоваться только для установки / обновления. Кроме того, схема должна быть заблокирована.
2. безопаснее отделить прикладной уровень в БД, чтобы учетные записи приложений могли выполнять только предварительно определенные функции (т.е. не могли удалять каждую строку в таблице). Уровень приложения БД является очень хорошей защитой от внедрения SQL, потому что подключенный пользователь просто не имеет разрешений на выбор в таблицах.
3. Храните зашифрованные значения вместо открытого текста и хешированные значения вместо зашифрованных значений и не храните ничего, что вам не нужно. Вам действительно нужны имена людей, адреса, номера телефонов, кредитные карты, SSN, пароли?
4. В зависимости от вашей архитектуры вам могут быть полезны пароли, срок действия которых истекает регулярно, или аутентификация с помощью другого механизма.

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

Довольно открытый вопрос.

Хорошее начало - прочитать некоторые основы, В Википедии есть хорошая статья в теме. Затем вам нужно изучить детали вашей конкретной системы. Почти все движки баз данных предоставляют массу информации о том, как конкретно защитить свои системы. И не забудьте заглянуть за горизонт: "защищена" не только база данных, но и система, в которой она работает.

SQL-инъекция - распространенная, но одна из многих проблем безопасности, на которые следует обратить внимание.

Вот контрольный список для безопасности SQL Server, который, кажется, сосредоточен на конфигурации самого SQL-сервера: http://www.sqlsecurity.com/FAQs/SQLSecurityChecklist/tabid/57/Default.aspx

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

В Oracle частый выбор дизайна, который я вижу, заключается в том, что приложение всегда входит в систему как один пользователь / схема базы данных - владелец всех объектов для этого приложения.

Лучше всего иметь одного пользователя / схемы, который владеет объектами приложения, тогда REVOKE CREATE SESSION от этого пользователя. Затем создайте другого пользователя / схему, которая не будет владеть объектами (за исключением, возможно, синонимов), которые будут использоваться приложением для входа в базу данных. Затем выдайте минимально необходимые разрешения (SELECT, INSERT, UPDATE, DELETE, EXECUTE и т. Д.) Пользователю приложения.

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

В противном случае, если приложение входит в систему как владелец, невозможно REVOKE любые привилегии на любой из объектов.