Плохо оформленная авторизация — это технический долг
technical-debt authorization

Плохо оформленная авторизация — это технический долг

1 декабря 2022 г.

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

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

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

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

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

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

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

Cerbos является реализацией именно этой модели, где логика отделена от кодовой базы и определяется как простые для понимания файлы конфигурации политик, а не код. Это устраняет технический долг всей логики авторизации, разбросанной по кодовой базе, и заменяет ее простой условной проверкой РАЗРЕШИТЬ/ЗАПРЕТИТЬ, где сама логика обеспечивается точкой принятия решения о политике, работающей внутри вашей инфраструктуры.

н

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE