Рады сообщить: мы прокачали наше мобильное приложение и запустили обновленную кроссплатформенную версию приложения, которое дублирует панель управления на сайте. Таким образом, в вашем телефоне будет полноценная панель управления Beget. Расскажем немного подробнее. Теперь в приложении доступен полный функционал веб-версии панели, включая работу с облачными решениями и SSH-терминалом, а благодаря этому обновлению все функции, которые появятся в десктопной версии панели управления, будут моментально доступны и в мобильной. В приложении доступны: вся функциональность виртуального хостинга: FTP-аккаунты, сайты, бэкапы, SSH-терминал и прочие разделы;вся функциональность облака: облачные серверы, облачные БД, S3-хранилище;пополнение баланса;мониторинг;регистрация доменов;поддержка мультиаккаунтов;документооборот для юрлиц.Создавайте серверы, регистрируйте и продлевайте домены и запускайте новые проекты буквально за несколько секунд – с мобильным приложением Beget. Обновить приложение можно уже сейчас – прямо в Google Play и App Store. play.google.com/store/apps/details?id=com.beget.mobileapp&hl=ru apps.apple.com/ru/app/beget-%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%D0%BD%D0%B0%D1%80%D0%BE%D0%B4%D0%BD%D1%8B%D0%B9-%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3/id1293772395...
Компания Hivelocity объявила о продаже своих услуг колокейшн в Чикаго и Майами компании Digital Realty, крупнейшему мировому поставщику облачных и нейтральных платформ для центров обработки данных. Этот стратегический шаг подтверждает приверженность Hivelocity инновациям, масштабируемости и успеху клиентов, а также расширяет сотрудничество с Digital Realty. Джереми Пиз, генеральный директор Hivelocity Digital Realty идеально подходит для приобретения этих активов и имеет все возможности для создания дополнительной ценности для наших клиентов в этих местах. Мы уверены, что их опыт в сочетании с нашим подтвержденным опытом работы на этих объектах обеспечит неизменно высокое качество обслуживания Наличие у Digital Realty производственных мощностей и опыт управления глобальными центрами обработки данных гарантируют клиентам бесперебойное предоставление услуг. Hivelocity планирует продолжить расширение услуг колокейшн на основных объектах и расширить возможности хостинга в США и за рубежом, опираясь на успешный опыт использования сети Digital Realty. Компания продолжит предоставлять решения для физических серверов, корпоративного облака и виртуальных серверов на площадках в Майами и Чикаго. Фарамарз Махдави, вице-президент по ИТ-инфраструктуре и операциям в Digital Realty Наша главная задача — обеспечить плавный переход и предоставить клиентам доступ к PlatformDIGITAL, глобальной платформе Digital Realty, инновационным решениям и передовой в отрасли надежности. Это приобретение ещё больше укрепляет наши позиции как надёжного глобального партнёра, расширяя наши сервисные возможности и предложение колокейшн в двух наших существующих центрах обработки данных. Клиенты продолжат получать бесперебойное обслуживание по мере постепенного подключения к MarketplacePORTAL, нашей глобальной платформе доступа к клиентам Поскольку Hivelocity продолжает развивать сотрудничество с Digital Realty, Valterra Partners продолжает играть важную роль, поддерживая как стратегический рост, так и партнерства, стимулирующие инновации на мировых рынках. Кевин Рид, управляющий директор Valterra Partners Мы гордимся тем, что смогли предоставить нашим инвесторам успешный результат, продав эти активы. Эта сделка отражает эффективность нашей инвестиционной стратегии и ценность, которую мы продолжаем создавать в сотрудничестве с лидерами отрасли, такими как Digital Realty Сотрудничество Hivelocity и Digital Reality способствует развитию гибких гибридных решений, безопасной эксплуатации центров обработки данных и непрерывной цифровой трансформации для клиентов по всему миру. Поскольку предприятия всё чаще ищут поддержку гибридных ИТ-сред, это партнёрство нацелено на предоставление оптимизированных решений по всему миру. www.hivelocity.net/data-centers/...
Корпоративное облако — удобное и доступное место для хранения файлов. Сотрудники могут получать доступ к нужным документам из любой точки мира, а компании не нужны собственные дата-центры и дорогое оборудование. Но если в организации большое количество данных, поиск необходимого файла может превратиться в блуждание по цифровым лабиринтам. Рассказываем, как избежать хаоса в облачном хранилище, как организовать в нем логичную структуру и как сделать облако удобным для всех в команде. Логичная структура папок и файлов Одна из причин цифрового хаоса — отсутствие структуры в облачном хранилище данных. Сотрудники создают папки с понятными только для них самих названиями и добавляют туда файлы из разных категорий. Они привыкают к такой системе и легко ориентируются в хранилище. Но когда прежние работники уходят, новым специалистам приходится тратить много времени, чтобы найти документы. Задача руководителей — внедрить логичную структуру хранения. Она может отличаться в зависимости от компании, но в ее основе должна быть иерархия из трех-четырех уровней. Например, вам нужно добавить файл с результатами A/B-теста нового продукта. Вот так может выглядеть структура: Продуктовое направление → Тестирование новых продуктов → А/B-тесты → 2025 год Помните, что иерархия не должна быть слишком длинной — если в ней более пяти уровней, может вновь возникнуть путаница. Единые правила именования файлов Если в компании следуют единым правилам именования в облаке для хранения файлов, находить нужные документы будет проще. Скорее всего, вы намного быстрее отыщете таблицу с названием «Отчет_по_РК_Директ_ апрель_2024_Иванов», чем «Отчет реклама». Основные принципы грамотного именования файлов следующие: Название отражает суть документа;название максимально полное, его легко найти по ключевым словам в поиске облака;в названии нет ошибок, опечаток, посторонних символов;при необходимости — указаны даты и ответственные лица. 
Борьба с дублированием и файловыми свалками Еще одна причина хаоса в корпоративном облаке — дублирование файлов. Сотрудники несколько раз сохраняют один и тот же документ в разные папки, тем самым создавая копии. Это засоряет облачное пространство и занимает лишнюю память. Из-за постоянного дублирования и отсутствия организации хранения файлов возникают свалки документов. Их можно сравнить со шкафом, в котором хранится сразу все: от инвентаря для дачи до старых квитанций, детских игрушек и зимних курток. Например, необходимый отчет может находиться среди дизайн-макетов, таблиц отдела продаж и текстовых документов. Найти нужный файл в таком хаосе очень сложно, при этом во время поиска приходится отвлекаться на посторонние документы. Выход — внедрить правила обращения с облаком, провести инструктаж для сотрудников и назначить ответственного, который будет следить за хранилищем. Настройка прав доступа для сотрудников и защита данных Навести порядок в облаке поможет и создание разных уровней доступа. Например, рядовые сотрудники смогут пользоваться только теми папками, которые необходимы им для работы. Дизайнер не сможет просмотреть файлы IT-отдела, маркетолог — открыть документы для топ-менеджмента. Ограничение прав доступа также необходимо для защиты чувствительных данных, таких как финансовая отчетность или персональная информация о сотрудниках. Настроить уровни доступа легко — так, в Astra Disk можно установить пароль или ограничить срок действия ссылки, по которой открывается файл. В Astra Disk также можно создать группы пользователей с разными возможностями доступа, настроить автоматическую блокировку аккаунтов бывших сотрудников, ввести аутентификацию через локальные учетные записи. Это помогает максимально защитить данные от утечек и взломов. astracloud.ru/disk Чек-лист для проверки порядка в облаке Проверьте по этому чек-листу, есть ли порядок в вашем корпоративном облаке: Файлы размещены в папках со строгой структурой.Названия документов понятные, оформлены по единым правилам.Найти любой документ в облаке можно за пару минут по ключевым словам.Отсутствуют дубли: один документ — один файл.Настроены уровни доступа, сотрудники пользуются только теми файлами, которые нужны им в работе.А если вы пока еще не подключили корпоративное облако, попробуйте Astra Disk для хранения файлов — безопасное российское решение, которое подходит для импортозамещения иностранного ПО и работы с большими объемами данных...
Привет, меня зовут Кирилл и я архитектор облачной платформы Astra Cloud. Это первая статья из цикла, в которой я расскажу о предпосылках появления собственной облачной платформы в продуктовом портфеле «Группы Астра». Почему мы начали делать своё облако в 2022 году Весна 2022 года стала переломным моментом для российской ИТ‑отрасли: уход западных вендоров ограничил продажи оборудования и ПО, доступ к публичным облакам, SLA, обновления и техподдержку. Многие российские компании оказались отрезаны от критически важных цифровых сервисов буквально за считанные дни. Стало очевидно: нельзя полагаться на инфраструктуру, неподконтрольную ни технически, ни юридически. Поддержка через «альтернативные каналы» (третьи страны и оффшорные юрлица) не обеспечивает стабильности, юридической чистоты и соответствия требованиям регуляторов. Эти условия стали основой для создания Astra Cloud — отечественной, готовой к использованию в критически важных сегментах ИТ‑инфраструктуры облачной платформы. Облачные услуги в России в 2022: сегментация и ориентиры Прежде чем начинать что‑то делать — и уж тем более создавать свою облачную платформу — неплохо было понять, что уже есть на рынке, а также какие достоинства и недостатки есть у наиболее популярных решений. Проведённый нами анализ показал, что отечественный рынок облачных решений в 2022 году можно было условно разделить на две основные группы: Облачные сервисы (IaaS) — часто основаны на устаревших технологиях, с трудом масштабируются и не предоставляют должного уровня изоляции и возможности доработки.Системы виртуализации — ориентированы на администрирование виртуальных машин, но не решают задачи учёта использования ресурсов, мультитенантности — то есть изоляции ресурсов и настроек между независимыми группами пользователей (арендаторами) в рамках одной инсталляции, автоматизации или самообслуживания.
Нельзя сказать, что отечественный рынок не предлагал и зрелых решений, но, как показали опросы заказчиков, этим решениям не хватало тех или иных функций, которые позволили бы их использовать в защищённых решениях. Мы видели растущий спрос на комплексную платформу, способную не просто запускать ВМ, но и предоставлять полноценный облачный сервис с API, ролями доступа, учётом потребления и возможностью гибкой с различными сетевыми технологиями и партнёрскими решениями. Мы не стремились конкурировать со стандартными решениями для простого хостинга BM, а сосредоточились на построении облака по тем критериям, которые выдвигали наши заказчики. Важно отметить, что ожидания заказчиков различались кардинально. Кто‑то требовал максимальной изоляции и соблюдения нормативов, другим нужна была простота, автоматизация, REST API, биллинг. Третьи ставили акцент на удобство администрирования или интеграцию с внешними IDM‑системами. Были и довольно экзотические запросы, такие как использование ОС реального времени, возможность гео‑тегирования дисков и наличие графического инсталлятора для всех компонентов облака в режиме «далее‑далее‑далее». Эта разнородность требований (ФТ, НФТ, SLA, мультитенантность, производительность, политики безопасности и так далее) требовала от платформы гибкости архитектуры и возможности интеграции со сторонними решениями. Забегая вперёд, отметим, что абсолютно все запросы заказчиков мы не смогли выполнить по ряду причин. Но об этом чуть позже. Анализ популярных технологий: OpenStack, oVirt Перед нами стоял сложный выбор технологического ядра облачной платформы, и мы честно рассмотрели все популярные решения. Мы не были привязаны к какому‑либо вендору или архитектуре, что давало свободу анализа и возможность взвешенного выбора. На первом этапе основное внимание было уделено двум решениям — OpenStack и oVirt, как довольно распространённым в корпоративных средах и ЦОД. OpenStack: неплохо, но очень дорого. OpenStack — это мощная и чрезвычайно гибкая экосистема, ориентированная на построение облаков в масштабе дата‑центра. Её основное достоинство — модульность: можно собирать нужный функционал из десятков компонентов (Nova, Neutron, Glance, Keystone, Cinder, Horizon и других). Это позволяет реализовать сложные сценарии, включая федеративную аутентификацию, программно‑определяемые сети, интеграцию с системами распределённого хранения (например, Ceph) и другими подсистемами. Однако на практике модульность OpenStack — это и её главный недостаток. Развёртывание требует скоординированной настройки десятков сервисов, каждое обновление несёт в себе риски несовместимости. Для поддержки OpenStack необходима отдельная DevOps‑команда с компетенциями по Kubernetes, Ansible, Ceph, и множеству других технологий. Его эксплуатация может оказаться чрезмерно ресурсоёмкой даже для крупных организаций, если нет готовности инвестировать в процессы сопровождения, а ИТ‑команды решают другие, более актуальные задачи. По сути, OpenStack — это не «установил и работает», а долгосрочный инженерный проект, как на этапе разработки облачной платформы, так и на этапах внедрения и сопровождения. Ещё один важный аспект — совместимость с российским стеком программного обеспечения и требованиями регулятора. OpenStack развивается в парадигме глобального облачного рынка не учитывая ограничений, присущих защищённым или изолированным инфраструктурам в российских реалиях. В российской практике это оборачивается рядом трудностей: отсутствие официальной поддержки отечественных ОС, несовместимость с сертифицированными модулями криптографической защиты, необходимость доработки интеграций со средствами криптографической защиты информации (СКЗИ), государственными информационными системами (ГИС) и прочими элементами, значимыми для защищённых сред. В частности, компоненты OpenStack, работающие с аутентификацией и хранилищами (Keystone, Cinder, Swift), требуют значительной адаптации под отечественные требования и могут вести себя нестабильно в условиях ограниченного доступа к внешним репозиториям. Для большинства частных облаков в России OpenStack слишком сложен и затратен. Его внедрение требует больших ресурсов, увеличивает сроки запуска и зависит от высококвалифицированной команды. И, как следствие, OpenStack оказывается не самым оптимальным выбором для проектов, где на первом плане стоят предсказуемость сопровождения и устойчивость к внешним ограничениям. oVirt: зрелая, но инертная технология oVirt (основанная на Red Hat Virtualization) — это решение с относительно простой архитектурой. Оно исторически развивалось как GUI‑ориентированная система управления виртуальными машинами, построенная вокруг QEMU/KVM и VDSM ‑отдельного демона‑агента, который отвечает за управление виртуальными машинами, сетями и хранилищами на каждом гипервизоре. Преимущество oVirt — в быстром развёртывании и достаточно стабильной работе на малых и средних масштабах. Однако у oVirt есть серьёзные ограничения. Архитектура платформы не рассчитана на построение мультиарендных облаков. Отсутствует полноценная поддержка мультитенантности, нет встроенных механизмов биллинга, а сценарии самообслуживания требуют отдельной доработки. Кроме того, развитие проекта в последние годы замедлилось, и его перспектива остаётся туманной. После прекращения развития Red Hat Virtualization и слияния ряда компонент с oVirt, сообщество стало меньше, а частота релизов — ниже. В экосистеме oVirt нет нативной поддержки множества популярных российских сертифицированных решений. Это означает, что при использовании oVirt в проектах с требованиями по регуляторному соответствию (ФСТЭК, ФСБ) заказчику придётся самостоятельно адаптировать компоненты, проводить дополнительные проверки, а также решать вопросы совместимости на уровне ядра и пользовательского пространства. В отличие от решений, включённых в реестр ЕРПОС и прошедших процедуру сертификации, oVirt не обеспечивает «из коробки» соответствие требованиям защищённых ИТ‑сред и нормативных актов РФ. Также отсутствует развитый API и гибкая система шаблонов, что делает платформу мало пригодной для построения облака как сервиса. Несмотря на ряд положительных качеств (простота, зрелость, стабильность), мы сочли oVirt неподходящим для реализации современных требований к изоляции, автоматизации и управляемости. Итак, в 2022 году перед нами стоял открытый выбор технологического ядра, и мы, рассмотрев популярные решения, пришли к следующему выводу: OpenStack — мощная платформа, но чрезвычайно сложная в установке, конфигурации и сопровождении. Её архитектура перегружена микросервисами, а эксплуатация требует команды с высоким уровнем DevOps‑компетенций. Для частного облака с ограниченными ресурсами это часто становится неподъёмной нагрузкой. Кроме того, OpenStack требует особых подходов к совместимости с отечественным ПО и ОС.oVirt + QEMU — решение более простое, но явно устаревшее. Развитие идёт медленно, документации немного. Поддержка мультитенантности в современном понимании в системе отсутствует. Кроме того, экосистема oVirt плохо масштабируется и практически не имеет встроенных механизмов биллинга или автоматизации. Сложно интегрировать в CI/CD или управлять через REST API. OpenNebula и ПК СВ «Брест» 
Мы уже были готовы пойти по самому сложному пути — использованию в качестве ядра облачной платформы OpenStack. Проработали сценарии развёртывания, разработали верхнеуровневаую архитектуру и даже провели тесты, но с каждым днём нам становилось всё более очевидно, что использование OpenStack приведёт к значительным накладным расходам, высокой зависимости от DevOps‑команды и другим потенциальным проблемам. Именно в этот момент мы обратили внимание на OpenNebula — платформа, которая с самого начала создавалась как лёгкое облачное решение с минимальным порогом вхождения. В её основе лежат проверенные временем компоненты: libvirt, KVM, REST API и XML‑RPC. Как показала практика, она довольно легко интегрируется с различными сетевыми решениями и СХД, предоставляет встроенные механизмы оркестрации и имеет простой, но функциональный пользовательский интерфейс. OpenNebula поддерживает мультитенантность, биллинг (увы, зачастую недостаточный, но об этом чуть позже), управление через Web‑интерфейс и API, шаблоны развёртывания и резервное копирование — всё это делает её если и не готовой облачной платформой, то уж точно её возможной основой. Особым преимуществом стало наличие сертифицированной редакции OpenNebula в сборке ПК СВ «Брест», которая не только основана на оригинальной OpenNebula, но и существенно доработана для интеграции со средствами защиты информации (СЗИ), встроенными в Astra Linux. В частности, в неё включены механизмы взаимодействия с мандатным разграничением доступа (МРД) и контролем целостности (МКЦ), что делает её пригодной для эксплуатации в средах с повышенными требованиями к безопасности. Это решение уже использовалось как система виртуализации у наших заказчиков. Мы понимали, что на этой базе можно построить полноценное частное облако — быстро, надёжно и с возможностью интеграции всех необходимых компонентов. Почему ПК СВ «Брест» как есть — недостаточно Несмотря на свои плюсы, ПК СВ «Брест» — это, по сути, платформа виртуализации «на стероидах». Чтобы стать полноценным облаком, ей не хватало ряда критически важных функций, необходимых не только администраторам, но и обычным пользователям. Среди них: Полноценный и удобный портал самообслуживания, позволяющий пользователю без участия ИТ‑службы запускать, останавливать, клонировать и настраивать свои виртуальные машины.Встроенный каталог шаблонов и приложений, содержащий типовые решения, востребованные российскими заказчиками (например, СУБД, СЭД, VPN).Интеграция со службой каталогов пользователей, обеспечивающая единую точку входа и авторизацию через корпоративные учётные записи.Встроенная система резервного копирования, позволяющая защищать пользовательские данные и выполнять восстановление по запросу.Централизованная система тарификации, выставления счетов и отчётности, обеспечивающая прозрачный учёт потреблённых ресурсов и справедливое распределение затрат между подразделениями.Единый инсталлятор, ускоряющий развёртывание платформы.И, что особенно важно по обратной связи от заказчиков, — поддержка всех компонентов облака в режиме «одного окна», включая техническую поддержку, обновления, документацию и сопровождение. Почему мы выбрали OpenNebula (ПК СВ «Брест») Итак, ПК СВ «Брест» стала для нас логичным выбором. Она соответствовала сразу нескольким ключевым критериям: Совместимость с Astra Linux и сертифицированное исполнение.Использование проверенных технологий (libvirt, KVM).Простая и надёжная архитектура.Поддержка HA‑кластера через RAFT.Возможность интеграции с ALD Pro (служба каталогов), API BILLmanager (единый портал для пользователей и биллинг), а также СРК RuBackup.Возможность предоставления «единого окна» технической поддержки.Регистрация в ЕРПОС и соответствие требованиям импортозамещения.Мультитенантность — изоляции ресурсов и настроек между независимыми группами пользователей (арендаторами) в рамках одной инсталляции.
Мультитенантность заслуживает особого внимания: для защищённых ИТ‑систем и крупных холдингов принципиально важно строгое разграничение ресурсов, учёт потребления по подразделениям и юридическим лицам, ведение журналов действий и возможность выставления счетов. Без этого невозможно построить ни безопасное облако, ни управляемую инфраструктуру для нескольких арендаторов. Программный и программно‑аппаратный подходы Чтобы учесть специфику разных заказчиков, мы предусмотрели две модели поставки: Программный комплекс (ПК) — единый и неделимый набор компонентов, составляющих облачную платформу, инсталлятор, позволяющий установить все компоненты ОП Astra Cloud в air‑gapped режиме (без доступа в Internet) и документация. Этот вариант идеально подходит для компаний с собственной ИТ инфраструктурой.Программно‑аппаратный комплекс (ПАК) — это полностью собранное и преднастроенное решение, включающее стойки, серверы, сетевое оборудование, системы хранения данных и весь набор программного обеспечения, идентичный используемому в программном комплексе. Более того, в состав ПАК входит дополнительный компонент — DCImanager: платформа для централизованного управления физической мультивендорной ИТ‑инфраструктурой. Она особенно полезна в дата‑центрах, серверных комнатах и организациях с распределённой или локальной инфраструктурой, позволяя автоматизировать учёт, мониторинг и управление оборудованием.Заказчик получает готовую к работе платформу, которая разворачивается за считанные часы. Оба варианта основаны на одном программном стеке и предоставляют одинаковый уровень безопасности и надёжности. Отличия — только в удобстве запуска, автоматизации и инфраструктурных компонентах. Итоговый набор компонентов. От минимума, до продуктивного решения После серии пилотных проектов, функционального тестирования и анализа эксплуатационных характеристик различных решений, мы сформировали стабильный и сбалансированный состав компонентов, который лёг в основу архитектуры платформы Astra Cloud. Этот набор был подобран с учётом совместимости, надёжности, соответствия нормативным требованиям и обратной связи от пилотных заказчиков. 
Базовые компоненты платформы Astra Cloud: Операционная Система Специального Назначения Astra Linux SE — сертифицированная ОС, обеспечивающая соответствие требованиям ФСТЭК и ФСБ, включающая встроенные СЗИ (МРД, МКЦ).Программный комплекс средств виртуализации «Брест» — доработанная сборка OpenNebula, адаптированная для работы с Astra Linux и защищёнными инфраструктурами.Программный комплекс для централизованного администрирования и службы каталогов ALD Pro — реализация FreeIPA с поддержкой Kerberos, LDAP и RBAC.Система резервного копирования RuBackup — решение для централизованного управления резервными копиями виртуальных машин, поддерживающее хранение в распределённых хранилищах, репликацию между ЦОДами и восстановление по расписанию или по запросу. Обеспечивает надёжность и отказоустойчивость как в локальных, так и в мульти‑ЦОД инфраструктурах.ПО для мониторинга компонентов платформы Astra Monitoring — сбор метрик, алерты, дашборды и контроль доступности.ПО для биллинга и автоматизации предоставления ресурсов BILLmanager — тарификация, учёт, выставление счетов, API для интеграции с «1С Бухгалетрия», а также полноценный портал самообслуживания, через который пользователи получают доступ ко всем функциям платформы из единой консоли.ПО «Магазин приложений» — интерфейс и система шаблонов для добавления собственных сервисов и предустановленных решений (VPN, базы данных, VDI).ПО «Справочный центр» — интегрированная документация и навигация по архитектуре и операциям в платформе. Этот состав компонентов может быть дополнен или адаптирован под конкретные требования проекта. При необходимости реализуются интеграции с системами управления доступом (IDM, Identity Management), системами управления событиями информационной безопасности (SIEM, Security Information and Event Management), средствами криптографической защиты информации (СКЗИ). Также поддерживается взаимодействие с системами управления конфигурациями и активами (CMDB, Configuration Management Database) и другими корпоративными ИТ‑системами. В этой статье мы рассмотрели историю возникновения и предпосылки создания облачной платформы, подробно остановились на выборе архитектурного ядра, а также рассмотрели альтернативные решения, от которых пришлось отказаться. В следующих частях мы разберём архитектуру платформы, её внутренние компоненты и принципы взаимодействия, поговорим про безопасность, и масштабируемость платформы. astracloud.ru...
Крупному бизнесу хотят запретить пользоваться иностранными облачными сервисами. Ограничения предлагает ввести Минцифры к сентябрю 2027 года. Об этом сообщают «Ведомости» со ссылкой на письмо главы ведомства Максута Шадаева, которое он направил министру промышленности и торговли Антону Алиханову. В документе речь идет о запрете на пользование корпоративными сервисам из-за рубежа в информационных системах хранения и обработки персональных данных. Работа крупных российских корпораций на зарубежных облачных платформах «вызывает особую озабоченность», приводит издание слова Шадаева. Опасения Минцифры связаны в том числе с развитием технологий искусственного интеллекта в иностранных облачных сервисах, считает заместитель генерального директора Astra Cloud Константин Анисимов: Большинство IT-систем устроено таким образом, что какая-то часть кода все равно находится в облаках. Это связано прежде всего с искусственным интеллектом. Например, даже если мы работаем в Microsoft World, и какие-то функции связаны искусственным интеллектом, все это берется из облаков. Законопроект направлен именно на такие истории, чтобы ограничить передачу данных российских пользователей во внешние хранилища в гибридных системах. Как работают ИИ-помощники? Они встраиваются в ваши коммуникации, а это почта, видеосвязь, мессенджеры. У нас на почте, в видеоконференциях, мессенджерах огромное количество внутрикорпоративной информации. Российские решения есть буквально в каждом сегменте. Никакой проблемы нет. Тем более достаточно грамотное решение, что эта мера вводится не сразу, то есть не с 1 сентября 2025 года, а дается еще два года на то, чтобы проработать все решения и постепенно ввести astracloud.ru...
«Группа Астра» совместно с Yadro строит полностью отечественную альтернативу западным облачным платформам. Новая инфраструктура объединяет серверы, СХД и сетевые решения российского производства, делая ключевые сервисы «Группы Астра» доступными для бизнеса и госструктур без необходимости разворачивать собственные мощности. Astra Cloud продолжает развитие своей облачной инфраструктуру, делая ставку на российские технологии. Ключевым партнером по серверному оборудованию выступает технологическая компания Yadro. В основе масштабируемой инфраструктуры Astra Cloud – передовые серверы, системы хранения данных и сетевые решения Yadro. Продукты «Группы Астра», включая почтовый сервер RuPost, корпоративное файловое хранилище Astra Disk, платформа виртуализации рабочих мест Termidesk и другие сервисы становятся более доступными на инфраструктуре Astra Cloud, без необходимости строить и разворачивать собственные мощности. Такой подход позволит российским компаниям любых масштабов быстрее переходить на современные цифровые безопасные сервисы. В архитектуре инфраструктуры Astra Cloud задействованы высокопроизводительные серверы Vegman R220 G2, системы хранения данных корпоративного уровня Tatlin.Unified GEN2, а также сетевые коммутаторы Kornfeld, разработанные и произведенные компанией Yadro. Проект включает развертывание 300 серверов Vegman, двух СХД и 38 коммутаторов с последующим масштабированием инфраструктуры до тысяч серверов в ближайшие годы по мере развития сервиса. Последующие этапы расширения проекта предусматривают возможное использование дополнительного объема аппаратных решений Yadro. В частности планируется тестирование сценариев использования Tatlin.Object (объектное хранилище с поддержкой протоколов S3, HTTP(S), gRPC) и Tatlin.Backup (специализированная СХД резервных копий). Первый этап проекта должен быть реализован в III квартале 2025 г. Сервис-провайдер Astra Cloud ориентирован как на бизнес, так и на государственный сегмент и гарантирует соответствие регуляторным требованиям. Astra Cloud делает упор на развертывание изолированной и аттестованной моделей — в зависимости от потребностей заказчиков, включая возможность создания выделенных инсталляций. Новый этап сотрудничества со стратегическим партнером укрепляет фундамент технологической независимости и создает прочную основу для предоставления программных решений «Группы Астра» по подписочной модели — в полностью отечественном облаке. Мы строим облако, где все под контролем — от уровня оборудования до уровня операционной системы и сервисов. В связке с Yadro мы предлагаем рынку надежную, безопасную и полностью российскую альтернативу западным платформамсказал Константин Анисимов, генеральный директор компании «Астра Облако». Для нас этот проект — логичное продолжение стратегического партнерства с «Группой Астра». Вместе мы создаем рынок, на котором заказчики могут быть уверены: все, от оборудования до ПО и сервисов, разрабатывается и поддерживается в России. Такой подход позволяет клиентам строить как локальные инфраструктуры, так и надежные облачные сервисы на единой технологической базе, сохраняя высокий уровень производительности и безопасностисказал Александр Бакулин, коммерческий директор компании Yadro...
Алексей Боровиков, технический архитектор в Astra Cloud, специально для CISO Club рассказал о базовых принципах миграции в облако с учетом минимизации рисков и соблюдения всех актуальных стандартов. Алексей разобрал основные этапы миграции, а также рассказал, как можно противостоять перехвату данных, бороться с ошибками конфигурации безопасности и несовместимостью некоторого ПО с российскими стандартами. 
Российский бизнес в последние годы переживает сложный процесс цифровой трансформации. Ужесточение регуляторных требований и снижение внутренних расходов на ИТ подталкивают все больше компаний к переносу виртуальной инфраструктуры в российские облачные решения. Однако такой переход требует не только технической подготовки, но и строгого соблюдения норм информационной безопасности. В данной статье Алексей Боровиков, технический архитектор в Astra Cloud (входит в «Группу Астра»), рассмотрит базовые принципы организации процесса миграции в облако с учетом минимизации рисков и соблюдения всех актуальных стандартов. Риски при миграции ИТ-инфраструктуры При переносе ИТ-инфраструктуры в российские облака компаниям важно внимательно отнестись к вопросам информационной безопасности (ИБ). Вот ключевые риски, с которыми может столкнуться бизнес: Риск перехвата данных во время миграции. В качестве решения можно использовать шифрование (TLS, VPN) и защищенные каналы связи.Ошибки конфигурации безопасности: неправильные настройки брандмауэров, прав доступа, резервного копирования. Для решения можно применять принцип least privilege и автоматизировать развертывание (IaC — Terraform, Ansible).Несовместимость с российскими стандартами. Зарубежное ПО может не поддерживать ГОСТ-шифрование или требования ФСТЭК, поэтому лучше перейти на отечественное сертифицированное ПО. Чтобы минимизировать эти и другие возможные риски, рекомендуем придерживаться простых правил: Обязательно проводить пилотное тестирование, то есть проверять безопасность на некритичных сервисах.Выполнять фазированный перенос, то есть разбить миграцию на несколько этапов с мониторингом на каждом шаге.Не пренебрегать документированием, то есть фиксировать все изменения и инциденты для дальнейшего тщательного анализа.Отдельно стоит отметить значительную пользу фазированного переноса в снижении рисков ИБ. Разбивка всего процесса на этапы позволяет контролировать весь процесс и вовремя реагировать на инциденты. Конечно, дорожная карта миграции будет уникальна для каждой отдельной компании. Однако можно выделить основные этапы, которые так или иначе будут присутствовать в каждом случае со своими отдельными дополнениями. Ключевые этапы миграции в облако Любая миграция в своей основе состоит из следующих этапов: анализа и планирования, собственно миграции данных и сервисов, дальнейшей поддержки. Давайте разберем каждый из них подробнее. Анализ и планирование: основа успешной миграции Прежде чем приступать к каким-либо техническим изменениям, необходимо провести всесторонний аудит текущего состояния инфраструктуры и сформировать четкий план действий. На этом этапе важно учитывать не только технологические аспекты, но и нормативно-правовые требования, которые могут существенно повлиять на выбор облачного провайдера и архитектуры будущего решения. Один из ключевых моментов – определение требований информационной безопасности. Даже если компания уже работает в соответствии с определенными стандартами, важно еще раз провести детальную сверку с российскими нормативными актами (152-ФЗ «О персональных данных» и Приказами ФСТЭК №17, №21, №239, которые регулируют вопросы защиты информации). Далее, в зависимости от отрасли, могут применяться дополнительные требования. Например, со стороны Центрального банка для финансовых организаций или со стороны Роскомнадзора для операторов персональных данных. Параллельно с этим проводится оценка текущей ИТ-инфраструктуры: важно проанализировать используемые сервисы, технологии, требования к производительности и отказоустойчивости. Особое внимание нужно уделить критически важным приложениям и данным, поскольку их миграция требует наиболее тщательной проработки. Следующий шаг – выбор облачного провайдера. В российских реалиях публичное облако зачастую не подходит для размещения чувствительных данных, поэтому предпочтение лучше отдать частным облачным решениям. Так, например, в Astra Cloud, помимо стандартного публичного облака, есть решение off-premise – это полностью частная инсталляция компании, но на оборудовании и территории сервис-провайдера. Такой подход позволяет защитить чувствительные данные, выполнить регуляторные требования и снизить расходы на создание собственной физической инфраструктуры. Завершающая часть этапа планирования – разработка детальной дорожной карты миграции. Необходимо прописывать сроки, порядок переноса сервисов, распределение ресурсов и меры по минимизации рисков. Отдельное внимание стоит уделить плану отката — порядку действий на случай, если процесс пойдет не по запланированному сценарию. Миграция: от тестирования до полного перехода После завершения подготовительных работ наступает этап переноса данных и сервисов. Однако прежде чем запускать полномасштабную миграцию, рекомендуем провести пилотное тестирование на отдельных приложениях. Это позволит выявить потенциальные проблемы, проверить настройки безопасности и оценить производительность системы в новых условиях. Если тестовая фаза завершена успешно, можно приступать к основному переносу. Важно обеспечить непрерывность бизнес-процессов, поэтому миграция часто проводится поэтапно, с минимальным временем простоя. Особое внимание стоит уделить целостности и доступности данных — любая ошибка на этом этапе может привести к серьезным последствиям. После завершения переноса рекомендуем провести комплексное тестирование, которое включает проверку на соответствие требованиям ИБ, оценку производительности и отказоустойчивости. При необходимости внесите корректировки в конфигурацию системы. Поддержка: обеспечение стабильности и безопасности Миграция — это не конечная точка, а лишь начало работы в новой среде. Чтобы гарантировать долгосрочную стабильность и безопасность, необходимо организовать постоянный мониторинг инфраструктуры для своевременного выявления и устранения потенциальных угроз. Еще одним важным аспектом является обучение персонала. Даже самая совершенная система не будет эффективной, если сотрудники не знают, как с ней работать. Поэтому тренинги и инструктажи — обязательная часть постмиграционного процесса. Обучение можно проводить в формате видеоуроков, а также предоставления доступа к различным гайдам, инструкциям и чек-листам. Программу каждого тренинга можно разбить на условно базовый уровень – для всех сотрудников, и на обучение техническим аспектам – для ИТ-отдела. В программу базового уровня обязательно нужно включить блок о безопасности, где рассказать о новых политиках доступа, работе с двухфакторной аутентификацией и правилах распознавания фишинга. Сотрудникам ИТ-отделов следует рассказать об управлении инцидентами в облаке, настройке систем мониторинга и особенностях резервного копирования в облачной среде. В качестве проверки усвоения знаний, можно использовать различные тесты или даже симуляции инцидентов. Важно проводить такие тренинги регулярно, хотя бы раз в квартал, чтобы освежать знания в памяти сотрудников и обновлять программу. Главное о миграции в облако Миграция сервисов в облако – сложный, но вполне реализуемый проект. Ключ к успеху – тщательное планирование, пошаговый подход и постоянный контроль на всех этапах. Если подытожить, то можно выделить следующие ключевые точки миграции: Анализ регуляторных требований: общих и с учетом сферы деятельности компании.Оценка текущего состояния инфраструктуры и сервисов с особым вниманием к критически важным приложениям и данным.Разработка плана миграции: порядок переноса и сроки, распределение ресурсов и сценарий отката.Пилотное тестирование на некритичных сервисах, а уже потом – полноценная, но поэтапная миграция.Комплексное тестирование работы систем и сервисов после переноса, в том числе с оценкой соответствия требованиям ИБ.Внедрение системы мониторинга и обучения сотрудников.Соблюдение этих фундаментальных принципов позволит минимизировать возможные риски и создать надежную ИТ-инфраструктуру, соответствующую даже самым строгим стандартам безопасности. astracloud.ru...
Благодаря обновлению Ceph, в нашем сервисе снова можно настраивать для S3 списки управления доступом для бакетов и объектов. ACL настраиваются в любых программах управления хранилищем, например, Cуberduck, S3 Browser, S3cmd и других. Также для управления доступом можно использовать политики (Policy), которые дают значительно больше возможностей. https://lk.clo.ru Промокод CLO1041223...
Если к началу сентября вы забыли не только, какие задачи решали перед отпуском, но и как зовут коллег, значит, ваш отдых удался! Чем не повод для отличного настроения? А пока осталось немного времени на раскачку, предлагаем вместе с нами потихоньку готовиться к продуктивной осени и освежить в памяти «пройденный материал». 
Чтобы было полегче, начнём с повторения простых определений, к примеру, что такое GitLab. Затем пройдёмся по «списку литературы» из блога на Хабре и приступим к изучению самого интересного — обновлений и фич. Всё по классике. Что такое GitLab, как и для чего он используется Удобно, когда всё, что нужно для разработки, собрано в одном месте — на единой платформе. Примером такой среды является GitLab. В статье разберём, чем GitLab отличается от GitHub и как начать с ним работу. Отдельно остановимся на его AL-возможностях. firstvds.ru/blog/chto-takoe-gitlab-kak-i-dlya-chego-ispolzuetsya Что такое VPS и VDS, зачем он нужен и как выбрать Споры о том, можно ли VDS приравнивать к VPS, кажется поутихли, но не исчезли совсем. В статье даём базу для тех, кто только вступает на путь изучения сферы хостинга — от принципа работы виртуального сервера до критериев выбора под свой проект. firstvds.ru/technology/whatisvdsvps Habr: самое интересное за август Если хочется размять мозги с пользой и удовольствием, ловите идеальное расписание. Сперва история странного самолёта-амфибии и технологии с разбором влияния ИИ. Дальше труд и практика — слушаем эфир с помощью SDR-радиоприёмника. Ну, и куда же без геометрии… правда, совсем не такой, к которой мы привыкли. Самый странный самолет в истории: Советский ВВА-14ИИ ускоряет работу, но замедляет проект?Этот увлекательный мир радиоприёмниковНовая геометрия для теории относительности Эйнштейна Ищем авторов для блога на Хабр Подготовьте статью на одну из специальных тем или отправьте материал на тему месяца. И если ваша статья подойдёт для блога, вы получите повышенный гонорар. Тема сентября: Информационная безопасность. firstvds.ru/avtoram 
Новости августа Изменения в S3 Мanager: полностью обновлённый дизайн и новые опции 
Наш S3-менеджер стал еще удобнее. Представляем большое обновление, которое делает работу с хранилищем прозрачнее и безопаснее. Вот что нового: Проще и понятнее. Полностью обновили дизайн панели — оптимизировали меню, улучшили графики отображения занятого места и многое другое. Меньше багов. Исправлена ошибка с выводом недостоверных данных о количестве объектов и занятом объёме памяти. Больше опций. Добавили: уведомления о действиях над объектами (копирование, удаление, перемещение) — в начале и конце каждого процесса;предупреждение о прерывании операции — если вы решите закрыть вкладку браузера или обновить страницу во время копирования, удаления или переноса файлов;возможность указывать права доступа (приватный/публичный) при создании бакета и просматривать его статус приватности после;возможность создавать папки прямо в процессе копирования.firstvds.ru/services/s3 Тарифы «Форсаж» и «Атлант» на новых процессорах AMD EPYC 9655 
Наши тарифы «Форсаж» (в Москве и Амстердаме, с NVMe) и «Атлант» стали ещё производительнее. Теперь серверы будут открываться не только на AMD EPYC 9654, но и на новом серверном процессоре AMD EPYC 9655 с 96 ядрами и частотой до 4,5 ГГц. И самое главное: примерно до середины сентября все новые серверы на этих тарифах будут запускаться только на EPYC 9655. В дальнейшем — в произвольном порядке. Так что если хотите гарантированно получить новый VDS на свежем процессоре, самое время переходить к выбору конфигурации. firstvds.ru/blog/novye-processory-amd-epyc-9655-v-tarifakh-forsazh-i-atlant Запустили новый способ оплаты услуг зарубежными картами 
Буквально на днях мы запустили новый способ оплаты — иностранной банковской картой. Теперь вы можете оплачивать наши услуги и пополнять баланс картами Visa, Mastercard и другими, выпущенными в Казахстане, Кыргызстане, Узбекистане, Таджикистане, Туркменистане, Азербайджане, Грузии и Армении. Для этого в способах оплаты в Личном кабинете или на сайте нужно выбрать вариант «Иностранная банковская карта». После подтверждения данных система перенаправит вас на сайт платёжной системы, где вы сможете завершить процесс оплаты. firstvds.ru/blog/2025_foreign_cards Топ новостей из мира безопасности 
И напоследок. Собрали для вас небольшое саммари о главных уязвимостях и инцидентах конца лета, которые нельзя пропускать — от критических дыр в WordPress и ядре Linux до хитрого фишинга, направленного на разработчиков. Кратко и по делу о том, что нужно срочно обновить и на что обратить внимание. Наследие xz Utils: десятки зараженных образов все ещё в Docker Hub Специалисты компании Binarly обнаружили, что в репозитории Docker Hub до сих пор доступны как минимум 35 контейнерных образов, зараженных через уязвимость CVE-2024-3094 (10 баллов по шкале CVSS) в утилитах xz Utils. Это создает серьезную угрозу для цепочек поставок (CI/CD), так как эти образы могут автоматически использоваться для сборки новых приложений, распространяя бэкдор дальше. Напомним, бэкдор, обнаруженный в 2024 году, позволял злоумышленнику обходить аутентификацию SSH и выполнять команды с правами root. Особое внимание исследователей привлекла позиция разработчиков Debian, которые сознательно не стали удалять свои зараженные образы, назвав их «историческими артефактами» и сославшись на низкую вероятность эксплуатации. Эксперты Binarly раскритиковали этот подход, указав, что даже случайное использование таких образов несет высокий риск. Специалисты рекомендуют работать только с актуальными образами. А кроме того, имеет смысл проверять не только версии ПО, но и двоичные файлы на наличие угроз, поскольку вредоносный код может годами оставаться в экосистеме. xakep.ru/2025/08/13/docker-hub-xz-utils/ В выпуске nginx 1.29.1 закрыта уязвимость и анонсирован встроенный ACME-клиент Команда nginx выпустила обновление для основной ветки разработки — версию 1.29.1. Самое важное для безопасности — устранение уязвимости CVE-2025-53859 в модуле ngx_mail_smtp_module. Ошибка позволяла при использовании аутентификации «none» и специально сформированных логина с паролем вычитать данные из памяти за пределами буфера, что могло привести к утечке чувствительной информации в процессе аутентификации. Помимо исправлений, выпуск примечателен двумя вещами: Улучшения безопасности TLS: по умолчанию отключено сжатие сертификатов в TLSv1.3 (потенциально опасная функция) и добавлена директива ssl_certificate_compression для гибкого управления этой настройкой.Развитие современного стека: добавлена поддержка режима 0-RTT для QUIC (ускоряет установление соединения) и внесён ряд исправлений для HTTP/2, HTTP/3 и ранних подсказок (HTTP 103).Отдельный сюрприз — компания F5 анонсировала экспериментальный модуль ngx_http_acme, написанный на Rust. Модуль позволяет автоматически получать и обновлять TLS-сертификаты от Let's Encrypt или других ACMEv2-совместимых центров прямо из конфигурации nginx, избавляя администраторов от необходимости использовать внешние клиенты. www.opennet.ru/opennews/art.shtml?num=63725 Новая уязвимость MadeYouReset в HTTP/2 угрожает масштабными DoS-атаками Исследователи представили новую технику атаки на реализации протокола HTTP/2 — MadeYouReset. Уязвимость позволяет злоумышленнику легко обходить ограничения на количество одновременных подключений и инициировать мощные атаки на отказ в обслуживании (DoS). Атакующий отправляет большое количество корректных запросов, но сразу после этого с помощью специальной последовательности управляющих кадров заставляет сервер самостоятельно сбросить эти потоки. Это ключевое отличие от известной уязвимости Rapid Reset (CVE-2023-44487), где сброс инициировал клиент. Здесь же сервер, уже начав обработку запроса (что потребляет CPU и память), вынужден его аварийно завершать. Это позволяет злоумышленнику генерировать лавину запросов без ожидания ответов, максимально нагружая сервер и потенциально выводя его из строя. Проблема затрагивает множество популярных реализаций, включая: Веб-серверы и фреймворки: Apache Tomcat, Eclipse Jetty, Netty, Lighttpd, h2o.Прокси и кэширующее ПО: Fastly, Varnish, Pingora.Другое: Сервисы Mozilla, BIND (через DNS-over-HTTPS), Zephyr RTOS.Проверка показала, что такие проекты, как Apache httpd, Apache Traffic Server, Node.js, LiteSpeed, Hyper и HAProxy не подвержены данной уязвимости. Статус nginx пока уточняется. Рекомендация проста: следить за выходом обновлений. www.opennet.ru/opennews/art.shtml?num=63726 Критические уязвимости в tar-fs и 7-Zip позволяют атаковать файловую систему Обнаружены критические уязвимости в популярных инструментах для работы с архивами, которые позволяют злоумышленнику записывать файлы в произвольные места файловой системы при распаковке специально сформированного архива. CVE-2025-48387 в npm-пакете tar-fs. Пакет, который еженедельно скачивают 23 миллиона раз, содержал ошибку, позволяющую обойти проверки символических ссылок. Атакующий мог создать архив, в котором с помощью цепочки ссылок путь раскрывался за пределы целевой папки распаковки. Это открывало возможность для перезаписи критически важных файлов (например, .bashrc или SSH-ключей) в домашней директории пользователя, что ведет к полной компроментации системы. Уязвимость уже исправлена в выпусках 3.0.9, 2.1.3 и 1.16.5.CVE-2025-55188 в архиваторе 7-Zip. Похожая проблема была найдена в знаменитом архиваторе 7-Zip. Она позволяла использовать симлинки с последовательностью “../” в пути для обхода ограничений целевого каталога. Уязвимость затрагивала обработку всех основных форматов архивов (ZIP, TAR, 7z, RAR) и была устранена в версии 25.01.Обе уязвимости демонстрируют, что даже доверенное ПО может стать инструментом для атаки на файловую систему, и подчеркивают необходимость всегда использовать последние версии программ. www.opennet.ru/opennews/art.shtml?num=63740 За последние две недели в мире технологий произошло несколько важных событий: от критических уязвимостей до экспериментов с ИИ и новых российских разработок. Сперва коротко о самом интересном: ИИ помог перевести старое Linux-приложение с GTK2 на GTK4 и Vulkan — разработчик из Red Hat за 5 часов модернизировал 20-летний код с помощью AI-ассистента. С одной стороны эксперимент показал, как ИИ может ускорить ускорить модернизацию legacy-кода, с другой — что такой ассистент все еще требует тщательного контроля со стороны разработчика из-за некорректной интерпретации задач.В России появился аналог Grafana — «Графиня» — новая платформа для визуализации данных, полностью написанная с нуля. Разработка «Лаборатории числитель» не использует код Grafana, поддерживает интеграцию с Zabbix, Prometheus и другими системами и уже зарегистрирована в реестре Минцифры России.Роскомнадзор заблокировал SpeedTest — сервис измерения скорости интернета признан угрозой безопасности, вместо него предлагают использовать российские аналоги.А теперь — подробнее о свежих киберугрозах. Уязвимость в Post SMTP угрожает 200 000 сайтов на WordPress Более 200 000 сайтов на WordPress подвержены атакам из-за уязвимости в плагине Post SMTP. Ошибка позволяет злоумышленникам получать доступ к администраторским аккаунтам. Post SMTP — популярный почтовый плагин с 400 000+ активных установок. В мае 2025 года исследователь обнаружил баг (CVE-2025-24000, 8.8 по CVSS) в механизме контроля доступа REST API. Плагин проверял авторизацию пользователя, но не его уровень прав. Как следствие, любые пользователи, не имеющие расширенных прав (например, подписчики), могут просматривать логи писем, включая конфиденциальные данные. А злоумышленники имеют возможность инициировать сброс пароля администратора, перехватить письмо и получить контроль над сайтом. Разработчик выпустил патч в версии 3.3.0 (11 июня 2025), но только 48,5% пользователей обновились. Около 24% до сих пор используют устаревшие версии 2.x, подверженные и другим уязвимостям. Рекомендуется срочно обновить Post SMTP до актуальной версии. xakep.ru/2025/07/28/post-smtp/ Фишинг-атака на разработчиков PyPI: злоумышленники имитируют официальные уведомления Администраторы PyPI (Python Package Index) предупредили о новой фишинг-атаке, направленной на владельцев Python-пакетов. Злоумышленники рассылали письма с поддельного домена pypj.org (вместо pypi.org), предлагая подтвердить email. Как это работало. Письма приходили с адреса noreply@pypj.org и содержали ссылку на фейковую страницу верификации. Сайт-клон повторял дизайн официального PyPI, чтобы обмануть невнимательных пользователей. В результате атаки злоумышленники получили доступ к аккаунтам разработчиков, создали два токена для API. А кроме того, выпустили вредоносные версии популярного пакета num2words (3+ млн загрузок в месяц), который конвертирует числа в слова. Рекомендации: внимательно проверять домен в письмах и ссылках и использовать двухфакторную аутентификацию для защиты аккаунтов. www.opennet.ru/opennews/art.shtml?num=63647 Критическая уязвимость в SUSE Manager: удалённое выполнение команд с root-правами Обнаружена опасная уязвимость (CVE-2025-46811, 9.3/10 по CVSS) в SUSE Manager — системе управления Linux-инфраструктурой. Она позволяет выполнять любые команды с правами root без аутентификации на всех подключённых системах. Проблема в обработчике WebSocket (/rhn/websocket/minion/remote-commands), который не проверяет авторизацию. Атакующий может отправить запрос на 443 порт сервера SUSE Manager без SessionId и получить полный контроль над инфраструктурой. Уязвимы все сборки SUSE Manager до версий 4.3.16, 5.0.5, включая образы SLES15-SP4-Manager-Server и контейнеры. Необходимо срочно обновиться до исправленных версий: SUSE Manager 4.3.16 и SUSE Manager 5.0.5. Угроза крайне критична, так как позволяет злоумышленникам захватить управление всей корпоративной инфраструктурой. www.opennet.ru/opennews/art.shtml?num=63651 Уязвимость в ядре Linux угрожает безопасности Chrome Google обнаружил критическую уязвимость (CVE-2025-38236) в ядре Linux, позволяющую злоумышленникам обойти песочницу (sandbox) Chrome и выполнить произвольный код с правами ядра. Проблема затрагивает ядра Linux версий 6.9 и выше.Ошибка связана с флагом MSG_OOB в UNIX-сокетах (AF_UNIX), который позволяет передавать внеполосные данные. Несмотря на то, что этот флаг редко используется, его некорректная обработка в ядре приводит к use-after-free уязвимости. Как это влияет на Chrome? В Chrome разрешены операции с UNIX-сокетами, включая send()/recv() с флагом MSG_OOB. Уязвимость позволяет преодолеть изоляцию песочницы, если злоумышленник уже эксплуатирует другую ошибку в браузере. Рекомендуется обновить ядро Linux до одной из исправленных версий и ограничить использование MSG_OOB, если он не требуется в системе.Исправление включено в обновления 6.1.143, 6.6.96, 6.12.36, 6.15.5. В сети уже появился рабочий прототип эксплоита. Уязвимость особо опасна для серверов и рабочих станций, где Chrome используется для обработки ненадёжного контента. www.opennet.ru/opennews/art.shtml?num=63710...
Приглашаем вас на Tech Support Conf — первую в России практическую конференцию для специалистов технической поддержки и клиентского сервиса. 
...