C7: Обязательный контроль доступа

Описание

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

Необходимо отметить, что авторизация (подтверждение права доступа к специальным функциям или ресурсам) не равняется аутентификации (подтверждению личности).

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

  • избирательное управление доступом (DAC) — предполагает ограничение доступа к объектам (например, файлам или элементам данных) на основе идентификатора, а также принципа «необходимого знания» субъектов (например, пользователей или процессов) и/или групп, которым принадлежат объекты;
  • мандатное управление доступом (MAC) — предполагает ограничение доступа к системным ресурсам на основе критичности (определяемой метками) данных, содержащихся в этих ресурсах, и формальных полномочий (т. е. допуска) пользователей на доступ к информации, указанной важности;
  • ролевая модель управления доступом (RBAC) — предполагает контроль доступа к ресурсам на основе ролей, определяющих разрешенные действия с ресурсами, а не на основе идентификаторов субъектов;
  • управление доступом на основе атрибутов (ABAC) — предполагает разрешение или запрещение запросов пользователя, исходя из атрибутов пользователя и атрибутов объекта, а также элементов окружения, которые могут определяться глобально и быть более релевантными для применяемых политик.

Принципы создания систем контроля доступа

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

1) Проектируйте тщательно и заранее

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

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

2) Направляйте все запросы через систему контроля доступа

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

3) Запрещайте доступ по умолчанию

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

  1. Приложение может выдавать ошибку или исключение при обработке запросов на предоставление доступа. В подобных случаях в доступе должно быть отказано.
  2. При создании администратором или пользователем новой учетной записи эта учетная запись по умолчанию должна иметь минимальный или нулевой набор прав доступа, пока эти права не будут назначены.
  3. При добавлении новой функции в приложение никто из пользователей не должен иметь права использовать ее до выполнения соответствующей настройки.

4) Принцип минимальных привилегий

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

5) Не используйте жестко закодированные роли

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

if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
    deleteAccount();
}

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

  • Программирование с использованием ролевой модели — дело рискованное. Легко создать некорректную или пропустить проверку ролей в коде.
  • Программирование с использованием ролевой модели не поддерживает мультитенантность. Использование ролевой модели в системах разных заказчиков потребует создания отдельной ветки кода или добавления отдельных проверок для каждого заказчика.
  • Программирование с использованием ролевой модели не поддерживает зависящее от данных или горизонтальное управление доступом.
  • Для больших баз кода с множеством проверок прав доступа бывает сложно проводить аудит или проверять политику управления доступом во всем приложении.

Вместо этого попробуйте использовать следующий способ управления доступом:

if (user.hasAccess("DELETE_ACCOUNT")) {
    deleteAccount();
}

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

6) Регистрируйте все события, связанные с контролем доступа

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

Инструменты