Базы данных: как защититься от инсайдеров?
22-04-2008 11:27
к комментариям - к полной версии
- понравилось!
Корпоративные базы данных нередко оказываются незащищенными от действий инсайдеров, поскольку злоумышленникам, работающим в компании, нетрудно замаскировать воровство конфиденциальных данных под обычный рабочий процесс. Как же организовать эффективную защиту? Необходим целый комплекс мер, включающий, помимо ведения журнала аудита, анализ потенциальных каналов утечки и их "сужение", выстраивание формализованных процедур контроля.
Широкое обсуждение разнообразных мер по защите данных от инсайдеров, ведущееся многими специалистами, все же не проясняет до конца сути вопроса. Под эту тему попадает все, включая контент-анализ информационных сообщений, выходящих за пределы организации, контроль подключаемых накопителей, контроль действий сотрудников на их рабочих местах и многое другое. Однако защите от инсайдеров корпоративных баз данных, хранящих стратегические нематериальные активы компаний, несомненно, должно придаваться первостепенное значение.
В рамках данной статьи мы рассмотрим доступ к корпоративным базам данных со стороны собственных сотрудников компании, которые имеют все необходимые права и работают с этими базами, выполняя свои прямые производственные обязанности. За пределами нашего внимания останется защита резервных копий и данных в мобильных устройствах, а также ряд других аспектов защиты баз, отличающихся тем, что в отношении них более или менее понятно, что и от кого защищать, и можно провести определенную аналогию с защитой периметра.
Особенность ситуации с доступом к БД состоит в том, что вредоносная деятельность сотрудника легко может быть замаскирована под обычную служебную активность. Таким образом, задача, которую мы пытаемся разрешить, является еще одним воплощением старой, как мир, проблемы – как выявить скрытых "врагов" в кругу "друзей".
Но давайте снимем эту излишнюю эмоциональную окраску – в компании нет ни друзей, ни врагов - только сотрудники. И некоторые из них могут сознательно действовать в ущерб компании (так называемые "обиженные", либо "лазутчики", засланные кем-то с криминальными намерениями, либо сотрудники, завербованные с этой же целью), другие могут находиться в некотором "пограничном" состоянии, борясь с соблазном "продаться". Есть еще одна категория – люди рассеянные или недисциплинированные, которые могут нанести ущерб ненамеренно.
На чем можно построить противодействие активным вредоносным элементам и как приучить к дисциплине "пассивных" потенциально опасных сотрудников?
Контроль и аудит
Первое, что приходит в голову, - это слово "контроль". Еще не определив это понятие и не наполнив его содержанием, можно согласиться с тем, что контроль - это хорошо: по меньшей мере, его наличие позволит поднять психологическую планку, которую необходимо преодолеть потенциальным "кротам" для начала своей вредоносной деятельности. Находясь в поле действия "контроля", такой субъект уже не просто берет то, что "плохо лежит", а должен спланировать свои действия, сознательно пойти на риск, что осложнит выполнение его намерений и во многих случаях заставит от них отказаться. Угроза наказания поможет приучить к дисциплине рассеянных.
Но каким конкретным содержанием может быть наполнено слово "контроль"?
Руководствуясь здравым смыслом, можно заключить, что это прослеживание событий, связанных с контролируемой сферой активности, с последующим анализом и выделением противоправных, сомнительных и потенциально опасных действий.
Прослеживание событий (или более терминологически точно – аудит, т.е. регистрация тех действий пользователей, которые имеют отношение к безопасности, с автоматической записью информации о них в специальные журналы) – находится в сфере внимания многих современных стандартов безопасности и целого ряда регулирующих актов, -- таких, как стандарт Банка России "Обеспечение информационной безопасности организаций банковской системы Российской Федерации", международный стандарт безопасности информационных систем ISO 17799:2005, его предшественник от 2000 года и соответствующий Российский ГОСТ Р ИСО/МЭК 17799-2005 "Информационная технология - Практические правила управления информационной безопасностью", Payment Card Industry Data Security Standard (PCI DSS), знаменитый закон Sarbanes- Oxley и др.
5 пунктов о журналах аудита
Эксперт Кимбер Спрэдлин (Kimber Spradlin) из Embarcadero Technologies сформулировал 5 пунктов о журналах аудита, которые стоит принять во внимание всем, кто имеет отношение к безопасности БД. Журналы аудита – важная область, связанная с безопасностью баз данных, и в частности, с обеспечением выполнения требований стандартов по ИБ.
Вне зависимости от страны и рода деятельности, компании сталкиваются с требованиями соблюдения законодательных норм по ИБ и конфиденциальности данных. Тем не менее, ни одна из этих норм, возможно, за исключением Payment Card Industry’s Data Security Standard (PCI DSS), не содержит четких указаний, как именно им следует удовлетворять. Другими словами, любой совет, связанный с проектированием и управлением БД, скорее всего, будет достаточно общим.
Но мы попробуем сформулировать определенные правила, выполнение которых поможет сделать базы данных более защищенными, удовлетворяющими законодательным требованиям, сконцентрировав свое внимание на ключевой области, связанной с безопасностью баз данных – на журналах аудита.
1. На чем основаны правила. Большинство законодательных норм в ИТ сформулировано намеренно расплывчато. Поэтому специалистам по аудиту и безопасности в области ИТ приходится искать соответствующие руководства и интерпретации в дополнительных источниках. Наиболее распространенными из них являются ISO 17799 – Code of Practice for Information Security Management, Control Objectives for Information and related Technology (CobiT), IT Infrastructure Library (ITIL) и связанные с ними публикации правительственных организаций. Эти документы дают некоторые представления о том, какие данные нужно записывать в журнал аудита, как его защитить и как использовать содержащуюся в нем информацию.
2. Что записывать в журнал. В первую очередь, необходимо определить, какие данные нужно записывать в журнал. Вне зависимости от требований законодательных норм, в журнале должны быть данные по системному доступу, деятельности привилегированных пользователей, системным изменениям и изменениям схемы.
Данные, которые нужно записывать в журнал
Системный доступ: - Успешные и неудачные логины
Изменения, связанные с пользователями, ролями, доступом и паролями
Деятельность привилегированных пользователей: - Все
Системные изменения: - Подключения/отключения журналов
Подключения/отключения служб
Изменения конфигурации
Перезагрузки
Ошибки
Изменения схемы: - Создания/удаления/изменения объектов БД - таблиц и полей, процедур, пакетов, представлений
Изменения данных*: - Вставки, обновления или удаления записей
Доступ к данным**: - Неудачные и успешные попытки (обычно запросы SELECT)
* для соблюдения законодательных норм, касающихся целостности данных, таких, как Basel II Accord или Sarbanes-Oxley
** для удовлетворения требований по конфиденциальности данных
Источник: Embarcadero Technologies, 2008
Получился довольно объемный список. Рассмотрим далее, что нужно делать с журналами и каким образом это можно реализовать.
3. Как защитить журналы. Для аудиторов и регулирующих органов недостаточно собранной информации - нужно доказать, что полученные данные полны и точны. Это означает, что в систему должна быть встроена защита, либо должны быть построены специальные защищенные процессы. У аудиторов это называется "разделение обязанностей", - должна существовать гарантия того, что один и тот же человек не сможет быть инициатором действий, выдавать на них разрешения и контролировать осуществление. Применительно к журналу аудита это означает, что люди, чьи действия записываются в журнал, не должны иметь доступ к журналу аудита или управлять им.
Требования, указанные в различных законодательных нормах, руководствах и стандартах, включают ограничение доступа на чтение, размещение журналов в местах, отдельных от объектных БД и недоступных их администраторам, запрет на изменения в журналах, выделение необходимого дискового пространства (чтобы не допускать потерь данных и системных ошибок), шифрование любой важной информации, содержащейся в журналах, наличие онлайновых предупреждений об изменениях, проблемах с пространством или ошибках, связанных с журналами.
4. Как использовать журналы. Использование данных, собираемых в журналах аудита, не так очевидно на первый взгляд. В зависимости от типа информации, вида бизнеса, и применимых законодательных актов, с которыми приходится сталкиваться, журнальные файлы следует изучать с разной частотой – некоторые из них подлежат непрерывному контролю, другие – просмотру раз в месяц или даже раз в квартал.
Если в системе есть настроенная компонента, выдающая сообщения по журналам аудита в реальном времени, журнальные файлы не придется просматривать слишком часто, нужно будет лишь отслеживать подозрительные изменения и тренды. Например, если за последний месяц отношение неудачных логинов к успешным резко увеличилось, это стоит проанализировать более детально.
Данные по действиям привилегированных пользователей необходимо просматривать чаще, чем по обычным - как минимум раз в неделю - и более детально. Также повышенного внимания заслуживают изменения привилегий пользователей и, если возможно, отчеты по неавторизованным изменениям конфигурации и схем.
Детализированные и суммарные отчеты по коррекции данных и доступу к ним стоит просматривать где-нибудь раз в месяц. И здесь опять стоит обращать особое внимание на соотношения и тренды. Об опасности может сигнализировать, например, увеличение числа неудачных SELECT’ов.
Кроме всего прочего, необходимо определить, сколько времени нужно хранить данные аудита. Обычно в течение трех месяцев информация находится в онлайн-хранилищах (данное ограничение по времени связано с требованиями к пространству хранения) и до 7 лет - в оффлайн-хранилищах. Юристы компаний рекомендуют хранить сведения ровно столько, сколько требуется, и ни днем больше.
5. Какие отчеты будут необходимы. Возможно, не стоило бы собирать столько данных, если бы это действительно не было необходимым. Несомненно, что людям, которые формулируют требования к регистрируемым данным, понадобятся некоторые отчеты.
Ключевые отчеты:
Отчет Описание Частота
Действия ВСЕХ Необходимо Ежедневно,
привилегированных наблюдать за этими еженедельно
пользователей наблюдателями
Неавторизованные изменения Сравнение реальных изменений Еженедельно
- привилегии, пользователи, с отчетом по авторизованным
схема, конфигурация изменениям из процесса по
управлению изменениями
Сравнение пользовательских
аккаунтов и приложений,
используемых при внесении
изменений, со списком
авторизованных
Тренды по входам/выходам Обзор для выявления основных Ежемесячно
из системы трендов и определения (стоит настроить
нестандартных схем поведения немедленное
Разделение на рабочее информирование
и нерабочее время по наиболее
для более осмысленных подозрительным
отчетов видам активности)
Источник: Embarcadero Technologies, 2008
В первую очередь потребуются, как минимум, три ключевых отчета – действия всех привилегированных пользователей, неавторизованные изменения (привилегии, пользователи, схемы, конфигурации) и тренды по входам/выходам из системы.
Наблюдение, анализ и контроль доступа
Итак, мы уже убедились в том, что следующим шагом за регистрацией данных в журналах аудита, позволяющим построить детальный контроль, является наблюдение (зарегистрированных данных) и анализ. Сами по себе отчеты не выходят за рамки такого наблюдения: это те же самые зарегистрированные данные, но в концентрированном или статистически обобщенном виде. Они могут навести на определенные мысли, но не реализуют собственно анализ. Что же делать со всеми этими данными, и какой анализ при этом требуется?
Итак, зафиксируем этот этап, когда детальные журналы аудита, хранящие след прошедшей активности по доступу к данным, есть, но собственно анализа еще нет, т.е. контроль как общее понятие – не реализован. Попробуем сделать следующий шаг, т.е. сформулировать принципы такого анализа и построить фундамент необходимого контроля.
Ясно, что целью анализа является отделение "правильных" операций от противоправных (или хотя бы от "подозрительных", если сразу не можем точно отделить одни от других).
В некоторых случаях для этих целей можно построить автоматизированные процессы контроля, например, для сравнения списков авторизованных изменений прав пользователей с реально осуществленными операциями (о чем упоминалось выше).
Иногда стоит попробовать "искать под фонарем", т.е. анализировать то, что легче всего поддается изучению. При этом не следует пренебрегать интуитивными способностями, в том числе "пространственным" знанием объекта, концентрирующим предыдущий опыт – т.е. знанием о конкретном содержимом базы, об используемых приложениях, персоналиях, осуществляющих доступ, и проч.
Например, в банке, глядя на отчет о лицах, имевших объемный доступ к таблице с персональными данными, можно на интуитивном уровне и с учетом "пространственного" знания объекта определить, кто действительно мог иметь необходимость работы с ними, а кто вызывает подозрение. Или на производственном предприятии: объемный доступ к информации об экспортных операциях со стороны группы лиц не вызовет подозрений, если известно, что руководство поручило им подготовку аналитического отчета по этой теме.
В каждой конкретной индустрии и на каждом конкретном предприятии такой "интуитивный" анализ может быть весьма эффективным и даже быть оформлен в виде некоторого внутреннего стандарта, однако, как мы увидим ниже, он имеет ряд ограничений.
Приведем еще несколько примеров. Так, если некто с нехорошими намерениями написал процедуру перекачки информации из таблицы с персональными данными во временную таблицу, не вызывающую подозрений, и в результате получил к ним доступ, не привлекая пристального внимания со стороны контролирующих структур – это явная брешь в защите данных.
Еще один пример. В базе данных появились таблицы, содержащие конфиденциальную информацию, но в силу слабого взаимодействия между подразделениями контролирующая служба узнала о них с опозданием. Риск злоупотреблений при бесконтрольном доступе к этим данным – налицо.
Для устранения такого рода "брешей" в защите следует включить в сферу наблюдения более широкий спектр внутренних операций компании, чтобы сделать возможным всесторонний анализ.
Для фокусирования внимания к наиболее важным компонентам информационной системы служит классификация наблюдаемых объектов, ограничение каналов доступа к данным, формализация процедур работы привилегированных пользователей. Все это позволит сделать анализ даже на интуитивном уровне более всеохватывающим, включив в сферу контроля те области, которые ускользали от нашего внимания, а в ряде случаев позволит внедрить формализованные процедуры контроля.
Итак, суммируя вышесказанное, получаем набор действий, требуемых для организации контроля доступа к БД, порядок выполнения которых может меняться, но суммарно должен содержать следующее.
Необходима реализация на деле "всевидящего ока", т.е. регистрация полного следа, включающего абсолютно все активности, связанные с базой данных. Это пригодится не только для анализа, о котором ведется речь, но и при расследованиях обнаружившихся фактов утечек информации (и для установления еще более высокого уровня "психологического" барьера для потенциальных инсайдеров, о котором говорилось в самом начале).
Классификация объектов БД при помощи атрибутов, характеризующих степень конфиденциальности, поможет "сузить" область наиболее пристального внимания. Исключение возможности внедрения в базу любых "левых" объектов: фиксация эталонной схемы БД, реализация стандартного бизнес-процесса внесения изменений, введение периодического контроля соответствия схем "живой" БД и архивного эталона позволит быть уверенными, что в базе не происходит "внутренней" утечки.
Формализация процессов работы привилегированных пользователей и ввод документированных бизнес-процессов изменения прав, внесения изменений в схему обеспечит контроль наиболее “чувствительных” операций. Практически полный запрет работы с консоли на сервере БД исключит возможность мошенничества, связанного с временным отключением функций контроля (возможность доступа к БД с консоли при любой реализации контроля не может исключить определенных уязвимостей). Работа с консоли должна разрешаться строго ограниченному кругу лиц и быть подчинена жестким правилам.
Детальная проработка объема и частоты наблюдения, в том числе задание онлайновых нотификаций о нестандартной активности, выдача периодических оффлайновых отчетов, их рассмотрение с учетом "пространственного" знания объекта позволит сопоставлять реальную активность по работе с данными модельным представлениям, построенным на основе всех возможных источников. Для более многостороннего анализа поможет статистическое профилирование доступа по типам должностных обязанностей пользователей с последующим сравнением повседневной активности каждого из них с модельным профилем – для выявления и анализа фактов нетипичного поведения.
Таким образом, наблюдение становится более всеохватывающим, контроль – более плотным.
Техническая реализация полного аудита по типу "всевидящего ока", практически не оказывающего влияния на объектную систему, хотя и не является широко распространенной, на самом деле особой трудности сегодня не представляет.
С использованием полного аудита, формализацией процедур работы привилегированных пользователей и внедрением контроля схемы БД существенно сужаются возможности получения данных из БД за рамками стандартных операций доступа.
Осталось одно: автоматический контроль каждого акта доступа к данным.
Этот шаг по пути эскалации степени контроля дается с бОльшим трудом, и полностью реализовать его – скорее всего, утопия.
Что он означает? Автоматический контроль всех бизнес-процессов, включающих доступ к важным данным. Например, если оператор call-центра телефонного провайдера получил запрос на выдачу детализированного счета для определенного абонента, должна существовать возможность автоматического сопоставления факта доступа к базе с наличием авторизации соответствующего клиентского запроса относительно этой детализации.
Для некоторых выделенных бизнес-процессов реализовать подобный контроль не так уж сложно, но охватить им все акты доступа к данным…
Возвращаясь к началу этой статьи, отметим, что, несмотря на трудности, содержащиеся в самой постановке задачи по обнаружению вредоносной или подозрительной активности инсайдеров, в ее реализации может быть достигнут серьезный прогресс при выстраивании подхода, объединяющего полноту собираемых данных о фактах доступа, скрупулезную работу по ограничению возможных "каналов" утечки, построение автоматизированного контроля бизнес-процедур, включающих работу с корпоративными данными, и применение конкретных "пространственных" знаний о внутренних процессах в компании для анализа всех существующих активностей.
CNews
вверх^
к полной версии
понравилось!
в evernote
Корпоративные базы данных нередко оказываются незащищенными от действий инсайдеров, поскольку злоумышленникам, работающим в компании, нетрудно замаскировать воровство конфиденциальных данных под обычный рабочий процесс. Как же организовать эффективную защиту? Необходим целый комплекс мер, включающий, помимо ведения журнала аудита, анализ потенциальных каналов утечки и их "сужение", выстраивание формализованных процедур контроля.
Широкое обсуждение разнообразных мер по защите данных от инсайдеров, ведущееся многими специалистами, все же не проясняет до конца сути вопроса. Под эту тему попадает все, включая контент-анализ информационных сообщений, выходящих за пределы организации, контроль подключаемых накопителей, контроль действий сотрудников на их рабочих местах и многое другое. Однако защите от инсайдеров корпоративных баз данных, хранящих стратегические нематериальные активы компаний, несомненно, должно придаваться первостепенное значение.
В рамках данной статьи мы рассмотрим доступ к корпоративным базам данных со стороны собственных сотрудников компании, которые имеют все необходимые права и работают с этими базами, выполняя свои прямые производственные обязанности. За пределами нашего внимания останется защита резервных копий и данных в мобильных устройствах, а также ряд других аспектов защиты баз, отличающихся тем, что в отношении них более или менее понятно, что и от кого защищать, и можно провести определенную аналогию с защитой периметра.
Особенность ситуации с доступом к БД состоит в том, что вредоносная деятельность сотрудника легко может быть замаскирована под обычную служебную активность. Таким образом, задача, которую мы пытаемся разрешить, является еще одним воплощением старой, как мир, проблемы – как выявить скрытых "врагов" в кругу "друзей".
Но давайте снимем эту излишнюю эмоциональную окраску – в компании нет ни друзей, ни врагов - только сотрудники. И некоторые из них могут сознательно действовать в ущерб компании (так называемые "обиженные", либо "лазутчики", засланные кем-то с криминальными намерениями, либо сотрудники, завербованные с этой же целью), другие могут находиться в некотором "пограничном" состоянии, борясь с соблазном "продаться". Есть еще одна категория – люди рассеянные или недисциплинированные, которые могут нанести ущерб ненамеренно.
На чем можно построить противодействие активным вредоносным элементам и как приучить к дисциплине "пассивных" потенциально опасных сотрудников?
Контроль и аудит
Первое, что приходит в голову, - это слово "контроль". Еще не определив это понятие и не наполнив его содержанием, можно согласиться с тем, что контроль - это хорошо: по меньшей мере, его наличие позволит поднять психологическую планку, которую необходимо преодолеть потенциальным "кротам" для начала своей вредоносной деятельности. Находясь в поле действия "контроля", такой субъект уже не просто берет то, что "плохо лежит", а должен спланировать свои действия, сознательно пойти на риск, что осложнит выполнение его намерений и во многих случаях заставит от них отказаться. Угроза наказания поможет приучить к дисциплине рассеянных.
Но каким конкретным содержанием может быть наполнено слово "контроль"?
Руководствуясь здравым смыслом, можно заключить, что это прослеживание событий, связанных с контролируемой сферой активности, с последующим анализом и выделением противоправных, сомнительных и потенциально опасных действий.
Прослеживание событий (или более терминологически точно – аудит, т.е. регистрация тех действий пользователей, которые имеют отношение к безопасности, с автоматической записью информации о них в специальные журналы) – находится в сфере внимания многих современных стандартов безопасности и целого ряда регулирующих актов, -- таких, как стандарт Банка России "Обеспечение информационной безопасности организаций банковской системы Российской Федерации", международный стандарт безопасности информационных систем ISO 17799:2005, его предшественник от 2000 года и соответствующий Российский ГОСТ Р ИСО/МЭК 17799-2005 "Информационная технология - Практические правила управления информационной безопасностью", Payment Card Industry Data Security Standard (PCI DSS), знаменитый закон Sarbanes- Oxley и др.
5 пунктов о журналах аудита
Эксперт Кимбер Спрэдлин (Kimber Spradlin) из Embarcadero Technologies сформулировал 5 пунктов о журналах аудита, которые стоит принять во внимание всем, кто имеет отношение к безопасности БД. Журналы аудита – важная область, связанная с безопасностью баз данных, и в частности, с обеспечением выполнения требований стандартов по ИБ.
Вне зависимости от страны и рода деятельности, компании сталкиваются с требованиями соблюдения законодательных норм по ИБ и конфиденциальности данных. Тем не менее, ни одна из этих норм, возможно, за исключением Payment Card Industry’s Data Security Standard (PCI DSS), не содержит четких указаний, как именно им следует удовлетворять. Другими словами, любой совет, связанный с проектированием и управлением БД, скорее всего, будет достаточно общим.
Но мы попробуем сформулировать определенные правила, выполнение которых поможет сделать базы данных более защищенными, удовлетворяющими законодательным требованиям, сконцентрировав свое внимание на ключевой области, связанной с безопасностью баз данных – на журналах аудита.
1. На чем основаны правила. Большинство законодательных норм в ИТ сформулировано намеренно расплывчато. Поэтому специалистам по аудиту и безопасности в области ИТ приходится искать соответствующие руководства и интерпретации в дополнительных источниках. Наиболее распространенными из них являются ISO 17799 – Code of Practice for Information Security Management, Control Objectives for Information and related Technology (CobiT), IT Infrastructure Library (ITIL) и связанные с ними публикации правительственных организаций. Эти документы дают некоторые представления о том, какие данные нужно записывать в журнал аудита, как его защитить и как использовать содержащуюся в нем информацию.
2. Что записывать в журнал. В первую очередь, необходимо определить, какие данные нужно записывать в журнал. Вне зависимости от требований законодательных норм, в журнале должны быть данные по системному доступу, деятельности привилегированных пользователей, системным изменениям и изменениям схемы.
Данные, которые нужно записывать в журнал
Системный доступ: - Успешные и неудачные логины
Изменения, связанные с пользователями, ролями, доступом и паролями
Деятельность привилегированных пользователей: - Все
Системные изменения: - Подключения/отключения журналов
Подключения/отключения служб
Изменения конфигурации
Перезагрузки
Ошибки
Изменения схемы: - Создания/удаления/изменения объектов БД - таблиц и полей, процедур, пакетов, представлений
Изменения данных*: - Вставки, обновления или удаления записей
Доступ к данным**: - Неудачные и успешные попытки (обычно запросы SELECT)
* для соблюдения законодательных норм, касающихся целостности данных, таких, как Basel II Accord или Sarbanes-Oxley
** для удовлетворения требований по конфиденциальности данных
Источник: Embarcadero Technologies, 2008
Получился довольно объемный список. Рассмотрим далее, что нужно делать с журналами и каким образом это можно реализовать.
3. Как защитить журналы. Для аудиторов и регулирующих органов недостаточно собранной информации - нужно доказать, что полученные данные полны и точны. Это означает, что в систему должна быть встроена защита, либо должны быть построены специальные защищенные процессы. У аудиторов это называется "разделение обязанностей", - должна существовать гарантия того, что один и тот же человек не сможет быть инициатором действий, выдавать на них разрешения и контролировать осуществление. Применительно к журналу аудита это означает, что люди, чьи действия записываются в журнал, не должны иметь доступ к журналу аудита или управлять им.
Требования, указанные в различных законодательных нормах, руководствах и стандартах, включают ограничение доступа на чтение, размещение журналов в местах, отдельных от объектных БД и недоступных их администраторам, запрет на изменения в журналах, выделение необходимого дискового пространства (чтобы не допускать потерь данных и системных ошибок), шифрование любой важной информации, содержащейся в журналах, наличие онлайновых предупреждений об изменениях, проблемах с пространством или ошибках, связанных с журналами.
4. Как использовать журналы. Использование данных, собираемых в журналах аудита, не так очевидно на первый взгляд. В зависимости от типа информации, вида бизнеса, и применимых законодательных актов, с которыми приходится сталкиваться, журнальные файлы следует изучать с разной частотой – некоторые из них подлежат непрерывному контролю, другие – просмотру раз в месяц или даже раз в квартал.
Если в системе есть настроенная компонента, выдающая сообщения по журналам аудита в реальном времени, журнальные файлы не придется просматривать слишком часто, нужно будет лишь отслеживать подозрительные изменения и тренды. Например, если за последний месяц отношение неудачных логинов к успешным резко увеличилось, это стоит проанализировать более детально.
Данные по действиям привилегированных пользователей необходимо просматривать чаще, чем по обычным - как минимум раз в неделю - и более детально. Также повышенного внимания заслуживают изменения привилегий пользователей и, если возможно, отчеты по неавторизованным изменениям конфигурации и схем.
Детализированные и суммарные отчеты по коррекции данных и доступу к ним стоит просматривать где-нибудь раз в месяц. И здесь опять стоит обращать особое внимание на соотношения и тренды. Об опасности может сигнализировать, например, увеличение числа неудачных SELECT’ов.
Кроме всего прочего, необходимо определить, сколько времени нужно хранить данные аудита. Обычно в течение трех месяцев информация находится в онлайн-хранилищах (данное ограничение по времени связано с требованиями к пространству хранения) и до 7 лет - в оффлайн-хранилищах. Юристы компаний рекомендуют хранить сведения ровно столько, сколько требуется, и ни днем больше.
5. Какие отчеты будут необходимы. Возможно, не стоило бы собирать столько данных, если бы это действительно не было необходимым. Несомненно, что людям, которые формулируют требования к регистрируемым данным, понадобятся некоторые отчеты.
Ключевые отчеты:
Отчет Описание Частота
Действия ВСЕХ Необходимо Ежедневно,
привилегированных наблюдать за этими еженедельно
пользователей наблюдателями
Неавторизованные изменения Сравнение реальных изменений Еженедельно
- привилегии, пользователи, с отчетом по авторизованным
схема, конфигурация изменениям из процесса по
управлению изменениями
Сравнение пользовательских
аккаунтов и приложений,
используемых при внесении
изменений, со списком
авторизованных
Тренды по входам/выходам Обзор для выявления основных Ежемесячно
из системы трендов и определения (стоит настроить
нестандартных схем поведения немедленное
Разделение на рабочее информирование
и нерабочее время по наиболее
для более осмысленных подозрительным
отчетов видам активности)
Источник: Embarcadero Technologies, 2008
В первую очередь потребуются, как минимум, три ключевых отчета – действия всех привилегированных пользователей, неавторизованные изменения (привилегии, пользователи, схемы, конфигурации) и тренды по входам/выходам из системы.
Наблюдение, анализ и контроль доступа
Итак, мы уже убедились в том, что следующим шагом за регистрацией данных в журналах аудита, позволяющим построить детальный контроль, является наблюдение (зарегистрированных данных) и анализ. Сами по себе отчеты не выходят за рамки такого наблюдения: это те же самые зарегистрированные данные, но в концентрированном или статистически обобщенном виде. Они могут навести на определенные мысли, но не реализуют собственно анализ. Что же делать со всеми этими данными, и какой анализ при этом требуется?
Итак, зафиксируем этот этап, когда детальные журналы аудита, хранящие след прошедшей активности по доступу к данным, есть, но собственно анализа еще нет, т.е. контроль как общее понятие – не реализован. Попробуем сделать следующий шаг, т.е. сформулировать принципы такого анализа и построить фундамент необходимого контроля.
Ясно, что целью анализа является отделение "правильных" операций от противоправных (или хотя бы от "подозрительных", если сразу не можем точно отделить одни от других).
В некоторых случаях для этих целей можно построить автоматизированные процессы контроля, например, для сравнения списков авторизованных изменений прав пользователей с реально осуществленными операциями (о чем упоминалось выше).
Иногда стоит попробовать "искать под фонарем", т.е. анализировать то, что легче всего поддается изучению. При этом не следует пренебрегать интуитивными способностями, в том числе "пространственным" знанием объекта, концентрирующим предыдущий опыт – т.е. знанием о конкретном содержимом базы, об используемых приложениях, персоналиях, осуществляющих доступ, и проч.
Например, в банке, глядя на отчет о лицах, имевших объемный доступ к таблице с персональными данными, можно на интуитивном уровне и с учетом "пространственного" знания объекта определить, кто действительно мог иметь необходимость работы с ними, а кто вызывает подозрение. Или на производственном предприятии: объемный доступ к информации об экспортных операциях со стороны группы лиц не вызовет подозрений, если известно, что руководство поручило им подготовку аналитического отчета по этой теме.
В каждой конкретной индустрии и на каждом конкретном предприятии такой "интуитивный" анализ может быть весьма эффективным и даже быть оформлен в виде некоторого внутреннего стандарта, однако, как мы увидим ниже, он имеет ряд ограничений.
Приведем еще несколько примеров. Так, если некто с нехорошими намерениями написал процедуру перекачки информации из таблицы с персональными данными во временную таблицу, не вызывающую подозрений, и в результате получил к ним доступ, не привлекая пристального внимания со стороны контролирующих структур – это явная брешь в защите данных.
Еще один пример. В базе данных появились таблицы, содержащие конфиденциальную информацию, но в силу слабого взаимодействия между подразделениями контролирующая служба узнала о них с опозданием. Риск злоупотреблений при бесконтрольном доступе к этим данным – налицо.
Для устранения такого рода "брешей" в защите следует включить в сферу наблюдения более широкий спектр внутренних операций компании, чтобы сделать возможным всесторонний анализ.
Для фокусирования внимания к наиболее важным компонентам информационной системы служит классификация наблюдаемых объектов, ограничение каналов доступа к данным, формализация процедур работы привилегированных пользователей. Все это позволит сделать анализ даже на интуитивном уровне более всеохватывающим, включив в сферу контроля те области, которые ускользали от нашего внимания, а в ряде случаев позволит внедрить формализованные процедуры контроля.
Итак, суммируя вышесказанное, получаем набор действий, требуемых для организации контроля доступа к БД, порядок выполнения которых может меняться, но суммарно должен содержать следующее.
Необходима реализация на деле "всевидящего ока", т.е. регистрация полного следа, включающего абсолютно все активности, связанные с базой данных. Это пригодится не только для анализа, о котором ведется речь, но и при расследованиях обнаружившихся фактов утечек информации (и для установления еще более высокого уровня "психологического" барьера для потенциальных инсайдеров, о котором говорилось в самом начале).
Классификация объектов БД при помощи атрибутов, характеризующих степень конфиденциальности, поможет "сузить" область наиболее пристального внимания. Исключение возможности внедрения в базу любых "левых" объектов: фиксация эталонной схемы БД, реализация стандартного бизнес-процесса внесения изменений, введение периодического контроля соответствия схем "живой" БД и архивного эталона позволит быть уверенными, что в базе не происходит "внутренней" утечки.
Формализация процессов работы привилегированных пользователей и ввод документированных бизнес-процессов изменения прав, внесения изменений в схему обеспечит контроль наиболее “чувствительных” операций. Практически полный запрет работы с консоли на сервере БД исключит возможность мошенничества, связанного с временным отключением функций контроля (возможность доступа к БД с консоли при любой реализации контроля не может исключить определенных уязвимостей). Работа с консоли должна разрешаться строго ограниченному кругу лиц и быть подчинена жестким правилам.
Детальная проработка объема и частоты наблюдения, в том числе задание онлайновых нотификаций о нестандартной активности, выдача периодических оффлайновых отчетов, их рассмотрение с учетом "пространственного" знания объекта позволит сопоставлять реальную активность по работе с данными модельным представлениям, построенным на основе всех возможных источников. Для более многостороннего анализа поможет статистическое профилирование доступа по типам должностных обязанностей пользователей с последующим сравнением повседневной активности каждого из них с модельным профилем – для выявления и анализа фактов нетипичного поведения.
Таким образом, наблюдение становится более всеохватывающим, контроль – более плотным.
Техническая реализация полного аудита по типу "всевидящего ока", практически не оказывающего влияния на объектную систему, хотя и не является широко распространенной, на самом деле особой трудности сегодня не представляет.
С использованием полного аудита, формализацией процедур работы привилегированных пользователей и внедрением контроля схемы БД существенно сужаются возможности получения данных из БД за рамками стандартных операций доступа.
Осталось одно: автоматический контроль каждого акта доступа к данным.
Этот шаг по пути эскалации степени контроля дается с бОльшим трудом, и полностью реализовать его – скорее всего, утопия.
Что он означает? Автоматический контроль всех бизнес-процессов, включающих доступ к важным данным. Например, если оператор call-центра телефонного провайдера получил запрос на выдачу детализированного счета для определенного абонента, должна существовать возможность автоматического сопоставления факта доступа к базе с наличием авторизации соответствующего клиентского запроса относительно этой детализации.
Для некоторых выделенных бизнес-процессов реализовать подобный контроль не так уж сложно, но охватить им все акты доступа к данным…
Возвращаясь к началу этой статьи, отметим, что, несмотря на трудности, содержащиеся в самой постановке задачи по обнаружению вредоносной или подозрительной активности инсайдеров, в ее реализации может быть достигнут серьезный прогресс при выстраивании подхода, объединяющего полноту собираемых данных о фактах доступа, скрупулезную работу по ограничению возможных "каналов" утечки, построение автоматизированного контроля бизнес-процедур, включающих работу с корпоративными данными, и применение конкретных "пространственных" знаний о внутренних процессах в компании для анализа всех существующих активностей.
CNews
Вы сейчас не можете прокомментировать это сообщение.
Дневник Базы данных: как защититься от инсайдеров? | neozakonnik - Дневник neozakonnik |
Лента друзей neozakonnik
/ Полная версия
Добавить в друзья
Страницы:
раньше»