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

Например, если задача пользователя состоит в редактировании в подвале сайта номера телефона - для него создается группа, имеющая права ТОЛЬКО на редактирование данной информации и он не может отредактировать мимоходом пункт меню или страницу "О компании". Аналогично, если пользователь управляет двумя инфоблоками, допустим, новостями, он должен иметь возможность редактировать только эти два инфоблока, а не 50 других инфоблоков в придачу.

Для чего это делается?

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

Так вот, полученные привилегии не должны быть критичными для безопасности веб-проекта. Одно дело - изменить телефон, другое - изменить информацию в 100 инфоблоках, а 50 - удалить.

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

1. Смотрим, какие группы определены в системе в разделе: "Настройки > Пользователи > Группы пользователей". Необходимо проверить доступы в каждой группе списка, кроме "Администраторы" (ее проверяем отдельно).
2. Для каждой группы на вкладке "Доступ" проверяем уровень доступа ко всем модулям системы. Если стоит уровень доступа "по умолчанию", проверяем что значит это уровень в настройках модуля: "Настройки > Настройки продукта > Настройки модулей > Название модуля > вкладка 'Доступ'", значение свойства "По умолчанию".
   Обычно выбрано консервативное значение этого свойства, например "Доступ запрещен". Однако важно проверить, что его никто не поменял на иное. Разумеется, перед тем, как настраивать права группы на модули, следует изучить в документации, какие операции внутри модуля соответствуют выбранному уровню прав. Например, какие операции разрешены учетной записи при уровне доступа к модулю "Интернет-магазин": "Обработка заказов" - означает ли этот уровень доступа возможность просматривать лицевые счета Покупателей или нет и т.п.
3. Если группа имеет доступ к модулю "Управление структурой" на уровне "Редактирование файлов и папок", необходимо тщательно проверить, к каким файлам и папкам группе предоставлен доступ в разделе "Контент > Структура сайта > Файлы и папки". Если группа по ТЗ имеет право только на редактирование файлов в папке "/about/company", то нужно убедиться что она не может ничего сделать в других папках сайтов. Аналогично проверяется доступ к другим файлам: меню, шаблоны сайта и т.д.
4. Просматриваем каждый инфоблок в проекте и проверяем права групп на него: "Контент > Информ. блоки > Типы информ. блоков > Название инфоблока > вкладка 'Доступ'". Если группе нужна информация из инфоблока, должен стоять уровень "Чтение", но никак не "Изменение", что очевидно.
5. Проверяем правильность настроенных прав группы в административном разделе, для чего авторизуемся под учетной записью группы в административную часть "/bitrix/admin" (если в ТЗ предусмотрена работа пользователей в административном разделе).

   Пользователь должен увидеть только то, на что ему даны права, допустим инфоблоки, некоторые папки с файлами, некоторые модули - и ничего лишнего. Иногда становится неожиданностью, что Покупатель магазина оказывается может зайти по адресу: "/bitrix/admin" и в административной части, например, отредактировать свой профиль и т.п. Если это не нужно, доступ в административную часть нужно ограничить.

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

   <Например, если группа редактирует страницы в определенных папках на сайте - учетная запись должна суметь выполнить данные операции без ошибок. Нередко проверяют работоспособность учетной записи, находящейся временно в группе "Администраторы", а когда учетную запись переводят в настроенную для нее группу - начинаются ошибки нехватки выделенных прав./p>

7. Проверяем количество учетных записей, находящихся в группе "Администраторы" - заходим в группу, смотрим на вкладке "Параметры" в подраздел "Пользователи в группе". Всем ли учетным записям в этой группе нужны административные права? Нередко в этой группе можно встретить "забытые" после интеграции учетные записи редакторов контента и т.п., что опасно.
8. Полезно проверить, какую информацию может найти на сайте пользователь в группе. Если в результатах поиска появляется "закрытая" для него информация - необходимо ограничить доступ группы к ней.

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