Файловый сервер и права доступа: типовые ошибки МСБ

Утро понедельника. Бухгалтер пишет в общий чат: «Не открывается договор с прошлого года». Через десять минут юрист отвечает: «А у меня открывается чужая зарплатная ведомость». Админ в отпуске. Временный «ответственный» снимает запрет «на всякий случай» — и к обеду в общей папке снова видят всё подряд.

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

Три сценария, которые повторяются годами

Первый — «все в Users». Когда компания была маленькой, общий диск раздали широкой группе. Потом выросли отделы, появились подрядчики и стажёры, а модель прав осталась той же. Документы с персональными данными лежат рядом с маркетинговыми макетами. Утечка здесь не обязательно злой умысел: достаточно любопытства и скриншота в мессенджер.

Второй — «наследовали от кого-то». Права копировали с соседней папки, «чтобы быстрее». Через год никто не помнит, почему у отдела продаж есть запись в каталоге кадров. При аудите или смене админа картина выглядит как лоскутное одеяло из исключений.

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

Где обычно ошибаются

Самая дорогая ошибка — выдавать права людям, а не группам. Сотрудник уходит, учётку блокируют, а доступ «по имени» остаётся в десятках ACL. Новый человек получает «как у Иванова» — и вместе с нужным каталогом получает лишнее.

Вторая ошибка — путать права шары МСБ и NTFS. На уровне шары «все могут читать», на уровне NTFS — хаос. В итоге диагностика превращается в угадайку: «почему у одного открывается, а у другого нет».

Третья — отсутствие аудита. Когда файл исчез или «кто-то поменял», расследование упирается в пустой журнал. Без логирования доступа вы узнаёте о проблеме только от пострадавшего бизнеса.

Практичный порядок наведения порядка

Начинать лучше не с «перезакрыть всё», а с карты данных. Какие каталоги критичны для финансов, кадров, договоров, проектов? Кто реально должен читать, кто писать, кто только просматривать? Пока нет ответа на эти вопросы, любая «техническая» правка — косметика.

Дальше — модель через группы каталога. Отдел, роль, проектная команда. Человеку выдают членство в группе, а не точечный ACE на каждый путь. Так проще принимать и увольнять, проще аудировать, проще объяснять бизнесу.

Отдельно стоит разобрать наследование. Глубокие деревья с локальными запретами почти всегда заканчиваются сюрпризами. Чем проще дерево и чем меньше исключений «deny», тем меньше ночных звонков.

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

Если параллельно идёт переход на облачный диск или корпоративную почту с общим хранилищем, те же принципы остаются: группы, минимально необходимые права, понятный владелец каталога, журнал. Технология меняется, логика — нет. Опытный подход предполагает сначала выровнять модель доступа, а потом уже переносить данные.

Что проверить за один рабочий день

• есть ли каталоги, где права выданы персонально десяткам учёток;
• совпадают ли права шары и NTFS с ожиданиями владельца данных;
• кто владелец критичных папок с точки зрения бизнеса, а не «папка просто лежит»;
• включён ли аудит хотя бы на финансовые и кадровые разделы;
• куда сотрудники складывают файлы, когда «на сервере нельзя» — часто там и сидит реальный риск.

Отдельно про аудит и расследование

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

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

Имеет смысл раз в квартал делать короткую ревизию: новые каталоги без владельца, персональные ACE вместо групп, шары с гостевым доступом, отключённый аудит. Ревизия на час предотвращает полугодовой проект «навести порядок после утечки».

Если компания параллельно смотрит в сторону облачных дисков и корпоративной почты, не переносите хаос один в один. Сначала назовите владельцев данных и матрицу доступа, потом мигрируйте. Иначе вы просто смените адрес проблемы.

Что считать победой

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

Для собственника это снижает два риска сразу: операционный простой из‑за «не открывается» и репутационный/регуляторный из‑за «открылось лишнее». Файловый сервер начинает работать как сервис с правилами, а не как общая тумбочка офиса.

Чем это заканчивается для бизнеса

Файловый сервер — не «просто диск». Это место, где лежат деньги в виде договоров, расчётов и коммерческих условий. Хаос прав либо тормозит работу («не открывается»), либо создаёт тихую утечку («открывается лишнее»). Обе цены измеримы: простоем людей и репутационным/регуляторным риском.

Когда права собраны через группы, наследование предсказуемо, а аудит включён, инцидент перестаёт быть детективом. Становится понятно, кого добавить, кого убрать и что произошло вчера в 18:40. Для руководителя это и есть настоящий результат: доступ работает, а «все видят всё» больше не является нормой по умолчанию.

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