Об эффективной и полноценной защите данных в жизненном цикле проектной документации

Предисловие

С уважением,
Аркадий Казанцев

Предотвратить нельзя поймать

Что делать? Как найти разумный баланс между «закручиванием гаек» и борьбой с утечками? Кого привлечь к поиску «брешей»?

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

Кадры решают: «Ой, всё!...»

С точки зрения информационной безопасности, тремя основными свойствами информации являются доступность, целостность и конфиденциальность. При этом в непосредственные задачи ИТ-службы, как подразделения, обслуживающего основной бизнес компании, входят прежде всего обеспечение постоянной доступности ИТ-сервисов и обеспечение их целостности (корректности). Задача же обеспечения конфиденциальности, т.е. разграничения доступа к информационным объектам, требует от ИТ-шника доскональных знаний о содержимом обрабатываемых данных, об их бизнес-ценности для компании, о полномочиях сотрудников в части доступа к тому или иному информационному контенту – то есть о тех «материях», о которых осознанно может судить лишь «владелец» этих данных – главный конструктор, руководитель проектного отдела, финансовый директор и пр. Другими словами, ИТ-шник просто не обладает достаточными знаниями для принятия оперативных текущих решений для обеспечения нужной степени конфиденциальности. В такой ситуации ИТ-шник либо «бьет по площадям», вводя общие ограничительные правила «для всех», либо старается переложить решение о классификации информационного контента на людей, способных реально оценивать важность обрабатываемых данных. Кроме того, ИТ-шнику мировоззренчески сложно внедрять защитные средства, затрудняющие и ограничивающие пользователям доступ к информационным ресурсам, ведь основная задача ИТ – обеспечивать как раз доступность ИТ-сервисов. Информационная безопасность зачастую понимается ИТ-шником как обеспечение безопасности не информационного контента, а безопасности самой ИТ-инфраструктуры – т.е. антивирусная защита, резервное копирование, устранение уязвимостей базового программного обеспечения, контроль доступа в Интернет и пр.

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

Анатомия утечки

Первое, что приходит в голову, когда встает задача обеспечения защиты информации – это поставить ограничительные барьеры на всех каналах связи, через которые информация может «утекать», и на этих барьерах попытаться успеть проанализировать, разрешено ли этой информации покидать периметр организации, или нет. Программные средства защиты должны уметь отличать «легитимные» перемещения от «нелегитимных», блокируя неразрешенные действия и пропуская разрешенные. Фактически такие средства должны анализировать весь трафик, на ходу разбирая и классифицируя контент. Поскольку основной задачей при этом становится определение «запретных» перемещений, то в систему должно вводиться множество признаков, по которым защитная система должна определять «неразрешенное» действие. Анализируется контекст, шаблоны, цифровые отпечатки, типы файлов и т.д. и т.п. Правила определения «запрещенного перемещения» должны анализировать все возможные способы (протоколы) передачи информации, отлавливая «подозрительную» информацию. При этом в погоне за зловредным нарушителем важно не заблокировать ложными срабатываниями нормальный производственный процесс, поскольку потери от простоев могут превысить возможный ущерб от утечки. В результате, компании вынуждены применять подобные средства лишь в режиме «зеркалирования» или мониторинга, сохраняя результаты сработки правил в архив для последующего «разбора полетов». Фактически, утечка все равно происходит, и мы узнаем о ней с запозданием. Правда, в системе остается след и есть возможность расследования инцидента и выявления виновного.

Не было у папы заботы…

Зачастую на этом месте руководитель уже опускает руки, понимая, что ввязавшись за борьбу с утечками, придется перерабатывать существующие и разрабатывать новые регламенты, привлекать и оплачивать дополнительную работу кадровиков и юристов, обучать сотрудников и требовать с них исполнения новых правил. Поэтому внедрение режима коммерческой тайны часто останавливается лишь на декларировании наличия такой тайны у организации и написании положения «О коммерческой тайне», но не перерастает в регулярный работающий процесс.

Где же выход из этого унылого круга? На самом деле выход есть, и он достаточно простой, нужно только поставить проблему «с головы на ноги».

В защиту режима

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

Во-первых, правильных, «разрешенных» рабочих процессов в компьютерной среде на порядок меньше, чем всех возможных. Разрешенные рабочие процессы заранее известны, более стабильны и менее вариативны. Поэтому список «разрешенных» процессов составить гораздо проще, чем описать все, «что нельзя».

Во-вторых, описывая и закрепляя «разрешенные» рабочие цепочки, мы стандартизуем и упорядочиваем их, что в конечном итоге приводит к увеличению их эффективности и безопасности.

В-третьих, построенная таким образом схема защиты никак не мешает правильным (разрешенным, легитимным) действиям пользователей, поскольку строится именно вокруг них.

Чтобы реализовать подход «Запрещено все, кроме того, что в явном виде разрешено» на уровне информационной системы, нам необходимо сделать четыре последовательных шага.

Дорогу осилит идущий

Шаг второй. Определение полномочий (допусков) наших пользователей по работе с этим контентом.

Шаг третий. Определение правил (на языке ИТ – «политик»), согласно которым наши пользователи будут работать с классифицированным контентом.

Шаг четвертый. Внедрение системы, которая будет на каждом шаге сверять полномочия пользователей с классификационными признаками обрабатываемой информации и разрешать или запрещать последующее действие.

Давайте рассмотрим все вышесказанное применительно к проектно-конструкторской деятельности. Определимся, что предметом защиты являются чертежи, создаваемые в CAD-приложениях, сопутствующие им текстовые документы, таблицы, рисунки и др., создаваемые в офисных приложениях и все вместе хранимые на каких-либо PDM-порталах.

Любой документ из вышеперечисленных снабжается неотъемлемой «классификационной меткой», которая сопровождает его и все производные документы, созданные на его основе, на всех этапах их «жизненного цикла», и определяет допустимые для него программы обработки, места хранения, способы передачи.

Классификацию информации можно и нужно выполнять в понятных бизнесу категориях, в соответствии с таким уровнем детализации, который обеспечит необходимую гранулярность в полномочиях пользователей. Например, мы можем ввести такие измерения:

• СЕКРЕТНОСТЬ (значения: «несекретно», «ДСП», «коммерческая тайна»)
• ФУНКЦИОНАЛЬНОСТЬ (значения: «конструкторские данные», «дизайнерские данные», «финансовые данные», «маркетинговая информация»).

• ГЛАВНЫЙ КОНСТРУКТОР имеет доступ к «конструкторским данным» любой степени секретности, а к прочим данным только до уровня «ДСП»,
• ЭКОНОМИСТ имеет доступ только к «финансовым данным» с признаком «секретности» – «несекретно» и «для внутреннего использования»,
• СЕКРЕТАРЬ –имеет доступ к документам с любой функциональностью, не относящимся к «коммерческой тайне»,
• РУКОВОДИТЕЛЬ ФИРМЫ имеет доступ к любым данным.

• Конструкторские данные могут храниться только на сервере PLM/PDM-системы и жестких дисках авторизованных компьютеров.
• Обработка КД возможна только с использованием определенных политиками приложений (AutoCAD, Компас, NanoCAD и пр).
• Печать конструкторской документации разрешена только на определенных сетевых принтерах, находящихся в отделе выдачи проектов.
• Разрешено копирование КД и ДД только на учтенные съемные накопители и в определенные сетевые папки.
• Отправка КД по электронной почте разрешена лишь на утвержденный список адресов.
• Сохранение КД в «облачные» хранилища не описано, как разрешенное.

Автоматизация защиты

Реализуется так называемая мандатная модель управления правами. «Владелец данных» определяет ценность данных и основные требования по обеспечению их безопасности, а пользователь лишь оперирует данными в строгом соответствии с правилами (политиками безопасности). Даже при создании информации пользователь не принимает решения о выборе метки, за него это делает система в соответствии предписаниями «владельца данных».

Поэтому метки проставляются следующим образом: первоначальная классификация информации, хранимой на рабочих компьютерах пользователей, выполняется специальным модулем защитной системы, которая сканирует места хранения и по заданным правилам (типу файла, контексту, месту хранения и т.д.) присваивает файлу определенную классификационную метку, с которой он будет жить в дальнейшем. Например, можно определить также правило, что любому новому файлу, создаваемому в Автокаде будет автоматически присваиваться метка «Коммерческая тайна, Конструкторские данные». Все дальнейшие действия с таким файлом будут впредь подчиняться установленным политикам безопасности. Более того, если пользователь сделает копию этого файла, метка «наследуется» и второй экземпляр файла также будет «помечен». Метка неотрывно следует за информационным контентом не только при копировании файла, но и при перемещении контента в буфер обмена, при передаче в другое приложение и т.д. Можно реализовать более сложные процедуры присвоения меток, например, если конструктор получает информацию для дальнейшей работы из PDM-портала, то можно установить правило, по которому такая информация «на лету» будет получать определенную классификационную метку.

Как быть в ситуации, когда по смыслу рабочего процесса необходим вынос контролируемой информации за пределы защищаемого периметра? Например, если нам необходимо показать проект заказчику в его офисе? В таком случае предусматривается помещение информации в «криптоконтейнер», представляющий собой своего рода зашифрованный архив. Открыть такой криптоконтейнер можно только на ноутбуке с установленным драйвером защиты и при наличии канала доступа к серверу корпоративных политик, который и выдает пароль для открытия криптоконтейнера. Таким образом, даже вне офиса на контролируемую информацию будут распространяться корпоративные политики безопасности.

Левак не пройдёт

Заключение

Система защиты должна действительно защищать информацию важную и при этом не блокировать информацию, не представляющую значимой ценности, должна не препятствовать «ложными срабатываниями» выполнению легитимных рабочих процессов и не вносить дополнительных бюрократических процедур для пользователей. Всеми этими характеристиками обладает система управления классифицированной информацией Perimetrix® SafeSpace™. Подробнее о составе ее модулей, порядке внедрения и эксплуатации мы расскажем в следующей статье.