Права доступа к файлам Битрикс: как найти лишние разрешения и закрыть их без риска

Права доступа к файлам Битрикс — это два независимых слоя: права файловой системы (владелец и chmod) и внутренние права платформы (уровни D, R, U, W, X для групп пользователей). Лишний доступ появляется, когда один из слоёв настроен шире, чем нужно задаче. Практический результат: матрица для фиксации расхождений, алгоритм диагностики и чек-лист приёмки.

Что именно проверяем: два слоя доступа к файлам Битрикс

Прежде чем что-то менять, разделите задачу на два независимых слоя. Первый — файловая система сервера: у каждого файла и папки есть владелец и режим доступа. Именно этот слой определяет, может ли веб-сервер прочитать файл, а посторонний процесс — записать в него. Второй слой — внутренние права платформы: для групп пользователей задаются уровни D (доступ запрещён), R (чтение), U (документооборот), W (запись), X (полный доступ). Эти уровни применяются к путям относительно корня сайта и не заменяют права файловой системы (chmod).

Частая ошибка: закрытие доступа на уровне платформы не блокирует прямой доступ к файлу по URL, если права файловой системы (chmod) этого не запрещают. Диагностика начинается с вопроса: какой именно слой открыт лишним? Ответ на него определяет и инструмент проверки, и способ исправления.

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

Исходные данные и ответственные за проверку

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

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

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

Варианты действий и критерии выбора

У проверки есть несколько режимов, и выбирать нужно по критериям, а не по привычке.

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

Второй вариант — сверка с эталоном: сравнение текущего состояния с документированным шаблоном развёртывания или регламентом проекта.

Третий вариант — проверка доступности извне: тестирование чтения файлов по URL. Требует согласования, так как создаёт нагрузку на работающий сайт.

Четвёртый вариант — исправление с предварительной копией и планом возврата. Применяется только после того, как матрица согласована и есть способ откатить изменения.

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

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

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

Затем опишите целевую картину: какие пути должны быть доступны на чтение веб-серверу, какие — на запись приложению, какие не должны отдаваться наружу вообще. Целевая картина согласуется с владельцем и разработчиком, потому что только они знают логику приложения.

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

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

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

Как читать режимы файловой системы

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

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

Отдельно проверьте файлы, которые появились не в результате развёртывания: временные, резервные копии, архивы, экспорт данных. Они часто остаются с широкими правами просто потому, что создавались вручную. Такие файлы — типичный источник лишнего доступа.

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

Внутренние права платформы и группы пользователей

Внутренние права задаются для групп пользователей и применяются к путям относительно корня сайта (или корня конкретного сайта в многосайтовой версии). Уровни доступа: D — запрет, R — чтение, U — документооборот, W — запись, X — полный доступ. Символ «*» применяется ко всем группам, включая гостей.

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

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

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

Матрица проверок и приоритеты

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

Заполняйте матрицу по мере проверки, а не после. Каждая строка — отдельный объект или группа объектов с одинаковыми свойствами. Если объектов много, группируйте по каталогам, но не теряйте конкретику там, где она важна.

Приоритет расставляйте по последствиям, а не по удобству. Сначала то, что открывает доступ к конфигурации и данным. Потом — служебные каталоги. Затем — всё остальное. Исправления идут в том же порядке.

Матрица согласуется с владельцем и ответственным за сервер. После согласования она становится основанием для изменений и для приёмки.

Учебный пример: проверка на условном проекте

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия: условный сайт на Битрикс с одним доменом, двумя группами пользователей (гости и редакторы), каталогом загрузки файлов и каталогом резервных копий, который создавался вручную. Есть тестовая копия, окно изменений согласовано, резервная копия сделана.

Действия. Сначала собрали список корневых каталогов и отметили те, что доступны по URL. Обнаружили, что каталог резервных копий читается извне. В матрице он получил высокий приоритет. Затем проверили владельцев: часть файлов принадлежала учётной записи, отличной от той, под которой работает веб-сервер. Это тоже попало в матрицу. После этого сверили внутренние права групп: у гостей был доступ к путям, которые должны быть доступны только редакторам.

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

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

Чек-лист приёмки после исправлений

• Матрица заполнена по всем проверенным путям и согласована с владельцем
• Для каждого изменения есть копия и описанный план возврата
• Изменения проверены на тестовой копии до применения на проде
• Каталоги, доступные на запись, соответствуют логике приложения
• Файлы конфигурации и резервные копии не читаются извне
• Внутренние права групп соответствуют их ролям
• Вложенные каталоги проверены отдельно от родительских
• Служебные каталоги закрыты и проверены повторно
• Работа сайта после изменений подтверждена ответственным
• Результаты проверки зафиксированы письменно

Ограничения, типичные ошибки и следующий шаг

Типичная ошибка — менять права массово, не понимая, какие пути используются приложением. Это приводит к отказу загрузки файлов, сбоям обмена и потере доступа к административным разделам. Вторая ошибка — считать, что внутренние права платформы заменяют права файловой системы. Третья — проверять только корневые каталоги и забывать о вложенных. Четвёртая — оставлять временные и резервные файлы с широкими правами.

Ограничения: диагностика не заменяет полноценный аудит кода и не выявляет уязвимости в логике приложения. Если нужно оценить проект целиком, разумно совместить проверку прав с техническим аудитом сайтов на 1С-Битрикс. Если требуется разобраться, как устроен код и где он работает с файлами, поможет аудит кода Битрикс: как проверить проект и принять работу. Понимание того, как в целом проходит проверка проекта, даёт Аудит сайта на Битрикс: как проходит и что вы получите.

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