Post #169
145
Forwarded from Пост Лукацкого
У одного провайдера ЦОДов ночью произошел инцидент, приведший к тому, что провайдер отключил целую зону от сети и остановил системы, а также приостановил доступ клиентов к управляющим консолям других регионов. Можно было бы подумать, что я снова о Яндексе, но нет. 7 октября облачный провайдер IDC Frontier, входящий в SoftBank Group, сообщил о несанкционированном доступе к инфраструктуре IDCF Cloud – ransomware-атака затронула 495 компаний и государственных организаций.
Например, Nissui Logistics, логистическая компания группы Nissui, 7 октября сообщила, что из-за сбоя у внешнего провайдера инфраструктуры (IDC Frontier не названа, но как бы да) не может выполнять приемку и отгрузку товаров. Другая японская компания, Six Apart, опубликовала отчет о влиянии этого инцидента на свою облачную версию Movable Type. У нее пострадал 31 сервер в регионе IDC Frontier, на которых стали недоступны административные интерфейсы и опубликованные сайты. А затем появилось интересное сообщение:
Six Apart начала переносить пострадавшие системы в другое облако. Она смогла это сделать, так как для всех серверов облачной версии Movable Type она хранит семь поколений ежедневных резервных копий в Google Cloud – на инфраструктуре, независимой от IDC Frontier. То есть производственная инфраструктура, хранилище резервных копий и новая площадка восстановления находятся у разных облачных провайдеров.
Вот такая история. Две совершенно разных причины выхода из строя двух провайдеров ЦОДов, но для бизнеса результат один; и для многих он из разряда недопустимых. Кстати IDCF тоже отключил весь регион. А теперь, внимание, вопрос, точнее четыре:
6️⃣ Какая доля ваших критичных бизнес-процессов может одновременно остановиться из-за одного решения стороннего облачного провайдера?
2️⃣ Если завтра провайдер скажет, что ваши виртуальные машины у него больше не восстановить, сможете ли вы развернуть их у другого поставщика, используя только собственные копии и документацию?
3️⃣ Есть ли у вас право, компетенции, инструменты и доступ к данным, чтобы сделать это без участия скомпрометированного провайдера?
4️⃣ Готовы ли обосновать своему CFO необходимость заплатить отдельные деньги за резервирование в ЦОДе, провайдер которого заверяет о своей отказоустойчивости (у Яндекса, например, резервирование надо настраивать отдельно, заплатив за это сверх стандартной оплаты)?
ЗЫ. Если вы думаете, что это не про кибербезопасность, то подумайте еще раз. Кому думать лень, то вот вам сообщение от ГК Астрал – перестали работать некоторые сервисы удостоверяющего центра из-за проблем в ЦОДе Яндекса и документы не подписываются электронной подписью.
#инцидент #недопустимое #resilience #ransomware
株式会社IDCフロンティア 【第2報】当社サービスの一部システムに対する不正アクセスについて | IDCフロンティア IDCフロンティアより、プレスリリース、トピックス・ニュースリリース、メディア・ブログ、イベント・セミナーなどのご紹介です。 Например, Nissui Logistics, логистическая компания группы Nissui, 7 октября сообщила, что из-за сбоя у внешнего провайдера инфраструктуры (IDC Frontier не названа, но как бы да) не может выполнять приемку и отгрузку товаров. Другая японская компания, Six Apart, опубликовала отчет о влиянии этого инцидента на свою облачную версию Movable Type. У нее пострадал 31 сервер в регионе IDC Frontier, на которых стали недоступны административные интерфейсы и опубликованные сайты. А затем появилось интересное сообщение:
Восстановить эти 31 сервер непосредственно в IDCF Cloud уже не представляется возможным.
Six Apart начала переносить пострадавшие системы в другое облако. Она смогла это сделать, так как для всех серверов облачной версии Movable Type она хранит семь поколений ежедневных резервных копий в Google Cloud – на инфраструктуре, независимой от IDC Frontier. То есть производственная инфраструктура, хранилище резервных копий и новая площадка восстановления находятся у разных облачных провайдеров.
Вот такая история. Две совершенно разных причины выхода из строя двух провайдеров ЦОДов, но для бизнеса результат один; и для многих он из разряда недопустимых. Кстати IDCF тоже отключил весь регион. А теперь, внимание, вопрос, точнее четыре:
6️⃣ Какая доля ваших критичных бизнес-процессов может одновременно остановиться из-за одного решения стороннего облачного провайдера?
2️⃣ Если завтра провайдер скажет, что ваши виртуальные машины у него больше не восстановить, сможете ли вы развернуть их у другого поставщика, используя только собственные копии и документацию?
3️⃣ Есть ли у вас право, компетенции, инструменты и доступ к данным, чтобы сделать это без участия скомпрометированного провайдера?
4️⃣ Готовы ли обосновать своему CFO необходимость заплатить отдельные деньги за резервирование в ЦОДе, провайдер которого заверяет о своей отказоустойчивости (у Яндекса, например, резервирование надо настраивать отдельно, заплатив за это сверх стандартной оплаты)?
ЗЫ. Если вы думаете, что это не про кибербезопасность, то подумайте еще раз. Кому думать лень, то вот вам сообщение от ГК Астрал – перестали работать некоторые сервисы удостоверяющего центра из-за проблем в ЦОДе Яндекса и документы не подписываются электронной подписью.
#инцидент #недопустимое #resilience #ransomware
- 👍 3
- 🔥 1
