УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Token Authentication


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Следующее поколение способов аутентификации представляет Token Based Authentication, который обычно применяется при построении систем Single sign-on (SSO). При его использовании запрашиваемый сервис делегирует функцию проверки достоверности сведений о пользователе другому сервису. Т. е. провайдер услуг доверяет выдачу необходимых для доступа токенов собственно токен-провайдеру (Identity provider). Это то, что мы видим, например, входя в приложения через аккаунты в социальных сетях. Вне IT самой простой аналогией этого процесса можно назвать использование общегражданского паспорта. Официальный документ как раз является выданным вам токеном — все государственные службы по умолчанию доверяет отделу полиции, который его вручил, и считает паспорт достаточным для вашей аутентификации на протяжении всего срока действии при сохранении его целостности.

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


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

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


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Способы аутентификации

При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.

Аутентификация в эпоху SaaS и облачных сервисов

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

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

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

За эти 15 лет представители индустрии совместными усилиями разработали стандарты аутентификации вроде OAuth2, OpenID connect и SAML. Мы также начали использовать JWT и прочие инструменты. Сегодня никому уже не нужно создавать систему авторизации, если он сам того не захочет, поскольку на то существует множество сервисов.

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

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

Проблема в том, что для авторизации не существует единых стандартов индустрии. Вы можете применять некие модели вроде контроля доступа на основе ролей (RBAC) или атрибутов (ABAC), но стандартов здесь нет, поскольку авторизация – это задача, решаемая в различных предметных областях. В этой сфере также не существует каких-либо специализированных разработчиков или сервисов. Вот вы можете представить себе использование для авторизации Twilio или Stripe? А поскольку не существует ни стандартов, ни заточенных под это сервисов, компании теряют гибкость из-за необходимости тратить время на создание собственных систем авторизации, преодолевая все сопряжённые с этим трудности.

Здесь также необходимо учитывать затраты. Во сколько вам обойдётся время, которое вы будете вынуждены вложить не в наращивание предлагаемой вашим бизнесом ценности, а в разработку и обслуживание собственной системы контроля доступа? А когда компании берутся реализовывать это самостоятельно, то зачастую получается у них это не особо удачно. Именно поэтому слабые места в системах контроля доступа лидируют в списке 10 наиболее распространённых уязвимостей, составленном открытым проектом по обеспечению безопасности веб-приложений (OWASP).

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

Forms Authentication


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Биометрическая идентификация

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

Наиболее распространенный пример — Touch ID компании Apple. Такие вещи действительно восхищают. Биология — наша истинная идентичность, она всегда с нами. Мы знаем об идее разблокирования телефонов или планшетов при помощи отпечатка пальца. Тем не менее биометрическая идентификация используется и в других местах (и с другими параметрами).

Windows Hello — это перспективная система идентификации для Windows 10, соединяющая камеры с датчиками (на компьютерах и устройствах) для распознавания лица, радужки глаз или отпечатков пальцев. Нужно просто открыть компьютер и заниматься своими делами, не жертвуя при этом безопасностью. Этот тип идентификации был до недавнего времени невозможен, особенно в масштабе Windows 10.

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

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

Биометрическая идентификация только начинает развиваться, но некоторые API и библиотеки позволяют нам пользоваться биометрической идентификацией уже сегодня. К ним относятся BioID Web Service, KeyLemon, Authentify и Windows Biometric Framework API (на котором, как мне кажется, построена Hello).

Сервисы для отправки Email и СМС сообщений.

Начнем с отправки email. Чтобы отправить сообщение на почту вам необходим SMTP сервер (и без него обойтись не получится). Здесь есть 2 варианта:

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

Вариант 2 – рациональный. Вы используете сторонние сервисы, которые берут на себя работу по обслуживанию SMTP сервера, а вам предоставляют, либо готовый API для отправки сообщений, либо сам адрес SMTP сервера, который вы можете использовать.

Как вы могли догадаться, в обоих случаях удовольствие это не бесплатное. Или почти не бесплатное. В случае с SMTP сервисами, многие провайдеры предоставляют триал или бесплатное использование на время разработки (то есть у вас все будет работать, но только на маленьких нагрузках). Одним из таких сервисов является SMTP.bz.

