Перейти к содержимому. | Перейти к навигации

Персональные инструменты
Вход Регистрация
Вы здесь: Главная ЧИТАЛЬНЫЙ ЗАЛ Безопасность баз данных Совершенно секретно: безопасность баз данных предприятия
Навигация
 

Совершенно секретно: безопасность баз данных предприятия

Операции с документом
ЕСЛИ ПРЕДПРИЯТИЕ ДОРОЖИТ СВОЕЙ ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТЬЮ, И КАЖДЫЙ РАБОТНИК МОЖЕТ ЛЕГКО ПОЛУЧИТЬ НЕОБХОДИМУЮ (И НЕ БОЛЕЕ ТОГО) ИНФОРМАЦИЮ, ТО КОМПАНИЯ МОЖЕТ НАДЕТЬСЯ НА РОСТ ПРОИЗВОДИТЕЛЬНОСТИ. НО ЕСЛИ ДАННЫЕ НЕ УПОРЯДОЧЕНЫ, ТО, НЕСМОТРЯ НА ЭНТУЗИАЗМ СОТРУДНИКОВ, В БОЛЬШИНСТВЕ СЛУЧАЕВ ПРЕДПРИЯТИЕ ОЖИДАЕТ КРАХ.

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

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

Основа доступа

В большинстве организаций, где я работал или с которыми мне приходилось сталкиваться по долгу службы, все администраторы и программисты имели полный доступ к базам данных, а любой сотрудник отдела ИТ мог делать в сети все, что угодно. Почему так происходит? Этому есть два объяснения:

  1. Работая в одном отделе или департаменте, сотрудники видят друг друга каждый день по 8 часов, и, естественно, у них завязываются дружеские отношения. Как же не дать другу доступ к информации? Тем не менее, дружба дружбой, а работа есть работа.
  2. Распределение некоторых прав доступа и изменение какой-то конфигурации может потребовать определенных привилегий. Администраторы иногда ленятся или просто считают, что программисты выполнят настройку лучше, поэтому дают им излишние права доступа. На самом деле, программисты не должны заниматься администрированием, и у них не должно быть на это прав.

На моем опыте второй пункт встречается очень часто, поэтому мы рассмотрим его более подробно. Разрабатывая программы для баз данных, программисты знают пароль суперпользователя или просто имеют права администратора базы данных. Это излишне и крайне небезопасно. Полные права должен иметь только администратор базы и больше никто. Даже начальник отдела, директор и лучшие друзья могут обойтись меньшими привилегиями. Например, для разработки программ достаточно иметь права владельца схемы в базе данных Oracle, где находятся рабочие таблицы. Этого достаточно для создания новых таблиц, пакетов, индексов и любых других объектов, а также для распределения прав доступа к объектам схемы другим пользователям. Права системы для полноценной работы абсолютно не нужны.

Если в вашем штате нет администратора баз данных, то это очень плохо. Лучше, когда за базу данных, ее производительность, оптимизацию и безопасность отвечает отдельный сотрудник. В крайнем случае, необходимо выделить одного программиста, который будет ответственным, и только он будет иметь исключительные права.

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

Пользователи и роли

Для распределения прав доступа в базах данных используется два типа объектов – пользователи и роли. Роли подобны группам, которые объединяют пользователей, имеющих схожие права. Например, всем бухгалтерам может потребоваться доступ к финансовым документам. Чтобы не выдавать права каждому бухгалтеру в отдельности, их можно объединить в роль, а затем уже этой роли определить необходимый доступ.

Как видите, принцип работы ролей схож с группами в ОС Windows, но, тем не менее, имеет и отличия. Недаром в базе данных могут быть реализованы все три типа объектов – пользователи, группы и роли, но в большинстве баз реализуют только два – первый и последний. Всеми этими объектами необходимо управлять и отслеживать, чтобы каждый пользователь, наследуя права, предоставляемые ролями, имел доступ только к тем данным, которые действительно необходимы для решения поставленных задач. К правам доступа нужно относиться как к правилам сетевого экрана, потому что с их помощью можно решить одну и ту же задачу – позволить пользователю выполнять только определенные действия и предотвратить возможную потерю данных или разрушение БД.

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

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

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

Аудит

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

SELECT user from dual

Этот запрос вернет имя пользователя, под которым открыто соединение с сервером. Если под одним именем может войти несколько человек, то идентифицировать, кто именно вошел, можно, но это уже сложнее. Следующий запрос позволяет получить более детальную информацию о сессии:

select s.user#, s.username, s.osuser, s.terminal, s.program
from sys.v_$session s
WHERE username=user

Здесь происходит обращение к представлению v_$session из системной схемы sys. Это представление возвращает информацию о соединениях с сервером. В секции WHERE мы ограничиваем вывод только текущим пользователем. В качестве результата запрос вернет идентификатор пользователя, имя, имя в ОС, терминал и программу, из которой создано подключение.

Теперь, зная имя и компьютер, пользователь идентифицируется однозначно.

Чтобы узнать, в какие роли входит текущий пользователь, можно выполнить следующий запрос:

SELECT GRANTED_ROLE
FROM dba_role_privs
WHERE grantee=user

Безопасность учетных записей

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

Мы также не будем говорить о том, что пароль должен быть сложным. Это правило относиться ко всем IT-областям и должно быть известно даже начинающему пользователю.

Мы поговорим о том, что касается именно баз данных.

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

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

Имя пользователя и пароль никогда не должны сохраняться в программе! Доступ в саму программу также должен быть ограниченным, а для стороннего человека и вовсе невозможным. Вполне логично будет объединить обе авторизации в одну. Каждому пользователю в организации необходимо завести отдельную учетную запись на сервере баз данных с необходимым минимумом прав, и именно эти имя/пароль должны использоваться при авторизации в программе. Можно использовать распространенную и очень эффективную логику - если с помощью введенных данных программа смогла авторизоваться в базе данных - доступ разрешен, если же нет, то необходимо прервать выполнение программы. Просто и эффективно, ведь мы задействовали авторизацию базы данных.

