Меню
ГлавнаяПрограммы

Защита систем управления базами данных. Защита информации в базах данных

    данные в любой таблице для выборки и изменения должны быть доступны ограниченному кругу пользователей;

    для некоторых таблицы необходимо обеспечить выборочный доступ к ее столбцам;

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

Схема доступа к данным в реляционных СУБД базируется на принципах:

    СУБД от имени конкретного пользователя выполняет операции над базой данных в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом БД.

    Объекты доступа – это элементы БД, доступом к которым можно управлять (разрешать или запрещать). Конкретный пользователь обладает конкретными правами доступа к конкретному объекту.

    Привилегии (priveleges) – это операции, которые разрешено выполнять пользователю над конкретными объектами.

2.5.4.2. Механизм ролей в СУБД

Способы определения групп пользователей:

    один и тот же идентификатор используется для доступа к БД целой группы физических лиц (например, сотрудников одного отдела);

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

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

2.5.5. Защита информации в сетях

2.5.5.1. Общая характеристика сетевых атак

Классификация удаленных атак выполняется по различным критериям:

1. По характеру воздействия:

Пассивные – внешние, никак не влияют на работу вычислительной системы и на передаваемые данные (например, простое прослушивание);

Активные – оказывают непосредственное влияние на работу системы (изменение конфигурации распределенной вычислительной системы (РВС), нарушение работоспособности и т. д.).

2. По цели воздействия:

Угроза раскрытия (утечки) информации, т.е. перехват информации без цели модификации;

Угроза целостности – несанкционированный доступ к информации и возможность ее модификации;

Угроза отказа в обслуживании – нарушение работоспособности системы.

3. По моменту начала атаки:

По запросу от атакуемого объекта (DNS,ARP– запросы);

По наступлению ожидаемого события на атакуемом объекте (например, разрыв TCPсоединения);

Безусловные атаки – осуществляются немедленно и безотносительно к состоянию системы и атакуемого объекта.

4. По наличию обратной связи:

С обратной связью (на некоторые запросы, переданные на атакуемый объект, атакующему требуется получить ответ);

Без обратной связи.

5. По расположению субъекта атаки (источника атаки):

Внутрисегментное расположение источника;

Межсегментное.

6. По уровню OSI(МВОС)

2.5.5.2. Типовые угрозы безопасности

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

Приведем характеристики типовых угроз в соответствии с рассмотренной классификацией:

1. Анализ сетевого трафика – внутрисегментные пассивные угрозы раскрытия без обратной связи, применяемые на физическом или канальном уровне.

2. Подмена объекта вычислительной системы – при установлении виртуального соединения, активное воздействие, угроза раскрытия или угроза целостности. Выполняется по событию. Захватывает канальный, сетевой или транспортный уровни.

3. Внедрение ложного объекта:

а) навязывание ложного маршрута, возможно из-за наличия протоколов, позволяющих удаленно изменять маршрутизацию в Интернет (протоколы RIP, OSPF, ICMP, SNMP);

б) использование недостатков алгоритмов удаленного доступа (протокол TCP, DNS-запрос).

4. Отказ в обслуживании (DoS) - активное воздействие; безусловная; межсегментное и внутрисегментное; на транспортном и прикладном уровнях.

2.5.5.3. Типовые атаки в сетях TCP/IP

Анализ трафика (sniffing)

Sniffingпозволяет изучить логику работыPBC, позволяет перехватить потоки данных, которыми обмениваются объекты – несанкционированный доступ к сети без модификации данных.

Защита: шифрование данных; также можно шифровать файлы и обмениваться на файловом уровне; коммутация Ethernet (рисунок 7); выделенный канал связи между объектами РВС.

Ложный ARP сервер.

Связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного уровня может быть вложен в пакет сетевого уровня, который, в свою очередь, вложен в пакет канального уровня. Спроецировав это утверждение на сетевую ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) вложен в пакет IP (сетевой уровень), который, в свою очередь, вложен в пакет Ethernet (канальный уровень). Таким образом, структура TCP-пакета выглядит так, как показано на рисунке 8.

Для получения Ethernetадреса служит протоколARP. Он ставит в соответствие адресу сетевой карты адрес конкретного компьютера. Он работает следующим образом:

а) ЭВМ посылает широковещательный (всем сразу) ARP-запрос с требуемымIP-адресом.

б) ЭВМ с затребованным адресом посылает на Ethernet-адрес автора запроса ответ с указанием своегоEthernet-адреса. Запрашиваемая ЭВМ получает ответ и записывает паруIPиEthernetадресов в свою локальнуюARPтаблицу.

Механизм атаки: hostатакующего посылает ложныйARPответ и в будущем будет получать все данные, адресованные на другой адрес (рисунок 9).

Ложный DNS-сервер

Ложный DNSработает следующим образом:

    Hostпосылает запрос на определение адреса информационно поисковомуDNSсерверу.

    Если домен локальный, то сервер сам отвечает на запрос, иначе отсылает запрос корневому DNSсерверу.

    Корневой сервер определяет локальный сервер для домена и отсылает ответ ему.

На любом этапе ответы кэшируются сервером и клиентом.

Выделяют 3 сценария атаки:

1) Перехват запроса и попытка ложного ответа.

2) Шторм ложных DNS ответов от имени настоящего DNS сервера.

3) Шторм ложных DNS ответов на атакуемый DNS сервер.

Как видно из приведенных формулировок, идеи атак достаточно близки к идее ложного ARP-сервера. СлужбаDNSработает по протоколуUDP, который отличается отTCPтем, что не гарантирует установление соединения и доставку.

Первый сценарий проиллюстрирован рисунком 10. Атакующий должен находиться на пути основного трафика или в сегменте настоящего DNS сервера.

Рисунок 9. Атака путем использования ложного ARP-сервера

а – фаза ожидания ARP-запроса; б – фаза атаки; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном ARP-сервере

Рисунок 10. Атака путем перехвата запроса к DNS-серверу

а – фаза ожидания DNS-запроса; б – фаза передачи атакующим ложного DNS-ответа; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном DNS-сервере

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

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

    использование файла hosts. (неудобный способ для большого количества машин);

    использование протоколов ТСР вместо UDP;

    для защищенности сети стараются избегать применения DNS – службы вообще.

Защита от Интернет-атак:

    фильтры на входе и на выходе из сети, контроль маршрутов;

    фиктивные адреса и шлюзы (socks,proxy);

    использования TCP, а неUDP(named,NFS);

    статические ARPиDNS;

    шифрование трафика (IPSEC,SKIP,SSL,SSH);

    туннелирование с шифрованием;

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

    контроль за сообщениями CERTиCIAC(американские центры по компьютерной безопасности:www.cert.org иwww.ciac.org );

    применение антивирусных средств (на почтовых серверах и в браузерах);

    использование средств автоматизированного контроля безопасности (SATAN,SAFEsuite,RealSecure,JohnTheRipper,Orge).

Кроме того, для защиты от проникновения путем использования Web-приложений применяют следующие решения:

    отключение Javaи всех видов языков сценариев, кромеJavaScript(не будут работать многие страницы);

    применение онлайновых антивирусов (AVP);

    выделение специальной ЭВМ для доступа в Интернет.

На сегодняшний день из технологий динамических страниц более-менее безопасными для клиентской ЭВМ в Интернете можно назвать только DHTML(HTML4.0) иJavaScript. Все остальное лучше отключить.

Рисунок 11. Атака путем организации шторма DNS-ответов от ложного сервера

а – фаза организации шторма ложных DNS-ответов; б – фаза получения атакуемым хостом DNS-ответа на свой запрос; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном DNS-сервере

Рисунок 12. Атака путем организации шторма DNS-ответов на атакуемый DNS-сервер

а – фаза ожидания атакующим DNS-запроса от DNS-сервера (для ускорения атакующий генерирует необходимый DNS-запрос); б – фаза передачи атакующим ложного DNS-ответа на DNS-сервер; в – DNS-сервер выдает IP-адрес атакующего хоста в ответ на запросы

Стандарт Х.800 описывает основы безопасности в привязке к эталонной семиуровневой модели. Стандарт предусматривает следующие сервисы безопасности:

    аутентификация (имеются в виду аутентификация партнеров по общению и аутентификация источника данных);

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

    конфиденциальность данных - в Х.800 под этим названием объединены существенно разные вещи - от защиты отдельной порции данных до конфиденциальности трафика;

    целостность данных – данный сервис подразделяется на подвиды в зависимости от того, что контролируется - целостность сообщений или потока данных, обеспечивается ли восстановление в случае нарушения целостности;

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

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

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

Базовые протоколы, наиболее полезные с точки зрения безопасности, включают в себя - Ipsec,DNSsec,S/MIME,X.509v3,TLSи ассоциированные с ними. Наиболее проработанными на сегодняшний день являются вопросы защиты наIP-уровне. Спецификации семействаIPsecрегламентируют следующие аспекты:

    управление доступом;

    контроль целостности на уровне пакетов;

    аутентификация источника данных;

    защита от воспроизведения;

    конфиденциальность (включая частичную защиту от анализа трафика);

    администрирование (управление криптографическими ключами).

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

Туннелирование может применяться как на сетевом, так и прикладном уровнях. Например, стандартизовано туннелирование для IР и двойное конвертование для почты Х.400.

На транспортном уровне аутентичность, конфиденциальность и целостность потоков данных обеспечиваются протоколом TLS(TransportLayerSecurity,RFC2246). Подчеркнем, что здесь объектом защиты являются не отдельные сетевые пакеты, а именно потоки данных (последовательности пакетов). Злоумышленник не сможет переупорядочить пакеты, удалить некоторые из них или вставить свои.

На основе TLSмогут строиться защищенные протоколы прикладного уровня. В частности, предложены спецификации для НТТР надTLS.

2.5.5.5. Архитектура механизмов защиты информации в сетях ЭВМ

