Проверка прав доступа к файлам, папкам и административной панели

Как найти лишние права раньше, чем это сделает злоумышленник или проверяющий

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

Зачем вообще проверять права доступа

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

Проверка прав доступа полезна как минимум по четырём причинам:

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

Что понимается под правами доступа

Проверяют не только папки на сервере. В контур входят домен, регистратор и DNS, CDN, хостинг, CMS и админ-панель, SSH/SFTP, база данных, Git и CI/CD, резервные копии и объектные хранилища, сервисные учётные записи, API-ключи и интеграции.

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

Как устроена проверка прав доступа на практике

Уровень операционной системы и файлового сервера

В Windows-инфраструктуре права на файлы и папки настраиваются через NTFS: администратор открывает свойства папки, вкладку «Безопасность» и назначает группе или пользователю конкретный набор разрешений — чтение, изменение, полный доступ . Дополнительно можно включить аудит доступа — тогда операционная система будет фиксировать каждую попытку открыть, изменить или удалить файл в журнале событий, если для объекта настроена соответствующая политика аудита .

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

Уровень облачных хранилищ и общих дисков

В облачных сервисах (Google Диск, SharePoint/OneDrive и аналогичные) основная точка риска — не столько базовые права пользователей, сколько расшаренные ссылки и внешний доступ. Администратор может включить уведомления о предоставлении внешнего доступа к контенту на диске, ограничить доступ по ссылке или полностью запретить передачу файлов за периметр организации . В SharePoint для этого предусмотрены отдельные отчёты по управлению доступом к данным, которые показывают, какие ссылки были созданы, кем и когда, и позволяют инициировать проверку доступа к конкретному сайту или библиотеке .

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

Уровень административной панели

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

• ограничение доступа к разделу администрирования по IP-адресу — только с корпоративных или доверенных адресов ;
• двухфакторная аутентификация хотя бы для учётных записей с правами администратора, а в идеале — и для хостинга, FTP и базы данных ;
• разграничение ролей внутри самой панели: у редактора не должно быть доступа к разделам, не связанным с его задачами, а у маркетолога — к настройкам разработки ;
• отдельные учётные записи для каждого сотрудника — использование одной общей учётной записи администратора несколькими людьми лишает смысла любой аудит, потому что становится невозможно понять, кто именно совершил то или иное действие ;
• регулярное обновление CMS и модулей, отключение неиспользуемых расширений и запрет редактирования кода прямо из веб-интерфейса .

Российская специфика: что требует закон

Статья 19 152-ФЗ требует правовых, организационных и технических мер защиты персональных данных. Приказ ФСТЭК № 21 применяется к информационным системам персональных данных, а состав мер выбирают с учётом уровня защищённости и актуальных угроз. [8] [9]

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

Модели управления доступом: что выбрать

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

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

Ролевая модель (RBAC). Идея простая: доступ пользователя к системам и данным ограничивается минимумом, необходимым для выполнения его должностных обязанностей, и не более того — это и есть принцип наименьших привилегий, который лежит в основе RBAC . Права группируются не вокруг конкретных людей, а вокруг ролей — «бухгалтер», «менеджер по продажам», «разработчик» — и уже роли назначаются сотрудникам. При смене должности или увольнении достаточно поменять роль, а не разбирать вручную десятки индивидуальных разрешений.

Атрибутная модель (ABAC) и более гибкие политики. Используются там, где ролей RBAC становится недостаточно — например, когда доступ должен зависеть не только от должности, но и от отдела, региона, срока действия или уровня чувствительности данных.

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

Практические этапы проверки прав доступа

Шаг 1. Инвентаризация ресурсов и учётных записей

Собирают CMS, хостинг, домен, DNS, SSH/SFTP, базу, репозитории, конвейеры, резервные копии, интеграции и сервисные ключи.

Шаг 2. Матрица фактических прав

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

Шаг 3. Проверка авторизации приложения

Права проверяются на сервере при каждом запросе и по принципу запрета по умолчанию. Тестируют горизонтальный доступ к чужим объектам, вертикальное повышение роли и прямые ссылки на файлы; скрытая кнопка в интерфейсе не считается контролем доступа. [1][2]

Шаг 4. Согласованное исправление

Лишние права отзывают вместе с владельцем ресурса, сохраняя аварийный доступ. Для административных ролей включают MFA; ограничение по IP используют как дополнительный слой, а не замену MFA. [3][7]

Шаг 5. Повторная проверка и журнал

После изменения повторяют контрольные сценарии и сохраняют подтверждение. Пересмотр запускают при увольнении, смене роли, окончании договора и после инцидента; календарная периодичность определяется риском. [5][6]

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

Типичные ошибки и риски

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

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

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

Отсутствие владельца процесса. Если ИТ-отдел только выполняет заявки на доступ, но никто не проводит регулярную ревизию и не отвечает за актуальность прав, модель со временем превращается в хаос .

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

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

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

Как выбрать подход к организации проверки

Многое зависит от масштаба инфраструктуры и от того, насколько критичны данные, к которым организован доступ.

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

Для организации с большим количеством систем, файловых хранилищ и облачных сервисов ручная проверка становится нежизнеспособной — здесь применяются специализированные решения класса Data Access Governance и IdM/IGA, которые автоматически сопоставляют права доступа с фактической активностью пользователей, выявляют избыточные права по директориям и позволяют смоделировать последствия их отзыва до того, как изменения применяются в реальной среде .

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

Как может помочь «Пятый фактор»

«Пятый фактор» может собрать реестр доступов к домену, хостингу, CMS, SSH/SFTP, Git, резервным копиям и интеграциям, сопоставить фактические права с владельцами и задачами, а затем согласованно убрать лишнее. После изменений повторяем контрольные сценарии и передаём актуальную матрицу доступов.

Вывод

Проверка прав доступа — это не разовая техническая процедура, а постоянный процесс: права имеют свойство накапливаться, а инфраструктура — меняться быстрее, чем успевает актуализироваться документация о том, кто и что может делать. Разумный минимум для любой организации — инвентаризация ресурсов, сопоставление фактических прав с реальными задачами сотрудников, регламент выдачи и отзыва доступа и регулярный, а не разовый пересмотр прав. Для компаний, работающих с персональными данными, эта работа дополнительно опирается на требования ФСТЭК и общую логику 152-ФЗ, а не является только вопросом внутренней гигиены безопасности.

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

Источники

[1] OWASP Authorization Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

[2] OWASP Application Security Verification Standard — https://owasp.org/www-project-application-security-verification-standard/

[3] OWASP Multifactor Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html

[4] WordPress — Hardening WordPress — https://developer.wordpress.org/advanced-administration/security/hardening/

[5] Microsoft Learn — планирование аудита доступа к файлам — https://learn.microsoft.com/ru-ru/windows-server/identity/solution-guides/plan-for-file-access-auditing

[6] CIS Controls Navigator — https://www.cisecurity.org/controls/cis-controls-navigator

[7] Yandex Cloud — безопасное использование IAM — https://yandex.cloud/ru/docs/iam/best-practices/using-iam-securely

[8] Официальное опубликование правовых актов — 152-ФЗ, статья 19 — https://ips.pravo.gov.ru/api/ips/legislation/document?baseid=None&hash=98490812b3409e2a8d78a11ca9010f434ea3d9250a11dbbdb78690cd5551bdd6

[9] ФСТЭК России — приказ № 21 от 18.02.2013 — https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-18-fevralya-2013-g-n-21