Чем отличается аутентификация от авторизации

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

Определение

Аутентификация – прохождение проверки подлинности.

Авторизация – предоставление и проверка прав на совершение каких-либо действий в системе.

Естественно, и аутентификацию, и авторизацию используют не только в процессе получения доступа к сетевым аккаунтам. Автоматизированные системы, EDI, передача данных, пластиковые банковские карты – мы не один раз в день проходим эти процедуры в автоматическом режиме.

В англоязычных системах путаницы с терминологией не возникает: пользователь вообще не задумывается, чем отличается аутентификация от авторизации, ведь обе процедуры от его глаз скрыты. Предлагается «войти в систему» – «log in, logging in».

к содержанию ↑

Сравнение

Как проходит процедура аутентификации? Вот некий пользователь вознамерился прочитать свежий спам в своем электронном почтовом ящике. Он заходит на сайт почтового сервиса, читает рекламу и новости, но никаких писем ему пока не показывают – система не знает ни о его личности, ни о его намерениях. Когда в форму ввода логина и пароля он впишет свои «username/qwerty» и отправит эту информацию, начнется процесс аутентификации. Система проверит, существует ли пользователь с таким именем, совпадает ли введенный пароль с его учетной записью. Во многих случаях соответствия подобных идентификаторов достаточно, однако сервисы, где безопасность данных в приоритете, могут запрашивать и другие сведения: наличие сертификата, определенный IP-адрес или дополнительный код верификации.

Пройденная аутентификация означает, что пользователь действительно тот, кем представляется. Однако этого мало для предоставления ему доступа к данным – начинается процесс авторизации. В случае с почтовыми сервисами клиенты имеют равные права: каждый из них может просматривать письма и документы, редактировать их и создавать новые. А вот в социальных сетях или на форумах посетители принадлежат к определенной группе, и авторизация помогает системе определить, что позволено Юпитеру и не позволено быку. К примеру, у вас нет права писать сообщения пользователю, который добавил вас в черный список; вы не можете добавлять в сообщения ссылки на видео, пока не набрали определенное количество постов; вы можете просматривать фотографии человека, добавившего вас «в друзья». В локальных системах у учетной записи пользователя может не быть доступа к некоторым программам, стоять запрет на редактирование или копирование документов.

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

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

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

к содержанию ↑

Таблица

Аутентификация	Авторизация
Процедура проверки подлинности субъекта	Процедура присвоения и проверки прав на совершение определенных действий субъектом
Зависит от предоставляемой пользователем информации	Не зависит от действий клиента
Запускается один раз для текущей сессии	Происходит при попытке совершения любых действий пользователем

thedifference.ru

Авторизация и аутентификация – в чём отличие [+ВИДЕО]

Уверен, что Вы, как и большинство пользователей, смутно себе представляете, что такое авторизация и аутентификация, часто путаете эти понятия. В этой статье решил попытаться объяснить (разжевать) эти цифровые сущности.

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

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

Основные определения

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

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

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

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

Читайте также на сайте:

…

…

Принцип работы

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

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

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

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

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

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

Основные отличия терминов

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

…

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

Что же касается авторизации, то она характеризуется следующими особенностями:

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

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

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

ПОЛЕЗНОЕ ВИДЕО

…

Рекомендую ещё посмотреть обзоры…

Я только обозреваю программы! Любые претензии — к их производителям!

Ссылки в комментариях публикуются после модерации.

^Наверх^

optimakomp.ru

Авторизация и аутентификация – разница определений

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

СОДЕРЖАНИЕ СТАТЬИ:

Какие уровни входа и ввода сведений существуют

Условно данный процесс делится на два уровня:

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

Довольно часто вместо этих терминов используются упрощенные термины – авторизация и проверка подлинности.

Данный процесс достаточно простой, его можно рассмотреть на примере одной из соцсетей:

• Регистрация – юзер вписывает свой email, телефонный номер, код. Это уникальные сведения, их нельзя дублировать в системе, поэтому нельзя зарегистрировать больше одной учетной записи на пользователя;
• Идентификация – вы вписываете указанные в процессе регистрации данные, в нашем случае это электронка и пароль;
• Аутентификация – когда вы нажимаете клавишу «вход», страничка связывается с сервером и выполняет сканирование наличия этой комбинаций пароля и логина. Если все введено корректно, будет открыта страничка соцсети.

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

---

Авторизация и аутентификация: разница и типы

Есть несколько типов определения подлинности, различающихся по уровню защиты и использованию:

• Защита с паролем. Юзер знает ключ, неизвестный никому. Сюда же относится идентификация через получение SMS;
• Привлечение предметов. Привлекают компании и фирмы. То есть тут используются карточки, брелки, флешки и прочее;
• Биометрическая проверка. Проверяется глазная сетчатка, голос, отпечатки пальцев. Это практически самая мощная системная защита;
• Скрытые данные. Чаще всего привлекается для защиты ПО. Проверяется кэш обозревателя, местоположение, которое установлено на компьютер.

Пароли

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

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

---

Специальные предметы

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

---

Биометрические системы

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

---

Отличие авторизации от аутентификации

Аутентификация означает, что юзер на самом деле тот, кем он представлялся. Вот только этого будет недостаточно, поэтому активируется авторизация.

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

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

Это может быть так же интересным:

life-v.ru

В чем разница между аутентификацией на основе OAuth и Token? — authentication

Это хороший вопрос — есть много путаницы вокруг токенов и OAuth.

Прежде всего, когда вы упоминаете OAuth, вы, вероятно, ссылаетесь на стандарт OAuth3. Это последняя версия протокола OAuth, и это то, о чем говорит большинство людей, когда говорят «OAuth».

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

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

Вместо того, чтобы ваш пользователь отправлял свои фактические учетные данные на ваш сервер по каждому отдельному запросу (например, с помощью Basic Auth, где пользователь отправляет свое имя пользователя/пароль на сервер для каждого запроса), с OAuth вы сначала обмениваете своего пользователя учетные данные для «токена», а затем аутентифицировать пользователей на основе этого «токена».

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

Теперь, где вводятся токены: спецификация OAuth построена вокруг концепции жетонов, но НЕ УКАЗАНА, ЧТО ТОКЕН.

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

Люди поняли это и разработали новый стандарт для создания токенов, называемый JSON Web Token standard. Этот стандарт в основном предоставляет набор правил для создания токенов очень определенным образом, что делает маркеры более полезными для вас в целом.

JWT позволяют делать такие вещи, как:

• Криптографически подписывать токен, чтобы вы знали, что токен не был подделан пользователем.
• Шифровать токены, чтобы содержимое не могло быть прочитано простым текстом.
• Вставить данные JSON INSIDE в символическую строку стандартным образом.

Теперь, по большей части: почти все в сообществе разработчиков согласны с тем, что если вы используете какой-либо OAuth, то маркеры, которые вы используете, должны быть JSON Web Tokens.

==========

OK! Теперь, когда мы рассмотрели предысторию, позвольте мне ответить на ваш вопрос.

Выбор, который вы делаете выше, заключается в том, хотите ли вы включить полную спецификацию OAuth3 для аутентификации/авторизации (что довольно сложно) или вам просто нужна базовая «токен-аутентификация».

Поскольку протокол OAuth предоставляет несколько разных способов аутентификации в режиме STANDARDS COMPLIANT, он добавляет большую сложность большинству систем аутентификации.

Из-за этого многие фреймворки предлагают «отключенную» версию потока паролей OAuth3, которая по сути является простым методом, где:

• Пользователь отправляет свое имя пользователя/пароль на ваш сервер по определенному URL-адресу, например /login.
• Ваш сервер генерирует токен JWT для пользователя.
• Сервер возвращает этот токен пользователю.
• Пользователь сохраняет этот токен в своих файлах cookie, мобильном устройстве или возможном сервере API, где они используют его для выполнения запросов.

