Введение

Эволюция угроз корпоративным данным вызвала соответствующие изменения в подходах к обеспечению информационной безопасности (ИБ) корпоративной ИТ-инфраструктуры. Множественные инциденты с данными, вызванные неправомерным использованием полномочий, повлекли создание в США отраслевых и государственных стандартов обеспечения безопасности, таких как Sarbanes — Oxley, HIPAA, COBIT и др. Из российских документов можно назвать появившийся недавно стандарт ЦБ РФ “Обеспечение ИБ организаций банковской системы РФ”. В данной статье мы предлагаем рассмотреть развитие концепции информационной безопасности с учетом новых требований к контролю доступа и хранению данных.

Управление полномочиями

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

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

Контроль доступа

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

  1. Недостаточность построения периметра. Современные технологии мобильной связи позволяют обходить стандартные программные и технические ограничения на доступ в интернет с рабочего места. Запрет на электронные устройства, способные передавать и хранить информацию, может снизить производительность труда сотрудников или вообще противоречить организации бизнеса.
  2. Инсайдеры. Возможность утечки данных на основании неправомерного использования предоставленных сотрудникам прав доступа вызвало появление целого сегмента рынка — DLP-систем, но проблема продолжает существовать. Отдельная категория угроз — уничтожение данных с соответствующей правкой системных журналов.
  3. Недостатки стандартных средств. Практически все ОС, базы данных и приложения имеют собственные журналы аудита и средства их просмотра. Работа с ними требует определенной квалификации и часто весьма трудоемка, создание удобочитаемых отчетов может потребовать часов и даже дней. Кроме того:
    • стандартные средства обычно не рассчитаны на обработку крупных объемов данных и требуют больших ресурсов продуктивных серверов;
    • сотрудник, создающий отчет, может случайно или сознательно пропустить важное событие, а неправильная фильтрация и сортировка способны исказить результаты в отчете. Поручите создание отчета об использовании интернет-каналов администратору — 99%, что он не будет в списке “лидеров”;
    • большое количество разнородных журналов затрудняет общую корреляцию событий. Например, в журнал Microsoft SQL Server заносятся действия пользователя, но данные о его входе/выходе нужно собирать из журналов безопасности ОС и домен-контроллеров. Сопоставление данных многих разных журналов в одну временную цепочку событий — задача нетривиальная и практически невыполнимая при отсутствии специальных инструментов.
  4. Большие объемы данных. Стандартный журнал аудита домен-контроллера при включенном полном аудите AD может достигать 2 Гб в сутки (!).

Виды аудита

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

Оперативный аудит

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

  • сбор информации о безопасности с как можно большего количества информационных ресурсов компании (в идеале 100%);
  • возможность создания триггеров, которые при наступлении заданной ситуации создают оповещения и/или выполняют какие-то дополнительные действия (например, блокируют источник вторжения); 
  • создание краткосрочных отчетов о состоянии ИБ и соответствии текущей ситуации политикам безопасности.

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

Сбор, долговременное хранение, проведение расследований

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

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

Область применения

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

Small:   небольшая компания — до 200 пользователей, несколько серверов. Зачастую под “производственными” системами понимается совместное использование документов на общем файловом ресурсе. Контроль над инфраструктурными серверами (например, AD) легко выполняется стандартными средствами.

Medium:   средняя компания (от 200 до 1000 пользователей, парк серверов, нередко на разных площадках). Обычно есть общие платформы ИС, содержащие серверы БД и серверы приложений. Необходим жесткий контроль полномочий в применяемых информационных системах. Контроль над инфраструктурными серверами требует отдельного внимания, так как необходимо собирать журналы с многих (часто — удаленных) серверов, а анализ полученной информации стандартными средствами затруднен.

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

Для каждой организации можно выбрать соответствующие средства аудита. Например, для небольшой компании нет необходимости собирать журналы аудита Active Directory — стандартный журнал AD security вполне достаточен для анализа и быстрого создания отчета по нему. С другой стороны, несколько домен-контроллеров могут записать в свои журналы действия одного пользователя, при этом эти записи не коррелируются в одно представление стандартными механизмами, поэтому для компаний Medium и Enterprise необходима система сбора и анализа данных журналов. Конечно, на практике нет четких границ между типами компаний, а значит, нет четких ограничений на используемый в ИТ-инфраструктуре инструментарий контроля безопасности.

Специализированный аудит SmallMedium Enterprise
Сетевая инфраструктура Нет Возможен Необходим
Единый каталог (AD) Нет Необходим Необходим
Общие файловые ресурсы Необходим Необходим Необходим
Почтовая система Нет Возможен Необходим
Серверы БД Нет Возможен Необходим
Серверы приложений Нет Возможен Необходим

Методы построения аудита ИС

На рынке ПО существует множество систем, обеспечивающих безопасность ИТ-инфраструктуры. При выборе системы под конкретную инфраструктуру необходимо обратить на некоторые технические аспекты. Выделим наиболее значимые.

Список поддерживаемых операционных систем и приложений

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

Сбор журналов

Существуют два метода сбора журналов.

  1. С помощью стандартных механизмов. Журналы Windows-систем могут быть перенаправлены или получены через интерфейсы WMI и WinRM. Для *nix-систем можно применять syslog server. Основное достоинство этого пути — стандартный для ОС целевого сервера метод. Из недостатков можно отметить отсутствие кэширования, шифрования и сжатия при передаче в централизованное хранилище.
  2. С помощью специализированных агентов. Применение агентов и коллекторов позволяет избежать недостатков, присущих встроенным механизмам: агенты могут быть настроены в соответствии с определяемыми политиками. При этом можно создавать сложные расписания для передачи журналов, использовать шифрование и сжатие. Агенты могут контролировать состояние журналов, например на предмет злоумышленной очистки. Но применение агентов имеет недостаток — дополнительную нагрузку на производственные серверы.

Централизованное хранение

Большинство представленных на ранке систем используют в качестве центрального хранилища журналов базу данных (обычно Oracle или MS SQL). Такой подход позволяет оперативно просматривать происходящие в инфраструктуре события и строить отчеты “на лету”, но имеет два существенных недостатка:

  1. хранение журналов в БД не уменьшает, а даже увеличивает (за счет накладных расходов самой базы данных) размер используемого дискового пространства;
  2. запись событий в базу ведет к очень интенсивному вводу-выводу, ведь каждое событие в журнале — фактически операция записи на диск. Так, при сборе журналов безопасности от десятка домен-контролеров в часы пик количество событий может достигать тысячи в секунду, что вызовет 1000 операций ввода-вывода в дисковой подсистеме.

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

Система отчетности

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

Заключение

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

Автор статьи — технический эксперт компании Allware Business Solutions.