Регистрационная карточка открытого ключа кода аутентификации (ключа шифрования)

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

Регистрационная карточка открытого ключа кода аутентификации (ключа шифрования)

(с изменениями на 17 августа 2004 года)____________________________________________________________________Фактически утратило силу с 1 января 2014 года в связи с истечением срока действия,

предусмотренного пунктом 7.2 положения Банка России от 29 августа 2008 года №321-П.

____________________________________________________________________

____________________________________________________________________
Документ с изменениями, внесенными:
указанием Банка России от 17 августа 2004 года N 1490-У (Вестник Банка России, N 54, 10.09.2004).
____________________________________________________________________

____________________________________________________________________
Принятые до дня вступления в силу Федерального закона от 12 апреля 2007 года N 51-ФЗ акты Центрального банка Российской Федерации, устанавливающие рекомендации по разработке правил внутреннего контроля, порядок определения квалификационных требований к специальным должностным лицам, ответственным за соблюдение правил внутреннего контроля и программ его осуществления, а также требований к подготовке и обучению кадров, идентификации клиентов, выгодоприобретателей, порядок представления информации в федеральный орган исполнительной власти, принимающий меры по противодействию легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма в соответствии с Федеральным законом от 7 августа 2001 года N 115-ФЗ “О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма”, в соответствии со статьей 2 Федерального закона от 12 апреля 2007 года N 51-ФЗ согласованы с уполномоченным органом (Федеральная служба по финансовому мониторингу) и применяются с 1 января 2009 в действующих редакциях – см. информационное сообщение Банка России от 26 декабря 2008 года “О согласовании актов Банка России указанных в статье 2 Федерального закона от 12 апреля 2007 года N 51-ФЗ с уполномоченным органом (Федеральная служба по финансовому мониторингу)”.
– Примечание изготовителя базы данных.________________________________________________________________________________________________________________________________________

С 1 января 2009 года (со дня вступления в силу положения Банка России от 29 августа 2008 года N 321-П) настоящее положениедействует в течение 5 лет для случаев формирования исправленного ОЭС по ОЭС, направленному до 1 января 2009 года и не принятому уполномоченным органом, либо ОЭС, формируемого на замену, удаление, по ОЭС, направленному до 1 января 2009 года и принятому уполномоченным органом, – см. пункт 7.2 положения Банка России от 29 августа 2008 года N 321-П.

– Примечание изготовителя базы данных.____________________________________________________________________

Центральный банк Российской Федерации на основании статьи 7 Федерального закона “О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма” (с изменениями и дополнениями) (Собрание законодательства Российской Федерации, 2001, N 33 (часть I), ст.3418; 2002, N 44, ст.4296) (далее – Федеральный закон) и статьи 7 Федерального закона “О Центральном банке Российской Федерации (Банке России)” (Собрание законодательства Российской Федерации, 2002, N 28, ст.2790) устанавливает следующий порядок представления кредитными организациями в уполномоченный орган сведений об операциях с денежными средствами или иным имуществом, подлежащих обязательному контролю, а также иных операциях с денежными средствами или иным имуществом, связанных с легализацией (отмыванием) доходов, полученных преступным путем, и финансированием терроризма.

1. Общие положения

1.1. Для целей настоящего Положения применяются следующие основные понятия:

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

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

Аутентификация – процесс установления подлинности и целостности сообщения.

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

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

Ключ КА – индивидуальные данные, используемые при создании и проверке КА сообщения и состоящие из:

– секретной части ключа КА (далее – секретный ключ КА) – данных, предназначенных для создания отправителем КА сообщения;

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

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

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

2.1. Представление кредитной организацией, филиалом кредитной организации (далее – кредитная организация) в уполномоченный орган сведений, предусмотренных Федеральным законом, осуществляется в виде ОЭС через территориальные учреждения Банка России (далее – территориальное учреждение).

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

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

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

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

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

2.5. Описание структуры ОЭС представлено в Приложениях 4 и 5 к настоящему Положению.

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

2.7. Ответственность за содержание данных, включаемых в ОЭС, несет владелец ключа КА, которым снабжено сообщение.

2.8.

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

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

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

2.9.

В случае приостановления кредитной организацией операции с денежными средствами или иным имуществом, а также при совершении операции по зачислению денежных средств, поступивших на счет физического или юридического лица, хотя бы одной из сторон которой является организация или физическое лицо, в отношении которых имеются полученные в установленном в соответствии с пунктом 2 статьи 6 Федерального закона порядке сведения об их участии в террористической деятельности, либо юридическое лицо, прямо или косвенно находящееся в собственности или под контролем таких организации или лица, либо физическое или юридическое лицо, действующее от имени или по указанию таких организации или лица (далее – операция, связанная с финансированием терроризма), кредитная организация в день приостановления или совершения такой операции формирует отдельный ОЭС, содержащий сведения о данной операции, и немедленно направляет его в уполномоченный орган через территориальное учреждение с признаком в имени файла, определяющим представление сведений об операциях, связанных с финансированием терроризма, в соответствии с Приложением 5 настоящего Положения.
Территориальное учреждение по получении ОЭС, содержащего сведения об операции (операциях), связанной(ых) с финансированием терроризма, немедленно передает его в Главный центр информатизации Банка России (далее – ГЦИ).

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

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

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

2.11.

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

Источник: http://docs.cntd.ru/document/901837675

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

