Архив метки: БПЛА

И что, теперь будут строить дата-центры внутри гор, чтобы их и ядерный взрыв не достал?

И что, теперь будут строить дата-центры внутри гор, чтобы их и ядерный взрыв не достал?

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

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

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

А вот те дата-центры, какие мы видим сейчас у крупных компаний, - по сути, незащищённые ангары по всем известным адресам, - перестанут считаться top-notch top-tier мегаЦОДами. Потому что здания, в которых они размещаются, сейчас вовсе не выглядят как объекты КИИ. Они скорее напоминают шведские магазины дешёвой мебели и фрикаделек с брусничным соусом. 😏 И отношение к таким дата-центрам будет примерно таким же, как отношение к Hetzner (немецкая компания, предоставляющая услуги хостинга на десктопном железе). Да, очень дёшево, но абсолютно несерьёзно. Использовать такое стоит только для чего-то некритичного, понимая, что в любой момент этот хостинг может отъехать навсегда, а данные будут безвозвратно потеряны. 🤷‍♂️

Бизнес не способен формулировать требования безопасности: ни физической, ни информационной

Бизнес не способен формулировать требования безопасности: ни физической, ни информационной

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

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

А можно ли строить дата-центры так, чтобы прилёты им были не страшны? Глядя на советскую инфраструктуру - конечно, можно. Можно заглублять объекты под землю, можно строить над ними капитальные защитные сооружения. Только на это бизнес отвечает: "Можно. А зачем?" Всё это увеличивает стоимость строительства. Бизнес считает деньги и задаёт закономерный с его точки зрения вопрос: "Как эти капитальные затраты будут окупаться?"

И здесь можно провести параллель с управлением уязвимостями информационной инфраструктуры. Отсутствие физической защиты, рассчитанной на то, что при прилёте в здание объект должен продолжать работу, - это ведь тоже уязвимость (экспозиция). Риски, связанные с ней, менеджмент бизнеса считает маловероятными и принимает решение ничего не делать. А когда риск реализуется, всё, что может сделать менеджмент, - это развести руками и сказать: "Ой, а мы что-то на это не закладывались". А почему вы не закладывались? Разве не было очевидно, что если не заниматься физической защитой объектов, то при прилёте дата-центры будут выходить из строя, а это нанесёт ощутимый ущерб организациям по всей стране?

Точно так же и с IT-шными уязвимостями. Вместо того чтобы устранять их в соответствии с рекомендациями того же ФСТЭК, менеджмент организаций принимает риски, оставляя уязвимости в инфраструктуре. Расчёт на то, что ничего страшного не произойдёт, что риски эксплуатации уязвимостей никогда не реализуются. Но никто не владеет всей информацией и не может предсказывать будущее. Зачастую, когда эти риски реализуются, это приводит к катастрофическим последствиям.

Моё мнение: бизнес самостоятельно не может формулировать стандарты безопасности. Он всегда стремится в моменте максимизировать прибыль. А безопасность всегда стоит денег. Это касается и физической, и информационной безопасности. Если дать бизнесу возможность чего-то НЕ делать, бизнес и не будет этого делать. Все риски будут приниматься как маловероятные. А в случае крупного инцидента менеджмент будет разводить руками. В крайнем случае будут просто катапультироваться на другое тёплое место с "золотым парашютом". 😏

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

Напишу несколько слов по поводу атак вражеских беспилотников на дата-центры Яндекса

Напишу несколько слов по поводу атак вражеских беспилотников на дата-центры Яндекса

Напишу несколько слов по поводу атак вражеских беспилотников на дата-центры Яндекса. В ночь с 7 на 8 октября в результате атаки БПЛА был серьёзно повреждён дата-центр Яндекса в Сасово Рязанской области. Утром 9 октября атаке подвергся дата-центр Яндекса в Калуге, несколько модулей которого были выведены из строя. В ночь на 11 октября был атакован дата-центр Яндекса во Владимире, инфраструктура ЦОДа получила повреждения, его работа была полностью остановлена, а часть сервисов Яндекса стала недоступна пользователям. В такой ситуации я, как и всегда, на стороне пострадавшей российской компании. Считаю злорадство по этому поводу абсолютно неадекватным и неприемлемым.

Также не думаю, что эта история касается исключительно Яндекса. Другие дата-центры тоже могут стать целями атак. При выборе целей враги учитывают как потенциальный ущерб, так и общественный резонанс. Яндекс - одна из крупнейших технологических компаний России, объединяющая десятки сервисов для миллионов пользователей и бизнес-клиентов - от поиска, карт и такси до доставки, электронной коммерции и облачной инфраструктуры Yandex Cloud. По оценкам iKS-Consulting, Yandex Cloud входит в тройку крупнейших российских провайдеров облачной инфраструктуры IaaS и PaaS. Поэтому атаки на инфраструктуру Яндекса затрагивают не только пользователей его собственных сервисов, но и множество компаний, которые размещают в его облаке свои системы и данные.

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

Провайдерам услуг обработки данных следует:

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

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

🔹 Регулярно проверять готовность к полной потере ЦОДа: отрабатывать перенос нагрузки и восстановление сервисов в приемлемые сроки.

Потребителям услуг обработки данных следует:

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

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

🔸 Уточнить у провайдера сроки и условия восстановления после потери площадки.

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