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

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

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

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

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

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

В РФ используют азиатскую модель регулирования. Поэтому, как только вам захотелось добавить в базу своей биометрической системы кого‑то, кроме себя, в дело вступают федеральные законы и вся цепочка тянущихся за ними ГОСТов, распоряжений и рекомендаций. Начинается всё с известного всем 152-ФЗ от 27.07.2006, продолжается 572-ФЗ от 29.12.2022 и далее по нисходящей (полный перечень нормативной документации ищите в конце статьи).

Попробуем построить гипотетическую систему сбора, обработки и передачи биометрических персональных данных населения (далее БПДн) в соответствии с этими нормативными актами РФ. В этой статье уделим внимание именно технической архитектуре такой системы.

Где начинается биометрия?

Если вам захотелось сфотографировать друзей и выложить эту фотографию на общедоступные ресурсы или напечатать в газете, то это ещё не биометрия. Такое распространение фото‑ и видео‑материалов регламентируется другими законами. Биометрия начинается с ЦЕЛИ. Как только у вас появляется ЦЕЛЬ — установить личность и сопоставить её с её персональными данными, — тут же начинается биометрия (статья 11 в 152-ФЗ).

Объясним на примерах:

• Василий фотографирует Василису и загружает фото в соцсеть — это не обработка БПДн;

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

То же самое относится и к следующим видам биометрической информации:

• рисунок сетчатки глаза;

• рисунок радужной оболочки глаза;

• отпечаток пальца;

• голос;

• некоторые другие биологические или физиологические данные (подробности можно почитать в ГОСТ Р 54412–2019).

А если Александр не хочет, чтобы его фото использовали для идентификации? В РФ это дело добровольное, не надо подписывать согласие. И если кто‑то делает это без согласия, то нарушает закон.

А если Александр раньше хотел использовать своё фото для идентификации, а потом перехотел? В РФ можно отозвать согласие, и оператор БПДн обязан его зафиксировать и удалить вектор из своей базы.

А есть ли случаи, когда можно использовать данные без согласия? Есть, они описаны в 152-ФЗ и 572-ФЗ и применяются к преступникам и делам государственной важности.

У биометрических персональных данных есть срок годности (но не у всех и не всегда).

Откуда появляется база векторов и как её использовать?

База векторов создаётся и наполняется на основании 325-ФЗ, 479-ФЗ и 572-ФЗ. На технической платформе «Ростелеком» создали Единую Биометрическую Систему (далее ЕБС; о её устройстве рассказали создатели), в которую передали разрозненные биометрические данные, ранее собранные различными операторами. То есть, на заре развития использования биометрической информации для идентификации любой мог содержать свою базу векторов и привязывать к ним ПДн, но сейчас это запрещено и официальной базой является только ЕБС.

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

Вот у нас есть единая база, но что с ней можно делать? Подробности об услугах ЕБС есть на сайте, там же в открытом доступе лежит документация по интеграции с ЕБС. А нас интересует архитектура системы, которая будет интегрироваться с ЕБС или с какой‑нибудь Коммерческой Биометрической Системой (КБС), которая являются частью инфраструктуры ЕБС. КБС — это делегирование возможностей по идентификации по БПДн от ЕБС к аккредитованным для этого организациям (в основном, банкам), создавшим у себя систему, отвечающую требованиям всех ФЗ и нормативных актов.

КБС предоставляет потребителям те же услуги по идентификации, получая от ЕБС копию базы векторов (но не сами БПДн! Ваши фотографии в КБС из ЕБС не передаются). Организация со своей КБС содержит копию базы векторов, регулярно её пополняет из ЕБС, а для подтверждения соответствия системы требованиям проводит аттестацию на соблюдение положений приказа ФСТЭК № 17 от 11.02.2013 (который скоро заменят на приказ № 117). Организация может использовать КБС для своих нужд по идентификации и предлагать аналогичные услуги своим партнёрам, дочерним организациям и другим потребителям, вплоть до ИП.

Чтобы собирать БПДн для ЕБС, надо быть аккредитованной организацией, построить закрытую систему, состав и средства защиты которой согласовать с ФСБ, интегрировать её с ЕБС и проходить аудит ЦБ раз в 2 года. Такие системы есть уже готовые, покупай коробку и ставь (в отдельную стойку с СКЗИ и МСЭ по периметру), поэтому вариант построения собственного модуля сбора и передачи БПДн в ЕБС и согласования его с ФСБ рассматривать не будем, но он есть.

Чтобы иметь свою КБС, надо быть аккредитованной организацией и предъявить аттестат своей системы, аттестат получается у аккредитованных в ФСБ организациях.

Чтобы получать услуги по идентификации от ЕБС или КБС необходимо организовать правильную интеграцию с этими системами.

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

Далее пойдём от простого к сложному: рассмотрим сначала процесс идентификации, потом архитектуру интеграции, потом архитектуру КБС и архитектуру узла связи с ЕБС.

Процедура идентификации

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

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

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

На первом этапе в объективе камеры появляется лицо (или в микрофоне кто‑то начинает говорить). Устройство должно понять, что это лицо или голос человека, и Заказчик принимает решение о начале процедуры. Это может быть ручной запуск, когда пользователь сам нажимает кнопку «узнай меня», или автоматический: человек подошёл к турникету, мы распознали, что это человек, значит, надо его идентифицировать для прохода.

На этапах 2–5 выполняются технические манипуляции:

• применяются алгоритмы захвата лучшего кадра;

• проверяется «живость кадра» (Liveness Detection), то есть не пытаются ли систему обмануть, подсунув фото, маску или DeepFake;

• вычисляется вектор, подписывается электронной подписью и отдаётся на сравнение.

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

• 1 к 1: запрос с вектором содержит ID клиента и надо только удостовериться, что это он и есть (например, пришёл человек с паспортом, оператор его снимает и добавляет к фото уже известный по паспорту ID);

• 1 ко многим: запрос с вектором не содержит ID и его надо получить, тогда идёт сравнение со всеми векторами базы в поисках совпадающего.

На этапах 7 и 8 выявляется наличие вектора в базе и корректность сопоставления. Важно понимать, что биометрическая система возвращает точный ответ и информацию о степени соответствия (ИСС). Для разных операций и разных систем важен не только точный ответ, что вектор принадлежит ID:0001, но и степень соответствия. Для регистрации в гостинице достаточно одной степени соответствия, для выдачи кредита — другой.

На этапе 9 происходит получение персональных данных на основании ID. Если считать, что мы работаем в связке с Госуслугами, то это будет OID, и сходить за ФИО нам придётся в ЕСИА. В финансовых организациях также используется MDM ID для извлечения ПДн из их баз. Если вам надо извлечь из своей базы ПДн по OID, значит, у вас должна быть такая база или интеграция с чьей‑то такой базой.

На этапе 10 ПДн получен, и «Заказчик» начинает считать, что человек, предоставивший сейчас свой БО, точно идентифицирован.

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

Теперь накладываем на эти этапы грубые мазки технической архитектуры системы:

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

1. какие устройства (по мнению законодательства) существуют для получения БО;

2. этапы с 4 по 7 происходят на стороне ЕБС или КБС;

3. система «Заказчик», по требованию которой запускается процесс идентификации, должна управлять своими устройствами получения БО;

4. «Заказчик» сопоставляет ID с ПДн с помощью обращения к третьей системе, содержащей ПДн; это может быть ЕСИА или своя база;

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

В этой схеме БПДн передаются только во взаимодействии 2, а во взаимодействии 3 передаётся информации о степени соответствия (ИСС). Их надо защищать особо. Это не значит, что другие взаимодействия можно не защищать вопреки здравому смыслу и другим законам РФ. Но в нашем случае нас интересует только то, что касается БПДн и ИСС.

Про аутентификацию

Аутентификация в законодательстве, касающемся БПДн, это не то, что вы себе привычно представляете, основываясь на своём опыте в ИТ. Это процесс сбора БПДн, передачи его в ЕБС и сопоставлении с учетной записью в ЕСИА. Как писалось ранее, биометрия по законам РФ без Госуслуг не должна существовать потому, что она, фактически, как предъявление паспорта при личном визите.

Процесс аутентификации:

На этапах 3–5 используется некое устройство сбора БПДн, к которому государственными законами предъявляются определённые технические требования.

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

На этапе 7 появляется система, обрабатывающая БПДн и канал передачи данных до ЕБС.

Этапы 8–11 происходят на стороне ЕБС.

Для нас, согласно теме статьи, интересны этапы 3–7. Главное, что происходит это всё только в пределах устройств, принадлежащих аккредитованной организации финансового рынка (в дальнейшем будет ещё МФЦ). Такую систему не может создать любой желающий.

Принципы построения технической архитектуры биометрических систем

Требования законодательства при выборе архитектуры можно свести к упрощенным постулатам:

1. Обеспечить защищенность устройства, собирающего биометрические образцы.

2. Обеспечить целостность и конфиденциальность БО, ИСС и векторов, передаваемых по каналам связи.

3. Обеспечить защищенность систем, обрабатывающих БО.

С точки зрения техники при выборе архитектуры систем необходимо учитывать:

1. Количество запросов на идентификацию или аутентификацию в единицу времени (RPS) и размер передаваемого БО.

2. Требуемое время отклика, то есть время с момента получения БО до успешной идентификации.

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

4. RTO систем обработки БПДн.

5. Необходимость интеграций с системой, хранящей ПДн.

6. Необходимость сервисных окон для оборудования.

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

1. Используемое оборудование и ПО должно входить в реестры Минцифры и Минпромторга, то есть полное импортозамещение во всех местах кроме ЛВС (всё законодательство начинает регламентировать с L3 уровня).

2. Используемое оборудование и ПО в некоторых особо важных местах должны иметь сертификаты ФСТЭК (например, все МСЭ, ОС и антивирусы).

3. Модуль сбора и передачи БПДн в ЕБС должен быть решением, согласованным с ФСБ.

4. Все каналы, по которым передаётся БПДн, должны защищаться с использованием ГОСТового шифрования, а сами сообщения, содержащие БПДн и ответ с ИСС, должны быть подписаны электронной подписью (где‑то УНЭП, где‑то УКЭП, где‑то КВ2).

5. Чаще всего любая обработка БПДн — это степень защиты оборудования от внутреннего нарушителя, обладающего административными полномочиями и доступом к СКЗИ, то есть в классификации ФСБ — уровень защищённости КС3.

К разным устройствам считывания БО применяют разные требования законодательства, и деление на типы в нём довольно странное:

1. стационарные СВТ и банкоматы, принадлежащие организациям финансового рынка (ОФР);

2. мобильная вычислительная техника — в том числе планшеты и электронные терминалы, — принадлежащая ОФР;

3. оконечные устройства СКУД;

4. устройства физических лиц (что бы это ни было).

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

Как защищать нашу биометрию по требованиям закона:

Требования к классам защиты КС1, КС2, КС3 — это требования ФСБ к средствам криптографической защиты информации (СКЗИ), которые будут использоваться. А СЗИ от НСД — это средства защиты информации от несанкционированного доступа.

Не сильно вдаваясь в подробности, опишем все эти защиты так:

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

• Чтобы обеспечить защиту по классу КС2, надо сделать всё то же, что и для КС1, и вдобавок проверять целостность при запуске ОС, использовать доверенный модуль загрузки (АПМДЗ) настроить контроль доступа обслуживающего персонала с минимальными привилегиями.

• Чтобы обеспечить защиту устройства по классу КС3, надо сделать всё то же, что и для КС1 и КС2, а также: использовать специализированное ПО для создания замкнутой программной среды и ролевую модель доступа всех и каждого, обеспечить отсутствие известных уязвимостей и физически ограничить доступ к устройствам (доступ к оборудованию по СКУД, обязательное видеонаблюдение, отдельная стойка на ключе и прочее). Ну и проходить регулярную аттестацию у аккредитованных в ФСБ организаций, а при внесении изменений в систему переаттестовываться вне очереди.

• Чтобы обеспечить СЗИ от НСД, надо воспользоваться сертифицированным программным обеспечением: какой‑либо МДМ‑системой (выбирайте тут), которая будет управлять устройством.

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

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

2. Все каналы связи, по которым передаются БПДн, надо защищать. Нельзя использовать TLS и OpenVPN, надо делать везде по ГОСТу. Хорошо, что у нас есть вендоры, которые предоставляют готовые решения, для организации необходимых защищенных каналов, и даже есть определённый выбор. У каждого вендора свои нюансы по настройке и управлению оборудованием, свои схемы лицензирования, поэтому подходить к вопросу выбора надо очень осторожно, так как поменять что‑то потом будет крайне дорого.

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

4. ФСБ официально не считает VLAN`ы средством разграничения трафика на третьем уровне OSI. Поэтому для каждой системы обработки и хранения БПДн приходится делать свою ЛВС на своём отдельном железе в своей отдельной стойке и серьёзный открытый вопрос о разделении продуктивного трафика и трафика управления.

5. Удалённый доступ — это не безопасно. Законодательство не предусматривает удаленное администрирование систем обработки БПДн. Администрирование необходимо осуществлять с отдельных АРМов, подключенных в сетевой сегмент системы. В крайнем случае, с отдельных АРМов, установленных в отдельных закрытых помещениях (СКУД, видео) и подключенных к контуру обработки с использованием ГОСТ VPN. Сам АРМ администратора защищается по КС3.

6. Системы обработки и хранения БПДн легко могут вовлечь Ваши другие системы в свой «контур аттестации»: как только мы хотим использовать СРК откуда‑то извне, тут же эта система РК попадает в «контур аттестации» и должна быть защищена так же, как и биометрическая система.

7. Трафик, содержащий БПДн, зашифрован ГОСТ‑алгоритмами (VPN или TLS) и его нельзя расшифровать по пути для проверки и балансировки. Даже по инфраструктуре организации вплоть до сервера, обрабатывающего БПДн, трафик должен проходить зашифрованным.

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

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

На схеме изображены все возможные типы устройств, которые надо защищать по‑разному, поэтому указано два вида СКЗИ: TLS‑шлюз и VPN‑шлюз. Для организации канала связи с использованием ГОСТ TLS на устройстве должен быть установлен криптопровайдер и браузерный плагин, а для канала ГОСТ VPN — VPN‑клиент, совместимый с VPN‑шлюзом.

Дополнительно сообщение с БО и ИСС необходимо подписывать электронной подписью. В случае, если это планшет или СВТ ОФР, подписание выполняет УКЭП сотрудника, если банкомат — КВ1 организации, если СКУД или устройство ФЛ — или подписание УНЭП/УКЭП или устройство или приложение должно быть сертифицировано ФСТЭК или иметь оценку соответствия по требованиям к оценочному уровню доверия не ниже чем ОУД 4 (п 7.6, раздел 7 ГОСТ Р ИСО/МЭК 15408-3-213).

В этой архитектурной схеме важно следующее:

• Сервер обработки, узел связи с ЕБС через СМЭВ и СКЗИ для подключения устройств получения БО размещаются в выделенной стойке, это одно из требований обеспечения уровня защищенности КС3.

• Шифрование канала связи между устройством и контуром — сквозное через всю ЛВС организации, нигде по пути не должно расшифровываться.

• Заказчик идентификации — система, для выполнения бизнес‑операций в которой нам понадобилась идентификация, не имеет отношения к передаче БПДн. Она может размещаться вне закрытого контура, а для получения ответа с подтверждением идентификации, ИСС и ПДн — использовать какой‑нибудь брокер сообщений, чтобы взаимодействовать с сервером обработки по API. Это тоже связано с безопасностью: закрытый контур не должен принимать входящих соединений кроме как через СКЗИ, допускаются исходящие из контура соединения. Поэтому система «выпихивает» ИСС в брокер, откуда её забирает «Заказчик».

• Для обеспечения степеней защиты КС1, 2 и 3 и СЗИ от НСД в сети организации должны быть созданы: сервер управления сертифицированным антивирусом, сервис сбора и анализа журналов ИБ с устройств сбора БО, сервис управления планшетными устройствами (MDM‑система).

• Взаимодействие с ЕБС или ЕСИА идёт по закрытым каналам связи, через СМЭВ, организация такого канала — тоже отдельная история с «Ростелекомом»: нужно стать участником взаимодействия в СМЭВ (на Госуслугах есть необходимая подробная информация).

Недостатки установки у себя узла связи с ЕБС:

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

• Так как требования к администрированию такого узла очень жёсткие (никакой удалёнки), то есть проблемы с SLA при выходе из строя оборудования, и нужно регулярно делать технологические «окна» для его обслуживания.

• Оборудование и ПО узла являются согласованным с ФСБ техническим решением, в котором нельзя заменить компоненты на компоненты других вендоров. Это просто чёрная, неизменяемая коробка в вашей инфраструктуре.

• Типовое решение не учитывает современных реалий обеспечения отказоустойчивости: кластеризации приложения и СУБД, георезервирования, необходимости кворумных ЦОДов и прочих «плюшек». Максимальный уровень — это горячий резерв сервера приложения и кластеры СКЗИ.

• По опыту: работа с ЕБС напрямую не позволяет создавать высоконагруженные, надёжные, отказоустойчивые системы, есть проблемы с временем отклика и количеством запросов в единицу времени (RPS).

Для устранения недостатков можно интегрироваться в коммерческией биометрические системы, которые есть у Банков и некоторых других организаций финансового рынка. Тогда не придётся организовывать узел связи с ЕБС, необходимо будет только наладить выделенный канал до какого‑нибудь банка и через него организовать взаимодействие по ГОСТ VPN с КБС. Схема архитектуры интеграции немного отличается от схемы с ЕБС:

Тут всё просто: организуем канал связи с ОФР, у которой есть своя КБС (как удобно обеим сторонам), устанавливаем у себя VPN‑шлюз и подключаемся к VPN‑шлюзу КБС, после чего получаем от КБС услугу по идентификации.

Шлюз на стороне организации потребителя услуги тоже должен размещаться в выделенной под биометрию стойке. Даже если у вас канал с банком уже как‑то зашифрован, всё равно канал между вашей обрабатывающей БПДн системой и КБС должен быть сквозным, от вашей стойки до стойки КБС нигде не расшифровывающимся, на сертифицированном ФСБ оборудовании с СКЗИ не ниже КС3 (это VipNet, S‑Terra, КриптоПро nGate и подобные железки российского производства).

Про надёжность и нагрузку

Добавим к нашей архитектуре немного надёжности. Есть ряд технических ограничений:

• Следует выбирать устройства СКЗИ (VPN‑ и TLS‑шлюзы), умеющие работать в отказоустойчивом кластерном исполнении.

• Если используется георезервирование или геораспределение (две и более площадок), то возможность подключения VPN‑клиента к разным площадкам в случае отказа основной надо уточнять на этапе выбора оборудования СКЗИ, не все так умеют. Трафик ГОСТ TLS можно балансировать между площадками с использованием anycast, DNS‑балансировки или GSLB.

• Если используется георезервирование или геораспределение, то трафик синхронизации серверов, СУБД и кластеров СКЗИ должен идти через зашифрованные по ГОСТу каналы связи.

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

• Если необходимо резервное копирование данных сервера обработки, то придётся организовывать такой сервис внутри контура биометрии, так как к хранению БПДн предъявляются такие же требования законодательства, как и к обработке — КС3. С одним нюансом: хранить БПДн нельзя, и БПДн и ИСС должны удаляться сразу, как только прошла процедура. Хранить БПДн можно только 30 дней в КБС для расследования инцидентов. Но если вы не делаете свою КБС, то и хранить вам ничего не надо кроме настроек сервера и ключей шифрования и подписи, а они не относятся к БПДн. Тут вопрос тонкий и требующий проработки специалистом ИБ. Нужно учесть, что если сервер сам будет «выпихивать» свои настройки в СРК, то это скорее приемлемо; а если СРК будет тянуться в контур, чтобы забрать копию, то это неприемлемо. Всё зависит от модели угроз. Что это такое, откуда она берётся, кем придумывается и как применяется на практике — тема отдельной большой статьи.

• Как писали выше, ФСБ не признаёт VLAN, а компоненты системы согласно ГОСТ 57580.1–2017 должны быть разделены на сетевом уровне. При этом управляющий трафик тоже должен быть отделён от продуктивного. В результате рождается решение с отдельными выделенными кластерами коммутаторов на каждой площадке: под продуктивный трафик и трафик управления. И с кластерами МСЭ для разделения потоков по подсетям.

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

Теперь наш контур выглядит так:

Что у нас получается:

• Устройства, подключающиеся по VPN, имеют основное подключение на одно плечо как активное, и на второе как резервное в случае отказа основного плеча. Надо подбирать VPN‑клиент и VPN‑шлюз, которые умеют так переключаться. Установив VPN‑канал, устройство сможет работать только с этим плечом, в случае разрыва соединения сессия идентификации прервётся. Решить это можно брокерами очередей, но такие брокеры относятся к обработке БПДн и тоже должны защищаться по КС3 и располагаться внутри контура. Мы считали, это выходит очень дорого.

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

• Устройства, работающие по TLS: тут легче, можно использовать балансировку любым доступным методом, главное, чтобы он не требовал расшифровки ГОСТ TLS и просто перенаправлял клиента на разные кластеры TLS‑шлюзов.

• В контуре должен быть свой кластер МСЭ (сертифицированный ФСТЭК по классу не ниже 4), который будет распределять служебный трафик управления и продуктивный трафик.

• В контуре должны быть: стек коммутаторов для продуктивного трафика и коммутаторы для управления оборудованием и СКЗИ (это желательно, но не 100% обязательное требование).

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

• Также трафик внутри контура должен анализироваться при помощи IDS и это тоже решение специалиста ИБ.

• Во всей этой обвязке обеспечения отказоустойчивости и информационной безопасности скромно установлены (внизу стойки, если хватило места) сами серверы обработки БПДн, защищённые по КС3: bare metal, с модулями доверенной загрузки, сертифицированными антивирусами, сертифицированной ОС с включенной замкнутой программной средой.

Ещё необходимо подумать о том, как будут подписываться сообщения в сторону КБС: это должна быть УКЭП КС3. Возможно, стоит завести себе HSM PKI, чтобы подпись хранилась надёжнее. Кстати, при использовании в контуре системы HSM PKI не все серверы контура можно будет защищать по КС3, а только те, где реально осуществляется подписание и проверка подписей БО, векторов и ИСС.

Несколько слов о системе сбора БПДн и передаче в ЕБС

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

1. Всё‑таки купить типовое решение со специальным ПО для сбора.

2. Организовать контур, как описано выше.

3. Пройти путь с «Ростелекомом» по подключению к СМЭВ.

4. Организовать отдельный закрытый контур сервисов поддержки, содержащий в себе:

   • контроллеры домена (каталога) для управления УЗ на всех серверах;

   • серверы управления СКЗИ;

   • серверы обновления ОС и ПО всего, что есть в контуре биометрии;

   • серверы мониторинга всего;

   • серверы сбора журналов всего;

   • АРМы, для админов, в отдельном защищенном помещении, защищённые по КС3 и подключённые VPN‑клиентом к контуру;

   • DLP‑систему и SIEM‑систему для слежения за операторами АРМов, на которых будут собирать БПДн;

   • свою СРК для всего этого.

Всё это надо организовать в экземпляре ТОЛЬКО для контура биометрии, общие от организации тут не подойдут. Помните, мы писали, что если к системе обращается с управляющими воздействиями какая‑то другая система, то она попадает в периметр и должна быть защищена так же, как система сбора БПДн. Таким образом, если подключить её к своим корпоративным, то защитить придётся их все и аудит ЦБ проходить тоже всей организацией.

Инфраструктурное ПО

Тут просто:

• Операционные системы — все в редакции ФСТЭК.

• СУБД импортозамещённые. Если хотите кластеры, то задумайтесь о том, что кворум в отдельном ЦОД будет стоить вам отдельной стойки и кластера СКЗИ для связи с остальными площадками.

Виртуализация возможна, но:

• Кластеры виртуализации, естественно, только под серверы контура.

• Серверы виртуализации — физически в контуре.

• На серверах — модули доверенной загрузки.

• Управление виртуализацией такое же, как и управление всем остальным — из контура.

• Само ПО виртуализации тоже должно иметь сертификат.

В целом, мы знаем только два российских решения, которые позволяют создавать системы класса защищённости до ГИС К1 и подходят под биометрию:

• zVirt — есть сертифицированный ПАК;

• ROSA — ПАКа нет, сертифицирован только гипервизор.

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

Заключение

Биометрия — это бурно развивающийся перспективный рынок, но требования законодательства делают вход дорогим, хотя решения на рынке есть, и их больше одного. Поэтому, если хотите начать, то пора уже планировать бюджет и присматривать решения. Важно понять, что систему с её СКЗИ и мерами защиты лучше спроектировать заранее ДО закупки чего либо, так как менять потом на ходу будет очень дорого.

Авторы:

Цыкин Павел, лидер по направлению технической архитектуры для заказчиков Т1/Сервионика.

Колотухин Александр, главный архитектор Т1/Сервионика.

Список нормативной документации

• Федеральный закон от 27 июля 2006 года № 152-ФЗ «О персональных данных»

• Федеральный закон от 29 декабря 2022 года № 572-ФЗ «Об осуществлении идентификации и (или) аутентификации физических лиц с использованием биометрических персональных данных, о внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных положений законодательных актов Российской Федерации»

• Федеральный закон от 07 августа 2001 года № 115-ФЗ «О противодействии легализации (отмыванию) доходов, полученных преступным путём, и финансированию терроризма»

• ГОСТ Р 57580.1–2017 «Национальный Стандарт Российской Федерации. Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер»

• ГОСТ Р 54412–2019 «Информационные технологии. Биометрия. Общие положения и примеры применения»

• Постановление правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»

• Постановление правительства РФ от 06.07.2008 № 512 «Об утверждении требований к материальным носителям биометрических персональных данных и технологиям хранения таких данных вне информационных систем персональных данных»

• Постановление правительства РФ от 16.04.2012 № 313 «Об утверждении Положения о лицензировании деятельности по разработке, производству, распространению шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнению работ, оказанию услуг в области шифрования информации, техническому обслуживанию шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя)»

• Приказ ФСБ от 10 июля 2014 года № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности»

• Приказ Министерства цифрового развития, связи и массовых коммуникаций РФ от 12 октября 2022 года № 179 «Об утверждении требований к подтверждению уничтожения персональных данных»

• Приказ Министерства цифрового развития, связи и массовых коммуникаций РФ от 12 мая 2023 года № 453 «О порядке обработки биометрических персональных данных и векторов единой биометрической системы в единой биометрической система и в информационных системах аккредитованных государственных органов, Центрального Банка Российской Федерации в случае прохождения аккредитации, организаций, осуществляющих аутентификацию на основе биометрических персональных данных физических лиц»

• Приказ ФСТЭК России от 11 февраля 2013 года № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»

• Приказ ФСТЭК России от 18 февраля 2013 года № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»

• Приказ ФСБ от 24 октября 2022 года № 524 «Об утверждении требований о защите информации, содержащейся в государственных информационных системах, с использованием шифровальных (криптографических) средств»

• Указание Банка РФ от 25 сентября 2023 года 6540-У «О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, векторов единой биометрической системы, проверке и передаче информации о степени соответствия векторов единой биометрической системы предоставленным биометрическим персональным данным физического лица при взаимодействии информационных систем организаций финансового рынка с единой биометрической системой»

• Указание Банка РФ от 25 сентября 2023 года 6541-У «О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, векторов единой биометрической системы, проверке и передаче информации о степени соответствия векторов единой биометрической системы предоставленным биометрическим персональным данным физического лица в информационных системах организаций финансового рынка, осуществляющих аутентификацию на основе биометрических персональных данных физических лиц, за исключением единой биометрической системы, а так же актуальных при взаимодействии информационных систем организаций финансового рынка, иных организаций, индивидуальных предпринимателей с указанными информационными системами»

• Методические рекомендации Банка России от 08.10.2024 № 18-МР «по нейтрализации организациями финансового рынка угроз безопасности, актуальных при обработке биометрических персональных данных, векторов единой биометрической системы, проверке и передаче информации о степени соответствия векторов единой биометрической системы предоставленным биометрическим персональным данным физического лица при взаимодействии информационных систем организации финансового рынка с единой биометрической системой»

• Методические рекомендации Банка России от 09.10.2024 № 19-МР «по нейтрализации организациями финансового рынка угроз безопасности, актуальных при обработке биометрических персональных данных, векторов единой биометрической системы, проверке и передаче информации о степени соответствия векторов единой биометрической системы предоставленным биометрическим персональным данным физического лица в информационных системах организаций финансового рынка, осуществляющих аутентификацию на основе биометрических персональных данных физических лиц, за исключением единой биометрической системы, а так же актуальных при взаимодействии информационных систем организаций финансового рынка, иных организаций, индивидуальных предпринимателей с указанными информационными системами»

Термины и сокращения