В модели ВОС различают следующие основные активные способы несанкционированного доступа к информации:

    маскировка одного логического объекта под другой, обладающий большими полномочиями (ложная аутентификация абонента);

    переадресация сообщений (преднамеренное искажение адресных реквизитов);

    модификация сообщений (преднамеренное искажение информационной части сообщения);

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

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

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

    Аутентификация источника данных - подтверждение подлинности источника (абонента-отправителя) сообщения.

    Управление доступом (разграничение доступа) - обеспечивает защиту от несанкционированного доступа к ресурсам, потенциально доступным посредством ВОС.

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

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

    Засекречивание поля данных - обеспечивает конфиденциальность отдельных полей данных пользователя на всем соединении или в отдельном сервисном блоке данных.

    Засекречивание трафика - препятствует возможности извлечения информации из наблюдаемого графика.

    Целостность соединения с восстановлением - позволяет обнаружить попытки вставки, удаления, модификации или переадресации в последовательности сервисных блоков данных. При нарушении целостности предпринимается попытка ее восстановления.

    Целостность соединения без восстановления.

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

    Целостность поля данных в режиме без установления соединения - позволяет обнаружить модификацию выбранного поля в единственном сервисном блоке данных.

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

    Информирование об отправке данных – позволяет идентифицировать отправителя информации на стороне ее получателя.

    Информирование о доставке – предоставляет отправителю информацию о факте получения данных адресатом.

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

    взаимное опознавание (аутентификация) вступающих в связь абонентов сети;

    обеспечение конфиденциальности циркулирующих в сети данных;

    обеспечение юридической ответственности абонентов за передаваемые и принимаемые данные.

Решение последней из названных задач обеспечивается с помощью так называемой цифровой (электронной) подписи.

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

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

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

История развития СУБД

Исторически развитие систем безопасности баз данных происходило как реакция на действия злоумышленников. Эти изменения также были обусловлены общим развитием баз данных от решений на мейнфреймах до облачных хранилищ.

Можно выделить следующие архитектурные подходы:

  • полный доступ всех пользователей к серверу БД;
  • разделение пользователей на доверенных и частично доверенных средствами СУБД;
  • введение системы аудита (логов действий пользователей) средствами СУБД;
  • введение шифрования данных; вынос средств аутентификации за пределы СУБД в операционные системы и промежуточное ПО; отказ от полностью доверенного администратора данных.

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

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

Современные проблемы обеспечения безопасности БД

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

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

Многие уязвимости сохраняют актуальность за счет невнимания или незнания администраторами систем баз данных вопросов безопасности. Например, простые SQL-инъек­ции широко эксплуатируются сегодня в отношении различных web-приложений, в которых не уделяется достаточного внимания входным данным запросов.

Применение различных средств обеспечения информационной безо­пасности является для организации компромиссом в финансовом плане: внедрение более защищенных продуктов и подбор более квалифицированного персонала требуют больших затрат. Компоненты безопасности зачастую могут негативно влиять на производительность СУБД.

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

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

Особенности защиты БД

Хранилища данных включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).

Обеспечение безопасности хранимой информации, в частности, невозможно без обеспечения безопасного управления данными. Исходя из этого, все уязвимости и вопросы безопасности СУБД можно разделить на две категории: зависящие от данных и не зависящие от данных.

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

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

Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, и наличие в нем тех или иных уязвимостей. Причем такие уязвимости, например, как инъекция, выполняются по-разному (sql-инъекция, java-инъек­ция) в зависимости от синтаксиса языка.

Требования к безопасности БД

На основании разделения уязвимостей можно выделить зависящие и независящие от данных меры обеспечения безопасности хранилищ информации.

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

  • Функционирование в доверенной среде.

Под доверенной средой следует понимать инфраструктуру предприятия и ее защитные механизмы, обусловленные политиками безопасности. Таким образом, речь идет о функционировании СУБД в соответствии с правилами безопасности, применяемыми и ко всем прочим системам предприятия.

  • Организация физической безопасности файлов данных.

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

  • Организация безопасной и актуальной настройки СУБД.

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

Следующие требования можно назвать зависящими от данных :

  • Безопасность пользовательского ПО.

Сюда можно отнести задачи построения безопасных интерфейсов и механизмов доступа к данным.

  • Безопасная организация и работа с данными.

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

Основные аспекты создания защищенных БД

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

  • Разработка комплексных методик обеспечения безопасности хранилищ данных на предприятии.

Создание комплексных методик позволит применять их при разработке и внедрении хранилищ данных и пользовательского ПО. Следование комплексной методике позволит избежать многих ошибок управления СУБД и защититься от наиболее распространенных на сегодняшний день уязвимостей.

  • Оценка и классификация угроз и уязвимостей СУБД.

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

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

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

Об авторе

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

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

  • * похищение и фальсификация данных;
  • * утрата конфиденциальности (нарушение тайны);
  • * нарушение неприкосновенности личных данных;
  • * утрата целостности;
  • * потеря доступности.

Вопросы защиты данных часто рассматриваются вместе с вопросами

поддержки целостности данных (по крайней мере, в неформальном контексте),

хотя на самом деле это совершенно разные понятия. Термин защита

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

  • · Под защитой данных подразумевается предотвращение доступа к ним со стороны несанкционированных пользователей.
  • · Под поддержкой целостности данных подразумевается предотвращение

их разрушения при доступе со стороны санкционированных пользователей.

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

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

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

Ниже описаны многочисленные аспекты проблемы защиты данных.

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

Обычно в современных СУБД поддерживается один из двух широко распространенных методов организации защиты данных -- избирательный или мандатный, а иногда оба этих метода. В обоих случаях единица данных (или объект данных), для которой организуется защита, может выбираться из широкого диапазона, от всей базы данных до конкретных компонентов отдельных кортежей. Различия между двумя указанными методами кратко описаны ниже.

В случае избирательного контроля каждому пользователю обычно предоставляются различные права доступа (иначе называемые привилегиями, или полномочиями) к разным объектам. Более того, разные пользователи, как правило, обладают разными правами доступа к одному и тому же объекту. (Например, пользователю U1 может быть разрешен доступ к объекту А, но запрещен доступ к объекту B, тогда как пользователю U2 может быть разрешен доступ к объекту B, но запрещен доступ к объекту А.) Поэтому избирательные схемы характеризуются значительной гибкостью.

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

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

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

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

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

Избирательная схема управления доступом

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

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

GRANT RETRIEVE { S#, SNAME, CITY }, DELETE

TO Jim, Fred, Mary ;

Этот пример иллюстрирует тот факт, что в общем случае полномочия доступа включают четыре описанных ниже компонента.

  • 1. Имя (в данном примере SA3, "suppliers authority three" -- полномочия поставщика с номером 3). Устанавливаемые полномочия будут зарегистрированы в системном каталоге под этим именем.
  • 2. Одна или несколько привилегий, задаваемых в конструкции GRANT.
  • 3. Задаваемое в конструкции ON имя переменной отношения, к которой применяются полномочия.
  • 4. Множество пользователей (точнее, идентификаторов пользователей), которым предоставляются указанные привилегии применительно к указанной переменной отношения, задаваемой с помощью фразы ТО.

Ниже приводится общий синтаксис оператора определения полномочий.

AUTHORITY

GRANT

ON

TO ;

Мандатная схема управления доступом

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

  • 1. Пользователь i может выполнить выборку данных объекта j только в том случае, если его уровень допуска больше классификационного уровня объекта j или равен ему {простое свойство безопасности -- simple security property).
  • 2. Пользователь i может модифицировать объект j только в том случае, если его уровень допуска равен классификационному уровню объекта j (звездное свойство -- star property).

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

"Секретно", в файл с меньшим уровнем классификации, что нарушит всю систему секретности.

Шифрование данных

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

Для изучения основных концепций шифрования данных следует ввести некоторые новые понятия. Исходные (незашифрованные) данные называются открытым текстом.

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

Пример 5.1. Пусть в качестве открытого текста дана следующая строка.

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

Ниже описывается используемый алгоритм шифрования.

1. Разбить открытый текст на блоки, длина которых равна длине ключа шифрования.

AS+KI NGFIS HERS+ CATCH +FIRE

  • (Здесь пробелы обозначены знаком "+".)
  • 2. Заменить каждый символ открытого текста целым числом в диапазоне 00-26, используя для пробела число 00, для А -- число 01,..., для Z -- число 26. В результате получится следующая строка цифр.
  • 0119001109 1407060919 0805181900 0301200308 0006091805
  • 3. Повторить п. 2 для ключа шифрования, в результате чего получится следующая строка цифр.
  • 0512091520
  • 4. Теперь значения, помещенные вместо каждого символа в каждом блоке открытого текста, просуммировать с соответствующими значениями, подставленными вместо символов ключа шифрования, и для каждой суммы из указанных двух значений определить и записать остаток от деления на 27.
  • 5. Заменить каждое число в нижней строке п. 4 соответствующим текстовым символом.

FDIZB SSOXL MQ+GT HMBRA ERRFY

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

Управление безопасностью обычно осуществляется на трех уровнях:

  • * уровень базы данных;
  • * уровень операционной системы;
  • * сетевой уровень.

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

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

В работе рассмотрены некоторые наиболее существенные требования законодательства по защите персональных данных (ПД). Представлены общие подходы к защите баз данных под управлением СУБД. Показан пример защиты ПД с учетом требований законодательства для платформы Oracle - одной из самых широко применяемых в средних и крупных информационных системах.

Закон о защите персональных данных не выполняется. Почему?

Для начала, вспомним некоторые положения №152-Федерального Закона "О персональных данных" .

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

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

Кроме этого, в требованиях закона "О защите персональных данных" №152-ФЗ содержатся некоторые, мягко говоря, непривычные для российских организаций процедуры, такие как:

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

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

Стоит добавить, что по некоторым данным, упомянутая классификация и соответствующие каждому классу требования, согласно постановлению Правительства №781, уже разработаны ФСТЭК, ФСБ и Мининформсвязи России и в ближайшее время будут опубликованы. Этот долгожданный во многом документ прольет свет на эти и другие аспекты практического применения ФЗ-152. Но основные надежды, которые с ним связаны, заключаются в получении практических инструкции по реализации требований закона для государственных организаций, обрабатывающих ПД граждан.

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

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

Закон суров, но справедлив

Не менее интересно и то, какие возможности предусматривает закон для самих граждан - субъектов персональных данных. В дополнение к вышесказанному вспомним другие положения закона. Согласно части 4 статьи 14 ФЗ-152 субъект персональных данных имеет право на получение при обращении или при получении запроса информации, касающейся обработки его ПД, в том числе содержащей: подтверждение факта обработки персональных данных оператором, а также цель такой обработки; способы обработки ПД, применяемые оператором; сведения о лицах, которые имеют доступ к ПД; перечень обрабатываемых персональных данных и источник их получения; сроки обработки ПД, в том числе сроки их хранения; сведения о том, какие юридические последствия для субъекта персональных данных может повлечь за собой обработка его ПД. По сути, это тоже трудновыполнимая задача для оператора, ведь никто не отменял ст.137 УК РФ "Нарушение неприкосновенности частной жизни" от 13 июня 1996г. В статье, в частности, говорится, что уголовную ответственность влечет: незаконное собирание или распространение сведений о частной жизни лица, составляющих его личную или семейную тайну, без его согласия либо распространение этих сведений в публичном выступлении, публично демонстрирующемся произведении или средствах массовой информации, если эти деяния совершены из корыстной или иной личной заинтересованности и причинили вред правам и законным интересам граждан.

Согласно статье 17 ФЗ-152 в случае, если субъект ПД считает, что оператор осуществляет обработку его ПД с нарушением требований настоящего Федерального закона или иным образом нарушает его права и свободы, субъект ПД вправе обжаловать действия или бездействие оператора в уполномоченный орган по защите прав субъектов ПД или в судебном порядке. При этом лица, виновные в нарушении требований, несут административную, гражданскую, уголовную и иную, предусмотренную законодательством, ответственность.

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

Вот основные составляющие системы госконтроля и надзора за обеспечением безопасности ПД при их обработке в ИС:

  • Россвязьохранкультура - уполномоченный орган по защите прав субъектов ПД;
  • ФСБ - Федеральный орган исполнительной власти, уполномоченный в области обеспечения государственной безопасности и применения средств шифрования;
  • ФСТЭК - федеральная служба по техническому и экспортному контролю и противодействия иностранным разведкам - уполномоченный орган в области контроля используемых технических средств защиты;
  • Министерство информационных технологий и связи РФ - порядок проведения классификации информационных систем, содержащих персональные данные.

Таким образом, создается продуманная система государственного контроля операторов, обрабатывающих персональные данные.

Как правильно защищать базы данных?

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

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

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

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

Перейдем к рассмотрению технических средств защиты БД, содержащей персональные данные, более подробно.

Основные компоненты системы защиты баз данных

Классическая схема защиты баз данных (БД) подразделяется на следующие обязательные процедуры:

  • Разграничение доступа - каждый пользователь, включая администратора, имеет доступ только к необходимой ему согласно занимаемой должности информации.
  • Защита доступа - доступ к данным может получить пользователь, прошедший процедуру идентификации и аутентификации.
  • Шифрование данных - шифровать необходимо как передаваемые в сети данные для защиты от перехвата, так и данные, записываемые на носитель, для защиты от кражи носителя и несанкционированного просмотра/изменения не-средствами системы управления БД (СУБД).
  • Аудит доступа к данным - действия с критичными данными должны протоколироваться. Доступ к протоколу не должны иметь пользователи, на которых он ведется. В случае приложений, использующих многозвенную архитектуру, приведенные функции защиты также имеют место, за исключением защиты данных на носителе - эта функция остается за БД.

Всеми перечисленными функциями безопасности в той или иной мере оснащены СУБД и приложения Oracle, что выгодно отличает их от продуктов конкурентов. Рассмотрим указанные процедуры подробнее.

Разграничение доступа

Преследуя цель защиты БД от инсайдерских угроз, для обеспечения разграничения доступа в версии СУБД 10g Release 3 компания Oracle выпустила новый продукт Database Vault , предназначенный для предотвращения несанкционированного доступа к информации пользователей, в том числе наделенных особыми полномочиями, например, администраторов базы данных. Набор правил в Database Vault , разграничивающих доступ, достаточно широк. Например, руководство организации может определить правила, согласно которым для решения задач, предполагающих доступ к критичной информации, потребуется одновременное присутствие двух сотрудников. Таким образом, Database Vault решает следующие проблемы:

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

Защита доступа

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

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

Итак, рассмотрим подробнее способы аутентификации в СУБД Oracle .

Аутентификация средствами операционной системы

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

Аутентификация при помощи сетевых сервисов

Данный вид аутентификации обеспечивает опция сервера Oracle Advanced Security . Она предоставляет следующие службы:

1. SSL - аутентификация использует протокол SSL (Secure Socket Layer) - протокол уровня приложений. Он может использоваться для аутентификации в БД и в общем случае (если далее используется аутентификация пользователя средствами СУБД) не зависит от системы глобального управления пользователями, обеспечиваемой службой каталога Oracle - Oracle Internet Directory .

2. Аутентификация службами третьих сторон.

На основе Kerberos . Применение Kerberos как системы аутентификации с доверенной третьей стороной, основано на использовании, т.н. общего секрета. Это предопределяет безопасность и надежность доверенной стороны и дает возможность использования Single Sign - On , централизованного хранения паролей, прозрачной аутентификации через связи БД (database links), а также средств усиленной безопасности на рабочих станциях.

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

  • протокол SSL
  • набор OCI (Oracle Call Interface - прикладной интерфейс доступа к БД) и PL / SQL функций
  • доверенные сертификаты (trusted certificate), для проверки подлинности сертификатов, предъявляемых пользователями (приложениями)
  • Oracle wallets - ключевые контейнеры, содержащие личный ключ (private key) пользователя, его сертификат и цепочки доверенных сертификатов
  • Oracle AS Certificate Authority - компонента Oracle Application Server , предназначенная для издания сертификатов и дальнейшего управления ими
  • - Oracle Wallet Manager (OWM) - компонента СУБД для управления wallet "ами

На основе RADIUS . СУБД Oracle поддерживает протокол RADIUS (Remote Authentication Dial - In User Service) - стандартный протокол для аутентификации удаленных пользователей. При этом становятся доступны службы и устройства аутентификации третьих производителей, с которыми может взаимодействовать сервер RADIUS (например, устройства генерации одноразовых паролей, биометрические устройства и т.п.).

На основе службы LDAP -каталога. Использование службы LDAP -каталога делает управление аутентификацией и управление учетными записями пользователей (приложений) очень эффективным. В инфраструктуре СУБД Oracle служба каталога представлена следующими компонентами:

  • Oracle Internet Directory (OID) позволяет централизованно хранить и управлять информацией о пользователях (т.н. enterprise -пользователях). Позволяет иметь единственную учетную запись пользователя для многих баз данных. Возможна интеграция со службами каталогов третьих производителей, например, MS Active Directory или iPlanet . OID позволяет гибко управлять атрибутами безопасности и привилегиями каждого пользователя, включая тех, кто аутентифицируется по цифровым сертификатам. Для повышения безопасности во время процесса аутентификации возможно использование SSL -протокола.
  • Oracle Enterprise Security Manager - утилита управления пользователями, группами, ролями и привилегиями.

3. Аутентификация в многоуровневых приложениях

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

Шифрование данных

Для защиты данных, передаваемых в сети, в СУБД Oracle, начиная с версии 8i, используется возможности опции Oracle Advanced Security , в которой предусмотрена функция Network encryption , позволяющая шифровать весь поток данных. Безопасность информации обеспечивается секретностью ключа, которым шифруются данные.

Network encryption позволяет добиться высокого уровня безопасности. Поддерживаются следующие алгоритмы шифрования AES (только 10 g /11g). DES , 3 DES , RC 4(только 10 g /11g).

Защита передаваемых в сети данных в приложениях Oracle обеспечивается протоколом SSL по алгоритмам, которые поддерживается сервером приложений, как правило, это WEB -сервер Oracle.

Защиту данных на носителе обеспечивают два компонента СУБД Oracle - пакеты, реализующие алгоритмы шифрования и опция Transparen t Data Encryption (T DE). Начиная с версии 8i, СУБД Oracle предоставляет для разработчиков приложений пакеты хранимых процедур, реализующих алгоритмы: DES с длиной ключа 56 бит, Triple DES с длиной ключа 112 и 168 бит , A ES с длиной ключа 128, 192 и 256 бит RC 4 (только 10 g /11g).

Опция T DE появилась в версии СУБД Oracle 10g Release 2 как составная часть Advanced Security. Она позволяет выборочно шифровать колонки таблиц с применением алгоритмов Triple DES (c длиной ключа 168 бит), AES (c длиной ключа 128, 192 или 256 бит). Управление ключами шифрования берет на себя ядро БД, а применение такого шифрования не требует переделки клиентского и серверного прикладного ПО. В версии СУБД 11g и выше появилась возможность зашифрования табличного пространства целиком.

Аудит доступа к данным

СУБД Oracle имеет мощные средства аудита действий пользователей, включающих как доступ к данным, так и события регистрации/выхода и изменения структуры БД. Начиная с версии 9i, СУБД оснащается опцией подробного аудита (Fine Grained Audit Control), которая позволяет проводить аудит доступа по условиям, определяемым достаточно гибкими настраиваемыми правилами. Однако, данные средства аудита не позволяет проследить за действиями, которые совершаются администратором базы данных, а также не мешают ему изменять журнал аудита, удаляя любые строки и не оставляя следов подобных действий. Возникшая необходимость аудита деятельности и защиты данных аудита от привилегированных пользователей, включая администраторов БД, побудило Oracle разработать новую концепцию аудита. В её основу положена идея, на которой базируется функционал Database Vault : администратор БД изолирован от управления аудитом, что по поянтным причинам обеспечивает более высокий уровень безопасности БД. Как и в случае Database Vault правила назначения аудита в Audit Vault очень гибкие.

Достаточно ли встроенных средств защиты?

Приведённый нами краткий обзор средств защиты информации, которые корпорация Oracle встроила в свои продукты и технологии, демонстрирует солидный задел для построения ИС с различным уровнем защищенности, отвечающих самым современным требованиям по безопасности. Однако, даже поверхностный взгляд на системы защиты различного ПО, использующего СУБД или сервер приложения Oracle , покажет, что за редким исключением, встроенные средства обеспечения безопасности либо не используются вовсе, либо их заменяют аналогичные по функционалу собственные разработки или готовые разработки, предлагаемые на рынке, либо встроенные средства дополняются ПО сторонних разработчиков.

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

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

От сторонников такого подхода при разработке и эксплуатации ИС чаще всего можно услышать следующие аргументы:

  • наиболее простая и, следовательно, более надежная в плане эксплуатации;
  • низкая стоимость владения;
  • более высокий уровень защиты не требуется.

Конечно, парольная защита не требует дополнительных затрат ни на стадии разработки, ни на стадии эксплуатации ИС - все "заботы" по обслуживанию пользователей и их паролей берет на себя СУБД или сервер приложений. Также отсутствуют затраты на дополнительное оборудование (серверы аутентификации, службы каталогов, устройства хранения ключевой информации и т.д.) и программное обеспечение (лицензии, ПО сторонних производителей и т.д.). Немаловажно, что и требования к квалификации администраторов БД и администраторов безопасности в данном случае значительно ниже, а это - также вопрос экономии. Третий аргумент, видимо, исторически сохраняется с тех времен, когда вопросами безопасности серьезно не занимались.

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

Доводы для такого подхода, примерно, следующие:встроенные средства защиты явно недостаточны и изобилуют уязвимостями;

  • лучше иметь дело с "местной" командой разработчиков, чем надеяться на поддержку вендора;
  • система нормально работает с парольной защитой и лучше ее не трогать, достаточно внедрить дополнительное программное обеспечение по управлению паролями.

Рассмотренные выше два варианта использования средств защиты характерны для ИС, разработанных и внедренных преимущественно в конце 90-х годов прошлого века. Характерный пример - биллинговые системы, самостоятельной разработкой которых занимаются десятки компаний. Не менее яркими примерами являются базы данных здравоохранения и силовых структур. А ведь они содержат внушительные объемы конфиденциальной информации и, в частности, персональных данных, которые обязывает надежно защищать российское законодательство. Является ли такое халатное отношение к защите БД с персональными данными граждан причиной постоянного появления среди пиратских копий фильмов сборников баз данных по физическим и юридическим лицам? Ответ на этот вопрос следует искать, прежде всего, опираясь на недостатки описанных подходов. Предпримем попытку анализа сторонников указанных подходов.

Достаточно ли парольной аутентификации?

Действительно, простота использования парольной защиты не вызывает сомнений. Но простота и надёжность защиты в данном случае малосовместимы. В безопасности и удобстве эксплуатации такая технология себя изживает. Надежность пароля и, следовательно, безопасность его использования, напрямую зависит от его качества (применяемые символы, их регистр, отличие от осмысленных слов). А удобство использования стремительно падает даже при незначительном усилении "безопасности" пароля, ведь запомнить нечитаемую комбинацию символов довольно сложно. Обратимся к цифрам и фактам. Пароли пользователей хранятся в СУБД Oracle в виде хеш-значений и доступны для чтения привилегированным пользователям. Алгоритм вычисления хеша пароля давно известен. Наиболее полное исследование стойкости паролей в Oracle проведено компанией Red - Database - Security GmbH - ведущего мирового эксперта в области безопасности продуктов Oracle. Вот некоторые данные по стойкости паролей для версий СУБД 7-10g:

На компьютере с Pentium 4 3 GHz требуемое время составляет (атака простым перебором):

  • 10 секунд все 5- символьные комбинации
  • 5 минут все 6- символьные комбинации
  • 2 часа все 7- символьные комбинации
  • 2,1 дня все 8- символьные комбинации
  • 57 дней все 9- символьные комбинации
  • 4 года все 10- символьные комбинации

И это при использовании далеко не самого мощного компьютера. При наращивании производительности атака по словарю проводится ещё быстрее. Нельзя сказать, что Oracle не реагирует на подобное положение дел - в версии СУБД 11g положение значительно улучшилось. Был усилен алгоритм выработки хеша и качество формирования паролей. В результате приведенные выше цифры выросли в 2.5-3 раза. Но, несмотря на такие улучшения, Oracle рекомендует использовать средства усиленной аутентификации, которые также были доработаны в лучшую сторону, например, стало возможно использовать HSM (Hardware Security Module) для аутентификации и хранения ключей шифрования.

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

Низкая стоимость владения - миф?

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

Уязвимы ли встроенные средства защиты?

И в этом вопросе мы вновь сталкиваемся с расхожим мнением о том, что штатные средства безопасности недостаточны. Как объяснить возникновение такого мнения, особенно при учёте того, что и встроенные средства защиты чаще всего используется далеко не на 100%. Т

Что же касается уязвимостей встроенных средств защиты в Oracle, то ситуация здесь ровно такая же как и в других сложных системах. Корпорация Oracle традиционно ответственно относится к обнаружению и устранению найденных уязвимостей. Регулярно (4 раза в год) выпускаются обновления CPU (Critical Patch Update), устраняющие бреши, обнаруженные как самой корпорацией Oracle, так и десятками других компаний, наиболее известная из которых - уже упоминавшаяся Red - Database - Security GmbH . Так, например, в CPU за октябрь 2007 г. были устранены 27 уязвимостей в СУБД, 11 - в сервере приложений, 13 - в различных приложениях. Учитывая число продуктов Oracle , их версий и программно-аппаратных платформ для них, это не так уж и много.

Своя разработка vs поддержка вендора

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

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

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

Возможности усиления функций защиты: когда это необходимо?

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

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

Алгоритмы российской криптографии (PKI, ЭЦП, шифрование в сети и на носителе)

Реализация шифрования при записи на носитель без использования TDE

Хранение ключевого материала.

По очевидным причинам разработчики Oracle не предусматривали универсальную реализацию этих двух моментов, хотя и предусмотрели некоторые общие подходы.

Применение отечественных криптографических алгоритмов

Криптографические алгоритмы могут использоваться в процессе аутентификации, выработки ЭЦП (ГОСТ Р 34.10-2001), для защиты канала связи (ГОСТ 28147-89, ГОСТ Р 34.11-94) и шифрования данных (ГОСТ 28147-89). Встроенные средства Oracle не реализуют данные алгоритмы ни в СУБД, ни в сервере приложений, ни в приложениях. Реализацию криптографии в виде библиотек, стандартных поставщиков криптографии (CSP), комплектов разработчика (SDK) предлагают несколько российских производителей - КриптоПро, Сигнал-Ком, Инфотекс, Лисси, КриптоКом, КриптоЭкс и др. Однако, заставить продукты Oracle работать с предлагаемыми библиотеками достаточно проблематично. Дело даже не в том, что данные средства не совместимы на уровне программно-аппаратного обеспечения - встраивание криптографии в продукты Oracle не должно нарушать лицензионного соглашения вендора относительно целостности ПО. Если с ИС, построенными на основе сервера приложений Ora cle или всего множества приложений Oracle, проблем со встраиванием, как правило, не возникает, то с СУБД дело обстоит сложнее. Вследствие того, что ядро СУБД не имеет программного интерфейса к криптооперациям (аутентификация, шифрование), приходится применять обходные пути. Например, использовать протокол аутентификации Kerberos или генераторы одноразовых паролей с протоколом RADIUS, а защиту канала связи осуществлять с помощью сертифицированных программных средств.

Шифрование данных без использования TDE

Несмотря на чрезвычайную простоту опции Oracle TDE, от ее использования часто приходится отказываться. Основных причин две:

Не поддерживаются некоторые типы данных

Нет возможности штатно применить российские криптоалгоритмы

Нет реальной защиты от привилегированных пользователей.

Первая проблема в принципе решается с помощью продуктов сторонних разработчиков - DbEncrypt for Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R . D .), The Encryption Wizard for Oracle (Relational Database Consultants , Inc .). Вторая проблема принципиально решается таким же образом, но здесь вариантов меньше - eToken SafeData или The Encryption Wizard for Oracle . Причем для первого продукта требуется дополнительная сборка версии (в зависимости от применяемого производителя сертифицированной криптографии), а по второму продукту, просто не удалось найти нужную информацию. Третья проблема, в принципе, могла бы быть решена с помощью совместного использования опций TDE и Oracle Database Vault , но в этом случае полномочия администратора СУБД плавно перетекают к администратору Database Va u lt, т.е. проблема защиты от привилегированных пользователей сохраняется.

Хранение ключевого материала

Ключевой материал (сертификаты, закрытые ключи, ключи шифрования), используемые встроенными средствами обеспечения безопасности Oracle для аутентификации или шифрования данных, хранятся в ключевых контейнерах, (т.н. бумажниках - wallets) как обычные файлы. Для доступа к информации в бумажнике требуется пароль. Часто такой способ хранения не отвечает требования по безопасности, особенно на рабочих станциях клиентов. СУБД Oracle , начиная с версии 10g, позволяет хранить закрытые ключи на аппаратных устройствах, поддерживающих стандарт PKCS#11. В то же время Oracle никак не гарантирует работу аппаратных устройств, отличных от устройств производства nCipher (nCipher Corporation Ltd.). Это не всегда приемлемо, например, если предполагается использование только сертифицированных аппаратных средств. И в этом случае проблема хранения ключей и сертификатов может быть решена с помощью решений сторонних производителей. На российском рынке, пожалуй, единственным в своем классе продуктом является eToken SecurLogon для Oracle (Aladdin Software Security R.D.) .

Заключение

Несмотря на осознанное понимание поднятой проблемы как законодателями, так государственными и коммерческими организациями, персональные данные всё же подвержены утечкам информации, ущерб от которых подчас оценивается весьма впечатляющими цифрами. Отсутствие громких прецедентов может быть объяснено латентностью преступлений в этой области. Однако утечки происходят постоянно и рано или поздно с кражами баз данных будет развернута полномасштабная борьба на госуровне. Конечно, можно использовать несертифицированные решения, можно использовать нелицензионное ПО и самостоятельно изобретать велосипед, игнорируя проверенные промышленные решения… Но только в этом случае организации должны отдавать себе отчет в том, что и все дополнительные риски - от финансовых до репутационных - связанные с применением таких продуктов, они тоже полностью берут на себя. Есть угрозы, и есть последствия. Принимая тот или иной подход к обеспечению безопасности информационных ресурсов, организации либо идут на риски, либо создают для себя максимально безопасные условия.

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

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