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

Выбор ЦОД или выбор админа схожи - вы или доверяете либо нет

Админ - это конкретный человек. Методы работы с конкретными человеками шлифуются шестое тысячелетие подряд.

А вот способов узнать, действительно ли в ЦОДе "АО АБВГД-Телеком" все устроено так радужно, как они рассказывают, человечество пока так и не придумало :)

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

При чем тут оценка рисков?

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

На мой взгляд, на это может быть только одна реакция:
- А, вы это свое "зашибись" чем можете подтвердить?

ФСТЭК это "чем можете подтвердить" еще и формализовала.

А при чем тут ЦОД, если мы говорим про безопасность системы?
Владельцы системы должны учитывать угрозы и оценивать риски (свои угрозы и свои риски) при выборе того или иного ЦОД.

В идеальном мире, в котором единороги какают радугой - безусловно. В реальном мире владельцы ЗОКИИ возмущаются "а с фига ли мы, медицина, должны заниматься безопасностью".

Поэтому им ставят заградительные требования: если вы используете услуги стороннего ЦОД, вы обязаны иметь на руках вот такие подтверждения добросовестного отношения этого ЦОД к безопасности.

Наверно я что-то упустил. Про какие требования речь? В 187 не видел такого

Отмотайте эту дискуссию вверх до 15:30 примерно

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

Эта бумажка становиться пустышкой сразу после выдачи. Аттестация облачного цода не имеет смысла в текущем виде.

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

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

То есть требований нет?
Ну кроме размещения средств в России.

Оценка риска очень индивидуальное занятие. Чем больше фактором учтешь тем лучше.

Более того, для 3 категории значимости такого требования ещё нет

Аттестация - это на 90% ритуальные танцы с бубном, которые от безопасности бесконечно далеки. Но в нее наконец добавили анализ уязвимостей, и "бумажка" отлично работает. Выглядит это примерно так (на опыте банков - они это уже второй год с ДБО проходят).

1. Отрасли ставят ограничение: если для софта не проводился анализ уязвимостей, использовать этот софт нельзя.

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

3. Все остальные начинают пинать вендоров: парни, нужна бумажка. Вендоры дружно их посылают, но одному приходит в голову интереса ради заказать анализ кода. Смотрит на результаты, грустнеет и ставит эту работу на поток.

4. Через год этому одному удается, наконец, устранить самые критические уязвимости, получить первую бумажку и использовать ее как конкурентное преимущество.

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

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

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

Почитайте п. 29.2 - 29.3.3. 239го приказа ФСТЭК. Выполнить их обязан ваш свечной заводик. Теряюсь в догадках, как вы сможете их выполнить, если не заставить из выполнить вашего поставщика услуг.

Поэтому "разместить ЗОКИИ в облаке можно, но выполнить при этом 239 приказ почти нереально"

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