Чтобы отслеживать попытки доступа с одним именем пользователя с разных компьютеров, можно выполнить следующий запрос:

select s.username, s.terminal, count(*)
from sys.v_$session s
WHERE username=user
HAVING count(*)>1
GROUP BY s.username, s.terminal

В идеале, он не должен вернуть ни одной записи.

Представления

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

Когда лучше использовать представления, а когда нет? Для начала определимся, в чем кроется недостаток. Представление – это запрос SELECT на выборку данных. Он может обращаться как к одной, так и к нескольким таблицам. Если просто выбрать данные из представления, то падения производительности не будет. Однако мы можем использовать представления в других запросах на выборку данных и обращаться к ним, как к таблицам. Например:

SELECT список полей
FROM представление, таблица1, таблица2
WHERE какие-то параметры

В данном случае запрос выбирает данные из представления и двух таблиц. При этом устанавливается связь между всеми объектами и дополнительное условие. А теперь посмотрим на этот запрос так, как видит его оптимизатор базы данных:

SELECT список полей
FROM (SELECT ...), таблица1, таблица2
WHERE какие-то параметры

В данном случае я заменил представление на абстрактный запрос SELECT (он указан в скобках), из которого и состоит view. Получается, что сервер видит запрос с подзапросом. Если подзапрос возвращает динамические данные, а не статическое значение, то такая выборка данных будет работать медленнее, чем если бы мы написали то же самое, избавившись от подзапроса.

Если у вас нет глубокого вложения запросов (запрос-представление1-представление2...), то можно смело использовать view, без опаски потерять слишком много тактов в производительности. Потери минимальны, зато вы получаете лишний уровень безопасности, на который можно распределять права доступа.

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

Без крайней необходимости никогда не стоит выдавать полный доступ на объекты. Чтобы не выдать лишнего, я всегда начинаю распределение прав с разрешения только выборки данных (то есть выполнения запроса SELECT). Если пользователю действительно необходима вставка новых записей, соответственно, нужно добавить разрешение INSERT на определенную таблицу.

Наиболее опасными для данных являются операции изменения и удаления, - UPDATE и DELETE соответственно. К распределению этих прав нужно подходить еще более тщательно. Убедитесь, что данные действительно могут изменяться или удаляться, и только в этом случае выделяйте соответствующие права. Некоторые таблицы по своей сути должны только пополняться.

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

Предоставление прав происходит с помощью оператора GRANT. В общем виде он выглядит следующим образом:

GRANT на что давать права ON объекты TO пользователи или роли

Например, следующий запрос предоставляет право на вставку и просмотр таблицы TestTable пользователю User1:

GRANT Select, Insert ON TestTable TO User1

Какие роли уже выданы пользователю, можно легко увидеть с помощью SQL Navigator. Для этого в версии 4.4 в дереве объектов выбираем раздел Users/Имя пользователя. Здесь вы увидите раздел Object Privileges, в котором и находятся все разрешенные пользователю действия.

Ключи

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

Не стоит бояться внешних ключей. Они предоставляют нам удобный способ контроля целостности данных со стороны сервера баз данных, усиливая безопасность, которая, как известно, лишней не бывает. То, что могут возникнуть проблемы с удалением - скорее плюс, ведь лучше не удалить данные, чем потерять их навеки. Внешний ключ, если он используется совместно с индексом, практически не уменьшает производительности. Это всего лишь небольшая проверка во время удаления данных или изменения ключевого поля, по которому происходит связь данных в разных таблицах.

Резервное копирование

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

Необходимо заранее разработать наиболее эффективную политику резервного копирования. Что под этим понимается? Простои в работе после потери данных и до момента восстановления работоспособности должны быть минимальны. Минимальными должны быть и потери данных, а само резервирование не должно мешать работе пользователей. Если позволяют финансы и возможности, то лучше использовать такие системы как RAID, кластер или даже репликацию данных.

Резервное копирование и восстановление – это отдельная и очень интересная тема. Не затронуть ее здесь мы не могли, но и рассматривать полностью не будем.

Итого

Я рассказал об основах безопасности, сделав небольшой уклон в сторону Oracle. Это только начало, и в будущем мы вернемся к этой теме, чтобы рассмотреть ее глубже. Но не стоит забывать, что средства защиты, предоставляемые базой данных – это только один уровень, а защита должна быть многоуровневой. Чтобы хоть немного спать спокойно, в сети, на серверах и всех компьютерах необходимо реализовать весь комплекс безопасности, а именно – антивирусы, антишпионы, сетевые экраны VPN, IDS и так далее. Чем больше уровней защиты, тем сложнее будет их преодолеть.

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

Безопасность необходима! И не только для защиты от хакеров, но и от действий «начинающих» пользователей, которые могут разрушить данные по своей неопытности.

Об авторе:

Михаил Фленов - Профессиональный программист. Автор бестселлеров «Библия Delphi», «Программирование в Delphi глазами хакера», «Программирование на C++ глазами хакера». Некоторые книги переведены на иностранные языки и популярны в США, Канаде, Польше и других странах. Основал компании Heapar Software (www.heapar.com) и CyD Software Labs (www.cydsoft.com).

Источник: itspecial.ru

Comments (0)

Как стать участником |  Что может участник  |  Как работать с порталом  |  Реклама |  Авторские права  |  Контакты  |  Конкурсы  |  RSS  |  Форум
©2003 - 2018 GlobalTrust
Рейтинг@Mail.ru Rambler's Top100 Yandex