Знакомая журналистка рассказывала случай: послала её редакция писать репортаж с круглого стола, где собрались одни ИТ-специалисты. Материал не вышел, поскольку, по словам коллеги, все выступающие говорили на каком-то «птичьем» языке, где понятны только предлоги. «Мне тогда был нужен переводчик с ИТ-шного», — пошутила она.

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

ДЛЯ КОГО ПЕРЕВОДИМ?

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

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

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

ПРИМЕР

Ещё один сценарий, когда «переводчик» необходим, — если компания в сотрудничестве с вузами и другими учебными заведениями работает со студентами, готовит для них курсы по работе со своими продуктами, лекции. Пример тому — компания Servicepipe, которая запустила образовательный проект, направленный на подготовку специалистов в сфере информационной безопасности с акцентом на защиту от ботовых и DDoS-атак. Одно из направлений этого проекта — курс для студентов технических вузов, благодаря которому ребята изучают азы защиты от DDoS-атак и попробуют себя в роли безопасника, работая с ПО DosGate и Flow Collector. «Когда появилась идея курса, встал вопрос: кто будет учить? — рассказывает директор по продуктам Servicepipe Михаил Хлебунов. — Было очевидно, что нужен человек, который сможет "перевести" достаточно сложную техническую документацию по продуктам для студентов, выявить, какие именно понятия или термины им незнакомы, и разъяснить на понятном для обучающихся на 2–3-м курсе языке». То есть такой уникальный специалист, работающий на стыке технологий и лингвистики.

ИТ-переводчиком для молодёжи в компании стал Иван Горячев, студент 2-го курса МГТУ им. Баумана. Он также является сотрудником Servicepipe и менеджером образовательного проекта. В своей работе Иван решает задачи, включающие в себя элементы ИТ-перевода. В частности, он преобразует техническую информацию в доступные объяснения для студентов, упрощает и адаптирует технические тексты для образовательных целей, а также участвует в разработке учебных материалов, которые эффективно передают знания об ИТ-продуктах компании. Как отмечает сам Иван Горячев: «В ИТ-сфере информация устаревает очень быстро, поэтому умение оперативно и точно переводить технические тексты, адаптировать их для разной аудитории, становится критически важным. Моя задача — не просто переводить слова, а делать сложные вещи понятными для молодёжи».

СПРОС ПРЕВЫСИТ ПРЕДЛОЖЕНИЯ

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

Опрошенные эксперты также сходятся во мнении, что спрос на этих специалистов будет только расти. «Я не удивлюсь, если даже появятся отдельные рекрутеры, специализирующиеся на подборе ИТ-переводчиков, будут созданы профессиональные ассоциации и сообщества, — рассуждает Евгений Пудовкин. — Чем более сложную информацию необходимо "перевести", тем сложнее будет найти специалиста с глубоким пониманием технологий и лингвистики, и ИТ и ИБ-компании будут готовы платить высокую зарплату специалистам с таким набором навыков».

По словам Катерины Смирновой, ИТ-переводчики уже работают в компаниях-лидерах рынка — просто их должности пока называются по-разному: Product Evangelist, Solutions Architect с фокусом на коммуникацию, Technical Product Marketing Manager, IT Business Partner. Их ценность — в предотвращении потери времени, денег и нервов, когда «миры» перестают понимать друг с друга. «Я уверена, эта профессия станет массово востребованной, — указывает Катерина Смирнова. — Это естественная эволюция отрасли».

СПЛАВ ТЕХНАРЯ И ГУМАНИТАРИЯ

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

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

По словам Ивана Горячева, также обязательно уметь работать с ИИ (DeepSeek, ChatGPT и т. д.), которые помогают снять часть «глупых» вопросов. «Конечно, "перевод" ИИ не сделает, но позволит хотя бы не дёргать коллег с просьбой пояснить тот или иной термин или аббревиатуру», — говорит он.

МЕЖДУНАРОДНЫЙ ОПЫТ

В чистом виде переводчиков с ИТ в мировом опыте пока нет. Но есть специалисты, которые решают схожие задачи. Подобные навыки в других странах включает в себя должность Technical Evangelist, специалиста, который продвигает новые технологии и решения, объясняя их преимущества простым и понятным языком. Также существует должность Solution Architect, специалиста, который проектирует ИТ-системы, учитывая потребности бизнеса и технические возможности. Ещё есть Technical Writer — специалист, который создаёт техническую документацию, понятную для пользователей разного уровня подготовки, а также Knowledge Manager — специалист, управляющий знаниями в организации, обеспечивая их доступность и актуальность.

Успешные примеры включают в себя создание должности Developer Advocate в компании Google, который занимается продвижением Google Cloud Platform среди разработчиков, объясняя им, как использовать облачные сервисы для решения своих задач. В компании Microsoft существует программа Microsoft Certified Trainer, на которой ИТ-специалистов обучают использованию продуктов Microsoft.

ОТ СКЕПСИСА ДО ШТАТНОГО РАСПИСАНИЯ

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

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

Минфин России сообщил, что 17 сентября Казначейство впервые начислило зарплату в цифровых рублях. Первым россиянином её получившим стал председатель думского комитета по финансовому рынку Анатолий Аксаков.

Аксаков рассказал, что деньги уже поступили на его цифровой кошелёк на платформе Банка России, а сам депутат протестировал систему, совершив переводы в благотворительные фонды и оплатив заказ в кафе с помощью QR‑кода.

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

Меняется мир, меняются требования

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

Что обычно происходит после успешной атаки (инцидента ИБ)? Начинается борьба с её последствиями, выделение денег на закупку и внедрение новых систем мониторинга, антивирусов, DLP, ИИ и других модных продуктов и технологий, а не устранение причин, приведших к инциденту.

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

Увы, этот сегмент ИБ — самый консервативный, нормативная база здесь не менялась десятилетиями.

Пароли

Существующая нормативная база предписывает использование для аутентификации пользователей в ИС паролей — не менее шести символов при мощности алфавита 30 символов для ИС 4-го класса защищённости, не менее восьми символов при мощности алфавита не менее 70 символов для ИС 1-го класса защищённости, а также смену пароля через каждые шесть месяцев и один месяц соответственно.

Насколько это надёжно сегодня?

Оценки времени, затрачиваемого на прямую атаку — прямой перебор всех возможных вариантов пароля (bruteforce) при использовании домашнего компьютера с двенадцатью графическими картами RTX 5090, приведены в таблице 1 ниже [1].

Таблица  1

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

А если увеличить мощность вычислительного ресурса и использовать облачный ресурс, например, Amazon (AWS) или ChatGPT-4?

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

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

А теперь давайте вспомним 2020-2021 гг., когда мы сидели на удалёнке. С чем мы столкнулись? С тем, что пользователи, выучив свой сложный пароль для доступа в корпоративную ИС, не сильно задумываясь о последствиях вводили его при заказе пиццы, в различных сервисах и соцсетях. Потом эти чужие сервисы ломали, пароли массово утекали в сеть, а затем уже попадали в объединённые базы типа Collection #2-5 (25 млрд учётных записей и паролей к ним). В результате там оказывалось до 7-10% наших сотрудников со своими актуальными паролями к корпоративным ресурсам.

Тот самый пресловутый человеческий фактор…

«Честными» — правильными и действительно стойкими паролями (выбранными случайно равновероятно из слов заданной длины используемого алфавита) практически никто не пользуется, запомнить их нереально, поэтому люди пользуются парольными фразами или составными паролями на основе легко запоминаемых слов.

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

Таблица 2

Резюме

Надёжность защиты ИС с помощью правильных восьмисимвольных паролей типа t~pbE#0u (как предписывают нам нормативные требования) — это иллюзия, такая защита ломается примерно за пять часов при стоимости аренды ресурсов ~$20.

Про использование паролей для аутентификации в корпоративных ИС следует забыть и использовать более надёжную аутентификацию — усиленную или строгую.

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

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

Основные понятия идентификации и аутентификации и требования к их реализации определены в российских национальных стандартах [2], основные из них:

• ГОСТ Р 58833-2020 (Идентификация и аутентификация. Общие положения).
• ГОСТ Р 70262.1-2022 (Идентификация и аутентификация. Уровни доверия идентификации).
• ГОСТ Р 70262.2-2025 (Идентификация и аутентификация. Уровни доверия аутентификации).

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

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

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

Идентификация всегда производится в два этапа: первичная и вторичная.

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

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

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

Уровни доверия идентификации определяют степень уверенности в правильности определения личности пользователя:

• Низкий (некоторая уверенность).
• Средний (достаточно высокая уверенность).
• Высокий (очень высокая уверенность).

Аутентификация пользователя — это процесс подтверждения (доказательства) подлинности пользователя и принадлежности ему предъявленного идентификатора.

Идентификация и аутентификация всегда неразрывны и используются вместе. Надёжность одного процесса существенно влияет (определяет) надёжность (уровень доверия) другого.

Цели аутентификации пользователей в ИС

1. Подтверждение личности пользователя (по предъявленному им идентификатору).

2. Установление доверительных отношений между участниками (сторонами) обмена:

• Аутентификация одной стороны (например, источника данных) — односторонняя аутентификация;
• Аутентификация обеих сторон (например, элементов ИТ-инфраструктуры) — взаимная аутентификация).

3. Предоставление доступа в ИТ-инфраструктуру или в ИС только «подлинным» пользователям;

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

Достоверность результатов идентификации и аутентификации и уровень доверия ИС

Достоверность (корректность, правильность) результатов идентификации и аутентификации и уровень доверия ИС зависят от ряда параметров:

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

2. От уровня доверия аутентификации, определяемого видом аутентификации, характеризуемого:

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

3. От способов реализации аутентификации в ИТ-инфраструктуре и самой ИС (всего их восемь — локальная, прямая, доменная, иерархическая, распределённая сетевая, мостовая, браузерная и браузерная с трансляцией доверия).

4. От среды функционирования и места выполнения (замкнутая доверенная или недоверенная среда, внутри или вне защищённого периметра).

Уровень доверия ИС определяется достигнутым уровнем доверия идентификации и аутентификации и не может быть выше него. При этом определяющим является используемый вид аутентификации.

Их три (таблица 3).

Таблица 3

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

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

Особенности и примеры:

1. Однофакторная

• Пароль — запоминаемый и вводимый вручную (фактор знания общего с ИС секрета);
• Одноразовый код доступа, присылаемый из ИС на зарегистрированное в ИС устройство пользователя;
• Электронный идентификатор, не требующий ввода PIN-кода (фактор владения).
• Использование биометрии в качестве единственного фактора аутентификации не допускается (например, лицо, голос или отпечаток пальца, снятый сканером, встроенным в компьютер пользователя).

2. Односторонняя — передача аутентификационной информации осуществляется в одном направлении — от пользователя к объекту доступа (ресурс ИС), при этом пользователь не может быть уверен, что получает доступ в нужную ему ИС, что её не подменили.

Усиленная аутентификация

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

Существенными условиями и отличиями от простой аутентификации являются:

• Использование двух факторов аутентификации (2ФА) — владения аппаратным устройством и знание пароля (секрета) или
• Использование двухэтапной [3] проверки — подтверждение личности пользователя с использованием фактора знания (долговременного пароля) и одноразового пароля (кода доступа), присылаемого пользователю на его зарегистрированный в ИС мобильный телефон SMS, push-уведомление, либо
• Одноразовый пароль (ОТР), сгенерированный в приложении, установленном на мобильном телефоне пользователя на основе общего с ИС секретного ключа. Секретный ключ может быть загружен в приложение при инициализации, при сканировании QR-кода или другим способом. Технически сложной является задача безопасной передачи секрета в приложение, у многих она не решена, что сводит на нет всю безопасность.

Примеры:

• Google Authenticator (его использование противоречит российскому законодательству).
• Яндекс Ключ.
• Aladdin 2FA + корпоративный высокопроизводительный сервер аутентификации JAS (решена проблема безопасной передачи секрета на устройство пользователя).
• Аппаратные ОТР-токены, U2F-токены (FIDO/FIDO-2), USB-токены, в защищённую память которых загружен файл-контейнер или сертификат, содержащий пользовательский идентификатор.
• Приложение на смартфоне, генерирующее и обслуживающее ОТР-токены и др.

Опасность и особенности:

• Мобильный телефон, независимо от установленной ОС, является недоверенным и небезопасным.
• Один ОТР-токен позволяет подключаться только к одной ИС, для работы с ОТР-токенами на стороне ИС требуется сервер аутентификации.
• Перехват кодов доступа, извлечение из телефона секретного ключа для генерации ОТР способно дискредитировать всю ИС и дать злоумышленникам доступ в неё под видом легальных пользователей (как в своё время было со взломом RSA SecurID).

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

Строгая аутентификация пользователей обязательна для применения в ИС с доменной архитектурой с высоким уровнем значимости информации и значительным размером возможного ущерба — для всех пользователей в ГИС класса защищённости К1, для привилегированных, удалённых пользователей, мобильных пользователей переносных устройств (ноутбуков), при обработке в ИС информации ограниченного доступа, для сотрудников подрядных организаций и их ИС, подключающихся к обслуживаемой ИС [4].

При строгой аутентификации должна применяться двух- или трёхфакторная взаимная аутентификация (2ФА/3ФА) с организацией двухстороннего обмена аутентификационной информацией между пользователем и объектом доступа, либо многостороннего обмена при использовании третьей доверенной стороны (корпоративного Центра Сертификации, выполняющего функции корпоративного «нотариуса»).

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

Третья доверенная сторона (Центр Сертификации) выполняет функции проверяющей стороны (Центр Валидации), и может не являться прямым участником обмена между пользователями и ИС, но может обеспечивать их данными, необходимыми для аутентификации (например, Ticket Kerberos для аутентификации в домене).

Необходимые компоненты для построения корпоративной PKI, обеспечения ДОВЕРИЯ и строгой аутентификации в ИС:

1. Корпоративный Центр Сертификации (ЦС, CA — Certificate Authority) [5]

• Это ключевой компонент, основа системы обеспечения доверенного взаимодействия всех объектов (сетевого, компьютерного оборудования, ПО, сервисов в ИТ-инфраструктуре), субъектов (пользователей) в ИС, основа корпоративной PKI.
• Центр Сертификации должен быть доверенным, ему должны безусловно доверять все элементы ИС и все участники обмена для реализации концепции Zero Trust (нулевое доверие), когда никто в ИС никому не верит, но все доверяют корпоративному «нотариусу» (СА), который всех идентифицировал, проверил и по запросу подтвердил подлинность. И это не должен быть Microsoft CA (CS) — бесплатный сыр в мышеловке и единая точка отказа в большинстве наших ИТ-инфраструктур.
• Центр Сертификации должен быть сертифицирован ФСТЭК России — его безопасность, корректность функционирования и уровень доверия должны быть проверены и доказаны в процессе сертификации.

2. Служба каталога с контроллером домена (для ИС с доменной архитектурой)

• Примеры реализации: Windows — Active Directory, Linux — ALD Pro, РЕД АДМ, Альт Домен, Samba DC, FreeIPA и др.

3. USB-токены, смарт-карты, BIO-токены/ридеры со встроенным сканером отпечатков пальцев — это пользовательские аппаратные средства 2ФА/3ФА (фактор владения). Требования к ним:

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

4. Клиентское ПО, обеспечивающее поддержку устройств аутентификации, работу с цифровыми сертификатами и PKI.

• В MS Windows таким штатным клиентским ПО является Windows Smartcard Logon.
• В Linux (и всех российских ОС на базе Linux) штатной поддержки PKI и средств 2ФА/3ФА нет.

Это серьёзная проблема, поскольку именно PKI обеспечивает безопасное доверенное взаимодействие всех со всеми в корпоративных сетях и инфраструктурах Enterprise-класса.

5. Система централизованного управления жизненным циклом сертификатов и средств 2ФА/3ФА.

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

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

Что нужно для внедрения строгой аутентификации и повышения живучести наших ИС?

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

Как только началась СВО, нам послали первое предупреждение — отозвали сертификаты для межсайтового взаимодействия, и половина Интернет-сайтов в стране «легла», точнее, не смогла обеспечить то самое доверенное взаимодействие.

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

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

А если перестанет работать корневой СА (который до поры до времени находился в офлайне, а вам надо перевыпустить сертификаты для подчинённых СА, срок действия которых заканчивается) или Центр Валидации, который и проверяет предъявляемые всеми участниками обмена сертификаты?

Вот тут и начнётся страшный сон — наши ИТ-инфраструктуры («железо», сервисы, ПО) рискуют развалиться за сутки, все компоненты перестанут доверять друг другу и взаимодействовать друг с другом. Почему сутки? Это срок жизни тикета Kerberos.

Так что же происходит при миграции на Linux? Почему там всё не так?

А всё достаточно просто — в Linux нет полноценного PKI корпоративного уровня, а без него — это всё консьюмерская история, не Enterprise, к которому мы все так привыкли.

И Open Source нам здесь, увы, не помощник — «поляна» хорошенько зачищена, поскольку это стратегическая технология, и как мне в своё время объяснили, цитирую: «Продать Enterprise PKI в Россию, это хуже, чем поставить ядерные технологии в Иран» (рисунок 1).

Рисунок 1

Резюме

Чтобы «вытянуть» Linux на уровень Enterprise, обеспечив при этом сквозную безопасность от ИТ-инфраструктуры до пользователей, реализовать доверенное взаимодействие, необходимо:

1. Внедрить корпоративную PKI — доверенный СА под Linux, который заменит MS CA — единую точку отказа, обеспечив бесшовный переход без остановки работы всех сервисов. Это обеспечит возможность «жить на два дома» — одновременно пользоваться ресурсами и из мира Windows, и новыми, из мира Linux.

2. Внедрить (поддержать с использованием нового доверенного СА) строгую аутентификацию всего используемого оборудования в ИТ-инфраструктуре.

3. Внедрить строгую аутентификацию пользователей (с использованием клиента PKI и 2ФА под Linux, обеспечивающего возможность «ходить налево» — в Windows). И не забыть про систему централизованного управления.

Ключевые различия двух экосистем (рисунок 2).

Рисунок 2

Адаптивная многофакторная аутентификация

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

А раз оно так, то разве можно подходить ко всем с одними правилами и требованиями по аутентификации? Нет, нельзя.

Для разных сегментов ИС, условий работы пользователей, для разных сред функционирования (в т. ч. средств 2ФА) должен быть определён РАЗНЫЙ набор факторов, дополнительных средств и способов подтверждения идентификационных данных и их связи с личностью пользователя.

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

Это и есть адаптивная многофакторная аутентификация (МФА), реализовать и поддерживать которую достаточно просто.

Попробуем показать и объяснить это с использованием рисунка 3.

Рисунок 3

1. Сотрудник работает в офисе

Контролируемый периметр объекта (здания, офиса), правильно настроенный корпоративный ПК, доверенная среда функционирования используемого ПО, развёрнута PKI, сотрудник работает с чувствительной информацией (CRM, ERP, персональные данные клиентов и пр.).

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

2. Привилегированные пользователи (администраторы, ВИПы, ТОПы) с корпоративными ноутбуками

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

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

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

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

Для устранения этих рисков необходимо использовать специализированное средство, обеспечивающее безопасную дистанционную работу и строгую 2ФА пользователя, работающего из недоверенной среды [7].

4. Сотрудники на удалёнке (с корпоративными ноутбуками — в доверенной среде функционирования)

Работают с чувствительной информацией (CRM, ERP, с персональными данными клиентов), им было дано разрешение работать удалённо, подключаясь из дома или работая на даче (где относительно безопасно).

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

Для многих организаций это недопустимый риск.

Чтобы получить геолокацию, понадобится зарегистрированный в ИС номер мобильного телефона такого сотрудника и дополнительные средства, обеспечивающие дополнительную (усиленную) аутентификацию с отправкой на него push, SMS, ОТР сообщений и обработку данных геолокации по базовым станциям (увы, GPS/ГЛОНАСС теперь могут увести далеко не туда). И это в дополнение к его штатному USB-токену. Телефон нужен как «второй» фактор с возможностью получения геолокации, позволяющий осуществлять блокирование доступа из-за границы.

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

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

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

6. Внешние пользователи открытых публичных сервисов

Являются потребителями информационных сервисов, подключаются к публичным ресурсам ИС.

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

Резюме

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

Правильная система аутентификации в ИС — залог её безопасности.

Подразделение компании Imperva проанализировало данные из более чем 4000 сред по всему миру и подготовило отчёт об угрозах API. В первой половине 2025 года под прицелом злоумышленников оказались сферы финансовых услуг, телекоммуникаций и туризма: только за этот период Thales зафиксировала 40 тыс. инцидентов.

В отчёте утверждается, что API в настоящее время привлекают 44% трафика продвинутых ботов, генерируемого сложным ПО, имитирующим поведение человека. На 40% увеличилось количество попыток подмены учётных данных и захвата аккаунтов, направленных на API без адаптивной MFA. На сбор данных пришлась почти треть (31%) активности API-ботов, на мошенничество с купонами и платежами — 26%, а на попытки удалённого выполнения кода (RCE) — 13%. Наиболее часто атакуемыми продуктами были Log4j, Oracle WebLogic и Joomla.

Безопасники отметили, что 27% инцидентов API за изученный период зафиксировано в финсекторе; далее следуют телеком и интернет-провайдеры (10%), туризм (14%), а также развлечения и искусство (13%). «API — это связующая ткань цифровой экономики, но в то же время это делает их наиболее привлекательной площадкой для атак», — заявил вице-президент по продуктам безопасности приложений компании Thales Тим Чанг.

Эксперты Thales сообщили и о крупной DDoS-атаке на уровне приложений в первой половине года с рекордным количеством запросов — 15 млн в секунду. В отчёте уточняется: 27% DDoS-трафика, ориентированного на API, было направлено на финансовые сервисы, поскольку те сильно зависят от API для операций в режиме реального времени, таких как проверка баланса, переводы и авторизация платежей.

Чан же предупредил, что объём и сложность атак на API в ближайшие месяцы продолжат расти, и к 2026 году ожидается уже более 80 тыс. инцидентов. «Организации должны выявлять каждую работающую конечную точку, понимать её бизнес-ценность и защищать её с помощью адаптивных средств защиты, учитывающих контекст, если они хотят сохранить прибыль, доверие и соответствие требованиям» — резюмировал эксперт.

Усам Оздемиров

«Google Таблицы» теперь поддерживают шифрование на стороне клиента (CSE). Как пояснили в компании, это обеспечит «полную совместимость» с Microsoft Excel тем, кому необходимо защитить чувствительные сведения (интеллектуальную собственность или, например, финансовые документы), и «добавит новый уровень безопасности к базовому».

Благодаря CSE в Google Workspace организация будет сама хранить ключи, а данные — шифроваться в браузере ещё до того, как попадут на серверы Google, где даже сам техгигант их не сможет расшифровать. Функция доступна определённым подписчикам GW, включая Frontline Plus, Enterprise Plus, Education Standard и Education Plus, и подразумевает полную поддержку импорта, экспорта и дешифрования, а также экспорта в Vault для целей электронного раскрытия информации.

При включённом CSE необходимо скачать, расшифровать и преобразовать файл «Таблиц», если его требуется использовать в Microsoft Office. Для этого нужно:

• использовать инструмент экспорта данных или Google Vault;
• задействовать опцию расшифровки экспортированных файлов (пока доступна только для Windows);
• открыть отдельный инструмент конвертации;
• выбрать исходную папку и нажать «Преобразовать».

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

ВТБ внедряет авторский ИИ в антифрод — он защищает клиентов от взломов аккаунтов и социнженерии, а также контролирует подозрительные операции. Об этом рассказал заместитель президента — председателя правления банка Вадим Кулик на международном форуме Kazan Digital Week — 2025.

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

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

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