Регистрационная карточка открытого ключа кода аутентификации (ключа шифрования)

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

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

Сертификат подписан цифровой подписью выпустившего его центра сертификации (СА).

Инфраструктура, используемая для поддержки сертификатов в организации, называется инфраструктурой открытого ключа (Public Key Infrastructure, PKI). [22]

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

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

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

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

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

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

Ниже приведены шаги описанного процесса аутентификации.

1. Клиент подает запрос аутентификации.

2. Сервер создаст вопрос.

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

4. Ответ возвращается серверу.

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

6. Если наблюдается совпадение, клиент успешно проходит аутентификацию. Данная концепция представлена на рис. 4.2.

Рис. 4.2. Аутентификация с использованием открытого и секретного ключей

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

SSL/TLS

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет.

При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.

0 был разработан и принят стандарт RFC, получивший имя TLS.

Данная система может использоваться в электронной коммерции или в любой другой сфере, где требуется машинная аутентификация или необходимы безопасные соединения. Transport Layer Security (TLS) — это версия SSL, стандартизированная для использования в Интернете (RFC 2246).

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

Необходимо обеспечить совместимость приложений с SSL или TLS, прежде чем использовать одну из этих двух систем.

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

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

Процесс аутентификации состоит из следующих этапов.

1. Пользователь вводит URL сервера в браузере.

2. Запрос клиента на веб-страницу передается на сервер.

3. Сервер получает запрос и отправляет свой сертификат сервера клиенту.

4. Браузер клиента проверяет свое хранилище сертификатов на наличие сертификата от центра сертификации, выпустившего сертификат сервера.

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

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

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

8. Зашифрованный ключ возвращается серверу.

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

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

  • Если веб-сервер не настроен соответствующим образом на требование использования SSL, сервер не аутентифицируется относительно клиента, и может быть установлено обычное незащищенное соединение. Безопасность зависит от того, укажет ли пользователь в строке URL браузера протокол https:/ вместо http:/.
  • Если у клиента нет копии сертификата СА, она будет предложена ему сервером. Несмотря на то, что это обеспечивает наличие шифруемого соединения между клиентом и сервером, данный подход не обеспечивает аутентификацию сервера. Безопасность соединения здесь зависит от пользователя, который, в лучшем случае, откажется от соединения с сервером, который не идентифицирован третьей стороной.
  • Процесс получения сертификата СА в хранилище браузера не является четко контролируемым. В прошлом данное обстоятельство могло потребовать уплаты денежных средств или зависело от ваших связей. Теперь же Microsoft требует, чтобы сертификаты, устанавливаемые все браузеры, были выпущены центрами сертификации, прошедшими соответствующий аудит.
  • Основой является защита секретного ключа. В то время как реализации по умолчанию требуют лишь нахождения ключа в защищенной области системы, возможно, применить аппаратные системы, требующие хранения секретного ключа только на аппаратном устройстве.
  • Как в случае с любой системой, базирующейся на PKI, решение о предоставлении сертификата организации для его использования на сервере этой организации зависит от политик, созданных людьми, и, таким образом, данное решит принимается именно людьми. Поэтому могут допускаться различные ошибки Сертификат SSL, определяющий сервер как принадлежащий компании, может быть выпущен каким-либо лицом, не являющимся представителем этой компании. Кроме того, если даже истек срок действия сертификата или обнаружена другая проблема и выдан сигнал тревоги, многие пользователи просто проигнорируют это предупреждение.

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

Для SSL-сеансов обычно применяются 40- и 128-разрядный уровни шифрования.

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

В версиях Microsoft Windows для США реализовано 128-, а в экспортных версиях — 40-разрядное шифрование. Чтобы обновить сервер для 128-разрядного шифрования, необходимо установить специальный пакет обновления, распространяемый Microsoft.

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

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

Ключи длиной 1 024 и более разрядов во многих случаях не поддерживаются.

Когда пользователь пытается установить SSL-соединение с Web-сервером, клиентский браузер и сервер на основе своих ключей шифрования определяют максимально возможный уровень шифрования. Если длина ключей шифрования 512 разрядов, используется 40-разрядное, если 1 024 — 128-разрядное шифрование. Также доступны другие длины ключей и уровни шифрования.

:

Источник: http://csaa.ru/autentifikacija-po-sertifikatam/

Ключи для двухфакторной аутентификации

Регистрационная карточка открытого ключа кода аутентификации (ключа шифрования)

17.08.2006 Сюзан Тиббеттс

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

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

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

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

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

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

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

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

USB-ключи, смарт-карты, устройства чтения биометрических параметров и PIN-генераторы

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

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

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

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

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

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

Проблемы развертывания

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

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

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

509, LDAP, ODBC, Remote Authentication Dial-In User Service — RADIUS) или фирменных стандартов поставщиков, что может привести в проблеме взаимной совместимости.

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

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

Полезно также установить второй сервер на случай отказа основного компьютера.

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

Комплексное управление аутентификацией

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

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

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

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

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

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

Другие способы двухфакторной аутентификации

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

Сюзан Тиббеттс – Заместитель редактора Windows IT Pro и SQL Server Magazine. Автор статей по компьютерной тематике с 15-летним стажем stibbetts@windowsitpro.com

Поделитесь материалом с коллегами и друзьями

Источник: https://www.osp.ru/winitpro/2006/05/2660019/

Поделиться:
Нет комментариев

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

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.