Инфраструктура доверия

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

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

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

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

Что такое доверие и причем тут информационные системы?

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

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

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

Требования, предъявляемые к инфраструктуре, должны соответствовать данным, которые в ней хранятся. Когда мы говорим про доверие с точки зрения ИТ, то ссылаемся на зарубежные документы и источники, где описываются стандарты ISO/IEC 15408. И тут следует учесть нюансы перевода терминов, которые на русский язык переводятся одинаково — как «доверие». Между тем в английском языке термины Trust, Assurance, Confidence различаются по смыслу. Если представить это в виде пирамиды, то получится следующая последовательность:

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

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

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

Наша основная задача — перейти на уровень Assurance, где уже есть заверения и гарантии. А гарантии может дать криптография. Если мы говорим о ГОСТовых алгоритмах, то это будет гарантированная проверенная стойкость. Если мы рассматриваем зарубежные крипто-алгоритмы, там мы можем говорить об известной математической стойкости.

Уровни доверия информационных систем

Уровень доверия — это совокупность действий, которые необходимо выполнить для достижения уверенности.

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

Уровни доверия определяются по двум параметрам:

• Уровень значимости обрабатываемой информации.
• Риск возникновения недопустимого события информационной безопасности и получения ущерба в случае инцидента ИБ: нарушения конфиденциальности (неправомерного доступа, копирования, предоставления или распространения информации), целостности (неправомерное уничтожение или модификация информации), доступности (неправомерное блокирование информации).

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

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

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

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

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

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

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

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

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

Идентификация бывает первичная и вторичная. В чем отличие?

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

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

Шаг 1. Пользователь приходит с набором документов и представляет их.

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

Чем выше уровень важности информации, тем выше нужен уровень доверия и тем более сложными станут шаги проверки информации и их количество. Например, может быть добавлена верификация документов. В таком случае дополнительно по запросу регистратора потребуются проверка и подтверждение официальным свидетельством заявленных идентификационных данных — это может быть подтверждение от МВД, МФЦ, ФСБ. Полномочные верификаторы могут проверять: не были ли документы украдены, действительно ли они выдавались, кем и когда. Такая проверка требуется для обеспечения высокого уровня доверия.

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

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

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

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

Цели первичной идентификации:

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

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

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

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

Цели вторичной идентификации:

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

Термин «уровень доверия к идентификации» был введен в документах NIST (National Institute of Standards and Technology) в 2017 году в документе «Аутентификация и управление жизненным циклом. Руководство по цифровой идентичности».

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

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

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

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

Цели аутентификации в информационных системах:

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

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

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

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

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

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

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

Двухфакторная аутентификация (2ФА/2FA) позволяет усилить защиту. У нас появляется дополнительный фактор – фактор владения. Это может быть либо смарт-карта, либо токен, либо мобильный телефон, на который придет одноразовый пароль (общий с ИС секрет).

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

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

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

Биометрия — это дополнительный фактор к двум предыдущим, доказательство принадлежности устройства владельцу и неотказуемости от факта проведения транзакции (доступа в ИС, подписания документа или финансовой транзакции своей ЭП).

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

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

Типы аутентификации для разных информационных систем

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

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

Прямая аутентификация — аутентификация в рамках рабочих групп, когда речь идет о небольших организациях на 20-30 рабочих мест. В них есть защищенный периметр, и владелец ресурса доверяет единому валидатору, расположенному внутри этого периметра. В свою очередь валидатор проверяет представленную информацию об аутентификации. Все пользователи локальной сети напрямую проходят процесс аутентификации и валидации. Доменная аутентификация — домен может быть любой. Это по-прежнему чаще всего Windows, но мы наблюдаем процесс миграции на Linux — ALD Pro, РЕД АДМ и другие. При таком типе аутентификации владельцы многих ресурсов, размещенных в локальной сети, доверяют единому валидатору, расположенному внутри защищенного периметра этой сети. Такой тип аутентификации применяется в сегментах малого и среднего бизнеса.

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

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

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

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

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

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

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

Таблица. Типы аутентификации в различных информационных системах

Требования к видам аутентификации пользователей

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

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

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

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

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

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

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

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

При простой однофакторной аутентификации наша задача — сказать, что «я – это я», и система должна с этим согласиться. При этом сами мы не проверяем, что система, к которой подключаемся, это действительно тот самый информационный ресурс, который нам нужен. Поэтому есть вероятность подключиться к нелегальному ресурсу (man-in-the-middle).

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

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

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

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

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

ВНИМАНИЕ! Использование зарубежных сервисов сейчас небезопасно. Также известны сложности, связанные с невозможностью получения одноразовых паролей из-за отключения сервисов для российских пользователей.

Для подтверждения личности применяются:

• Электронные идентификаторы («ключ с таблеткой», i-button, Dallas Touch Memory). Персональные аппаратные устройства, содержащие уникальный идентификатор (фактор владения).
• OTP-токены (аппаратные и программные). В них загружается общий секретный ключ, известный информационной системе, затем с помощью токена генерируется одноразовый пароль, который синхронизируется с системой. Для работы с OTP-токенами на стороне ИС требуется сервер аутентификации.
• Электронные идентификаторы — U2F-токены с поддержкой стандартов FIDO/FIDO2. Такие устройства предназначены для отказа от вводимых вручную паролей. В основном они используются внешними пользователями различных сервисов, чаще — с веб-интерфейсом. Среди них есть иностранные и российские решения. В отличие от OTP-токенов, один U2F-токен может использоваться для доступа к множеству различных веб-ресурсов.

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



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



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

• Взаимной — аутентификация обеих сторон взаимодействия: пользователь-ИС, ИС-пользователь.
• Двухфакторной — с использованием фактора владения аппаратным устройством и фактором знания: ПИН-кодом, паролем, подтверждающим фактор владения данным устройством. Либо трехфакторной — с дополнительным фактором подтверждения личности пользователя с использованием его уникальных контактных биометрических характеристик.
• Использующей цифровые сертификаты, выдаваемые корпоративным Центром сертификации развернутой в организации (владельца или оператора ИС) инфраструктуры открытых ключей (PKI), защищенных криптографическими протоколами аутентификации.

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

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

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

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

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

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

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

Требования к средствам 2ФА

Персональное электронное устройство – средство 2ФА – должно иметь:

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

Присвоенный пользователю идентификатор должен храниться в цифровом сертификате Х.509 в поле «Уникальный идентификатор субъекта». Пользовательский сертификат должен быть выдан доверенным (желательно сертифицированным) корпоративным центром сертификации. Microsoft CA в настоящее время доверенным не является.

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

Для пользовательских персональных устройств рекомендуется использовать RSA с длиной ключа не менее 2048 бит или более современный алгоритм ECDSA c длиной ключа 304 бита.

Если не углубляться в математику, то RSA с длиной ключа 2048 бит и эллиптическая кривая с ключом 304 бита дают приблизительно одинаковую стойкость.

Требования к средствам 2ФА/3ФА с биометрией

При идентификации по отпечаткам пальцев должно использоваться персональное защищенное устройство со встроенным в него полупроводниковым сканером (не оптическим!). Технология называется Match-On-Device. Все вычисления выполняются не на сервере, а локально — внутри устройства. Проводится первичная регистрация и шаблонизация отпечатка пальцев, сравнение предъявляемого отпечатка пальца с шаблоном, вынесение вердикта «свой-чужой». Сравнение необходимо проводить по типу 1:1.

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

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



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

• Корпоративный центр выпуска и обслуживания сертификатов — это корень всей информационной системы.
• Защищенное хранилище сертификатов, если мы говорим про IIoT, M2M, серверы, персональные компьютеры, сетевые устройства.
• Устройства для строгой аутентификации — usb-токены и смарт-карты.
• Клиент PKI и двухфакторная аутентификация для Linux необходимы для линуксовых операционных систем. Аналога Microsoft Smartcard Logon в Linux нет, а сделать без него такую же комфортную работу, как привыкли пользователи в клиентских ОС Windows, не представляется возможным.
• Система централизованного управления токенами и сертификатами понадобится для крупной информационной системы (от 100 пользователей), так как это обеспечит централизованное применение политик обновления сертификатов, политик к смене ПИН-кода, подготовку отчетов о выданных токенах — все то, с чем трудно будет справиться администратору.

Большинство пользователей привыкли, что используется Microsoft CA — центр выдачи и обслуживания сертификатов. От него зависели:

• Доверенное взаимодействие всех объектов и компонентов ИТ-инфраструктуры.
• Аутентификация объектов системы — оборудования, приложений (ПО), пользователей.
• Работоспособность доменов безопасности/службы каталога.
• Работа различных сервисов (удаленного доступа, VDI, VPN, RDP-шлюзы и др).

Практически все ИТ-инфраструктуры в России построены на базе Microsoft CA и на 100% зависят от его работоспособности. В 2022 году компания Microsoft ушла из России, представительство закрыто, поддержки больше нет, купить решения Microsoft нельзя. С 30 сентября 2023 года Microsoft перестала продлевать подписки корпоративным клиентам из России.

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

PKI (ИОК – инфраструктура открытых ключей) и двухфакторная аутентификация известны давно, но во многих ИТ-инфраструктурах в России 2ФА не используется. Более того, двухфакторная аутентификация не всегда значит строгая. Она не означает автоматическое действие двухсторонней аутентификации, использование PKI в инфраструктуре и обеспечение высокого уровеня доверия к информационным системам.

Строгая аутентификация для Linux

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

• Специализированного защищенного устройства (таково требование новых ГОСТов).
• Аппаратной реализацией криптографии с неизвлекаемым закрытым ключом.
• Хранением сертификатов доступа в памяти неклонируемого (Secure by Design) устройства, с возможностью его использования только авторизованными пользователями.

Строгая аутентификация должна быть взаимной (аутентификация обеих сторон) и с использованием защищенных протоколов. Она требуется во всех системах, обрабатывающих значимую информацию — в государственных учреждениях, КИИ, АСУ ТП и др. Также она нужна тем, где должна быть развернута инфраструктура открытых ключей (PKI), централизованное управление жизненным циклом сертификатов, средств 2ФА.

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

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

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



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

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

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

Менеджер по развитию бизнеса Softline Максим Коновалов

ГК Softline имеет большой опыт работы в области информационной безопасности. Портфель продуктов и услуг представлен на сайте. Вопросы по решениям «Аладдин Р.Д.» вы можете направить на email менеджеру по развитию бизнеса Softline в сфере кибербезопасности Максиму Коновалову.