Речь пойдет о графических процессорах (GPU) NVIDIA для дата-центров — а именно о серверных ускорителях архитектур Hopper (H100, H200) и Blackwell (B200, B300). Такие ускорители используют для обучения больших языковых моделей (LLM), запуска инференса, научных вычислений и других ресурсоемких ИИ-задач. Вопрос выбора между поколениями актуален для тех, кто строит или модернизирует инфраструктуру: провайдеров облачных услуг, ИИ-лабораторий, крупных корпоративных центров разработки.

Каждый раз, когда NVIDIA выпускает новое поколение ускорителей, в профессиональных чатах начинается один и тот же ритуал. Кто-то спрашивает: «Брать B300 или еще хватит H200?» — и почти сразу получает в ответ табличку: вот память, вот терафлопсы, вот пропускная способность, новое — значит лучше. Спор вроде бы решен, но на самом деле только начинается.

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

Дальше разберем две ключевые вещи, которые в Hopper и Blackwell реально меняют расклад: память и новый формат вычислений FP4.

Сразу важное уточнение про вычислительную мощность. H200 бывает как в одиночном исполнении, так и в конфигурации из восьми GPU. А вот B300 поставляется только в виде готовой ноды с восемью ускорителями. Это серверные решения за десятки миллионов рублей, которые потребляют 12–14 киловатт и размещаются в дата-центрах. Для большинства задач, особенно для профессиональной графики на рабочей станции, такие мощности избыточны. Но начать стоит именно с тяжелых конфигураций, чтобы было понятно, от чего вы отказываетесь и почему вообще идет этот разговор.

Память — это главное, но не всегда так, как кажется

С видеопамятью история обманчиво простая: модель либо помещается целиком, либо нет. Вот тут и начинается самое интересное. У H100 было 80 гигабайт, и для многих больших языковых моделей этого уже не хватало. Например, популярная Llama 70B в полной 16-битной точности весит около 140 гигабайт — на одну H100 она просто не влезает, приходится ставить две карты и делить модель между ними.

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

А теперь про новинку. У B200 памяти уже 180 гигабайт, а у флагманского B300 — все 288.

Кстати, про скорость памяти забывать тоже не стоит. Когда нейросеть генерирует текст, она не столько считает, сколько перегоняет гигантские объемы данных из памяти в вычислительные блоки. У H200 пропускная способность почти на 40% выше, чем у H100 — и это на том же самом чипе. Поэтому даже те, кому 141 гигабайт не нужен, часто берут H200 именно ради скорости.

FP4 — то, из-за чего все спорят

Если пропускная способность памяти — это про скорость, то новый формат вычислений FP4 — это про будущее. Раньше все работали в 8-битном или 16-битном формате. Чем меньше бит, тем меньше памяти нужно и тем быстрее всё работает, но падает точность. Инженеры научились сжимать модели так, что потеря качества почти незаметна, и вот теперь в Blackwell появилась аппаратная поддержка 4-битных вычислений.

У Hopper такой поддержки нет. Да, формально он может работать с FP4, но делать это будет медленнее, чем с FP8 — потому что нет специальных аппаратных блоков. А в Blackwell эти блоки есть, и они дают реальный прирост скорости на самых тяжелых операциях — матричных умножениях, на которых построены все современные трансформеры.

Но тут есть важный нюанс. Это не магия, которая ускорит любую модель сама по себе. Разработчик должен вручную разметить в коде, какие участки считать в FP4, а какие оставить в старых форматах. И для этого нужно, чтобы ваша модель была подготовлена — либо скачана в специальном формате NVFP4, либо сконвертирована самостоятельно. Не все популярные инструменты это умеют: например, в ollama с FP4 пока проблемы, а вот в более продвинутом vLLM — уже работает. Так что если вы привыкли запускать модели одной командой в терминале, с новым форматом придется немного повозиться.

И главный вывод: если вы не собираетесь реально использовать FP4, а планируете работать в привычных FP8 или FP16, то переплачивать за Blackwell просто бессмысленно. Вы получите дорогую карту, которая будет работать как Hopper.

Выводы: что выбрать

Выбор сводится к трем простым сценариям.

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

Второй: вы работаете в 3D-графике или VFX и иногда экспериментируете с нейросетями, но не строите дата-центр. Тогда ваш выбор — RTX PRO 6000. Это современная архитектура, большой объем памяти и отличная производительность в профессиональном софте.

Третий: вы еще не решили, насколько серьезно будете нагружать карту, или проект только стартует. Тогда разумнее взять ресурсы в аренду, проверить гипотезы, а когда загрузка станет стабильной и высокой — задуматься о покупке своего железа.

Новое поколение всегда кажется лучшим, но в реальности оно дает выигрыш только тем, кто использует новые фичи. Если ваш стек живет в старых форматах — спокойно берите Hopper и работайте. Если готовы переходить на FP4 — Blackwell ждет.

Теперь облачной базе данных можно выдать бесплатный публичный IPv6-адрес.

Полезно, если:

1️⃣ Уже раскатали IPv6 в своей инфраструктуре и не хотите держать IPv4 только ради базы

2️⃣ Масштабируете проект и постепенно уходите от дефицитных IPv4-адресов

3️⃣ Строите cloud-native или корпоративную инфраструктуру, где важна поддержка IPv6.

Подключается в пару кликов: при создании новой базы или в настройках существующей «Сеть» → «Публичный IPv6-адрес». Если переключателя IPv6 у базы нет — значит, на вашей сети он пока недоступен.

При защищенном TLS-подключении адрес автоматически привяжется к техническому домену базы. Остальные детали в документации →

Фича появилась не случайно — ее давно просили в разделе идей (тут и тут), теперь она в проде.

Привязать айпишник к базе →

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

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

Мы придумали, как эту проблему решить, и запустили 2 этап программы бесплатного доступа к облачным серверам Рег.облака. Разбираем, как перевести сайт с классического хостинга в облачную инфраструктуру без начальных вложений и без жесткой привязки к конкретному специалисту на примере Free Tier 2 Рег.облака — бесплатного облачного сервера с предустановленной панелью управления ispmanager.

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

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

Коротко: кому это подойдет, а кому нет

Чтобы не разочароваться, лучше честно оценить задачу еще до старта. Бесплатный уровень доступа Free Tier — это легкий и стабильный фундамент, но у него есть свои границы. Важно понимать различия между этапами 1 и 2 Free Tier. Stage 1 — это базовый бесплатный облачный сервер. Он идеально подходит для пет-проектов, тестирования, учебных стендов и сред разработки. Stage 2 — это уже готовое решение для тех, кто хочет перенести сайты с хостинга в облако. Здесь к такому же серверу добавляется панель ispmanager.

Рассказываем, кому Free Tier подходит идеально, а кому лучше сразу присмотреться к платным конфигурациям.

Ваш случай, если:

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

Человек не хочет работать в консоли. Free Tier 2 идет с предустановленной панелью ispmanager — это веб-интерфейс, похожий на привычную программу. Всё управление сайтом, базами данных, почтой и файлами делается через браузер. Консоль может вообще не открываться после первичной настройки.

Вы хотите передать управление заказчику и забыть о сайте. Ваша роль заканчивается в момент, когда сервер запущен, а WordPress установлен. Дальше человек работает в панели сам. Вы не становитесь техподдержкой на годы вперед и не получаете звонков в десять вечера с вопросом «а как тут картинку поменять». Передали доступ к ispmanager — и забыли.

Не ваш случай, если:

Планируется тяжелая система управления контентом (CMS) с десятками плагинов. WordPress сам по себе довольно легкий. Но если вы намерены установить 20–30 активно работающих плагинов (конструкторы страниц, слайдеры, SEO-инструменты, кеширование, бэкапы, аналитика, формы) — нагрузка вырастет многократно. Система управления контентом с десятками дополнений на 1 ГБ оперативной памяти будет тормозить, а при всплеске посетителей — падать. Для таких проектов нужно минимум 2–4 ГБ.

Нужно несколько проектов на одном сервере. Free Tier дает один сервер с 1 ГБ памяти и 10 ГБ диска. Если вы планируете разместить на нем два, три или пять сайтов — ресурсы будут делиться между ними. При активной работе хотя бы одного проекта остальные могут начать испытывать нехватку ресурсов. Но и в этом случае конфигурацию Free Tier можно расширить один раз по заявке в техподдержку (до 2 vCPU / 2 ГБ RAM / 20 ГБ NVMe, не более двух параметров).

Шаг 0. Честно оценить, что нужно на самом деле

Вначале давайте посмотрим на цифры. Бесплатный сервер Рег.облака дает: 1 виртуальный процессор, 1 ГБ оперативной памяти и 10 ГБ под данные.

Сколько это в реальности? Сама операционная система занимает около 200 МБ. Остается примерно 800 МБ под всё остальное. На такой объем спокойно помещаются:

• Статический сайт — просто страница с картинками и текстом. Занимает буквально 10 МБ, летает, ломаться практически нечему.

• Один сайт на системе управления контентом (CMS) — например, витрина на WordPress с минимумом дополнений. Работает нормально, если не ждать миллиона посетителей.

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

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

Вывод по нашей задаче: сайту свечной мастерской достаточно либо статической страницы, либо легкой системы управления контентом (CMS). Далее по тексту будет рассматриваться витрина на WordPress, поскольку управлять сайтом должен обычный человек — добавлять новые изделия, изменять цены. Для этого нужна простая панель администрирования, а не редактирование файлов в текстовом редакторе.

Шаг 1. Получить сервер

Активация требует двух вещей: подтвердить личность и пополнить баланс на 100 рублей. Это не плата за сервер — сумма возвратная и остается на счету, потом ее можно потратить на другие услуги. Подтверждение личности нужно, потому что вы получаете настоящий сервер с реальным IP-адресом, а не просто страничку в конструкторе.

После этого выбираете площадку (дата-центр) — Москва-2 или Москва-3. Для одного сайта разницы нет: оба работают одинаково хорошо. Операционная система — Ubuntu 22.04 или 24.04. Берите 24.04, если нет причин оставаться на старой версии.

Шаг 2. Настроить подкачку (чтобы сервер не падал)

С одним гигабайтом оперативной памяти обязательно нужна подкачка (swap), то есть страховка от внезапного падения сервера, когда случается всплеск нагрузки. Он не заменяет оперативную память по скорости, но страхует от OOM-killer на пиках нагрузки: без него один тяжелый запрос к базе или всплеск трафика может остановить nginx или базу данных без предупреждения.

Настраивается парой команд в консоли. Дальше про это можно забыть.

Шаг 3. Разместить сайт и отдать управление ответственному лицу

Это самое важное. Бесплатный сервер идет с уже установленной панелью управления ispmanager. Вместо того чтобы вручную прописывать в консоли настройки веб-сервера, PHP и базы, вы получаете уже настроенную среду и интуитивно понятный интерфейс, который почти не отличается от того, к чему вы привыкли на хостинге.

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

• загружает фотографии свечей;

• добавляет и убирает товары;

• меняет цены;

• заводит почтовый ящик для заказов;

• при необходимости смотрит логи (кто заходил, не было ли ошибок).

Консоль вы открываете только один-два раза на старте — чтобы настроить подкачку и базу данных. После этого она не нужна вообще.

Шаг 4. Настроить базу данных под маленький сервер

WordPress работает с базой данных MySQL или MariaDB. Стандартные настройки рассчитаны на мощные серверы с запасом памяти, поэтому их нужно адаптировать.

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

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

Шаг 5. Знать пределы и правила расширения

Об этом лучше знать заранее, чтобы потом не было сюрпризов. Бесплатная конфигурация — 1 ГБ памяти и 10 ГБ диска. Если этого станет мало, можно попросить техподдержку расширить сервер бесплатно один раз:

• либо до 2 ГБ памяти и 20 ГБ диска;

• либо до 2 процессоров и 2 ГБ памяти (диск останется 10 ГБ).

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

Примерно 200 лет назад у каждого крупного производства была собственная паровая машина. Громоздкая, дорогая, требовавшая топлива, инженеров и постоянного ухода. Примерно 20 лет назад у многих компаний была своя серверная — со стойками, гулом кондиционеров и сисадмином, который знал, где лежит запасной блок питания.

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

И вот ирония: в России ЦОДам предложили строить собственные электростанции. Минцифры и Минэнерго разрабатывают схему, по которой дата-центры в столичном регионе в ближайшие 5–7 лет должны будут сами обеспечивать себя энергией. Получается, история идет по спирали. Сначала были свои паровые машины, потом — центральные электростанции и сети. А теперь крупные потребители снова вынуждены думать о собственной генерации. Давайте посмотрим, как это работало в промышленности — и как повторяется в технологиях.

До: паровые машины в промышленности и серверные комнаты в ИТ

Промышленность. Первые паровые машины появились еще в конце XVII века, но по-настоящему менять мир они начали после разработок Джеймса Уатта во второй половине XVIII века. Он сделал паровую машину в пять раз мощнее и приспособил ее для вращения станков и мельниц.

Это стало энергетической основой промышленной революции. Заводы больше не зависели от рек или ветра — их можно было строить где угодно. К 1810 году в одной только Англии работало около пяти тысяч паровых машин, а через 15 лет их число выросло втрое.

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

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

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

Масштабирование было возможным, но медленным и дорогим. Чем больше становился бизнес, тем больше ресурсов уходило на то, чтобы просто поддерживать железо в рабочем состоянии, а не на развитие.

После: централизованные электростанции и серверы в облаке

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

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

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

ИТ-сфера. В ИТ похожая революция произошла с появлением облачных сервисов. Amazon, Google, Microsoft первыми построили огромные центры обработки данных. Гораздо больше и эффективнее, чем любая серверная, которую большинство компаний могло бы создать самостоятельно.

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

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

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

Мировой рынок облачных услуг продолжает расти: по итогам 2025 года затраты на глобальном рынке облачных инфраструктур достигли $419 млрд. Компании переходят в облака, чтобы оптимизировать ИТ-расходы и быстрее запускать новые проекты. Особенно активно это происходит в сфере искусственного интеллекта, где потребность в вычислительных мощностях растет очень быстро.

Выводы

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

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

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

Сегодня рассмотрим ситуацию, в которой оказываются многие, когда переносят 1С:Документооборот в облако. Кажется: взял виртуальный сервер, поставил туда 1С — и всё работает. Но есть один нюанс, про который узнаешь либо от ИТ-специалиста, либо от проверяющих органов.

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

Тяжелая артиллерия: как не запутаться в 152, 242, 1119 и 21

Многие думают, что вопрос с персональными данными регулируется одним-единственным законом — 152-ФЗ. На самом деле это целая цепочка из нескольких документов, и проходить ее нужно последовательно. Вот как это выглядит на практике.

Шаг 1. 152-ФЗ — главный закон о персональных данных. Он определяет, кто такой оператор (то есть вы, если храните и обрабатываете ПДн), какие у вас обязанности и что будет за их несоблюдение. Без понимания этого документа остальные не имеют смысла.

Шаг 2. 242-ФЗ — поправка про локализацию. Согласно поправке, собирать, хранить и обрабатывать персональные данные граждан России нужно на серверах, которые физически находятся в России. Это как раз то, что закрывает обычный российский ЦОД. Но только это — и ничего больше.

Шаг 3. Постановление Правительства № 1119 — уровни защищенности. Здесь начинается самое интересное. Система с ПДн получает один из четырех уровней защищенности:

• УЗ-4 — низший (например, только ФИО и телефоны, небольшое количество людей);

• УЗ-3 — средний;

• УЗ-2 — высокий;

• УЗ-1 — высший (спецкатегории данных, большой объем, высокие риски).

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

Шаг 4. Приказ ФСТЭК № 21 — что конкретно делать. Под каждый уровень защищенности в этом приказе прописаны конкретные меры. Например, для УЗ-4 — одни требования, для УЗ-2 — другие: обязательное шифрование, сертифицированные средства защиты, отдельный контроль доступа и так далее.

Самое важное про порядок действий: нельзя пропустить ни один из шагов. Сначала вы определяете, какие данные у вас обрабатываются и где. Затем разрабатываете модель угроз — смотрите, что именно может пойти не так: кто и как может получить доступ, какие каналы утечки существуют. И только на основании трех вещей — типов персональных данных, актуальных угроз и количества субъектов — определяете и актом закрепляете уровень защищенности. Далее под этот уровень реализуете конкретные меры из приказа № 21.

Отдельно про аттестацию. Аттестация обязательна для ГИС (Государственная информационная система) и для тех систем, где это прямо установлено нормативно или условиями взаимодействия с государственной системой. Для обычной информационной системы персональных данных аттестация, как правило, не обязательна, а проводится добровольно или по специальному требованию.

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

Аттестованное облако — это готовый инфраструктурный слой, который уже прошел проверку. Вы платите — и вам не нужно самим всё это проектировать и тратиться на строительство с нуля. Удобно, но важно понимать: аттестация закрывает только фундамент, а не весь дом целиком.

Матрешка ответственности: кто за что в ответе (спойлер: провайдер меньше, чем вы думаете)

Соответствие 152-ФЗ — это всегда совместная работа. Разложим, кто за что отвечает.

Инфраструктура — зона ответственности провайдера защищенного облака. Провайдер должен обеспечить физическую защиту ЦОДа, защиту среды виртуализации и гипервизора, сегментацию и изоляцию сетей, межсетевой экран на периметре, обнаружение вторжений, защиту каналов администрирования, а главное — использовать средства защиты, сертифицированные ФСТЭК и ФСБ. Это то, чего у обычного облака нет, а у защищенного — есть из коробки.

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

Гостевая ОС виртуальной машины — ваша зона ответственности. У вас есть два пути: либо использовать сертифицированную операционную систему, либо установить на обычную ОС сертифицированное средство защиты от несанкционированного доступа (СЗИ). В любом случае также потребуются антивирус, своевременные обновления, включенная регистрация событий и ограничения на запуск программ.

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

Организационный слой — ваша зона ответственности. Нужно разработать модель угроз, актом определить уровень защищенности (УЗ), утвердить политику обработки персональных данных, собрать согласия от сотрудников и клиентов, назначить ответственного за обработку ПДн, зарегистрироваться в реестре операторов Роскомнадзора, подготовить регламент реагирования на инциденты и подписать с провайдером договор-поручение по статье 6 №152-ФЗ, а также регулярно проводить оценку эффективности принятых мер защиты — потому что мало внедрить, надо еще доказать, что это работает.

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

Чек-лист: какое облако выбрать под 1С:Документооборот

Пролистайте пункты. Если хотя бы на один ответили «да» — вам нужно защищенное облако.

1. Есть ли в системе персональные данные?

• ФИО сотрудников, паспорта, СНИЛС, ИНН, адреса, телефоны;

• кадровые приказы, трудовые договоры, больничные, заявления;

• сканы паспортов контрагентов (физлиц) или доверенности с ФИО.

✅ Если да — вы оператор ПДн. Обычное облако не подходит.

2. Важна ли защита от атак и взломов?

✅ Если да — защищенное облако дает сертифицированные средства защиты. У обычного облака их нет.

3. Планируете ли рост?

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

✅ Если да — лучше заложить защищенное облако сразу.

Когда можно остаться на обычном облаке или свом сервере? Таких случаев мало, но они есть. Например, если в системе абсолютно нет персональных данных (только юрлица, ИНН/КПП компаний, счета без ФИО). Вы готовы должны быть готовы взять на себя полную настройку ОС, СЗИ, МЭ+СОВ и обслуживание, а бюджет критически ограничен.

Но даже если рассматривать вопрос шире, без привязки к 152-ФЗ: защищенное облако объективно безопаснее. А такие важные для работы организации системы, как 1С:Документооборот, лучше в любом случае размещать в надежном месте — независимо от того, есть там формально ПДн или нет.

Итог: с чего начать, чтобы не получить штраф

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

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

Что касается защищенного Рег.облака — оно как раз размещено в изолированном сегменте дата-центра, имеет аттестат по высшему уровню УЗ-1 и соответствует приказам ФСТЭК № 21. Защита построена на сертифицированных ФСТЭК и ФСБ средствах, с оператором подписывается договор-поручение.

А как у вас организована работа с персональными данными в 1С? На что обращали внимание в первую очередь?

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

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

Она станет самым высокопоставленным израильским руководителем в SAP.

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

Облачная платформа SAP, известная как SAP Business Technology Platform (SAP BTP), объединяет возможности автоматизации, разработку бизнес-приложений и корпоративные процессы, все чаще используя агентов искусственного интеллекта, призванных трансформировать методы работы организаций. В этом контексте назначение Кляйнманн рассматривается как ключевой шаг в укреплении лидерства, движущего трансформацией SAP в области ИИ.

Кляйнманн в течение 12 лет занимала должность управляющего директора SAP Labs Israel, удвоив размер подразделения, превратив SAP в Израиле из регионального центра разработки в глобальный центр инноваций в области искусственного интеллекта благодаря 11 приобретениям и переходу к разработке программного обеспечения, изначально ориентированного на ИИ.

Компания SAP сообщила о выручке в размере 37,8 млрд евро в 2025 году. Компания обслуживает более 400 000 организаций по всему миру, на деятельность которых приходится приблизительно 84% мировой торговли. В облачном сегменте платформы SAP насчитывают более 300 миллионов подписчиков, что укрепляет ее позиции в качестве мирового лидера.

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

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

Перевод с английского

ИСТОЧНИК