Как работает контроль учетных записей

Единая точка входа (Single Sign On, SSO)

Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автомагически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но всё же раздельные продукты

Как они аутентифицируют пользователя во всех продуктах после единственного входа?

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:

1. Пользователь входит в один из сервисов Google.
2. Пользователь получает сгенерированную в Google Accounts куку.
3. Пользователь идёт в другой продукт Google.
4. Пользователь снова перенаправляется в Google Accounts.
5. Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.

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

Как доработать производительный RLS

Неоднократно в последнее время поступали задачи, когда требовалось доработать новый производительный RLS. В своей статье Ретунский Александр, программист компании АО «Корпоративные ИТ-проекты» (официальный партнер ИнфоСофт) опишет последовательность действий при доработке нового RLS, ключевые моменты и сложности, с которыми столкнулся. В Интернете статей или инструкций, которые подробно и просто описывают – как доработать производительный RLS, не так много и автор делиться своим опытом.
В данной статье не будут описаны различия и плюсы/минусы между стандартным и производительным RLS, в Интернете по этому вопросу есть много информации.

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

Многим известно, что в современных конфигурациях, разработанных с использованием БСП, имеются широкие возможности для настройки прав доступа. В частности, реализован функционал разделения доступа на уровне записей (RLS). Однако администратор(разработчик) при планировании схемы доступа в организации неминуемо столкнется со сложностями, если временами путается в понятиях: Группы пользователей/Группы доступа/Профили групп доступа.
В статье представлен принцип решения типичной задачи – ограничения прав пользователя на просмотр/изменение информации «чужих» складов и подразделений в конфигурации 1С: Управление торговлей 11.4.

Инструкция по управлению доступом к объектам ИАС «ИСТИНА»¶

Назначение ответственных по подразделениям

Система предоставляет два способа назначения ответственных по подразделению.
Один из этих способов заключается в использовании специально разработанной
для этой цели страницы и является более удобным. Для пользователей, обладающих
административными привилегиями в системе также возможно добавление
ответственных по подразделениям с использованием механизмов администрирования,
встроенного в библиотеку Django, используемую ИАС «ИСТИНА» в качестве
«слоя-посредника» при обращении к базе данных системы. Второй способ
предоставляет несколько больше возможностей для управления полномочиями
пользователей, однако требует использования значительно менее дружественного
интерфейса. Для большинства задач по управлению полномочиями пользователей
ИАС «ИСТИНА» предпочтительным является использование интерфейса, разработанного
специально для этой системы. В настоящем разделе инструкции рассматриваются
способы управления доступом к объектам системы с использованием приложения,
разработанного специально для нее. Управление доступом с использованием
панели администрирования Django может осуществляться только персоналом сайта.

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

Рис. 177 Диалог добавления ответственного по подразделению

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

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

4.1. Функциональные опции.

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

Подробнее о работе с функциональными опциями можно почитать на ИТС

Множество уязвимостей в традиционных методах аутентификации

• Дублирование SIM-карты. Злоумышленники создают копию SIM (с помощью сотрудников сотового оператора, либо самостоятельно, при помощи специального программного и аппаратного обеспечения). В результате злоумышленнику приходит SMS с одноразовым паролем. В одном особенно известном случае хакеры даже смогли скомпрометировать учётную запись AT&T инвестора криптовалюты Майкла Терпина, и украсть почти 24 миллиона долларов в криптовалютах. В результате чего Терпин заявил, что AT&T был виноват из-за слабых мер проверки, приведших к дублированию SIM-карты.
• Вредоносные программы (malware). Одной из самых ранних функций мобильных вредоносных программ был перехват и пересылка злоумышленникам текстовых сообщений. Также, атаки «человек в браузере» (man-in-the-browser) и «человек посередине» (man-in-the-middle) могут перехватывать одноразовые пароли, когда они вводятся на зараженных ноутбуках или настольных устройствах.
• Социальная инженерия. Когда мошенникам известно, что у жертвы включены одноразовые пароли по SMS, они могут напрямую связаться с жертвой, выдавая себя за доверенную организацию, такую как её банк или кредитный союз, чтобы обмануть жертву и заставить её предоставить только что полученный код.

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

Двухфакторная аутентификация

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

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

Входить в сервис намного дольше. 

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

Войти сложно, даже если у вас везде один и тот же пароль. 

Модель меток

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

Выстраивается система доступа, в которой метки для субъекта дифференцируются в соответствии с уровнем доступа, определенного внутренней документацией, а для объекта – исходя из степени конфиденциальности информации, например, «Коммерческая тайна», «Общедоступно», «Секретно», «Совершенно секретно», «Особой важности». . Подобная модель реализована в «СёрчИнформ FileAuditor»

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

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

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

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

Работа в СУД на примере UMI.CMS

Рассмотрим работу в распространенной системе управления доступами пользователей. UMI.CMS предлагает гибкий функционал, позволяющий настраивать права не только для групп, но и отдельных пользователей. В ней предусмотрено два основных типа пользователей:

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

2. Гость. Данный тип пользователя характеризуется минимальным списком полномочий. 

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

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

Супервайзер может оперативно предоставить отдельному пользователю полноценные права для работы с конкретным модулем. Для этого в выбранном модуле достаточно поставить флажки напротив пунктов «Просмотр» и «Управление». Для того чтобы позволить управлять всем функционалом, необходимо также разрешить администрирование в колонке «Прочие права». В UMI.CMS пользователи могут получить возможность работать с отдельным модулем без возможности внесения настроек. Например, в модуле обмена данными обмениваться файлами с помощью протокола HTTP, но без доступа к заданию или снятию ограничений на экспорт и импорт данных.

Параметры поставщика удостоверений

Администраторы шлюза могут выбрать один из следующих элементов:

• .
• .

Проверка подлинности смарт-карты

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

Условный доступ и многофакторная проверка подлинности

Если для шлюза требуется выполнить проверку подлинности Azure AD, вы можете использовать дополнительные функции безопасности, такие как условный доступ и многофакторная проверка подлинности, предоставляемые Azure AD. Краткое руководство. Требование Многофакторной идентификации для конкретных приложений с помощью условного доступа Azure Active Directory

Безопасность MFA

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

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

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

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

Элементы аутентификации

1. Субъект — пользователь
2. Характеристика субъекта — информация, предоставляемая пользователем для проверки подлинности.
3. Владелец системы аутентификации — владелец ресурса.
4. Механизм аутентификации — принцип проверки
5. Механизм авторизации — управление доступом

Методы аутентификации

1. Парольные
2. Комбинированные
3. Биометрические
4. Информация о пользователе
5. Пользовательские данные

Парольные

Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом. 

Комбинированные

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

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

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

Информация о пользователе

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

Пользовательские данные

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

Классификация видов аутентификации

В зависимости от политики безопасности систем и уровня доверия

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

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

Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.

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

• Login
• PAP (Password Authentication Protocol) — логин и пароль
• Карта доступа — USB и сертификаты
• Биометрические данные

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

• Cookies. Используются для отслеживания сеанса, сохранения предпочтений и сбора статистики. Степень защиты невысокая, однако привязка к IP-адресу решает эту проблему.
• Kerberos. Протокол взаимной аутентификации с помощью криптографического ключа.
• SAML (Security Assertion Markup Language) Язык разметки, который позволяет сторонам обмениваться данными аутентификации.
• SNMP (Simple Network Management Protocol) Протокол, который контролирует подключенные к сети устройства.
• Сертификаты X.509 Сертификаты с открытым ключом.
• OpenID Connect. Используется для создания единой учетной записи для аутентификации на разных ресурсах.

История происхождения аутентификации

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

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

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

В древних сказках можно встретить упоминания о паролях, с помощью которых можно было попасть в пещеры с сокровищами. Например, в сказке “Али-Баба и 40 разбойников” присутствует пароль “Сим – Сим, откройся!”, что является ничем иным как аутентификацией.

Ролевое управление

По мере роста размеров информационной системы и количества сотрудников компании решение задачи организации дискреционного управления доступом к данным для сотрудников разного уровня становится все более сложным. Число связей на уровне «пользователь – файл» возрастает практически в геометрической прогрессии, это создает нагрузку на систему и персонал. Решить задачу призвана модель ролевого управления доступом (РУД). Основа этой системы является создание промежуточной сущности – роли, при администрировании она занимает место между пользователем и объектом. Роль прямо не связана с пользователем, но она предоставляет права доступа к определенному классу объектов. Для одного пользователя одновременно может быть открыто несколько ролей с различными правами доступа, это позволяет управлять доступом к информационным ресурсам более гибко.

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

Двухфакторная аутентификация

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

В качестве второго способа для проверки существует следующее:

Примеры

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

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

• Вконтакте позволяет активировать целый ряд функций дополнительной защиты, например: аутентификация через номер мобильного телефона для сообщений, сервисы для генерации данных входа, идентификация с помощью мессенджеров, авторизация по геолокации;
• Telegram для идентификации предлагает прикрепить к профилю адрес электронной почты, а также придумать второй код, который будет запрашиваться в качестве дополнения к коду из SMS во время авторизации с нового устройства;
• Instagram привязан к электронной почте, поэтому если ресурс обнаружит подозрительную авторизацию, то в интерфейсе сервиса тут же появится предупреждение и предложение выслать код безопасности на e-mail или мобильный телефон;
• Популярнейший сервис для компьютерных игр Steam перед авторизацией просит ввести 5 символов, случайно генерируемых каждые 30 секунд в мобильном приложении.

Зачем нужна аутентификация

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

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

4.2. RLS (Record Level Security)

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

Для настройки такого разрешения есть дополнительный механизм  RLS (Record Level Security). Как и следует из названия, этот механизм контроля доступа на уровне конкретных записей таблиц. Если права доступа дают доступ к таблицам вцелом (справочникам) или колонкам таблиц (реквизитам), то RLS определяет конкретные строки таблиц (записи), с которыми разрешено работать пользователю. Он позволяет определить данные, которые пользователю доступны.

При разборе данного механизма стоит всегда помнить, что RLS не является механизмом запрета доступа. Он является механизмом фильтрации выдачи доступа. Т.е. RLS  не влияет на имеющиеся у пользователя права, он является фильтром, ограничивающим выдачу прав. RLS влияет только на ту конкретную связь «Роль» — «Право доступа», в которой он прописан. И не влияет на права доступа, выданные с помощью других ролей.   Например, если одной ролью будет разрешен доступ к документам только по Организации1, а другой ролью доступ к документам по Складу1, то в итоге пользователь получит доступ ко всем документам, в которых указана Организация1 ИЛИ Склад1. Поэтому если пользователю выдается несколько ролей, то фильтр с помощью RLS нужно ставить в каждой роли по обоим полям  (по организации и складу). В типовых решениях эта задача обычна решается созданием одной роли, в которой прописываются все возможные фильтры RLS. Данная роль потом назначается всем пользователям, работающим с данными справочниками. Также контролируется, чтобы у пользователя не были доступны другие роли, содержащие право доступа к ограниченным документам. 

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

Это означает, что мы не можем, например, дать пользователю одновременно право «Изменение» без фильтра для возможности работать программно с любыми документами и право «Редактирование» с фильтром RLS по организации для интерактивной работы. Если нам нужно, чтобы пользователь мог редактировать документы с фильтром RLS , мы обязаны наложить общий фильтр на верхнем уровне «Изменение» или «Чтение».

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

Основные методы аутентификации

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

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

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

Методы

Существует 5 методов аутентификации:

1. Парольный.
2. Комбинированный.
3. Биометрический.
4. Информация о пользователе.
5. Пользовательские данные.

Парольные

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

Комбинированные

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

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

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

Информация о пользователе

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

Пользовательские данные

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