-
Похожий контент
-
От KL FC Bot
Требования, которые онлайн-сервисы предъявляют при проверке своих пользователей, — будь то длина пароля, обязательное указание номера телефона или необходимость биометрической проверки с подмигиванием, зачастую регулируются индустриальными стандартами. Одним из важнейших документов в этой сфере является NIST SP 800-63, Digital Identity Guidelines, разработанный Национальным институтом стандартов и технологий США. Требования этого стандарта обязательны для выполнения всеми государственными органами страны и всеми их подрядчиками, но на практике это означает, что их выполняют все крупнейшие IT-компании и действие требований ощущается далеко за пределами США.
Даже организациям, которые не обязаны выполнять требования NIST SP 800-63, стоит глубоко ознакомиться с его обновленными требованиями, поскольку они зачастую берутся за основу регуляторами в других странах и индустриях. Более того, свежий документ, прошедший четыре раунда публичных правок с индустриальными экспертами, отражает современный взгляд на процессы идентификации и аутентификации, включая требования к безопасности и конфиденциальности, и с учетом возможного распределенного (федеративного) подхода к этим процессам. Стандарт практичен и учитывает человеческий фактор — то, как пользователи реагируют на те или иные требования к аутентификации.
В новой редакции стандарта формализованы понятия и описаны требования к:
passkeys (в стандарте названы syncable authenticators); аутентификации, устойчивой к фишингу; пользовательским хранилищам паролей и доступов — кошелькам (attribute bundles); регулярной реаутентификации; сессионным токенам. Итак, как нужно аутентифицировать пользователей в 2024 году?
Аутентификация по паролю
Стандарт описывает три уровня гарантий (Authentication Assurance Level, AAL), где AAL1 соответствует самым слабым ограничениям и минимальной уверенности в том, что входящий в систему пользователь — тот, за кого себя выдает. Уровень AAL3 дает самые сильные гарантии и требует более строгой аутентификации. Только на уровне AAL1 допустим единственный фактор аутентификации, например просто пароль.
View the full article
-
От tav
Всех приветствую !
Поднял пока что тестовый KSC последний на Alt Linux.
Версия KSC Linux PF 15.1.0.12199 и версия KESL PF 12.1.0.1543.
В настройках политики установил распространять ключ через KSC и на самой лицензии галка стоит.
Клиент работает не в режиме легкого агента.
В итоге клиент виндовый подхватывает ключ с сервера KSC, клиент линуксовый при установке автоматом ставит тестовую/пробную лицензию и ни как не хочет цеплять автоматом лицензию.
Если я создаю задачу для линуксовой группы/клиента сменить ключ, то все ок клиенты по задаче меняют ключ тестовый на корпоративный.
Не понимаю почему именно линуксовые клиенты автоматом не тащат ключ. Настройки как я понимаю правильные.
-
От Din
Есть приватный ключ, подскажите как и чем расшифровать?
Сообщение от модератора Mark D. Pearlstone Перемещено из темы. -
От Совух белобокий
Добрый день, господа!
Имеем развёрнутый Kaspersky Security Center 14.2.20222 на Windows Server 2016, лицензионный ключ для продукта "Kaspersky Endpoint Security для бизнеса – Стандартный Russian Edition. 25-49 Node 1 year Renewal Download Licence - Лицензия" на 27 ПК, но почему-то на последний добавленный ПК не "прилетает" лиц. ключ, может быть потому, что все 27 лицензии уже использованы? Как тогда удалить ключ с одного из ПК (или это нужно делать с удалением самого KES на этом ПК?) чтобы освободилась лицензия для последнего ПК?
Заранее благодарю за ответы!
-
От TSN_prm
Добрый день.
KSC Linux 15.0
KES Linux 12.0
Кесы на связи с KSC, приложение останавливается-запускается, лицензия подгружена, задачи на поиск вр-го ПО и локальные выполняются, а задача по обновлению завершается статусом "Сбой", в результатах:
Application databases update error (Initiator: Product; Runtime task ID: 72; Task type: Update;) и Task failed (Initiator: Product; Runtime task ID: 72; Task state: Stopped; Task type: Update; Reason: InternalError;).
Подскажите, пожалуйста, как понять конкретную причину Reason: InternalError, в каких логах смотреть.
Пробовал очищать хранилище баз в KSC и загружать новые. Переустановка клиента тоже не помогает.
Так же, на некоторых тачках есть проблема с лицензией (лицензионный ключ один единственный в KSC) но на некоторых статус "защита выключена", в компонентах "не поддерживается лицензией", задача по добавлению ключа падает в эту же InternalError. Всё перепробовал, в т.ч. удалить из KSC, потом еще локально на тачке, ребут, установка из KSC новой 12.1 версии - ничего не помогает, хелп, плиз!
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти