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

Подскажите пожалуйста, где можно взять шаблоны какие нибудь или готовые , такие вот документы

Не мудрствуя лукаво Яндекс рулит...

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

"По общему правилу, можно все, что не запрещено. Размещать компоненты ЗОКИИ в облаке не запрещено - такого запрета нет ни в ФЗ, ни в подзаконных актах.

А дальше нюансы:
1. Компоненты ЗОКИИ 1й категории запрещено размещать за рубежом (а значит, и в трансграничном облаке) - п. 31 новой редакции приказа 239.
2. За реализацию мер защиты, направленных против угроз со стороны облака, отвечает все равно владелец ЗОКИИ. Если меры защиты реализуются на уровне облака - он должен провести испытания, подтверждающие реализацию этих мер защиты. И объем этих испытаний должен соответствовать объему сертификационных испытаний (с анализом исходных кодов и т. п. - фишка, привнесенная новой редакцией приказа 239).

Так что утверждение "размещать запрещено" - неправда. Но выполнить при этом требования 239 приказа... Теоретически можно, но на практике нереально."

Может в региональное управление и задать вопрос? Только в данном случае стоимость обеспечения всех мер ЗОКИИ будет явно превышать аналогичную стоимость если данное оборудование будет размещено локально, как мне кажется.

То же самое и про утверждение, что нельзя привлекать стороннюю организацию для помощи в категорировании.
Формально не запрещено. Значит можно привлечь внешних аудиторов, которые могут описать процессы, объекты и выдать рекомендации, в том числе основываясь на опыте

ФСТЭК, особенно региональный, ничего, кроме "не запрещено" не ответит. Но позиция центрального аппарата есть в проекте методики моделирования угроз:
1. Если компоненты ЗОКИИ размещены в стороннем ЦОД, при моделировании угроз нужно учитывать угрозы инфраструктуре этого ЦОД.
2. Частную модель угроз инфраструктуре ЦОД нужно запросить у оператора ЦОД.
3. Если оператор ЦОД нужную информацию не дает, использовать такой ЦОД не рекомендуется.

На "не рекомендуется" обращаю внимание: для запрета ФСТЭК у себя полномочий не видит, может только рекомендовать.

На фоне активизации коммерческих структур по предложениям в области 187-фз есть "облака" которые могут взять на себя такую ответственность с решением инфраструктурных вопросов подключения заказчика хотя бы по 3 категории? Что-то не попадались на глаза.

Фстэк и РКН специфику облаков не сильно понимают и учитывают. Хорошо хоть традиционный ЦОД учитывают

Не могут. Отвечает все равно субъект КИИ

А в чем там специфика? :)

в постоянной изменчивости ит-ландшафта

И в чем тут специфика? :)

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

С учетом этого нюансах с точки зрения защиты никакой разницы между облаком и системой ЦОД с виртуализацией нет никакой разницв

Речь про выполнение требований регуляторов, а не про реальную защиту

Построить систему защиты для ЦОД (для облака) не проблема. А вот как все подогнать под требования нормативки и потом с этим жить - вопросы есть (

Ну то есть регуляторы должны были выпустить для облаков специальные требования "для выполнения требований регуляторов"? :)

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

Давайте использовать точные формулировки: "для своего ЦОД (облака)".

А вот когда облако чужое, то какие у клиента основания считать, что владелец ЦОД хоть что-то смыслит в безопасности? Буклетики красивые и периодически вывозит заказчиков на конференции побухать за безопасность - так себе основания :)

)) все зависит от уровня доверия, а не от модели угроз ЦОД, сертификата или лицензии.
Если я потребляю услугу IaaS ЦОД мне должен обеспечить определенный SLA по доступности, моя же задача минимизировать риски, связанные с НСД со стороны ЦОД, это вполне можно сделать внутри системы, заложив для нее определенные угрозы.

Минимизировать риски со стороны человека, который контролирует гипервизор? А мсье знает толк в извращениях :)

Вы правы в том, что это - вопрос уровня доверия. И это доверие должно чем-то обеспечиваться.