 |
 |
№ 6 ноябрь-декабрь 2006 г.
Тема номера:
СОЦИАЛЬНАЯ ИНЖЕНЕРИЯ
|
|
МЕТОДИКИ ЗАЩИТЫ БАЗ ДАННЫХ ОТ ВНУТРЕННИХ ЗЛОУМЫШЛЕННИКОВ
И. Б. Алябушев, В. В. Бабушкин
Группа компаний «Астра СТ»
|
|
  |
Вероятно, излишне еще раз говорить об актуальности вынесенной в заголовок проблемы. Стоит лишь конкретнее обозначить ее, чтобы представлять, с каким врагом мы имеем дело.
Речь пойдет о теоретических методах защиты данных от пользователей, уполномоченных с этими данными работать по долгу службы. Почему это представляется интересным? Защита информационной системы от внешнего злоумышленника на сегодня достаточно хорошо формализована, разработаны методы, стандарты и средства, на рынок выведены всевозможные продукты, подготовлены специалисты, и хотя эту проблему нельзя назвать полностью разрешенной, ее решение сегодня требует скорее количественных усилий, нежели качественных.
Иначе дело обстоит с так называемыми «атаками инсайдеров», внутренними атаками. На первый взгляд кажется, что и здесь предложения компаний пестрят всевозможными «средствами защиты от НСД» (от несанкционированного доступа), но на поверку оказывается, что все они сводятся к еще одному оригинальному способу введения пароля (что, безусловно, также важно). Попробуем разобраться в вопросе.
Предположим, мы разработчики базы данных. Пусть это будет база бюро кредитных историй. После того как мы защитили все сервисы доступа к БД от проникновения извне и определились с постулатом: пользователь должен проходить процедуру идентификации, аутентификации и авторизации при доступе к данным, мы решили одну проблему и создали новую. Мы создали сущности данных, определили на них права пользователей, учли все нюансы, обучили администратора – защитили систему.
Теперь посмотрим на эту ситуацию со стороны владельцев базы. Мы (владельцы) заказали разработку базы данных, потребовали защитить все подступы к ней и попросили ограничить права пользователей. При этом уполномоченные пользователи системы (а в нашем примере это сотрудники головного офиса бюро кредитных историй) должны работать с данными. Например, они должны отвечать на письменные запросы в бюро, то есть могут получить любую кредитную историю из базы данных. Или, может быть, сразу все?
Итак, мы создали базу данных, защищенную от внешних атак. Отныне она требует наполнения и обслуживания. Мы предоставили к ней частичный доступ сотрудникам нашей организации и абсолютный доступ администратору системы – с этого момента перед нами предстала проблема суперпользователя.
Здесь проявляется важная логическая особенность проблемы внутренних атак: защититься от инсайдера невозможно принципиально. Это очень похоже на известный парадокс Рассела или парадокс брадобрея, бреющего несамостоятельных жителей деревни. Попробуем перефразировать его так, чтобы он звучал в наших терминах.
Администратор-брадобрей блокирует доступ к системе каждому, кто не должен его иметь, то есть каждому, кто не блокирует свой доступ сам. А дальше следует стандартное рассуждение: если администратор не блокирует себе доступ сам, значит, он должен его себе блокировать. Если же администратор блокирует доступ сам себе, то это уже не администратор, так как он может блокировать доступ только тем, кто сам не может его себе заблокировать. Тогда кто блокирует доступ администратору?
Это забавное рассуждение ставит владельцев базы данных перед печальными выводами. Впрочем, ситуация не так безнадежна. Нельзя забывать, что этой проблеме не одна сотня (а, может быть, тысяча) лет. И за прошедший век тоталитарные государственные машины добились в этом направлении потрясающих результатов. Ключевое слово в решении, которое они применяли, – «регламент». Конечно, эти методы по-прежнему эффективны.
Вернемся к нашему примеру – бюро кредитных историй. Очевидно, что на этапе его создания мы должны принять в штат «специалиста по безопасности». Этот сотрудник должен быть даже не IT-специа-листом, а скорее специалистом по безопасности информации вообще (хорошо подходят отставные военные). В его обязанности входит составление регламента доступа к защищаемой информации. В документах, которые он разрабатывает, есть строчки: «…отсутствовать сменные носители», «запретить доступ в нерабочее время», «…процедуру смены пароля не реже…», «ограничить функционал рабочего места…», «изолировать вычислительную сеть от…», «…несет личную ответственность», «…решается в судебном порядке»
и т. п.
Слабое место этого подхода очевидно – человеческий фактор.
Мы не будем сейчас останавливаться на регламенте безопасности информационной системы, поскольку этому посвящено множество трудов – мы коснемся его позже, но уже в другом аспекте. Также мы не будем останавливаться на психологических приемах решения этой проблемы (мотивирование сотрудников, имеющих доступ к БД, а может, запугивание?) – эта тема требует отдельного рассмотрения. Мы попробуем выработать такие концепции проектирования информационной системы, которые помогут автоматизировать защиту от внутренних атак.
Итак, если проблема не имеет решения, следует сокращать ее негативное воздействие. Если защитить данные от внутренних атак принципиально невозможно, можно попытаться сузить границу атаки, фронт нападения внутренних злоумышленников.
< ... >
Обращайтесь!!!
e-mail: magazine@inside-zi.ru
тел.: +7 (921) 958-25-50, +7 (911) 921-68-24
Предыдущая статья СОДЕРЖАНИЕ НОМЕРА Следующая статья
|
