Авторизация что это простыми словами
Значение слова «авторизация»
Авторизацию не следует путать с аутентификацией: аутентификация — это процедура проверки легальности пользователя или данных, например, проверки соответствия введённого пользователем пароля к учётной записи паролю в базе данных, или проверка цифровой подписи письма по ключу шифрования, или проверка контрольной суммы файла на соответствие заявленной автором этого файла. Авторизация же производит контроль доступа легальных пользователей к ресурсам системы после успешного прохождения ими аутентификации. Зачастую процедуры аутентификации и авторизации совмещаются.
АВТОРИЗА’ЦИЯ, и, мн. нет, ж. [фр. autorisation] (книжн., право). Действие по глаг. авторизовать. Книга переведена без авторизации.
Источник: «Толковый словарь русского языка» под редакцией Д. Н. Ушакова (1935-1940); (электронная версия): Фундаментальная электронная библиотека
авториза́ция
1. комп. действие по значению гл. авторизовать, авторизоваться; процедура определения прав доступа процедурой предоставления субъекту определённых прав
Делаем Карту слов лучше вместе
Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!
Спасибо! Я стал чуточку лучше понимать мир эмоций.
Вопрос: спутать — это что-то нейтральное, положительное или отрицательное?
Что такое авторизация?
При входе посетителей на сайт, в систему банковских платежей, требуется авторизоваться. Что такое авторизация? Это процесс подтверждения прав на совершение определенных операций – управления счетом, снятия средств, изменения данных. Он необходим для обеспечения безопасности при совершении действий, для разграничения прав пользователей, для защиты от злоумышленников. Используется на сайтах, в банкоматах, пропускниках, Интернет-магазинах. Обычно пользователь должен ввести свой логин (имя) в системе и пароль (кодовое слово, набор символов). Если коды введены правильно, разрешается вход в систему и выполнение разрешенных манипуляций. Если допущена ошибка, вход в систему не производится.
Ошибка авторизации
Ошибка авторизации – неверное введение логина, пароля и других данных. При наборе кодовых слов, пользователь должен обращать внимание на правильный порядок символов, регистр, установленную раскладку клавиатуры. При ошибке авторизации система блокирует посетителя доступ к системе и может производить такие действия:
Код авторизации
Код авторизации представляет собой набор символов, которые хранятся в памяти системы и позволяют идентифицировать права пользователя. В качестве кода обычно выступают комбинации 3-12 букв, цифр, знаков, набранных в определенной последовательности. Код авторизации генерируется в процессе регистрации пользователя и впоследствии может изменяться по желанию владельца учетной записи или по требованию службы безопасности. Часто устанавливается определенное ограничение на количество изменений комбинаций в период времени. Для безопасного пользования сервисом, пользователь должен хранить набор символов в тайне.
Авторизация в личном кабинете
Авторизация в личном кабинете позволяет пользователю получить доступ к изменению настроек своей учетной записи, интерфейса взаимодействия с системой, паролей, типовых операций, на управление счетом, внесение изменений в систему. До выполнения авторизации, посетитель сайта или банковского учреждения может использовать ограниченный набор функций: просматривать общедоступную информацию, проводить транзакции, не требующие подтверждения прав доступа. Часто при авторизации в личном кабинете используют дополнительные средства безопасности – ввод капчи, подтверждение по SMS или e-mail.
Онлайн авторизация
Онлайн авторизация позволяет пользователям использовать сервисы без личного посещения финансовых учреждений, магазинов, учебных заведений. Для этого нужно войти на сайт, перейти по соответствующей ссылке или нажать на определенную кнопку, ввести данные в форму. Онлайн авторизация помогает посетителям ресурса экономить время, а организациям – делать услуги доступными широким массам, привлекать большее количество клиентов, улучшать качество обслуживания, повышать степень безопасности выполнения операций, проводить статистические исследования, ранжировать права доступа пользователей.
Авторизация недоступна
При входе в систему, пользователю может быть выдано сообщение о том, что авторизация недоступна. В этом случае посетителю следует попробовать повторно авторизоваться, выполнив все требования безопасности, выполнить восстановление забытого пароля или логина или обратиться в службу технической поддержки по телефону или e-mail. Сообщение «Авторизация недоступна», выдается посетителю сайта или пользователю сервиса в следующих случаях:
Данные авторизации
Авторизация банковской карты
Авторизация банковской дебетовой карты – это получение права на совершение транзакций с помощью «пластика», доступа к управлению счетом. Выполняется в режиме онлайн – на сайте финансового учреждения или офлайн – с помощью POS-терминала. Для авторизации необходимо ввести определенные данные: пароль, логин, PIN-код, проверочные слова, коды из SMS. При попытке получения несанкционированного доступа, подбора пароля, система безопасности может временно блокировать аккаунт пользователя. Для восстановления прав пользования сервисом, нужно обратиться в учреждение, выдавшее «пластик», лично или по телефону.
Виды режимов авторизации
Для удобства пользователей, для использования имеющейся в наличии аппаратуры и для обеспечения выполнения требований безопасности, созданы различные виды режимов авторизации. Часто используется комбинация нескольких таких режимов. Различают такие их типы:
Плюсы авторизации
Плюсы авторизации для пользователей: возможность получить доступ к большему количеству функций сервиса, управлять личными данными, повысить степень защиты своих средств, конфиденциальной информации.
Неавторизованным пользователям обычно открыт доступ к базовым сервисам, ограниченному количеству функций и к публичной информации. Плюсы авторизации для компании: идентификация клиентов и сотрудников, простое разграничение прав доступа, повышение степени безопасности и защиты конфиденциальной информации, учет и регулирование количества посетителей сервиса.
Никто (почти) не знает, что такое авторизация
За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.
Что же это такое?
Авториза́ция (англ. authorization «разрешение; уполномочивание») — предоставление определенному лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.
С точки зрения любой информационной системы это процесс принятия решения о предоставлении доступа субъекту на выполнение операции на основании каких-либо знаний о субъекте. К этому моменту субъект, как правило, уже должен быть идентифицирован (мы должны знать, кто он) и аутентифицирован (подтверждена его идентичность).
Реализация авторизации при разработке корпоративной информационной системы или продукта, ориентированного на корпоративный сектор — очень сложная и ответственная задача, которой часто уделяется недостаточное внимание на этапе проектирования и первичном этапе разработки, что в будущем ведет к «костыльной» реализации.
Проблематика
Давайте разберемся, какие требования к авторизации встречаются, и почему их крайне важно учитывать изначально при проектировании системы, а не откладывать на будущее. Источников требований к авторизации в корпоративной информационной системе, как правило, два — это бизнес и информационная безопасность. В общем случае бизнес хочет хранить секреты в тайне и предоставлять полномочия пользователям в соответствии с их функцией в бизнес-процессе, а безопасность хочет обеспечить минимальную достаточность полномочий каждому пользователю и аудировать доступ.
Возьмем для примера гипотетическую систему согласования договоров крупной компании, типовой кровавый энтерпрайз. Практически наверняка возникнут следующие требования к авторизации от бизнеса:
Итак, обозначим, почему эти требования проблемные:
Пути решения
Решить данную задачу нам помогают разработанные модели управления доступом:
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, однако так делать не стоит. Это то самое место, где авторизация вступает в конфликт с бизнес-логикой, и если происходит такая ситуация, ответственность стоит отдать бизнес-логике. |
| Требование от ИБ | Решение | |
|---|---|---|
| 1 | Знать, кто имеет доступ к конкретному договору | Общий журнал для ACL и PBAC |
| 2 | Знать, кто имел доступ к конкретному договору в заданный момент времени | Общий журнал для ACL и PBAC |
| 3 | Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей | ACL |
Итого
Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований.
Мы планируем серию статей, посвященных моделям авторизации и предмету в целом. Будем рады вопросам и предложениям по темам для рассмотрения.
Идентификация, аутентификация и авторизация — в чем разница?
Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.
Это происходит с каждым из нас, причем ежедневно: мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», когда на самом деле речь идет об аутентификации.
Ничего такого уж страшного в этом нет — пока идет бытовое общение и обе стороны диалога по контексту понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляешь, а то рано или поздно нарвешься на зануду-специалиста, который вынет всю душу за «авторизацию» вместо «аутентификации», кофе среднего рода и такое душевное, но неуместное в серьезной беседе слово «ихний».
Идентификация, аутентификация и авторизация: серьезные определения
Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:
Объясняем идентификацию, аутентификацию и авторизацию на енотах
Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации — это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и тем более аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны вообще кому угодно. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный енот. Несмотря на то, что енот совершенно неопознанный, система его все же авторизовала — то есть выдала право прочитать этот документ.
А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.
А уж если речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного енота на чтение вашей переписки — если, конечно, он не идентифицируется с вашим логином и не аутентифицируется с вашим паролем. Но тогда это уже не будет неопознанный енот, поскольку Google однозначно определит этого енота как вас.
Теперь вы знаете, чем идентификация отличается от аутентификации и авторизации. Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать. Поэтому:
Авторизация
Авторизация — процесс предоставления пользователю или группе пользователей определенных разрешений, прав доступа и привилегий в компьютерной системе.
Разница между авторизацией, аутентификацией и идентификацией
Авторизацию не следует путать с идентификацией и аутентификацией пользователя. Она происходит по завершении этих процессов.
Допустим, пользователь хочет получить доступ к определенному документу в корпоративном облаке. Сначала он вводит логин от своего аккаунта, и система проверяет, есть ли такой логин в ее базе данных. Это идентификация.
Если логин существует, система запросит у пользователя пароль, вычислит для него хеш и проверит, совпадает ли он с хешем в базе данных. Это аутентификация.
Если логин и пароль верные, система проверит, имеет ли этот пользователь право читать и изменять запрашиваемый документ, и в случае успеха предоставит ему доступ к файлу. Это авторизация.
Некоторые сервисы спрашивают логин и пароль одновременно, однако они все равно сначала идентифицируют пользователя, а потом, если он успешно прошел проверку, переходят к аутентификации. Для пользователя момент перехода от идентификации к аутентификации в этом случае незаметен.
Авторизация возможна и без идентификации (и аутентификации). Например, сервис может предусматривать, что пользователи, которые не ввели логин и пароль, по умолчанию получают какой-то набор прав — скажем, на чтение документов без возможности правки.
Виды авторизации
Существует несколько моделей авторизации. Три основные — ролевая, избирательная и мандатная.
Например, пользователь А, создав текстовый файл, может назначить пользователю Б права на чтение этого файла, а пользователю В — права на его чтение и изменение. При этом пользователи Б и В могут передать свои права пользователю Г.
Мандатная модель авторизации применяется в системах, ориентированных на безопасность, и чаще всего она используется для организации доступа к гостайне и в силовых ведомствах.
Например, в организации может быть пять уровней доступа. Пользователь, имеющий доступ к файлам 3-го уровня, может также открывать файлы 1-го и 2-го уровня, но не может работать с файлами 4-го и 5-го уровня.
Публикации на схожие темы
Идентификация, аутентификация и авторизация — в чем разница?
Береги ДНК смолоду!
У мошенников тоже могут быть права
Платформа WordPress подверглась масштабной брут-форс атаке