Корпоративная безопасность

Корпоративная безопасность

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

1. Обеспечение передачи необходимого объёма информации

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

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

В одной компании, где я работал, стояло ограничение всего в 10 МБ. И таких компаний достаточно. То есть передача больших файлов обеспечивается далеко не всегда.

2. Квотирование

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

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

3. Ограничение срока жизни и доступности файла

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

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

4. Ограничивать передачу файлов по типу

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

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

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

5. Чёткое определение участников обмена

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

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

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

6. Полный аудит событий передачи данных

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

Кроме этого должны фиксироваться все операции, выполняемые администраторами по настройке системы, события входов/выходов. Традиционно в каждом событии должно фиксироваться время, субъекты, объекты и действия.

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

7. Антивирусная проверка

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

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

8. Использование защищённых протоколов передачи данных

Корпоративная информация требует защиты. Использование защищённых протоколов передачи по умолчанию – минимальный необходимый уровень защиты информации при передаче. Это также обеспечивает защиту передаваемых аутентификационных данных (логин/пароль).

Для защиты передачи могут быть использованы протоколы SSL/TLS, но и их следует правильно настраивать.

9. Шифрование файлов, содержащих конфиденциальную информацию при передаче

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

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

10. Ограничивать доступ к файлам обслуживающего персонала

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

11. Проверять содержимое файлов системами контроля утечек данных

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

12. Не передавать файлы, безопасность которых нельзя проверить

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

13. Не использовать публичные облака, а тем более файловые обменники

Зачастую пользователи за неимением корпоративной альтернативы используют сервисы типа DropBox, Яндекс.Диск или в худшем случае обменники в Интернете.

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

14. Использовать отечественные решения

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

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