Центры обработки данных: под землёй, под водой и за пределами планеты

Концептуальная иллюстрация вариантов размещения ЦОД. Изображение создано с помощью ИИ; реальные объекты не воспроизводятся.  

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

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

В октябре 2026 года физическая уязвимость цифровой инфраструктуры получила особенно наглядное российское подтверждение. В сообщении от 9 октября Яндекс рассказал о серьёзном повреждении и остановке дата-центра в Сасове после атаки БПЛА в ночь с 7 на 8 октября, а также об атаке на площадку в Калуге. По сообщению компании, сотрудники не пострадали; на момент публикации сроки восстановления оборудования ещё оценивались. Это описание ситуации на указанную дату, а не утверждение о состоянии сервисов в момент, когда читатель открыл статью. [1]

Я предлагаю посмотреть на ЦОД одновременно с нескольких сторон: какие задачи они решают, почему получают необычную архитектуру, что можно подтвердить в заявлениях об их защищённости и какие требования действительно распространяются на владельцев инфраструктуры и её пользователей. Открытые источники позволяют разобрать немало интересных объектов. Однако объявить один из них безусловно «самым защищённым в мире» они не позволяют: для такого сравнения понадобились бы единая модель угроз, сопоставимые испытания и данные, которые операторы обычно не публикуют.

Что такое ЦОД и чем он отличается от облака

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

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

Классифицировать ЦОД удобнее по нескольким независимым признакам. Иначе в один ряд попадают, например, «модульный», «облачный» и «подземный», хотя один объект может одновременно соответствовать всем трём определениям. Приведённое ниже деление — практическая схема для этой статьи, а не попытка заменить нормативную классификацию.

Модель владения и услуги. Основные варианты: Собственный ЦОД, colocation, аренда серверов, облако; Что меняется для заказчика: Границы управления и ответственности.

Масштаб и назначение. Основные варианты: Корпоративный, крупный облачный, edge, AI и HPC; Что меняется для заказчика: Плотность нагрузки, задержки, требования к сети.

Исполнение. Основные варианты: Капитальное здание, модульный, контейнерный; Что меняется для заказчика: Темпы развёртывания, расширения и замены.

Среда размещения. Основные варианты: Наземный, подземный, плавучий, подводный; Что меняется для заказчика: Внешние воздействия и условия ремонта.

Архитектура сервиса. Основные варианты: Одна площадка, несколько зон, несколько регионов; Что меняется для заказчика: Последствия потери здания или региона.

При colocation заказчик обычно размещает собственное оборудование и получает питание, охлаждение, связь и физические условия эксплуатации в согласованном объёме. При аренде выделенного сервера к зоне ответственности поставщика добавляется само оборудование. В IaaS провайдер управляет ещё и виртуализацией, а заказчик обычно отвечает за гостевую систему, приложения и данные. В PaaS и SaaS граница сдвигается дальше. Это типовые модели: окончательное распределение обязанностей устанавливают архитектура услуги и договор. Публичные модели разделения ответственности, например у AWS, прямо связывают границу управления с выбранным сервисом. [52]

Edge-ЦОД размещают ближе к пользователям, промышленным объектам или источникам данных, когда важны задержка и локальная автономность. Их сложность часто заключается в распределённой эксплуатации: десятки небольших площадок труднее одинаково хорошо обслуживать и контролировать. Модульное исполнение помогает тиражировать решения, но каждый модуль всё равно зависит от местного электроснабжения, коммуникаций и условий доступа.

У AI- и HPC-инфраструктуры свои особенности. Плотно установленные ускорители предъявляют высокие требования к отводу тепла и межсоединениям. Жидкостное охлаждение требует работы с гидравлическими контурами, качеством теплоносителя, обнаружением протечек и обслуживанием соединений. При direct-to-chip жидкость проходит через теплообменники на компонентах; при погружном охлаждении оборудование работает в подходящей диэлектрической среде. Оба подхода отличаются от подводного ЦОД: там в воду помещают герметичный модуль, а не обязательно сами электронные платы.

Надёжность, доступность и классификация Tier

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

Система Tier от Uptime Institute относится к инфраструктуре площадки. Tier I обозначает базовую инфраструктуру, Tier II — наличие резервных компонентов мощности. Для Tier III существенна возможность планового обслуживания инфраструктуры без остановки ИТ-нагрузки, для Tier IV — отказоустойчивость в рамках требований стандарта. Это полезная классификация, но она не означает неуязвимости к кибератаке, ошибке приложения или любому внешнему воздействию. Также нужно различать сертификацию проектной документации, построенного объекта и эксплуатационной устойчивости. [2]