Теперь разберемся с сервисами для отправки СМС сообщений. В этом случае у нас также есть готовые API для отправки смс. Например – smsc.ru. Использование довольно простое – отправка http запроса с номером телефона и сообщением.

Однако в данном случае я не нашел сервисов, у которых есть бесплатные периоды (Напишите в комментариях если вы знаете такие) Возможно это связано с тем, что в цепочке отправки смс также участвует сотовый оператор, который взымает плату за отправку с “смс сервисов”. Потому они не могут предоставить бесплатный триал доступ, как в случае с SMTP.

Взгляд сверху


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

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

В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

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

Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. O Auth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.

Контроль в реальном времени – это задача распределённых систем

В современных системах авторизации очень важны проверки в реальном времени. Авторизация – это действительно сложная задача, поскольку при верной реализации она становится задачей распределённых систем.

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

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

Кодовая фраза

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

Секретные фразы безопаснее паролей, их легче запомнить. Об этом пишут уже больше десяти лет: от статьи «
Пароли-слова против паролей-фраз» в 2005 году до «Почему секретные фразы удобнее для пользователей, чем пароли» в 2015-м.

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

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

Хотите доказательств?
Zxcvbn — это проект Dropbox, определяющий надежность пароля. Другие сайты могут использовать Zxcvbn как определитель надежности пароля с открытым исходным кодом. В этой статье Dropbox есть статистика и сведения об истинной надежности различных паролей. Прочтите статью, и вы поймете, что пароль Tr0ub4dour&3 гораздо уязвимее, чем «правильнаялошадьштапельнойбатареи». Это легко проверить с помощью тестов.

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

Впервые я использовал пароли-фразы с компанией интернет-банкинга
Simple, которая приветствует эксперименты и новые технологии, и они показали себя прекрасно. Мою фразу-пароль просто запомнить и легко набрать — особенно на мобильном телефоне.

Использование в Банковской сфере

Авторизация банковских карт

Структура токена

Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).

Токен обновления

Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.

Более подробно о составе токенов в разделе «структура токена».

OAuth2 & Open ID Connect

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

Два подхода к детальному контролю доступа

Вокруг концепции детального контроля доступа сформировалось две экосистемы:

▍ 1. Политика как код

В этой парадигме мы выражаем политики как набор правил, написанных на языке Rego. Она представляет собой продолжение ABAC, и наиболее популярным проектом здесь является Open Policy Agent (OPA).

OPA – это механизм принятия решений общего назначения, который создавался для управления доступом на основе политик и ABAC. Однако у него есть свои недостатки: используемый для написания политик язык – Rego – является производным от языка Datalog, который очень труден для освоения. При этом он также не сгодится для моделирования авторизации в приложении. А поскольку OPA поистине является механизмом общего назначения, вам придётся собирать всё из рудиментарных кирпичиков.

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

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

▍ 2. Политика как данные

В этом случае политика хранится не как набор правил, а является встроенной в структуру данных. Граф связей сам по себе является самодостаточной системой, поэтому заниматься разработкой модели вам не придётся. Здесь у нас есть «субъекты», «объекты» и «связи», что обеспечивает широкую гибкость.

Если ваша модель области выглядит, как Google Drive и несёт в себе каталоги, файлы и пользователей, то именно с этого подхода следует начать. С другой стороны, эта экосистема всё ещё находится на этапе становления и представлена множеством конкурирующих опенсорсных реализаций, в связи с чем будет сложно совместить её с другими моделями авторизации вроде RBAC и ABAC.

Процесс аутентификации


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Формат


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

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

Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.

Пять лучших практик облачного контроля доступа

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

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

В последние пару лет крупные организации начали публиковать работы, описывающие принцип действия их специализированных систем авторизации. Всё началось с публикации Google Zanzibar, в которой рассказано о создании такой системы для Google Drive и других сервисов. За Google последовали и другие компании, которые описали разработку своих специализированных сервисов авторизации и окружающих их распределённых систем. Речь идёт о таких инструментах, как AuthZ компании Intuit, Himeji ресурса Airbnb, AuthZ платформы Carta и PAS компании Netflix. Теперь мы начинаем анализировать их опыт и применять его в собственном ПО.

▍ 2. Детальный контроль доступа

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

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

▍ 3. Управление доступом на основе политик

Третий антипаттерн – это реализация контроля доступа в виде спагетти-кода, то есть, когда разработчики беспорядочно раскидывают инструкции switch и if по всему коду, управляющему логикой авторизации. Это плохой подход, который создаёт массу трудностей, когда нам нужно изменить способ осуществления авторизации по всей системе.

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

▍ 4. Проверки доступа в реальном времени

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

Рассмотрим в качестве примера сценарий с авторизацией пользователя, которому доступна область «администратор». Эта область встраивается в токен доступа. Теперь, когда пользователь взаимодействует с системой, используя действующий токен с областью «администратор», он получает привилегии администратора. Почему это плохо? Дело в том, что если мы захотим лишить пользователя этой области доступа и сделать её недействительной, то столкнёмся со сложностями. До тех пор, пока пользователь обладает неистёкшим токеном доступа, он сможет использовать все ресурсы, к каким этот токен его предоставляет.

При использовании токенов доступа невозможно реализовать детальную модель управления. Даже если издатель токена видит, к каким ресурсам пользователь имеет доступ, будет непрактичным встраивать эти права в токен. Предположим, у нас есть коллекция документов, и мы хотим дать пользователю разрешение на доступ к одному из них. О каком документе идёт речь? Может, обо всех? Или о нескольких? Очевидно, что такой подход не масштабируется.

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

▍ 5. Централизованные логи решений

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

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

JWT(JSON Web Token)

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

Что представляет из себя этот стандарт ? Как можно догадаться из названия, этот стандарт основан на JSON и позволяет передавать вместе с токеном любой JSON объект (а поскольку мы можем любые данные представить в качестве объекта, который в последствии будет превращен в JSON, то внутри JWT можно передавать всё что угодно). J WT состоит из 3-х частей:

3) Уникальный ключ, для шифрования

Получается у нас есть объект, состоящий из 3-х полей. В хедере мы указываем, что за тип токена мы используем и как будут кодироваться данные. В секции payload – данные, которые мы хотим передавать с сервера на клиент и обратно. А уникальный ключ – это пароль, с помощью которого мы кодируем 2 предыдущих части и превращаем их в строку.

Ключ, всегда хранится только на сервере. И клиентское приложение не имеет к нему доступа. Таким образом гарантируется, что изменить токен может только приложение у которого есть этот ключ (то есть только сервер). Здесь важно, что именно ИЗМЕНИТЬ, т.к декодировать токен и получить из него header и payload может любой, кто получил этот токен. Эти данные публичные.

Алгоритм генерации JWT токена на Java Script

Сначала мы превращаем header и payload в base64. Далее используем алгоритм шифрования из библиотеки CryptoJs, для того чтобы закодировать две полученные base64 строки и получить сигнатуру(которая тоже является строкой). После чего просто объединяем 3 полученные строки в одну, разделяя точками.

Как вы могли заметить внутри сигнатуры закодирована информация о хедере и payload. Это нужно для того, чтобы когда сервер получает токен от клиента, он с помощью своего ключа декодировал бы сигнатуру и сравнил соответствуют ли данные внутри сигнатуры, тем, которые хранятся внутри payload. И в случае если данные разнятся или вообще не удалось декодировать их, то это является признаком того, что данные могли перехватить и изменить. Соответственно запрос не проходит валидацию и в ответ возвращается ошибка.

Access и Refresh токены

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

Для решения этой проблемы существуют Access и Refresh токены. Здесь мы не начинаем использовать какой-то новый способ авторизации. Используется все тот же JWT, но теперь единственный токен, который у нас был мы называем Access Token, при этом в дополнении к нему появляется второй Refresh токен, который также представляет из себя строку, имеет одинаковую структуру с Access Token, поэтому может хранить внутри какие-то данные (хоть и не обязательно и обычно это не требуется).

Важно то, что у Access и Refresh токенов появляются обязательные поля внутри их payload (iat, exp). Об их существовании я уже упоминал, но когда у нас есть только 1 токен, то эти поля по большому счету не используются и содержат дополнительную информацию.

Iat (issued at time) – время, когда токен сгенерирован.

Exp (expiration time) – время, до которого токен будет считаться валидным.

Алгоритм авторизации с использованием Refresh и Access токенов.

Почему нельзя обойтись одним Access токеном

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

Давайте разберемся что у нас произойдет, если ваши токены похищены. Хакер получил доступ к вашему аккаунту и может делать все что угодно, до тех пор пока вы не зайдете в систему. Потому что в этот момент истечет срок действия вашего Access токена и вам придется обновить пару токенов на новую, следовательно похищенные токены станут не валидными. Или представим др. ситуацию. Хакер провел долгое время на вашей странице, а значит требуется обновить Access Token с его стороны (что он успешно сделает), ведь он завладел обеими (в том числе и Refresh). Следовательно, теперь уже когда вы попытаетесь зайти в свой аккаунт сервер вернет ошибку, т.к уже ваш Refresh Token не валидный, после чего вы введете свои данные и не валидной станет пара токенов, похищенная злоумышленником.

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

Где хранить токены

Хотя существуют методики и для хищения данных из куки. Здесь нужно запомнить один момент. У вас не получится на 100% защититься от всех атак в браузере, но чем больше уровней защиты вы установите, тем меньше вероятность взлома.

HTTP Basic Authentication


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Что же это такое?

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

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

Терминология OAuth2 & OpenID Connect

Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.

Пути решения

Решить данную задачу нам помогают разработанные модели управления доступом:

MAC — мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.

DAC — прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL) объекта.

RBAC — ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.

АВАС — атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC, с некоторыми нюансами (шикарный обзор от CUSTIS).

Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.

Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:

Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:

Истоки проблемы

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

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

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

Для этого уже есть несколько методов и постоянно появляются новые. Традиционную аутентификацию при помощи пароля можно сделать комфортной и удобной. Вот актуальные способы:

Я буду оценивать каждый метод, исходя из нескольких факторов:

Разбираемся детально ху из ху

В данный момент на слуху следующие протоколы:

OpenID Attribute Exchange 1.0 (2007) расширяет OpenID 2.0 разрешая получать и хранить профиль пользователя.

OAuth 1.0 (2010) позволяет пользователю разрешать приложению получать ограниченный доступ на третьесторонних серверах(third-party server), доверяющих удостоверяющему центру.

OAuth 2.0 (2012) делает тоже самое, что и OAuth 1.0, но только протокол существенно поменялся и стал проще.

OpenID Connect (2014) объединяет возможности OpenID 2.0, OpenID Attribute Exchange 1.0, и OAuth 2.0 в один общий протокол. Он позволяет приложениям использовать удостоверяющий центр для:

Важно понимать, что OpenID Connect не дает доступ к внешним ресурсам. Он использует OAuth 2.0 для того, чтобы представить параметры профиля как будто это такие ресурсы.

Социальный вход

Социальный вход или вход через авторитетный проверенный сайт — популярный и удобный способ идентификации. Он предназначен не только для входа в систему. У American Express есть Amex Express Checkout, откуда вы входите на свой Amex-аккаунт, чтобы безопасно оплачивать товары на сторонних сайтах. Вы идентифицированы, и уже не нужно отправлять данные кредитной карты продавцу.

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

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

Тем не менее
статья MailСhimp от 2012 года понятно объясняет, почему сайт был против социального входа (и, судя по всему, с тех пор не поменял позицию). Сервис аргументирует это тем, что социальный вход создает слишком много неудобств для пользователя. Даже при однократной регистрации в варианте социального входа и при запасном варианте входа пользователь должен запомнить, как именно он регистрировался в самом начале.

В чем-то я согласен с MailСhimp, но социальный вход сейчас для многих гораздо понятнее и удобнее. Подтверждение тому — широта его применения: часто это отличный способ упростить идентификацию. Я по-прежнему предлагал бы только один вариант, а именно социальный вход, но если такие компании, как Medium, предлагают несколько вариантов, такое решение точно имеет право на жизнь.

HTTP Digest Authentication


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Паттерны детального контроля доступа


УПРАВЛЕНИЕ АВТОРИЗАЦИЕЙ

Давайте подробнее поговорим о детальном контроле доступа и его появлении.

▍ Списки контроля доступа (ACL)

В далёких 80-х годах операционные системы определяли для файлов и каталогов разрешения вроде «чтение», «запись» и «выполнение». Эти паттерны назывались списками контроля доступа (ACL).

С помощью ACL можно было ответить на такие вопросы, как «Есть ли у Алисы доступ к ‘чтению’ этого файла?»

▍ Контроль доступа на основе ролей (RBAC)

RBAC, или контроль доступа на основе ролей, вошёл в обиход в период между 90-ми и началом 2000-х вместе с появлением каталогов вроде LDAP и Active Directory. Такие каталоги дают возможность создавать группы и добавлять в них пользователей. При этом каждая группа обычно соответствует конкретной роли в приложении. Администратор приписывал пользователя группе, чтобы дать ему нужные разрешения, производя все необходимые манипуляции в одной консоли.

С помощью RBAC можно отвечать на вопросы вроде: «Состоит ли Боб в роли ‘администратор продаж’?»

▍ Контроль доступа на основе атрибутов (ABAC)

Очередным витком развития стал контроль на основе атрибутов (ABAC), и именно здесь мы начали уходить от многокомпонентных ролей в сторону детального контроля доступа. В начале 2000-х и 2010-х мы увидели, как стандарты вроде XACML определяют построение политик детальной авторизации.

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

С помощью ABAC можно ответить на вопросы вроде: «Состоит ли Мэллори в отделе ‘Продаж’? Находится ли документ в каталоге ‘Продажи’? или «Рабочее ли сейчас время в США?».

▍ Контроль доступа на основе связей (ReBAC)

Последней, но не менее важной является новая модель авторизации, описанная в работе Zanzibar под названием контроль доступа на основе отношений (ReBAC). Согласно этой модели, вы определяете набор субъектов (обычно ваших пользователей или групп) и объектов (например, организаций, каталогов или клиентов). Следом вы также определяете, имеет ли конкретный субъект связь с неким объектом. Например, между пользователем и объектом каталога такими связями будут выступать «наблюдатель», «администратор» или «редактор».

С помощью ReBAC можно отвечать на очень сложные вопросы, перебирая граф отношений, сформированный объектами, субъектами и их связями.

Что представляет из себя база данных.

Выше я писал про чудесный “текстовый файл”, в котором хранятся все данные пользователей. Вы безусловно можете организовать хранение данных в обычных .txt файлах, но на практике так никто не делает. Данная формулировка была использована, для того чтобы вы понимали, что ваши данные хранятся на жестком диске, таким же образом, как вы храните у себя на компьютере фотки, записи и видео.

Но используют для этих целей определенные программы “Базы данных”. База данных – это программа, которая работает в фоновом режиме, функциями которой вы можете пользоваться из других программ (написанных вами). Что это за функции? – если коротко, то это операции сохранения и получения данных, но в отличии от обычного текстового файла, база данных выполняет операции сохранения и получение намного быстрее (Особенно когда этих данных становится очень много).

Таким образом работу backend приложения можно представить, как работу 2-х независимых программ:

Запрос на аутентификацию

Authentication/Token Request — процесс запроса аутентификации.

В зависимости от того какие области (scopes) запрошены, сервис выдачи токенов вернет:

Более подробно про процесс аутентификации можно прочесть в разделе «процесс aутентификации».

Область (scope)

Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.

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

Scopes бывают двух видов:

Токен доступа

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

Имя пользователя и пароль

Буду честен: у меня возникают проблемы с традиционной моделью. В идеальном мире я бы устранил пароли вообще, но в реальности я пользуюсь этим методом в 99% своих проектов.

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

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

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

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

Ограничивать или исключать правила для паролей

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

Регистрация на сайте GoDaddy

В США и Великобритании 73% взрослых людей
используют на всех своих аккаунтах один и тот же пароль. Если ваши правила не дают пользователю использовать его стандартный пароль — он создает уникальный и, как правило, очень быстро его забывает. Исключив правила для паролей, вы даете пользователю возможность помнить пароль, чем повышаете юзабилити своего сервиса.

Зачем нам навязывают этот комплекс правил? Существуют исследования, которые утверждают, что длинные пароли эффективнее паролей с различными символами, но об этом я расскажу позже.

Напоминать пользователю о правилах

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

Авторизация на cайте BrowserStack

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

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

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

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

Подсказки Люка Вроблевски

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

Конкретизировать сообщение об ошибках ввода

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

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

Что же теперь делать

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

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

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

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

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

Токен личности

Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *