Дата-центр QTS в американской Джорджии оказался в центре скандала после того, как власти нашли неучтённое потребление около 110 млн литров воды. Жители жаловались на падение давления, а коммунальные службы месяцами не видели два подключения к водопроводу на стройке крупного кампуса для искусственного интеллекта.
История выглядит как коммунальный конфликт, но для отрасли интернет-безопасности она важнее. Она показывает, что уязвимости крупных цифровых объектов часто начинаются не с вредоносного кода, а с плохого учёта, слабой проверки подрядчиков и непрозрачной эксплуатации инфраструктуры.
Что произошло в Джорджии
Речь идёт о проекте QTS Fayetteville, который также называют Project Excalibur. Застройщик Quality Technology Services принадлежит инвестиционной группе Blackstone. Кампус строят примерно в 30 километрах к югу от Атланты.
По данным источника, объект занимает около 2,5 кв. км. На площадке возводят 13 зданий общей площадью примерно 576 тыс. кв. м, а позже число корпусов может вырасти до 16. Инвестиции оценивают в $1 миллиард.
Проблему заметили не инспекторы, а местные жители. Они пожаловались на резкое падение давления воды в жилом районе. Это случилось на фоне засухи: власти сами просили население экономить воду и отказаться от полива газонов.
Проверка показала, что строительная площадка использовала два подключения к водопроводу, о которых коммунальные службы фактически не знали. За это время через них прошло около 110 млн литров воды.
Почему штрафа не последовало
По данным Politico, QTS должна была задним числом выплатить около $147 тыс. за неучтённое потребление. Но власти округа решили не назначать штраф.
Директор местной водной службы Ванесса Тайгерт объяснила это так: «QTS — крупнейший клиент округа, с которым необходимо оставаться партнёрами». Формулировка вызвала критику: для жителей она прозвучала как признание, что крупный технологический проект получил особый режим.
Компания заявляет, что вода шла только на строительные нужды: бетон, подавление пыли и подготовку площадки. В дальнейшем QTS обещает замкнутые системы охлаждения, где вода циркулирует повторно и почти не берётся из муниципальных сетей. После запуска объектов, по версии компании, вода понадобится только для туалетов и кухонь.
Стороны спорят даже о сроках. Власти считают, что неучтённое потребление длилось около четырёх месяцев. QTS говорит о периоде от девяти до 15 месяцев.
Где здесь риск для интернет-инфраструктуры
Дата-центр держится не только на серверах, сетевых кабелях и системах хранения. Ему нужны электричество, охлаждение, вода, физическая охрана, подрядчики, учётные системы и регламенты доступа. Если одна часть этой цепочки выпадает из контроля, страдает весь объект.
В случае QTS округ признал сразу несколько слабых мест. Коммунальные службы не заметили проблему месяцами из-за ошибок при переходе на облачную систему учёта и нехватки сотрудников. По словам Тайгерт, фактически один человек занимался и инспекциями, и проверкой документов.
Для кибербезопасности это знакомая картина. Организация может купить дорогие средства защиты, но пропустить базовую инвентаризацию: кто подключён, какие системы работают, кто их проверяет и кто отвечает за аномалии. В цифровой среде похожие провалы приводят к утечкам ключей, забытым серверам и незамеченным правам доступа. Похожий урок виден в истории про то, как уволенный подрядчик стёр 96 баз властей США: слабый контроль процедур превращает рядовой доступ в серьёзный ущерб.
Бум ИИ усиливает нагрузку на города
Инцидент в Джорджии всплыл на фоне быстрого роста инфраструктуры для искусственного интеллекта. По данным источника, в штате уже работают более 200 дата-центров. Их энергопотребление и давление на коммунальные сети всё чаще вызывают споры с местными жителями.
В этом году городской совет одного из городов штата полностью запретил строительство новых дата-центров во всех зонах города. Похожие ограничения, по данным отраслевого трекера, действуют как минимум в 50 американских городах.
Для бизнеса это сигнал: репутационные риски инфраструктурных проектов растут вместе с мощностью серверных ферм. Компания может говорить о передовых вычислениях и ИИ-сервисах, но конфликт с водой, электричеством или землёй быстро превращает технологический проект в политическую и юридическую проблему.
Есть и климатический фактор. Джорджия переживает умеренную и сильную засуху, а губернатор недавно вводил режим чрезвычайной ситуации из-за лесных пожаров. На таком фоне десятки миллионов литров неучтённой воды выглядят не технической ошибкой, а провалом управления.
Урок для компаний: инвентаризация важнее презентаций
Для российских организаций история QTS полезна не географией, а логикой. Чем сложнее инфраструктура, тем опаснее слепые зоны. Это касается и собственных серверных, и аренды мощностей, и проектов с подрядчиками.
Нужно знать не только, где лежат данные, но и кто управляет площадкой, какие журналы ведутся, как проверяют доступы, какие датчики подключены к учётным системам и кто реагирует на отклонения. Если компания строит ИИ-сервис, использует локальные модели или хранит чувствительные данные, цена ошибки растёт. Об этом напоминают и технические инциденты вроде уязвимости Ollama, которая грозит утечкой ключей API и переписок.
Отдельный риск — удалённая работа с документами по инфраструктуре: схемами, договорами, актами доступа, инженерными планами. В публичных сетях лучше использовать сервис безопасного интернет-соединения, который помогает защитить соединение и приватность рабочих данных.
Что проверить уже сейчас
- Составьте список всех критичных подключений: электричество, вода, охлаждение, сеть, системы контроля доступа.
- Назначьте ответственных за каждую группу ресурсов и зафиксируйте это в документах, а не в устных договорённостях.
- Проверьте, кто из подрядчиков имеет доступ к площадке, учётным системам и инженерной документации.
- Настройте регулярную сверку показаний: счётчики, журналы доступа, сетевые подключения, заявки на работы.
- Введите правило: любое новое подключение или изменение схемы проходит проверку до начала эксплуатации.
- Разберите, кто увидит аномалию первым и как быстро команда должна на неё отреагировать.
- Храните инженерные документы и ключи доступа отдельно, с журналированием действий и резервными копиями.
- Проводите разборы не только киберинцидентов, но и сбоев физической инфраструктуры: они часто связаны одной цепочкой.
Комментарии (0)
Будьте уважительны. Спам и ссылки на сторонние сервисы скрываются модерацией.
Пока комментариев нет. Вы можете быть первым.