Из надписи Tier III нельзя автоматически вывести гарантированный простой конкретного приложения за год. Приложение может иметь собственную единственную точку отказа, а в договорном SLA могут быть исключения и особые правила расчёта. Выражения вроде «Tier III+» тоже требуют уточнения: у Uptime Institute четыре уровня, а дополнительный знак сам по себе не образует отдельной категории этой системы. Для проверки полезнее увидеть точное наименование сертификата, охваченную им площадку и проверяемые свойства. [2]

Оценивать защищённость стоит через сценарии. Что произойдёт при отключении внешнего питания? При ремонте одного контура охлаждения? При компрометации учётной записи инженера? При пожаре, который закрывает доступ на территорию? При одновременной недоступности связи и резервного канала администрирования? Ответы будут различаться даже у внешне похожих объектов. Столь же важно понимать предел: можно ли сохранить обслуживание клиентов при полной потере площадки.

Необычные ЦОД в России и мире

Подземные ЦОД в бывших шахтах и убежищах

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

Pionen в Стокгольме. Оператор Bahnhof размещает этот дата-центр в бывшем убежище времён холодной войны под массивом Vita Bergen. Он стал одним из самых узнаваемых примеров серверного пространства внутри скалы. Для читателя здесь интересен сам принцип повторного использования защитного сооружения: природный массив и контролируемые входы становятся частью физической среды. [3]

Распространённые описания «выдержит ядерный удар» я бы воспринимал только вместе с условиями, к которым они относятся. Мощность и удалённость воздействия, состояние входных узлов и инженерных коммуникаций имеют принципиальное значение. Сохранность помещения ещё не доказывает сохранение внешней связи или возможности обслуживать клиентов. В нашей подборке Pionen — подтверждённый пример необычного подземного ЦОД, а не победитель универсального испытания на неуязвимость.

SVG-Rennesøy в Норвегии. Green Mountain переоборудовала бывшее хранилище боеприпасов НАТО в дата-центр с машинными залами внутри горы. Оператор указывает Tier III и использование природных условий для охлаждения; отдельные материалы посвящены системе, использующей холодную воду фьорда. Здесь защитное размещение соединяется с инженерной экономикой: окружающая среда одновременно формирует физический барьер и источник охлаждения. [4]

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

Iron Mountain WPA-1 в Пенсильвании. Оператор описывает действующий коммерческий ЦОД в бывшей известняковой шахте на глубине 220 футов — примерно 67 метров. Это пример того, как подземное промышленное пространство используют для обычных услуг размещения оборудования. Полезный вопрос здесь связан не только с толщиной породы: насколько независимы внешние коммуникации и как организованы доступ, доставка и восстановление при повреждении наземной инфраструктуры. [5]

Swiss Fort Knox в Швейцарии. MOUNT10 представляет эту подземную инфраструктуру как защищённое место хранения данных и основу сервисов резервного копирования. Название и формулировки о максимальной безопасности относятся к позиционированию оператора. Для заказчика важнее выяснить, какой именно сервис он приобретает, как разделены полномочия доступа и насколько независимо хранится резервная копия от рабочей среды. Географически удалённое хранилище может оказаться ценнее ещё одного защищённого зала в том же здании. [6]

Российский опыт RUVDS. В технической статье 2020 года компания подробно рассказала о своём первом ЦОД в бывшем советском убежище. Среди описанных работ — гидроизоляция, организация охлаждения, питания и связи. Особенно показателен рассказ о вибрациях, которые передавались через конструкции и оборудование и влияли на дисковые системы. Это эксплуатационное наблюдение самого оператора, а не независимое испытание объекта, но оно хорошо показывает, почему в бункере приходится решать вполне приземлённые инженерные задачи. Текст 2020 года также не подтверждает автоматически текущее состояние площадки. [7]

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

Российские ЦОД рядом с энергетической инфраструктурой

Для России показателен ЦОД «Калининский» в Удомле, который АТОМДАТА связывает с инфраструктурой Калининской АЭС. Оператор подчёркивает защищённое размещение, режим территории и индивидуальные зоны доступа клиентов. Это другой подход к выбору площадки: использовать преимущества энергетической и организационной инфраструктуры крупного промышленного объекта. [8]

