Доверенные среды передачи данных: как внедрить и регламентировать безопасный обмен документами

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

В Сети бытует убеждение, что «о каждом из нас уже все известно, всё есть в утечках», — и это представляет одну из ключевых угроз безопасности данных. Суровый пользовательский фатализм подрывает попытки внедрения культуры защиты информации в крупные организации, где рядовой сотрудник теряет смысл в соблюдении требований Федерального закона №152 «О персональных данных» над моментными бизнес-процессами.

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

Современные практики защищенной передачи документов

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

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

• Передача по зашифрованным каналам связи (протоколы TLS/HTTPS).

Криптографические защищенные сетевые протоколы позволяют передавать информацию по открытым сетям, обеспечивая шифрование end-to-end с проверкой подлинности сервера. Решение может включать шифрование контента с применением криптографических протоколов PGP/GPG со сквозным шифрованием E2EE. Областью внедрения являются сервисы загрузки документов, интеграционные шлюзы и личные кабинеты.

• Автоматизированный обмен документами через SFTP.

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

• Интеграционный обмен документами через защищенные API.

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

• Работа с документами через защищенные сети и VPN (Site—to—Site/Remote Access).

Данный подход предназначен для построения безопасного туннеля между заданными точками, включая как сегменты инфраструктуры организации, так и внешние аутентифицированные источники. Реализация полезна для контроля трафика СЗИ и позволяет авторизованным пользователям и устройствам работать с документами из любой точки мира в любое время непосредственно в корпоративной среде без необходимости передавать документы. Предназначено для передачи документов внутри сети организации или между доверенными сегментами.

• Контроль целостности и подлинности передаваемых документов и ЭДО (хеш-суммы, ЭЦП на базе PKI).

Технологическое решение позволяет обеспечить защиту и контроль от несанкционированного изменения документа в процессе передачи. В простейшем случае выполнение условия становится возможно через внедрение алгоритма вычисления криптографических отпечатков (напр., SHA-256). Но наиболее стабильным решением будет внедрение ЭЦП, которое позволит заверять документы как рядовому сотруднику, так и системам в автоматизированном режиме по API через криптопровайдеров. Внедряется совместно с другими каналами передачи.

• Обмен через корпоративные облачные платформы (напр., NextCloud).

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

• Аудит и мониторинг событий через средства защиты информации (SIEM/DLP/LM).

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

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

Направление	Технологии	Параметр защиты	Сценарии	Риски внедрения
End-to-End	HTTPs/TLS	Конфиденциальность	Обмен между конечными пользователями	Перехват данных при ошибках конфигурации; подмена сервера; утечка через уязвимости веб-сервера
Автоматизированный файловый обмен	SFTP	Идентификация и конфиденциальность	Повторяющийся обмен между системами и пользователями	Компрометация ключей доступа; ошибки изоляции каталогов; ошибки логирования
Интеграции межсистемного взаимодействия	API Security	Программный обмен	Системы с полной автоматизацией	НСД к API; ошибки авторизации; утечка при логировании
ЭДО	HMAC, PKI, hash	Подлинность	Юридически значимый документооборот	Подмена подписей; нарушение целостности
Изолированные сетевые сегменты	VPN	Изоляция сети	Работа с документами в корпоративной среде	Горизонтальное перемещение при компрометации узла (TA0008, MITRE)
Облачные хранилища	Защищенное хранилище	Доступ и контроль	Совместные рабочие процессы	Избыточные права доступа; Утечка при компрометации аккаунта сотрудника
СЗИ	SIEM, LM, DLP	Расследование инцидентов	SOC	Отсутствие доказательной базы (сбои, ошибки, недостатки правового регулирования); квалификация инженеров

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

Реализация регламента в контексте выполнения требований к защищенному документообороту

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

Содержательная составляющая по крупным разделам:

1. Назначение регламента

Целью настоящего регламента является установление единых и понятных правил безопасного обмена документами при внутреннем и внешнем взаимодействии.

→ Почему без регламента нельзя работать дальше?

Зачастую утечка конфиденциальных сведений — это следствие не отсутствия средств защиты, а выбора некорректных каналов передачи данных:

— передача в мессенджерах «быстренько» (или «так удобнее»);

— файлы сохраняются в облачные хранилища, а ссылки свободно «расшариваются» между сотрудниками без настройки прав доступа;

— данные передаются на личные устройства для дальнейшей работы с ними.

Глобальная проблема: пользователям разрешено слишком много, «потому что так удобнее».

Можно «до бесконечности» настраивать средства защиты, но, если не определено, как работать с документами, здравый смысл не выдерживает конкуренции с удобством. У пользователей всегда возникают вопросы: «Куда можно? Кому можно? В каком виде можно? А если срочно?».

→ Где чаще всего происходят нарушения при обмене документами?

Кейсы, которые нарушают правила в большинстве случаев:

— Использование личных устройств для просмотра и редактирования конфиденциальных документов;

— Предоставление безграничного доступа подрядчику/контрагенту к конфиденциальным документам в общем хранилище;

— Отправка конфиденциальных данных через почтовый канал, скачивание файлов из корпоративной почты, сохранение файлов в черновиках отправлений;

— Срочная передача конфиденциального документа или отчёта «прямо сейчас» через мессенджер;

— Отсутствие понимания кто и когда владеет финальной версией документа.

→ Как кейс с подрядчиком может выглядеть без регламентированного обмена?

Подрядчику необходимо направить проектные материалы с пометкой «срочно». Сотрудник выполняет пересылку архива в мессенджере и дублирует ссылкой на облако без заданных прав доступа. Через месяц выяснилось, что как минимум архив был переслан третьей стороне, а ссылка осталась доступна.

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

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

Настоящий регламент распространяется на все процессы передачи документов:

• между сотрудниками организации;
• между автоматизированными системами;
• при взаимодействии с подрядчиками, контрагентами и иными внешними организациями.

Регламент представлен к соблюдению всем участниками обмена документами, предполагая единые правила, независимые от бизнес-приоритетов. Участниками обмена являются:

• сотрудники организации;
• контрагенты/партнеры;
• подрядчики;
• автоматизированные системы и сервисы.

Регламент определяет иерархию документов по уровню доступа, где в зависимости от уровняопределяются ограничения на передачу и редактирование документа.

Иерархическая система классификации документов предполагает следующие уровни:

• общедоступные;
• только для внутреннего пользования;
• конфиденциальные;
• ограниченного доступа (высококритичные).

Уровень доступа определяет следующие параметры:

• условия доступа к файлу (дополнительные согласования);
• допустимые каналы передачи;
• требования к контролю и журналированию.

В отношение средств каналов передачи информации определяются:

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

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

• детальному описанию;
• классификации по целям и задачам обмена данными;
• контролю;
• логированию.

К допустимым средствам передачи/хранения данных относятся:

• корпоративные облачные хранилища;
• SFTP и иные настроенные автоматизированные защищенные каналы;
• корпоративные изолированные сетевые сегменты (с применением VPN);
• защищенные веб-порталы и личные кабинеты;
• встроенные корпоративные мессенджеры (передача данных низкой чувствительности).

→ Как определить полный перечень процессов передачи документов?

Провести полный аудит процессов компании, затрагивающих внутренний и внешний обмен документами. Без определения всех критично значимых процессов регламент утратит значение.

Уточнение от автора: этот пункт определяет содержание Регламента, который должен отражать прямые сценарии документооборота, с которыми необходимо ознакомиться всем конечным пользователям. Все анонсированные здесь элементы должны быть содержательно раскрыты в крупных разделах, не оставляя пространства для манипулирования со стороны пользователей.

3. Модель угроз

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

Активы, подлежащие защите:

1. Конфиденциальные данные (финансовые отчеты, платежные документы);
2. Ключи и учетные данные (пароли, токены);
3. Метаданные (кто, кому, когда совершил отправление).

Потенциальные нарушители:

1. Внутренний сотрудник, совершающий нарушения по неосведомленности;
2. Внутренний злонамеренный сотрудник, намеренно эксплуатирующий уязвимости;
3. Внешний злоумышленник (получает доступ извне через уязвимости в периметре);
4. Партнер/контрагент с доступом в инфраструктуре;
5. Пентестер/Аудитор* для проверки на соответствие требований.

Матрица угроз:

Угроза	Нарушитель	Актив	Вектор атаки
Отправка документа нецелевому пользователю	Внутренний неосведомленный	Документ и его метаданные	Некорректная выдача прав доступа; Отправка на некорректный почтовый адрес или некорректному контакту
Компрометация учетных данных и ключей доступа	Внешний, Внутренний	Учетные данные, Криптоключи	Фишинговая атака; Кейлогеры извне; Хранение паролей в открытом виде; Слабые пароли
Перехват документа неавторизованным пользователем	Внешний	Документ	Атака MitM в публичных и корпоративных сетях; Компрометация промежуточных узлов
Использование личных устройств и сервисов	Внутренний	Документ	Отправка документов на личное устройство для удобства работы через почту/мессенджер; Сохранение документов на внешние облачные хранилища
Выдача чрезмерных прав доступа, не соответствующих уровню конфиденциальности документа	Внутренний	Документ	Использование общих/служебных прав доступа; Отключение механизмов логирования
Нарушение сроков предоставления прав доступа к документам	Внутренний неосведомленный, Партнер	Документ	Несвоевременный отзыв выданных прав; Долгосрочные токены доступа и длинные сессии
Неконтролируемое распространение копий конфиденциальных документов	Внутренний, Партнер	Документ и его копии	Сохранение документа на нелегитимный носитель; Пересылка копии в мессенджер и/или отправка через почтовый клиент; Распечатка и неучтенное хранение
Несанкционированное изменение целостности документа	Внутренний, Внешний, Партнер	Документ	Изменение документа в хранилище с общим доступом; Перехват и модификация документа без ЭЦП
Мисконфигурации и уязвимости сервисов для безопасной работы с документами	Внутренний	Документ, метаданные и логи	Логи операций содержат фрагменты конфиденциальных данных; Некорректное применение разграничения прав доступа; Некорректная настройка резервного копирования
Некорректное логирование документооборота, отсутствие данных о правах доступа	Внутренний неосведомленный	Документ, метаданные и логи	Использование личной почты, мессенджеров, внешних носителей и внешних облачных хранилищ (в зависимости от типа ошибки)

→ Что должна отражать модель угроз? Нужна ли модель нарушителя?

Составленный пункт документа должен отвечать на вопросы: Что защищаем? От кого защищаем? Как могут атаковать? Описанные потенциальные злоумышленники и типы активов, а вместе с тем и матрица может быть расширена. Предложенная сверху матрица может быть дополнена свойствами, в которых заинтересована организация. Допустимо указание используемых контрмер (применение DLP-систем, обязательное использование ЭЦП для высококритичных документов) со ссылкой на раздел или уже используемый документ с контрмерами по информационной безопасности.

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

Кроме того, можно ввести расчетные коэффициенты и рассчитать тягость реализованного риска для организации и для источника угрозы (потенциального нарушителя) и разместить в Приложение к Регламенту.

4. Принципы безопасного обмена

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

4.1. Применение согласованных контролируемых каналов

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

4.2. Предоставление минимальных привилегий

Предоставление доступа осуществляется только к необходимым документам и на необходимый регламентированный срок. Это должны быть документы и каталоги, необходимые для выполнения должностных обязанностей, с автоматическим отзывом доступов по истечении заданного срока. Отдельные доступы предоставляются только с согласования руководства (сотрудником из топ-менеджмента), в зависимости от критичности данных. Избыточные права на редактирование, копирование и экспорт запрещены. За соблюдением минимальных привилегий установлен мониторинг со стороны ИБ.

4.3. Единый стандарт безопасности для всех участников обмена данными

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

5. Правила обмена данными в соответствии с каналами передачи данных

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

5.1. Подробная классификация документов

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

Уровень документа	Условия доступа	Каналы передачи	Примеры документов	Требования к логированию
Общедоступные	• не требует аутентификации для доступа к данным; • доступ для всех участников без ограничений	Публичные веб-порталы; Электронная почта; Социальные сети	Пресс-релизы, публичные годовые отчеты, маркетинговые материалы, общая информация о компании	Минимальный контроль целостности (актуальность версий)
Только для внутреннего пользования	• сотрудникам компании с аутентификацией через учетную запись; • доступ ограничен для подрядчиков и партнеров	Корпоративная почта; Внутренние корпоративные порталы и облачные хранилища; Корпоративные мессенджеры (для ссылок); Защищенные сегменты сети	Внутренние регламенты и инструкции, результаты совещаний, корпоративные новости, отчеты по проектам	Логирование и журналирование фактов доступа к ресурсам; Контроль версий документа и метаданных (автор, версия)
Конфиденциальные	• доступ по предварительному согласованию с владельцем информации; • обязательная 2FA; • минимальные привилегии для работы с документами	Защищенные корпоративные файлообменники с шифрованием; Зашифрованные каналы связи; Защищенная корпоративная почта; Иные каналы запрещены	Персональные данные сотрудников и клиентов, финансовые отчеты и планы, договоры и коммерческие предложения, архитектурные решения и планы развития инфраструктуры	Сквозное журналирование всех операций (просмотр, скачивание, изменения, печать); Алерт на подозрительные действия (массовое скачивание, доступ во внерабочее время); Пересмотр прав доступа
Строго конфиденциальные	• доступ по предварительному согласованию (white-list) руководящих должностей; • многофакторная аутентификация с аппаратным токеном; • подписанное NDA; • персональная ответственность за копии	Системы защищенного документооборота со сквозным шифрованием; Передача на зашифрованных носителях; Иные каналы запрещены	Данные, составляющие государственную, коммерческую или банковскую тайну, патенты и ноу-хау, документы по слияниям и поглощениям, результаты внутренних расследований и материалы судебных разбирательств	Полное и не редактируемое журналирование с привязкой к пользователю; Запрет на печать и экспорт без водяных знаков; Аудит логов и анализ поведения пользователей для настройки правил DLP

→ Как проводится корректировка таблицы под потребности бизнеса?

Первостепенное категорирование документов — основа основ при написании Регламента. Стоит согласовать единый подход и распространить его на все сферы бизнеса (или позаимствовать уже существующее). Нередко встречается расходящееся представление о категории и ценности документа в разных департаментах бизнеса. Кроме того, стоит реализовать минимальные аспекты защиты, перед внедрением Регламента. Безопасные каналы должны быть описаны (п. 5.2) и внедрены в организации. У сотрудников должны быть заявленные доступы в системы. Системы предоставления прав доступа (IDM) должны исправно функционировать, а процесс выдачи прав доступа «стоять на потоке». Превентивная защита требует высокой экспертизы со стороны специалистов. Представленная таблица может «позволить договориться» ИБ, ИТ и бизнес-структурам.

5.2. Описание каналов передачи данных

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

Канал передачи (описание)	Задачи для обмена	Уровень документа	Требования к контролю	Требования к логированию
Публичные каналы (почта, сайт, соцсети)	• информирование партнеров, клиентов, сотрудников; • маркетинг; • обратная связь от пользователей	Общедоступные данные	Защита от атак внешними злоумышленниками; Контроль публикуемого контента от имени организации	Мониторинг доступности сервиса
Корпоративные порталы общего назначения (сетевые папки, внутренняя почта, порталы, вн. мессенджеры)	• оперативное взаимодействие между сотрудниками; • обсуждение проектов, задач; • распространение документов внутреннего назначения	Для внутреннего пользования; Некритичные конфиденциальные — только ссылки	Аутентификация через SSO; Сегментация по подразделениям; Сканирование документов DLP-краулерами	Логирование входа/выхода, факта отправки/получения сообщения, количество скачиваний и попыток доступа к файлам
Защищенные каналы для передачи конфиденциальных данных (шифрованная почта, защищенные файлообменники, VPN)	• передача документов с персональными данными; • удаленная работа с корп. ресурсами	Конфиденциальные документы	MFA для доступа к каналу; Поддержка сквозного или транспортного шифрования; Превентивная блокировка незашифрованных вложений	Расширенное журналирование: действия с файлами (просмотр, скачивание, печать), сбор IP-адресов, устройств, времени сессии, объема переданных данных с прокси
Спец. каналы для информации ограниченного доступа (SFTP, EE2E, изолированные сегменты)	• передача строго конф. документов; • обмен в рамках NDA или с госорганами; • передача активов (код, патенты)	Строго конфиденциальные документы	Аутентификация по аппаратным токенам или сертификатам; Проверка целостности и подлинности документа до передачи (ЭДО)	Неизменяемое логирование с детализацией действий с документом; Мониторинг аномальной активности
Каналы автоматизированного обмена (B2B, API)	• интеграция с партнерами, банками, регуляторами; • синхронизация между высококритичными системами; • автоматическая выгрузка/загрузка больших данных	Конфиденциальные и строго конфиденциальные документы	Аутентификация на уровне системы через токены и сертификаты; Разграничение прав «только запись», «только чтение»; Регулярная ротация ключей и проверка их принадлежности	Логирование всех сессий и транзакций (файл, источник/получатель, статус отправки, хеш-сумма) и мониторинг аномальной активности (время, объем, частота)

→ Какие есть правила для работы с таблицей?

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

5.3. Правила обмена по основным каналам связи

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

