Как-то раз мы решили устроить самопроверку и провели аудит файловых хранилищ. О первой части этого эксперимента мы уже вам рассказывали, тогда речь шла о проверке дисциплины и базовых правил ведения документооборота. Сегодня расскажем о безопасности. Наш основной инструмент для аудита – собственная DCAP-система FileAuditor, а одна из ее основных задач – контентное разграничение доступов к чувствительной информации. Исходили из того, что утечка не произойдет, если ничего не будет «плохо лежать» и попадаться на глаза, кому не надо. Собственно, цель была проверить, как распределены права пользователей и устранить ошибки, если найдем.
Итак, в эфире Алексей Дрозд (aka@labyrinth), начИБ «СёрчИнформ» – продолжаем рассказ.
Напомним, как в нашем эксперименте все было устроено. В постановке задач опирались на реальные рабочие процессы, грубо говоря, мы проверяли, чтобы доступ к данным о продажах не попадал к разработчикам, а код не был доступен сейлам. Если коротко, делали это в три шага:
Аудит доступов
Управление правами пользователей
Мониторинг нарушений
В зоне проверки были около 170 сотрудников из нескольких подразделений, в основном смотрели, что им доступно в общих сетевых папках. В компании у каждого отдела есть свое сетевое хранилище, плюс директории для обмена тяжелыми файлами между отделами. Внутри «собственных» папок отдела тоже есть иерархия – например, вложенные папки руководителей должны быть под замком, «сырые» проекты доступны только исполнителям, чтобы их коллеги получили только итоговый результат и не запутались в версиях, и так далее.
«Танцевали» от данных: искали, кому в принципе доступны те или иные директории и документы, и исключали лишних. Вот, как это было.
1. Аудит прав доступа
Тут все просто: нужно было сверить с эталонной матрицей доступов, как по факту распределены права пользователей.
За такую проверку в FileAuditor отвечает группа отчетов, в том числе для аудита наследования прав и классический журнал прав доступа. Классическим журналом я воспользовался для анализа сетевого хранилища. Смотрел, нет ли лишних пользователей в группах доступа. Сам отчет позволяет просмотреть сразу все директории со списком пользователей и групп, которым они доступны. Но при такой масштабной выдаче заметить единичные отклонения сложно, так что на помощь пришли мини-версии отчета. Его видно в режиме «Просмотр файла» при выборе конкретной директории в общей консоли.
В этом режиме FileAuditor показывает права доступа, вычитывая их из ресурсов файловой системы. Сразу видно, кому и какие операции с файлом / папкой доступны. Удобно, что и перенастроить права можно в один клик в рабочей консоли, никуда не переходя. Это быстрее, чем вручную разбираться с настройками в ОС.
Критичных нарушений не нашлось, наши сисадмины, как правило, исправно модерируют группы пользователей и распределяют права по матрице.
И все же каждое правило имеет исключения. Всплыла явная проблема – в общих сетевых папках по отделам. В идеальном мире доступ к ним должны иметь только сотрудники этих отделов, системные администраторы и я – как начальник службы ИБ. Но на деле пользовательские группы по отделам в AD иногда включали больше пользователей, чем фактическое число сотрудников этих отделов. Например, в одном из отделов 14 человек, а в группе, которой открыт доступ к сетевой папке – 20. Оказалось, что дело в учетках бывших сотрудников – на деле они заблокированы и не несут угрозы. Но из группы доступа их забыли удалить.
Что сделали: поговорил с админами, мой перфекционизм поддержали и навели порядок в Active Directory.
Для закрепления результата заглянули в отчет «Аудит наследования прав». Он помогает разобраться с доступами пользователей, если в хранилищах появляются объекты и файловая система автоматически «расшаривает» на них права. С этим отчетом, например, можно контролировать, как распределены права пользователей на подпапки и файлы внутри крупных директорий. Если к каким-то объектам заданы права, не соответствующие правилам доступа к родительским папкам, то FileAuditor выдает предупреждение. Еще наглядно видно, если для какого-то ресурса даны избыточные права.
Вот, как выглядит отчет. Ошибки в наследовании нашлись, но разобрались быстро и не нашли больше критичных причин.
2. Управление разрешениями
Понятно, что и до аудита в компании все работало, то есть права к файлам были настроены, с нуля задачу решать не пришлось. Я хотел точечно проверить доступы к критичным объектам и усилить их защиту.
Покажу на конкретном примере. Изначально это была задача из первой части: мы искали определенный контент, чтобы он не лежал, где попало. Одним из искомых объектов были анкеты перед тестированием софта у заказчиков. Они содержат чувствительные данные о клиенте: конфигурацию инфраструктуры, данные о сотрудниках и так далее. Если они попадают в руки пользователей, не связанных с проведением триалов, – это нарушение договоренностей с заказчиком. Так что регламент требует, чтобы они хранились только у менеджеров и сотрудников техподдержки, которые и ведут «пилот».
Решили проверить. Искать нужно было по всем сотрудникам, не связанным с продажами, и в общих сетевых папках. Правило в FileAuditor я построил по поиску похожих, загрузив шаблон анкеты, плюс по формату документа. Нарушений не нашлось. Но все равно нужно было перестраховаться.
Что сделали: у нас уже было настроено правило, которое запрещает доступ к папке с шаблонами анкет непрофильным сотрудникам. Эти настройки задаются на уровне распределения прав в AD, только сделать это можно прямо в FileAuditor. Как раз об этом рассказывал выше: просто кликаешь по папке правой кнопкой мыши, и, как в режиме администрирования в ОС, переназначаешь права.
Кстати, если бы все же пришлось настраивать разрешения с нуля — скажем, создавай мы эту папку заново, — помог бы отчет «Владельцы ресурсов». Он помогает контролировать создание новых объектов в файловой системе и распределять права доступа к ним. Вот, как он выглядит.
Дополнительно я настроил блокировку передачи файлов из категории «Анкеты» по всем каналам кому-либо, кроме групп сотрудников с доступом: менеджеров и инженеров техподдержки.
Блокировки в FileAuditor работают на уровне процессов, которым разрешается или запрещается вычитывать документы из файловой системы при заданных условиях.
«Под капотом» процесс блокировки выглядит так: драйвер, контролирующий файловую систему, распознает метку классификации на документе (в нашем случае как раз «Анкеты») и обращается в FileAuditor за «инструкциями», как его обрабатывать. Доступ к файлу с меткой блокируется, если соблюдаются все условия. Их можно задать по пользователю, ПК, процессам – в разных сочетаниях. В результате системе не нужно дополнительно вычитывать содержимое файла, чтобы принять решение о блокировке – нужные алгоритмы применяются мгновенно.
То есть если настроен запрет чтения файлов с меткой «Анкеты» в MS Outlook для пользователей не из группы «Менеджеры», приложение в аккаунтах таких сотрудников не сможет открыть такой документ. Значит, и не прикрепит во вложение письма при отправке. В том числе ограничения действуют для групп процессов: например, для всех распространенных браузеров и мессенджеров разом. FileAuditor может блокировать доступ к файлу через любое приложение вне зависимости от его версии, типа, происхождения – будь это хоть системный процесс, хоть самописный корпоративный софт. Таким образом, даже те нарушители, у которых уже оказались не предназначенные им документы, не смогут передать их со своего ПК никаким способом.
Блокировки и ручное распределение прав в системе помогают контролировать чтение, изменение, пересылку документов с конфиденциальным содержимым и другие варианты нежелательного доступа к ним. Акцент на контент – отличительная особенность блокировок в FileAuditor, «классические» DCAP и другие ИБ-инструменты в основном реализуют такой функционал по свойствам или расположению файлов, но не по их содержимому.
3. Мониторинг нарушений
Заключительный этап – проверить, кто и что делает с файлами и не пытается ли обойти запреты. Для нас задача была скорее умозрительная – в целом сотрудники знакомы с правилами и не нарушают их. Тем не менее, некоторые любопытные находки мы сделали.
Сначала я проверил журналы операций с наиболее критичными файлами. Проще всего было настроить по нежелательным операциям политики безопасности, они фиксируют их автоматически и сразу сообщают в службу ИБ. Запустил политику – нарушений не нашел, только обычную работу с документами.
Чтобы перестраховаться, решил углубленно изучить вопрос. FileAuditor подгружает историю обращений к файлу с меткой при его просмотре в основной консоли. Собственно, операции видны в классической терминологии ОС: чтение, изменение, перемещение и т.д. Дополнительно система фиксирует внутренние события – если файл получил метку классификации (попал под автоматическое правило или был размечен пользователем вручную), потерял эту метку (то есть, например, пользователь удалил или изменил чувствительное содержимое), был переименован, удален или к нему кто-то получил новые права.
Но и такой аудит сюрпризов не принес. Никто из посторонних не пытался скопировать или как-то модифицировать файлы, скажем, из категории «Анкеты», о которых мы рассказывали выше, – что логично, учитывая заданные ограничения доступа.
А вот нарушения передачи документов я отметил. Для этого в FileAuditor есть фильтр «Операции -> Доступ запрещен». Это своего рода аудит блокировок: он показывает как попытки открыть файл / папку пользователем вручную, так и обращения к файлам через приложения, для которых настроен запрет.
Обнаружился инцидент: менеджер, имея легитимный доступ к файлу из категории «Анкеты», отправил его пиарщикам. Те, получив файл, закономерно не смогли его открыть, а система зафиксировала «сработку» блокировки. Стали разбираться – оказалось, менеджер собирался отдать анкету клиента инженеру ТП, но ошибся адресом при пересылке (пиарщик и инженер ТП – однофамильцы).
Что сделали: менеджеру вынесли предупреждение о внимательности, т.к. эту анкету он мог случайно отправить и кому-то во вне. Оставалось только донести до пиара, что за странный файл и почему он не открылся. Донесли, но задумались, что на такой случай хорошо бы сделать механизм, чтобы открыто уведомлять пользователя о блокировках. Это лишнее напоминание о корпоративных правилах и объяснение, почему не получается та или иная операция. Для пользователей, в свою очередь, нужно предусмотреть возможность оперативно запросить у службы ИБ разрешение на манипуляции с нужным файлом. Сейчас делаем функционал для запросов доступа через интерфейс FileAuditor на агенте, скоро оттестируем – и в релиз.
Еще немножко выводов
Главный – аудит освежает. Я привык ежедневно разбирать перехват, разбираться с тем, как сотрудники работают с конфиденциальными данными. И если возникают нарушения, на 90% их причины в том, что сотрудники получили доступ к файлам, которые «плохо лежали». Делаем аудит – опережаем проблемы на шаг. Особенно с учетом возможности превентивно настроить запреты и блокировки.
Итого – эксперимент удался. Даже базовые возможности аудита помогли нащупать, где нам можно усилить корпоративные политики ИБ. Заодно, кстати, «боевой» тест помог сформулировать задачи к разработке – кое-что можно сделать проще и удобнее, плюс появились идеи для новых фич. Так что, возможно, эксперимент будет полезен не только нам.
Если вы хотите пройти по нашему пути и проверить, как у вас с порядком в файловой системе, то до конца марта еще успеваете оставить заявку – получите систему бесплатно на три месяца.