Информационная безопасность *

ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)

20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.

Несколько информационных моментов.

1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО

Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.

2. Вебинары РБПО-направленности

Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:

1. Интеграция статического анализа и DevSecOps: PVS-Studio и AppSec.Hub в действии.

2. Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM.

Приглашаем принять участие в следующем совместном с "ИНСЕК" вебинаре "Регулярный статический анализ по ГОСТу" (21 мая 12:00 по Москве), где они презентуют InSeq RBPO.

Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.

3. Сертификация ФСТЭК

В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?

Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).

PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.

PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):

• PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);

• PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);

• продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.

Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.

В феврале 2025 вышел релиз Docker Engine 28.0.0, устранивший проблемы безопасности:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:

Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment. 

Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.

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

К сожалению, нежелание признавать CVE со стороны различных разработчиков случается периодически. В моей практике была ситуация, когда разработчик не просто не хотел заводить CVE, а ещё и желал, чтоб я сам отозвал CVE. После моего отказа пытался CVE оспорить (но, неудачно). Подробности - в статье "Как я зарегистрировал CVE и разозлил вендора"

Личный кабинет налогоплательщика, или как потерять доступ, если бы не длинный буфер обмена Windows 11

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

1. Входим в ЛК.

2. Нажимаем "Изменить пароль" в настройках профиля.

3. Генерируем пароль сторонним сервисом, назовем его "Пароль 1".

4. Вводим пароль, сохраняем.

5. Вдруг система говорит, что в пароле нет цифр!..

6. Хорошо, генерируем новый пароль, с цифрами.

7. Вводим новый пароль... О-па, а в поле "Старый пароль" уже неверный пароль.

8. Нервно ищем Пароль 1. Оказывается, что он применился, несмотря на ругань системы. Если не нашли, то всё... Мне помог длинный буфер обмена Windows 11.

Шёл 21-й век.

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

• Продуктовая разработка: DevOps или Golang.

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

• Команда внедрения: QA.

• Технические продажи: технический менеджер клиентов.

Что тебя ждет:

• оплачиваемая стажировка,

• работа в реальных проектах,

• поддержка наставников и экспертов,

• регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

У пенсионера из США c помощью социальной инженерии украли 3520 биткойнов на $330 миллионов. Мошенники потом кучу раз дробили сумму и отмыли её через 300 кошельков и 20 бирж. Большую часть денег вообще перевели в XMR — монету, которую трудно отследить. Эксперты говорят, что вернуть эти криптоактивы пострадавшему невозможно.

ИБ-дайджест InfoWatch

Утечка данных оператора связи
Телекоммуникационная компания MTN Group сообщила об утечке ПДн абонентов, подчеркнув, что это не повлияло на работу ее сети.

Кибератака на телеком-оператора
Корейский оператор SK Telecom расследует хакерский взлом — злоумышленники использовали вредоносное ПО и завладели ПДн клиентов.

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

Форум безопасного Интернета
На «XIV Форуме безопасного Интернета» рассказали про архитектуру мошенничества и противодействие подобным манипуляциям в докладе «Как активировать психологическую защиту пользователей».

Нейронные сети в руках хакеров

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

Когда программист делает запрос на генерацию кода скажем бекенда для веб сервера его запрос проксируется в ChatGPT, а потом модифицируется скриптом, который добавляет небезопасный код.

Попутно сайт собирает информацию о самом программисте, например, IP адрес, а в случае регистрации - email работодателя.

Информация сохраняется для разработки, через полгода-год когда код гарантировано попадает на прод происходит кибератака.

Телеграм, дай возможность отозвать заявки в группы! Это же базовый функционал!

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

История банальна до смешного. Вечер, пишет какой-то аккаунт, кидает ссылку на группу "взаимной подписки". Мозг отключен, палец машинально жмет "Подать заявку". Через час доходит – зачем мне это? Лезу в диалог, а приглашение уже удалено. Название группы? Не помню. Ссылка? Потеряна.

И тут начинается паранойя. А что, если это была какая-то мутная группа? Что, если ее завтра переименуют во что-то совершенно неприемлемое? А я там буду висеть в "кандидатах на вступление", и отозвать заявку НЕ МОГУ, потому что я ее тупо не вижу!

Я перерыл все настройки – бесполезно. Telegram не показывает список твоих активных, еще не одобренных заявок. Ты просто сидишь и надеешься, что пронесет, или что админ той самой группы (которую ты даже не помнишь) отклонит твой запрос.

В моем случае все разрешилось относительно мирно. Через пару дней меня приняли в очередной канал про "успешный успех". Фух, пронесло.

Но сама ситуация – дичь! Почему я не могу контролировать, куда я "постучался"? Почему нельзя посмотреть список своих ожидающих заявок и отменить ненужные? Это же базовая гигиена цифровой безопасности и просто здравый смысл!

Как-то неловко случайно "подписаться" на неизвестно что без права на отмену.

Кто-нибудь еще сталкивался с такой проблемой?

Как автоматизировать распознавание текста с изображений?

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

Раньше в моём арсенале был только pytesseract (Python-библиотека для распознавания текста). Она работала, но с серьёзными ограничениями:
➖Плохо справлялась с разными шрифтами
➖Теряла точность на низкокачественных изображениях
➖Путала языки, если текст был мультиязычным

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

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

Обзор моделей для OCR
Прошерстив не один десяток источников, я выделил две наиболее популярные на текущий момент модели:
1️⃣ GPT-4 mini — высокая точность, но платная.
2️⃣ Google Gemini 2.0 Flash — высокая точность + бесплатный лимит.

Выбор без раздумий пал на Gemini. На момент публикации бесплатные лимиты от Google следующие:
✔️ 15 запросов в минуту
✔️ 1 млн токенов в минуту (ввод + вывод)
✔️ 1 500 запросов в сутки

Как взаимодействовать с Gemini?
1️⃣ Получаем API-ключ в Google AI Studio
2️⃣ Через API отправляем изображение в base64 + промпт
3️⃣ Получаем распознанный текст в ответе

Но есть важный нюанс: сервис не работает с российскими IP

Что делать, если Gemini недоступна?
Если у вас по какой-то причине нет возможности получить доступ к серверам Google AI Studio, то можно воспользоваться сервисами, которые предоставляют доступ к различным open-source моделям. Например, DeepInfra.
Плюсы:
✔️ Нет блокировок по геолокации
✔️ Гибкая тарификация
Минусы:
✖️ Нет бесплатного тарифа

Примеры скриптов выложил на github (https://github.com/vmtest439/britalb_ocr)

Если вам понравился пост и вы хотите читать больше подобного контента, то можете подписаться на мой авторский Telegram-канал BritLab!

Время уходит — компаниям до 30 мая следует сообщить в РКН об утечках данных

Скоро в России вступят в силу новые законодательные требования по обороту ПДн. Вчера в ТАСС состоялась посвященная этой теме пресс-конференция. Модератором и участником стала Наталья Касперская, президент ГК InfoWatch.

Главные тезисы:

• Наталья Касперская: утечки ПДн затрагивают не только бизнес, но и всех граждан. Они — причина успеха кибермошенников, которые используют достоверную информацию о людях для обмана.

• Михаил Смирнов (эксперт и главный редактор BISA): масштабы проблемы утечек данных не осознаны и недооценены. Объем скомпрометированных ПДн растет — в 2024 году из российских компаний утекло 1,5 млрд записей ПДн.

• Милош Вагнер (замруководител РКН): у компаний до 30 мая есть время, чтобы проинформировать уполномоченные органы о произошедших ранее инцидентах. И тогда к ним будут применяться текущие меры ответственности, а не более строгие.

Подробнее — на сайте InfoWatch.

Безопасная разработка API на практике

Как устроен ваш цикл разработки приложений? Проверяются ли API на наличие уязвимостей до их публикации? И есть ли вообще для этого процесса какая-то методология?

Вместе с экспертом команды Вебмониторэкс, участвующим в совместной работе с ИСП РАН, подробно разберём, как выстроить эффективный процесс тестирования API, и чем отличаются различные его виды.

Когда? 23 апреля в 14:00

Спикер: Динко Димитров, руководитель продуктового направления, Вебмониторэкс

Зарегистрироваться на мероприятие 

Ждем вас на вебинаре!

Цитату из Библии нашли в блоке №666 666 в блокчейне Bitcoin: «Не будь побеждён злом, но побеждай зло добром» — Римлянам 12:21.

Коллеги, если вы знаете, что такое TAP и SPAN, вам не безразличны вопросы зеркалирования и оптимизации сетевого трафика, а ещё хочется узнать, как в этом помогают брокеры сетевых пакетов, то 23 апреля мы ждем вас на техническом вебинаре, где мы подробно обсудим эти темы. А ещё помимо слайдов с картинками будет живая демонстрация работы ответвителей трафика DS TAP и пакетных брокеров DS Integrity в связке c системой анализа сетевого трафика PT NAD.

Зарегистрироваться нужно тут, присоединяйтесь!

Когда тема ИБ вышла за пределы профессиональной аудитории и попала в федеральные СМИ, мы не можем пройти мимо. А когда речь идёт ещё и об одной из самых удобных баз уязвимостей, мы просто обязаны вставить свои 5 копеек.

Итак, представим, что с финансированием CVE всё будет плохо и российские пользователи перестанут получать информацию об актуальных уязвимостях. Руководитель технического центра «АйТи Бастион» Владимир Алтухов видит в этом ещё один шаг в направлении антиглобализации мира ИБ. Универсальный для всех специалистов на планете инструмент исчезает, поэтому возникает необходимость пользоваться чем-то своим.

Не стоит радоваться тому, что не надо будет закрывать какую-то Цэ-Вэ-Ешку – обязательно придётся закрыть очередную БДУшку!

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

Да, с учётом геополитической нестабильности, исключать внезапное отключение от всего привычного нельзя. Поэтому в очередной раз настоятельно рекомендуем быть готовыми заранее к любому развитию событий. Базовый набор «подушки безопасности от неизвестных уязвимостей» прост:

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

✅ Соблюдать принцип Zero Trust.

✅ Отдавать предпочтение зрелым продуктам ИБ с подтверждённым уровнем доверия и на сертифицированных ОС.

Как известно, основной глобальный инструмент для просмотра логов Certificate Transparency (CT-логов) через веб-интерфейс - это crt.sh. Однако сертификаты российских УЦ в глобальные логи пока не попадают (перечень принимаемых сертификатов и пресертификатов в CT-логе всегда ограничен некоторым набором корневых ключей). Для российских УЦ запущены российские CT-логи. Для просмотра российских CT-логов тоже есть сервисы с веб-интерфейсом:

• ct.tlscc.ru - это выделенный экземпляр crt.sh, поддерживаемый ТЦИ и настроенный на российские логи; веб-сайт использует TLS-сертификат, выпущенный от корня ТЦИ, так что если корня в браузере нет, то будет выдаваться предупреждение; (пример запроса);

• precert.ru - отдельный и весьма удобный сервис, имеющий целый ряд преимуществ: например, здесь другой интерфейс для поиска записей, подробная статистика по логам и УЦ; (пример запроса).

Сейчас в российские CT-логи добавляются сведения о сертификатах, выпускаемых НУЦ (все логи) и ТЦИ (логи "Яндекса" и VK). Основной объём логов составляют пресертификаты, которые добавляют сами УЦ, в процессе выпуска сертификата. Пресертификат отличается от сертификата наличием специального расширения (CT Poison), отсутствием SCT-меток и значением подписи. Обратите внимание, что сертификаты добавить в CT-лог может каждый. Например, можно добавить сертификат, найденный на каком-то веб-узле в Сети (если, конечно, сертификат выпущен подходящим УЦ). Но для добавления придётся уже воспользоваться HTTP-интерфейсом соответствующего лога напрямую, подготовив и отправив POST-запрос.

Зачем просматривать CT-логи? Во-первых, наличие сторон, изучающих записи в CT-логах, это основной декларируемый смысл Certificate Transparency. Во-вторых, просмотр логов позволяет пронаблюдать, что и для чего выпускается, и даже минимально контролировать выпуск сертификатов для тех доменов, которые вы администрируете; Certificate Transparency не гарантирует, что сведения о выпущенном сертификате будут в CT-логе, но такие сведения могут там быть, а сам по себе сертификат, благодаря наличию цифровой подписи, это какой-никакой, но документ, подтверждающий хотя бы свой собственный выпуск. В-третьих, в логах можно найти что-то неожиданное - для этого внимание нужно обращать на таймстемпы, на формат (пре)сертификатов, на состояние конкретных лог-сервисов.

Как я едва не стал жертвой мошенников с помощью Zoom-схемы

Хочу поделиться историей, которая произошла буквально час назад — всё выглядело настолько реалистично, что я по-настоящему поверил, что это обычное собеседование. Но в итоге это оказался тонко продуманный скам, и я чудом не попался.

Всё началось с приглашения на интервью

Мне написал человек в Telegram под ником @AlexImmerman. Он представился сотрудником компании xLabs, объяснил, что им нужен человек с моими навыками, и пригласил на Zoom-интервью. Меня немного смутило, почему он пишет через Telegram, а не через LinkedIn, но он удачно соврал, что меня ему порекомендовали ребята из одного криптопроекта, с которым я недавно работал — и я успокоился.

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

Всё выглядело привычно и по делу. И вот сегодня наконец состоялось интервью.

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

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

Но тут он добавил:

“Чтобы тебе было проще, просто расшарь экран — я покажу тебе, куда нажимать и как всё быстро пройти.”

В этот момент у меня внутри сработал звоночек. Я вспомнил, что недавно читал про мошенничество через Zoom, и говорю: “Извини, но я бы не хотел делиться экраном — слышал, что бывают скам-сценарии через Zoom, и хотел бы сначала убедиться, что всё безопасно.”

Он ответил, что понимает мои опасения, добавил, что “сам в крипте уже 10 лет”, и похвалил мою бдительность. Затем предложил перенести вторую часть на завтра и использовать другой сервис — например, Google Meet.

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

Мы согласовали время и он тут же отключился... А спустя несколько минут я заметил, что вся переписка в Telegram была удалена. Даже жалобу не успел отправить. Вот так вот.

Что это было

Это был очень хорошо продуманный скам. И он бы сработал, если бы буквально вчера я не прочитал, что мошенники могут получить удалённый доступ через Zoom. Никаких “переведите деньги” или “установите программу” — всё выглядело на 100% натурально.

Что бы он сделал, если бы я расшарил экран — я, к счастью, так и не узнал. Но подозреваю, что мог попросить установить какое-нибудь “удобное приложение” или, пока я отойду“за каким-нибудь документом”, сам бы успел что-то скачать. Вариантов масса.

Выводы

Будьте осторожны! Не бойтесь быть подозрительным, задавать вопросы, просить подтверждение личности — например, через LinkedIn или корпоративный сайт. А ещё лучше — проходите онлайн-интервью на отдельном устройстве, где нет кошельков, логинов и приватной информации.

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

Пусть об этих схемах знают как можно больше людей. Берегите себя. И будьте бдительны.

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки - шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS - есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз - для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

Так что, вместо возни с автоматическим перевыпуском суперкоротких сертификатов, центральный сервис может выдавать квитанции доступа на каждую TLS-сессию. Естественно, TLS-сертифкат сервера должен быть предъявлен раньше, чем отправлено сообщение с подписью CertificateVerify. Однако эти сообщения в TLS передаются сервером одной серией, поэтому, в процессе создания TLS-сессии, сервер сможет сразу же получить от центрального узла и сгенерированный только что сертификат, и соответствующую подпись, собрать это всё вместе и отправить клиенту.

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify - TLS-сессия браузером установлена не будет.

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

Добавили сервис управления приватными сетями в облаке Рег.ру

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

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

Передача данных в приватных сетях осуществляется по высокоскоростным оптическим каналам доступа. По умолчанию для пользователей доступна скорость до 1Гбит/с, ограничение внешнего канала до 350 Мбит/с.

Сквозные сценарии и новый портрет клиента: ключевые ИТ-тренды глазами техподдержки

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

Ниже — несколько ключевых инсайтов, которые отражают реальные изменения в поведении бизнеса, от руководителя дирекции технологических сервисов МойОфис Василия Уварова. А полную версию можно прочесть в свежей колонке Василия для TAdviser по этой ссылке.

Технологическое развитие важнее функционального

Все больше клиентов, особенно те, кто использует серверные продукты, обращают внимание не только на функциональное развитие решений, когда увеличивается количество фичей и новых «кнопочек», но и на технологическое — то есть на стабильность, надежность и безопасность работы ПО. Для них важна высокая скорость работы, устойчивость системы к сбоям, возможность обработки больших объемов данных, защита от потенциальных угроз, а также быстрое копирование и восстановление после инцидентов. Поэтому в текущем году приоритетными направлениями разработки стали повышение производительности и обеспечение отказоустойчивости наших решений. Так, благодаря оптимизации кода и архитектуры мы ускорили работу в веб-редакторах в разных сценариях от 2 до 10 раз. Например, открытие табличного документа выполняется в 4 раза быстрее, а скорость форматирования текста и изменения размера столбца увеличилась в 6 раз.

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

Поддержка комплексных инфраструктурных сценариев

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

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

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

Пишут, что CA/B-форум согласовал дальнейшее сокращение интервала валидности TLS-сертификатов: теперь планируют к 2029 году уменьшить этот интервал до 47 дней. Ожидаемо. Я бы предположил, что ещё короче сделают (да и, фактически, раньше; например, Let's Encrypt уже готовит шестидневные сертификаты).

Тенденция коснётся и сертификатов, выпускаемых "собственными УЦ": если браузер принципиально не верит сертификатам только на основании длительности их интервала валидности, то не играет роли, был ли добавлен корневой ключ УЦ вручную или приехал в составе дистрибутива. (Технически, да, урезать действие ограничения для "домашних" сертификатов можно, но вряд ли имеет смысл на это рассчитывать.) Кроме того, строго автоматический выпуск сертификатов - требует наличия подходящего API на стороне УЦ, тоже немаловажный технологический фактор.

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