новый уровень информационной безопасности или новые риски? / Публикации / Пресс-центр / Компания «Актив»

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

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

В процессе идентификации пользователь вынужден предоставлять свои данные в среднем более чем пятнадцати сервис-провайдерам. Известно, что у 70% пользователей есть идентификатор в системе ЕСИА и, как минимум, в одном банке и у одного оператора связи. У 30% — как минимум, в двух банках и операторах связи, в дополнение к десяткам онлайн-сервисов и магазинов. При этом многие из сервис-провайдеров собирают данные «на всякий случай». Таким образом, число идентификаторов и идентификационной информации растет в геометрической прогрессии, часто повторяясь многократно.

Таблица 1. Пример масштаба сбора данных

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

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

Диаграмма 1. Виновники утечек персональных данных

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

Так, по оценкам аналитиков Ernst & Young, построенным на основе опроса текущих клиентов, стоимость соответствия требованиям регуляторов в области персональных данных (ФЗ-152, ФЗ-115) постоянно увеличивается. Разовые затраты на комплаенс могут составлять до 20% от выручки, а штрафы за несоответствие требованиям — до 4% от глобальной выручки. Стоимость работы с запросами от регулятора за два последних года выросла в 3 раза.

Диаграмма 2. Число зарегистрированных утечек данных, Россия, 2006–2019 гг., прогноз на 2020 г.

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

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

Диаграмма 3. Оцениваемый эффект цифровой идентификации и аутентификации

Кроме того, сокращение объема и периметра хранения способствовало бы снижению числа утечек. Экономический эффект от объединения идентификаторов Ernst & Young оценивает в 1–2% ВВП. Его можно ожидать за счет снижения транзакционных издержек и развития онлайн- рынков, включая образование и медицину, которые сейчас преимущественно привязаны к физической локации.

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

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

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

Проверка подлинности для решений гибридной идентификации Azure AD — Active Directory

• Статья
• 01/24/2022
• Чтение занимает 15 мин

Были ли сведения на этой странице полезными?

Оцените свои впечатления

Да Нет

Хотите оставить дополнительный отзыв?

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

Отправить

В этой статье

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

1. Это первое решение, принимаемое организацией, желающей перейти в облако.

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

3. Это основа всех других дополнительных функций безопасности и пользовательского интерфейса в Azure AD.

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

Примечание

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

Вне области

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

Методы проверки подлинности

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

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

Azure AD поддерживает следующие методы аутентификации для решений для гибридной идентификации.

Облачная аутентификация

При выборе этого метода аутентификации Azure AD обрабатывает процесс входа пользователей. В сочетании с простым единым входом (SSO) пользователи могут войти в облачные приложения без необходимости повторного ввода своих учетных данных. При использовании облачной аутентификации вы можете выбрать один из двух вариантов:

Синхронизация хэша паролей Azure AD. Это самый простой способ включить аутентификацию объектов локального каталога в Azure AD. Пользователи могут использовать те же имя пользователя и пароль, которые они вводят в локальной среде, без необходимости развертывания какой-либо дополнительной инфраструктуры. Некоторые функции Azure AD, такие как «Защита идентификации» и доменные службы Azure Active Directory, требуют синхронизации хэша паролей независимо от выбранного метода проверки подлинности.

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

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

Федеративная аутентификация

При выборе этого метода аутентификации Azure AD передает процесс аутентификации отдельной доверенной системе аутентификации, например локальным службам федерации Active Directory (AD FS), для проверки пароля пользователя.

Эта система аутентификации может накладывать дополнительные требования расширенной аутентификации. Примеры: аутентификация на основе смарт-карт или многофакторная проверка подлинности сторонних производителей. Дополнительные сведения см. в статье о развертывании служб федерации Active Directory.

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

Дерево решений

Уточнение вопросов дерева принятия решений:

1. Azure AD может контролировать вход пользователей, не полагаясь на локальные компоненты проверки паролей.
2. Azure AD может передать функцию контроля входа пользователей доверенному поставщику проверки подлинности, например AD FS корпорации Майкрософт.
3. Если необходимо применять политики безопасности Active Directory уровня пользователя, например проверять срок действия учетной записи, отключенные учетные записи, срок действия пароля, заблокированные учетные записи и время входа при каждом входе пользователя, Azure AD потребуются некоторые локальные компоненты.
4. Способы входа, не поддерживаемые Azure AD:
   • вход с помощью смарт-карт или сертификатов;
   • вход с помощью многофакторной проверки подлинности на локальном сервере;
   • вход с помощью стороннего решения проверки подлинности;
   • универсальное локальное решение проверки подлинности.
5. Защита идентификации Azure AD предусматривает синхронизацию хэшей паролей, независимо от используемого метода входа в систему, для подготовки отчета о пользователях со скомпрометированными учетными данными. Организации могут переключаться на синхронизацию хэшей паролей, если происходит сбой в их основном методе входа в систему и он был настроен до сбоя.

Примечание

Для защиты идентификации Azure AD требуется лицензия Azure AD Premium P2.

Подробные рекомендации

Облачная проверка подлинности Синхронизация хэша паролей

• Трудозатраты. Синхронизация хэша паролей требует минимальных трудозатрат для развертывания, обслуживания и обеспечения инфраструктуры. Этот уровень трудозатрат обычно подходит для организаций, которым требуется, чтобы пользователи входили в Office 365, приложения SaaS и другие ресурсы на основе Azure AD. После включения синхронизация хэша паролей становится частью процесса синхронизации Azure AD Connect и запускается каждые две минуты.

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

• Сложные сценарии. При необходимости организации могут использовать аналитические сведения из удостоверений в отчетах службы защиты идентификации Azure AD с Azure AD Premium P2. Например, в отчете об утечке учетных данных. Windows Hello для бизнеса включает в себя особые требования при использовании синхронизации хэша паролей. Доменным службам Azure Active Directory требуется синхронизация хэша паролей для предоставления пользователям корпоративных учетных данных в управляемом домене.

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

Примечание

Для условного доступа Azure AD требуются лицензии Azure AD Premium P1.

• Непрерывность бизнес-процессов. Использование синхронизации хэша паролей с облачной аутентификацией обеспечивает высокий уровень доступности в качестве облачной службы, которая охватывает все центры обработки данных Майкрософт. Чтобы убедиться в том, что синхронизация хэша паролей не отключится на продолжительное время, разверните второй сервер Azure AD Connect в промежуточном режиме в резервной конфигурации.

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

Примечание

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

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

Облачная проверка подлинности Сквозная проверка подлинности

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

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

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

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

  Организации, которым требуется многофакторная проверка подлинности со сквозной аутентификацией, должны использовать Многофакторную проверку подлинности Azure AD (MFA) или пользовательские элементы управления для условного доступа. Эти организации не могут использовать метод многофакторной проверки подлинности сторонних производителей или локальный метод многофакторной проверки подлинности. Для использования расширенных функций требуется, чтобы синхронизация хэша паролей была развернута независимо от того, реализуется ли сквозная аутентификация. Например, это требуется для получения отчетов об утечке учетных данных службы «Защита идентификации».

• Непрерывность бизнес-процессов. Рекомендуется развернуть два дополнительных агента сквозной аутентификации. Они устанавливаются в дополнение к первому агенту на сервере Azure AD Connect. Развертывание эти агентов обеспечивает высокий уровень доступности запросов на аутентификацию. Если развернуты три агента, один агент все еще может выйти из строя, если другой агент отключен для обслуживания.

  Развертывание синхронизации хэша паролей в дополнение к сквозной аутентификации дает еще одно преимущество. Это обеспечивает резервный метод аутентификации на случай, если основной метод аутентификации станет недоступен.

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

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

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

Федеративная аутентификация

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

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

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

  • Аутентификация, требующая наличия смарт-карт или сертификатов.
  • Локальные серверы MFA или сторонние поставщики многофакторной проверки подлинности, которым необходим федеративный поставщик удостоверений.
  • Аутентификация с использованием решения для аутентификации стороннего производителя. Ознакомьтесь со списком совместимости с федерацией Azure AD.
  • Для входа в систему требуется имя sAMAccountName, например «ДОМЕН\имя пользователя», а не имя участника-пользователя (UPN), например [email protected].

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

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

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

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

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

Примечание

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

Схемы архитектуры

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

• Простота решения для синхронизации хеша паролей:

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

• Компоненты, необходимые для федерации в сети периметра и внутренней сети организации:

Сравнение методов

Примечание

Пользовательские элементы управления в компоненте условного доступа Azure AD в настоящее время не поддерживают регистрацию устройств.

Рекомендации

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

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

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

   Чтобы избежать появления единых точек отказа, разверните избыточные серверы. Это обеспечит непрерывную обработку запросов на аутентификацию при сбое любого компонента. Сквозная аутентификация и федерация зависят также от контроллеров домена для реагирования на запросы на аутентификацию, сбой которых также возможен. Многие из этих компонентов требуют обслуживания для обеспечения работоспособности. Вероятность простоев повышается, если обслуживание не запланировано и реализовано неправильно. Простоев можно избежать, используя синхронизацию хэша паролей, так как облачная служба аутентификации Microsoft Azure AD масштабируется глобально и всегда доступна.

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

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

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

3. Защита идентификации. Одним из лучших способов защиты пользователей в облаке является «Защита идентификации Azure Active Directory» с Azure AD Premium P2. Корпорация Майкрософт постоянно ищет в Интернете списки пользователей и паролей, которые злоумышленники продают и предоставляют на теневых веб-сайтах. Azure AD может использовать эту информацию, чтобы проверить, были ли скомпрометированы какие-либо имена пользователей и пароли в организации. Поэтому очень важно включить синхронизацию хэша паролей независимо от используемого метода аутентификации, будь то федеративная или сквозная аутентификация. Сведения об утечке учетных данных представляются в виде отчета. Эти сведения можно использовать, чтобы блокировать пользователей или вынудить их сменить пароль при попытке выполнить вход с помощью скомпрометированного пароля.

Заключение

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

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

Дальнейшие действия

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

Начните работу с Azure AD и разверните правильное решение аутентификации для своей организации.

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

ТЕХНОЛОГИИ ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ — NovaUm.Ru

УДК 004.931

ТЕХНОЛОГИИ ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ

Технические науки

Мухаметянов Амир Рашидович

Шарипов Алмаз Мунирович

---

Ключевые слова: БЕЗОПАСНОСТЬ; ИДЕНТИФИКАЦИЯ; АУТЕНТИФИКАЦИЯ; SECURITY; IDENTIFICATION; AUTHENTICATION.

---

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

Введение

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

Основными процедурами регистрации пользователей в ИС являются процедура идентификации — получение ответа на вопрос «Кто Вы?» и аутентификации — доказательства того, что «Вы именно тот, кем представляетесь». Несанкционированное получение злоумышленником доступа к ИС связано, в первую очередь, с нарушением процедуры аутентификации.

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

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

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

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

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

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

Биометрическая аутентификация. Особенности статических методов биометрического контроля

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

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

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

Аутентификация по любой биометрической системе проходит четыре стадии: Запись — физический или поведенческий образец запоминается системой; Выделение — уникальная информация выносится из образца и составляется биометрический образец;

Сравнение — когда сохраненный образец сравнивается с представленным; «Совпадение/несовпадение» — система решает, совпадают ли биометрические образцы, и выносит решение.

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

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

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

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

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

Аутентификация по радужной оболочке глаз

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

Аутентификация по геометрии лица

Существует множество методов распознавания по геометрии лица. Все они основаны на том, что черты лица и форма черепа каждого человека индивидуальны. Эта область биометрии многим кажется привлекательной, потому что мы узнаем друг друга в первую очередь по лицу. Данная область делится на два направления: 2-D распознавание и 3-D распознавание. У каждого из них есть достоинства и недостатки, однако многое зависит еще и от области применения и требований, предъявленных к конкретному алгоритму.

---

Список литературы

1. https://studbooks.net/2249890/informatika/autentifikatsiya_identifikatsiya
2. Галатенко В.А. Идентификация и аутентификация, управление доступом лекция из курса «Основы информационной безопасности». — Интернет Университет Информационных Технологий, 2010г.
3. Тихонов И.А. Информативные параметры биометрической аутентификации пользователей информационных систем по инфракрасному изображению сосудистого русла Биомедицинская техника и радиоэлектроника. 2010. № 9. C. 26-32.

Вконтакте

Facebook

Twitter

Вступил в силу ГОСТ Р 58833-2020 «Защита информации. Идентификация и аутентификация. Общие положения»

Непосредственное участие в разработке Стандарта принял Алексей Сабанов, заместитель генерального директора компании «Аладдин Р.Д.»

Москва, 09 июня 2020 года. — Компании «Аладдин Р.Д.», ведущий российский разработчик и поставщик средств аутентификации и решений для обеспечения информационной безопасности и защиты конфиденциальных данных, сообщает о вступлении в действие ГОСТ Р 58833-2020 «Защита информации. Идентификация и аутентификация. Общие положения».

Работа над Стандартом объединила лучших специалистов отрасли, в числе которых ТК 362, ТК 26, ТК 098. Непосредственное участие в разработке стандарта приняли Алексей Сабанов, заместитель генерального директора «Аладдин Р.Д.», и Александр Бойко, руководитель аналитического отдела «Аладдин Р.Д.».

10 апреля 2020 года Росстандартом был подписан приказ о присвоении стандарту ГОСТ Р 58833-2020 «Защита информации. Идентификация и аутентификация. Общие положения» статуса «Действующий» и вступлении его в силу с 1 мая 2020 года.

«Для компании «Аладдин Р.Д.» принятие Стандарта является знаковым событием, поскольку раньше приходилось терпеливо разъяснять разницу между идентификацией и аутентификацией, объяснять, что строгая аутентификация должна быть обязательно взаимной (аутентифицируются обе стороны – субъект и объект доступа), многофакторной (факторы должны быть разной природы и использоваться одновременно) с применением строгих криптографических алгоритмов. Теперь, после вступления в действие ГОСТ Р 58833 «Идентификация и аутентификация. Общие положения», нет необходимости тратить много усилий на переубеждение оппонентов – всё отражено в действующем ГОСТ«, — отметил А. Сабанов.

О компании «Аладдин Р.Д.»

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

«Аладдин Р.Д.» признана лидером российского рынка аппаратных средств аутентификации и электронной подписи и входит в ТОП-10 крупнейших российских ИБ-компаний (CNews Analytics, 2017). Продукты «Аладдин Р.Д.» и комплексные решения на их основе используются в банковском, государственно-административном, топливно-энергетическом и других секторах отечественной экономики.

Компания имеет все необходимые лицензии ФСТЭК России и ФСБ России. Система менеджмента качества «Аладдин Р.Д.» соответствует требованиям национальных стандартов ГОСТ Р ИСО 9001-2015 и ГОСТ РВ 0015-002-2012.

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

Идентификация и аутентификация в CISSP

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

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

Идентификация

и CISSP

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

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

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

Авторизация и CISSP

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

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

Давайте рассмотрим наиболее распространенные методы идентификации и аутентификации:

• Идентификатор пользователя : это наиболее стандартная форма идентификации, которая чаще всего используется организациями в качестве способа идентификации, чтобы отличить пользователя от других.Всякий раз, когда пользователь предоставляет идентификатор пользователя во время процесса идентификации, пользователь сообщает системе, что он хочет, чтобы его распознали по этому идентификатору пользователя, и после этого начинается процесс аутентификации пользователя, предоставляющий пользователю соответствующие ресурсы.
• MAC-адрес : Всем компьютерам присваивается 48-битный номер, называемый адресом управления доступом к среде (MAC), для уникальной идентификации. Ранее MAC-адрес был встроен в аппаратную часть устройства и не мог быть изменен конечным пользователем.Таким образом, это был безопасный идентификатор, но в настоящее время большинство сетевых устройств имеют MAC-адрес, встроенный в программное обеспечение, и поэтому пользователь может изменить его. Таким образом, он не считается теперь той уникальной и безопасной идентификацией
.
• IP-адрес : MAC-адрес помогает определить физическое местоположение компьютера, тогда как IP-адрес поможет определить логическое местоположение системы. Он выделяется для всех систем, использующих сетевой протокол TCP/IP. IP-адреса представляют собой диапазон пула IP-адресов и, таким образом, могут быть разделены на подсети.Разные системы в разных подсетях могут иметь один и тот же IP-адрес, но он должен быть уникальным в одной и той же подсети устройства. Он может быть легко изменен пользователем, поэтому он также не является надежным идентификатором.
• Персональный идентификационный номер (ПИН-код) : ПИН-код предоставляется пользователю, чтобы определить, имеет ли пользователь право выполнять какие-либо действия с личностью. Это наиболее часто встречается в банковских транзакциях и является второй формой идентификации пользователя.
• Идентификационные значки : Идентификация может быть не только логической, но и физической.Таким образом, организации должны иметь несколько бейджей для идентификации своих сотрудников, поскольку бейдж должен содержать имя пользователя с их фотографией. Это сделано для сдерживания любой возможной активности, которую может вызвать не сотрудник в самой точке входа в организацию. Звучит как эффективный метод идентификации, но чаще всего сотрудники не используют его должным образом, а охранники тоже допускают ошибки, сравнивая человека с фотографией на бейдже.
• Адрес электронной почты : В последние годы новая форма идентификации, известная как адрес электронной почты, стала также использоваться в качестве уникального идентификатора.Однако они уникальны только по соглашению и не должны использоваться в качестве доверенного фактора только потому, что адрес электронной почты можно легко подделать, и организации должны использовать другие средства проверки подлинности, чтобы связать адрес электронной почты с пользователем.

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

Механизмы аутентификации

Теперь рассмотрим механизмы аутентификации.

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

• То, что вы знаете : Секрет или PIN-код
• То, что у вас есть : Смарт-карта или токен
• Что-то, чем вы являетесь : Распознавание лиц, биометрия

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

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

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

Типы отказов

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

• Ложное признание : Ложное признание путем принятия самозванца как законного пользователя.
• Ложное отклонение : Отказ авторизованному и законному пользователю в доступе к системе/помещениям.

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

IA: Идентификация и аутентификация — инструменты CSF

Средства управления

IA-1: Политика и процедуры идентификации и аутентификации

Базовые показатели:

Организация: разрабатывает, документирует и распространяет [Назначение: персонал, определенный организацией или роли]: политика идентификации и аутентификации, которая касается цели, области действия, ролей, обязанностей, обязательств руководства, координации между организационными единицами и соответствия требованиям; и Процедуры, облегчающие реализацию политики идентификации и аутентификации и связанных с ней средств управления идентификацией и аутентификацией; и Просматривает и обновляет текущую:…

IA-2: Идентификация и аутентификация (организационные пользователи)

Базовый уровень(и):

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

IA-3: Идентификация и аутентификация устройств

Базовый уровень(и):

Информационная система однозначно идентифицирует и аутентифицирует [Назначение: конкретные и/или типы устройств, определяемые организацией] перед установлением [Выбора (одного или нескольких) : местный; дистанционный пульт; подключение к сети.

IA-4: Управление идентификаторами

Базовый уровень(и):

Организация управляет идентификаторами информационных систем посредством: Получения авторизации от [Назначение: персонал или роли, определяемые организацией] для назначения отдельного лица, группы, роли или идентификатора устройства ; Выбор идентификатора, идентифицирующего человека, группу, роль или устройство; Назначение идентификатора предполагаемому лицу, группе, роли или устройству; Предотвращение повторного использования идентификаторов для [Назначение: период времени, определенный организацией];…

IA-5: Управление аутентификатором

Базовый уровень(и):

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

IA-6: Обратная связь от аутентификатора

Базовый уровень(и):

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

IA-7: Аутентификация криптографического модуля

Базовая(ые) версия(и):

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

IA-8: Идентификация и аутентификация (неорганизационные пользователи)

Базовый уровень(и):

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

IA-9: Идентификация и аутентификация службы

Базовая(ые) линия(и):

(Не является частью какой-либо базовой линии)

Организация идентифицирует и аутентифицирует [Назначение: службы информационной системы, определяемые организацией], используя [Назначение: определяемые организацией услуги гарантии безопасности].

IA-10: Адаптивная идентификация и аутентификация

Базовый уровень(и):

(Не является частью какого-либо базового уровня)

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

IA-11: Повторная аутентификация

Базовый уровень(и):

(Не является частью какого-либо базового уровня)

Организация требует от пользователей и устройств повторной аутентификации, когда [Назначение: определенные организацией обстоятельства или ситуации, требующие повторной аутентификации аутентификация].

Настройка элементов управления идентификацией и проверкой подлинности для соответствия уровню FedRAMP High Impact с Azure Active Directory

IA-02	Уникальная идентификация и аутентификация пользователей или процессов, действующих от имени пользователей. Azure AD напрямую идентифицирует пользователей и объекты субъектов-служб. Azure AD предоставляет несколько методов проверки подлинности, и вы можете настроить методы, соответствующие уровню гарантии проверки подлинности (AAL) 3 Национального института стандартов и технологий (NIST). Субъекты-службы: тип ресурса ServicePrincipal: свойство ID Проверка подлинности и многофакторная проверка подлинности Достижение уровней проверки подлинности NIST с помощью платформы идентификации Microsoft
ИА-02(1) ИА-02(3)	Многофакторная проверка подлинности для любого доступа к привилегированным учетным записям. Настройте следующие элементы для полного решения, чтобы гарантировать, что для любого доступа к привилегированным учетным записям требуется многофакторная проверка подлинности. Настройте политики условного доступа, чтобы требовать многофакторную проверку подлинности для всех пользователей. Реализовать управление привилегированными пользователями Azure AD, чтобы требовать многофакторную проверку подлинности для активации назначения привилегированных ролей перед использованием. При наличии требования активации Privileged Identity Management активация привилегированной учетной записи невозможна без доступа к сети, поэтому локальный доступ никогда не является привилегированным. Многофакторная проверка подлинности и управление привилегированными пользователями Условный доступ: Требовать многофакторную проверку подлинности для всех пользователей Настройка параметров роли Azure AD в управлении привилегированными пользователями
ИА-02(2) ИА-02(4)	Реализовать многофакторную проверку подлинности для любого доступа к непривилегированным учетным записям Настройте следующие элементы в качестве общего решения, чтобы гарантировать, что для любого доступа к непривилегированным учетным записям требуется MFA. Настройте политики условного доступа, чтобы требовать MFA для всех пользователей. Настройте политики управления устройствами через MDM (например, Microsoft Intune), Microsoft Endpoint Manager (MEM) или объекты групповой политики (GPO), чтобы принудительно использовать определенные методы проверки подлинности. Настройте политики условного доступа для обеспечения соответствия устройств требованиям. Microsoft рекомендует использовать многофакторный криптографический аппаратный аутентификатор (например, ключи безопасности FIDO2, Windows Hello для бизнеса (с аппаратным доверенным платформенным модулем) или смарт-карту) для достижения AAL3.Если ваша организация полностью облачная, мы рекомендуем использовать ключи безопасности FIDO2 или Windows Hello для бизнеса. Windows Hello для бизнеса не прошла проверку на требуемый уровень безопасности FIPS 140, поэтому таким федеральным клиентам необходимо будет провести оценку рисков, прежде чем принимать ее как AAL3. Дополнительные сведения о проверке Windows Hello для бизнеса на соответствие стандарту FIPS 140 см. в документах Microsoft NIST AAL. Рекомендации относительно политик MDM немного различаются в зависимости от методов проверки подлинности. Они представлены ниже. Смарт-карта / Windows Hello для бизнеса Беспарольная стратегия — требуется Windows Hello для бизнеса или смарт-карта Требуется, чтобы устройство было помечено как совместимое Условный доступ — требуется MFA для всех пользователей Только гибрид Беспарольная стратегия — настройка учетных записей запретить аутентификацию по паролю Только смарт-карта Создать правило для отправки запроса на метод аутентификации Настройка политик аутентификации Ключ безопасности FIDO2 Беспарольная стратегия — исключение поставщика учетных данных пароля Требовать пометки устройства как совместимого Условный доступ — Требовать MFA для всех пользователей Методы аутентификации Вход без пароля в Azure Active Directory (предварительная версия) | Ключи безопасности FIDO2 Беспарольный вход с ключом безопасности Windows — Azure Active Directory ADFS: проверка подлинности сертификата с помощью Azure AD и Office 365 Как работает вход с помощью смарт-карты в Windows (Windows 10) Обзор Windows Hello для бизнеса (Windows 10) Дополнительные ресурсы: Политика CSP — управление клиентами Windows Использование сценариев PowerShell на устройствах Windows 10 в Intune Планирование развертывания проверки подлинности без пароля с помощью Azure AD
ИА-02(5)	Если несколько пользователей имеют доступ к общему или групповому паролю учетной записи, требуется, чтобы каждый пользователь сначала прошел проверку подлинности с помощью индивидуального средства проверки подлинности. Использовать отдельную учетную запись для каждого пользователя. Если требуется общая учетная запись, Azure AD разрешает привязку нескольких аутентификаторов к учетной записи, чтобы у каждого пользователя был индивидуальный аутентификатор. Ресурсы Как это работает: многофакторная проверка подлинности Azure AD Управление методами проверки подлинности для многофакторной проверки подлинности Azure AD
ИА-02(8)	Реализовать устойчивые к повторному использованию механизмы проверки подлинности для сетевого доступа к привилегированным учетным записям. Настройте политики условного доступа, чтобы требовать многофакторную проверку подлинности для всех пользователей. Все методы проверки подлинности Azure AD на уровне обеспечения проверки подлинности 2 и 3 используют либо одноразовый номер, либо вызовы и устойчивы к атакам воспроизведения. Ссылки Условный доступ: Требовать многофакторную проверку подлинности для всех пользователей Достижение уровней проверки подлинности NIST с помощью платформы идентификации Microsoft
ИА-02(11)	Реализуйте многофакторную проверку подлинности Azure AD для удаленного доступа к ресурсам, развернутым клиентом, чтобы один из факторов предоставлялся устройством, отдельным от системы, получающей доступ, если устройство соответствует FIPS-140-2, сертификации NIAP или утверждению NSA. См. руководство для IA-02(1-4). Методы проверки подлинности Azure AD, которые следует учитывать в AAL3, отвечающие отдельным требованиям к устройствам: Ключи безопасности FIDO2 Windows Hello для бизнеса с аппаратным доверенным платформенным модулем (доверенный платформенный модуль признается допустимым фактором «что-то, что у вас есть» в соответствии с разделом 5.1 NIST 800-63B). .7.1.) Смарт-карта Ссылки Достижение уровней проверки подлинности NIST с помощью платформы идентификации Microsoft NIST 800-63B Раздел 5.1.7.1
ИА-02(12)	Примите и подтвердите учетные данные проверки личности (PIV). Этот элемент управления неприменим, если клиент не развертывает учетные данные PIV. Настройте федеративную проверку подлинности с помощью служб федерации Active Directory (AD FS), чтобы принимать PIV (проверку подлинности сертификата) в качестве основного и многофакторного методов проверки подлинности и выдавать утверждение многофакторной проверки подлинности (MultipleAuthN) при использовании PIV. Настройте федеративный домен в Azure AD с помощью SupportsMFA, чтобы направлять запросы многофакторной проверки подлинности, исходящие из Azure AD, в AD FS.Кроме того, вы можете использовать PIV для входа на устройствах Windows, а затем использовать встроенную проверку подлинности Windows вместе с простым единым входом. Windows Server и клиент проверяют сертификаты по умолчанию при использовании для проверки подлинности. Ресурсы Что такое федерация с Azure AD? Настройка поддержки AD FS для проверки подлинности сертификата пользователя Настройка политики проверки подлинности Защита ресурсов с помощью многофакторной проверки подлинности Azure AD и AD FS Set-MsolDomainFederationSettings Azure
ИА-03	Реализовать идентификацию и аутентификацию устройства до установления соединения. Настройте Azure AD для идентификации и проверки подлинности устройств, зарегистрированных в Azure AD, присоединенных к Azure AD и гибридных подключенных к Azure AD. Ресурсы Что такое идентификатор устройства? Планирование развертывания устройств Azure AD Требование управляемых устройств для доступа к облачным приложениям с условным доступом
ИА-04 ИА-04(4)	Отключить идентификаторы учетных записей после 35 дней бездействия и запретить их повторное использование в течение двух лет.Управляйте индивидуальными идентификаторами, однозначно идентифицируя каждого человека (например, подрядчиков и иностранных граждан). Назначение и управление идентификаторами и состоянием отдельных учетных записей в Azure AD в соответствии с существующими политиками организации, определенными в AC-02. Следуйте инструкциям AC-02(3), чтобы автоматически отключать учетные записи пользователей и устройств после 35 дней бездействия. Убедитесь, что политика организации поддерживает все учетные записи, которые остаются в отключенном состоянии в течение как минимум двух лет. По истечении этого времени их можно удалить. Определение бездействия Управление неактивными учетными записями пользователей в Azure AD Управление устаревшими устройствами в Azure AD См. руководство AC-02
ИА-05	Настройка и управление аутентификаторами информационных систем. Azure AD поддерживает различные методы проверки подлинности. Вы можете использовать существующие организационные политики для управления. См. руководство по выбору аутентификатора в IA-02(1-4). Разрешить пользователям комбинированную регистрацию для многофакторной проверки подлинности SSPR и Azure AD и потребовать от пользователей зарегистрировать как минимум два приемлемых метода многофакторной проверки подлинности, чтобы упростить самоисправление.Вы можете отозвать настроенные пользователем аутентификаторы в любое время с помощью API методов аутентификации. Надежность средства проверки подлинности/защита содержимого средства проверки подлинности Достижение уровней гарантии проверки подлинности NIST с помощью платформы Microsoft Identity Platform Методы проверки подлинности и комбинированная регистрация Какие методы проверки подлинности и проверки доступны в Azure Active Directory? Комбинированная регистрация для SSPR и многофакторной аутентификации Azure AD Отзыв аутентификатора Обзор API методов аутентификации Azure AD
IA-05(1)	Реализовать требования аутентификации на основе пароля. В соответствии с разделом 5.1.1 NIST SP 800-63B: Ведите список часто используемых, ожидаемых или скомпрометированных паролей. При защите паролем Azure AD глобальные списки запрещенных паролей по умолчанию автоматически применяются ко всем пользователям в арендаторе Azure AD. Для поддержки вашего бизнеса и обеспечения безопасности вы можете определить записи в пользовательском списке запрещенных паролей. Когда пользователи изменяют или сбрасывают свои пароли, эти списки запрещенных паролей проверяются, чтобы обеспечить использование надежных паролей. Мы настоятельно рекомендуем стратегии без пароля.Этот элемент управления применим только к средствам проверки подлинности паролей, поэтому удаление паролей в качестве доступного средства проверки подлинности делает этот элемент управления неприменимым. Справочные документы NIST Специальная публикация NIST 800-63B Специальная публикация NIST 800-53 Редакция 5 — IA-5 — Улучшение управления (1)
IA-05(2)	Реализовать требования аутентификации на основе PKI. Объединение Azure AD через AD FS для реализации проверки подлинности на основе PKI. По умолчанию AD FS проверяет сертификаты, локально кэширует данные отзыва и сопоставляет пользователей с прошедшим проверку подлинностью удостоверением в Active Directory. Ресурсы Что такое федерация с Azure AD? Настройка поддержки AD FS для проверки подлинности сертификата пользователя
ИА-05(4)	Используйте автоматизированные инструменты для проверки требований к надежности пароля. В Azure AD реализованы автоматизированные механизмы, обеспечивающие надежность проверки подлинности пароля при создании. Этот автоматизированный механизм также можно расширить, чтобы обеспечить надежность проверки подлинности пароля для локальной службы Active Directory. Версия 5 NIST 800-53 отозвала IA-04(4) и включила это требование в IA-5(1). Ресурсы Устранение неверных паролей с помощью защиты паролем Azure AD Защита паролем Azure AD для доменных служб Active Directory Специальная публикация NIST 800-53, редакция 5 — IA-5 — Улучшение управления (4)
ИА-05(6)	Защита аутентификаторов в соответствии с определением FedRAMP High Impact level. Дополнительные сведения о том, как Azure AD защищает средства проверки подлинности, см. в разделе Вопросы безопасности данных Azure AD.
ИА-05(7)	Убедитесь, что незашифрованные статические аутентификаторы (например, пароль) не встроены в приложения или сценарии доступа или не хранятся на функциональных клавишах. Внедрить управляемые удостоверения или объекты субъектов-служб (настроены только с сертификатом). Ресурсы Что такое управляемые удостоверения для ресурсов Azure? Создайте приложение Azure AD и субъект-службу на портале
ИА-05(8)	Реализуйте меры безопасности, когда отдельные лица имеют учетные записи в нескольких информационных системах. Реализуйте единый вход, подключив все приложения к Azure AD, вместо того, чтобы иметь отдельные учетные записи в нескольких информационных системах. Что такое единый вход Azure?
ИА-05(11)	Требовать требования к качеству аппаратного токена в соответствии с требованиями уровня FedRAMP High Impact. Требовать использования аппаратных токенов, соответствующих AAL3. Достижение уровней проверки подлинности NIST с помощью платформы Microsoft Identity Platform
ИА-05(13)	Принудительное истечение срока действия кэшированных аутентификаторов. Кэшированные аутентификаторы используются для аутентификации на локальном компьютере, когда сеть недоступна. Чтобы ограничить использование кэшированных средств проверки подлинности, настройте устройства Windows, чтобы отключить их использование. Если это действие невозможно или нецелесообразно, используйте следующие компенсирующие элементы управления: Настройте элементы управления сеансом условного доступа, используя ограничения приложений для приложений Office. Настройте условный доступ с помощью элементов управления для других приложений. Ресурсы Интерактивный вход Количество предыдущих входов в кэш Элементы управления сеансом в политике условного доступа: принудительные ограничения приложений Элементы управления сеансом в политике условного доступа: управление приложениями условного доступа
ИА-06	Скрыть информацию об аутентификации во время процесса аутентификации. По умолчанию Azure AD скрывает все отзывы аутентификатора.
ИА-07	Реализовать механизмы аутентификации в криптографическом модуле, соответствующие применимым федеральным законам. Для уровня FedRAMP High Impact требуется аутентификатор AAL3. Все средства проверки подлинности, поддерживаемые Azure AD в AAL3, предоставляют механизмы для проверки подлинности доступа оператора к модулю по мере необходимости. Например, в развертывании Windows Hello для бизнеса с аппаратным доверенным платформенным модулем настройте уровень авторизации владельца доверенного платформенного модуля. Ресурсы Для получения дополнительной информации см. IA-02 (2 и 4). Достижение уровней проверки подлинности NIST с помощью платформы идентификации Microsoft Параметры групповой политики TPM
ИА-08	Информационная система однозначно идентифицирует и аутентифицирует неорганизационных пользователей (или процессы, действующие для неорганизационных пользователей). Azure AD однозначно идентифицирует и аутентифицирует пользователей, не являющихся членами организации, размещенных в арендаторе организации или во внешних каталогах, с помощью протоколов, одобренных федеральным удостоверением, учетными данными и управлением доступом (FICAM). Ресурсы Что такое совместная работа B2B в Azure Active Directory? Прямая федерация с поставщиком удостоверений для B2B Свойства гостевого пользователя B2B
IA-08(1) IA-08(4)	Принимать и проверять учетные данные PIV, выданные другими федеральными агентствами. Соответствуют профилям, выпущенным FICAM. Настройте Azure AD для приема учетных данных PIV через федерацию (OIDC, SAML) или локально с помощью встроенной проверки подлинности Windows. Ресурсы Что такое федерация с Azure AD? Настройка поддержки AD FS для проверки подлинности сертификата пользователя Что такое совместная работа B2B в Azure Active Directory? Прямая федерация с поставщиком удостоверений для B2B
IA-08(2)	Принимайте только учетные данные, одобренные FICAM. Azure AD поддерживает средства проверки подлинности NIST AAL 1, 2 и 3. Ограничьте использование средств проверки подлинности в соответствии с категорией безопасности системы, к которой осуществляется доступ. Azure AD поддерживает множество методов проверки подлинности. Ресурсы Какие методы проверки подлинности и проверки доступны в Azure Active Directory? Обзор API политики методов проверки подлинности Azure AD Достижение уровней проверки подлинности NIST с помощью платформы Microsoft Identity

Идентификация, аутентификация и авторизация (IAA)

Система идентификации, аутентификации и авторизации (IAA) Университета Висконсина предоставляет услуги управления идентификацией и аутентификации, поддерживающие безопасное развертывание приложений в учреждениях UW-System.Службы управления идентификацией и доступом IAA для утвержденных приложений включают доступ к данным в реестре IAA для управления пользователями и учетными записями, централизованную службу аутентификации (Authentication Hub), централизованную службу авторизации и общесистемное управление идентификацией UW.

Система Университета Висконсина запустила инициативу идентификации, аутентификации и авторизации (IAA) в 1996 году. Разработка инфраструктуры и пилотных приложений для белых страниц началась в 2001 году. К августу 2004 года все кампусы UW System начали предоставлять «потоки» данных в систему IAA.К началу 2005 года пять общесистемных приложений приняли IAA в качестве средства аутентификации доступа пользователей со всей системы UW.

Все данные, переданные в систему IAA кампусами UW System, и любое использование этих данных в системе IAA защищены и регулируются Меморандумом о взаимопонимании (MOU), заключенным между каждым учреждением и Системным администрированием Университета Висконсина (UWSA). Меморандум о взаимопонимании был создан Рабочей группой IAA по управлению, которая спонсируется и курируется системным администрированием UW.Группа управления установила и гарантирует соблюдение ключевых принципов управления для системы IAA:

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

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

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

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

показать службы идентификации пользователя таблицы аутентификации | ОС Junos

Домен	Имя домена, к которому принадлежат пользователи. Личность пользователя и информация об аутентификации отображается для всех пользователей, которые принадлежат к домену и для кого есть записи в указанной аутентификации исходная таблица или репозиторий.
Всего записей	Количество записей пользователей в таблице аутентификации, по домен.
Для каждой записи:
IP источника	IP-адрес устройства пользователя. Если пользователь подключен к сети более чем с одного устройства, отдельный запись создается для пользователя для каждого устройства. Он показывает устройства Айпи адрес.
Имя пользователя	Имя, под которым пользователь входит в сеть.
Группы	Список групп, к которым принадлежит пользователь. Список может включать группу, идентифицирующую положение устройства.
Государственный	Состояние записи. Есть четыре состояния для запись аутентификации: начальная, действительная, недействительная и ожидающая. Исходное состояние является временным состоянием, и его можно создать либо из действительной, либо из недействительной записи. Запись не была передана механизму пересылки пакетов. Допустимое состояние указывает на то, что запись аутентификации имеет действительный IP-адрес, домен и имя пользователя. Запись проверки подлинности помещается в систему пересылки пакетов. Двигатель. Недопустимое состояние указывает на то, что запись не имеет действительный IP-адрес, домен и имя пользователя. Если запись недействительна, ставится в нулевой домен. Состояние ожидания указывает на то, что запись была создана после запрос пользователя был отправлен и до того, как был получен ответ.То IP-адрес проверяется.
Источник	Источник аутентификации.
Дата начала доступа	Дата создания записи аутентификации устройство серии SRX.
Время начала доступа	Время создания записи аутентификации устройство серии SRX.
Отметка времени последнего обновления	Время создания информации о пользователе.Этот значение берется из поля метки времени в информации о пользователе.
Возраст время	Время в минутах, по истечении которого срок действия записи истекает, как настроено оператором аутентификации-входа-тайм-аута. Если было указано значение 0, срок действия записи не ограничен.
Время принудительного возраста	Остаточное значение и принудительное значение. Эта информация становится доступной, если вы настроите тайм-аут принудительной аутентификации брандмауэра. оператор для активного каталога.

Что такое идентификация, аутентификация и авторизация?

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

Основная терминология

Существует три часто используемых понятия (идентификация, аутентификация, авторизация) для объяснения управления доступом в кибербезопасности.Несмотря на то, что эти термины тесно связаны между собой, они имеют определенные различия, которые необходимо разъяснить, чтобы хорошо понимать правильную терминологию в области кибербезопасности. Также важно четко понимать эти концепции перед сдачей сертификационных экзаменов по кибербезопасности, таких как CompTIA Security +, CISSP (Certified Information Systems Security Professional) и т. д.

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

• A Субъект — это активный объект, который обращается к объекту. В примере пользователя, обращающегося к файлу, субъектом является пользователь. Однако субъект не обязательно должен быть живой сущностью, это также может быть программа или процесс, обращающийся к объекту.
• Объект — это пассивный компонент, к которому обращается субъект. Файлы, принтеры, компьютеры, базы данных — вот некоторые примеры объектов в механизме управления доступом.

Что такое идентификация, аутентификация и авторизация?

Что такое идентификация?

Что такое идентификация?

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

Что такое аутентификация?

Что такое аутентификация?

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

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

• Что-то известное вам (также известное как фактор аутентификации типа 1), например пароль, личный идентификационный номер (PIN) или кодовая фраза.
• То, что у вас есть (также известное как фактор аутентификации типа 2), например смарт-карта, карта памяти или токен.
• Что-то, чем вы являетесь (биометрия) (также известный как фактор аутентификации типа 3), например отпечаток пальца, топология ладони, геометрия руки, сканирование радужной оболочки/сетчатки или распознавание фазы.
• Что-то, что вы делаете (поведенческая биометрия) (также известный как фактор аутентификации типа 3), например шаблон набора текста (динамика нажатия клавиш), образец подписи (динамика подписи) или образец голоса.

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

Что такое авторизация?

Что такое авторизация?

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

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

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

Цитата: Брюс Шнайер

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

Брюс Шнайер

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

Чтобы узнать больше об аутентификации, вы также можете прочитать нашу статью Что такое многофакторная аутентификация?

---

Аутентификация и авторизация: различия и сходства

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

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

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

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

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

Что такое аутентификация?

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

• Что вы знаете : Это самый слабый фактор аутентификации, так как другие люди могут знать то, что знаете вы.
• Что у вас есть : Это обеспечивает более надежную аутентификацию, потому что кто-то должен украсть объект, который у вас есть, для аутентификации.
• Кто вы : Это самый безопасный фактор аутентификации и самый удобный для пользователя.

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

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

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

Что такое авторизация?

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

Независимо от стратегии сервер принимает эти решения за кулисами. Некоторые популярные стратегии авторизации включают в себя:

• Управление доступом на основе ролей : традиционный метод авторизации пользователя на основе групповых привилегий. Например, представителю ИТ-поддержки нужен доступ к системным процессам, но не к системе расчета заработной платы.
• Веб-токены JSON : открытый стандарт, использующий пару открытый/закрытый ключ для авторизации пользователей.
• SAML : используется в системе единого входа, включает документы XML с цифровой подписью, содержащие данные аутентификации.
• OpenID : использует сервер аутентификации в качестве посредника для проверки личности.
• OAuth : использует API для аутентификации.

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

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

Сходства

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

Отличия

Между этими двумя концепциями гораздо больше различий, как вы можете видеть на диаграмме:

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

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

В Beyond Identity мы верим в аутентификацию без пароля. Наша система заменяет пароль безопасными учетными данными на основе сертификатов X.509 и пар открытого и закрытого ключей. Beyond Identity полагается только на то, что у вас есть и кем вы являетесь, исключая любую аутентификацию на основе знаний, которая популярна среди злоумышленников.Если ваша организация придерживается стратегии нулевого доверия, вы не добьетесь этого, пока будете основывать все на фундаментально небезопасном методе аутентификации: имени пользователя и пароле.

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