INSIDE – как много в этом звуке…
Говорить ещё раз об актуальности проблемы, вероятно, излишне.
Стоит лишь обозначить её конкретнее, чтобы представлять, с каким врагом мы имеем дело. Речь пойдёт о теоретических методах защиты данных от пользователей, по долгу службы уполномоченных с этими данными работать.
Почему это представляется интересным?
Защита информационной системы от внешнего злоумышленника на сегодня достаточно хорошо формализована, разработаны методы, стандарты и средства, на рынок выведены всевозможные продукты, подготовлены специалисты, и, хотя полностью разрешённой эту проблему назвать нельзя, её решение сегодня требует скорее количественных усилий, нежели качественных.
Иначе дело обстоит с так называемыми «атаками инсайдеров», внутренними атаками.
На первый взгляд, кажется, что и здесь предложения компаний пестрят всевозможными «средствами защиты от НСД» (от несанкционированного доступа), но на поверку оказывается, что они сводятся к ещё одному оригинальному способу введения пароля (что, безусловно, также важно).
Попробуем разобраться в вопросе.
Предположим, мы разработчики базы данных, пусть это будет база для бюро кредитных историй.
После того как мы защитили все сервисы доступа к БД от проникновения извне и определились с постулатом: пользователь должен проходить процедуру идентификации, аутентификации и авторизации при доступе к данным — мы решили одну проблему и создали новую. Мы создали сущности данных, определили на них права пользователей, учли все нюансы, обучили администратора – защитили систему.
Теперь посмотрим на эту ситуацию со стороны владельцев базы. Мы (владельцы) заказали разработку базы данных, потребовали защитить все подступы к ней и попросили ограничить права пользователей.
При этом уполномоченные пользователи системы (а в нашем примере это сотрудники головного офиса бюро кредитных историй) должны работать с данными.
Например, они должны ответить на письменный запрос в бюро, т.е. они могут получить любую кредитную историю из базы данных. Или, может быть, сразу всё.
Дальнейшее развитие событий.
База данных растёт, пользователи приходят и уходят, и мы назначаем администратора безопасности (или даже группу таких администраторов).
Перед нами предстала проблема суперпользователя.
Здесь проявляется важная логическая особенность проблемы внутренних атак: защититься от инсайдера невозможно принципиально.
Это очень похоже на парадокс Рассела о брадобрее, который бреет несамостоятельных жителей деревни, попробуем перефразировать, его так, чтобы он звучал в наших терминах:
Администратор-брадобрей блокирует доступ к системе каждому, кто не должен его иметь, т.е. каждому, кто не блокирует свой доступ сам.
А дальше стандартное рассуждение: если администратор не блокирует себе доступ сам, значит, он должен его блокировать.
Если же администратор блокирует доступ сам себе, то это уже не администратор, т.к. он может блокировать доступ только тем, кто сам не может (не хочет) его себе заблокировать.
Тогда, кто блокирует доступ администратору?
Это забавное рассуждение ставит владельцев базы данных перед печальными выводами.
Впрочем, ситуация не так безнадёжна.
Нельзя забывать, что возраст этой проблемы – не одно столетие (а может и тысячелетие).
А за прошедший век тоталитарные государственные машины добились действительно потрясающих результатов. Ключевое слово в решении, которое они применяли – это регламент. Безусловно, эти методы по по-прежнему эффективны.
Вернёмся к нашему примеру, бюро кредитных историй. Очевидно, на этапе создания мы должны принять в штат «специалиста по безопасности».
Этот сотрудник должен быть даже не IT-специалистом, а скорее специалистом по безопасности информации вообще (например, бывший сотрудник УВД). В его обязанности входит составление регламента доступа к защищаемой информации.
В документах, которые он разрабатывает, есть строчки: «…отсутствовать сменные носители», «запретить доступ в нерабочее время», «…процедуру смены пароля не реже…», «ограничить функционал рабочего места…», «изолировать вычислительную сеть от…», «…несёт личную ответственность», «…решается в судебном порядке», и т.п.
Слабое место этого подхода очевидно – человеческий фактор.
Мы не будем сейчас останавливаться на регламенте безопасности информационной системы, этому посвящено множество трудов, мы коснёмся его позже, но уже в другом аспекте.
Также мы не будем останавливаться на психологических приёмах решения этой проблемы (мотивирование сотрудников, имеющих доступ к БД, а может, запугивание?), т.к. это далеко выходит за рамки этой статьи. Мы попробуем выработать такие концепции проектирования информационной системы, которые помогут автоматизировать защиту от внутренних атак.
Итак, если проблема не имеет решения, следует сокращать её негативное воздействие.
Если защитить данные от внутренних атак принципиально невозможно, можно попытаться сузить границу атаки, фронт нападения внутренних злоумышленников.
Идеальный вариант – если база умещалась бы в бумажный блокнот, её можно положить в карман и не выпускать из рук, даже, когда кто-то читает из неё данные.
Тогда единственный момент времени, когда она будет уязвима – это момент, в который эту базу достают из кармана (от воровства из кармана – т.е. внешних угроз – мы защитились в самом начале).
От действительности эту ситуацию отделяет даже не то, что реальная база кредитных историй в блокноте не поместится, а то, что её обслуживание требует специальных навыков, которыми владелец базы данных в общем случае не владеет.
Удобно было бы доверить управление базой некоторой интеллектуальной сущности.
Эта сущность, назовём её «гном», должна уметь передавать записи, управлять структурой базы, проводить обслуживание, но при этом «гном» должен быть закрыт от внешнего мира в «чёрном ящике», который даже для назначенного администратора должен служить промежуточным слоем абстракции при доступе к структуре и записям базы.
Гном в ящике
Это базовая концепция создания защищённой от внутренних атак информационной системы.Её суть в сосредоточении всех полномочий на доступ к базе в рамках одного программного модуля, «гнома».
А ящиком для него будет являться комплекс мер.
«Гном» общается с внешним миром на уровне информационных сообщений (посредством web-сервисов, например), этот канал доступа должен быть универсальным и единственным.
Т.е. в «ящик» может пролезать только такой «конверт», который соответствует формату.
Каждый «конверт», т.е. каждый запрос на выполнение операции, сопровождается электронной подписью отправителя.
Т.о. этот программный модуль – единственный способ доступа в систему (или доступа к закрытым данным системы).
Как же эту концепцию воплотить в жизнь? В обобщённых терминах это может выглядеть так…
Но для начала нужно сказать несколько слов об «инфраструктуре открытых ключей».
Это набор технологий, алгоритмов и стандартов, на которых в частности реализован т.н. сертификат электронной цифровой подписи.
Каждый сертификат содержит пару ключей для симметричного шифрования (закрытый ключ хранится отдельно в защищённом контейнере) и описание сертификата, на которое наложена электронная подпись выдавшей организации (удостоверяющего центра).
С точки зрения пользователя сертификат цифровой подписи позволяет подписывать блоки данных, проверять подпись и шифровать.
За счёт описания сертификат также удобно использовать в качестве средства идентификации.
В нашем примере надёжными сертификатами цифровой подписи должны быть снабжены все пользователи базы данных и, конечно, владелец.
Вернёмся к реализации.
Так как «гном» – единственная сущность, которая имеет доступ к закрытым таблицам, она должна быть единственной сущностью, которая владеет паролем суперпользователя. Возникает вопрос, где же его хранить?
Очевидно, что в хранилище он может находиться только в зашифрованном виде. Расшифровываться он должен закрытым ключом сертификата владельца.
Опять же держать постоянно сертификат цифровой подписи владельца на сервере нелепо, вывод: закрытый ключ сертификата владельца должен быть закеширован, загружен в оперативную память на стадии загрузки системы. Это нас приводит к одному ограничению и одной проблеме.
Первое: при каждой загрузке системы, ей потребуется инициализация сертификатом владельца.
Второе: из оперативной памяти закешированный закрытый ключ можно украсть.
Но к этой проблеме мы вернёмся в следующих концепциях.
Промежуточный итог: при загрузке системы запускается программный модуль «гном в ящике», который инициализируется сертификатом владельца и становится единственным окном в базу данных.
Продолжим.
Для работы пользователей «гном» должен уметь их идентифицировать. Для этого программный модуль ведёт реестр сертификатов электронных подписей субъектов, осуществляющих доступ. Сертификат владельца БД предустановлен в этот реестр.
Пользователи отправляют «гному» свои сообщения, инструкции (упакованные в XML, например), «гном» идентифицирует отправителей по их сертификатам в своём реестре, проверяет подпись и принимает решение о выполнении запроса.
Первые инструкции, которые увидит гном в своей жизни – это инструкции от владельца БД.
В них будут указаны сертификаты, владельцы которых должны получить доступ к БД.
Эти управляющие запросы будут подписаны электронной подписью владельца базы данных (сертификат которого предустановлен).
После чего «гном» начнёт обрабатывать запросы уже от вновь добавленных пользователей.
Такая системная роль как Администратор в данной концепции претерпевает изменения.
Как уже было сказано, пароль суперпользователя системы не знает ни один пользователь.
Этот пароль генерируется случайным образом на стадии первичной настройки и сохраняется в независимом от базы данных контейнере (запечатанный конверт в банковской ячейке или сейфе владельца БД, например), плюс, зашифрованная копия остаётся у «гнома».
Тот пользователь, который всё же занимается администрированием, также как и прочие общается с БД через «гнома».
Инструкции администратора, которые должен выполнять «гном» можно разбить на две категории, условно назовём их: проверенные и свободные.
Проверенные инструкции представляют собой подпрограммы на языке управления базами данных, которые были проверены внешним аудитором, и считаются безопасными для БД, например создание индекса.
Главная особенность таких инструкций в том, что для их вызова администратор запрашивает наименование инструкции и передаёт только параметры вызова, но не сам код. Конечно, при аудите этих подпрограмм необходимо убедиться в том, что нельзя превысить полномочия, используя особенным образом заданные параметры.
Свободные инструкции – это код на языке управления БД в чистом виде.
Однако этот код «гном» также пропускает через себя. Что может защитить от утечки в данном случае?
Комплекс мер: уведомление владельца о необходимости выполнить свободную инструкцию (или требование его разрешения, т.е. подписи), электронная подпись администратора под каждой такой инструкцией и ведение журнала выполненных инструкций на отдельном сервере.
В случае утечки можно будет найти виновника.
Конечно, важно, чтобы страх злоумышленника от понимания этого превышал утешение для владельца после раскрытия информации.
Очевидно, что защищённость базы в данном случае зависит от соотношения проверенных и свободных инструкций (не будем останавливаться на том, что свободных инструкций на языке управления БД всегда много более).
Другими словами, нужно наращивать интеллект «гнома» (может, не интеллект, а эрудированность), т.е. набор тех функций, которые может выполнять этот сервис по авторизованному запросу администратора.
В идеале в набор «умений» должны входить: управление индексами, табличным пространством, буферизацией; а также работа с некоторыми базовыми сущностями предметной области: создание/удаление пользователей, определение их полномочий, в нашем примере, добавление сертификатов электронной подписи пользователей.
Эта концепция не лишена недостатков: её, например, очень сложно применять в базах данных, которые находятся на начальном уровне развития своей структуры и требуют постоянного вмешательства со стороны архитекторов.
«Гном в ящике» в чистом виде предполагает использование «зрелых» баз данных.
Также возникает и такая проблема: доверие «гному».
Она в свою очередь делится на проблему доверия разработчику этого программного модуля (нет ли там «закладок» или просто уязвимостей) и на проблему доверия текущему экземпляру «гнома» (не был ли он подменён).
Первая проблема отчасти решается привлечением стороннего аудитора в области информационных систем, а вторая сопровождением исполняемого кода «гнома» электронной подписью.
Почему отчасти – потому что каждое новое «решение» поднимает новый вопрос доверия (доверия аудитору или тому коду, который будет проверять электронную подпись «гнома»).
Мы рассмотрели достоинства и недостатки этой концепции, и теперь стоит вернуться к уже упомянутому регламенту безопасности.
«Тонкое место» в данной концепции – регламентное предоставление полного доступа администратору базы данных для изменений структуры (разрешение выполнения свободных инструкций).
Т.е. если задача, которую должен выполнить администратор не входит в список умений «гнома» (не автоматизирована), полный доступ администратору нужно предоставлять. Именно здесь ответственная роль возлагается на регламент.
Здесь можно придумать свод правил, которые максимально усложнят раскрытие данных.
Например: выдавать разрешение на выполнение свободных инструкций только после прохождения администратором проверки на детекторе лжи, при работе администратора с базой в таком режиме закрывать доступ в сеть, ограничивать трафик обмена с базой данных, требовать наличия двух свидетелей, проводить предварительный аудит кода, и т.д.
Нельзя забывать и о том, что с увеличением усилий, требуемых на воровство информации, растут и усилия, требуемые для поддержки и развития базы данных.
Если «гном в ящике» сковывает развитие структуры базы, к тому же ограничивает возможности работы со статистикой и тестовыми данными, мы можем попытаться расширить границы, сделать ящик не таким чёрным.
Но как при этом обезопасить данные? Может ли существовать база данных, информация из которой абсолютно надёжно закрыта? Да, если эта информация абсолютно ничего не стоит…
Концепция Ржавый сундук
Суть её заключается в том, что данные в базе должны представлять интерес, только в момент их запроса, но не в момент хранения.
Т.е. всё, что лежит в физических хранилищах, должно являться бесполезным «ржавым хламом» для того, кто попытается это прочитать.
Или другими словами: все данные должны быть зашифрованы, прежде чем быть записаны, и расшифрованы при санкционированном прочтении.
Шифрование на лету – прозрачное шифрование.
В таком случае украденный жесткий диск или весь сервер не будет представлять интереса.
Как это можно реализовать?
При инициализации базы данных в сервер вставляется контейнер закрытого ключа сертификата ЭЦП. Закрытый ключ кэшируется в области памяти крипто-провайдера (средствами ОС или Крипто ПРО).
Затем ключ изымается. Теперь при потере питания этот ключ уже не восстановить.
Закрытый ключ с этого контейнера служит для расшифровки таблицы симметричных паролей, которые представляют собой случайные последовательности.
Каждая закрытая таблица может иметь свой собственный симметричный пароль.
Теперь мы возвращаемся к «гному».
«Гном» – единственный сервис в ОС, который имеет доступ к закрытому ключу и к таблице паролей.
При каждом запросе он, считывая данные из хранилища, расшифровывает их и передаёт клиенту, а также обратно, зашифровывает и записывает в хранилище.
Концепция Котлеты и мухи отдельно
Суть концепции заключается в выделении некоторых единичных записей, а затем разделении этих записей на титульные и содержательные части.
Титульная часть содержит описание объекта, к которому относится эта запись, а содержательная собственно данные по этому объекту.
Разделённые части хранятся в разных таблицах (а возможен вариант и с использованием разных БД, разных информационных площадок).
Таблица, в которой хранятся указатели, связывающие разделённые части, зашифрована, и доступ к ней имеет только «Гном в ящике».
Плюсы этой концепции: широта возможностей по дальнейшему развитию структуры. Возможность открыто использовать данные для статистического анализа.
А минусы в том, что провести границу, по которой можно разбить данные бывает достаточно сложно. Случается так, что одна только титульная часть уже содержит достаточное количество конфиденциальных данных, чтобы представлять интерес для злоумышленника.
Концепция Узкий ход
Её суть в том, что количество данных, которые передаются пользователю, ограничивается по нескольким критериям. Т.е. нельзя украсть всё и сразу.
Для чего создавалась эта концепция. Все пользователи проходят какую-либо идентификацию, однако в случае insider-а ключ идентификации (сертификат ЭЦП) может быть скомпрометирован (украден).
Тогда необходимо ограничивать всех, включая доверенных пользователей.
Критерии ограничения могут быть различны, например:
количество информации в единицу времени (не более 100 записей в сутки в одни руки),
ограничение по времени (нельзя делать запросы после окончания рабочего дня),
ограничение по группам пользователей (не более 200 записей с группы адресов, с одного отдела, района, города).
Мы же предлагаем также ввести матрицу коэффициентов доверия и значимости.
Т.е. сопоставить каждой записи коэффициент её значимости, который может зависеть от частоты доступа к ней, от объекта, который она описывает, от политической обстановки, в конце концов.
Каждому пользователю поставить в соответствие коэффициент доверия, который будет определяться временем работы клиента с системой, возможностью внешнего контроля над клиентом, его репутацией, историей отношений.
Таким образом, если пользователь с низким коэффициентом доверия начинает активно запрашивать записи с высоким коэффициентом значимости, он получит временный отказ.
При этом владельцу БД будет отправлено уведомление о том, что система ограничила доступ этому клиенту к определённым записям. Владелец примет решение и отправит подписанный пакет в систему.
Разделяй и властвуй
Основная идея концепции в том, что для получения привилегированного доступа требуется аутентификация не одного, а нескольких пользователей. Т.е. для выполнения запроса к секретной таблице или для внесения изменений в БД командный пакет для «гнома» должен иметь несколько цифровых подписей. Причём используется избыточное количество пользователей. Например: есть 5 администраторов, требуются подписи любых троих для выполнения пакета с командой.
Преимущества: отпадает необходимость постоянно контролировать уполномоченных пользователей. Для того чтобы украсть базу, нужно вступать в сговор, в нашем примере нужно сообразить «на троих».
Недостатки: размывается ответственность, каждый может сослаться на другого уполномоченного пользователя.
Подводя итоги наших «исследований», мы приходим к выводу о том, что проблема ещё не может быть закрыта, но поднять уровень защиты от внутренних злоумышленников на новый уровень возможно, хотя это и требует скорее качественных, а не количественных усилий. Возможно, как и у парадокса Рассела о брадобрее, решение этой проблемы кроется в ином формулировании условий. Быть может, будущие разработки в области IT и законотворчества (а может быть также социологии и психологии) позволят смотреть на эту проблему совершенно под другим углом.
Рассматриваемый пример с бюро кредитных историй не вымышленный, с применением описанных концепций действительно была разработана информационная система, она получила название «Плеяды».
На базе этой системы функционирует Межрегиональное Бюро Кредитных Историй (http://mbki.ru), эта организация под номером 2 была внесена в государственный реестр бюро кредитных историй (http://fcsm.ru/catalog.asp?ob_no=24284).
Разработкой занималась компания «ИВЦ-1» (http://ivc-1.ru), которая входит в группу компаний «Астра СТ»