62
Разработчики стремятся учесть общие требования информационной
без-опасности и требования своих заказчиков, поэтому на рынке постоянно
появляется большое число специализированных DLP-систем.
Специалистам, отвечающим за безопасности предприятий и
готовящихся к обеспечению защиты корпоративной информации от утечек,
важно оценить, какими будут через 3-5 лет специализированные системы
защиты от утечек. Такая оценка позволит вложиться именно в те технологии,
которые найдут применение и в будущем.
Проекты внедрения и использования DLP нельзя считать чисто
техноло-гическими, т.к. в них задействованы помимо представителей
вендоров владельцы информационных ресурсов организации и служба
информационных технологий и защиты информации предприятия. Опираясь
на логику работы продукта, необходимо участие каждого участника
обеспечения конфиденциальности информации. [5]
Принцип эксплуатации системы DLP должен заключаться в
циклическом выполнении нескольких процедур, описанных в таблице 2.
Таблица 2 - Схема эксплуатации системы DLP
Процедура
Описание процедуры
Роль участников со
стороны бизнес-
подразделений
Обучение
системы
принципам
классификации
информации
Передача в DLP принципов обнаружения и
классификации конфиденциальной
информации.
Владельцы
информационных
ресурсов участвуют в
классификации
информации и
указания мест
расположения
ресурсов.
Ввод правил
реагирования
Настройка правил реагирования системы в
привязке к категории обнаруживаемой
информации и групп сотрудников, контроль
действий которых должен осуществляться.
Прописываются в исключения пользователи,
действия которых пользуются доверием.
Службой ИТ и защиты
информации
разрабатываются и
затем уточняются
правила защиты
ресурсов
63
Продолжение таблицы 2
Процедура
Описание процедуры
Роль участников со
стороны бизнес-
подразделений
Выполнение
системой DLP
операций
контроля
Система анализирует и нормализует
информацию (исходящие информационные
потоки, результаты сканирования сетевых
ресурсов и рабочих станций, локальные
действия пользователей). Выполняется
сопоставление с принципами обнаружения и
классификации данных. При обнаружении
конфиденциальной информации система
сопоставляет с существующими политиками,
назначенными на обнаруженную категорию
информации. В случае нарушений в системе
создается «инцидент».
Служба ИТ и защиты
информации получает
уведомления о
произошедших
инцидентах.
Обработка
инцидентов
Созданные инциденты в системе могут быть
связаны с такими правилами реагирования,
как проинформировать, или приостановить,
или заблокировать отправку. Кроме того,
сводная информация и подробности об
инцидентах доступны для анализа службе ИТ
и защиты информации, владельцем ресурса в
системе. В результате обработки службой ИТ
и защиты информации, инцидент может быть
закрыт, или эскалирован, или направлен на
доработку политики.
Служба ИТ и защиты
информации участвует
в реагировании на
инциденты и дает
рекомендации по
исправлению правил
реагирования
Владельцы информационных ресурсов отвечают за хранение и
обработку информации определенной категории. Как правило, это
руководители структурных подразделений, которые определяют ценность
информации и ее отношение к той или иной категории.
Разработчики DLP допускают, что внедряющие организации не имеют
представления о том, какую информацию необходимо защищать. Тем не
менее, для повышения отдачи от использования DLP следует передать в
систему правила классификации собственных документов. [5]
При внедрении DLP-системы необходимо проводить обучение
системы, которое осуществляется следующим образом:
64
- ввод образцов конфиденциальной информации, разбитой по
категориям для снятия цифровых отпечатков;
- ввод выгрузок из актуальных баз данных для снятия отпечатков
баз данных;
- включение существующих в системе шаблонов политик
обнаружения;
- ввод собственных слов и выражений, характерных для
конфиденциальных данных на конкретном предприятии;
- ввод исключений (например, шаблоны договоров, стандартные
поля для исходящей корреспонденции). [1]
Вовлечение ответственных участников со стороны бизнес-
подразделений предприятия увеличивает отдачу от внедрения DLP-систем в
виде ожидаемых бизнесом результатов: сводной отчетности по
произошедшим инцидентам, измеряемого снижения рисков информационной
безопасности, связанных с утечками. [2]
Итак, можно выделить следующие рекомендации по внедрению DLP-
системы при реализации политики информационной безопасности на
предприятии:
1. Принятие решения о необходимость внедрения политики
информаци-онной безопасности на предприятии на основе использования
DLP-системы. Требуется проведение анализа следующих аспектов:
- цели и задачи внедрения политики информационной
безопасности;
- область применения DLP-системы;
- обоснование введения политики информационной безопасности;
- рассмотрение рисков от внедрения DLP-системы;
- определение целевой аудитории.
2. Решение организационных вопросов, а именно:
65
- определение ответственности при внедрении политики
информационной безопасности;
- контроль доступа к конфиденциальной информации;
- организация защиты оборудования и программного обеспечения
от не-санкционированного доступа;
- формирование правил использования конфиденциальной
информации;
- проведение классификации помещений;
- управление локальными сетями предприятия;
- обеспечение защиты и сохранности данных.
3. Выбор DLP-системы, исходя из следующих критериев:
- анализ предложений на рынке;
- изучение опыта подобных внедрений;
- рассмотрение достоинств и недостатков различных DLP-
решений;
- ценовая категория (выбор подходящего решения из
определенной ценовой категории).
4. Техническая реализация проекта внедрения политики
информационной безопасности на предприятии на основе использования
DLP-системы, которая состоит из следующих этапов:
- построение архитектуры системы;
- установка серверов и агентов для рабочих станций;
- инсталляция программного обеспечения;
- настройка оборудования и программного обеспечения;
- работа с системой.
66
3.2 Структура программно-аппаратного комплекса
информационной безопасности и защиты информации предприятия
АПК "Гарда Предприятие". Данное решение является DLP-системой,
предназначенной для контроля утечек конфиденциальной информации,
расследования связанных с ними инцидентов и решения других задач.
Рассматриваемый продукт является универсальным. Это значит, что он
является одновременно шлюзовым и хостовым. Это позволяет
контролировать с его помощью как локальные, так и сетевые каналы утечки
конфиденциальной информации. На сегодняшний день рассматриваемое
решение может контролировать все основные каналы корпоративных
коммуникаций - электронную почту, IM-системы, IP-телефонию, интернет-
сервисы (социальные сети, форумы, блоги, чаты и пр.), сервисы передачи
файлов (FTP, P2P и т.п.), съемные накопители, запускаемые на рабочем месте
программы и приложения, а также внешние устройства, в частности,
локальные и сетевые принтеры и факсы [17].
Важной особенностью рассматриваемого продукта является его
специализация. На сегодняшний день DLP-система «Гарда Предприятие»
остается одним из наиболее мощных решений, поскольку разработана
специально для использования в крупных и средних компаниях. Решение
обеспечивает очень высокую производительность, вплоть до 10 Гбит/с и
выше. Разработчик АПК "Гарда Предприятие", "МФИ Софт", является
известным на рынке производителем систем операторского уровня, в том
числе, систем СОРМ и решений для защиты от DDoS-атак. И уж кому, как не
специалистам этой компании, иметь большой опыт в области
высокопроизводительных сетевых приложений [18].
Рассматриваемое решение работает с зеркалированным трафиком. То
есть его установка "в разрыв" и работа в режиме фильтрации не
рассматривается. С одной стороны, это снижает функциональные
67
возможности системы. Однако нужно учитывать, что на практике в средних
и крупных компаниях крайне редко используется именно фильтрация. В
подавляющем большинстве случаев DLP-системы в них используются для
"прослушивания" трафика, то есть для мониторинга утечек, расследования
произошедших инцидентов, выявления нелояльных сотрудников и решения
прочих типовых задач. Поэтому, отсутствие режима фильтрации в решении,
строго говоря, нельзя считать серьезным недостатком [22].
Поставляется АПК "Гарда Предприятие" в виде готового аппаратно-
программного комплекса, в состав которого входит сервер и установленное
на него программное обеспечение. Такое решение удобно тем, что
потребитель получает уже готовое к запуску решение, которое полностью
удовлетворяет потребностям заказчика и позволяет провести его внедрение в
кратчайшие сроки. Впрочем, если у потенциального клиента уже есть
аппаратная платформа, продукт может быть продан и в виде программного
обеспечения.
В состав АПК "Гарда Предприятие" входят следующие модули
(рисунок 5):
Анализатор
База данных
Монитор
рабочего места
Центр управления
"Гарда
Предприятие"
Монитор
рабочего места
Монитор
рабочего места
Сервер
управления
рабочими
местами
Рисунок 5 - Состав АПК "Гарда Предприятие"
68
• "Анализатор" – аппаратно-программный комплекс,
предназначенный для перехвата и анализа трафика;
• База данных – СУБД с базой данных, в которой хранится вся
информация системы;
• "Сервер управления рабочими местами" – аппаратно-
программный комплекс для управления агентами на рабочих станциях;
• "Монитор рабочего места" – программа-агент,
устанавливающаяся на рабочие станции;
• "Центр управления "Гарда Предприятие" – программное
обеспечение для администратора системы и администраторов безопасности.
В системе может работать несколько анализаторов, которые будут
собирать информацию в единой базе данных. Это позволяет построить
высокопроизводительную, и распределенную систему защиты от утечек
конфиденциальной информации.
АПК "Гарда Предприятие" поставляется как готовый аппаратно-
программный комплекс, конфигурация которого рассчитана исходя из
потребностей конкретного клиента. Поэтому приводить какие-то системные
требования для серверных компонентов системы не имеет смысла.
В настоящее время для резервирования данных и обеспечения их
сохранности с вероятностью, близкой к 100%, применяется:
Хранение данных на дисках, связанных в RAID-массивы;
Резервное копирование фалов баз данных;
Зеркалирование серверов MS SQL.
Далее опишем каждый из методов более подробно и укажем его
реализацию на рассматриваемом предприятии.
Для создания RAID-массива будем использовать 8 дисков
Seagate ST3600057SS. Это серверные диски с повышенной надежностью и
максимальным объемом и скоростью вращения шпинделя для подобных
69
дисков 600гигабайт при 15 000 обор\м вращение шпинделя. Эти диски
подлежат объединению в 4 раздела Raid 1.
Логически их можно назвать следующим образом:
1. Раздел System ( Диск 1 + Диск 2) общий объем 600гигабайт на
данной диске установлена система и хранятся исполняемые файлы MS SQL
сервера;
2. Раздел Data (Диск 3 + Диск 4) общий объём 600гигабайт. На
данном диске хранятся файлы данных: UPP (Управление производственным
предприятием) – основная база в которой создаются и ведутся все
управленческие документы. База занимает - 280 гигабайт, CR (Центр
Розница) - Основная база данных для связи с розничной сетью в нее
поступают документы из UPP, которые база обрабатывает определенным
образом и выгружает на всю розничную сеть. И в обратном порядке данные
из магазинов поступают в CR, а оттуда выгружаются на UPP, где и
обрабатываются. Так же часть данных обрабатывается в CR - в основном это
данные, которые требуют быстрого реагирования и принятия каких- либо
мер. База данных занимает 96 гигабайт
3. Раздел Log (Диск 5 + Диск 6) Общий объём 600гигабайт. На
данном разделе располагаются Log файлы баз данных UPP и CR. Объем лог-
файлов каждой из баз варьируется от 50% до 200% от размера базы данных,
так как транзакции хранятся в несжатом виде для быстроты обработки.
4. Раздел TEMP (Диск 7 + Диск 8). Общий объём данных - 600
гигабайт В TEMP разделе хранится Файл Данных и Лог базы данных. TEMP -
это системная база данных сервера MS SQL, отличающаяся высокой
важностью и влиянием на работу всех баз данных на сервер. Ее сохранность
не так важна, как скорость работы в этой базе, так как любой запрос, который
поступает на сервер, получает данные из БД и складывает эти данные в
TEMP , далее обрабатывает необходимым образом и результаты выгружает в
70
ЛОГ файл базы данных, откуда они записываются непосредственно в файл
данных после завершения транзакции. ТЕМП база занимает около 80
Гигабайт. Так же этот диск выполняет функцию промежуточного диска для
бекапирования баз данных.
Рассмотрим план резервного копирования на примере базы данных
отдела продаж. Для нее предусмотрены следующие этапы:
FULL – Полное резервное копирование базы + регламентные задания;
DIFF – Дифференцируемый бекап;
TL – Бекап Лога.
Старт задания происходит в каждый понедельник в 2:00 часа. Это
время выбрано специально, так как в это время база никем не используется и
можно провести полное резервное копирование и другие регламентные
задания, часть из которых приводит к блокировке базы во время выполнения.
Первый этап в свою очередь состоит из определенного порядка действий
каждое последующие зависит от успешности выполнения предыдущего:
1. Backup Log UPP until - это действие делает бекап лога базы
данных, чтобы сохранить базу на момент перед началом всех регламентных
операций и полного Бекапа, то есть у нас всегда будет архив, время создания
которого на секунду раньше начала всех операций (длительность – 10
минут).
2. Shrink Log until – это действие обрезает Лог файл от всех
завершенных транзакций. Это необходимо для того, чтобы лог файл не
увеличивался бесконечно завершенными транзакциями, которые нам уже не
нужны, так как их сохранили в предыдущем шаге. (длительность – 2мин)
3. Rebuild index task – Это регламентная операция, которая
полностью перестраивает все индексы базы данных для более быстрого
поиска и обращения к ней, так как за неделю происходит очень много
операций добавления или удаления данных, которые приводят к неверным
71
индексам и увеличенному времени выполнение запросов. (длительность –
1.5часа)
4. Update statistic task – Происходит обновление статистики базы
данных, так же приводит к ускорению выполнения запросов, так как
перестраиваются все планы запросов (длительность – 1час).
5. DELL CASHE – Удаляется старые кеш запросов, чтобы запросы
пользовались обновленными индексами и статистикой, а не шли по ранее
созданному пути (длительность – 1мин).
6. Backup Log After – Производится бекап лога базы данных после
выполнения всех регламентных операций и непосредственно перед полным
бекапом (длительность – 15мин).
7. Shrink Log After – Обрезка лог файл перед бекапом, чтобы не
сохранять лишние данные в полный архив (длительность – 2мин).
8. Полный Backup UPP – Производится полное резервное
копирование базы данных и всех ее данных на текущий момент времени. Так
как выгружаемый архив с сервера очень большой (он почти равен полному
размеру базы), он сохраняется в разделе ТЕМП.
9. Программа APbackup автоматизирует архивирование бекапа
путем архивирования бекапа в формате 7zip p и копированием его на сетевое
хранилище NAS Dlink 343, на котором они в дальнейшей и хранятся
(длительность – 45мин +1.5часа). Программа АPbackup производит действия
в другое время не зависит от нагрузки базы.
10. Delete TL backup UPP for clear DISK – удаление бекапа ЛОГ
файлов, так как после успешного полного бекапирования они более не
актуальны.
Следующий этап, дифференцированное копирование (DIFF),
выполняется каждый день в 22:00.
Дифференцированное копирование содержит следующие этапы: