Авторизация
предоставление определённому лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий. Часто можно услышать выражение, что какой-то человек «авторизован» для выполнения данной операции — это значит, что он имеет на неё право.
Авторизацию не следует путать с аутентификацией — процедурой проверки легальности пользователя или данных, например, проверки соответствия введённого пользователем пароля к учётной записи паролю в базе данных, или проверка цифровой подписи письма по ключу шифрования, или проверка контрольной суммы файла на соответствие заявленной автором этого файла. Авторизация же производит контроль доступа к различным ресурсам системы в процессе работы легальных пользователей после успешного прохождения ими аутентификации.
В этих статьях, упоминается это определение:
Боткэмп-3. Советы и лайфхаки при создании навыков для Алисы
Боткэмп-3. Доклад на тему советы и лайфхаки при разработке навыков для Алисы. С чего начать, и на что стоит обратить внимание. Доклад от Максима Мочалова.Расскажем, с чего начать разработку навыка, на что важно обратить внимание и чем хорошие навыки отличаются от плохих.
Весеннее обновление платформы Диалогов
Команда Яндекс.Диалогов подготовила большой пакет обновлений и сегодня представляет его сообществу разработчиков голосовых приложений в формате Dev Preview.
Создание навыка я никогда не
Создание навыка я никогда не с использованием движка u_bot, позволяющего создавать приложения на разных платформах.
Как со мной связаться?
Свяжитесь со мной по любому поводу!
Я с радостью отвечу на все вопросы!
Никто (почти) не знает, что такое авторизация
За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.
Что же это такое?
Процитируем Википедию:
Авториза́ция (англ. authorization «разрешение; уполномочивание») — предоставление определенному лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.
С точки зрения любой информационной системы это процесс принятия решения о предоставлении доступа субъекту на выполнение операции на основании каких-либо знаний о субъекте. К этому моменту субъект, как правило, уже должен быть идентифицирован (мы должны знать, кто он) и аутентифицирован (подтверждена его идентичность).
Реализация авторизации при разработке корпоративной информационной системы или продукта, ориентированного на корпоративный сектор — очень сложная и ответственная задача, которой часто уделяется недостаточное внимание на этапе проектирования и первичном этапе разработки, что в будущем ведет к «костыльной» реализации.
Проблематика
Давайте разберемся, какие требования к авторизации встречаются, и почему их крайне важно учитывать изначально при проектировании системы, а не откладывать на будущее. Источников требований к авторизации в корпоративной информационной системе, как правило, два — это бизнес и информационная безопасность. В общем случае бизнес хочет хранить секреты в тайне и предоставлять полномочия пользователям в соответствии с их функцией в бизнес-процессе, а безопасность хочет обеспечить минимальную достаточность полномочий каждому пользователю и аудировать доступ.
Возьмем для примера гипотетическую систему согласования договоров крупной компании, типовой кровавый энтерпрайз. Практически наверняка возникнут следующие требования к авторизации от бизнеса:
- Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе
- Автор договора должен видеть его на всех этапах.
- Создавать договор имеет право пользователь с грейдом не ниже 10.
- Визирующий должен видеть договор, начиная с поступления к нему на этап и далее.
- Руководители подразделений должны видеть договоры своих подразделений вверх по иерархии.
- Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования.
- Руководство и секретариат головного офиса должны видеть документы всех филиалов.
- Пользователь, создавший договор, не должен иметь права его завизировать.
- Знать, кто имеет доступ к конкретному договору.
- Знать, кто имел доступ к конкретному договору в заданный момент времени.
- Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей.
Итак, обозначим, почему эти требования проблемные:
- Они не стабильны. Вероятность их изменения, даже в краткосрочной перспективе, стремится к 1.
- Они сквозные. Их реализация влияет на все слои, от дизайна БД до UI.
- Они лежат в плоскости предметной области. Это ведет к сильной связности механизма авторизации со слоем бизнес-логики.
- Они влияют на производительность.
Пути решения
Решить данную задачу нам помогают разработанные модели управления доступом:
MAC — мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.
DAC — прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL) объекта.
RBAC — ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.
АВАС — атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC, с некоторыми нюансами (шикарный обзор от CUSTIS).
Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.
Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:
| Требование от бизнеса | Решение | |
|---|---|---|
| 1 | Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе | Тут напрашивается ACL, поскольку определить отношение пользователя к бизнес-процессу достаточно сложно, не записывая его в какой-то список в момент вовлечения. Это будет оптимальным решением с точки зрения производительности чтения относительно реализации с помощью политик. |
| 2 | Автор договора должен видеть его на всех этапах | Требование может быть реализовано обоими механизмами, но оптимальным я считаю ACL, поскольку в этом случае будет проще реализовать требование №3 от ИБ. |
| 3 | Создавать договор имеет право пользователь с грейдом не ниже 10 | Это политика (PBAC), без вариантов |
| 4 | Визирующий должен видеть договор начиная с поступления к нему на этап и далее | ACL будет оптимален |
| 5 | Руководители подразделений должны видеть договоры своих подразделений вниз по иерархии | Замечательная задача для PBAC, но его применение может снизить производительность чтения, а требования 1 и 2 от ИБ потребуют дополнительных усилий, поэтому стоит подумать над реализацией. |
| 6 | Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования | PBAC справится отлично |
| 7 | Руководство и секретариат головного офиса должны видеть документы всех филиалов | PBAC, с теми же ограничениями что и в п. 5 |
| 8 | Пользователь, создавший договор, не должен иметь права его завизировать | Это требование можно было бы закрыть с помощью PBAC, однако так делать не стоит. Это то самое место, где авторизация вступает в конфликт с бизнес-логикой, и если происходит такая ситуация, ответственность стоит отдать бизнес-логике. |
Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:
| Требование от ИБ | Решение | |
|---|---|---|
| 1 | Знать, кто имеет доступ к конкретному договору | Общий журнал для ACL и PBAC |
| 2 | Знать, кто имел доступ к конкретному договору в заданный момент времени | Общий журнал для ACL и PBAC |
| 3 | Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей | ACL |
Итого
Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований.
Мы планируем серию статей, посвященных моделям авторизации и предмету в целом. Будем рады вопросам и предложениям по темам для рассмотрения.
Авторизация
Под авторизацией (англ. authorization) подразумевается проверка, осуществляемая компьютерной системой или сайтом для идентификации пользователя перед получением им права доступа к системе или интернет-ресурсу. Авторизованный пользователь может выполнять в системе определенные действия, не доступные другим лицам. Авторизация может быть как успешной, последствием которой является разрешение пользователю войти в систему или на сайт и совершать там необходимые действия, так и такой, после которой последует отказ в предоставлении подобной возможности. Похожими по смыслу являются понятия “идентификация” и “аутентификация”, однако они всё же имеют свои отличия.
Цели использования
Авторизация применяется в компьютерных системах (Windows, Linux и т.д., настраивается пользователем, применение не является обязательным), социальных сетях, базах данных, корпоративных системах компьютеров, разнообразных сайтах для защиты системы или сайта от распространения вирусной информации, хакерских атак, взломов баз данных, атак на персональные страницы пользователей, нанесения вреда компьютерам, их программам и функциям.
Этапы
Авторизация пользователя в системе проходит поэтапно, выделяют два основных этапа авторизации:
- аутентификация и идентификация – пользователь получает возможность доступа, выполнив действия по определенному алгоритму с помощью специальной системы, применяемой на сайте или в компьютерной системе (ввод пароля, личных данных, ответ на секретный вопрос и тому подобное);
- проверяется запрос пользователя на доступ, после чего он либо отклоняется, либо одобряется системой.
Идентификация, аутентификация, авторизация: чем они различаются
Разбираемся, как приложения и сайты понимают, кто мы.
Иллюстрация: freepik / Colowgee для Skillbox Media
Мария Толчёнова
Филолог и технарь, пишет об IT так, что поймут даже новички. Коммерческий редактор, автор технических статей для vc.ru и «Хабра».
Заходя в электронную почту или банковское приложение, мы встречаемся с тремя процессами: авторизацией, аутентификацией и идентификацией. Они помогают обезопасить важную информацию, например личные данные, и деньги на счетах. Термины легко спутать, но важно понимать значение каждого.
- что такое идентификация;
- что такое аутентификация;
- что такое авторизация;
- как эти три процесса связаны друг с другом и могут ли они существовать отдельно.
Идентификация пользователя: подтверждение возможности доступа
Идентификация — это процесс, когда информационная система, например социальная сеть или интернет-магазин, определяет, существует конкретный пользователь или нет. Делает она это с помощью идентификатора.
Идентификатором может быть логин, электронная почта, номер телефона или другой признак, который есть только у одного пользователя. Идентификатор позволяет сайту или приложению отличить конкретного человека от других людей.
Принцип работы любой системы идентификации: два одинаковых идентификатора не могут существовать одновременно. Возможно, вы сталкивались с этим, когда пытались зарегистрироваться на сайте, но получали сообщение, что выбранный логин уже занят.
Аутентификация: право на вход
С идентификатором всё ясно. Но как сайт или приложение может проверить, имеет ли пользователь право войти в аккаунт? Здесь помогает аутентификация.
Аутентификация — это процесс, когда пользователь вводит ключ, например пароль или пин-код, подтверждая своё право на доступ к той или иной учётной записи и хранящейся в ней информации.
Аутентификация бывает одно-, двух- и трёхфакторной.
Однофакторная аутентификация требует подтверждения только одним способом — например, с помощью пароля. Она встречается чаще всего.
Двухфакторная аутентификация используется в системах, которые хранят важные или личные данные. Например, в банковских приложениях или в социальных сетях. При входе в соцсеть у пользователя могут попросить не только пароль, но и другую информацию — код из СМС или биометрические данные.
В системах с повышенными требованиями к безопасности — например, в банковской сфере — встречается трёхфакторная аутентификация. Третьим фактором, позволяющим подтвердить личность, могут быть электронные ключи доступа. Электронный ключ хранится на специальном USB-накопителе и подключается в момент подтверждения доступа.
Авторизация: проверка доступов и привилегий
Авторизация — это процесс присвоения учётной записи положенных ей привилегий. Давайте рассмотрим её на нашем примере с личным кабинетом образовательной платформы Skillbox.
Если авторизация прошла успешно, человек попадает в личный кабинет. Он может читать уведомления, видеть список доступных курсов, просматривать их и учиться. Права доступа к этим действиям называются привилегиями.
Другая задача авторизации — защищать систему от изменений со стороны пользователей, которые не должны влиять на её работу. Например, в компаниях часто нельзя самостоятельно установить программное обеспечение на рабочий компьютер. Прав обычного пользователя для этого не хватит. Такими привилегиями обладает только системный администратор компании, который авторизуется под своим логином и может устанавливать дополнительный софт.
Как связаны идентификация, авторизация и аутентификация
Эти три процесса обычно рассматривают вместе. Они идут последовательно — идентификация, аутентификация и авторизация. Но что будет, если убрать какой-то этап?
Идентификация без аутентификации не имеет смысла и может быть опасна для пользователей и компаний. Поэтому сочетание идентификации и авторизации в реальном мире не встречается. Без аутентификации мошенник мог бы получить доступ к личной информации, зная только идентификатор пользователя. Например, мог бы зайти в электронную почту, зная только её адрес, который легко отыскать в открытых источниках.
Аутентификация без идентификации бесполезна. Если у нас есть пароль, но мы не знаем идентификатора, то не сможем получить доступ к веб-сайту или приложению. Система просто не поймёт, как нас следует авторизовать на следующем шаге.
Сервисов без авторизации не бывает, так как функциональность, которую они предоставляют пользователю, связана с ней. Если человек смог пройти идентификацию и аутентификацию, но не может авторизоваться, то непонятно, какими правами он должен обладать. Кроме того, это может привести к проблемам с конфиденциальностью пользователей.
Представьте, что можно было бы зайти в соцсеть без авторизации и получить максимальные привилегии. Тогда любой человек смог бы просматривать личные сообщения других людей или управлять настройками профиля. Поэтому в любых сервисах с личным кабинетом есть авторизация.
Тем не менее возможен вариант авторизации без идентификации и аутентификации — например, при работе с «Google Документами». Владелец Google-диска может дать доступ к просмотру или редактированию файла или папки с данными всем, у кого есть ссылка на документ.
Если у человека есть ссылка на документ, то он сможет работать с ним без идентификации и аутентификации. Поэтому в «Google Документах» можно встретить «неопознанного енота» и других необычных пользователей.
Подводим итоги
Давайте вспомним основные понятия:
Идентификация используется для определения, существует ли конкретный пользователь в системе. Проводится, например, по номеру телефона или логину.
Аутентификация — это процесс подтверждения права на доступ с помощью ввода пароля, пин-кода, использования биометрических данных и других способов.
Авторизация определяет набор привилегий и прав, доступных конкретному пользователю. Например, открывает доступ к просмотру и отправке электронных писем.
Больше интересного про код — в нашем телеграм-канале. Подписывайтесь!