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

ГлавнаяКоллекция «Otherreferats»Программирование, компьютеры и кибернетикаАутентификация и её виды

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 12.10.2014
Размер файла 48,7В K

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.PPT, PPTX и PDF-файлы представлены только в архивах.Рекомендуем скачать работу.

Аналитика Анализ технологий Корпорации Системы аутентификации … image

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

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

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

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

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

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

Тем не менее, электронная подпись постепенно становится все более влиятельным фактором во множестве сфер деятельности людей. Anti-Malware.ru посвятил этому круглый стол с участием ведущих экспертов отрасли.

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

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

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

Рисунок 2. Аппаратный токен с генерацией одноразовых ключей RSA SecurID

image

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

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

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

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

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

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

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

Популярность и относительная надежность двухфакторной аутентификации приводят к тому, что на рынке появляются готовые решения, избавляющие клиента от необходимости разрабатывать все самому. Одно из них – упоминавшийся выше Google Authenticator, однако это приложение – не единственный вариант. Например, Symantec предлагает сервис VIP – Validation and Identity Protection (бывший VeriSign Identity Protection), который не бесплатен, но предлагает довольно разнообразные функции вроде бесконтактной разблокировки, когда сотруднику не нужно ничего вставлять в считыватель или подносить к нему – достаточно находиться рядом.

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

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

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

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

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

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

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

Определяем термины

Во-первых, давайте определимся с некоторыми ключевыми терминами:

  • Аутентификация: подтверждение правильности личности
  • Авторизация: разрешение определенного действия

API может аутентифицировать, но не разрешит делать определенный запрос.

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

Последствия нехватки безопасности API

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

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

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

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

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

Разные виды авторизации

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

API ключ

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

Ключи APK используют строку в свойстве заголовка для авторизации запросов

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

Basic Auth

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

Authorization: Basic bG9sOnNlY3VyZQ== 

API, использующие Basic Auth, также будут использовать HTTPS, что означает, что содержимое сообщения будет зашифровано в транспортном протоколе HTTP. (Без HTTPS людям было бы легко расшифровать зашифрованные данные)

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

В Postman можно настроить базовую авторизацию, щелкнув вкладку Authorization, выбрав Basic Auth в раскрывающемся списке и введя имя пользователя и пароль справа от двоеточия в каждой строке. На вкладке Заголовки будет показана пара ключ-значение, выглядящая следующим образом:

Authorization: Basic RnJlZDpteXBhc3N3b3Jk 

Postman обрабатывает кодировку Base64 автоматически, при вводе имени пользователя и пароля с выбранным Basic Auth.

HMAC (код авторизации сообщений на основе хэша)

HMAC расшифровывается как Hash-based message authorization code — код авторизации сообщений на основе хэша и является более строгим типом аутентификации, более распространенным в финансовых API. В HMAC только отправитель, и получатель знают секретный ключ, который больше неизвестен никому. Отправитель создает сообщение на основе некоторых системных свойств (например, отметка времени запроса плюс идентификатор учетной записи).

Затем сообщение кодируется секретным ключом и проходит через алгоритм безопасного хеширования (SHA — secure hashing algorithm). (Хеш — это зашифрованная строка на основе алгоритма.) Результирующее значение, называемое сигнатурой, помещается в заголовок запроса.

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

Вот диаграмма, отображающая процесс авторизации HMAC:

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

OAuth 2.0

Одним из популярных методов аутентификации и авторизации пользователей является OAuth 2.0. Такой подход опирается на сервер аутентификации для связи с сервером API для предоставления доступа. Понять, что используется метод OAuth 2.0, можно когда предлагается войти в систему при помощи сторонних сервисов, как Twitter, Google или Facebook.

окно входа в систему, использующую Oauth2.0

Существует несколько разновидностей OAuth, а именно «one-legged OAuth» и «three-legged OAuth». One-legged OAuth используется, когда нет конфиденциальных данных для защиты. Например, в том случае, если просто получаем общую информацию только для чтения.

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

  • сервер аутентификации;
  • сервер API;
  • пользователь или приложение.

Вот базовый процесс Oauth2.0:

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

Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).

Затем пользователь отправляет запрос на сервер ресурсов (сервер API). Токен доступа (авторизации) добавляется в заголовок запроса API со словом Bearer, за которым следует строка токена. Сервер API проверяет токен доступа (авторизации) в запросе пользователя и решает, аутентифицировать ли пользователя.

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

  • Learn API Technical Writing 2: REST for Writers (Udemy), Питера Грюнбаума;
  • OAuth simplified, Аарона Парецки.

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

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

Тем не менее нужно объяснить необходимую информацию:

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

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

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

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

API ключ SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

Twitter

авторизация Twitter

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

Amazon Web Services

авторизация Amazon

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

Dropbox

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

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

👨‍💻 Практическое занятие: Авторизация

В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:

  • Какого рода авторизация требуется для отправки запросов к API?
  • Существуют ли разные уровни доступа в рамках авторизации (например, платные и бесплатные), которые определяют, сколько запросов можно сделать или какие типы информации можно получить?
  • Можно ли вы получить ключ API или какой-либо другой метод авторизации, необходимый для выполнения тестовых вызовов API?
  • Как информация об авторизации интегрируется в раздел “Начало работы”?

🔙

Go next ➡

Описание решения

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

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

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

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

Однако на практике возможны следующие проблемы:

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

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

Сложности с использованием и администрированием паролей, с управлением цифровыми сертификатами и их носителями ведут к снижению управляемости ИТ-инфраструктурой и снижению уровня ИБ. Оптимальным решением будет использование связки специализированных программных комплексов классов Public Key Infrastructure Management (PKI-Management), Authentication Management (или Access Management) и Two-Factor Authentication (2FA)

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

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

Такие задачи позволит решить совместное применение платформ Indeed Access Manager и Indeed Certificate Manager.

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

Совместное использование продуктов Indeed AM и Indeed CM позволяет реализовать следующие задачи информационной безопасности:

  • Двухфакторная аутентификация во всех корпоративных ресурсах даже в тех, где не поддерживаются сценарии многофакторной аутентификации и используются только пароли, включая настольные приложения без встроенной поддержки Single Sign-On)
  • Реализация единого защищенного носителя для хранения сертификатов электронной подписи, хранения идентификационной и аутентификационной информации, а также для регистрации и идентификации в СКУД
  • Контроль обращения и использования цифровых сертификатов и защищенных носителей
  • Нейтрализация проблем и уязвимостей технологии парольной аутентификации

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

  • Отсутствие необходимости “придумывания” новых паролей для всех корпоративных ресурсов
  • Отсутствие риска забывания паролей и последующего простоя работы
  • Единое универсальное защищенное устройство для всех задач управления доступом и хранения электронных подписей

С точки зрения администраторов ИБ и ИТ, внедрение подобного технологического комплекса также несет выгоды:

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

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

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

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

Совместное применение платформ Indeed Access Manager и Indeed Certificate Manager позволяет реализовать в корпоративной ИТ-инфраструктуре специальное аппаратное средство двухфакторной аутентификации в целевых сервисах.

Аутентификация в ОС Windows по сертификатам

Платформа Indeed Certificate Manager поддерживает интеграцию с внутренними удостоверяющими центрами, реализованными на базе Microsoft CA. При этом в доменной инфраструктуре Active Directory “из коробки” поддерживается аутентификация по выпущенным Windows CA сертификатам.

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

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

Аутентификация в приложениях по смарт-картам и сертификатам

До сих пор многие информационные системы и сервисы по умолчанию используют парольную аутентификацию. При этом они могут не поддерживать иные сценарии аутентификации или иные протоколы (RADIUS, SAML, ADFS, Active Directory, X.509 и т.п.).

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

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

Платформа Indeed Access Manager позволяет использовать аппаратные устройства с защищенным хранилищем для сквозной аутентификации в любом приложении или веб-приложении с парольной защитой. Это может быть реализовано:

  • через поддержку протоколов аутентификации (RADIUS, ADFS, SAML и т.п.)
  • через модуль Enterprise Single Sign On (ESSO)

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

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

Единый носитель идентификационной и аутентификационной информации

Платформа Indeed Access Manager позволяет реализовать сценарии аутентификации с использованием аппаратного защищенного носителя в любых целевых ресурсах (с помощью соответствующих модулей интеграции). Возможна интеграция со СКУД, тогда используемые пользователями для аутентификации аппаратные носители также можно использовать и для прохода в помещения, защищенные СКУД.

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

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

Шифрование и электронная подпись

Платформа Indeed Certificate Manager реализует не только задачи управления внутренними цифровыми сертификатами , но позволяет ставить под контроль сертификаты, выпущенные сторонним удостоверяющим центром, в т.ч. аккредитованным.

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

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

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

Корпоративное удостоверение сотрудника

Совместное использование продуктов Indeed Access Manager и Indeed Certificate Manager позволяет реализовать единый защищенный носитель для идентификации, аутентификации и для иных бизнес-задач:

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

Безусловно, конечный перечень возможностей, реализуемых единым устройством, зависит от технических особенностей самого устройства (наличие RFID чипа, наличие защищенного хранилища сертификатов, наличие магнитной полосы или микросхемы для привязки к счету, форм-фактор), получившееся устройство может служить корпоративным удостоверением (или карточкой) сотрудника. Данное удостоверение позволяет сотрудникам получать все “услуги” своей компании, а также доступ ко всем корпоративным сервисам.

Нейтрализация угроз утери или поломки устройства

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

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

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

Продукты компании Индид реализуют инструментарий централизованного мониторинга использования подобных устройств. Более того, в случае выявления факта компрометации устройство может быть оперативно заблокировано, а сертификаты — отозваны, все это — используя инструментарий Indeed Access Manager и Indeed Certificate Manager. Поддержка интеграции с SIEM позволяет оперативно выявлять инциденты и факты компрометации без обращения сотрудника.

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

  • Поддерживаемые Удостоверяющие центры: КриптоПро УЦ, Microsoft CA, Валидата УЦ
  • Поддержка моделей съемных аппаратных носителей сертификатов: Рутокен, компании Актив, eToken, компании SafeNet, ESMART, компании ISBC, JaCarta, компании Аладдин Р.Д. Yubikey, компании Yubico, ID Prime, компании Gemalto, ePass, компании Feitian
  • Поддержка протоколов аутентификации: RADIUS, SAML, ADFS, OpenID Connect, Kerberos (Active Directory)
  • Поддержка аутентификации в целевых системах: Microsoft Windows Logon, Microsoft RDS, MS IIS, VPN, Web-Application, Desktop Application
  • Поддержка интеграции с: средства защиты от НСД (Secret Net Studio), принтеры смарт-карт, средства управления аутентификацией (Indeed Access Manager), средства управления полномочиями и учетными записями — IdM (через API)

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Citilink-kabinet.ru
Добавить комментарий