Методики защиты баз данных от внутренних злоумышленников

Методики защиты баз данных от внутренних злоумышленников

Методики защиты баз данных от внутренних злоумышленников

Комплексные системы безопасности \\ 09.03.2010 17:28 \\ ООО "Астра Системные Технологии" \\ Челябинск

INSIDE – как много в этом звуке… Говорить ещё раз об актуальности проблемы, вероятно, излишне. Стоит лишь обозначить её конкретнее, чтобы представлять, с каким врагом мы имеем дело. Речь пойдёт о теоретических методах защиты данных от пользователей, по долгу службы уполномоченных с этими данными работать. Почему это представляется интересным?

INSIDE – как много в этом звуке…

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

Иначе дело обстоит с так называемыми «атаками инсайдеров», внутренними атаками. На первый взгляд, кажется, что и здесь предложения компаний пестрят всевозможными «средствами защиты от НСД» (от несанкционированного доступа), но на поверку оказывается, что они сводятся к ещё одному оригинальному способу введения пароля (что, безусловно, также важно). Попробуем разобраться в вопросе.


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

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


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

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

А дальше стандартное рассуждение: если администратор не блокирует себе доступ сам, значит, он должен его блокировать. Если же администратор блокирует доступ сам себе, то это уже не администратор, т.к. он может блокировать доступ только тем, кто сам не может (не хочет) его себе заблокировать. Тогда, кто блокирует доступ администратору?

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

Вернёмся к нашему примеру, бюро кредитных историй. Очевидно, на этапе создания мы должны принять в штат «специалиста по безопасности». Этот сотрудник должен быть даже не IT-специалистом, а скорее специалистом по безопасности информации вообще (например, бывший сотрудник УВД). В его обязанности входит составление регламента доступа к защищаемой информации. В документах, которые он разрабатывает, есть строчки: «…отсутствовать сменные носители», «запретить доступ в нерабочее время», «…процедуру смены пароля не реже…», «ограничить функционал рабочего места…», «изолировать вычислительную сеть от…», «…несёт личную ответственность», «…решается в судебном порядке», и т.п.

Слабое место этого подхода очевидно – человеческий фактор.

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

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

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

Гном в ящике

Это базовая концепция создания защищённой от внутренних атак информационной системы. Её суть в сосредоточении всех полномочий на доступ к базе в рамках одного программного модуля, «гнома». А ящиком для него будет являться комплекс мер.

«Гном» общается с внешним миром на уровне информационных сообщений (посредством web-сервисов, например), этот канал доступа должен быть универсальным и единственным. Т.е. в «ящик» может пролезать только такой «конверт», который соответствует формату. Каждый «конверт», т.е. каждый запрос на выполнение операции, сопровождается электронной подписью отправителя.
Т.о. этот программный модуль – единственный способ доступа в систему (или доступа к закрытым данным системы).

Как же эту концепцию воплотить в жизнь? В обобщённых терминах это может выглядеть так…
Но для начала нужно сказать несколько слов об «инфраструктуре открытых ключей». Это набор технологий, алгоритмов и стандартов, на которых в частности реализован т.н. сертификат электронной цифровой подписи. Каждый сертификат содержит пару ключей для симметричного шифрования (закрытый ключ хранится отдельно в защищённом контейнере) и описание сертификата, на которое наложена электронная подпись выдавшей организации (удостоверяющего центра). С точки зрения пользователя сертификат цифровой подписи позволяет подписывать блоки данных, проверять подпись и шифровать. За счёт описания сертификат также удобно использовать в качестве средства идентификации. В нашем примере надёжными сертификатами цифровой подписи должны быть снабжены все пользователи базы данных и, конечно, владелец.
Вернёмся к реализации.

Так как «гном» – единственная сущность, которая имеет доступ к закрытым таблицам, она должна быть единственной сущностью, которая владеет паролем суперпользователя. Возникает вопрос, где же его хранить? Очевидно, что в хранилище он может находиться только в зашифрованном виде. Расшифровываться он должен закрытым ключом сертификата владельца. Опять же держать постоянно сертификат цифровой подписи владельца на сервере нелепо, вывод: закрытый ключ сертификата владельца должен быть закеширован, загружен в оперативную память на стадии загрузки системы. Это нас приводит к одному ограничению и одной проблеме. Первое: при каждой загрузке системы, ей потребуется инициализация сертификатом владельца. Второе: из оперативной памяти закешированный закрытый ключ можно украсть. Но к этой проблеме мы вернёмся в следующих концепциях.

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

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

Такая системная роль как Администратор в данной концепции претерпевает изменения. Как уже было сказано, пароль суперпользователя системы не знает ни один пользователь. Этот пароль генерируется случайным образом на стадии первичной настройки и сохраняется в независимом от базы данных контейнере (запечатанный конверт в банковской ячейке или сейфе владельца БД, например), плюс, зашифрованная копия остаётся у «гнома». Тот пользователь, который всё же занимается администрированием, также как и прочие общается с БД через «гнома».

Инструкции администратора, которые должен выполнять «гном» можно разбить на две категории, условно назовём их: проверенные и свободные.

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


Свободные инструкции – это код на языке управления БД в чистом виде. Однако этот код «гном» также пропускает через себя. Что может защитить от утечки в данном случае? Комплекс мер: уведомление владельца о необходимости выполнить свободную инструкцию (или требование его разрешения, т.е. подписи), электронная подпись администратора под каждой такой инструкцией и ведение журнала выполненных инструкций на отдельном сервере. В случае утечки можно будет найти виновника. Конечно, важно, чтобы страх злоумышленника от понимания этого превышал утешение для владельца после раскрытия информации.


Очевидно, что защищённость базы в данном случае зависит от соотношения проверенных и свободных инструкций (не будем останавливаться на том, что свободных инструкций на языке управления БД всегда много более). Другими словами, нужно наращивать интеллект «гнома» (может, не интеллект, а эрудированность), т.е. набор тех функций, которые может выполнять этот сервис по авторизованному запросу администратора. В идеале в набор «умений» должны входить: управление индексами, табличным пространством, буферизацией; а также работа с некоторыми базовыми сущностями предметной области: создание/удаление пользователей, определение их полномочий, в нашем примере, добавление сертификатов электронной подписи пользователей.

Эта концепция не лишена недостатков: её, например, очень сложно применять в базах данных, которые находятся на начальном уровне развития своей структуры и требуют постоянного вмешательства со стороны архитекторов. «Гном в ящике» в чистом виде предполагает использование «зрелых» баз данных.
Также возникает и такая проблема: доверие «гному». Она в свою очередь делится на проблему доверия разработчику этого программного модуля (нет ли там «закладок» или просто уязвимостей) и на проблему доверия текущему экземпляру «гнома» (не был ли он подменён).

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

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

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

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

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

Концепция Ржавый сундук

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

Как это можно реализовать?

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

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

Концепция Котлеты и мухи отдельно

Суть концепции заключается в выделении некоторых единичных записей, а затем разделении этих записей на титульные и содержательные части. Титульная часть содержит описание объекта, к которому относится эта запись, а содержательная собственно данные по этому объекту. Разделённые части хранятся в разных таблицах (а возможен вариант и с использованием разных БД, разных информационных площадок). Таблица, в которой хранятся указатели, связывающие разделённые части, зашифрована, и доступ к ней имеет только «Гном в ящике».

Плюсы этой концепции: широта возможностей по дальнейшему развитию структуры. Возможность открыто использовать данные для статистического анализа.

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

Концепция Узкий ход

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

Критерии ограничения могут быть различны, например:

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

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

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

Разделяй и властвуй

Основная идея концепции в том, что для получения привилегированного доступа требуется аутентификация не одного, а нескольких пользователей. Т.е. для выполнения запроса к секретной таблице или для внесения изменений в БД командный пакет для «гнома» должен иметь несколько цифровых подписей. Причём используется избыточное количество пользователей. Например: есть 5 администраторов, требуются подписи любых троих для выполнения пакета с командой.

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

Подводя итоги наших «исследований», мы приходим к выводу о том, что проблема ещё не может быть закрыта, но поднять уровень защиты от внутренних злоумышленников на новый уровень возможно, хотя это и требует скорее качественных, а не количественных усилий. Возможно, как и у парадокса Рассела о брадобрее, решение этой проблемы кроется в ином формулировании условий. Быть может, будущие разработки в области IT и законотворчества (а может быть также социологии и психологии) позволят смотреть на эту проблему совершенно под другим углом.

Рассматриваемый пример с бюро кредитных историй не вымышленный, с применением описанных концепций действительно была разработана информационная система, она получила название «Плеяды». На базе этой системы функционирует Межрегиональное Бюро Кредитных Историй (http://www.mbki.ru), эта организация под номером 2 была внесена в государственный реестр бюро кредитных историй (http://www.fcsm.ru/catalog.asp?ob_no=24284).

Разработкой занималась компания «ИВЦ-1» (http://www.ivc-1.ru), которая входит в группу компаний «Астра СТ»

Комментарии:

Статьи Комплексные системы безопасности

Развенчание мифов о мобильном доступе

Развенчание мифов о мобильном доступе

Комплексные системы безопасности \\ 23.08.2016 16:17 \\ HID Global \\ Комментарии()

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

Пожаротушение в котельной

Пожаротушение в котельной

Комплексные системы безопасности \\ 13.04.2016 11:01 \\ ЗАО "НПГ Гранит-Саламандра" \\ Комментарии()

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

Преимущества конвергенции для контроля доступа

Преимущества конвергенции для контроля доступа

Комплексные системы безопасности \\ 29.01.2016 15:47 \\ HID Global \\ Комментарии()

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

Смартфоны: открывая двери новым возможностям

Смартфоны: открывая двери новым возможностям

Комплексные системы безопасности \\ 15.12.2015 20:36 \\ HID Global \\ Комментарии()

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

Безопасность на предприятии, системы безопасности для бизнеса

Комплексные системы безопасности \\ 09.12.2015 13:43 \\ Разбег Системы безопасности Ставрополь \\ Комментарии()

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

Что считать импортом? Обзор ситуации на рынке источников питания

Комплексные системы безопасности \\ 18.11.2015 14:08 \\ К-Инженеринг \\ Комментарии()

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

Рынок ИБП: перемены неизбежны!

Рынок ИБП: перемены неизбежны!

Комплексные системы безопасности \\ 18.11.2015 13:44 \\ К-Инженеринг \\ Комментарии()

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

Мобильный доступ с помощью Bluetooth Smart и NFC

Комплексные системы безопасности \\ 01.10.2015 23:49 \\ HID Global \\ Комментарии()

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

Видеодетекторы дыма и огня: раннее обнаружение

Видеодетекторы дыма и огня: раннее обнаружение

Комплексные системы безопасности \\ 05.08.2015 10:28 \\ Macroscop \\ Комментарии()

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

Обнаружение оставленных предметов. Анализ двух прогрессивных методов

Комплексные системы безопасности \\ 31.07.2015 14:49 \\ Macroscop \\ Комментарии()

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

Книги

Системы охранной, пожарной и охранно-пожарной сигнализации

ISBN: 978-5-7695-6218-1
Год: 2010 (май)
Страниц: 512

 

 

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

Технические средства охраны

Системы охранной сигнализации: основы теории и принципы построения

ISBN: 978-5-9912-0025-7
Год: 2008
Страниц: 496

 

Учебное пособие поможет при прохождении теоретических курсов специалистами в области охраны. Здесь есть всё об эксплуатации технических средств охраны. Это второе, дополненное издание, созданное на основе лекций.

Технические средства охраны

Системы контроля и управления доступом

Год: 2010
Страниц: 272

 

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

 

Технические средства охраны

вверх