Что такое идентификация и аутентификация: Обзор технологий идентификации и аутентификации

Содержание

Идентификация и аутентификация пользователя БД.

Идентификация и аутентификация пользователя БД. | Шпаргалка к написанию экзаменов

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

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

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

Что необходимо сделать, чтобы решить задачу авторизации пользователя БД
1. В предметной области определяются права (привилегии) пользователя на основе соответствующих документов (положения и инструкции по защите данных на предприятии, должностные инструкции сотрудников, соответствующие приказы и распоряжения  и т.п.).
2. В соответствии с каким-либо распоряжением по предприятию администратор БД создает в БД пользователя и присваивает ему уникальный идентификатор (логин). С идентификатором связывается пароль, известный только пользователю. (Аутентификация)
3. АБД для реализации уровней доступа заданного пользователя создает, в соответствии с проектной документацией, необходимые объекты БД (представления, роли). (Аутентификация)
4. АБД назначает (грантует) пользователю права на выполнение заданных операций над заданным объектом БД заданному пользователю. (Аутентификация)
5. Реализация в АИС процесса идентификации пользователя. Как правило, на уровне приложения: интерфейс ввода имени и пароля пользователя, формирование сообщения об отказе доступа или запуск механизма аутентификации. (Идентификация)

6 Реализация процедуры аутентификации (выполняет СУБД).

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

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

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

  • Что-то, что пользователь знает
  • Что-то, что у пользователя есть
  • Что-то, чем пользователь является.

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

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

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

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

Для защиты паролей от прослушивания, нужно применять их одностороннее шифрование, т.е. алгоритм хеширования. Хеширование это алгоритм одностороннего шифрования, при котором вычисляется контрольная сумма какого-то файла, которая всегда одна и та же, если только файл не изменён (например Sh2). Пароли в системе сохраняются в зашифрованном виде и их невозможно расшифровать к изначальному виду. Для проверки введённого пользователем пароля, пароль зашифровывается тем же алгоритмом хеширования, и полученный результат сравнивается с сохранённым в системе. Если аутентификация происходит через терминал, то на сервер не передаётся незашифрованный пароль, а применяется метод вызова-ответа (Challenge-Response) вместе с техникой шифрования.

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

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

Рисунок 2‑14. Примемение цифровой подписи (Иточник: Learning Materials for Information Technology Professionals (EUCIP-Mat))

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

Идентификация и аутентификация субъектов — Студопедия

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

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

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

В качестве идентификаторов могут использоваться, например, имя пользователя (

логин), аппаратные устройства типа Touch Memory, бесконтактные радиочастотные карты proximity, отдельные виды пластиковых карт и др.

Идентификаторы субъектов не являются секретной информацией и могут храниться в КС в открытом виде.


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

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

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

Этапы идентификации и аутентификации пользователя объединяются в единой подсистеме, называемой подсистемой идентификации и аутентификации (И/АУ).

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

Стойкость к взлому подсистемы идентификации и аутентификации

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

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

Парольные системы.

Идентификация/аутентификация с использованием технических

Идентификация, аутентификация и авторизация субъектов доступа

Стр 1 из 4Следующая ⇒

Архитектура подсистемы защиты ОС

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

Подсистема защиты ОС выполняет следующие основные функции.

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

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

3. Аудит. ОС регистрирует в специальном журнале события, потенциально опасные для поддержания безопасности системы.

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

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

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

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

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

Идентификация, аутентификация и авторизация субъектов доступа

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

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

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

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

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

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

©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.

Электронный регион

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

Минкомсвязь России в рамках инфраструктуры электронного правительства создала и развивает Единую систему идентификации и аутентификации (ЕСИА), цель которой — упорядочить и централизовать процессы регистрации, идентификации, аутентификации и авторизации пользователей.


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

Возможности учетной записи ЕСИА:

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

Регистрация в ЕСИА

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

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

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


Подтверждение личности пользователя ЕСИА

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

Пользователю предлагается три основных способа подтверждения личности:

  1. Обратиться в центр обслуживания пользователей ЕСИА, предъявив оператору ЦО документ, удостоверяющий личность (см. список центров обслуживания).
  2. Получить код подтверждения личности по почте.
  3. С помощью средства усиленной квалифицированной электронной подписи. Получить электронную подпись можно в любом аккредитованном Минкомсвязью России удостоверяющем центре

В качестве Центров обслуживания пользователей ЕСИА могут выступать:

а) федеральные органы исполнительной власти;

б) государственные внебюджетные фонды;

в) органы исполнительной власти субъектов Российской Федерации;

г) органы местного самоуправления;

д) государственные и муниципальные учреждения;

е) многофункциональные центры предоставления государственных и муниципальных услуг;

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

ISSP \ Домен 02. Управление доступом. Часть 2

В этой части рассмотрены следующие вопросы:
  • Идентификация и аутентификация
  • Управление идентификацией
  • Каталоги
  • Роль каталогов в Управлении идентификацией
  • Управление паролями
  • Синхронизация паролей
  • Система самообслуживания для сброса паролей
  • Сброс паролей с дополнительной помощью
  • Функциональность единого входа
  • Управление учетными записями
  • Инициализация
  • Обновление профиля
  • Интеграция
  • Управление доступом и языки разметки

Обновлено: 19.03.2010

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

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

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

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

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

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

Требования к идентификации. При выпуске идентификаторов для пользователей, следует учитывать следующее:
  • Каждый идентификатор должен быть уникален для обеспечения подотчетности;
  • Должна использоваться стандартная схема имен;
  • Идентификатор не должен указывать на должность или задачи пользователя;
  • Идентификатор не должен совместно использоваться несколькими пользователями.
Обзор управления доступом. Основные концепции управления доступом:
  • Идентификация
    • Субъекты предоставляют идентификационную информацию
      • Имя пользователя, идентификатор пользователя, номер счета
  • Аутентификация
    • Проверка идентификационной информации
      • Парольная фраза, PIN-код, биометрия, одноразовый пароль, обычный пароль
  • Авторизация
    • Использование критериев, определяющих операции, которые субъект может выполнять над объектом
      • «Я знаю, кто вы, что теперь мне разрешить вам делать?»
  • Подотчетность
    • Ведение и мониторинг журналов регистрации событий для отслеживания действий субъектов над объектами
Идентификация – достаточно сложная концепция, которая имеет множество нюансов (например, один и тот же человек может иметь множество различных логинов в различных системах, что может вызвать значительные сложности при попытке централизации управления доступом). Определение идентификации в сфере безопасности имеет три ключевых аспекта: уникальность (uniqueness), неявность (nondescriptive) и публикация (issuance). Уникальность подразумевает, что каждый пользователь должен иметь уникальный идентификатор (для обеспечения подотчетности). Неявность означает, что никакая из частей учетных данных не должна указывать на цель учетной записи (например, не следует использовать логины типа «administrator», «CEO», «backup_operator» и т.п.). Публикация подразумевает возможность выпуска средств идентификации другим уполномоченным органом (например, идентификационные карты).
Управление идентификацией (IdM – Identity Management) – это широкое понятие, заключающееся в использовании различных автоматизированных средств идентификации, аутентификации и авторизации пользователей.

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

Рынок продуктов управления идентификацией сегодня процветает, так как эти продукты позволяют снизить административные расходы, повысить безопасность, обеспечить соответствие требованиям и повысить уровень сервиса в масштабах всей компании. Продолжающееся повышение сложности и разнообразия сетевых сред только повышает потребности в управлении тем, кто может получить доступ, к чему и когда. Компании используют различные типы приложений, сетевых операционных систем, баз данных, ERP-систем, CRM-систем – все они используются для выполнения различных задач бизнеса. У компаний есть партнеры, консультанты, подрядчики, постоянные и временные сотрудники. Каждый из пользователей использует несколько различных видов систем для выполнения своих ежедневных задач, что делает систему управления доступом и обеспечение необходимого уровня безопасности различных типов данных весьма трудной задачей. Часто это приводит к неожиданным и невыявленным «дырам» в защите активов, дублированию и противоречию средств управления, несоответствию действующим требованиям. Целью технологий IdM является упрощение задач администрирования и наведение порядка в этом хаосе.

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

  • К чему каждый пользователь должен иметь доступ?
  • Кто дает разрешение на доступ и сам доступ?
  • Как принимаются решения о доступе в соответствии с политиками?
  • Остается ли доступ у уволенных сотрудников?
  • Как поддерживать в порядке нашу динамичную и постоянно меняющуюся среду?
  • Каков процесс отзыва прав доступа?
  • Каким образом осуществляется централизованное управление правами доступа и их мониторинг?
  • Почему сотрудники должны помнить по восемь паролей?
  • Мы имеем пять различных операционных платформ. Как нам централизовать доступ, если каждая платформа (и приложение) требует своего набора учетных данных?
  • Как мы управляем доступом наших сотрудников, клиентов, партнеров?
  • Как мы можем убедиться, что мы соответствуем необходимому набору требований?
Традиционный процесс управления доступом, осуществляющийся вручную, с использованием службы каталогов, списков контроля доступа (ACL) и профилей стал неэффективным в современных условиях, поэтому он был заменен автоматизированными приложениями с богатой функциональностью, которые работают совместно друг с другом, создавая инфраструктуру управления идентификацией. Основными целями технологий IdM является оптимизация процессов управления идентификацией, аутентификацией, авторизацией и контролем субъектов на множестве систем в рамках всей компании. Внедрение IdM в крупной компании может являться сложнейшей задачей.
На рынке существует множество решений по управлению идентификацией. В рамках CISSP нужно иметь представление о следующих типах технологий:
Большинство компаний имеют тот или иной каталог (directory), который содержит информацию о компании, ее сетевых ресурсах и пользователях. Большинство каталогов имеют формат иерархической базы данных, основаны на стандарте X.500 и имеют протокол доступа (например, LDAP — Lightweight Directory Access Protocol), позволяющий приложениям и субъектам взаимодействовать с ним. Приложения могут запросить информацию о конкретном пользователе, сделав LDAP-запрос в каталог, а пользователь аналогичным образом может запросить информацию о конкретных ресурсах.

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

В среде Windows, когда вы входите в систему, вы регистрируетесь на контроллере домена (DC — Domain Controller), который хранит в своей базе данных иерархический каталог. Эта база данных используется службой каталога (AD — Active Directory), которая организует сетевые ресурсы и выполняет функции управления доступом пользователей. Как только пользователь успешно аутентифицируется на контроллере домена, ему станут доступны определенные сетевые ресурсы (сервер печати, файловый сервер, почтовый сервер и т.д.) в соответствии с настройками AD.

Как же службе каталогов удается содержать в порядке все эти элементы? Она использует для этого пространства имен (namespace). Каждая служба каталога имеет способ идентификации и именования объектов, которыми она управляет. В базе данных, основанной на стандарте X.500 и доступной посредством LDAP, служба каталогов присваивает каждому объекту различимое имя (DN — Distinguished Name). Каждое DN представляет собой набор атрибутов, относящихся к соответствующему объекту, который хранится в каталоге как элемент. В следующем примере DN состоит из общего имени (cn — common name) и компонента домена (dc — domain component).

dn: cn=Ivan Ivanov,dc=Acme,dc=ru
cn: Ivan Ivanov
Это очень простой пример. Обычно компании имеют широкие деревья (каталоги), включающие в себя много уровней и объектов, представляющих различные департаменты, роли, пользователей и ресурсы.

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

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

  • Каталог имеет древовидную структуру организации элементов с использованием конфигурации «родительский-дочерний».
  • Каждый элемент имеет уникальное имя, состоящее из атрибутов соответствующего объекта.
  • Атрибуты, используемые в каталоге, определены схемой.
  • Уникальные идентификаторы называемые различимыми именами (DN).
Схема описывает структуру каталога, используемые в нем имена и другие вещи (схема и компоненты базы данных более глубоко описаны в Домене 09).

OU (organizational unit ) – это организационные единицы. Они используются в качестве контейнеров для других OU, пользователей и ресурсов. Они обеспечивают организационную структуру «родительский-дочерний» (иногда ее называют «дерево-лист»).

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

Роль каталогов в Управлении идентификацией


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

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

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

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

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

Рисунок 2-4 показывает основные компоненты и действия в процессе управления веб-доступом.

Рисунок 2-4.Простой пример управления веб-доступом

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ. Куки-файл в формате текстового файла может быть сохранен на жестком диске пользователя (постоянно) или может храниться только в памяти (в течении сессии). Если в куки-файле содержится какая-либо критичная информация, его следует хранить только в памяти и стирать по окончании сессии.
Пока браузер направляет куки-файл веб-серверу, Кэти не нужно предоставлять свои учетные данные при переходе к другому ресурсу. Это и есть результат работы SSO. Вы только однажды предоставляете свои учетные данные, а дальше происходит постоянная проверка наличия у вас необходимого куки-файла, который позволяет вам переходить от одного ресурса к другому. Если вы завершили сессию с веб-сервером, но вам потребовалось взаимодействовать с ним снова, вы должны повторно пройти аутентификацию, после чего вашему браузеру будет выслан новый куки-файл и все начнется с начала.
ПРИМЕЧАНИЕ. Технологии SSO будут рассмотрены далее в этом домене.
Итак, продукты WAM позволяют администратору настроить и управлять доступом к внутренним ресурсам. Этот тип управления доступом обычно используется для управления внешними сущностями (пользователями), запрашивающими доступ. Продукт WAM может работать как на единственном веб-сервере, так и на ферме серверов.
Мы рассмотрим требования к паролям, вопросы безопасности и лучшие практики далее в этом домене. Сейчас нам нужно понять, как работает управление паролями в среде IdM.

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

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

  • Синхронизация паролей (password synchronization). Уменьшает количество различных паролей от различных систем, которые нужно помнить пользователям.
  • Система самообслуживания для сброса паролей (self-service password reset). Уменьшает количество звонков в службу технической поддержки, позволяя пользователям самим сбрасывать свои пароли.
  • Сброс паролей с дополнительной помощью (assisted password reset). Упрощает процесс сброса паролей службой технической поддержки. Могут использоваться различные механизмы аутентификации (биометрия, токены).

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

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

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


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

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

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

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

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

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

Функциональность единого входа


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

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

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

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

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

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


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

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

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

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

ПРИМЕЧАНИЕ. Эти типы продуктов управления учетными записями обычно используются для сопровождения внутренних учетных записей. Управление веб-доступом используется в основном для внешних пользователей.
Как и продукты SSO, корпоративные продукты управления учетными записями обычно дороги и могут потребоваться годы, чтобы полностью внедрить их в масштабах крупной компании. Однако, требования регуляторов заставляют все большее и большее число компаний тратить деньги на такие типы решений.
Давайте немного повторим то, что мы уже знаем, так как далее мы будем основываться на этих концепциях.

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

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

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

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

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

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

Сейчас вы должны понимать, как эти различные технологии работают вместе для оптимальной реализации IdM. Каталоги предназначены для хранения информации о пользователях и ресурсах. Каталог извлекает идентификационную информацию, хранящуюся в различных местах в сети, чтобы процессы IdM могли из одного места получить все данные, необходимые им для выполнения своих задач. Инструменты управления пользователями предоставляют автоматизированные средства управления идентификаторами пользователей на всем протяжении их (идентификаторов) жизни и обеспечивают инициализацию. Инструменты управления паролями применяются для того, чтобы производительность работы сотрудника не понижалась, если он забудет свой пароль. Технологии SSO требуются внутренним пользователям для того, чтобы аутентифицироваться только один раз для доступа к любым ресурсам компании. Инструменты управления веб-доступом предоставляют средства SSO внешним пользователям и управляют доступом к веб-ресурсам. Рисунок 2-5 представляет собой наглядный пример совместной работы многих из этих компонентов.

Рисунок 2-5.Компоненты управления идентификацией


Обновление профиля


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

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

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

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

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

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

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


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

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

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

ПРИМЕЧАНИЕ. Федеративный идентификатор, как и все технологии IdM, обсуждаемые далее, обычно более сложны, чем представляется в этом тексте. Это всего лишь обзор «на один дюйм в глубину», позволяющий сдать экзамен CISSP. Для получения более глубоких сведений о технологиях IdM посетите веб-сайт автора www.logicalsecurity.com/IdentityManagement.
Кому нужно управление идентификацией? Следующий список является хорошим показателем для оценки потребности вашей компании в решениях по управлению идентификацией:
  • Если пользователи имеют более шести комбинаций имен и паролей
  • Если создание и настройка учетной записи для нового сотрудника занимает у вас более одного дня
  • Если отзыв всех прав доступа и блокировка учетной записи увольняющегося сотрудника занимает у вас более одного дня
  • Если доступ к критичным ресурсам не может быть ограничен
  • Если доступ к критичным ресурсам не может мониториться и/или периодически проверяться.
В следующих разделах рассказывается про различные типы методов аутентификации, наиболее часто используемые и интегрированные во многие современные процессы и продукты управления идентификацией.
HTML (HyperText Markup Language – гипертекстовый язык разметки) появился в начале 1990-х годов. Предшественниками HTML были SGML (стандартный обобщенный язык разметки) и GML (обобщенный язык разметки). В настоящее время HTML по-прежнему широко используется.

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

Более мощный язык разметки – XML (Extensible Markup Language – расширяемый язык разметки) – был разработан в качестве спецификации для создания различных языков разметки. Исходя из этой спецификации XML были разработаны более специфические стандарты, предоставляющие для отдельных отраслей необходимые им функции. Отдельные отрасли имеют различные потребности в использовании языков разметки, что может вызвать проблемы совместимости для компаний, которым требуется взаимодействовать друг с другом. Например, автомобильной компании нужно работать с данными о ценах, цветах, запасных частях, моделях и т.п. А компания, производящая автомобильные шины, работает с другими данными – этапах производства, спецификациях, типах синтетической резины, способах доставки для автомобильных компаний и т.п. Эти компании должны иметь возможность взаимодействия на уровне своих компьютеров и приложений. К примеру, автомобильная компания использует тег языка разметки <модель>, который определяет модель автомобиля, и шинная компания также использует тег <модель>, однако он определяет модель шин. Это приводит к возникновению проблемы совместимости. Чтобы иметь возможность взаимодействия, эти компании должны говорить на одном языке. Таким языком является XML, который должны использовать и понимать обе взаимодействующие компании. Поскольку компании используют различные типы данных, необходимые им для работы, каждая компания (либо отрасль) использует свой производный от XML стандарт, который лучше всего подходит ее потребностям.

ПРИМЕЧАНИЕ. XML используется для множества различных целей, а не только для построения веб-страниц и веб-сайтов.
Но какое все это имеет отношение к управлению доступом? Существует язык разметки, построенный на базе XML, предназначенный для обмена информацией о доступе пользователей к различным ресурсам и сервисам. Скажем, шинная компания предоставляет менеджерам автомобильной компании возможность для заказа шин. Менеджер автомобильной компании Боб регистрируется в программном обеспечении автомобильной компании и делает заказ на 40 комплектов шин. Но каким образом шинная компания узнает, что этот заказ действительно исходит от автомобильной компании и от уполномоченного на это менеджера? Программное обеспечение автомобильной компании может передавать программному обеспечению шинной компании идентификационную информацию о пользователе и группе. На основе этой информации программное обеспечение шинной компании может провести авторизацию данного запроса и реально позволит Бобу заказать 40 комплектов шин.

Языком разметки, который может обеспечить такую функциональность, является SPML (Service Provisioning Markup Language – обеспечивающий сервис язык разметки). Этот язык позволяет одной компании передавать запросы на обслуживание, а другой компании принимать их и обеспечивать (разрешать) доступ к своим сервисам. Так как и отправляющая, и принимающая компании следуют одному и тому же стандарту (XML), они могут взаимодействовать.

Если автомобильная и шинная компании имеют реализованную модель доверия и общие методы идентификации, авторизации и аутентификации, Боб может быть аутентифицирован и авторизован программным обеспечением автомобильной компании, которое передаст соответствующую информацию программному обеспечению шинной компании, и Бобу не нужно будет дважды проходить аутентификацию. Таким образом, когда Боб регистрируется в программном обеспечении автомобильной компании, он сразу же получает возможность заказа шин в шинной компании. Это означает, что автомобильная и шинная компании имеют домены безопасности, которые доверяют друг другу (это доверие может быть либо взаимным, либо односторонним). Компания, которая отправляет авторизационные данные, называется поставщиком подтверждений (producer of assertion), а получающая их компания – потребителем подтверждений (consumer of assertion).

Компании не должны принимать решения об авторизации волей-неволей. Например, разработчик XML для шинной компания должен не просто принимать решение о том, что менеджеры могут выполнять одни функции, бухгалтеры – другие функциональности, а Сью может делать все, что захочет. Компания должна иметь политики безопасности для конкретных приложений, в которых указано, какие роли и отдельные пользователи могут выполнять конкретные функции. Эти решения должны приниматься не на уровне разработчика приложений. Автомобильная и шинная компании должны следовать одинаковым политикам безопасности, чтобы когда менеджер регистрируется в приложении автомобильной компании, обе компании одинаково понимают, что может делать эта роль. Это является целью XACML (eXtensible Access Control Markup Language – расширяемого языка разметки управления доступом). Политики безопасности приложений могут совместно использоваться различными приложениями, чтобы гарантировать, что все приложения следуют одним и тем же правилам безопасности.

ПРИМЕЧАНИЕ. Кто разрабатывает и отслеживает все эти стандартизованные языки? Это делает Организация по развитию структурированных информационных стандартов (OASIS – Organization for the Advancement of Structured Information Standards). Эта организация разрабатывает и поддерживает стандарты по различным аспектам взаимодействия через веб.
Итак, подытожим эти сведения. Компаниям нужен способ управления информацией внутри их приложений. XML является стандартом, обеспечивающим структуры метаданных, которые позволяют описывать данные. Компаниям необходимо иметь возможность передавать свою информацию, для чего им целесообразно использовать XML, являющийся международным стандартом и позволяющий избежать проблем совместимости. Пользователям на стороне отправителя нужно иметь доступ к сервисам на стороне получателя, что обеспечивается с помощью SPML. Принимающая сторона должна убедиться, что пользователь, который делает запрос, надлежащим образом аутентифицирован отправляющей стороной, прежде чем она разрешит доступ к запрошенному сервису, что обеспечивается посредством SAML. Чтобы обеспечить, что отправляющая и принимающая компания следуют одним и тем же правилам безопасности, они должны следовать одинаковым политикам безопасности, что является функциональностью, обеспечиваемой XACML.
ПРИМЕЧАНИЕ. XML рассматривается в Домене 09.
Для получения дополнительной информации об этих языках разметки и их функциях, посетите следующие сайты:
Ссылки по теме:

Проверка и идентификация через ЕСИА

Единая система идентификации и аутентификации (ЕСИА) начала создаваться государством 10 лет назад. Ее основа – данные о гражданах, которые регистрируются в системе на добровольной основе, чтобы получить доступ, в первую очередь, к госуслугам. Данные о себе гражданин заполняет самостоятельно, а потом они верифицируются в эталонных источниках, идентификация один раз должна произойти очно (например, в МФЦ), после этого запись считается подтвержденной.

Идентификация через ЕСИА (на портале госуслуг) может применяться человеком для удаленного взаимодействия с налоговой службой, ПФР, МВД, службой судебных приставов, учреждениями образования и здравоохранения и т.д. По данным Минцифры на ноябрь 2020 года в ЕСИА было зарегистрировано почти 75 млн подтвержденных учетных записей.

Какие данные могут содержаться в ЕСИА?

  1. Базовая информация о личности – фамилия, имя, отчество, дата и место рождения, гражданство, пол.

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

  3. Данные документов, подтверждающих личность – общегражданский и заграничный паспорт, военный билет (если есть), СНИЛС, ИНН, свидетельство о рождении, водительское удостоверение, полис ОМС.

  4. Сведения о детях (личные данные и документы).

  5. Данные о принадлежащих гражданину транспортных средствах (госномер ТС и номер свидетельства о регистрации).

  6. Сведения об юридических лицах и ИП (их в ЕСИА совсем немного, для удостоверения этих данных лучше пользоваться ЕГРЮЛ).

  7. Сведения о выпущенных квалифицированных электронных подписях.

  8. Результаты тестов на COVID-19 и т.д.

Однако гражданин не обязан заполнять все поля в ЕСИА. Например, если у гражданина есть автомобиль, то он может не вносить эти сведения, но при этом получить доступ к госуслугам. Но в целом ЕСИА – одна из самых полных баз о гражданах РФ.

Идентификация в ЕСИА для бизнеса

Доступ к ЕСИА для бизнеса ограничен. По закону осуществлять идентификацию клиентов в ЕСИА имеют право финансовые организации, операторы связи, медицинские организации и удостоверяющие центры. Для некоторых видов бизнеса идентификация клиентов через ЕСИА критична. Например, для услуг телемедицины идентификация, как доктора, так и пациентов возможна только через ЕСИА (подобный сервис был реализован IDX для группы компаний ИНВИТРО).

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

IDX предлагает два вида сервисов с использованием ЕСИА:

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

  2. Проверка через ЕСИА данных о человеке. В этом случае заказчик поставляет данные, которые верифицируются в ЕСИА. В результате заказчик получает информацию о корректности данных, ID в ЕСИА и статус аккаунта. Кроме валидации данных (прежде всего, паспортных), можно подтвердить телефонный номер и e-mail. Это позволяет идентифицировать личность с той же степенью надежности, как и в первом способе по логину-паролю.

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

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

6.4.1 Системы идентификации и аутентификации

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

  • Проверка подлинности Kerberos с использованием идентификаторов и паролей SUNet.

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

(1) Идентификатор университета и обычный личный идентификатор SUNet
Право на участие в службе аутентификации начинается, когда человек принимает предложение о регистрации или трудоустройстве студента. Право на участие заканчивается, когда прекращается активное сотрудничество человека с Университетом; я.е., когда сотрудник больше не работает (и не имеет почетного статуса) или студент больше не зарегистрирован. При определенных обстоятельствах может быть разрешен льготный период в качестве любезности после окончания права на участие. См. Раздел «ИТ-процедуры университета».
(2) Спонсируемый SUNet ID
Спонсируемый SUNet ID спонсируется на определенный период времени. Спонсор определяет продолжительность спонсорства; спонсорство должно быть возобновлено, чтобы идентификатор оставался действительным. Льготного периода нет: запись становится недействительной сразу по окончании периода спонсорства.
(3) Повторная активация
Запись может быть возобновлена, если человек впоследствии снова присоединится к Университету, либо через регулярную ассоциацию, либо через спонсорство.
(4) Подвеска
Использование аутентификационной записи может быть отменено, если она используется способом, несовместимым с политиками Стэнфордского университета, или если к лицу применяются другие административные меры, лишающие его университетских привилегий.

г. Обязанности пользователя
(1) Официальные действия
Использование службы аутентификации для идентификации себя в онлайн-системе представляет собой официальную идентификацию пользователя для Университета так же, как и предъявление идентификационной карты.Пользователи могут нести ответственность за все действия, предпринятые во время аутентифицированных сеансов.
(2) Целостность
Независимо от используемого метода аутентификации, пользователи должны использовать только ту информацию аутентификации, которую им разрешено использовать; то есть никогда не должны ложно идентифицировать себя как другое физическое или юридическое лицо.
(3) Конфиденциальность
Независимо от используемого метода аутентификации пользователи должны сохранять конфиденциальность своей аутентификационной информации; я.е., не должны сознательно или по небрежности предоставлять его для использования неуполномоченным лицом.
(4) Сообщения о проблемах
Любой, кто подозревает, что его аутентификационная информация была скомпрометирована, должен связаться с отделом информационной безопасности по адресу [email protected], ввести запрос о помощи или позвонить в Стэнфордскую службу ИТ-обслуживания по телефону 650-725-4357.
(5) Меры безопасности
Пользователям настоятельно рекомендуется регулярно менять свой пароль (не реже одного раза в три месяца), чтобы ограничить возможное злоупотребление паролями, которые могли быть взломаны без ведома пользователя.Пароли следует выбирать так, чтобы их было трудно угадать; например, не основываться на имени или дате рождения пользователя.
(6) Дисциплинарные меры
Лица, умышленно нарушившие одно из этих положений, будут подвергнуты дисциплинарным взысканиям. Возможные дисциплинарные меры за нарушения, которые могут включать увольнение с работы или получение статуса студента, будут зависеть от фактов и обстоятельств каждого дела.

Идентификация, аутентификация и авторизация — получить сертификат Get Ahead

Если вы изучаете один из сертификатов безопасности, например CISSP, SSCP или Security +, важно понимать разницу между идентификацией, аутентификацией и авторизацией.Эти понятия взаимосвязаны, но имеют определенные различия. При рассмотрении этих тем, особенно для экзаменов SSCP и CISSP, важно понимать различия между предметами и объектами.

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

Сдать экзамен Security + при первой сдаче.
CompTIA Security +: получить сертификацию Получите вперед: SY0-401 Учебное пособие


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

Безопасность + пакет полного доступа

Проходи с первого раза!

Актуальный контент

Новый множественный выбор и основанный на производительности вопросы добавляются регулярно

Пройдите первый раз с качественными практическими тестовыми вопросами, вопросами на основе успеваемости, дидактическими карточками и аудио.

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

Доступ на 60 дней

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

Все материалы доступны в Интернете сразу после оплаты.

Получите учебный пакет «Безопасность + полный доступ» здесь

Наши онлайн-учебные материалы «Безопасность +» являются идеальным дополнением к CompTIA Security +: получить сертификацию Get Ahead: SY0-601 Study Guide. Их также можно использовать, чтобы убедиться, что вы готовы, независимо от того, какое учебное пособие вы используете.

Этот экзамен стоит дорого.

Убедитесь, что вы готовы к экзамену.

Вот что вы получите:
  • Все вопросы с несколькими вариантами ответов из бестселлера CompTIA Security +: Get Certified Get Ahead: SY0-601 Study Guide. Смотрите демо здесь. Все вопросы имеют подробные объяснения, поэтому вы будете знать, почему правильные ответы правильные, а неправильные — неправильные.
  • Реалистичные SY0-601 Вопросы безопасности + практические тесты
  • Вопросы, связанные с производительностью.
  • Все карточки из учебного пособия. Просматривайте их в любом веб-браузере.См. Демонстрацию здесь
  • Все аудио из учебного пособия.
  • Доступ к бесплатному коду скидки 10% на ваш ваучер Security +.

Купите учебный пакет с полным доступом сегодня

Доступ на 60 дней

Все материалы доступны в Интернете вскоре после оплаты.

Получите пакет для изучения Security + Full Access здесь


Ищете качественные практические тестовые вопросы для экзамена SY0-401 Security +?
CompTIA Security +: получить сертификацию Get Ahead- SY0-401 Вопросы практического теста


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

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

  • Что-то, что вы знаете , например пароль или PIN-код
  • Что-то, что у вас есть , например, умный карта, CAC, PIV или токен RSA
  • Что-то, чем вы являетесь , с использованием биометрии

Security + (SY0-601) Вопросы практического теста

SY0-601 Вопросы практического теста

Более 385 реалистичных вопросов безопасности + практического теста

Не менее 10 вопросов, связанных с производительностью.

Все вопросы включают пояснения, чтобы вы знали, почему правильные ответы верны,

и почему неправильные ответы неверны.

Обновите свое резюме с помощью системы безопасности + новая версия

Несколько форматов викторин, чтобы вы могли использовать эти вопросы в зависимости от того, как вы учитесь.
  • Режим обучения — случайный . Просматривайте каждый из вопросов в произвольном порядке. Режим обучения позволяет вам продолжать выбирать ответы, пока вы не выберете правильный ответ. Как только вы выберете правильный ответ, вы увидите объяснение. Щелкните здесь, чтобы узнать, как работает режим обучения.
  • Тестовый режим — случайный . Просматривайте каждый из вопросов в произвольном порядке.В тестовом режиме вы можете увидеть правильные ответы и объяснения только после завершения теста. Щелкните здесь, чтобы увидеть, как работает тестовый режим.
  • Тестовый режим — 75 случайных вопросов . Просмотрите 75 случайных вопросов из полного банка тестов, аналогично тому, как экзамен Security + имеет максимум 75 вопросов с несколькими вариантами ответов.

Пройдите с первого раза

Получите полный набор вопросов практического теста SY0-601 здесь

Щелкните здесь, если вы ищете пакет онлайн-обучения SY0-501

Пакет безопасности + полный доступ

Проходи с первого раза!

Актуальный контент

Новый множественный выбор и основанный на производительности вопросы добавляются регулярно

Пройдите первый раз с качественными практическими тестовыми вопросами, вопросами на основе успеваемости, дидактическими карточками и аудио.

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

Доступ на 60 дней

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

Все материалы доступны в Интернете сразу после оплаты.

Получите учебный пакет «Безопасность + полный доступ» здесь

Наши учебные материалы по онлайн-безопасности + являются идеальным дополнением к CompTIA Security +: получить сертификацию Get Ahead: SY0-501 Study Guide.Их также можно использовать, чтобы убедиться, что вы готовы, независимо от того, какое учебное пособие вы используете.

Этот экзамен стоит дорого.

Убедитесь, что вы готовы к экзамену.

Вот что вы получите:
  • Все вопросы с несколькими вариантами ответов из бестселлера CompTIA Security +: Get Certified Get Ahead: SY0-501 Study Guide. Смотрите демо здесь. Все вопросы имеют подробные объяснения, поэтому вы будете знать, почему правильные ответы правильные, а неправильные — неправильные.
  • Более 40 новых вопросов с несколькими вариантами ответов, которые мы добавили после публикации учебного пособия.
  • Более 30 вопросов по результатам. Смотрите демо здесь.
  • Все карточки из учебного пособия. Просматривайте их в любом веб-браузере.
  • Все аудио из учебного пособия. Послушайте образец здесь.
  • Доступ к бесплатному коду скидки 10% на ваш ваучер Security +.

Купите учебный пакет с полным доступом сегодня

Доступ на 60 дней

Все материалы доступны в Интернете вскоре после оплаты.

Получите пакет исследования безопасности + полный доступ здесь


Изучаете SSCP?
В этой книге рассматриваются новые цели, вступающие в силу с 1 февраля 2012 г.
Руководство по комплексному экзамену для сертифицированного специалиста по безопасности систем SSCP


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

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

Другие ресурсы по безопасности + учеба

Приложения для ваших мобильных устройств

Основные вопросы по безопасности и производительности Видео

Другие ресурсы по безопасности + учеба

Более пристальный взгляд на NIST 800-171: Идентификация и аутентификация

Пятое семейство требований стандарта NIST 800-171 — это идентификация и аутентификация.Это семейство описывает, как ваши авторизованные пользователи проверяются до того, как они получат доступ к вашей системе.

Почему важны идентификация и аутентификация?

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

Что такое идентификация и аутентификация в NIST 800-171?

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

  1. Проверьте личность любого человека или устройства, имеющего доступ к вашей системе — убедитесь, что информация для входа в систему соответствует известному авторизованному пользователю и что любые устройства, которые получают доступ к вашей системе, могут быть отслежены до назначенного и авторизованного пользователя.
  2. Обеспечьте соблюдение протоколов минимальной сложности для паролей — помогите авторизованным пользователям защитить свои пароли с помощью политики паролей. Протоколы сложности паролей устанавливают, какой длины должны быть пароли, а также цифры, прописные буквы или специальные символы (!, @, * И т. Д.) являются обязательными.
  3. Использовать многофакторную аутентификацию для доступа к сети — включите как минимум двухфакторную аутентификацию, для которой требуется другой инструмент аутентификации в дополнение к логину и паролю. Это может быть либо числовой код, отправленный на мобильное устройство пользователя, либо сканер отпечатков пальцев.
  4. Установить время ожидания доступа для отключения доступа после периода бездействия учетной записи — установите время ожидания сеанса, при котором сетевое соединение будет автоматически закрыто по истечении указанного времени. Это помешает пользователю поддерживать открытое соединение с вашими данными, если он не работает в системе активно.

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

Кэтрин Беннетт возглавляет группу по разработке инструкций для партнера NCMEP, NC State Industry Expansion Solutions. Она также работает менеджером проектов в сфере учебных услуг. Кэтрин играет ключевую лидирующую роль в поддержке цели IES по предоставлению учебных материалов и опыта разработки, которые дополняют отраслевые знания партнеров IES, одновременно удовлетворяя образовательные потребности целевых аудиторий.Кэтрин имеет степень бакалавра компьютерных наук Университета Северной Каролины в Шарлотте и степень магистра педагогических технологий Университета Восточной Каролины.

Идентификация, аутентификация, авторизация — в чем разница —

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

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

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

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

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

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

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

В целом, акт установления чьей-либо личности известен как идентификация.

Почему важна идентификация пользователя?

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

Идентификация выгодна для организаций, так как это:

  • Легко интегрируется в различные системы
  • Недорого
  • Служит сдерживающим фактором для самозванцев

Типы идентификации

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

Некоторые другие допустимые формы идентификации включают:

  1. Что-то, что знает человек: Пароль, PIN-код, девичья фамилия матери или комбинация замка.Аутентификация человека с помощью того, что он уже знает, вероятно, самый простой вариант, но один из наименее безопасных.
  2. Что-то, что есть у человека: Ключ, считывающая карта, карта доступа или значок — все это примеры предметов, которыми может владеть человек. Этот метод обычно используется для получения доступа к таким объектам, как банки и офисы, но он также может использоваться для получения доступа к конфиденциальным местоположениям или проверки учетных данных системы. Это тоже простой вариант, но эти предметы легко украсть.
  3. Что-то, чем является человек: Биометрические данные человека являются уникальными и не могут быть потеряны или украдены. Использование биометрии для идентификации кого-либо — самый точный и безопасный вариант.

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

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

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

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

  • Однофакторная аутентификация
  • Двухфакторная аутентификация
  • Многофакторная аутентификация

Почему важна аутентификация пользователя?

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

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

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

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

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

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

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

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

Некоторые распространенные типы биометрической аутентификации:

  • Распознавание голоса
  • Распознавание лиц
  • Отпечаток
  • Отпечаток ладони

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

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

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

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

Почему важна авторизация?

Авторизация определяет, что пользователь может делать и видеть в ваших помещениях, сетях или системах.Итак, какова польза от авторизации?

  • Предотвращает доступ пользователей к чужой учетной записи
  • Запрещает посетителям и сотрудникам доступ к защищенным зонам
  • Обеспечивает недоступность всех функций для бесплатных учетных записей
  • Обеспечивает доступ внутренних учетных записей только к необходимой информации

Способы авторизации

Авторизация может быть выполнена разными способами, в том числе:

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

Basic Auth: Basic Auth — это еще один тип авторизации, при котором отправитель должен ввести имя пользователя и пароль в заголовок запроса. Base64 — это метод кодирования, который превращает логин и пароль в набор из 64 символов для обеспечения безопасной доставки.

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

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

Заключение

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

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

Управление идентификацией и аутентификацией людей и устройств — CISSP: Домен 5 — Управление идентификацией и доступом (IAM)

Мы собираемся продолжить обсуждение в Разделе 2 «Управление идентификацией и аутентификацией людей и устройств». Итак, этот процесс получения доступа, мы собираемся исследовать, как он на самом деле происходит. Это возможность доступа к информации и управления ею, и она должна быть активирована в процессе инициализации после утверждения руководством.Как я описал ранее, процесс определения того, что может потребоваться конкретному предмету, должен быть отделен от фактического осуществления этой потребности. Итак, процесс начинается с идентификации, которая представляет собой логическую или физическую характеристику, используемую в качестве подтверждения личности. Затем следует проверка подлинности, которая предлагается для проверки этого утверждения и преобразования его в удостоверение. Мы следуем за этим с помощью авторизации, которая связывает эту личность, однажды установленную, с привилегированным профилем или профилем возможностей.И, конечно же, она должна заканчиваться подотчетностью, которая включает в себя две задачи. Один из них — это учет, то есть запись всех доступов и других действий, которые будет совершать личность, и аудит, который представляет собой просмотр всех записей таких действий.

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

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

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

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

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

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

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

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

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

Некоторые формы, которые мы находим очень часто, представляют собой RFID-метки, которые не содержат интегральной схемы. Они сделаны из волокнистых материалов, которые отражают часть сигнала считывающего устройства, и уникальный обратный сигнал может использоваться в качестве идентификатора.Это тип, который мы обычно находим в книгах в таких магазинах, как Barnes and Noble. Читатель, имеющий форму пистолета, излучает луч, бирка отражает луч обратно к читателю, и тогда читатель может почувствовать, какие книги находятся на полках, вместо того, чтобы физически пересчитать их все, и может обнаружить книги, у которых есть были сбиты с толку с большой легкостью.

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

Однако системы

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по идентификации и аутентификации в доверенных системах

Руководство по пониманию идентификации и аутентификации в доверенных системах
                                                              NCSC-TG-017
                                                       Библиотека № 5-235,479
                                                                  Версия 1

                                   ПРЕДИСЛОВИЕ
Руководство по идентификации и аутентификации в доверенных системах
предоставляет набор передовых практик, связанных с идентификацией и аутентификацией (I&A).Мы написали это руководство, чтобы помочь сообществу поставщиков и экспертов по оценке:
соответствовать требованиям I&A, а также уровню детализации, необходимому для
Я & А на всех классах, как описано в Надежных компьютерных системах Министерства обороны.
Критерии оценки. В целях обеспечения руководства мы даем рекомендации в
это техническое руководство, не являющееся требованиями Критериев.

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

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

 Я приглашаю ваши предложения по пересмотру этого технического руководства. Мы рассмотрим это
документ по мере необходимости.






Патрик Р. ГАЛЛАХЕР-МЛАДШИЙ. 1 сентября 1991 г.
Директор
Национальный центр компьютерной безопасности
 
БЛАГОДАРНОСТИ Национальный центр компьютерной безопасности пользуется особым признанием и благодарность Джеймсу Андерсону и лейтенантуCoI. Рэйфорд Вон (США) как соавторы этого документа. Лейтенант Патриция Р. Тот (USN) получила признание за разработку этого руководства, и капитан Джеймс А. Муйзенберг (USAF) признан за его редактирование и публикация. Мы хотим поблагодарить многих членов сообщества компьютерной безопасности, которые с энтузиазмом посвятили свое время и технический опыт изучению этого руководства и предоставление ценных комментариев и предложений. ii
ОГЛАВЛЕНИЕ ПРЕДИСЛОВИЕ................................................. БЛАГОДАРНОСТИ 11 1.0 ВВЕДЕНИЕ 1 1.1 Предпосылки 1 1.2 Цель 1 1.3 Объем 1 1.4 Цель управления 2 2.0 ОБЗОР ПРИНЦИПОВ 3 2.1 Цель I&A 3 2.2 Процесс I&A 4 2.3 Аспекты эффективной аутентификации 5 2.4 Безопасность аутентификационных данных 9 3.0 СОБЛЮДЕНИЕ ТРЕБОВАНИЙ TCSEG 11 3.1 C1 Требования 11 3.1.1 Требования к I&A 11 3.1.2 Другие связанные требования 11 3.1.3 Комментарии 11 3.2 Требования C2 12 3.2.1 Требования к I&A 12 3.2.2 Другие связанные требования 12 3.2.3 Комментарии 13 3.3 81 Требования 14 3.3.1 Требования к I&A 14 3.3.2 Другие связанные требования 14 3.3.3 Комментарии 15 3.4 82 Требования 15 3.4.1 Требования к I&A 15 3.4.2 Другие связанные требования 16 3.4.3 Комментарии 16 3.5 83 (и A1) Требования 16 3.5.1 Требования к I&A 16 3.5.2 Другие связанные требования 17 3.5.3 Комментарии 17 iii
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ 4.0 ВОЗМОЖНЫЕ МЕТОДЫ РЕАЛИЗАЦИИ 19 4.1 Что-то, что знает пользователь (метод типа 1) 19 4.2 Что-то, что есть у пользователя (метод типа 2) 20 4.3 Что-то, чем является пользователь (метод типа 3) 21 4.4 Комментарии 21 ГЛОССАРИЙ 25 БИБЛИОГРАФИЯ 29 iv
1.0 ВВЕДЕНИЕ 1.1 ИСТОРИЯ ВОПРОСА Основная цель Национального центра компьютерной безопасности (NCSC) состоит в том, чтобы мужество повсеместной доступности надежных компьютерных систем. В подтверждение этого цель NCSC создал метрику, DoD Trusted Computer System Evaluation Cri- teria (TCSEC) [3], по которым можно оценивать компьютерные системы. TCSEC был первоначально опубликован 15 августа 1983 года как CSC-STD-001-83. В В декабре 1985 г. Министерство обороны приняло его с некоторыми изменениями в качестве Стандарт Министерства обороны США, DoD 5200.28-СТД. Директива Министерства обороны США 5200.28, Securi- ty Требования к автоматическим информационным системам (A 155) [11], требует TCSEC использоваться во всем Министерстве обороны. TCSEC - это стандарт, используемый для оценки эффективности мер безопасности, встроенных в DoD AlS. TCSEC разделен на четыре отдела: D, C, B и A. Эти подразделения упорядочены в иерархическом порядке, с высшим разделом (A), зарезервированным для системы, обеспечивающие наилучший доступный уровень уверенности и безопасности.Внутри подразделений C и B - это подразделения, известные как классы, которые также упорядочены в иерархическом порядке. способ представления различных уровней безопасности в этих подразделениях. 1.2 ЦЕЛЬ Этот документ предоставляет поставщикам руководство по разработке и внедрению эффективные механизмы идентификации и аутентификации (l & A) в своих системах. Это также написан, чтобы помочь поставщикам и оценщикам понять требования I&A. Экзамен- Содержащиеся в этом документе не являются единственным способом идентификации или аутентификации. тикация.Рекомендации не являются дополнительными требованиями к TCSEC. Единственной мерой соответствия TCSEC является сам TCSEC. 1.3 ОБЪЕМ Компьютерная безопасность основана на понятии контроля доступа между Пользователи AlS и данные в AlS. Концепция контролируемого доступа основана на установление идентифицирующей информации для пользователей AlS, чтобы эта информация могла использоваться для определения того, имеет ли пользователь надлежащий допуск или удостоверение личности, чтобы принять получить доступ к заданному объекту данных.Таким образом, требования I&A являются центральными для
ИДЕНТИФИКАЦИЯ И РУКОВОДСТВО ПО Аутентификации системы идентификации и аутентификации пользователей, и, таким образом, обеспечение соблюдения Политики обязательного контроля доступа (MAC) и дискреционного контроля доступа (DAC). I&A также предоставляет механизму аудита информацию, необходимую для связи отношения с конкретными пользователями. 1.4 ЦЕЛЬ КОНТРОЛЯ Идентификация является частью цели контроля подотчетности.Подотчетность цель управления гласит: "Системы, которые используются для обработки или обработки секретной или другой конфиденциальной информации. обязательство должно гарантировать индивидуальную подотчетность всякий раз, когда обязательное или дискреционное активирована обычная политика безопасности. Кроме того, для обеспечения подотчетности возможность должен существовать для авторизованного и компетентного агента для доступа и оценки учетной записи - информацию о возможностях безопасным способом, в разумные сроки и без- из неоправданных трудностей."[3, с. 76] Основное требование идентификации гласит: «Отдельные субъекты должны быть идентифицированы. Каждый доступ к информации должен быть медиа- редактируется в зависимости от того, кто имеет доступ к информации и какие классы информации они уполномочены иметь дело с. Эта идентификационная и авторизационная информация должна быть надежно поддерживаются компьютерной системой и связаны с каждым активным элемент, который выполняет в системе какое-либо действие, связанное с безопасностью."[3, стр. 4] 2
2.0 ОБЗОР ПРИНЦИПОВ Требования к идентификации и аутентификации встречаются во всех оценочные классы. Они напрямую связаны в том смысле, что «идентификация» - это утверждение кто пользователь (всемирно известный), тогда как «аутентификация» является доказательством идентификации. Аутентификация - это процесс подтверждения заявленной личности.Процедура l & A- Характеристики системы имеют решающее значение для правильной работы всех других доверенных вычислений. базовые (TCIS) функции безопасности. 2.1 ЦЕЛЬ ИиП Эффективность процедур I&A напрямую влияет на возможности других УТС. механизмы для выполнения своей функции. Например, сила механизма аудита. и уверенность в правильности аудита зависит от механизма контроля и аудита. низм. Если L&A успешно обойти, то все проверенные действия станут ненадежными. возможно, потому что неверный идентификатор может быть связан с проверяемыми действиями.В этом В смысле, требование l&A является основой для других функциональных требований TClB. (Рисунок 1). TCB, используя структуры данных, относящиеся к безопасности, контролирует доступ к системе, де- прекращает авторизованный доступ к объектам в системе и связывает проверенные действия * с конкретными людьми в зависимости от их личности. При контроле доступа к системе TCIS действует как первая линия защиты. Как только TCIS идентифицирует пользователя как уникальную сущность или члена группы, она затем точно определяет, какие права доступа могут быть назначены пользователю повторно. Spect к данным, защищаемым системой.Если система имеет рейтинг С1, сгруппируйте AUDIT DAC MAC; ИДЕНТИФИКАЦИЯ И АУТЕНТИФИКАЦИЯ #Рисунок 1 Аудит механизмов & A начинается с C2. 3
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ членство обеспечивает достаточную степень детализации для выполнения требований L&A.В Системы с рейтингом C2 или выше, принудительное исполнение должно осуществляться на уровне отдельного пользователя. Системы на уровнях B и A применяют политику обязательного контроля доступа и используют механизм l&A для установления авторизованного уровня или уровней безопасности, на которых пользователь будет работать во время данного сеанса. Личность пользователя определяет, какие функции или привилегии он может выполнять. безопасность в системе. В некоторых системах (например, системах транзакций) функциональный доступ может быть преобладающим выражением политики безопасности.Распространенный случай функционального доступ во многих системах - это контроль доступа к офису безопасности системы. функции cer, основанные на его личности. Назначение устройства также может определять функции или привилегии пользователя. может тренироваться по системе. Например, те же физические механизмы, защищающие системное оборудование обычно защищает устройство, обычно называемое "контролем оператора". sole. "Пользователь этого устройства обычно подвергается более строгому физическому контролю и административные процедуры, чем другие пользователи системы.В некоторых случаях ac- доступ к устройству подразумевает физический доступ к данным (всем носителям), которые УТС отвечает за защиту. В системах с рейтингом B1 и ниже требования l и A может быть расслаблено для пользователя пульта оператора, если устройство защищено те же механизмы физической безопасности, защищающие саму систему. Функции аудита в доверенных системах являются обязанностью УТС. Безусловно, аккуратно идентификация рейтинга отдельного пользователя необходима для правильной атрибуции действий принимаются системой от имени человека.Опять же, сила l&A механизм напрямую влияет на надежность и уверенность в правильности аудиторских функций. 2.2 ПРОЦЕСС L&A Процесс идентификации и аутентификации (обычно называемый «Iogin») начинается с пользователь устанавливает связь с TCB. (В B2 и выше TCB это выполняется путем вызова доверенного пути, который гарантированно является незыблемым ---------------------------- * Дискреционный контроль доступа, применяемый на уровне C и выше, зависит от эффективных и надежный я и А.** См. Интерпретации ct -cl-02-83 и ci -cl-04-86 в NCSC DockMaster Eva __Announcements Форум. B2 и выше требуют, чтобы оператор входил в систему, но вход оператора в систему не является обязательным в B1 и ниже. 4
ОБЗОР ПРИНЦИПОВ канал связи между пользователем и TCIS). Используя TCIS, пользователь идентифицирует себя (т.е., претензии - личность). Либо как часть передача, требующая идентичности, или в ответ на запрос от TCIS, пользователь предоставляет один или несколько элементов аутентификации в качестве подтверждения личности. TCIS, используя заявленные элементы идентификации и аутентификации в качестве параметров, проверяет предоставленную информацию по базе данных аутентификации. Если информация- От пользователя выполняется процесс проверки TClB, TCIS завершает вход в систему путем установления пользовательского сеанса и связывания личности пользователя и разрешения доступа троллить информацию с этим сеансом.В системах C1-C2 эта информация управления доступом может быть просто записью личности пользователя для сравнения с информацией управления доступом. связь с файлами. В системах 191-Al TClIS также связывает определенный уровень безопасности (в допустимом диапазоне для пользователя) с сеансом пользователя для использования в принятие решений об обязательном управлении доступом. На уровне C2 и выше TCB может регистрировать (проверять) успех или неудачу новый логин. Если вход прошел успешно, TCB выполняет все необходимые действия, чтобы установить сеанс пользователя.2.3 АСПЕКТЫ ЭФФЕКТИВНОЙ АУТЕНТИФИКАЦИИ Личность пользователей проверяется одним из трех общих методов: что-то они знают (тип 1), что-то, что у них есть (тип 2), или то, чем они являются (тип 3). Хотя требованиям TCSEC может соответствовать ОДИН из этих различных методы, системы, использующие два или более методов, могут привести к большей безопасности системы. Системы, использующие только один метод аутентификации, могут быть более уязвимы для заражения. обещание аутентификатора, поэтому предпочтительны несколько методов.Примеры механизмов типа 1 включают пароли, парольные фразы, PIN-коды (Per- личные идентификационные номера), а также данные о себе или членах семьи. Тип 2 механизмы включают настоящие и электронные ключи, генераторы вызовов resport.se и карточки или бейджи с магнитной полосой. В последнюю категорию, тип 3, входят отпечатки пальцев, не подлежащие повторному использованию. паттерны, паттерны ДНК и геометрия рук. Чтобы быть эффективными, механизмы аутентификации должны быть уникальными и надежными. идентифицировать человека.«Аутентификация по знанию» (тип 1) и «аутентификация по механизмы собственности »(тип 2) ограничены в эффективности только потому, что общается с человеком одержимостью. Человек обладает знаниями или какими-то 5
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ Тип 1 = аутентификация посредством знаний (то, что они знают) Тип 2 = Аутентификация по собственности (что-то, что у них есть) Тип 3 = аутентификация по признаку (что-то такое) фигура 2 идентифицирующий объект, но поскольку пользователь физически не привязан к аутентификации информации, аутентификационная информация может быть утеряна, украдена или иным образом передана. обещал.Что отличает первые два типа, так это то, насколько эффективно каждый из них может быть защищен; у каждого есть свои преимущества и недостатки. Основная слабость типа 1 - двойная катион. Мало того, что обычно очень легко выучить что-то, что знает кто-то другой, но и возможно, информацию удастся угадать, даже не имея к ней доступа. Нет специальные инструменты, навыки или оборудование требуются для дублирования "аутентификации по знанию" край ". Часто можно сломать его простой атакой методом перебора с использованием автозапуска. совмещенные техники.Самым важным преимуществом этого типа аутентификации является следующее: пользователь может взять его где угодно и изменить при возникновении компромисса. An- другим преимуществом является его простота, поскольку такая информация имеет тенденцию легко быть представлена. ед. в УТС без спец. оборудования. Любые данные аутентификации в конечном итоге должны быть закодированы в той или иной форме в базе данных аутентификации TCB, и в этом смысле копия информации должна храниться в TCB, чтобы ее можно было использовать при аутентификации.Поскольку символьная строка обычно может представлять тип 1, ее легко сохранить для дальнейшего использования. использование УТС. Хотя тип 1 легко скопировать, если он действительно уникальный, например чушь слово или число, его может быть легче охранять, чем физический объект. Это потому что элемент знания, хотя его легко скопировать, всегда полностью принадлежит человека, которого он идентифицирует. В отличие от ключа, карты или другого физического устройства "аутентификация по знанию «нельзя украсть, временно оставив сидеть на столе, не может произойти- счетчик выпадает из кармана, и его часто нельзя насильно украсть, если только человек не украдет он может проверить его правильность.Тем не менее, простота дублирования делает тип 1 всегда несовершенная форма аутентификации и, следовательно, требует добросовестной защиты, чтобы повторно главный эффективный. 6
ОБЗОР ПРИНЦИПОВ Для сравнения: «аутентификация по владению» имеет большую силу в трудностях. культ дублирования. Тип 1, по сути, является примером типа 2. Поэтому, когда мы говорим о Тип 2 мы будем, по соглашению, иметь в виду физический объект, а не элемент знания. край.Хотя такие предметы требуют больше усилий для защиты от кражи, их можно сделать с использованием специального оборудования или процедур, которые обычно недоступны. Следовательно, dupli- их выявление обходится дороже, чем ценность всего, что может быть получено путем фальсификации их. Это препятствует их дублированию, хотя и не обязательно предотвращает их дублирование. соединение решительным злоумышленником. Третий тип аутентификации, "аутентификация по характеристикам", очень сильнее первых двух.В конце концов, цель аутентификации - проверить, кто вы есть, и тип 3 очень тесно с этим связан. Основным препятствием для этого типа аутентификации является сложность затрат на строительство. эффективные периферийные устройства, которые могут получить достаточно полный образец характеристики чтобы полностью отличить одного человека от другого. Стоимость также является фактором определения тип 2. Но в типе 3 сам элемент аутентификации может быть разработан для упрощения идентификации. фиксация УТС.Обычные компьютерные периферийные устройства обычно не могут быть легко подключены. код «аутентификация по признаку». Хотя может быть легко создать устройства, которые подтвердить чьи-то отличительные особенности, такие как вес или длина пальца, дополнительные Более подробная информация, позволяющая полностью отличить одного человека от другого, может служить основанием для tially увеличить стоимость. К счастью, достаточно уникальная идентификация не требует каждой детали. о человеке. Таким образом, специальные методы, такие как снятие отпечатков пальцев или сканирование сетчатки глаза может использоваться отдельно, что снижает затраты по сравнению с полным исследованием всех физические атрибуты человека.Даже эти методы требуют больших затрат, чем простые использование пароля, которое не требует вообще никакого дополнительного оборудования, и они не гарантированно будет безошибочным. Например, однояйцевые близнецы не будут различимы. считывателями ДНК, и могут быть не различимы другими спецификациями тестов физического характеристики. В воображаемом случае полностью идентичных близнецов эти два человека могут отличаться исключительно по признакам категории "аутентификация посредством знания". кровавый.Мало того, что различные типы методов аутентификации имеют стоимость и осуществимость - компромиссы, но адекватная уверенность в аутентификации может потребовать нескольких методов од. (Каждый из них подвержен ошибкам на самом теоретическом уровне.) Можно было бы 7
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ ожидать большей уверенности от комбинации механизмов типа 1 и типа 2, чем либо используется отдельно.Точно так же тип 3 может обеспечить большую уверенность, чем комбинация. ция типов 1 и 2 вместе. Возможные варианты подхода показаны на рисунке 3, где тип 12 представляет использование механизмов типа 1 и типа 2. Прямые сравнения силовых отношений невозможны, если никто не знает точный механизм реализации; однако можно предположить, что некоторые такие дружеские отношения вероятны. Кто-то может возразить, что тип 2 сильнее, чем члены типа олово гарантия, и тип 123, вероятно, сильнее, чем тип 12.Необычные механизмы может предложить необходимую уверенность на более низких уровнях, тогда как более высокие уровни могут потребовать комбинации для достижения адекватной уверенности. Возможные подходы аутентификации Тип I Тип 12 Тип 2 Тип 13 Тип 23 Тип 3 Тип 1 = аутентификация по знаниям Тип 2 = аутентификация по владению Тип 3 = аутентификация по признаку фигура 3 8
ОБЗОР ПРИНЦИПОВ 2.4 БЕЗОПАСНОСТЬ АУТЕНТИФИКАЦИОННЫХ ДАННЫХ Данные идентификации и аутентификации (как и большинство передач) уязвимы для перехват (например, подслушивание, спуфинг) злоумышленником, находящимся между пользователь и УТС. Как следствие, связь между пользователем и трастом - компьютер требует защиты, соизмеримой с конфиденциальностью данных, системные процессы. В соответствии с правительственными постановлениями, системы, используемые для обработки классификационных данные должны соответствовать строгим стандартам физической безопасности, которые включают защиту подключение терминала к TCB.(Эта защита может включать в себя установку компьютер и его терминалы в физически безопасном месте, защищая кабельные каналы от между терминалами и компьютером или с использованием криптографии для защиты транзакции. Для несекретных систем может потребоваться аналогичная защита. Кроме того, 192 и системы с более высоким рейтингом должны иметь надежные пути. Сети предоставляют злоумышленникам множество возможностей для перехвата данных L&A. Одноразовые пароли могут помочь защититься от такой возможности.Данные аутентификации пользователя должны храниться, защищаться и поддерживаться УТС. Он должен быть доступен только сотруднику службы безопасности системы (550). Тем не мение, даже 550 следует запретить видеть фактическую текстовую версию данных (например, пароли, используемые пользователями.) Чтобы убедиться, что только 550 может входить в открывать и управлять базой данных l&A, уникальным и, возможно, расширенным специальным 550 процедура идентификации и аутентификации должна быть встроена в TCB.В УТС следует использовать эту процедуру для проверки идентичности 550 (и, возможно, используемое устройство), когда этот человек ведет базу данных L&A. Помимо перехвата, действия оператора или несанкционированный физический доступ может поставить под угрозу I&A данные. Это может быть сделано путем неправильного обращения с автономными версиями данные в таких формах, как файлы резервных копий системы, дампы системы, вызванные сбоями, или списки ings. Чтобы защитить данные I&A от такого рода несанкционированного раскрытия, данные могут быть хранится в зашифрованном виде.Несколько так называемых односторонних преобразований (необратимых functions) аутентификационных данных, которые могут выполнять эту функцию (см. Purdy [10]). Однако, если кто-то использует односторонние преобразования, важно, чтобы оно было истинным не- обратимое преобразование. Пример того, как произвольное одностороннее преобразование был сломан, см. статью Дауни [4]. 9
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ База данных аутентификации нуждается в защите от общего доступа, независимо от того, база данных зашифрована или нет.Даже в зашифрованном виде база данных может быть объект к "атаке по каталогу". (Такая атака была очень успешной в ноябре Бер 1988 ИНТЕРНЕТ-атака программой сетевого червя. [5]) Атака по каталогу осуществляется путем шифрования словаря вероятных данных аутентификации (например, пароль слова). Затем злоумышленник сопоставляет шифрованные тексты базы данных аутентификации. с зашифрованным текстом словаря для обнаружения законных аутентификаторов. Если данные- база хранит как идентификацию пользователя, так и аутентификацию в зашифрованном виде, злоумышленник должен найти идентификатор пользователя И аутентификатор (например,g., пароль) в КОМБИНАЦИЯ. Однако необходимость защиты механизма трансформации повторно сеть. 10
3.0 СОБЛЮДЕНИЕ ТРЕБОВАНИЙ TCSEC В этой главе описаны требования TCSEC к I&A и их взаимодействие. ции с соответствующими требованиями TCSEC.3.1 С1 ТРЕБОВАНИЯ 3.1.1 Требования к I&A «2.1.2.1 Идентификация и аутентификация TCB должен требовать, чтобы пользователи идентифицировали себя с ним перед началом выполнения любые другие действия, посредничество которых ожидается от УТС. Кроме того, УТС должно использовать защищенный механизм (например, пароли) для аутентификации личности пользователя. TCB должен защищать данные аутентификации таким образом, чтобы к ним не мог получить доступ посторонний. авторизованный пользователь ". 3.1.2 Другие связанные требования «2.1.1.1 Дискреционный контроль доступа Механизм правоприменения (например, личный / групповой / общественный контроль, контроль доступа списки) должны позволять пользователям определять и контролировать совместное использование этих объектов с помощью именованных diviauals или определенные группы или и то, и другое ". 3.1.3 Комментарии Соответствующее требование дискреционного контроля доступа (DAC), позволяющее пользователям совместное использование управления определенными группами означает, что достаточно идентифицировать пользователей как память бер группы.Индивидуальная идентификация НЕ требуется для C1. Таким образом, допустимо иметь коллективную идентификацию, такую ​​как "Покупка", аутентифицированную паролем, троллинг доступ к файлу закупок. TCSEC не требует дополнительной информации. А без индивидуального учета аудит невозможен или не требуется. Что такое достаточная аутентификация? Это сложный вопрос, поскольку он взаимодействует критически с тем, как используется доверенная система, в сочетании с гарантиями и особенности дизайна, связанные с рейтингами.(См. Руководство по применению Depart- Критерии оценки доверенных компьютерных систем в конкретной среде [7].) Требование C1 определяет только использование защищенного механизма. 11
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ и дает, например, пароли. Как обсуждалось в другом месте данного руководства, пароли могут быть эффективным механизмом аутентификации, если их применять добросовестно.3.2 ТРЕБОВАНИЯ C2 3.2.1 Требования к I&A «2.2.2.1 Идентификация и аутентификация TCB должен требовать от пользователей идентифицировать себя перед началом выполнения любые другие действия, посредничество которых ожидается от УТС. Кроме того, УТС должно использовать защищенный механизм (например, пароли) для аутентификации личности пользователя. TCB должен защищать данные аутентификации таким образом, чтобы к ним не мог получить доступ посторонний. авторизованный пользователь. УТС должно иметь возможность обеспечить индивидуальную ответственность путем предоставление возможности однозначно идентифицировать каждого отдельного пользователя системы ADI.TCB также должен обеспечивать возможность связывания этого идентификатора со всеми автоматическими устройствами. соответствующие действия, предпринятые этим лицом ". 3.2.2 Другие связанные требования «2.2.1.1 Дискреционный контроль доступа Механизм правоприменения. . . позволяет пользователям определять и контролировать совместное использование ing оф. . . объекты по. . . определенные группы лиц. . . . Эти доступ к тролли должны иметь возможность включать или исключать доступ к детализации Один пользователь.. «2.2.2.2 Аудит ... УТС должно иметь возможность записывать следующие типы событий: использование идентификатора механизмы фиксации и аутентификации, ... действия, предпринятые оператором компьютера торов и системных администраторов и / или сотрудников службы безопасности системы. . . . Для каждого зарегистрированное событие, в протоколе аудита должны быть указаны: дата и время события, пользователь, тип события и успех или неудача мероприятия. Для идентификации / события аутентификации источник запроса (например,g., ID терминала) должны быть включены в протоколе аудита. . . . Системный администратор ADP должен иметь возможность выбирать: проводить аудит ... одного или нескольких пользователей на основе индивидуальной идентичности ". 12
СООТВЕТСТВИЕ ТРЕБОВАНИЯМ 7CSC 3.2.3 Комментарии Начиная с уровня C2, идентифицируются отдельные пользователи. Контроль доступа повторно требование требует использования индивидуальной идентичности для принятия решений о доступе.lf групповой доступен контроль доступа, членство в группе основано на личности человек, а не пользователь, предоставляющий имя группы с помощью аутентификатора. Это важное различие. С идентификатором группы, коллективным именем и общей аутентификацией. катор действителен. С индивидуальными идентификаторами, уникальный индивидуальный идентификатор, проверенный через уникальная аутентификация, используется для определения членства в группе, при этом группа затем идентификация используется для доступа к данным.В этой последней реализации система может проверять действия человека, тем самым обеспечивая индивидуальную подотчетность. Требование аудита - ужесточение требования к индивидуальной идентичности. Это означает, что системный администратор может проверять действия одного или нескольких нас- эры, основанные на индивидуальной идентичности. L&A должны различать операторов, системных администраторов. tors, и офицеры безопасности системы от обычных пользователей для записи безопасности связанные события как действия, инициированные лицами, выполняющими эти роли.Поскольку в- лица, выполняющие эти роли, также могут быть обычными пользователями системы, это необходимо essary, чтобы различать людей, когда они действуют как обычные пользователи. Например, в одной (сетевой) системе с множеством лиц, выполняющих рекламные задачи министра или сотрудника службы безопасности, система установила идентификатор, связанный с выполняемой ролью (например, системный администратор (SA)). В расширенном журнале- включен, произошла двухэтапная идентификация и аутентификация; сначала как SA, а затем как человек, выполняющий эту роль.Если человек не был признан одним из тех, кто авторизовал функции SA, вход в систему завершился, и система провела аудит мероприятие. Записи аудита действий, предпринятых SA, включали индивидуальные личность. Последующая проверка записей аудита позволила собрать все действия SA в упорядоченном по времени порядке. В рамках функции SA система определила лица, выполняющие роль SA. Поскольку это было очень большое международное время- система совместного использования, два или более человека могут выполнять функции SA совершенно независимо. однозначно друг друга.Система записывала все их действия под идентификатором SA, и в каждой записи были личности лиц, фактически выполняющих функция. 13
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ Наконец, соответствующее требование аудита требует идентификации происхождения документов и документов. События. Приведенный пример взят из терминала, но в некоторых системах это может быть хранимая пакетная процедура (PROC в некоторых системах), активируемая оператором -оператором из пульт оператора.В этом случае запись аудита должна содержать как оператор идентификатор консоли и указание на то, что оператор выполнил задание для некоторого человека, указанного в пакетная процедура. К источнику соединения часто присоединяется идентификатор пользователя. ty, чтобы убедиться, что местоположение терминала одобрено для обработки секретных материалов на авторизованный уровень пользователя. 3.3 ТРЕБОВАНИЯ B1 3.3.1 Требования к I&A «3.1.2.1 Идентификация и аутентификация TCB должен требовать от пользователей идентифицировать себя перед началом выполнения любые другие действия, посредничество которых ожидается от УТС.Кроме того, УТС должно поддерживать данные аутентификации, которые включают информацию для проверки личности отдельных пользователей (например, пароли), а также информацию для определения допуск и авторизация отдельных пользователей. Эти данные будут использоваться TCB для аутентификации личности пользователя и обеспечения уровня безопасности и полномочия субъектов, внешних по отношению к УТС, которые могут быть созданы для действий от имени отдельного пользователя преобладают разрешения и авторизация этого пользователя.TCB должен защищать данные аутентификации, чтобы к ним нельзя было получить доступ. sed любым неавторизованным пользователем. УТС должно иметь возможность принудительно применять индивидуальную учетную запись: способность, предоставляя возможность однозначно идентифицировать каждую отдельную систему ADP Пользователь. TCB также должен обеспечивать возможность связывания этого идентификатора со всеми автоматическими устройствами. соответствующие действия, предпринятые этим лицом ". 3.3.2 Другие связанные требования «3.1.1.4 Обязательный контроль доступа ... Идентификационные и аутентификационные данные должны использоваться УТС для аутентификации. установить личность пользователя и убедиться, что уровень безопасности и авторизация субъектов, внешних по отношению к УТС, которые могут быть созданы, чтобы действовать от имени ин- у отдельного пользователя преобладает допуск и авторизация этого пользователя." 14
СООТВЕТСТВИЕ ТРЕБОВАНИЯМ TCSEC 3.3.3 Комментарии B1 - это первый уровень рейтинга, на котором управление доступом и перемещением данных на основе уровни чувствительности субъектов и объектов. Для непривилегированного пользователя & Данные используются для определения текущего уровня авторизации пользователя, который TCB сравнивается со своей пользовательской базой данных, содержащей диапазоны авторизации для каждого пользователя.Если информация для входа в систему верна и его уровень действителен, TCB позволяет ему в системе. Затем TCB модерирует доступ к файлам в зависимости от текущего уровня пользователя и метка файла или объекта, к которому пытается добраться пользователь. Поскольку уровень чувствительности представлен разрешением и категорией доступа, а также разрешениями на доступ к объекту. Сознание определяется чувствительностью, связанной с обоими объектами (за пределами УТС) и объект, авторизация субъекта становится компонентом авто- требование к трактовке.Значение термина «авторизация» в этом разделе включает функциональные роли, назначенные отдельным лицам. Авторизации, связанные с ролями пользователей (например, SA, 550, оператор) определяют режимы доступа, которые могут или не могут контролироваться политика обработки меток (или MAC), в зависимости от конкретной системы. Можно иметь систему, в которой пользователь, действующий как авторизованный 550, может добавлять новых пользователей, де- lete пользователей, или изменить их данные аутентификации, чтобы увеличить или уменьшить их расширенный доступ, и все это без какой-либо метки конфиденциальности, связанной с записями или 550-е акции.Такие действия, конечно, подлежат проверке. Лучший подход использует механизмы MAC для обеспечения дополнительной поддержки для наименее привилегированных административных легенда. Здесь пользователь, как 550, по-прежнему должен входить в систему на любом уровне необходимо делать свою работу. 3.4 ТРЕБОВАНИЯ B2 3.4.1 Требования к I&A «3.2.2.1 Идентификация и аутентификация TCB должен требовать от пользователей идентифицировать себя перед началом выполнения любые другие действия, посредничество которых ожидается от УТС.Кроме того, УТС должно поддерживать данные аутентификации, которые включают информацию для проверки личности индивидов. визуальные пользователи (например, пароли) в качестве информации для определения допуска и авторизация отдельных пользователей. Эти данные должны использоваться УТС для аутентификации: указать личность пользователя и убедиться, что уровень безопасности и авторизация 15
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ субъекты, внешние по отношению к УТС, которые могут быть созданы, чтобы действовать от имени отдельного лица. пользователем преобладают допуск и авторизация этого пользователя.УТС должно защищать данные аутентификации, чтобы к ним не мог получить доступ неавторизованный пользователь. УТС должно иметь возможность обеспечивать индивидуальную подотчетность, предоставляя возможность для уникальной идентификации каждого отдельного пользователя системы ADP. УТС также предоставляет возможность связать эту личность со всеми проверяемыми действиями, предпринимаемыми этим лицом. ual. " «3.2.2.1.1 Надежный путь TCB должен поддерживать доверенный канал связи между собой и [] пользователь для первоначального входа в систему и аутентификации.Связь по этому пути должна быть инициирован исключительно пользователем ". 3.4.2 Другие связанные требования «3.2.3.1.4 Trusted Facility Management УТС должно поддерживать отдельные функции оператора и администратора ». 3.4.3 Комментарии Требование доверенного пути - главное дополнение на этом уровне. Уровень B2 это первый уровень рейтинга, обеспечивающий достаточную архитектурную поддержку доверенных путей в операционная система. Это требование гарантирует, что на уровне B2 и выше индивид визуальный вход пользователя в систему - это безупречная связь с TCB, а не какая-то программа маскируется под УТС.В противном случае пользователь может быть подделан на раскрытие информации. передать свои данные аутентификации прикладной программе. Требование поддержки отдельных функций оператора и администратора может возложить дополнительную нагрузку на функцию l & A, чтобы различать лиц, действующих в эти роли. С этой целью (функциональные) авторизации, связанные с аутентификацией. данные о катионах из требования B1 могут быть эффективно использованы. 3.5 ТРЕБОВАНИЯ B3 (И A1) 3.5.1 l & A Требования «3.3.2.1 Идентификация и аутентификация TCB должен требовать от пользователей идентифицировать себя перед началом выполнения любые другие действия, посредничество которых ожидается от УТС. Кроме того, УТС должно 16
СООТВЕТСТВИЕ ТРЕБОВАНИЯМ TCSEC поддерживать данные аутентификации, которые включают информацию для проверки личности индивидов. виртуальные пользователи (например,g., пароли), а также информацию для определения зазора и авторизация отдельных пользователей. Эти данные должны использоваться УТС для аутентификации: указать личность пользователя и убедиться, что уровень безопасности и авторизация субъекты, внешние по отношению к УТС, которые могут быть созданы, чтобы действовать от имени отдельного лица. пользователем преобладают допуск и авторизация этого пользователя. УТС должно защищать данные аутентификации, чтобы к ним не мог получить доступ неавторизованный пользователь.УТС должно иметь возможность обеспечивать индивидуальную подотчетность, предоставляя возможность для уникальной идентификации каждого отдельного пользователя системы ADP. УТС также предоставляет возможность связать эту личность со всеми проверяемыми действиями, предпринимаемыми этим лицом. ual. " «3.3.2.1.1 Надежный путь TCB должен поддерживать доверенный канал связи между собой и пользователями для используйте, когда требуется положительное соединение TCB-to-user (например, вход в систему, изменение уровень безопасности предмета).Связь через этот доверенный путь должна быть активирована ex- исключительно пользователем или TCB и должны быть логически изолированы и безошибочно отличим от других путей ". 3.5.2 Другие связанные требования «3.3.1.1 Дискреционный контроль доступа TCB должен определять и контролировать доступ между именованными пользователями и именованными объектами. (например, файлы и программы). . . . Эти средства управления доступом должны быть способны определять: для каждого именованного объекта список именованных лиц и список групп именованные лица с их соответствующими режимами доступа к этому объекту.Шерсть- Кроме того, для каждого такого именованного объекта должна быть возможность указать список поименованные лица и список групп поименованных лиц, в отношении которых нет доступа доступ к объекту должен быть предоставлен .... " 3.5.3 Комментарии Использование доверенного пути обобщается на случай, когда [когда-либо] положительный TCB-to-user требуется соединение "не только для входа в систему. В 193 системах другие TCB-to-user общаются. связи могут продолжаться, отсюда и требование логически изолировать и различать уберите НАДЕЖНЫЙ путь от всех других путей.Обратите внимание, что TCB может запускать доверенный путь при необходимости. 17
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ Различие между надежным путем в B3 и надежным путем в B2 зависит от нужно ли TCB знать о предыдущем контексте. В случае B2 единственный требование для доверенного пути есть у Иогина. В случае B3 доверенный путь может быть повторно требуется, чтобы пользователь изменил уровни безопасности или инициировал другой процесс на другом уровне. уровень безопасности ниже того, в котором он сейчас находится.Пример TCB, запускающего доверенный путь может сообщать пользователю, что его уровень безопасности был изменен по запросу - изд. Основное влияние этого требования - установление доверенного пути. между пользователем (то есть физическим лицом) и УТС, а не субъектом процесса или какими-либо другими эр пользователь-суррогаты. Для человека, подключающегося к TCB, так же важно быть как- удостовериться в идентичности TCB, как для TCB, чтобы быть уверенным в идентичности человек.Ранее работа в области компьютерной безопасности предполагала повторную аутентификацию в качестве гарантийный механизм для случаев такого рода. Если в системе есть такая возможность- Обычно время между (повторными) аутентификациями должно быть параметром конфигурации. Соответствующее требование дискреционного контроля доступа состоит из двух компонентов; во-первых, каждый именованный объект (уже управляемый элементами управления обязательным доступом) должен также находиться под контролем Дискреционного доступа. Во-вторых, списки названных лиц или группы, авторизованные или специально запрещенные в доступе, должны поддерживаться для каждого названного объект.18
4.0 ВОЗМОЖНЫЕ МЕТОДЫ РЕАЛИЗАЦИИ Существует множество возможных методов реализации `для идентификации и аутентификация людей. Задача разработчика TCB заключается в том, как интегрировать выбранный метод в остальной конструкции УТС таким образом, чтобы выбранная технология- nique нельзя обойти или проникнуть внутрь.Самый частый метод выявления лиц по-прежнему является заявленной идентичностью, подтвержденной паролем. Разумный обсуждение вопросов проведено Хоффманом [8], хотя и не полностью Spect ко всем проблемам. Следующее обсуждение служит хорошим экзаменом. ples или только общие рекомендации. Есть много других приемлемых методов l&A. 4.1 ЧТО-ТО ЗНАЕТ ПОЛЬЗОВАТЕЛЯ (МЕТОД ТИПА 1) Этот метод почти полностью ориентирован на пароли.В прошлом восемь символов пароли были более или менее стандартом для большинства систем, предоставляющих пользователю идентификации и аутентификации, хотя не существует определенного стандарта для длина слова. Руководство Министерства обороны по управлению паролями [2] rec- заменяет не менее шести символов. В двух приложениях к этому руководству обсуждается параметры, влияющие на выбор длины пароля. В руководстве также настоятельно рекомендуется автоматизировать создание паролей.А Описание генератора произносимых паролей можно найти в статье Гассера. по [6]. Как указывалось выше, для низших классов достаточно простых паролей. По мере продвижения в рейтинге система паролей или парольных фраз должна быть: приходят более сложные. В старших классах схема паролей должна быть некоторые варианты схем одноразовых паролей или комбинация методов, как показано на рисунке 3. В схеме одноразового пароля система предоставляет пользователю начальную пароль для подтверждения заявленной личности.Во время первоначального Иогона пользователь получает новый пароль для следующего входа в систему. В самой ранней концепции этого приложения кстати, никого не беспокоило прослушивание телефонных линий, перехватывающих проход пользователей. словами, поскольку все линии находились в пределах защищенных проводных путей. Единственное беспокойство было за кто-то маскируется под другого пользователя, не будучи обнаруженным, или для пользователей, написавших: сбрасывая свои пароли, чтобы они их не забыли. 19
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ В современных приложениях, особенно с персональными компьютерами, используемыми в качестве терминалов, TCB может зашифровать следующий пароль для пользователя; Пользователь получит свой следующий пароль, расшифруйте его (личным, уникальным) ключом дешифрования и сохраните для своего следующая сессия.Другие предложения включают хранение личных данных о человеке, например о вашем девичья фамилия бабушки, возраст твоего отца, когда он был женат, средний имя вашей третьей сестры и т. д. Этот метод не соответствует требованиям TCSEC. по целому ряду причин. Сложно управлять любым разумным количеством пользователей, и, даже если рандомизировать задачу, общее количество доступных swers слишком мал. Личная информация, относящаяся к физическому лицу, обычно доступна. доступный из открытых источников и не защищенный.4.2 ЧТО-ТО ЕСТЬ У ПОЛЬЗОВАТЕЛЯ (МЕТОД ТИПА 2) Этот тип содержит несколько артефактных подходов к обеспечению позитивной идентичности пользователей. Схемы охватывают широкий диапазон, от считывателей магнитных полос до различных формы ключей зажигания (некоторые с криптографическими подсистемами, другие просто альтернативные формы считывателя магнитных полос). Интересная форма выражения «что-то есть», объединяет артефакт со схемой пароля, типизируется одноразовым паролем (вызов и ответ) устройство.Устройство представляет собой блок размером с калькулятор, который при нажатии правильно пользователем с личным идентификационным номером (PIN), генерирует правильный одноразовый ответ на запрос пароля, выданный хостом сервера. Одно только владение устройством не позволяет получить правильную реакцию на случайный вызов. Чтобы использовать артефакт, необходимо знать ПИН-код. Есть нет известного способа прочитать PIN-коды, установленные в этом конкретном продукте, поэтому потеря устройства может быть скорее неудобством, чем серьезным нарушением безопасности, если сообщить: Эд немедленно.Хотя вполне возможно, что такие устройства могут быть украдены у законного пользователя, Нарушение прав может быть управляемым, если пользователь не сообщит об убытках немедленно - Либо или по неосторожности записывает ПИН-код. Кроме того, если усилить механизм при стандартном парольном подходе для формирования метода типа 12 можно получить много большая уверенность. 20
ВОЗМОЖНЫЕ МЕТОДЫ РЕАЛИЗАЦИИ Существует тенденция требовать полной безопасности для простых устройств (запирать их в сейфы или ограничение места их ношения).Во многих случаях все, что нужно, - это возможность обнаружения утери или взлома устройства. 4.3 ПОЛЬЗОВАТЕЛЬ (МЕТОД ТИПА 3) Эта категория аутентификации включает в себя все биометрические схемы, такие как считыватели отпечатков пальцев, считыватели отпечатков на губах, сканеры сетчатки глаза, анализаторы ДНК и динамические подписи читателей. Некоторые утверждают, что эти устройства обладают значительной разрешающей способностью, практически исключая ложное принятие, сохраняя при этом ложные отказы по причине - способный уровень.Однако статистический характер принятия или отклонения в некоторой степени ограничен. вещь для рассмотрения. Мы отметили ранее, что аутентификацию можно удвоить. механизмы для систем с более высоким рейтингом, поэтому аутентификация основана на двух независимых элементы вмятины, например считыватель отпечатков пальцев и пароль (метод типа 13). Такая схема фактически исключила бы ложное принятие процедуры l&A. В двойная схема аутентификации, система не должна принимать ни один из элементы, если другой элемент также не правильный.Продавцам биометрических устройств приходится труднее, чем тем, кто палатку с простыми паролями, так как изменить биометрический измеряемый параметр. Однако можно скопировать биометрическую па- rameter таким образом, чтобы получить доступ к системе, как если бы она была фактическим пользователем. Если злоумышленник встает между измерительным прибором и УТС, отсутствует защищенный путь, он может скопировать чтение для воспроизведения позже.Как это может быть возможно независимо от используемого метода аутентификации, это предполагает либо мак- одноразовый элемент аутентификации или защита пути между аутентификациями. вход катиона (измерение) и TCB против перехвата. 4.4 КОММЕНТАРИИ Требования к идентификации и аутентификации сильно подчеркнуты в направление аутентификации. Один заявляет личность, затем должен доказать это оператору. система ing. «Теоретически» возможно использовать самоидентифицирующуюся аутентификацию (или можно было бы назвать самоутентификационной идентификацией).Примерами таких может быть --------------- * Мартин в своей книге сообщил о ложном приеме распознавателя голоса на уровне 1% и геометрии руки. считыватель от 0,5 до 0,05%, в зависимости от допусков измерения. У распознавателя голоса был ложный отклонение 1%, в то время как считыватель геометрии руки был «очень низким». [9] 21 год
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ сканер отпечатков пальцев или анализ ДНК клеток, соскобленных с кожи.Конечно это всегда (и, вероятно, ошибочно) предполагал, что можно сохранить целостность своей кожа или отпечатки пальцев. Тем не менее, возможно, удастся скопировать отпечатки пальцев на латексную пленку. пальцем (или пальцами), и получить участок кожи может быть не так сложно, как могу представить. Даже для самоидентификационной аутентификации защита аутентификации катионный механизм является ключом к его успешному применению. Как указано выше, если применяется в ситуациях, требующих применения более низкого рейтинга классы, такие методы, которые сочетают идентификацию и аутентификацию, вполне могут быть достаточным.В ситуациях, когда требуются более высокие классы, методы могут быть в сочетании с другим универсальным аутентификатором. Фактически это создает второй доступ барьер для систем, используемых в ситуациях повышенного риска. На сегодняшний день вопрос о том, сколько аутентификации будет достаточным, должным образом не решен. и является предметом обсуждения между аккредитатором сайта или специалистом по сертификации сайта и продавец. Может потребоваться несколько механизмов аутентификации для любого заявленная идентичность для систем более высокого уровня.Как бы эффективно ни было такое требование может быть, это было бы довольно дорого для множества систем, НЕ на специальных опасности, но которые используют системы с рейтингом B2 или выше в квазисистеме высокой среды из-за условий обработки этикеток. (Квазисистемная высокая среда Это те, где всем пользователям даются все допуски и категории в пределах организации, но данные должны быть правильно помечены, чтобы контролировать, где они экспортировано.) один встроенный в УТС.Основная рекомендация - использовать другой базовый механизм. низм. Если встроенный аутентификатор основан на аутентификации по характеристикам, & Подсистема может быть либо аутентификацией по владению (тип 2), либо аутентификацией. ция по знаниям (тип 1). Расхожее мнение гласит, что системы паролей можно достаточно хорошо, но могут потребоваться более эффективные средства аутентификации. В общем, можно было бы ожидать, что в системах с более низким рейтингом будут использоваться более простые механизмы. системы, чем системы с более высоким рейтингом.В C1, простые механизмы типа 1 или любой из простейшие схемы артефактов (например, комбинации замков или ключи от запертых дверей для терминальные помещения для пользователей, известных системе только как определенные группы) может быть достаточно, в зависимости от сайта, на котором используется система. В C2 любая из произвольно произносимых систем паролей или любая из аналогичных объектный артефакт (например, таблица ответов на запрос) или биометрические системы (например, 22
ВОЗМОЖНЫЕ МЕТОДЫ РЕАЛИЗАЦИИ измерение геометрии руки, межглазного расстояния или других мер Бертильона) кажется подходящим.В B1 парольные фразы, произвольно произносимые пароли длиной не менее 8 символов, схемы запрос-ответ, одноразовые пароли, расширенные артефакты (например, термин nal Iogon «ключи» или карты с магнитной полосой) или биометрические системы (например, отпечатки пальцев, изображения сетчатки глаза или голосовые изображения). Для более высоких уровней (B2, 03 и Al) аутентификация может быть основана как минимум на два из трех общих способов подтверждения личности. Карточка с магнитной полосой и пароль, PIN-код, используемый для запуска устройства запроса-ответа, или биометрического устройства и пароль могут использоваться в комбинации для увеличения «рабочего фактора» at- соблазн подорвать или диагностировать параметры аутентификации.Хотя это специально не рассматривается в TCSEC, процесс оценки должен рассмотрите силу механизма l&A по отношению к классу оценки. В гарантия, связанная с выбранным механизмом, должна соответствовать оценке: съел класс. Кроме того, прочность механизма L&A также должна основываться на среда, в которой будет использоваться система, и риск потери данных в системе Тем. Помните, возможно, что система C2, работающая на высоком уровне системы, с очень конфиденциальные данные нуждаются в высоконадежном механизме l&A так же, как и в системе Al бы.Интересно отметить, что системы паролей редко дают сбой. их функции в защищаемых системах. Большая часть сбоев паролей происходит из-за неправильных выполнение, обмен паролями с иным неуполномоченным лицом, или меньшее обращение с паролями (по крайней мере, столь же серьезное, как и такое же неосторожное обращение с безопасные комбинации). Некоторые агентства относятся к небрежному обращению с паролями с помощью такая же серьезность, как оставлять сейфы незапертыми и без присмотра.Для нескольких В системах tilevel, обрабатывающих секретные данные, пароль классифицируется на самом высоком уровне. el информации авторизовал пользователя, которому она принадлежит. Правильно управлять схемой паролей можно с помощью частой смены пароля. слова и произносимый генератор случайных паролей, используемый для устранения некоторых более простые атаки на угадывание. Это правда, что люди могут неправильно использовать систему, не лечя свои пароли должным образом (например, написав их на своих терминалах, намеренно 23
РУКОВОДСТВО ПО ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ раздавать их или позволять наблюдать за ними при использовании).Тем не менее меньше, низкая стоимость и высокая степень эффективности делают пароли аутентификационными. ционный метод выбора для большинства систем. Если пользователям разрешено выбирать свои собственные определенные аутентификаторы, их поведение достаточно стереотипный, чтобы позволить диагностировать и восстановить выбранный подлинный тион. Это особенно верно в отношении систем, позволяющих пользователям выбирать свои собственные пароли. Как следствие, техника системного администратора, выполняющая (начальную) Использование аутентификатора - лучшая практика безопасности, чем кажется на первый взгляд.24
ГЛОССАРИЙ ОБЕСПЕЧЕНИЕ Мера уверенности в том, что функции безопасности и архитектура автоматизированная информационная система точно посредничает и обеспечивает безопасность политика.АУДИТ ТРЕЙЛ Хронологическая запись действий системы, достаточная для того, чтобы реконструкция, просмотр и исследование последовательности сред и действия, связанные или ведущие к операции, процедуре или событию в сделке от ее начала до конечных результатов. ПОДТВЕРЖДЕНИЕ Подтвердите заявленную личность как законную и принадлежащую истцу. РАЗРЕШЕНИЕ Право человека на доступ или использование объекта.КРИПТОГРАФИЯ Принципы, средства и методы обеспечения непонятной информации, и для восстановления зашифрованной информации в понятной форме. ДИСКРЕЦИОННЫЙ КОНТРОЛЬ ДОСТУПА (DAC) Средство ограничения доступа к объектам на основе личности субъектов и / или группы, к которым они принадлежат. Элементы управления являются дискреционными в ощущение, что субъект с определенным разрешением доступа способен передавать это разрешение (возможно, косвенное) на любой другой предмет.ПРИВИЛЕГИЯ ДИСКРЕЦИОННОГО ДОСТУПА Доступ к объектам предоставляется на основе личности субъекта и / или группы, к которым они принадлежат. ДОМИНИРОВАТЬ Уровень безопасности S доминирует над уровнем безопасности S2, если иерархическая классификация S больше или равно S2, а неиерархические категории S, включают все таковые из S2 как подмножество. 25
ИДЕНТИФИКАЦИЯ И АУТЕНТИЧНОСТЬ РУКОВОДСТВО ЛИЧНОСТЬ Уникальное имя или номер, присвоенный человеку, использующему систему.НАИМЕНЕЕ ПРИВИЛЕГИИ Принцип, который требует, чтобы каждому предмету был предоставлен самый строгий набор привилегий, необходимых для выполнения авторизованных задач. В применение этого принципа ограничивает ущерб, который может возникнуть в результате аварии, ошибка или несанкционированное использование. ОБЯЗАТЕЛЬНЫЙ КОНТРОЛЬ ДОСТУПА (MAC) Средство ограничения доступа к объектам на основе чувствительности (как представлен меткой) информации, содержащейся в объектах и формальное разрешение (т.д., разрешение) субъектов на доступ к информации таких чувствительность. ОБЪЕКТ Пассивный объект, который содержит или получает информацию. Доступ к объекту потенциально подразумевает доступ к содержащейся в нем информации. Примеры объектов это: записи, блоки, страницы, сегменты, файлы, каталоги, деревья каталогов, программы, биты, байты, слова, поля, процессоры, видеодисплеи, клавиатуры, часы, принтеры и сетевые узлы. ЭТИКЕТКА ЧУВСТВИТЕЛЬНОСТИ Часть информации, которая представляет уровень безопасности объекта и который описывает чувствительность (например,g., классификация) данных в объекте. В TCB использует метки конфиденциальности в качестве основы для обязательного контроля доступа решения. СПУФИНГ Попытка получить доступ к системе, выдав себя за авторизованного пользователя. Синоним выдачи себя за другое лицо, маскировки или имитации. ТЕМА Активная сущность, как правило, в форме человека, процесса или устройства, которое заставляет информацию перемещаться между объектами или изменяет состояние системы.Технически пара процесс / домен. 26
ГЛОССАРИЙ НАДЕЖНАЯ ВЫЧИСЛИТЕЛЬНАЯ БАЗА (TCB) Совокупность механизмов защиты внутри компьютерной системы, включая аппаратное обеспечение, микропрограммное обеспечение и программное обеспечение, сочетание которых `отвечает за обеспечение соблюдения политики безопасности. Он создает базовую среду защиты и предоставляет дополнительные пользовательские услуги, необходимые для доверенной компьютерной системы.В способность TCB правильно применять политику безопасности зависит исключительно от механизмы внутри TCB и от правильного ввода со стороны администратора системы персонал параметров (например, допуск пользователя), связанных с безопасностью политика. НАДЕЖНЫЙ ПУТЬ Механизм, с помощью которого человек на терминале может напрямую общаться с Надежная вычислительная база. Этот механизм может быть активирован только человека или базы доверенных вычислений и не может быть инициирован ненадежным программное обеспечение.ПРОВЕРЯТЬ Доказать истину путем представления доказательств или свидетельских показаний; обосновать. 27


Политика идентификации и аутентификации | octo

Дата утверждения — 22.02.2021
Дата публикации — 22.02.2021
Дата пересмотра — 25.05.2021

1.Назначение

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

2. Полномочия

Официальный кодекс округа Колумбия, § 1-1401 и последующие, наделяет Управление главного технологического директора («OCTO») полномочиями предоставлять услуги в области информационных технологий (ИТ), разрабатывать и обеспечивать соблюдение ИТ-политик, а также обеспечивать безопасность сети и ИТ-систем. для района.Этот документ можно найти по адресу: https://code.dccouncil.us/dc/council/code/sections/1-1402.html.

3. Применимость

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

4. Политика

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

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

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

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

4.4. Управление идентификаторами
Окружные агентства должны управлять идентификаторами информационных систем с помощью:

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

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

Окружные агентства должны управлять аутентификаторами информационных систем по:

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

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

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

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

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

4.10. Идентификация и аутентификация | Принятие внешних учетных данных
Окружные агентства должны управлять информационной системой, чтобы принимать только внешние учетные данные, сертифицированные на соответствие требованиям NIST SP 800-63-3 (Руководящие принципы цифровой идентификации).

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

  • Системный замок
  • Смена роли
  • После обновления / обновления системы
  • Для выполнения привилегированных функций
  • Для доступа к конфиденциальным данным

5.Освобождение

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *