Всем привет! Меня зовут Наталья Бессонова, я директор проектов блока цифровой идентичности «Ростелеком». В этой статье хочу рассказать о том, как мы выбирали пассивный лайвнесс по одному изображению лица для Единой биометрической системы.

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

Круг DevOps – катаем квадратное, таскаем круглое

Всем привет! Это третья, завершающая, часть нашего рассказа о том, как «Ростелеком ИТ» внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы. Первую часть про внедрение CI/CD в десятки проектных команд очень большой компании можно прочитать на Хабре по ссылке здесь. Вторую часть – сугубо инженерную, с описанием прикладных подходов, инструментов и реализаций – читайте тут.

Сегодня мы расскажем про процесс внедрения в рамках Karma Framework в круге.

Привет, меня зовут Олег Герасимов, я директор центра компетенций IT-кластера Ростелекома. Наша команда среди многих задач разрабатывает прошивки камер видеонаблюдения для B2B и B2C-сервисов. В предыдущей статье я рассказывал, как мы научились самостоятельно разрабатывать софт и прошивки для IP-камер, в том числе и недорогих, и подключать их к облаку.

За прошедшее время камеры с нашей прошивкой уже появились на рынке, и, судя по данным Яндекс.Маркета, — на полках магазинов цены на них начинаются от 1500 рублей. И это уже не дешевый «ноунэйм», а качественные камеры ведущих мировых брендов: Hikvision, Dahua и Uniview. На мой взгляд, это отличный результат!

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

Привет! Как вы знаете, мы являемся провайдером видеонаблюдения на различных значимых событиях, в том числе и ЕГЭ. 

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

Обычно за ходом экзамена следят специальные люди — наблюдатели. Они отмечают на портале видеонаблюдения smotriege.ru подозрительное поведение участников ЕГЭ и передают обнаруженные нарушения на модерацию в Рособрнадзор. Если модераторы считают, что нарушение действительно было, то его передают дальше на отработку в пункт проведения экзаменов (ППЭ). Сотрудники ППЭ проверяют каждое такое обращение и решают, как поступить с нарушителем. Например, удалить с экзамена, если он использовал телефон или шпаргалку. 

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

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

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

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

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

И в процессе возникает вопрос — а как дизайн-систему будут применять пользователи? Станут ли следовать всем правилам и гайдам, если мы их заложим в систему? Если напишем подробные мануалы, будут ли их читать? А если не напишем — не появится ли масса вопросов о границах и правильности применения компонентов? Что лучше: жестко зафиксированная инструкция или, наоборот, никаких правил?

Платформа Цифровых Продуктов Ростелеком. Как это устроено

Датой создания Платформы Цифровых Продуктов (ПЦП) можно считать лето 2017. Старое название - Digital Sandbox, или просто Песочница.

В основе инфраструктуры лежат два тенанта на базе виртуализации OpenStack-KVM, размещенных в независимых ЦОДах Национальной облачной платформы: продуктивный стенд ПЦП на М9, стенд разработки на М10.

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

Создание платформы позволило существенно сэкономить время на разработке цифровых сервисов и продуктов, упростив их разработку и эксплуатацию за счет того, что теперь не нужна подготовка инфраструктуры “с нуля”. Появилась возможность легко, быстро и эффективно создавать сайты, веб-приложения, чат-боты, различные интеграционные сервисы, а у команды разработки внутри ПЦП - прототипировать, развёртывать и администрировать приложения без необходимости настройки какой-либо инфраструктуры и технологий. Время предоставления готового стенда сократилось до нескольких часов. Все это помогло сделать ПЦП центром IT ядра Ростелекома.

Сетевой сегмент DMZ-КСПД-НОП позволил нам интегрироваться с системами Ростелекома, что в дальнейшем помогло запускать сервисы, работающие с персональными данными по ФЗ-152.

Благодаря всему этому мы смогли сделать ПЦП оптимальным решением для российского рынка, так как ядро платформы построено на базе Open source с применением технологий OpenShift, Kubernetes, Docker, не требующих приобретения дополнительных лицензий, так как являются свободно распространяемым ПО, на ресурсах НОП с набором готовых к работе сервисов. 

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

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

Зачем это нужно знать, если есть встроенные методы сортировки?

Зачем изобретать велосипед заново?

Это нужно, чтобы пройти собеседование, объективно больше незачем это знать

В "любой движок javascript" работают не дураки, и уже сделали все как нужно

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

Сразу к делу

Как думаете, что произойдет после выполнения данного кода? ​

Тема до сих пор весьма хайповая, и админы, добавляющие в свои резюме словечко DevOps, автоматически рассчитывают на +100К к зарплате. Но мы не про это. Мы хотим рассказать про то, как Ростелеком ИТ внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы.

Первая часть нашего руководства будет про « Почему, зачем, как получить на это денег от бизнеса и как получается внедрять CI/CD в десятки проектных команд очень большой компании». Это интересная практическая информация для руководителей ИТ-подразделений и лидов. Вторая часть статьи – сугубо инженерная, с описанием прикладных подходов, инструментов и реализаций в зависимости от типа и технологического статуса проекта. И третий блок будет про процесс внедрения в рамках Karma Framework в круге. Поехали!

• Выработка ключевой пары валидатора для выдачи и проверки слепой подписи, как наиболее стойкий и рекомендуемый академическим сообществом для процедуры анонимизации в системах электронного голосования. В настоящий момент системой поддерживается алгоритмы слепой подписи на эллиптических кривых и на базе алгоритма шифрования RSA. В проводимом голосовании использовался алгоритм выдачи и проверки слепой подписи на базе алгоритма шифрования RSA с длиной ключа 4096 бит.
• Выработка общего открытого ключа шифрования. Для большей безопасности в процессе выработки ключа используется сразу два криптографических алгоритма: протокол DKG Pedersen 91 распределенной выработки ключа и протокол разделения ключа Шамира. Выработка ключа осуществляется как участниками, обладающими техническими средствами, позволяющими контролировать непосредственно ноды сети и сервера подсчета, так и участниками, которые являются хранителями ключей, записанных на внешние носители. Итогом работы двух этих алгоритмов является общий открытый ключ шифрования бюллетеней. Далее мы более подробно рассмотрим процедуру выработки этого ключа.

Оглавление

1. Не конкурент магнитной ленте
2. Жизнь после DiscoVision
3. Заключение

Не конкурент магнитной ленте