Динамический пароль 2.0 / Хабр

2.Аутентификация на основе одноразовых паролей

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

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

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

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

Однако количество приложений ИТ-безопасности, которые поддерживают возможность работы с OTP-токенами, намного меньше, чем для смарт-карт и USB-токенов. Недостатком OTP-токенов является ограниченное время жизни этих устройств (три-четыре года), так как автономность работы предполагает использование батарейки.

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

Реализация.

Технологии OTP были разработаны в рамках отраслевой инициативы Open Authentication (OATH), выдвинутой компанией VeriSign в 2004 г. Суть этой инициативы заключается в разработке стандартной спецификации действительно надежной аутентификации для различных Интернет-сервисов.

Причем речь идет о двухфакторном определении прав пользователя, в процессе которого последний должен «предъявить» смарт-карту или USB-токен и свой пароль. Таким образом, одноразовые пароли со временем могут стать стандартным средством удаленной аутентификации в различных системах.

Сегодня разработано и используется на практике несколько вариантов реализации систем аутентификации по одноразовым паролям.

1.Основные понятия

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

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

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

В соответствии с рекомендациями стандарта Х.509 различают процедуры строгой аутентификации следующих типов:

• односторонняя аутентификация;
• двусторонняя аутентификация;
• трехсторонняя аутентификация.

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

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

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

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

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

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

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

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

на симметричных алгоритмах шифрования;

однонаправленных ключевых хэш-функциях;

асимметричных алгоритмах шифрования;

алгоритмах электронной цифровой подписи.

3.Строгая аутентификация, основанная на асимметричных алгоритмах

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

• расшифровать запрос, зашифрованный на открытом ключе;
• поставить свою цифровую подпись на запросе.

Пара ключей, необходимая для аутентификации, не должна

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

Аутентификация с использованием асимметричных алгоритмов шифрования

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

(1)

. (2)

Участник В выбирает случайным образом r и вычисляет значение х=h(r) (значение х демонстрирует знание r без раскрытия самого значения r), далее он вычисляет значение е = РA(r, В). Под РА подразумевается алгоритм асимметричного шифрования (например, RSA), а под А(•) — хэш-функция.

Участник В отправляет сообщение (1) участнику А. Участник А расшифровывает е = РА(r, В) и получает значения r1, и B1, а также вычисляет х1=h(r1).

После этого производится ряд сравнений, доказывающих, что x=x1, и что полученный идентификатор B1, действительно указывает на участника В. В случае успешного проведения сравнения участник А посылает r. Получив его, участник В проверяет, то ли это значение, которое он отправил в сообщении (1).

В качестве другого примера приведем модифицированный протокол Нидхэма и Шредера, основанный на асимметричном шифровании.

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

. (1)

. (2)

; (3)

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

В рекомендациях стандарта Х.509 специфицирована схема аутентификации, основанная на использовании цифровой подписи, меток времени и случайных чисел.

Для описания этой схемы аутентификации введем следующие обозначения:

tA , rА и rв — временная метка и случайные числа соответственно;

SA — подпись, сгенерированная участником А;

SB — подпись, сгенерированная участником B;

certA — сертификат открытого ключа участника А;

certB — сертификат открытого ключа участника В.

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

В качестве примеров приведем следующие протоколы аутентификации.

1. Односторонняя аутентификация с применением меток времени:

(1)

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

1. Односторонняя аутентификация с использованием случайных чисел:

; (1)

(2)

Участник В, получив сообщение от участника А, убеждается, что именно он является адресатом сообщения; используя открытый ключ участника А, взятый из сертификата certA, проверяет корректность подписи SA(rA , rB , В) под числом rА, полученным в открытом виде, числом rB , которое было отослано в сообщении (1), и его идентификатором В. Подписанное случайное число rА используется для предотвращения атак с выборкой открытого текста.

1. Двусторонняя аутентификация с использованием случайных чисел:

; (1)

(2)

(3)

В данном протоколе обработка сообщений (1) и (2) выполняется так же, как и в предыдущем протоколе, а сообщение (3) обрабатывается аналогично сообщению (2).

Заключение

На данной лекции мы изучили принципы управления доступом к информационным ресурсам. Нами были рассмотрены вопросы: «Идентификация и аутентификация пользователей и программ», «Методы аутентификации, использующие пароли и PIN-коды», «Строгая аутентификация».

1.Аутентификация на основе многоразовых паролей

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

Примером такой БД является Active Directory. Active Directory («Активный каталог», AD) — службы каталогов корпорации Microsoft для операционных систем семейства Windows Server. Первоначально создавалась, как LDAP-совместимая реализация службы каталогов, однако, начиная с Windows Server 2008, включает возможности интеграции с другими службами авторизации, выполняя для них интегрирующую и объединяющую роль.

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

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

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

• в незашифрованном виде: например, согласно протоколу парольной аутентификации PAP (Password Authentication Protocol) пароли передаются по линии связи в открытой незащищенной форме;
• в защищенном виде: все передаваемые данные (идентификатор и пароль пользователя, случайное число и метки времени) защищены посредством шифрования или однонаправленной функции.

Рис. 1. Простая аутентификация с использованием пароля.

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

Для этого в схему включены средства шифрования Ек и расшифровывания DK, управляемые разделяемым секретным ключом К. Проверка подлинности пользователя основана на сравнении присланного пользователем пароля РА и исходного значения Р’А, хранящегося на сервере аутентификации.

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

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

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

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

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

Хэширование или хеширование (англ. hashing) — преобразование массива входных данных произвольной длины в (выходную) битовую строку фиксированной длины, выполняемое определённым алгоритмом. Функция, реализующая алгоритм и выполняющая преобразование, называется «хеш-функцией» или «функцией свёртки».

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

Например, односторонняя функция h(.) может быть определена следующим образом:

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

Такие функции удобны, если длина пароля и ключа одинаковы. В этом случае проверка подлинности пользователя А с помощью пароля РA состоит из пересылки серверу аутентификации отображения h(PA) и сравнения его с предварительно вычисленным и хранимым в БД сервера аутентификации эквивалентом h'(PA) (рис. 2).

Рис. 2. Использование односторонней функции для проверки пароля

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

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

2.Строгая аутентификация, основанная на симметричных алгоритмах

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

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

Протоколы аутентификации с симметричными алгоритмами шифрования.

Ниже приводятся три примера протоколов аутентификации, специфицированных в ISO/IEC 9798-2. Эти протоколы предполагают предварительное распределение разделяемых секретных ключей.

Рассмотрим следующие варианты аутентификации:

• односторонняя аутентификация с использованием меток времени;
• односторонняя аутентификация с использованием случайных чисел;
• двусторонняя аутентификация.

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

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

Введем следующие обозначения:

rА — случайное число, сгенерированное участником А;

rB — случайное число, сгенерированное участником В;

tA — метка времени, сгенерированная участником А;

Eк — симметричное шифрование на ключе К (ключ K должен быть предварительно распределен между А и В).

1. Односторонняя аутентификация, основанная на метках времени:

. (1)

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

1. Односторонняя аутентификация, основанная на использовании случайных чисел:

; (1)

. (2)

Участник В отправляет участнику А случайное число rB. Участник А шифрует сообщение, состоящее из полученного числа rBи идентификатора В, и отправляет зашифрованное сообщение участнику В.

1. Двусторонняя аутентификация, использующая случайные значения:

; (1)

. (2)

. (3)

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

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

Протоколы, основанные на использовании однонаправленных ключевых хэш-функций

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

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

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

Дайджест m = hK(M) передается получателю вместе с исходным сообщением М. Получатель сообщения, зная, какая односторонняя хэш-функция была применена для получения дайджеста, заново вычисляет ее, используя расшифрованное сообщение М.

Рис.3. Применение для аутентификации односторонней хэш-функции с параметром-ключом

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

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

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

На рис. 4 показан другой вариант использования односторонней хэш-функции для проверки целостности данных. В этом случае односторонняя хэш-функция h(•) не имеет параметра-ключа, но применяется не просто к сообщению М, а к сообщению, дополненному секретным ключом К, т. е. отправитель вычисляет дайджест т = h(M, К).

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

Рис. 4 – Применение односторонней хэш-функции к сообщению, дополненному секретным ключом К

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

• функция симметричного шифрования Е_К заменяется функцией h_K;
• проверяющий вместо установления факта совпадения полей в расшифрованных сообщениях с предполагаемыми значениями вычисляет значение однонаправленной функции и сравнивает его с полученным от другого участника обмена информацией;
• для обеспечения независимого вычисления значения однонаправленной функции получателем сообщения в протоколе 1 метка времени t_А должна передаваться дополнительно в открытом виде, а в сообщении (2) протокола 3 случайное число r_А должно передаваться дополнительно в открытом виде.

Модифицированный вариант протокола 3 с учетом сформулированных изменений имеет следующую структуру:

; (1)

. (2)

. (3)

Заметим, что в сообщение (3) протокола включено поле А. Результирующий протокол обеспечивает взаимную аутентификацию и известен как протокол SKID 3.

1 Время восстановления/энтропия входных параметров

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

Если у вашей системы есть на входе A,B,C,D,E,F — факты о пользователе, то если вы будете объединять все в одно, то получите A * B * C * D * E * F комбинаций, которые невозможно эффективно кешировать. По возможности следует найти такую комбинацию входных, что бы у вас было A * B * C и D * E * F комбинаций, а еще лучше A * B, C * D, E * F, которые вы уже легко сможете вычислять и кешировать.

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

10 О кешировании данных

Основной проблемой при работе авторизации является точка в которой необходимо кешировать результаты, что бы работало быстрее все, да еще желательно так, что бы нагрузка на ЦПУ не была высокой. Вы можете поместить все ваши данные в память и спокойно их читать, но это дорогое решение и не все готовы будут себе его позволить, особенно если требуется всего лишь пара ТБ ОЗУ.

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

Предлагаю решить такую задачу на примере ролей пользователя и некоего микросервиса, которому нужно проверять наличие роли у пользователя. Разумеется в данном случае можно сделать карту (Пользователь, Роль) -> Boolean. Проблема в том, что все равно придется на каждую пару делать запрос на удаленный сервис.

Даже если вам данные будут предоставлять за 0,1 мс, то ваш код будет работать все равно медленно. Очевидным решением будет кешировать сразу роли пользователя! В итоге у нас будет кеш Пользователь -> Роль[]. При таком подходе на какое-то время микросервис сможет обрабатывать запросы от пользователя без необходимости нагружать другие микросервисы.

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

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

5 Роль

Множество разрешений, по сути под словом роль всегда подразумевается множество разрешений.

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

Ролевые модели позволяют как выполнять вертикальное, так и горизонтальное разграничение доступа (описание ниже). Из типа разграничения доступа следует, что сами роли делятся на типы:

Но отсюда следует вопрос, если у пользователя есть глобальная роль и локальная, то как определить его эффективные разрешения? Поэтому авторизация должна быть в виде одной из форм:

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

Роль имеет следующие связи:

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

6 Группа

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

Группы используются исключительно для горизонтального разграничения доступа (описание ниже). Даже если вы будете использовать группы для доступа к сервисам, то это все равно горизонтальное разграничение доступа, потому что сервис — это совокупность ресурсов.

Группа имеет следующие связи:

9 Конъюнктивная/дизъюнктивная форма авторизации

Из-за того, что у теперь у нас существуют два варианта наборов разрешений пользователя, то можно выделить два варианта, как объединить все вместе:

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

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

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

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

Методы аутентификации, использующие пароли и PIN-коды

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

2 Логистика

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

Для реализации такого функционала нам потребуется реестр регионов и магазинов в качестве отдельного микросервиса, назовем его С1. Заявки и историю будем хранить на С2. Авторизация — А.Далее при обращении продавца для получения списка его магазинов (а у него может быть их несколько)

, С1 вернет только те, в которых у него есть меппинг (Пользователь, Магазин), так как ни в какие регионы он не добавлен и для продавца регионы всегда пустое множество. Разумеется при условии, что у пользователя есть разрешение просматривать список магазинов — посредством микросервиса А.

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

4 Команда и ее проекты

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

Такую проблему проще всего решить при помощи групп.Группа будет объединять все необходимые проекты в одно целое. При добавлении участника в команду, добавляем меппинг (Пользователь, Группа, Роль).

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

Поэтому микросервис проектов обратится в микросервис групп, что бы получить список групп, в которых Вася — Разработчик. Получив список этих групп можно легко проверить уже в БД микросервиса проектов — есть ли у проекта какая-нибудь из полученных групп и на основании этого предоставлять или запрещать ему доступ.

2 Архитектура решения

Для решения поставленной задачи нам необходимы следующие микросервисы:

1. Ролевая модель для глобальной авторизации запросов
2. Чайный сервис для предоставления возможности пить чай и получать статистику по выпитому
3. Кракен — гейт с проверкой доступа к точке, все остальные проверки совершит чайный сервис

Графически это будет выглядеть так:

В качестве БД будем использовать PostgreSQL.Предусмотрим следующие обязательные для решения задачи роли:

1. Сотрудник — для возможности пить чай;
2. Удаленный сотрудник — для доступа к микросервису кракена (так как сотрудники в офисе не должны иметь возможности пить чай через точки распрастранения чая);
3. Кракен — учетная запись микросервиса, что бы была возможность обращаться к API чайного сервиса;
4. Авторизационная учетная запись — для предоставления доступа микросервисов к ролевой модели.

Permission system

Разработчики Android знают, что приложения, которые мы разрабатываем, по умолчанию не имеют никаких разрешений. У нас нет возможности подключиться к Интернету или сохранить внешнее пространство (внутреннее пространство возможно), если мы не подадим заявку на соответствующее разрешение.

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

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

Android делит все разрешения на два типа: один — «Нормальный», а другой — «Опасный».

Requestpermissions

Когда мы обнаруживаем, что нашему приложению не было предоставлено определенное разрешение, мы можем отобразить приложение.Например,

ActivityCompat.requestPermissions(this, newString[]{Manifest.permission.READ_CONTACTS}, MY_PERMISSIONS_REQUEST_READ_CONTACTS);

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

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

Динамический пароль 2.0

Вот и подошла очередь описать принципиально новый «Динамический пароль 2.0». Включаем юмор, и оставляем включенной логикуПредставьте ситуацию:Вы видите как ваш друг набирает в поле пароля банальный пароль «QQQQQ» или «11111» и входит, вы говорите ему, что он полный чайник, раз использует подобный пароль, а он в ответ, выходит из программы и предлагает ввести его вам.

Вы пытаетесь ввести пароль 5 раз и вас не пускает, после этого вы вспоминаете что когда-то читали статью на хабре Динамический пароль и предполагаете что пароль просто перегенерился и, скорее всего, тогда на часах была или 11-я минута или что то еще… Но ваш приятель садится за комп и опять у вас на глазах начинает вводить «11111» и его пускает!

В чем секрет?В фразе «Динамический пароль 2.0» основным словом является «динамический», но не в смысле «изменяемый», а в смысле «динамичный, танцевальный» ;)Помните реакцию винды на неправильный ввод пароля 3 раза подряд? Она не дает ничего вводить пару минут, что бы исключить подбор пароля, а потом, через пару минут снова дает 3 попытки.

Что, если контролировать время между введенными символами и использовать его как еще один параметр при входе в систему?Не буду разжевывать то, что вы и так поняли, и сразу приведу шаблон пароля нашего «продвинутого» приятеля:Q[[T>500]]Q[[T>500]]Q[[T>500]]Q[[T>

1000]]QГде [[T>500]], говорит о том что между символами должно быть время в миллисекундах большее чем пол секунды, а между предпоследним и последним символами — больше секунды.Включаем фантазию и думаем какие еще правила можно придумать: минимальное/максимальное время ввода всего пароля, больше, меньше, погрешность в миллисекундах, динамическое время основанное на первом промежутке времени между вводом первого и второго символа пароля, и много чего еще…

Сразу о преимуществах:

Теперь о недостатках:

Не забываем, всё это концепты, идеи для размышления, не надо сразу прикладывать идею к сайту «Одноклассники» и его хомячков обитателей 😉

В общем, интересных проектов и удачи Всем!

Лжеминирования

Информации на эту тему много, например:

Интересная цитата из этой публикации:

Недавно в хулиганских посланиях стала появляться любопытная приписка — «Помните о УК РФ 205.6. Несообщение о преступлении». Такая статья Уголовного кодекса действительно существует и грозит штрафом в размере до ста тысяч рублей, а также лишением свободы на срок до одного года

Уникальность ситуации состоит в том, что злоумышленник добивается максимального результата при минимальных затратах и риске быть обнаруженным: любой поисковик поможет составить список для атаки, достаточно набрать «школа», «ТЦ», «суд» и т.п.; на сайте практически любой организации email представлен в открытом виде; мало кто из настройщиков спам-фильтров рискнёт отправлять сообщения о минировании в папку «спам», проще переложить ответственность на кого-то другого.

Про материальные и психологические потери от таких атак говорить не приходится. Для решения проблемы нужно лишь скрыть email организации, а злоумышленника послать на ФОС.

Мошенничество

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

полноценной

обратной связи с ними в надежде избавиться от спама и фишинга. Там также спамят… в разумных пределах, в противном случае, начнётся отток аудитории из этих сетей и мессенджеров. Мы также не будем говорить о квесте при регистрации в них с привязкой к мобильному телефону (фактически «интернету по паспорту»), передаче персональной информации третьим лицам и унизительном ожидании приглашения после того, как попросился в друзья к кому-либо.

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

Интернет-ресурсы, использующие ФОС, хотя бы сообщают о том, что отправленное сообщение получено, но мы также понимаем, что вероятность попадания данного сообщения в инбокс далеко не 100%, т.к. оно переправляется формой на обычный почтовый ящик…Этим недостатком пользуются: мошенники, нерадивые исполнители, руководители и чиновники, охотники за идеями, поставщики. У них всегда есть возможность «прикрыться» проблемой спама.

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

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

Недобросовестная конкуренция

Владельцы сайтов наверняка сталкивались с подобными предложениями:

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

Любой желающий может заспамить любой email (поисковики подскажут как). Скорее всего, этот email уже где-нибудь «засвечен». Ресурсы вроде хантер.ио помогут это узнать. Если не «засвечен», это легко исправить, отправив на сайт через ФОС предложение, от которого «нельзя отказаться» или запрос типа «а есть такое же, но с перламутровыми пуговицами?».

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

Рассылки

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

«отписаться от рассылки»

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

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

Фишинг

главы Group-IB Ильи Сачкова фонду «Росконгресс» (ПРАЙМ):

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

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

Примеров тому – множество. Это – бесконечная борьба искусственного и человеческого интеллектов и технологий. К сожалению, злоумышленники всегда будут на шаг впереди. Пока интернет-сообщество обсуждает что-то новенькое, злоумышленники успевают найти лазейки. Тема серьёзная. Недавно в новостях на Хабре

каждый день в сервисе Gmail блокируется более 100 млн фишинговых писем

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

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

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

Мышление становится шаблонным, стереотипным, мозг пребывает в спячке

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

Итоги из статьи динамический пароль

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

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

Сложность, надо потратить немного времени что бы подготовить пароль по известному вам шаблону и, как следствие, слабая применяемость «в народе».Преимущества — бесполезность идеи взлома пароля методом перебора (пока идет перебор паролей, сабж может стать тем, который уже был использован генератором ранее). Защита от «подглядываний» пароля (точный пароль, набранный через [1-N] минут может оказаться уже неактуальным)

Заключение

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

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

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

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