Авторизацию и аутентификацию легко спутать, но это разные вещи. Их нужно различать и понимать, как использовать, чтобы обезопасить свои данные или данные пользователей.
Аутентификация — это проверка, что вы действительно тот человек, за которого себя выдаёте.
Вот простой пример из жизни: представьте, что вам написал друг и попросил занять денег до понедельника. Чтобы убедиться, что это не мошенник, вы проводите аутентификацию — звоните приятелю. И если ваш друг подтвердит, что это ему нужны деньги, он пройдёт проверку.
Авторизация — это получение права доступа к чему-то. Например, ваш друг получит доступ к деньгам и потратит их.
Идентификация, аутентификация и авторизация в IT
На самом деле в цепочке проверки есть ещё один пункт — идентификация, то есть распознавание пользователя по его идентификатору. Она помогает понять, для какого субъекта будет выполняться проверка.
Допустим, вы хотите открыть свою страницу в соцсетях. Сначала вводите логин — система опознаёт, что вы пытаетесь войти под именем BossKeks. Это идентификация. Затем вам нужно доказать, что вы тот, за кого себя выдаёте. Для этого вы вводите пароль и нажимаете кнопку «Отправить». Выполняется аутентификация: ваши данные сверяются с паролем, который хранится на сервере.
Значение слова авторизация. Что такое авторизация.
Если всё совпадёт, выполнится авторизация. Вы получите доступ к своему аккаунту и сможете отправлять сообщения, загружать фото или писать комментарии к постам.
Дополнительные проверки при аутентификации
От способа аутентификации зависит, насколько защищены данные пользователей. Самый простой способ защиты — традиционная или однофакторная аутентификация, когда вы проходите одну проверку. Например, вы можете ввести пароль, чтобы попасть в личный кабинет в интернет-магазине. По биометрии, отпечатку пальца или Face ID, разблокируете смартфон.
Используя аппаратный ключ безопасности (ключ U2F), зайдёте в менеджер паролей или на другой сервис. А по разовому коду сможете войти в Телеграм, если не включите дополнительную защиту аккаунта.
У однофакторной аутентификации есть недостаток: злоумышленники могут взломать или украсть пароли, поэтому лучше использовать двухфакторную. Например, вы можете на Госуслугах после ввода пароля запрашивать код из смс. Двухфакторная аутентификация безопаснее — используйте её и в разработке, и при личном использовании веб-сайтов или приложений.
Итоги
Авторизация и аутентификация — два разных процесса. Аутентификация нужна, чтобы проверить право доступа к данным, авторизация — это когда вы получаете доступ.
Начинается проверка всегда с идентификации, за ней идёт аутентификация и в конце авторизация. Эти процессы защищают ваши персональные данные и деньги. Поэтому подходите к проверке ответственно, чтобы ваши данные не оказались в руках злоумышленников.
☝ Научиться писать безопасный код и защищать сайт от атак можно на курсе «Протоколы и сети».
Как пройти авторизацию аккаунта в программе Quick sender Ultra. Что такое авторизация аккаунта?
Материалы по теме
- Как защитить приложение от хакеров
- Основные протоколы передачи данных
- Как работает HTTP
Источник: htmlacademy.ru
Авторизация. Определение и методы
Современные системы информационной безопасности держатся на «трёх китах» – аутентификации, идентификации и авторизации. Хотя скрывающиеся за этими терминами процессы тесно взаимосвязаны, путать между собой их не следует.
Идентификация представляет собой этап, на котором система проверяет, есть ли в базе данных реквизиты пользователя, пытающегося получить доступ к её ресурсам. Этап защиты информации, где рассматривается подлинность личности пользователя, называется аутентификацией. Узнать больше об аутентификации и её методах вы можете из нашей предыдущей статьи.
Авторизация. Суть процесса
Авторизация завершает процесс предоставления пользователю защищённого доступа к чувствительным данным. Если пользователь успешно прошёл аутентификацию, то на этом этапе система проверяет его права на чтение и изменение запрашиваемых данных. Если всё в порядке – доступ он получает.
Поясним на примере. Пользователь зарегистрировался в личном кабинет маркетплейса и получил на электронную почту реквизиты для входа (логин и пароль), и ссылку для подтверждения регистрации. Когда в форму входа на сайте он подставит свои реквизиты, то система автоматически проведет его по всем трем этапам и предоставит возможность пользоваться личным кабинетом.
Веб-сайт, онлайн-магазин, видеохостинг, электронная почта, информационные и развлекательные порталы — всюду, где есть необходимость персонализированного использования информации , вы сталкиваетесь со средствами авторизации.
Виды авторизации
В зависимости от доступного аппаратного обеспечения, методов взаимодействия с пользователями и набором требований безопасности были разработаны различные виды систем авторизации. Они могут отличаться:
- методом разграничения прав (на основе ролей, мандатное, избирательное);
- способом доступа (онлайн/офлайн);
- количеством проверок (одно- или многоступенчатые).
Как правило, системы авторизации с использованием разных методов разграничения прав используются чаще остальных. Но могут встречаться и комбинированные модели.
Авторизация на основе ролей применяется в операционных системах или программах, где администратор назначает пользователям роли, согласно которым определяет полномочия и привилегии. Подобный подход использует наше фронтальное приложение для бизнеса, входящее в «Адаптер для СБП» — в нем администратор может назначать роли операторов и продавцов на торговой точке. Например, один пользователь может просматривать историю операций торгово-сервисного предприятия (ТСП) и искать нужную транзакцию, а другой — осуществлять возврат платежа или генерировать QR-код для оплаты.
В мандатной модели авторизации администратор определяет свой уровень конфиденциальности для каждого элемента системы. Для этой модели характерна иерархическая структура, в которой каждый уровень доступа определяет свой набор полномочий и объектов, с которым пользователи могут работать. Чаще всего пользователь с более высоким уровнем доступа может работать и с младшими уровнями тоже. Подобная модель авторизации нередко встречается в приложениях корпоративной сети.
В авторизации избирательного вида пользователю назначаются права доступа к конкретному объекту. Правом изменять уровень доступа обладает владелец объекта, он же может наделять правами других пользователей — а те, в свою очередь, оставляют за собой возможность передавать назначенные им права другим. На практике реализацию избирательной модели авторизации можно увидеть на Google-диске: при работе с документом его владелец (создатель) имеет полномочия назначать другим пользователям разные права — только просматривать файл, комментировать или редактировать его.
Основные преимущества авторизации
Преимущества для владельцев
Для владельцев системы (веб-сайтов, сервисов, приложений и проч.) ключевым преимуществом применения авторизации можно считать общее повышение степени безопасности и защиты конфиденциальности чувствительной информации — как внутренней, так и пользовательской. Это повышает уровень клиентского доверия и помогает сделать администрирование системы проще и дешевле.
К другим плюсам относятся:
- возможность блокировать спам-запросы;
- возможность собирать аналитическую информацию о клиентах и пользовательских сессиях — эти данные помогают бизнесу точнее сегментировать свою целевую аудиторию и укрепить каналы взаимодействия с ней;
- возможность тонко настраивать права на использование того или иного контента.
Преимущества для пользователей
В современной парадигме использования интернета прошедший авторизацию пользователь, как правило, получает доступ к более широкому массиву информации, сервисов и функций. Авторизованный пользователь предоставляет информацию об опыте взаимодействия с сайтом или приложением владельцу, благодаря чему последний может перестроить или оптимизировать свой продукт, чтобы впоследствии улучшить клиентский опыт.
К другим плюсам относятся:
- возможность настраивать личную информацию для получения пользователем персонально ориентированных услуг — например, указать номер телефона или ссылки в социальной сети для быстрой коммуникации бизнеса с ним;
- возможность пользоваться ресурсами, с меньшим количеством рекламы или ограниченным функционалом;
- возможность связать между собой учетные записи на нескольких площадках и проходить сквозную авторизацию единожды — например, в сторонних веб-сервисах через профиль социальной сети.
Источник: ekassir.com
Никто (почти) не знает, что такое авторизация
За время работы архитектором в проектах внедрения 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) стоят на костылях благодаря сложности требований.