Astracloud.ru

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

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

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

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

Например, вам нужно добавить файл с результатами 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

Облачная платформа Astra Cloud и разработчик систем управления веб-проектами и корпоративных порталов «1С-Битрикс» объявляют о подписании меморандума о стратегическом сотрудничестве. Соглашение скрепили подписями Александр Воеводин, директор по работе с ключевыми клиентами «1С-Битрикс», и Константин Анисимов, директор Astra Cloud.

Партнерство направлено на создание решений в области облачных технологий и искусственного интеллекта. Ключевым совместным продуктом станет интегрированный программный комплекс, объединяющий облачную платформу Astra Cloud и сертифицированную версию решения от «1С-Битрикс».

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

Общие правила деловой переписки
Переписку обычно ведут по e-mail и в корпоративных мессенджерах, реже — в Telegram или в WhatsApp. У каждого из каналов коммуникаций есть свои особенности. Например, в электронной почте принято указывать тему письма и писать строго по делу, а в групповых чатах — отмечать тегами людей, которым адресовано сообщение.

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

В книге «Новые правила деловой переписки» Максим Ильяхов и Людмила Сарычева обозначили главные принципы письменных коммуникаций в коллективе. Эти принципы применимы как к письмам, так и к сообщениям:

Быть уважительным к собеседнику, заботиться о его времени;

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

Плохой пример


Нет темы письма, приветствия и четкого объяснения задачи. Две темы соединены в одно письмо

Хороший пример



Две задачи — два письма. У каждого из них есть своя тема, информация представлена в полном объеме и вежливой форме

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

Привет, СРОЧНО нужен пост про нашу победу на конкурсе, сделай сегодня. Дима.

Или такое:

Привет! В среду команда нашего агентства заняла первое место на конкурсе N. Нужно рассказать об этом нашим подписчикам. Подготовь, пожалуйста, пост для Telegram к 8.06, опубликуем 11.06. К письму приложил ссылки на сайт конкурса, проект, с которым мы победили, а также примеры предыдущих постов про наши победы. Если будут вопросы, пиши мне сразу в Телеграм, так будет быстрее.

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

Есть три основных правила, соблюдение которых необходимо для эффективной переписки. Расскажем о них подробнее.

Делать мысль понятной для собеседника
Главная задача деловой переписки — донести мысль так, чтобы собеседник понял ее правильно. В вашем письме не должно быть:

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

Попробуйте поставить себя на место собеседника. Например, вы пишете коллеге: «На странице не хватает CTA». Если сообщение адресовано маркетологу, он поймет, что вы говорите про call to action — призыв к действию. Но если письмо получит начинающий дизайнер, который никогда не сталкивался с этим термином, он потратит время на выяснение значения слова и поиск примеров.

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

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

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

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

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

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

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

• Укажите тему. Часто сотрудникам приходится искать нужное письмо среди сотен других. Если известна тема, найти его будет проще. Тема обязательно должна отражать суть сообщения. Хороший пример: «Презентация ко Дню студента-2025». Плохой: «Презентация».
• Настройте подпись. В любом почтовом клиенте можно создать и настроить свою подпись — текст, который автоматически добавляется к каждому сообщению. В ней укажите вашу должность, имя и фамилию и контакты для связи. Например, электронную почту, номер телефона, ник в Telegram.
• Следуйте классической структуре. Стандартное письмо содержит тему, приветствие, основной текст, вопрос или призыв, подпись.

Плохой пример

Без темы, без подписи, без уважения

Хороший пример

С темой, подписью и уважением

Отвечать на письма принято в течение 1-2 дней. Если затягиваете с ответом, вы проявляете неуважение к собеседнику и можете замедлять бизнес-процессы.

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

Кстати, RuPost не даст вам забыть обозначить тему письма и выдаст отдельное напоминание перед отправкой.


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

Для этого нужно:

• Создать событие на конкретную дату в корпоративном календаре или CRM, которую используют в компании.
• Обозначить тему и основные вопросы обсуждения.
• Выбрать время и добавить всех участников.

Встречи принято назначать не позднее, чем за сутки до проведения. Всех участников нужно оповестить письменно — отправить приглашения на почту или в мессенджер.

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

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

Плохой пример


Нет четких итогов встречи: не понятно что конкретно нужно сделать, кто и за что отвечает, какой крайний срок

Хороший пример


С чувством, с толком, с расстановкой задач и ответственных лиц

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

Книги о правилах деловой переписки
Узнать больше о правилах делового общения в переписке помогут книги:

• «Новые правила деловой переписки», Максим Ильяхов и Людмила Сарычева.
• «Переписка 2.0. Как решать вопросы в чатах, соцсетях и письмах», Саша Карепина.
• «Проще говоря. Как писать деловые письма, проводить презентации, общаться с коллегами и клиентами», Салливан Джей.

Знание цифрового этикета — навык, который упрощает коммуникации с сотрудниками и клиентами, повышает эффективность переговоров и влияет на бизнес-процессы. Если в компании соблюдают правила деловой переписки, это формирует положительный имидж, повышает доверие клиентов и укрепляет HR-бренд.

Работайте в RuPost в облаке Astra Cloud
Быстрый старт, простое масштабирование, удобный интерфейс, высокий уровень безопасности для крупного и малого бизнеса или работы в госсекторе astracloud.ru/mail

ВТБ полностью отказался от использования американской операционной системы Microsoft Windows и перешел на российскую платформу Astra Linux. Как сообщил заместитель главы банка Вадим Кулик, для группы ВТБ у российского вендора было приобретено свыше 110 тысяч лицензий российской платформы.

Переход на отечественную операционную систему с привычной и широко распространенной зарубежной среды MS Windows, с ее обширной экосистемой приложений и интеграцией большого числа самых распространенных инструментов, стал одним из самых масштабных проектов импортозамещения в банке. Для работы наших сотрудников мы приобрели у ГК «Астра» свыше 110 тысяч лицензий отечественного решения

сообщил Вадим Кулик.

По его словам, в ходе реализации проекта важно было обеспечить полноценную работу всех информационных систем, используемых сотрудниками банка. Приоритетное внимание уделяли не только адаптации и настройке необходимых систем, но и всесторонней подготовке как IТ-специалистов, так и конечных пользователей. Для этого в ВТБ организовали специализированные программы обучения по работе с Astra Linux и настройку инфраструктуры.

Проект перевода сотрудников ВТБ на российскую ОС Astra Linux продолжался полтора года. Проект реализован без остановки бизнес-процессов и с сохранением работоспособности почти 1200 информационных систем, работающих в банке.

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

Согласно прогнозу Gartner, к 2025 году до 99% проблем с безопасностью данных в облачных сервисах будет возникать по вине пользователей. Хотя немало случаев, когда в сбоях виноваты провайдеры. Чтобы избежать недопонимания и выполнить свою часть работ по обеспечению безопасности данных, важно разобраться в основных принципах разделения ответственности в облачных сервисах.

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

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

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

Также в зоне ответственности клиента находятся:

• Маркировка и классификация данных в соответствии с законодательством;
• контроль прав доступа к данным;
• использование внутренних сетей (VPN);
• резервное копирование данных (при выборе модели IaaS);
• управление собственными приложениями на облачной платформе, включая защиту кода (при выборе моделей IaaS и PaaS).

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

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

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

Разные модели облака — разная ответственность
Во многом разделение ответственности зависит от того, какой моделью облака вы пользуетесь: IaaS, PaaS или SaaS.

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

Ответственность провайдера:

• Исправная работа физических серверов и облачной платформы виртуализации;
• защита инфраструктуры от уязвимостей;
• безопасность хранилища и оборудования.

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

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

В ответственность провайдера входит все то же, что и при IaaS, а также:

• Проведение мониторинга;
• обновление антивируса;
• проверка учетных записей пользователей на соответствие требованиям безопасности.

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

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

Ответственность провайдера включает все то же, что и при PaaS, а также:

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

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

Серая зона ответственности
Четко разграничить зоны ответственности между провайдером и клиентом не всегда возможно. Это приводит к появлению «серых зон», которые могут вызывать разногласия.

Споры случаются в следующих вопросах:

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

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

Выводы

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

В России 58,6% компаний используют удаленный формат работы. Это удобно, эффективно и сокращает расходы на обслуживание офиса. Но «удаленка» имеет серьезный недостаток — проблемы с информационной безопасностью.

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

Что такое VDI
VDI (Virtual Desktop Infrastructure) — это технология виртуализации рабочих мест. Операционная система и все данные хранятся не на компьютере пользователя, а на сервере в дата-центре. Сотрудник может подключиться к своему виртуальному рабочему месту из любой точки мира и любого устройства.

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

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

Termidesk VDI — сервис организации удаленных рабочих мест от «Группы Астра». Работает на локальном оборудовании и через облачную платформу Astra Cloud. Termidesk VDI позволяет централизованно управлять виртуальными рабочими местами, гибко настраивать систему и обеспечивает полную безопасность данных. Узнайте больше о продукте и закажите бесплатную демонстрацию.

Как работает VDI


Сотрудники подключаются к VDI через браузер или специальную программу на своем устройстве. Для пользователей виртуальное рабочее место не отличается от обычного. При подключении они заходят в операционную систему — например, Linux, Astra Linux или Windows — и запускают привычные программы.

Управляет удаленными рабочими местами администратор. На команду до 15 000 сотрудников достаточного одного-двух администраторов.

При создании нового удаленного стола администратору не нужно заново устанавливать ПО. У VDI-решений существует «золотой образ» — шаблон рабочего места со всеми необходимыми программами. Достаточно скопировать его на новый виртуальный стол, и рабочее место будет готово к использованию.

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

Termidesk VDI обеспечивает высокий уровень безопасности данных: можно управлять пользовательскими сессиями и настраивать параметры доступа к рабочим местам в соответствии с политикой безопасности компании. Узнайте больше о Termidesk VDI в облаке Astra Cloud и закажите бесплатную демонстрацию.

Преимущества VDI
VDI — не единственная технология, которая помогает организовать работу дистанционных сотрудников, но у нее есть несколько важных преимуществ для бизнеса:

• Централизованное управление. Всеми данными, операционными системами и приложениями пользователей управляет администратор через единую систему. Это легко и удобно — например, обновить ПО или установить новое приложение можно одновременно на всех рабочих местах.
• Безопасность и гибкие настройки доступа. Рабочие места подключенных сотрудников находятся под контролем. VDI позволяет ограничивать доступ к определенным приложениям и данным в зависимости от роли пользователя — так, у руководителя отдела и младшего сотрудника могут быть разные права. А если работник выполняет подозрительные действия, то доступ к VDI на его устройстве блокируется автоматически.
• Масштабируемость. VDI легко масштабировать в зависимости от потребностей бизнеса. Компания может быстро добавить новые виртуальные рабочие столы, если расширит штат или переведет действующих сотрудников на удаленный формат работы.
• Упрощенное резервное копирование и восстановление данных. Поскольку все данные хранятся на сервере, процесс резервного копирования и восстановления становится проще и быстрее. Это помогает минимизировать риски потери данных в случае сбоя или атаки.

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

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

Технология подойдет:

• Дистанционным командам, например, студиям разработки. Сотрудники могут подключаться к виртуальным рабочим местам с собственных компьютеров и работать под контролем администратора, даже если живут в разных городах и странах.
• Компаниям, сотрудники которых часто ездят в командировки. Во время поездки работник сможет легко подключиться к рабочему месту и воспользоваться необходимыми программами.
• Командам дизайнеров, архитекторов, проектировщиков. Через VDI сотрудники смогут пользоваться профессиональным ПО, для которого необходимы значительные вычислительные мощности.

VDI-решения применяют и компании с офисным режимом работы. Это удобно, если сотруднику нужно поработать из дома, или если одно рабочее место используют сразу несколько человек.

Termidesk VDI в облаке Astra Cloud
Termidesk VDI можно установить на локальном оборудовании в закрытом контуре компании или работать через облачную платформу Astra Cloud. При работе через облако Astra Cloud вы экономите на покупке, модернизации и администрировании серверного оборудования — все заботы мы берем на себя. А еще сможете получать экспертную поддержку по облаку и по продукту через единое окно.

Кроме того, в облаке Astra Cloud вы можете:

• Работать с серверами на GPU;
• интегрироваться с BIM-решениями;
• организовать через Termidesk полноценное рабочее место для специалиста Data Science и работать с САПР.

Запросите демонстрацию решения и оцените возможности Termidesk VDI в облаке Astra Cloud.
astracloud.ru/desktop