Канал передачи данных	Разрешено	Запрещено
Электронная почта	— передавать общедоступные и внутренние не конфиденциальные документы; — использовать шифрование и доп. меры защиты	— использовать личную почту; — отправлять конфиденциальную информацию без предварительного шифрования
Мессенджеры	— использовать корпоративные мессенджеры для общения, координации и установления договоренностей; — передавать ссылки на защищенные хранилища данных и SFTP-сервера	— передавать конфиденциальные и высококритичные документы; — использовать личные мессенджеры
Облачные хранилища	— использовать корпоративные мессенджеры для общения, координации и установления договоренностей; — передавать ссылки на защищенные хранилища данных и SFTP-сервера	— передавать конфиденциальные и высококритичные документы; — использовать личные мессенджеры
SFTP и автоматизированные средства обмена	— использовать аутентификацию по ключу и входить с MFA (или сквозную доменную); — применять контрольные меры и журналирование; — полная изоляция каталогов по правам доступа	— использовать слабую парольную защиту; — предоставлять общий доступ к каталогам и файлам; — отсутствие политик ротации и хранение файлов без контроля целостности
VPN и изолированные сегменты	— использовать VPN для передачи конфиденциальных документов; — осуществлять мониторинг трафика средствами ИБ в частности	— считать сеть по умолчанию «доверенной»

Требования сформулированы на основе анализа угроз и реализуемых средств коммуникации и передачи документов в организации.

→ Как сделать правила «рабочими», а не формальными?

Категорически запретить использование личных и неконтролируемых сервисов в организации для служебной коммуникации с документами. Это формирует неконтролируемый канал утечки. Для технической реализации комплекса мер требуется настройка DLP-систем с превентивным контролем, внедрение корпоративных чатов для общения (не создавать для сотрудников неудобств в коммуникации), применять VPN для удаленного доступа к корпоративной информации. Здесь же актуален регулярный аудит соблюдения требований.

5.4. Пользовательский чек-лист для самопроверки

Основной инструкцией перед передачей документа может послужить следующий опросник:

1. Отправка документа осуществляется целевому пользователю в соответствии с поставленной задачей;
2. Выбранный канал передачи данных соответствует уровню документа;
3. Доступ к файлу ограничен и контролируем;
4. Передается требуемся версия документа, со всеми учтенными положениями;
5. Существует возможность отозвать доступ.

Внедрение практики осознанной работы с цифровыми данными формирует не только культуру защиты данных, но и культуру осознанности — все это позволит противодействовать в том числе и социальной инженерии. Выполнение указанных пунктов позволит обеспечить контекстную безопасность документов и снизит утечки по небрежности, научит пользователей следовать пунктам регламента, воплотит концепцию минимальных привилегий и снизит общее число инцидентов ИБ.

→ Как проинформировать пользователя о важности проведения такой самопроверки?

Чек-лист может стать компонентом интерфейса почтовых клиентов, порталов загрузки, облачных хранилищ и SFTP: краткие напоминания и галочки подтверждения помогут пользователям сориентироваться.

6. Роли и ответственность

В Регламенте производится разграничение зон ответственности между участниками процесса в контексте процессов организации. Вводятся следующие роли с назначенной ответственностью:

• Отправитель. Является инициатором отправления и несет ответственность за факт передачи документа в соответствии с требованиями. Производит Классификацию документа (п. 5.1), Выбор канала передачи данных (п. 5.2) и проверяет Контроль прав доступа.
• Получатель. Обеспечивает сохранность сведений и не распространение информации третьим лицам. Выполняет работу над документом в рамках поставленной задачи. Несет ответственность за утечку информации наравне с Отправителем.
• Специалисты ИТ/ИБ-подразделений. Отвечают за формирование технологичной защищенной среды обмена документами. Обеспечивают построение защищенных каналов передачи данных (развертывание, поддержка и мониторинг работы), внедряют контролирующие механизмы (DLP, шифрование, IDM/IAM, применение политик), проводят непрерывный аудит и мониторинг (проверка логов, анализ и расследование инцидентов).
• Руководство (топ-менеджмент и линейные руководители). Соблюдение регламентов без исключений (без должностных привилегий), поддержка и снабжение ресурсами потребностей ИТ/ИБ-подразделений, публичное формирование культуры безопасности (одобрение политик и практик защиты данных).

→ Как продемонстрировать руководству значимость этих практик?

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

7. Действия при инциденте при передаче конфиденциальных данных

В Регламенте описывается пользовательское поведение при фиксации утечки данных.

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

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

Дальнейшее рассмотрение инцидента берет на себя корпоративная структура по информационной безопасности.

Заключение

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

Автор: инженер-аналитик лаборатории исследований кибербезопасности компании «Газинформсервис» Ирина Дмитриева.