Лучшие принципы авторизации микросервисов

Не позволяйте уязвимостям авторизации проникнуть в вашу систему

Эй, у тебя когда-нибудь был такой опыт? Некий микросервис внезапно «выходит из себя» и либо зависает здесь, либо не имеет разрешения там. В результате все приложение рушится одно за другим, как домино. Хуже всего то, что вы даже не знаете, в чем проблема, и можете лишь искать эту маленькую настройку авторизации, как иголку в стоге сена среди сотен или тысяч сервисов.

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

Что делать? Основной принцип на самом деле очень прост

Сначала задайте себе несколько вопросов: каждый из ваших микросервисов повторяет «изобретение колеса» и пишет свой собственный набор проверок разрешений? При добавлении новой службы нужно ли нам реорганизовывать всю цепочку разрешений, опасаясь пропустить какое-либо звено? Приведет ли изменение правила разрешений к серии неожиданных сбоев?

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

Вот несколько простых идей:

• Централизованная власть, но не узкое место. Вместо того, чтобы позволять каждой службе принимать собственные решения о том, «кто что может делать», лучше настроить выделенную, облегченную службу авторизации. Это похоже на дирижера на концерте, который сам не играет на инструментах, но следит за тем, чтобы каждый игрок знал, когда вмешаться. Сервис заботится только о своей собственной бизнес-логике, и проверка разрешений оставлена ​​на усмотрение этой «команды» для координации.
• Разрешения следуют за данными, а не жестко запрограммированы в сервисе.. Например, служба заказов не должна писать «Изменять заказы могут только администраторы», а должна спрашивать: «Имеет ли текущий пользователь право изменять этот номер заказа?» Это суждение может основываться на роли пользователя, команде или более детальных атрибутах (например, «Этот пользователь является создателем этого заказа»). Таким образом, изменения разрешений больше не требуют внесения изменений в код службы.
• Токены должны быть «правильными». Токен удостоверения (например, JWT), передаваемый службе, не должен содержать всю информацию о пользователе. Должны быть включены только необходимые удостоверения и глобальные роли, а конкретные, детализированные разрешения должны быть возвращены службой авторизации в режиме реального времени по запросу. Это уменьшает размер токена и снижает риск утечки конфиденциальной информации.

Это звучит немного абстрактно? Давайте подумаем об этом по-другому

Вы можете думать о системе микросервисов как о современном сообществе. Служба авторизации похожа на интеллектуальный центр управления доступом сообщества. Когда жители (пользователи) входят в сообщество, центр управления доступом подтверждает их личность (аутентификацию). Когда жилец хочет войти в определенное здание или воспользоваться тренажерным залом (получить доступ к определенному микросервису), картридеру (сервису) здания не нужно хранить список разрешений всех жильцов - ему достаточно быстро спросить центр контроля доступа: "Имеет ли житель А право войти в Корпус 3?" Центр контроля доступа мгновенно проверяет сертификат собственности, аренду или бронирование (политику) жителя А, а затем отвечает «разрешить» или «запретить».

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

При выборе вы можете взглянуть на эти места

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

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

Немного случайного мышления

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

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

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

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.