Такой объект обоснованно интересен для обзора защищённых ЦОД в РФ. Однако формулировки «самый защищённый» и «самый крупный» на странице поставщика не дают независимого сравнения всех российских площадок. Для оценки безопасности требуется проверить режим доступа, фактическую автономность, независимость внешних зависимостей и договорные обязательства. Бесполётный режим территории представляет собой правовую и организационную меру; сам по себе он не доказывает способность сооружения выдержать любое физическое воздействие.

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

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

Плавучие и подводные ЦОД

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

Nautilus в Стоктоне. Проект известен размещением на плавучей платформе и использованием воды окружающего водоёма через систему теплообмена. Компания сообщала о вводе Stockton в эксплуатацию в 2021 году. Это коммерческий пример использования водной среды, который следует отличать от герметичной серверной капсулы на морском дне. Заявления о водопотреблении и эффективности необходимо читать вместе с границами измерения: водозабор, возврат воды и её безвозвратное потребление — разные показатели. [10]

Project Natick Microsoft. В 2018 году исследователи разместили модуль Northern Isles у Оркнейских островов, а в 2020 году подняли его для изучения результатов. Microsoft сообщила, что частота отказов серверов в этом эксперименте была примерно в восемь раз ниже, чем в сравниваемой наземной среде. Среди возможных объяснений обсуждались азотная атмосфера и отсутствие вмешательства людей. Это результат конкретного исследовательского развёртывания; переносить коэффициент на любой подводный ЦОД нельзя. [9]

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

Hicloud и китайские проекты. Компания описывает развитие подводной инфраструктуры в Линшуе на Хайнане как переход к коммерческому применению. В случае шанхайского Lingang UDC уже недостаточно ссылаться только на анонс 2025 года: материалы администрации Lin-gang за февраль 2026 года сообщают о размещении вычислительных кластеров, а публикация на портале Шанхая от 1 июня — о вводе демонстрационного проекта в работу в мае. Его особенность — сочетание подводных модулей, морского теплообмена и электроснабжения от офшорной ветроэнергетики. При этом опубликованную проектную мощность и показатели экономии нельзя автоматически приравнивать к фактической загрузке или независимо подтверждённым результатам за весь жизненный цикл. [11]

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

Орбитальные ЦОД и отвод тепла

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

В Project Suncatcher Google исследует сеть спутников с TPU-ускорителями и оптическими межспутниковыми каналами. В технической публикации 2025 года рассмотрены связь, динамика близко расположенных аппаратов, радиационные воздействия и экономика запусков; работа обозначена как препринт. Планы испытаний прототипов являются следующим этапом исследования, а не свидетельством наличия готового орбитального облака. [12]

Европейский ASCEND исследует техническую осуществимость и экологические последствия космических дата-центров. Материалы проекта и Thales Alenia Space показывают, насколько выводы зависят от допущений о средствах выведения и жизненном цикле. Экологический результат необходимо считать вместе с изготовлением аппаратов, запусками, заменой оборудования и завершением эксплуатации. [13]

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

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

Сравнение объектов и стадий развития

Рисунок 1. Как различать коммерческую эксплуатацию, завершённый эксперимент и исследовательский проект. Схема обобщает приведённые в статье примеры и не является рейтингом технологической готовности. Источники: [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14].  

Pionen, Швеция. Что подтверждают использованные источники: Коммерческий ЦОД в бывшем убежище [3]; Главная оговорка: Универсальная стойкость к ударам не доказана.

SVG-Rennesøy, Норвегия. Что подтверждают использованные источники: ЦОД внутри горы, охлаждение с использованием фьорда [4]; Главная оговорка: Зависит от всей инженерной цепочки.

Iron Mountain WPA-1, США. Что подтверждают использованные источники: Коммерческое размещение в бывшей шахте [5]; Главная оговорка: Глубина не обеспечивает независимость связи.

Swiss Fort Knox, Швейцария. Что подтверждают использованные источники: Подземная инфраструктура хранения и резервирования [6]; Главная оговорка: Проверяется конкретная услуга и её границы.

Бункерный кейс RUVDS, Россия. Что подтверждают использованные источники: Опубликованный опыт эксплуатации [7]; Главная оговорка: Источник датирован 2020 годом.

Калининский, Россия. Что подтверждают использованные источники: Площадка у АЭС с заявленным защищённым режимом [8]; Главная оговорка: Сравнительный мировой рейтинг отсутствует.

Natick, Великобритания. Что подтверждают использованные источники: Завершённый подводный эксперимент [9]; Главная оговорка: Результаты относятся к его условиям.

Stockton, США. Что подтверждают использованные источники: Коммерческий водоохлаждаемый проект [10]; Главная оговорка: Плавучий объект не равен подводному.

Hicloud и Lingang UDC, Китай. Что подтверждают использованные источники: Коммерческие проекты; есть сообщения 2026 года о вводе Lingang [11]; Главная оговорка: Ввод проекта не равен освоению всей проектной мощности.

Suncatcher и ASCEND. Что подтверждают использованные источники: Исследования орбитальной инфраструктуры [12, 13]; Главная оговорка: Не готовая замена наземным облакам.

Что показывают научные исследования

Инженерный проект отвечает на вопрос, как построить определённый объект. Научное исследование должно ещё и показать, на каких данных основан вывод, с чем сравнивали решение и при каких условиях результат перестаёт работать. Для необычных ЦОД это особенно важно: выигрыш в одной характеристике легко получить ценой ухудшения другой. Например, уменьшение потребления энергии на охлаждение не гарантирует уменьшения стоимости восстановления после отказа.

Плавучие ЦОД для Северного морского пути. В работе А. Е. Карповича, И. Е. Маренича, В. Н. Половинкина и С. А. Ямщикова, опубликованной в «Трудах Крыловского государственного научного центра» в 2025 году, рассматривается перспектива такого размещения в России, включая энергетическую концепцию с использованием водорода. Это исследование проектного направления, а не отчёт о функционирующей российской сети плавучих ЦОД. [14]

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

Переиспользование шахтных территорий. Публикация Д. А. Джерелей 2017 года о проектировании центров хранения и обработки данных на основе недействующих и убыточных шахт Донбасса рассматривает архитектурное преобразование промышленной инфраструктуры. Здесь важно не достраивать вывод за автора: использование территории и сооружений шахты не означает обязательного размещения серверов в глубоких подземных выработках. Для конкретного решения нужны планы, изыскания и инженерные расчёты. [15]

Устойчивость как задача о зависимостях. Г. Г. Гребенюк и Н. В. Лубков из ИПУ РАН в статье 2022 года рассматривают надёжностный подход к инженерной инфраструктуре. Помимо оценки устойчивости они исследуют обратную задачу: поиск критических сечений, которые разрывают снабжение потребителей ресурсами и энергией. Это работа об инфраструктуре в целом, но её подход полезен и для ЦОД. [16]

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

Геотехнические риски. Е. Ю. Куликова, А. Г. Полянкин и А. М. Потокина в статье 2023 года исследуют управление рисками при проектировании подземных сооружений. Для нашего предмета значимы учёт грунтовых вод, геологической среды и взаимодействия сооружения с окружающей застройкой. Работа не посвящена специально ЦОД; её можно использовать как смежную методическую основу при оценке подземной площадки. [17]

Физическое воздействие на цифровое управление. В AquaSonic, опубликованной в рамках IEEE Symposium on Security and Privacy 2024, исследователи изучали акустическое воздействие на дисковые подсистемы в экспериментальной подводной среде. На стенде наблюдались снижение производительности и последствия для распределённых систем и управления ресурсами. Принципиально, что воздействие на физический носитель отражалось на поведении программных механизмов, предназначенных для обеспечения устойчивости. [18]

Это не сообщение об успешной атаке на промышленный Natick и не доказательство уязвимости любого подводного ЦОД. Выводы зависят от оборудования, корпуса, среды и условий эксперимента; результат для механических HDD нельзя автоматически переносить на SSD. Но исследование демонстрирует важный класс связей: физическая аномалия способна выглядеть для управляющего ПО как обычное ухудшение работы узла и запускать перераспределение нагрузки. Для защиты полезно исследовать поведение всей системы, включая реакцию автоматики. [18]

Наконец, есть технические и отраслевые материалы, которые помогают формулировать вопросы, но не заменяют научную проверку. Российские публикации НВБС об инженерных системах как цели кибератак и экспертная дискуссия RUБЕЖ полезны для анализа контроллеров, удалённого обслуживания и устаревающих компонентов. Их заявления о масштабах угроз следует проверять отдельно от рекомендаций самих экспертов. [49, 50]

Эффективность и восстановление

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

Показатель PUE — отношение всей энергии, потреблённой ЦОД, к энергии ИТ-оборудования за согласованный период и в определённых границах измерения. Его определение и применение стандартизирует ISO/IEC 30134-2. Если условный объект за период потребил 12 МВт·ч, а ИТ-оборудование — 10 МВт·ч, PUE равен 1,2. Однако показатель ничего не говорит о полезности выполненных вычислений, устойчивости к атакам или количестве потерянных данных. [22]

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

Для непрерывности важны RTO и RPO. RTO задаёт целевой срок восстановления, RPO — требуемую точку восстановления данных, обычно выраженную как максимально допустимая глубина их потери во времени. Фактический интервал между последней пригодной точкой восстановления и инцидентом ещё нужно сравнить с установленным RPO. Если бизнес допускает потерю не более 15 минут операций, ночной бэкап сам по себе не выполняет это условие. Если требуется восстановление за час, наличие копии без готовой площадки и проверенной процедуры тоже недостаточно. Эти параметры устанавливают исходя из последствий для деятельности, а не из удобства расписания резервного копирования. [24, 53]

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

Рисунок 2. Условный пример целевых RPO и RTO при инциденте в 10:00. Масштаб времени условный; фактический результат проверяют восстановлением. Источники: [24, 53].  

Как защищают ЦОД

Выбор площадки и инженерная защита

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

Физическую защиту выстраивают последовательно: границы территории, въезд, вход в здание, внутренние зоны, машинный зал, стойка и носитель. Google публично описывает собственную модель из шести слоёв физической безопасности. Её полезно изучать как пример эшелонирования, но число слоёв не является универсальной нормой. Для конкретного объекта значимы независимость механизмов, контроль исключений и способность обнаружить нарушение. [19]

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

В электроснабжении важны не только количество источников, но и схема переключения, селективность защиты, распределение нагрузки и проверяемая работа при обслуживании. ИБП даёт время для переходных процессов и запуска резервных источников; длительная автономность зависит от другой части системы, в том числе топлива. Два генератора могут иметь общий уязвимый элемент, а большой запас топлива — не решать проблемы его качества или подачи. Обозначения N+1 и 2N описывают резервирование, но не заменяют анализа общей схемы. Требования к инфраструктуре питания рассматриваются, в частности, в серии ISO/IEC 22237. [25]

Рисунок 3. Четыре взаимосвязанных уровня защиты и общие организационные процессы. Это авторская схема для статьи, а не классификация Tier или обязательный набор мер. Источники: [19, 20, 21, 22, 23, 24, 25, 29].  

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

Противопожарная защита также не сводится к выбору газа. Нужны обнаружение, зонирование, огнестойкость конструкций, защита кабельных проходок, работа инженерных систем при пожаре и безопасная эвакуация. Решение для машинного зала не обязательно подходит для аккумуляторного помещения или дизельной установки. Конкретные способы тушения выбирают по проекту, характеристикам помещений и оборудования. Здесь нельзя объявлять одну технологию обязательной для всех ЦОД или гарантированно безвредной для любой электроники. [29]

Киберзащита инженерной автоматики

Системы диспетчеризации здания, контроллеры охлаждения, электропитания и мониторинга образуют собственную цифровую среду. Для её обозначения используют OT — операционные технологии. DCIM помогает управлять инфраструктурой ЦОД, BMS — инженерными системами здания, но конкретные функции и границы этих платформ зависят от реализации. Их компрометация способна затронуть физические условия работы серверов. Особенности защиты подобных систем рассматривает NIST SP 800-82. [20]

Разумная архитектура отделяет пользовательские и корпоративные сети от инженерного управления и ограничивает переходы между ними. Подрядчику нужен доступ к конкретной системе на согласованный срок, а не постоянный универсальный проход в инфраструктуру. Значимы индивидуальные учётные записи, многофакторная аутентификация там, где она поддерживается, контролируемые точки входа и журналирование. Для старого оборудования могут потребоваться компенсирующие меры, поскольку просто установить современный агент защиты на контроллер часто невозможно. [20]

Отдельного внимания заслуживают IPMI, iDRAC, iLO и другие средства внеполосного управления серверами. Они полезны, когда операционная система недоступна, но предоставляют мощные административные возможности. Изоляция таких интерфейсов, учёт действий инженеров и управление привилегированным доступом должны охватывать и аварийные процедуры. Общая аварийная учётная запись без контроля может обесценить аккуратно настроенные обычные права. [50]

Полезно сопоставлять инженерную телеметрию с событиями информационной безопасности. Изменение температурной уставки, новая удалённая сессия и рост температуры вместе дают больше контекста, чем три независимых уведомления. Но корреляция ещё не доказывает злонамеренность: причиной могут быть обслуживание, ошибочная команда или неисправный датчик. Аналитика должна помогать инженеру принимать решение, сохраняя предусмотренные проектом локальные защитные механизмы. [49]

Защита данных и восстановление сервиса

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

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

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

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

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

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

Потеря внешнего питания. Примеры мер: ИБП, резервные источники, управление нагрузкой; Чем проверить результат: Испытанием перехода и работы под нагрузкой.

Отказ теплоотвода. Примеры мер: Резерв охлаждения, датчики, ограничение мощности; Чем проверить результат: Проверкой теплового режима и автоматики.

Компрометация инженера. Примеры мер: Разделение прав, MFA, контроль сессий; Чем проверить результат: Проверкой доступных действий и журналов.

Повреждение данных. Примеры мер: Раздельные копии, защищённое хранение; Чем проверить результат: Восстановлением в изолированную среду.

Потеря площадки. Примеры мер: Георезервирование и запас ресурсов; Чем проверить результат: Учением с переключением бизнес-сервиса.

Общая внешняя зависимость. Примеры мер: Независимые трассы и поставщики; Чем проверить результат: Анализом фактических маршрутов и узлов.

Организационные меры и эксплуатация

Защита ЦОД требует согласованной работы владельца здания, эксплуатации, ИТ, ИБ, охраны, подрядчиков и заказчиков. Если организация не определила, кто принимает решение об отключении нагрузки, разрешает аварийный доступ или уведомляет клиентов, техническая готовность может не превратиться в своевременное действие. Управленческая задача состоит в том, чтобы полномочия и обязанности были понятны до инцидента.

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

Управление изменениями нужно не только администраторам серверов. Замена контроллера, обновление BMS, перенос кабеля, изменение порогов температуры или перестройка доступа подрядчика способны повлиять на общий риск. Для значимых работ нужны оценка последствий, согласованное окно, порядок возврата и последующая проверка. Для аварийных изменений — ускоренный, но всё равно прослеживаемый процесс. Исключения без срока действия постепенно превращаются в постоянную архитектуру.

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

ISO/IEC 27001 задаёт основу системы менеджмента информационной безопасности и управления рисками, а ISO 22301 — системы менеджмента непрерывности деятельности. Их ценность заключается в организации постоянной работы: планирования, контроля, оценки и улучшений. При этом сертификат нужно читать вместе с областью действия. Он может относиться к определённой услуге или подразделению, а не к любому продукту всей группы компаний. [23, 24]

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

Ответственность провайдера и заказчика

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

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

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

Рисунок 4. Типовые границы технического управления без дополнительных управляемых услуг. Юридические обязанности и детали обслуживания определяют отдельно. Источник для модели IaaS: [52].  

Требования к ЦОД и размещённым системам

Российское регулирование

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

Общую правовую основу защиты информации задаёт 149-ФЗ, в том числе статья 16. Специальные режимы уточняют обязанности в зависимости от категории информации и системы. Из этого следует практический порядок: сначала установить объект защиты и основания применения требований, затем выбирать меры и способы подтверждения их выполнения. [51]

Определение ЦОД и реестр. Федеральный закон от 23 июля 2025 года № 244-ФЗ внёс в законодательство о связи определение центра обработки данных и положения о реестре. Правила его формирования утверждены постановлением Правительства РФ от 28 ноября 2025 года № 1932, вступившим в силу 1 марта 2026 года. Этот слой регулирования следует учитывать отдельно от требований к защите конкретных ИСПДн, ГИС или значимых объектов КИИ. [27, 28]

В пункте 9 Правил № 1932 среди условий включения предусмотрена декларация соответствия требованиям, затрагивающим мониторинг ИБ в системах управления инженерной инфраструктурой и физической защищённостью, надёжность, ограничение доступа, возможность резервного копирования, сигнализацию, сегментацию и разграничение прав. Это показательный пример того, как нормативное регулирование связывает ИБ с инженерией ЦОД. Но реестровая запись не заменяет сертификацию Tier, аттестацию размещённой системы и проверку исполнения договора. [28]

Здание и инженерная безопасность. Для строительства и эксплуатации существенны технические регламенты о безопасности зданий и сооружений и о требованиях пожарной безопасности, а также применимые проектные нормы. Специальный СП 541.1325800.2024 посвящён зданиям и сооружениям центров обработки данных. У него есть собственная область применения: например, она не распространяется на проектирование некапитальных мобильных зданий ЦОД. Поэтому механически переносить все его положения на контейнер, судно или морскую капсулу нельзя. Обязательность конкретного положения устанавливается с учётом законодательства, применимых перечней и принятого способа обоснования безопасности. [29]

Персональные данные. Если в системе обрабатываются ПДн, применяются 152-ФЗ, требования постановления Правительства № 1119 и соответствующие меры защиты. Статья 19 закона касается безопасности обработки, включая защиту от уничтожения, изменения и блокирования данных; поэтому доступность и восстановление имеют здесь самостоятельное значение. Постановление № 1119 определяет уровни защищённости ИСПДн. Эти уровни нельзя отождествлять с Tier дата-центра. [30, 31]

В проверенной нормативной базе меры технической защиты ИСПДн представлены приказом ФСТЭК России от 18 февраля 2013 года № 21. При работе с обновлениями нужно отличать опубликованный проект замены от принятого и вступившего в силу акта. Само наличие обсуждения нового документа не прекращает действие прежнего. Для практического проекта необходимо фиксировать редакцию и переходные положения на дату применения, а не руководствоваться заголовком новости. [32]

Размещение в стороннем ЦОД не устраняет обязанностей оператора персональных данных. Если поставщику поручается обработка, отношения оформляют с учётом части 3 статьи 6 152-ФЗ: определяют операции, цели, обязанности и требования к защите. Но аренда помещения или стойки сама по себе ещё не описывает весь фактический состав обработки. Нужно разобраться, получает ли поставщик доступ к данным, выполняет ли резервное копирование, администрирование или поддержку и какие участники вовлечены дальше. Отдельно оценивают локализацию и трансграничную передачу по применимым положениям закона. [30]

Государственные информационные системы. С 1 марта 2026 года действует приказ ФСТЭК России от 11 апреля 2025 года № 117 о защите информации в ГИС и иных ИС государственных органов, государственных унитарных предприятий и государственных учреждений. Изменения приказом от 8 мая 2026 года № 137 в основном вступили в силу 1 сентября 2026 года. Для пункта 7 приложения, который меняет пункт 32 требований об оценке показателей защищённости и зрелости, установлен отдельный срок — 1 марта 2027 года. Поэтому в октябре 2026 года нельзя применять всю новую редакцию без учёта этой отсрочки. [33, 34]

Для заказчика здесь важен объект применения требований: информационная система и её инфраструктурные компоненты, а не только вывеска здания. Услуга защищённого размещения должна быть сопоставлена с архитектурой системы, классом защищённости, моделью угроз и границами ответственности. Заявление поставщика «у нас есть аттестат» требует уточнения: на какой объект, в какой конфигурации, с какими условиями эксплуатации и охватывает ли это решение конкретного клиента. [33]

Критическая информационная инфраструктура. 187-ФЗ и требования к безопасности значимых объектов КИИ образуют ещё один слой. Дата-центр не становится значимым объектом КИИ автоматически из-за мощности, наличия серверов или важности для клиента. Анализируют признаки субъекта, информационные системы, сети и АСУ в установленных законом сферах, затем выполняют предусмотренные процедуры категорирования. Для значимых объектов применяются, в частности, требования приказа ФСТЭК № 239. Необходимо различать владельца здания, поставщика услуги и субъекта КИИ. [35, 36]

СКЗИ. При использовании криптографической защиты персональных данных рассматривают приказ ФСБ России от 10 июля 2014 года № 378. В соответствующих случаях учитывают Положение ПКЗ-2005, утверждённое приказом ФСБ № 66, Инструкцию, утверждённую приказом ФАПСИ № 152 от 13 июня 2001 года, и эксплуатационную документацию конкретных средств. Это не универсальное требование установить один и тот же криптографический шлюз в любой ЦОД. Применимость и состав мер определяют по режиму информации, модели угроз, используемым средствам и условиям их эксплуатации. [37, 38, 39]

Практическая сторона криптографической защиты включает учёт экземпляров и ключевых документов, назначение ответственных, допуск персонала, хранение, замену ключей, действия при компрометации и вывод из эксплуатации. Размещённое у подрядчика СКЗИ продолжает нуждаться в этих процессах. Договор, режим помещения и обязанности обслуживающего персонала должны соответствовать выбранной схеме использования. Наличие сертификата на изделие само по себе не доказывает соблюдение правил его эксплуатации. [37, 38, 39]

Специальные обязанности организаций. Указы Президента № 166 от 30 марта 2022 года и № 250 от 1 мая 2022 года необходимо рассматривать в пределах указанного в них круга субъектов. Первый затрагивает технологическую независимость и ограничения в отношении ПО на значимых объектах КИИ для соответствующих органов и заказчиков. Второй устанавливает дополнительные организационные меры ИБ и требования для перечисленных органов и организаций. Формула «любой российский ЦОД обязан по этим указам заменить всё иностранное оборудование» не отражает содержание и границы этих актов. [40, 41]

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

Статус ЦОД и реестр. Применимость правил, сведения об объекте и владельце.

Здание и инженерия. Проектные решения, пожарную безопасность, эксплуатацию.

ИСПДн. Роли участников, уровень защищённости, актуальные угрозы.

ГИС и иные ИС в области приказа № 117. Класс, состав системы, меры и подтверждение соответствия.

КИИ. Статус субъекта, объекты, категорирование и обязанности.

Криптографическая защита. Основания применения, условия эксплуатации, ключи и учёт.

Отрасль и договор. Дополнительные ограничения, SLA и ответственность.

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

Зарубежное регулирование и международные стандарты

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

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

Директива NIS2 включает поставщиков услуг дата-центров в цифровую инфраструктуру. Применимость зависит от установленных критериев и национальной реализации директивы. Статья 21 предусматривает управление киберрисками, включая реагирование, непрерывность, резервирование, безопасность цепочки поставок и контроль эффективности мер. Исполнительный регламент ЕС 2024/2690 конкретизирует технические и методические требования для ряда цифровых поставщиков, включая ЦОД. Это уже непосредственно относится к организации процессов провайдера. [43, 44]

Регламент DORA относится к цифровой операционной устойчивости финансового сектора. Для ЦОД он важен через отношения финансовых организаций с поставщиками ИКТ-услуг: договоры, контроль рисков сторонних поставщиков, тестирование, планы выхода и, для поставщиков, признанных критическими, специальный надзор. Из этого не следует, что каждый дата-центр автоматически получает одинаковый набор обязанностей по DORA. Требуется определить роль и основание применения. [45]

В ЕС также действует директива CER об устойчивости критических субъектов. Её нужно читать во взаимосвязи с NIS2: для цифровой инфраструктуры предусмотрен специальный режим исключений из ряда положений CER, чтобы избежать дублирования. Поэтому нельзя просто сложить все требования двух директив и объявить получившийся список обязательным для каждого ЦОД. [46]

В США полезной технической основой являются публикации NIST. SP 800-53 содержит каталог мер, включая физическую и средовую защиту, управление доступом и планирование восстановления. SP 800-82 рассматривает операционные технологии. Это не единый универсальный закон для всех коммерческих дата-центров: обязательность конкретного набора мер определяется применимым регулированием, отраслью и договорными условиями. [47, 20]

В Великобритании в 2024 году инфраструктуру дата-центров отнесли к критической национальной инфраструктуре. Само это решение следует отличать от введения детальных обязательных требований. Правительственные материалы по Cyber Security and Resilience Bill описывают развитие специального регулирования; положения законопроекта нельзя выдавать за уже действующие нормы без проверки стадии его принятия. [48]

Отдельный общий язык дают стандарты. Серия ISO/IEC 22237 охватывает инфраструктуру ЦОД, включая строительные решения, питание и другие обеспечивающие системы. ANSI/TIA-942 также рассматривает инфраструктуру, размещение, инженерные и защитные аспекты. ISO/IEC 27001 относится к менеджменту информационной безопасности, ISO 22301 — к непрерывности деятельности. Сертификаты по этим системам имеют разный предмет и не взаимозаменяемы. [23, 24, 25, 26]

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

Что спросить перед выбором площадки

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

Полезно запросить подтверждения по нескольким группам вопросов:

1. Какие услуги и компоненты охватывает обязательство по доступности, как её измеряют и какие исключения есть в SLA?
2. Что происходит при потере площадки, кто выполняет переключение и хватает ли резервной мощности для реальной нагрузки?
3. Насколько независимы энергоснабжение, связь, управление, персонал и логистика основной и резервной площадок?
4. Какие данные, конфигурации и ключи входят в резервирование, где находятся копии и когда проверялось восстановление?
5. Кто получает физический и удалённый доступ, как согласуются работы и контролируются привилегии подрядчиков?
6. Какими документами подтверждаются заявленные свойства и относится ли их область действия к приобретаемой услуге?
7. Как выполняются уведомление об инциденте, расследование, предоставление свидетельств и выход из услуги?

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

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

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