Что вообще такое мандатный доступ, и зачем он нужен
Мандатный доступ – это механизм, позволяющий ограничить доступ к файлам, содержащим секретную информацию. Это может быть что угодно: коммерческая тайна, документы для служебного пользования или даже просто фотографии с корпоратива.
Основной принцип работы данного механизма достаточно прост – пользователь может каким-либо образом взаимодействовать с файлом только в том случае, если он имеет доступ к тем меткам безопасности, которые присутствуют на данном файле.
Это особенно актуально в случаях массовых рассылок файлов для сотрудников компании или (что ещё критичнее) – для внешних пользователей. Пользователь просто выделяет каталог и без задней мысли нажимает на кнопку “Поделиться”, а информация попадает к пользователям, которые не должны иметь к ней доступ.
В случае использования механизмов мандатного доступа, подобная ситуация в принципе невозможна – система (в зависимости от реализации) просто не даст возможности предоставить доступ к файлам пользователям, не имеющим нужных меток безопасности.
В чём отличия дискреционного метода предоставления доступа от мандатного
В описаниях систем хранения файлов вы могли встречаться с таким термином, как «дискреционный метод предоставления доступа». Что же это такое, и зачем вам нужен мандатный метод, когда в вашей системе уже есть дискреционный? Могут ли они взаимозаменять друг друга и быть исключительно мандатным или дискреционным?
На самом деле – всё очень просто. Это два независимых метода, регулирующих механизмы предоставления доступа. Мандатный метод определяет – может ли пользователь в принципе получить доступ к файлу, а дискреционный – набор действий, которые получатель сможет выполнять над файлом.
Таким образом, два этих метода прекрасно работают в тандеме, дополняя друг друга. При этом система вполне может использовать только дискреционный метод доступа в случае, если ваша работа не предполагает высокой секретности при выполнении предоставления доступа к файлам или не содержит документов, являющихся секретными.
Зачем нужны метки безопасности, если есть политики
У продвинутых пользователей может возникнуть закономерный вопрос: “А зачем нужна мандатная модель доступа, если моя система уже имеет настроенные политики безопасности?”
Это достаточно логичный и правильный вопрос. По сути, политики безопасности, предназначенные для верификации действий по предоставлению доступа к файлам, выполняют ту же самую функцию – позволяют не дать получателям, не имеющим прав на просмотр секретных документов, их получить.
Однако, между мандатным методом предоставления доступа и политиками есть несколько существенных отличий, а именно:
- Превентивность работы – механизмы мандатного доступа работают превентивно, не позволяют (тем или иным образом) случиться самому событию предоставления доступа к файлу;
- Универсальность – политики могут быть автоматическими (например, проверка файла через DLP-систему), однако они в любом случае могут ориентироваться в основном на определённые триггеры в контенте файла. Метки могут быть назначены на файлы с любым содержимым и запрещать работу с ними, если у пользователей нет соответствующих меток.
- Отсутствие ошибок – как уже было выше сказано, политики проверок опираются в основном на контентный анализ файла и не всегда могут быть настроены корректно. Однако, если файл имеет метку безопасности, само событие предоставления доступа просто не произойдёт.
- Гибкость управления – обычно политики безопасности назначаются на глобальные сущности, такие как группы пользователей. Метки безопасности позволяют перевести работу на более низкий уровень и регулировать возможность предоставления доступа на уровне отдельных пользователей.
В целом, для достижения максимального уровня безопасности рекомендуется комбинировать все вышеописанные подходы (и политики, и мандатную модель доступа) – это позволит создать систему, компоненты которой будут страховать друг друга от возможных ошибок.
Кто управляет метками безопасности
В рамках системы мандатного доступа есть несколько уровней управления метками:
- Сотрудник ИБ управляет списком имеющихся в системе меток безопасности;
- Сотрудник ИБ назначает метки безопасности на пользователей и группы пользователей;
- Сотрудник ИБ верифицирует запросы пользователей по изменению меток безопасности на файлах;
- Пользователь создаёт запросы на изменение меток безопасности файла.
- Система назначает метки безопасности на файлы по настроенным правилам классификации.
Как можно понять из списка выше, основным сотрудником, управляющим метками, является представитель службы безопасности (или иной администратор). Именно он формирует список меток системы, назначает их на сущности разного уровня, и именно он верифицирует запросы от пользователей.
Пользователь в этой системе имеет минимальный набор прав. Он может подсветить необходимость назначения меток на конкретный файл для сотрудника ИБ, однако прав на самостоятельное изменение списка меток у пользователя нет.
Дополнительно, стоит подсветить такой механизм, как классификация файлов, который был упомянут в списке выше. Он позволяет автоматически назначать метки безопасности на файлы в моменте их попадания в систему. Подробнее о данном механизме будет описано в отдельной статье.
Как в Secret Cloud DRM реализован мандатный доступ
В рамках нашего решения Secret Cloud DRM мы реализовали мандатную модель доступа следующим образом. Само управление метками осуществляется в прямом соответствии с правилами управления, описанными выше.
Механизмы запрета на предоставление доступа пользователям, не имеющим необходимых меток, мы реализовали в виде двухуровневой модели:
В случае, если пользователь пытается предоставить доступ к одному или нескольким файлам, мы прямо подсвечиваем ему пользователей, которым он не может предоставить доступ, и не даём возможности выбрать их для предоставления доступа.
В случае, если пользователь пытается предоставить доступ к каталогу, мы пришли к иной реализации, поскольку динамическое отслеживание всех вложенных меток на дочерних файлах каталога потребовало бы существенных затрат вычислительных ресурсов. Кроме того, это было бы банально неудобно для пользователей – в случае наличия подобного файла в каталоге, пользователю приходилось бы его искать, убирать из каталога, и только после этого предоставлять доступ к остальным файлам.
Мы нашли более дружелюбный к пользователю подход – он может предоставить доступ к любому из каталогов, однако файлы, на которые назначены метки безопасности, не совпадающие с метками получателя, не будут отображены у последнего.
На что влияют метки безопасности помимо мандатного доступа
Помимо ограничений на предоставление доступа в рамках Secret Cloud DRM, метки безопасности применяются во многих механизмах в роли триггера для срабатывания того или иного действия.
Например, механизм контейнеризации (тоже входит в состав SC DRM и будет описан в отдельной статье) позволяет настраивать правила, благодаря которым в контейнеры можно помещать только файлы, на которые назначаются метки безопасности.
Ещё мы используем метки безопасности при создании правил передачи файлов между предприятиями (о них также будет отдельная статья), ограничивая возможность передачи документов между различными предприятиями, использующими один и тот же Secret Cloud.
Кроме того, мы создали отдельные наборы проверок в рамках политик, которые позволяют создавать дополнительные сложные правила верификации действий по белому или чёрному списку меток, что позволяет запрещать передачу файлов даже в том случае, если получатель имеет все необходимые метки безопасности.
Автор статьи: Захар Максименко, руководитель отдела аналитики компании Secret Technologies.
Хотите узнать больше о возможностях Secret Cloud DRM для вашей компании? Свяжитесь с нами для получения консультации или закажите демонстрацию на нашем сайте.