Вход в личный кабинет Что такое оauth2.0?
Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации — фреймворк авторизации OAuth2.0.
Стандарт был принят в 2022 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.
Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем.
OAuth 2.0 — это фреймворк авторизации.
Он описывает, как должно реализовываться взаимодействие между сервисами для обеспечения безопасной авторизации. Многие нюансы описаны достаточно подробно, например, flow взаимодействия узлов между собой, но некоторые отдаются на откуп конкретной реализации.
Особенности:
Разберёмся подробнее в особенностях.
Краткое описание
(Central Authentication Service) — это веб-приложение, написанное на java. Чтобы начать им пользоваться, почти ничего не надо делать. Нужно загрузить, настроить, собрать, развернуть. И настроить клиентов (сайты на которых мы делаем single sign on).
Основные понятия aaa
Прежде чем мы познакомимся с протоколами RADIUS и TACACS , разберемся с основными понятиями механизма AAA. Для примера будем использовать процесс законного проникновения в помещение с контролем доступа.
Что такое grant?
Grant — это данные, которые представляют из себя успешную авторизацию клиента владельцем ресурса, используемые клиентом для получения access token.
Например, когда мы где-либо аутентифицируемся с помощью Google, перед глазами всплывает уведомление. В нём говорится, что такой-то сервис хочет получить доступ к данным о вас или к вашим ресурсам (выводятся запрашиваемые scope-token). Это уведомление называется «Consent Screen».
В момент, когда нажимаем «ОК», в базу данных попадает тот самый grant: записываются данные о том, что такой-то пользователь дал такие-то доступы такому-то сервису. Клиент получает какой-то идентификатор успешной аутентификации, например строку, которая ассоциируется с данными в базе данных.
Существует 4 1 способа получения grant — grant type:
Начало
Сегодня я хотел бы рассказать о том, как проходит аутентификация в приложениях самых различных платформ – начиная от мобильных приложений, заканчивая консольными утилитами.
Аутентификация – это процесс, при котором пользователь подтверждает подлинность своей личности в какой-либо системе. Система предоставляет личные данные только своему владельцу.
Основные различия между radius и tacacs
Основные различия сводятся к тому, что TACACS шифрует все содержимое пакета, оставляя только простой заголовок. Такой способ защищает от злоумышленников, которые прослушивают сообщения, передаваемые между устройствами. Также TACACS реализует функции AAA раздельно, что позволяет вынести каждую из них на отдельный сервер или даже использовать другой протокол (не TACACS ).
TACACS также предлагает более тесную интеграцию с устройствами Cisco и позволяет осуществлять детальное управление маршрутизаторами (процесс авторизации). С сервером TACACS возможно реализовать управление командами с применением уровней доступа (которые далее настраиваются на самих устройствах). RADIUS позволяет частично реализовать эту возможность, но не так хорошо и гибко, как TACACS .
TACACS также поддерживает несколько других протоколов (отличных от IP), таких как AppleTalk, NetBIOS, NetWare Asynchronous Service Interface (NASI) и X.25, но в современных сетях их использование сошло на нет.
При использовании протокола TACACS между клиентом и сервером не может быть брендмауэра, так как сервер должен получить запрос от клиента с его IP-адресом, а не с адресом брендмауэра. У RADIUS IP-адрес клиента содержится еще и в самом пакете, что позволяет ААА-серверу получить его оттуда.
А вот самый большой недостаток TACACS заключается в том, что Cisco разработала этот протокол для собственных нужд и поэтому самую широкую его поддержку получили именно сетевые устройства этой компании. Однако постепенно ситуация меняется, и остальные производители стали также поддерживать TACACS .
Какой протокол для ААА-сервера использовать, необходимо выбирать в зависимости от задачи. Если это администрирование устройств, то TACACS станет лучшим вариантом, а если доступ к сети, то более универсальный и быстрый – RADIUS.
В версии 6.0 СКАТ DPI стала доступна авторизация IPoE-сессий на RADIUS, что расширило возможности оператора связи по осуществлению контроля доступа абонентов к сети Интернет и применения политик тарифных планов и дополнительных тарифных опций:
- назначение и изменение политик (тарифных планов и опций);
- перенаправление пользователей в Captive Portal (блокировка);
- работа на уровне L3;
- идентификация пользователей по IP или по метке Q-in-Q.
Более подробную информацию о преимуществах СКАТ DPI, ее эффективном использовании на сетях операторов связи, а также о миграции с других платформ вы можете узнать у специалистов компании VAS Experts, разработчика и поставщика системы анализа трафика СКАТ DPI.
Аутентификация на основе токенов
Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.
При аутентификации на основе токенов состояния не отслеживаются. Мы не будем хранить информацию о пользователе на сервере или в сессии и даже не будем хранить JWT, использованные для клиентов.
Процедура аутентификации на основе токенов:
Authorization code
Самый распространённый flow на данный момент. В основном используется для confidential клиентов, но с появлением дополнительной проверки с помощью PKCE, может применяться и для public-клиентов.
Cookies
Наверное вы часто слышали термин Cookies – это маленький фрагмент данных, которые система (сервер) хранит у пользователя. Каждый раз, когда пользователь открывает сайт – серверу отправляются данные Cookies, которые сервер сохранил у пользователя на устройстве.
Вы можете проектировать свои интерфейсы как с сохранением сессий пользователей, так и без сохранения.
Radius
Протокол RADIUS является IETF-стандартом для AAA. Используется с начала 1990-х годов и первоначально применялся для коммутируемых модемных соединений. Изначально использовался для расширения Layer 2 протокола точка-точка (PPP) между конечным пользователем и сервером доступа к сети (NAS), передавая трафик аутентификации с NAS на AAA-сервер.
Современная реализация RADIUS использует порты 1812 (аутентификация) и 1813 (учет) протокола UDP (также возможно использование портов 1645 и 1646). UDP обладает высокой скоростью, но имеет ряд недостатков, которые необходимо учитывать при его применении.
Resource owner password credentials flow
По текущим рекомендациям безопасности описанных в
, данный flow не рекомендуется использовать вовсе из-за явных проблем с безопасностью.
Tacacs
Данный протокол разработан компанией Cisco и является развитием прошлых версий TACACS и XTACACS. Несмотря на схожесть названий, TACACS был сильно видоизменен и не имеет обратной совместимости с TACACS, который сейчас практически нигде не применяется.
Основная сфера использования TACACS – это администрирование сетевых устройств, однако он может применяться для некоторых типов AAA при доступе в сеть. TACACS использует Transmission Control Protocol (TCP) порт 49, а не UDP, так как он обладает большей надежностью и позволяет заранее получать информацию о потенциальных ошибках благодаря пакету TCP-RST.
ТСP более медленный протокол, но обладает дополнительными преимуществами: возможность разделения аутентификации, авторизации и учета в качестве отдельных и независимых функций, множественная авторизация после одной аутентификации, шифрование всего содержимого пакета.
Для наглядности объединим основные характеристики в таблицу:
Абстрактный oauth 2.0. flow c применением access token
Мы рассмотрели роли, рассмотрели виды токенов, а также как выглядят scope. Посмотрим на flow предоставления доступа к сервису.
Ниже представлена абстрактная схема (или flow) взаимодействия между участниками. Все шаги на данной схеме выполняются строго сверху вниз. Разберём детальнее.
Клиент получает одобрение от resource owner, на основе которого ему выдаётся доступ к ресурсу. Всё просто. А будет ли так же просто, если мы добавим в эту схему работу с refresh token?
Абстрактный oauth 2.0. flow c применением refresh token
Первый и второй шаги опущены из данной схемы — они ничем не отличаются от схемы абстрактного flow выше.
Схема подробнее:
Архитектору безопасности на заметку
Задача данного исследования и подготовленного обзора заключается в том, чтобы предоставить Архитектору безопасности лучшие практики для реализации модели АА в разрабатываемом продукте и оставить его наедине с вопросом: «Что из этого лучше подходит к моему приложению?».
При этом, мы не исключаем, что на этот же вопрос «Что из этого лучше подходит к моему приложению?» Архитектор ответит: «Кажется, что ничего не подходит. Придется делать свою модель с блэк-джеком». И в итоге, разработанная им модель окажется в данном списке в качестве новой «best practice» — смело делай pull requests в соответствующую шпаргалку от OWASP.
В полном тексте научной публикации, помимо рекомендаций архитектору по безопасности приложений по выбору подходящего архитектурного шаблона, можно найти полный перечень источников информации (публикации, выступления на конференциях), которые были проанализированы в рамках данного исследования.
Архитектурные модели реализации аа
Мы провели декомпозицию функций АА (если собираешься стать архитектором безопасности приложений, то добавляй сложные слова и термины в свою коллекцию – возможно, они пригодятся на совещаниях) на основе характеристик типовых микросервисных приложений и определили следующий список подфункций безопасности (Рисунок 1): пограничная авторизация (edge-level authorization), авторизация на уровне сервиса (service-level authorization), пробрасывание идентификатора внешнего субъекта (external entity identity propagation), межсервисная аутентификация (service-to-service authentication). Затем мы рассмотрели основные электронные базы данных и библиотеки, а также стандарты безопасности и презентации на основных конференциях по безопасности с целью выявления существующих архитектурных схем.
Рисунок 1. Подфункции аутентификации и авторизации в системах на базе микросервисов
Разберем основные модели и их схемы.
В простом сценарии авторизация может происходить только на пограничном уровне (при помощи шлюза API). Шлюз API можно использовать в качестве центра авторизации для всех последующих микросервисов, исключая необходимость обеспечения аутентификации и контроля доступа для каждого отдельного микросервиса.
Однако авторизация на пограничном уровне имеет следующие недостатки:
Аутентификация в соцсетях
Уверен, эта картинка знакома всем:
Аутентификация или авторизация?
Некоторые путают термины «аутентификация» и «авторизация». Это разные вещи.
Ещё тут?
Поздравляю, вы успешно дочитали длинную, нудную и скучную статью.
Беспарольная аутентификация
Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»
В наши головы внедрено убеждение, что пароли — абсолютный источник защиты наших аккаунтов. Но если изучить вопрос глубже, то выяснится, что беспарольная аутентификация может быть не просто безопасной, но и безопаснее традиционного входа по имени и паролю. Возможно, вы даже слышали мнение, что пароли устарели.
Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:
Вместо ввода почты/имени и пароля пользователи вводят только свою почту. Ваше приложение отправляет на этот адрес одноразовую ссылку, пользователь по ней кликает и автоматически входит на ваш сайт / в приложение. При беспарольной аутентификации приложение считает, что в ваш ящик пришло письмо со ссылкой, если вы написали свой, а не чужой адрес.
Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.
И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.
Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.
Двухфакторная аутентификация
В некоторых случаях может потребоваться дополнительная мера защиты учётных данных пользователя, и именно для этого вводится механизм двух факторной аутентификации – это когда пользователю необходимо подтвердить подлинность своей личности двумя разными способами. Примером может служить – ввод Email Пароль, а затем номера телефона и СМС кода.
Двухфакторная аутентификация (2fa)
Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN.
Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.
Децентрализованный шаблон
В этом шаблоне команда разработчиков реализует PDP и PEP непосредственно на уровне кода микросервиса (рис. 3). Все правила контроля доступа, а также атрибуты, необходимые для реализации этого правила, определяются и хранятся в каждом микросервисе (шаг 1). Когда микросервис получает (шаг 2) запрос на доступ вместе с некоторыми метаданными авторизации (например, контекст конечного пользователя), микросервис анализирует его (шаг 3) для того, чтобы сгенерировать решение политики контроля доступа, а затем реализует (enforce) авторизацию (шаг 4).
Рисунок 3. Высокоуровневая архитектура децентрализованного шаблона
Существующие библиотеки и фреймворки для различных языков программирования позволяют разработчикам осуществлять авторизацию на уровне микросервисов. Реализация авторизации на уровне исходного кода означает, что код должен обновляться всякий раз, когда команда разработчиков хочет изменить логику авторизации.
Соответственно, данная модель несет в себе следующие ограничения:
С другой стороны, внедрение политики контроля доступа в код микросервиса позволяет разработчикам использовать более гибкие правила контроля доступа, поскольку микросервис обладает всеми необходимыми данными доменной модели.
Для кого эта статья
Статья для дизайнеров интерфейсов, которые желают понять то, как работают процессы регистрации, авторизации, восстановления пароля, применяемые в различных системах. Если вы разработчик/дизайнер, и нашли ошибку/неточность – то дайте мне знать (я с радостью доработаю статью).
Для чего нужен aaa
При строительстве и эксплуатации сети важно иметь строгий контроль над теми, кто имеет доступ к ее устройствам. Если ваша сеть небольшая и число ее пользователей невелико, то следить за доступом и безопасностью не составляет труда, и часто за это отвечает один сетевой администратор.
Но если организация имеет масштабную корпоративную сеть или это сеть оператора связи с большим числом абонентов, то отслеживать вручную, кто к чему имеет доступ, становится невозможно. В этом случае на помощь приходит AAA – механизм, который позволяет осуществлять аутентификацию, авторизацию и учет пользователей, то есть контролировать доступ и записывать производимые действия.
Для обеспечения безопасности сети необходимо обеспечить контроль за доступом к различным элементам сети со стороны пользователей. Такими элементами могут быть сетевые устройства, серверы, компьютеры, приложения или даже сегменты самой сети.
Сценарии разные, а принцип один – аутентификация, авторизация и учет (Authentication, Authorization, Accounting – AAA).
Есть два основных типа AAA для сетей:
- Администрирование сетевых устройств. Осуществляет управление теми, у кого есть доступ для входа в консоль сетевого устройства, Telnet-сессии, Secure Shell (SSH-сессии) или другим способом.
- Доступ к сети. Идентификация пользователя или устройства до того, как ему будет предоставлен доступ к сети.
Задача auth
Проблема авторизации в десятках сервисов встречалась ещё несколько лет назад — в начале «
». Эту проблему решили новым сервисом, который назвали – Auth. Он помог реализовать бесшовную аутентификацию в различных сервисах и перенести данные о пользователях в отдельные базы данных.
У сервиса Auth есть три основные задачи:
Идентификация, аутентификация и авторизация: серьезные определения
Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:
- Идентификация — процедура, в результате выполнения которой для субъекта идентификации выявляется его идентификатор, однозначно определяющий этого субъекта в информационной системе.
- Аутентификация — процедура проверки подлинности, например проверка подлинности пользователя путем сравнения введенного им пароля с паролем, сохраненным в базе данных.
- Авторизация — предоставление определенному лицу или группе лиц прав на выполнение определенных действий.
Межсервисная аутентификация
Существует два общих способа реализации межсервисной аутентификации:
В подходе mTLS каждый микросервис может уверенно определить, с кем он общается, в дополнение к достижению конфиденциальности и целостности передаваемых данных. Каждый микросервис при старте должен получать свою пару открытый/закрытый ключей и открытый ключ доверенного центра сертификации, которые в дальнейшем используются для аутентификации микросервиса получателя через mTLS.
Объясняем идентификацию, аутентификацию и авторизацию на енотах
Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
Права доступа
Права доступа выдаются клиенту в виде scope. Scope – это параметр, который состоит из разделённых пробелами строк — scope-token.
Каждый из scope-token представляет определённые права, выдающиеся клиенту. Например, scope-token doc_read может предоставлять доступ на чтение к какому-то документу на resource server, а employee — доступ к функционалу приложения только для работников фирмы. Итоговый scope может выглядеть так: email doc_read employee.
В OAuth 2.0 мы сами создаём scope-token, настраивая их под свои нужды. Имена scope-token ограничиваются только фантазией и двумя символами таблицы ASCII — ” и .
На этапе регистрации клиента, в настройках сервиса авторизации клиенту выдаётся стандартный scope по умолчанию. Но клиент может запросить у сервера авторизации scope, отличный от стандартного. В зависимости от политик на сервере авторизации и выбора владельца ресурса, итоговый набор scope может выглядеть совсем иначе.
Процессы аутентификации
Так как наши данные при регистрации в каком либо сервисе хранятся в базе данных – то к процессу аутентификации применяются базовые принципы работы с базами данных (далее БД) – это чтение, запись, обновление и удаление данных. При этом, во время каждого из действий с БД проверяется возможность совершения этих действий пользователем.
Регистрация (CREATE) – создание в системе вашей личной учётной записи
Авторизация (READ) – получение доступа к вашей личной учётной записи
Восстановление доступа к учётной записи (UPDATE) – если вы на пример забыли пароль – то его можно сменить, подтвердив свою личность.
Удаление (DELETE) – удаление вашей учётной записи из системы
Разворачивание
Для разворачивания понадобится сервер с установленной jvm и какой-либо СУБД. Даже если вы не используете СУБД для авторизации, CAS использует ее для хранения своих служебных таблиц.
В этих таблицах он хранит списки адресов, на которых возможна авторизация через этот сервер.
Регистрация клиента
Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от
фантазии
конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.
Redirection URI — адрес, на который отправится владелец ресурса после успешной авторизации. Кроме авторизации, адрес используется для подтверждения, что сервис, который обратился за авторизацией, тот, за кого себя выдаёт.
Client type — тип клиента, от которого зависит способ взаимодействия с ним. Тип клиента определяется его возможностью безопасно хранить свои учётные данные для авторизации — токен. Поэтому существует всего 2 типа клиентов:
Свой способ авторизации
Сначала нам нужно определить свою логику проверки имени пользователя и пароля. Для этого нам нужно переопределить класс
Схема работы
Как работает CAS можно понять вот из этой диаграммы:
Аналогичную схему использует Яндекс и Гугл.
Рассмотрим её по шагам:
Токены
Токен в OAuth 2.0 — это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная — её формат не имеет значения для клиента. Токен — это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).
У каждого токена своё время жизни. Но у refresh token оно должно быть больше, т.к. он используется для получения access token. Например, если срок жизни access token около часа, то refresh token можно оставить жить на целую неделю.
Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением.
За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.
Упрощённое объяснение термина “сессия”
Сессия – это механизм сохранения состояния авторизации пользователя в системе на заданный срок. Сессий одного пользователя может быть много. Примером может служить сессии в социальных сетях – когда вы можете зайти в свой аккаунт социальной сети с нескольких устройств одновременно, без необходимости выходить из учётной записи на другом устройстве.
Для того что бы различать входы с различных устройств – каждой сессии присваивается свой уникальный для каждой авторизации номер (Токен), который хранится в Cookies. Это нужно для того, что бы при выходе (закрытии сессии) с одного из устройств вы не выходили из своей учёной записи во всех остальных устройствах.
Цели исследования
Архитектура микросервисов все чаще используется для проектирования и внедрения прикладных систем как в облачных, так и в локальных инфраструктурах, крупномасштабных приложениях и сервисах. Достаточно изучить Хабр на предмет различных практик, связанных с разработкой распределенных и отказоустойчивых систем, чтобы убедиться в повсеместном внедрении микросервисной модели.
На этапах разработки и внедрения программного продукта необходимо решить множество проблем безопасности. Основополагающими требованиями, над которыми ломает голову aрхитектор безопасности (Application Security Architect – роль в крупной продуктовой компании, которая еще не избавляет от технических задач Security Engineer’a, но которая уже добавляет высокоуровневые проблемы, связанные с архитектурой и процессами) и которые должны быть решены на этапе проектирования, являются аутентификация и авторизация (для краткости, АА).
Поэтому архитекторам безопасности приложений крайне важно понимать и правильно использовать существующие архитектурные шаблоны для реализации АА в системах, основанных на микросервисах. Цель нашего исследования заключалась в том, чтобы выявить такие шаблоны и дать архитектору безопасности рекомендации по их возможному использованию.
Исследование проводится с учетом трех ключевых вопросов:
В ходе исследования мы провели обзор основных электронных библиотек научных статей, мы также просмотрели стандарты безопасности, презентации на крупных конференциях по безопасности и локальных тематических митапах (привет, OWASP Moscow Meetup).
Итогом стали следующие результаты:
Централизованная модель со встроенной точкой принятия решения
В этой модели правила контроля доступа определяются централизованно, но хранятся и оцениваются на уровне микросервисов (рисунок 5). Правила контроля доступа определяются с помощью PAP (шаг 1) и доставляются во встроенную PDP вместе с атрибутами субъектов и объектов доступа, которые необходимы для использования этих правил (шаг 2). Когда субъект вызывает микросервиса (шаг 3), код микросервиса вызывает PDP, а PDP генерирует решение политики контроля доступа, оценивая входной запрос по правилам и атрибутам контроля доступа (шаг 4). На основе решения PDP микросервис применяет авторизацию (шаг 5).
Рисунок 5 Высокоуровневая архитектура централизованной модели со встроенной PDP
PDP код в этом случае может быть реализован как встроенная библиотека микросервиса или «sidecar-прокси». Sidecar обрабатывают коммуникации между сервисами, производят мониторинг и устраняют проблемы безопасности, то есть все, что может быть абстрагировано от отдельных сервисов, подробнее можно почитать тут.
В связи с возможными отказами сети или хоста и задержками в сети рекомендуется реализовать встроенную PDP в виде микросервисной встроенной библиотеки или sidecar на одном хосте с микросервисом. Встроенная PDP обычно хранит политику авторизации и связанные с политикой данные в памяти, чтобы уменьшить количество внешних зависимостей во время авторизации и для получения низкой задержки.
Основное отличие от “централизованного шаблона с единой точкой принятия решения” с подходом к кэшированию заключается в том, что решения по авторизации не хранятся на стороне микросервиса, вместо этого на стороне микросервиса хранится актуальная политика авторизации.
В выступлении “How Netflix Is Solving Authorization Across Their Cloud” представлен практический пример применения шаблона “Централизованную модель со встроенной PDP” для реализации авторизации на уровне микросервисов (рисунок 6):
Преимущества этих шаблонов такие же, как и для “Централизованных шаблонов с одним PDP”. Кроме того, шаблон не сильно влияет на задержки в обслуживании сетевых запросов из-за встраивания PDP на уровне микросервисов.
Существует несколько проблем, которые необходимо учитывать при применении этой модели:
- этот шаблон опирается на ручные или полуручные правила политики доступа, разработанные командой безопасности, которые могут быть подвержены ошибкам — во избежание уязвимостей конфигурации необходимо применять методы тестирования и верификации безопасности;
- архитекторы безопасности приложений должны комбинировать его с другими шаблонами (например, авторизация на пограничном уровне), чтобы избежать наличия единой точки принятия решений и обеспечить соблюдение принципа “эшелонированной обороны”;
- может случиться так, что некоторые специфические для бизнеса правила контроля доступа не могут быть реализованы таким образом — архитекторы безопасности приложений должны комбинировать этот шаблон с “Децентрализованным шаблоном”;
- архитекторы безопасности приложений должны выбрать подход, как получать обновления политик авторизации из централизованных PAP (например, опрос PAP или механизм публикации-подписки);
- команда разработчиков должна безопасно использовать сторонние компоненты авторизации и описывать политику контроля доступа, используя некий формальный язык, который в некоторых случаях может быть накладным — “Децентрализованный шаблон” может быть достаточным для реализации некоторой простой политики контроля доступа.
Централизованный шаблон с единой точкой принятия решения
В этой модели правила контроля доступа определяются, хранятся и оцениваются централизованно (рисунок 4). Правила контроля доступа определяются с помощью PAP (шаг 1) и доставляются в централизованную PDP вместе с атрибутами субъектов и объектов доступа, которые необходимы для использования этих правил (шаг 2).
Когда субъект вызывает микросервис (шаг 3), код микросервиса вызывает централизованный PDP через сетевой вызов, а PDP генерирует решение политики контроля доступа, оценивая входной запрос по правилам и атрибутам контроля доступа (шаг 4). На основе решения PDP микросервис реализует авторизацию (шаг 5).
Рисунок 4. Высокоуровневая архитектура централизованного шаблона с единой PDP
Некоторыми преимуществами этой схемы являются:
- команды разработчиков и продуктовой безопасности могут обновлять правила контроля доступа без изменения исходного кода, это позволяет централизованно управлять политиками, изменения в политиках могут быть развернуты отдельно от микросервисов;
- определения правил контроля доступа можно оставить для реализации команде разработчиков, но при этом вынести за пределы основной части исходного кода, чтобы политики были доступны для периодического аудита, более того, некоторые правила контроля доступа являются универсальными для системы и могут совместно использоваться в микросервисах всей организации;
- правила контроля доступа могут использоваться в среде эксплуатации для обнаружения аномалий безопасности, например, аномальное поведение микросервисов, основанное на вызовах API, при обнаружении угроз можно динамически воссоздавать и применять новые правила контроля доступа для снижения риска безопасности.
Для определения правил контроля доступа команда разработчиков и DevOps-инженеров должна использовать язык или нотацию. Примером может служить язык разметки Extensible Access Control Markup Language (XACML) и Next Generation Access Control (NGAC), который является стандартом для реализации описания правил политики.
Этот шаблон плохо влияет на время обслуживания запросов из-за дополнительных сетевых вызовов PDP; использование кэширования решений политики авторизации на стороне микросервиса позволяет уменьшить сетевые задержки.
Следует отметить, что PDP должен работать в режиме высокой доступности из-за возможных проблем с отказоустойчивостью. Архитекторы безопасности приложений должны комбинировать его с другими шаблонами (например, авторизация на уровне шлюза API), чтобы избежать наличия единой точки принятия решений и обеспечить соблюдение принципа “эшелонированной обороны”.
Заключение
В данной статье мы рассмотрели базовые принципы работы аутентификации в различных системах. Вся эта статья нацелена для того, чтобы помочь дизайнерам интерфейсов понять то – как работает процесс аутентификации, для чего он нужен, каких видов он бывает и что происходит на большинстве этапов во время авторизации, регистрации, восстановления пароля пользователем.
Надеюсь вам было полезно, и хоть немного интересно.
Вместо вывода
В этой статье я опустил много подробностей, чтобы максимально просто и доступно рассказать о самом важном. Например, типы запросов, как и в каком виде передавать параметры, какие символы допустимы в качестве значений для того.
Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.
Если статья была полезна и захотите подробностей — пишите в комментариях, и в следующих статьях расскажу о PKCE, о протоколе аутентификации OpenID Connect 1.0, о нашей реализации сервера аутентификации и многом другом.
Полезные ссылки:
(1 оценок, среднее: 4,00 из 5)
Загрузка...