V1.4.1 Access Control Architecture

Requirement:

Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client.

Explanation:

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

Trusted Enforcement Points:

• Доверенные точки внедрения - это компоненты или узлы в архитектуре приложения, в которых должно происходить выполнение контроля доступа. Как правило, эти точки являются частью инфраструктуры бэкенда или серверной части. В качестве примера можно привести веб-серверы, API-шлюзы, бессерверные функции и внутренние сервисы.

Enforcing Access Controls at Trusted Points:

• Обеспечение контроля доступа в доверенных точках внедрения является лучшей практикой безопасности по нескольким причинам:
  • Centralization: Централизация логики управления доступом в доверенных точках позволяет обеспечить последовательность и контроль. Это гарантирует, что решения по управлению доступом принимаются в контролируемой среде с соблюдением мер безопасности.
  • Security: Компоненты Backend более безопасны, чем код на стороне клиента, поскольку они менее подвержены вмешательству и манипуляциям со стороны злоумышленников. Это снижает риск несанкционированного доступа и нарушения безопасности.
  • Consistency: Централизованная логика управления доступом обеспечивает согласованность политик и правил управления доступом в рамках всего приложения. Это упрощает управление и снижает вероятность неправильной конфигурации.
  • Auditing: Доверенные точки внедрения хорошо подходят для аудита и логирования, что очень важно для контроля и соблюдения нормативных требований.

Client-Side Enforcement:

• Применение средств управления доступом на стороне клиента означает, что решения о доступе принимаются в браузере или на устройстве пользователя. Это не рекомендуется по нескольким причинам:
  • Lack of Trust: Применение контроля на стороне клиента основывается на предположении, что клиенту можно доверять, что не является безопасным предположением в контексте безопасности. Код на стороне клиента может быть изменен злоумышленниками.
  • Limited Control: После запуска приложения на клиентском устройстве, вы имеете ограниченный контроль над его поведением. Злоумышленники могут модифицировать код приложения на стороне клиента или перехватывать и управлять запросами, обходя контроль доступа.
  • Inconsistency: При внедрении на стороне клиента, можно получить несогласованные политики управления доступом на различных клиентских платформах (например, веб-, мобильных, настольных), что затрудняет поддержание согласованной системы безопасности.

Remediation:

Для выполнения данного требования необходимо учитывать следующие рекомендации:

1.Identify Trusted Enforcement Points:

• Определите ключевые компоненты и места в приложении, где должно осуществляться управление доступом. Это и есть доверенные точки внедрения.

2.Review Existing Access Control Mechanisms:

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

3.Move Access Control Logic to Trusted Points:

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

4.Use Authentication and Authorization Services:

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

5.Centralize Access Control Rules:

• Централизуйте правила и политики управления доступом в бэкенде приложения. Не следует полагаться на клиентские скрипты или пользовательские интерфейсы при принятии решений по управлению доступом.

6.Secure API Endpoints:

• Если ваше приложение содержит API, обеспечьте их защиту путем реализации проверок контроля доступа на шлюзе или сервере API. Убедитесь, что каждая конечная точка API обеспечивает проверку авторизации перед обработкой запросов.

7.Implement Role-Based Access Control (RBAC):

• Используйте RBAC или аналогичные модели управления доступом для централизованного управления ролями и разрешениями пользователей. Назначение разрешений ролям и последующее предоставление ролей пользователям в соответствии с их ролями и обязанностями.

8.Audit and Logging:

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

9.Security Testing:

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

10.Client-Side Validation:

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

11.Regular Review and Maintenance:

• Регулярно пересматривайте и обновляйте политики и правила контроля доступа, чтобы адаптироваться к изменяющимся требованиям и угрозам

Additional:

https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

https://owasp.org/www-pdf-archive/Owasp-top-10-proactive-controls-2018-russian.pdf