Опять же: поток выше НЕ соответствует требованиям OAuth, но это немного более простая версия, в которой STILL использует токены.

Основной смысл здесь в том, что токены (JWT), как правило, полезны и не нуждают

qaru.site

Так что же будет с аутентификацией и паролями? Вторая часть отчета Javelin «Состояние строгой аутентификации»

Недавно исследовательская компания «Javelin Strategy & Research» опубликовала отчёт «The State of Strong Authentication 2019». Его создатели собрали информацию о том какие способы аутентификации используются в корпоративной среде и пользовательских приложениях, а также сделали любопытные выводы о будущем строгой аутентификации.

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

От переводчика

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

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

Пользовательская аутентификация

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

В целом, процент компаний, использующих строгую аутентификацию в своем бизнесе увеличилось втрое с 5% в 2017 до 16% в 2018 (рисунок 3).

Возможности по использованию строгой аутентификации для web-приложений до сих пор ограничены (

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

Аппаратные криптографические ключи (тут имеются в виду только соответствующие стандартам FIDO), такие как предлагаемые Google, Feitian, One Span, и Yubico могут быть использованы для строгой аутентификации без установки дополнительного ПО на стационарных компьютерах и ноутбуках (потому что большинство браузеров уже поддерживает стандарт WebAuthn от FIDO), но только 3% компаний использует эту возможность для логина своих пользователей.

Сравнение криптографических токенов (вроде Рутокен ЭЦП PKI) и секретных ключей, работающих по стандартам FIDO, выходит не только за рамки данного отчета, но и моих комментариев к нему. Если совсем, кратко, то оба вида токенов используют сходные алгоритмы и принципы работы. Токены FIDO на данный момент лучше поддерживаются производителями браузеров, правда ситуация скоро изменится по мере того, как все больше браузеров будут поддерживать Web USB API. Зато классические криптографические токены защищены PIN-кодом, могут подписывать электронные документы и использоваться для двухфакторной аутентификации в Windows (любой версии), Linux и Mac OS X, имеют API для различных языков программирования, позволяющие реализовать 2ФА и ЭП в настольных, мобильных и Web приложениях, а токены произведенные в России поддерживают российские алгоритмы ГОСТ. В любом случае, криптографический токен, вне зависимости от того, по какому стандарту он создан, является наиболее надежным и удобным методом аутентификации.

Помимо безопасности: другие преимущества строгой аутентификации

Неудивительно, что применение строгой аутентификации тесно связано с важностью данных, хранимых бизнесом. С наибольшим юридическим и нормативным давлением сталкиваются компании, которые хранят конфиденциальную личную информацию (Personally Identifiable Information — PII), такую как номера социального страхования или личную медицинскую информацию (Personal Health Information — PHI). Именно такие компании являются наиболее агрессивными приверженцами строгой аутентификации. Давление на бизнес усиливается ожиданиями клиентов, которые хотят знать, что организациях, которым они доверяют свои наиболее конфиденциальные данные используют надежные методы аутентификации. Организации, которые обрабатывают чувствительный PII или PHI, более чем в два раза чаще используют строгую аутентификацию, чем организации, которые хранят только контактную информацию пользователей (рисунок 7).

К сожалению, компании пока не хотят внедрять надежные методы аутентификации. Почти треть лиц, принимающих бизнес-решения, считают пароли наиболее эффективным из методов аутентификации, среди всех перечисленных на рисунке 9, а 43% считают пароли самым простым методом аутентификации.

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

Не будем трогать пароли. Но во что же надо верить, чтобы считать, что контрольные вопросы более безопасны, чем криптографические токены?? Эффективность контрольных вопросов, которые элементарно подбираются оценили в 15%, а не взламываемых токенов – всего в 10. Хотя бы фильм «Иллюзия обмана» посмотрели бы, там хоть и в аллегорической форме, но показано как легко фокусники выманили у бизнесмена-афериста все необходимые ответы и оставили его без денег.

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

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

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

Корпоративная аутентификация

С 2017 года внедрение строгой аутентификации на предприятиях растет, но немного скромнее, чем для потребительских приложений. Доля предприятий, использующих строгую аутентификацию увеличилась с 7% в 2017 до 12% в 2018. В отличие от пользовательских приложений, в корпоративной среде использование не-парольных методов аутентификации несколько более распространено в web-приложениях, чем на мобильных устройствах. Около половины предприятий сообщают об использовании только имен пользователей и паролей для аутентификации своих пользователей при входе в систему, причем каждый пятый (22%) также полагается исключительно на пароли для вторичной аутентификации при доступе к особо важных данным (то есть пользователь вначале логинится в приложение, используя более простой способ аутентификации, а если захочет поучить доступ к критичным данным, то выполнит еще одну процедуру аутентификации, на этот раз обычно используя более надежный метод).

Нужно понимать, что в отчёте не учтено использование криптографических токенов для двухфакторной аутентификации в операционных системах Windows, Linux и Mac OS X. А это на текущий момент – самое массовое использование 2ФА. (Увы, но токены созданные по стандартам FIDO умеют реализовывать 2ФА только для Windows 10).

Причем, если для внедрения 2ФА в онлайн и мобильные приложения необходим комплекс мероприятий, включающий в себя доработку этих приложений, то для внедрения 2ФА в Windows необходимо всего лишь настроить PKI (например, на базе Microsoft Certification Server) и политики аутентификации в AD.

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

Следующими двумя наиболее распространенными методами аутентификации пользователей при входе в систему являются одноразовые пароли, предоставляемые через отдельное приложение (13% предприятий), и одноразовые пароли, доставляемые с помощью SMS (12%). Несмотря на то, что процент использования обоих методов весьма схож, но OTP SMS чаще всего используется для повышения уровня авторизации (в 24% компаний). (Рисунок 12).

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

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

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

Поэтому единственным работающим методом 2ФА в мобильных устройствах является использование криптографических токенов, которые подключаются к смартфону по интерфейсам NFC, Bluetooth и USB Type-C.

Защита финансовых данных компании является главной причиной инвестиций в беспарольную аутентификацию (44%) с самым быстрым ростом с 2017 года (увеличение на восемь процентных пунктов). Далее следует защита интеллектуальной собственности (40%) и кадровых (HR) данных (39%). И понятно почему — мало того, что ценность, связанная с этими типами данных, широко признается, так с ними еще и работает сравнительно небольшое количество сотрудников. То есть затраты на внедрение не такие большие, да и научить работать с более сложной системой аутентификации нужно всего несколько человек. Напротив, типы данных и устройства, к которым обычно обращаются большинство сотрудников предприятия, по-прежнему защищены исключительно паролями. Документы сотрудников, рабочие станции и корпоративные порталы электронной почты являются областями наибольшего риска, поскольку только четверть предприятий защищают эти активы с помощью беспарольной аутентификации (Рисунок 14).

Вообще, корпоративная электронная почта – весьма опасная и «дырявая» штука, степень потенциальной опасности которой недооценена большинством ИТ-директоров. Ежедневно сотрудники получают десятки писем, так почему бы среди них не оказаться хотя бы одному фишинговому (то есть мошенническому). Это письмо будет оформлено в стиле писем компании, поэтому сотрудник без опасения нажмет на ссылку в этом письме. Ну а дальше может быть что угодно, например, загрузка вируса на атакуемую машину или слив паролей (в том числе методом социального инжиниринга, через ввод в созданную злоумышленником фальшивую форму аутентификации).

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

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

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

Есть у строгой аутентификации и еще одно преимущество. Поскольку пароль больше не используется (заменен на простой PIN-код), то нет и запросов от сотрудников с просьбой поменять забытый пароль. Что в свою очередь снижает нагрузку на ИТ-департамент предприятия.

Итоги и выводы

1. Руководители зачастую не обладают необходимыми знаниями, позволяющими оценить реальную эффективность различных вариантов аутентификации. Они привыкли доверять таким устаревшим способам защиты как пароли и секретные вопросы просто потому, что «раньше это работало».
2. Пользователи этими знаниями обладают еще в меньшей степени, для них главное – простота и удобство. Пока у них нет побудительных мотивов выбирать более защищенные решения.
3. У разработчиков пользовательских приложений зачастую нет причин, чтобы внедрять двухфакторную аутентификацию взамен парольной. Конкуренция по уровню защиты в пользовательских приложениях отсутствует.
4. Вся ответственность за взлом переложена на пользователя. Назвал одноразовый пароль злоумышленнику – виноват. Твой пароль перехватили или подсмотрели – виноват. Не потребовал от разработчика использовать в продукте надежные методы аутентификации – виноват.
5. Правильный регулятор в первую очередь должен требовать от компаний внедрения решений, которые блокируют утечки данных (в частности двухфакторная аутентификация), а не наказывать за уже произошедшую утечку данных.
6. Некоторые разработчики ПО пытаются продать потребителям старые и не особенно надежные решения в красивой упаковке «инновационного» продукта. Например, аутентификация, путем привязки к конкретному смартфону или использование биометрии. Как видно из отчета, по настоящему надежным может быть только решение на основе строгой аутентификации, то есть криптографических токенов.
7. Один и тот же криптографический токен можно использовать для целого ряда задач: для строгой аутентификации в операционной системе предприятия, в корпоративном и пользовательском приложении, для электронной подписи финансовых транзакций (важно для банковских приложений), документов и электронной почты.

habr.com

многофакторная аутентификация на базе SafeNet Authentication Service / DataLine corporate blog / Habr

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

Сегодня я расскажу про другие способы многофакторной аутентификации и задачи, которые они помогают решить компании. Рассказывать буду на примере решения Gemalto Safenet Authentication Service (SAS), которое существует в формате облачного сервиса и on-premise версии, сертифицированной ФСТЭК.

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

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

Обычно внутри компании многофакторную аутентификацию используют для защиты от несанкционированного доступа VDI, web-порталы (OWA, разные ServiceDesk, Confluence, Microsoft IIS), VPN, облачные приложения (Office 365, Salesforce).

Ниже приведу несколько примеров того, какие задачи можно решить с помощью SafeNet Authentication Service.

Задача: соблюдение стандарта PCI DSS
Многофакторная аутентификация – одно из требований стандарта PCI DSS (п. 8.3.). Более того, стандарт требует, чтобы многофакторная аутентификация была одноэтапной: пароль и второй фактор должны вводиться в одном поле. Если злоумышленник попробует завладеть учеткой и ошибется при вводе, ему будет непонятно, где была допущена ошибка – в пароле или токене.

Решение: одноэтапная многофакторная аутентификация по схеме PIN + OTP
Такая схема аутентификации на базе SafeNet реализована в нашей IaaS-платформе, соответствующей требованиям PCI DSS и 152-ФЗ, – Cloud-152. Ее проходят администраторы платформы Cloud-152 для доступа к management-сегменту. Для авторизации нужно ввести в одном поле PIN и OTP, который приходит push-уведомлением в мобильном приложении Mobile Pass.

Так выглядит авторизация для администраторов Cloud-152 со стороны DataLine.

*Здесь должен был быть скриншот с SafeNet Mobile Pass, но приложение блокирует скриншоты.

Задача: двухфакторная аутентификация для сотрудников без смартфона и мобильного интернета
Компания собирается внедрять двухфакторную аутентификацию для входа на рабочие станции. У компании распределенная сеть офисов по всей России, у многих сотрудников нестабильный мобильный интернет или вообще нет смартфона. Получается, что Push-уведомления от мобильных приложений в качестве второго фактора не подойдут. СМС и физические токены отпадают из-за дороговизны.

Решение: использование в качестве второго фактора GrIDSure
GrIDSure – это одноразовый пароль (OTP). Он состоит из таблицы с символами и паттерна, который пользователь сам задает при настройке аутентификации. Для авторизации пользователь выбирает символы из таблицы по этому паттерну и вводит в качестве второго фактора.

Таблица с символами, которую пользователь получает при авторизации на рабочие станции.

Дальше пользователь просто следует выбранному паттерну. Например, вот такому.

В качестве символов можно использовать цифры, буквы и спецсимволы. Размер таблицы настраивается: это может быть таблица 5 на 5 или больше.

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

С Gridsure также не нужно мобильное приложение, и следовательно, смартфон с мобильным интернетом. GrIDSure отображается в том же интерфейсе и устройстве, что и защищаемый сервис.

Задача: защита веб-сервиса от атаки методом перебора
Многофакторную аутентификацию на базе SafeNet можно использовать для защиты веб-сервисов, опубликованных в интернете, например, Outlook Web App (OWA). Safenet поддерживает RADIUS и SAML-протоколы, поэтому легко интегрируется с сервисами Microsoft Outlook, Office 365, Saleforce, Dropbox, Apache и т.д.

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

Решение: использование OTP в качестве второго фактора
Тут можно использовать GrIDSure или Mobile Pass в качестве второго фактора.

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

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

Решение: использование портала самообслуживания
В SafeNet есть портал самообслуживания, который поможет автоматизировать рутинные операции и снизить нагрузку на администраторов.

На портале самообслуживания пользователь может оставить всю информацию, необходимую для выпуска токена. Администратору остается только подтвердить ее и отправить ссылку на формирование токена. Если пользователь забыл, какую траекторию выбрал для GrIDSure, то опять-таки самостоятельно может сбросить ее здесь и задать новую.

Задач: Регламентирование доступа к рабочим станциям
В call-центре работают 200 сотрудников посменно. Для экономии ресурсов на двух сотрудников приходится одна рабочая станция. Нужно настроить доступы так, чтобы не было конкурентных сессий.

Решение: внедрение входа по токенам и политики доступа
SafeNet можно установить на каждую рабочую станцию и через него задать политики доступа по времени и IP-адресам. Если смена сотрудника еще не началась, то он не сможет зайти на свою рабочую станцию. Администратор сможет проследить, когда тот или иной сотрудник заходил в систему и с какого IP-адреса в журнале.

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

habr.com

Аутентификация и авторизация в микросервисных приложениях [Часть 1]

Доброго времени суток, codeby.

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

В качестве приложения для примера — выбраны микросервисы, из моей статьи о docker. Читателю также предлагается ознакомиться с ними самостоятельно. Стоит сказать, что приложение было модифицировано. Фронтенд вынесен в контейнер с ngnix, о чём я также расскажу во второй части, apigetway мы перепишем в рамках второй части.

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

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

Как раз в этом месте и начинается творчество. Проблема заключается в том, что ответы на приведённые вопросы сильно различаются. Нельзя не заметить, что различия коррелируют с особенностью рассматриваемой системы — ответы, которые правильны для системы А будут в корне не верны для системы Б и так далее.

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

Словарь

Рассуждая теоретически, очень важно говорить на одном языке, поэтому давайте для начала определимся с некоторыми моментами.
Задача аутентификации — убедиться, что пользователь — тот за кого себя выдаёт.
Задача авторизации — убедиться, что пользователь имеет право делать то или иное действие в системе.
Данные бывают передаваемыми и хранимыми. Передаваемые данные — это данные которые “гуляют” от микросервиса до микросервиса. Хранимые — это данные которые хранятся в базах данных микросервисов.
Область действия — идентификатор для группы ресурсов, которые необходимо защитить. Например, все конечные точки способные изменить местоположение Пети, должны входить в группу location_information_write. Этакие наименования прав.
Маркер доступа — подписанный объект, используемый для предоставления доступа к микросервисам. Микросервис может запросить маркер доступа к любой области действий, если доступ разрешен — микросервис начинает взаимодействовать с разрешенной зоной.
OAuth и OpenId Connect — мы будем использовать эти протоколы для аутентификации и авторизации, реализацию возьмём из IdentityServer.

Аутентификация

Разобравшись с понятиями давайте приступим к размышлениям. Напомни, что раньше мы использовали архитектуру frontend for backend, где в качестве бэкэнда мы использовали микросервисы. Тогда каждый фрагмент фронтенда либо прорисовывался, либо нет — в зависимости от того был ли запущен сервис. Сейчас же давайте изменим архитектуру на нечто такое:

Что произошло: я вынес фронтенд часть на волю ngnix, действительно, нет особой необходимости иметь целый .net core проект, который существует лишь для того, чтобы рендерить заглавную страницу сайта, ngnix легковесней, дешевле и быстрее, этого вполне достаточно чтобы сделать выбор в его пользу. Появилось бизнесс-требование, которое гласит: “Необходимо дать пользователю возможность предустанавливать свою страну и город, для корректного вывода погоды и курса валют”. Вот у нас и появился функционал, который должен быть разграничен пользовательским контекстом. Так для Пети из Москвы погода и курс рубля к доллару будет отличаться от Тараса из Харькова (курс валюты для Тараса будет представлен как гривна к доллару).
Появился микросервис Login, в рамках которого и строится дальнейшее проектирование, предполагается что микросервис логин будет аутентифицировать пользователей, так как только Петя может менять свои настройки, ну суть ясна я думаю.

Взглянем ещё раз на новую архитектуру. Микросервис Login отвечает за вход Тараса и Пети в систему, однако за запросы Пети и Тараса всё ещё отвечает API Gateway (вернее он вообще отвечает за то что запросы могут выполнять только вошедшие в систему пользователи). Следовательно микросервис API Gateway должен знать аутентифицирован ли пользователь отправивший запрос или нет.

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

• логин и пароль
• google auth

Вне зависимости от способа входа, микросервис Login должен предоставлять подтверждение API Gateway того, что пользователь аутентифицирован, в таком виде в котором API Gateway предоставляет возможность проверить подлинность. Для этого существуют различные протоколы, в данном случае мы будем использовать OpenId Connect.

Хочу обратить ваше внимание, что аутентификация пользователя происходит на периферии системы, т.е. она проводится микросервисом, получившем запрос непосредственно от пользователя (через промежуточное ПО перенаправления). Это хорошо зарекомендовавший себя принцип разработки систем безопасности для микросервисов: аутентификация пользователя происходит на периферии системы.

Авторизация пользователей

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

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

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

Доверие микросервисов друг к другу

Поговорим о моменте, который нередко (разумеется во вред) упускается из вида. Смоделируем ситуацию атаки, допустим злоумышленник смог завладеть микросервисом валют и собирается отправить от его имени запрос на изменение логина и пароля Тараса на микросервис Login. В сценарии, где микросервисы доверяют друг другу и ничем не ограничены — мы, как blue team, потерпели сокрушительное фиаско. Однако, если голова нам дана “не чтоб шапку носить” и мы ограничили доступ к микросервису Login (разумно, чтоб его мог вызывать только Api Gateway, так как он находится на периферии) то всё будет хорошо.

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

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

Google OAuth

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

Давайте взглянем на картинку:

Процесс описан сверху вниз. В данном случае Client — это фронтенд часть приложения которое мы обсуждаем. Server — это его серверная часть, которая представлена у нас микросервисом Login. Google API Server — апи гугла, с которым мы будем взаимодействовать, а OAuth Dialog — это тот самый диалог, которые предоставляет гугл для аутентификации юзеров. Для использование google oauth нам нужен api-ключ: не имеет смысла расписывать пошагово как его получить, поэтому вот:

Скрыто от гостей

Ну а в следующей части я расскажу и покажу как всё это реализовать.

codeby.net