Изначально я хотел назвать эту статью «IT-проекты и промышленный шпионаж», но это оказалось слишком провокационно. Пять лет назад я общался с одним иностранным приятелем, и мы обсуждали, кто же лучший промышленный шпион, кто имеет доступ к максимальному количеству данных. Сошлись на том, что это айтишники: у айтишника на любом IT-проекте, на любом внедрении появляется доступ практически ко всей конфиденциальной информации, которая есть на предприятии.
Довольно часто люди, получившие этот доступ, не осознают, что видят перед собой. У кого-то из вас на диске или ноутбуке хранится папка-сборник документов со всех проектов? У меня такая папка занимает полтора терабайта – со всех проектов я собирал максимум того, до чего мог дотянуться: технические задания на разные блоки, зарплатные ведомости, материалы по управлению производством и прочее, что присылали друзья или коллеги – вдруг пригодится.
Работая в консалтинговых компаниях, которые выполняли работы как подрядчики, я видел практику, когда приходя в компанию, люди сваливают на общий диск весь свой опыт: «Покажи, с чем работал, а теперь отдай нам, вдруг мы поучимся». Когда начинается любой IT-проект, обязательно встает задача защиты получаемой информации.
Типы конфиденциальной информации на предприятиях
Понятно, что запуская Бухгалтерию, мы получаем доступ ко всей бухгалтерской информации. Но не только: любая система управления платежами или аналитики часто содержит чувствительные данные – с точки зрения восприятия компании и ее руководства. Очень часто, вспоминая свой прошлый опыт, я видел, как и руководители, и сотрудники на проектах относятся к подобной информации халатно. Ненормально, когда человек копирует весь диск со всей проектной информацией.
Существуют законы, которые определяют перечень защищаемой информации. Все помнят про 152-ФЗ, но он не единственный, и эти законодательные нормы в некоторых случаях действительно работают. На практике же большинство коммерческих и частных компаний относят к защищаемой и конфиденциальной информации совсем не то, что указано в законах.
Персональные данные – понятная категория: адреса, телефоны сотрудников, базы клиентов.
Вторая важная группа – бизнес-процессы, регламенты, методики, положения, которые помогают компании конкурировать на рынке и являются ее особенностями. Естественно, неприятно, если конкурент узнает, как устроена твоя работа.
Экономические и технические показатели компании – тоже, очевидно, чувствительная информация. Многие руководители считают конфиденциальной бухгалтерскую отчетность, хотя баланс любой компании можно найти в открытом доступе, и это не такая уж секретная информация. В отдельных отраслях, например в нефтегазовой, к защищаемой информации относят технические показатели: масштаб компании, рынок, на котором она работает, количество сотрудников и другие параметры.
Например, в одной из компаний, где я работал, сотрудникам было запрещено говорить, сколько у нас было буровых бригад. Компания занималась бурением, и количество буровых бригад считалось секретной информацией, разглашать которую было запрещено. Даже когда сидишь с друзьями в баре, нельзя было ответить на вопрос, сколько бригад сейчас работает.
Далее идут технологические данные и данные о средствах производства. В сегодняшних условиях многие производственные компании стараются защитить свои технологии, потому что эксплуатация разностороннего оборудования и знание того, как правильно его использовать, – это важная информация, которая может давать серьезный коммерческий эффект. Это чем-то похоже на бизнес-процессы, но находится уровнем ниже – на техническом уровне.
Коммерческие данные также относятся к защищаемой информации: сведения о поставщиках, подрядчиках, качестве и ценах.
Формальные инструменты защиты и их ограничения
С точки зрения формальных инструментов защиты существует действующее законодательство, которое работает ограниченно. Тему государственной тайны рассматривать не буду, потому что там действуют отдельные процедуры. Есть федеральные законы, гражданский кодекс, подзаконные акты и приказы, определяющие порядок обращения с информацией. Под информацией я имею в виду не только базы данных, но и оперативные записи, протоколы интервью и другие материалы, которые попадают в проектную команду.
С чего начинается общение с клиентом? С предложения заключить соглашение о конфиденциальности (NDA). При этом половина компаний не имеет своих форм NDA, а вторая половина просто подписывает предложенные варианты. В лучшем случае туда вписывают штраф в размере, например, 10 миллионов рублей за раскрытие информации, без понимания, как это будет доказываться. На практике соглашения о конфиденциальности не работают, потому что законодательство не дает инструментов для доказательства того, что конкретный человек намеренно раскрыл информацию.
Еще менее эффективно работают пункты о конфиденциальности в договорах. Компании указывают, что обмениваются конфиденциальной информацией и раскрывать ее нельзя, но на деле это мало что значит.
Самый бесполезный способ защиты – подписи в электронных письмах. Многие видели такие фразы внизу письма, как: «Данное сообщение содержит конфиденциальную информацию». Эти подписи автоматически добавляются даже к коротким сообщениям вроде «Окей, документ получил» или «Спасибо, принято». На такие формулировки никто не обращает внимания.
Каналы передачи информации и степень их защищенности
Существует ряд каналов передачи информации между участниками IT-проекта, которые различаются по степени защищенности.
Самый контролируемый – официальная переписка. Это то, что можно проверить и отследить: кто с чем работал, какие документы направлял и получал. К ней относятся бумажные письма, входящая корреспонденция, официальные электронные ящики. Все входящие сообщения должны регистрироваться, поэтому, при необходимости, их можно проверить.
Следующий уровень – бумажные и электронные носители. Часто передаются флешки с базами данных, реже – диски с базами или документами, содержащими защищенную информацию. Такие носители можно учесть, зафиксировать, протоколировать и наладить контроль за их передачей и доступом.
Электронная почта и интернет. Очень часто для обмена данными используются ссылки на облачные хранилища: например, при внедрении проекта айтишники пересылают друг другу подготовленные базы через Яндекс.Диск или аналогичные сервисы.
В последнее время все чаще проектные документы пересылаются через мессенджеры. Запретить и контролировать такую передачу крайне сложно. С учетом того, что один известный мессенджер увеличил объем пересылаемых файлов до нескольких гигабайт, все чаще встречаются случаи, когда администратор подрядной или компании-заказчика пересылает через сообщение бухгалтерскую или финансовую базу данных. Контролировать такие действия почти невозможно.
И последний по степени контроля тип – неформальные каналы.
По своему опыту могу сказать следующее: самую интересную, самую конфиденциальную и самую защищаемую «информацию» я получал в курилке. Коллега приглашал пойти покурить и рассказывал все, что не говорил в формальной обстановке. Но таким образом полученная «информация», де-факто, не является конфиденциальной информацией, а относится к категории слухов и сказок.
У этого «канала» есть забавный способ пресечения, который я наблюдал. Когда коллега зовет: «Пойдем покурим», рядом оказывается некурящий РП, который говорит, что просто постоит и «подышит воздухом». Он стоит молча и слушает. Мы выкуриваем сигарету, смотрим на него, выкуриваем вторую – коллеге явно есть что рассказать, но он молчит. После этого становится понятно, что поговорим мы в следующий раз и лучше обойтись без РП.
Риски утечки информации
Обмен информацией идет, базы данных наполнены информацией, документы и записи «летают», проект движется – все хорошо. Но какие риски это несет?
Первый риск – человек, получивший базу данных, список контрагентов или проектную оперативную информацию, может не осознавать ее ценности. Например, программист уровня middle не знает, какую ценность представляют технологические карты производства пищевой продукции. А вот человек, знакомый с отраслью, увидит в этом сокровище.
У меня есть база клиентов из пищевой промышленности, где содержится более тысячи рецептов разных блюд: технологии, сырье, поставщики, описание процессов, вся документация. При желании можно открыть собственную компанию, использовать эти рецепты и организовать новый бизнес. Все уже технологизировано, система выстроена, готовят вкусно – я пробовал эти рецепты дома – а значит, покупать будут.
Если показать такую базу обычному программисту, он не поймет, что это и зачем. Это и есть главная опасность: человек не осознает, что попало к нему в руки, и может случайно выгрузить или передать данные дальше.
Второй риск – передача информации по незащищенным каналам. Используя неконтролируемые каналы, мы не знаем, кто получил доступ к данным и куда они могут попасть.
И самый большой риск заключается в том, что обладая информацией во взаимоотношениях «Заказчик – Исполнитель» или «Работодатель – Работник», человек может использовать ее как инструмент давления. Речь идет не о контрагенте или юридическом лице, а именно об исполнителе. При возникновении конфликта информация и риск ее утечки нередко превращаются в средство шантажа. Такое случалось не раз, в том числе и в моей практике.
Меры защиты информации на IT-проектах
Во-первых, нужно четко определить состав информации, которая подлежит защите. При запуске проекта важно составить перечень данных, которые относятся к конфиденциальным, и довести его до всех участников – и заказчика, и исполнителя. Это значительно снижает вероятность того, что информация попадет в ненужные руки. Нельзя допускать ситуации, когда к защищаемой относят ВСЮ информацию. Если все, с чем вы работаете, будет объявлено защищаемой информацией, вы не сможете ни работать, ни обеспечивать процедуры защиты и ограничения доступа. Это же правило действует и при подписании любых форм соглашений о защите информации.
Во-вторых, необходимо прописать процедуры работы с этой информацией. Если сотрудники не понимают, как можно и как нельзя передавать данные, они будут искать собственные способы, часто небезопасные.
В-третьих, крайне важно обеспечить удобные каналы передачи информации. Именно удобные – потому что если пользоваться системой неудобно, люди всегда найдут обходной путь. Даже на самых защищенных проектах при неудобстве появляются неформальные способы передачи данных «от точки А до точки Б». Отдельно хочется отметить частые попытки различных компаний определить канал передачи «в устной форме»: это недопустимо. В устной форме конфиденциальная информация перестает быть таковой и становится фольклором.
Четвертый пункт – организация рабочих мест, хранилищ информации и контроль доступа к ним. Репозиторий проектных документов – хороший инструмент: он позволяет хранить все в одном месте, управлять доступом и исключать ситуации, когда кто-то открывает общий доступ к файлам на Google-диске без контроля.
Со стороны исполнителя необходимо проводить инструктаж технических специалистов. Это обязательная мера, которая помогает предотвратить ошибки и случайные утечки.
Обязательно нужно знакомить сотрудников с последствиями нарушений. Чем яснее и жестче обозначены последствия, тем меньше вероятность, что исполнители будут халатно относиться к базам данных, протоколам и документам.
На исполнителях лежит ответственность за использование контролируемых средств передачи информации.
Приведу пример. У меня есть личный почтовый ящик на Google, и примерно половина писем в нем – это проектные документы со старых проектов: ссылки на базы данных, сами базы, отчеты, протоколы. Все это хранится во внешнем хранилище уже около 15 лет. Это ненормально.
Если вы работаете на проекте, даже при участии нескольких подрядчиков, создайте для всех отдельную корпоративную электронную почту – хотя бы будет видно, кто с кем общается и какие данные передает.
Серверная инфраструктура – та же история. При запуске IT-проекта, когда разворачиваются тестовые, рабочие и исполнительские контуры, сервера должны быть под контролем, даже если они арендные.
Системы внутреннего взаимодействия, репозитории, задачники и другие инструменты тоже обязательно должны быть.
И самое главное – предотвращение конфликтных ситуаций. Это ключевая задача при управлении отношениями заказчика и исполнителя на любом проекте. Не допускайте конфликтов. Конфликты всегда приводят к риску.
Все процедуры работы с информацией необходимо зафиксировать в Уставе проекта. Этот документ предназначен, в том числе, для описания таких процедур.
Архивация информации по завершении проекта
В конце проекта об этом часто забывают, но информацию необходимо архивировать. После завершения работ, подписания всех документов, получения результатов и передачи проекта в сопровождение данные должны быть переведены в архив.
Архивация – это отдельная процедура со своими правилами доступа. Процесс архивации и последующего удаления информации должен завершать любой IT-проект. Иначе останутся флешки, записи, блокноты с оперативными заметками, именами, телефонами и другой конфиденциальной информацией.
Организуя управление проектами и работу с информацией, стоит ввести простое правило: выдать всем членам проектной команды рабочие блокноты, а через год их собрать. Это простая мера, но она позволит избежать ситуаций, когда блокнот со списком фамилий случайно оказывается рядом с мусоркой.
Чего нельзя делать при защите информации
Нельзя нарушать установленные процедуры. Если решено, что пользоваться Telegram нельзя, значит нельзя никому, включая руководителя и директора проекта. Как только один человек нарушит правило, это станет нормой для всех.
Нельзя допускать внезапных конфликтов. Контроль конфликтов и предотвращение резких разрывов отношений – обязательная часть безопасности. Нельзя доходить до ситуации, когда во время спора между двумя юридическими лицами подрядчик угрожает заказчику: «Не примешь работы – опубликую твою базу в открытом доступе и передам данные в налоговую, ведь я за полтора года работы узнал все о твоих финансовых махинациях». Конфликты должны решаться заранее, а не перерастать в шантаж.
Конфликт может возникнуть не только между компаниями, но и с сотрудником. Поссорившись с программистом, можно получить ответ в виде утечки.
Нельзя скрывать утечки информации. Если взлом произошел, если кто-то получил доступ к серверу, не стоит надеяться, что «прокатит» и никто об этом не узнает. Замалчивание увеличивает риски.
Если информация попала в чужие руки, нужно сразу признать факт утечки и нести ответственность в соответствии со всеми договоренностями.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
