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

Вот и я склоняюсь к этой точке зрения,  но есть и иные мнения исходя из понятия ИТКС,  которое определено в рамках подзаконных НМД в рамках 187-фз

Тут как раз нужен перечень по 127 , в нем вы пепечисляете все свои системы , которые относиться к кии по критерию кого что они есть и участвуют в ваших критических беихнес процессах с точки зрения области. Так же лично я рекомендую у казать все чужие системы котрые у вас есть и обязательно ответственных лиц от них, там есть такой столбец. Дальше отправляете перечень на согласование вышестоящий орган. После того как он вернется вам подписанный рассылаете письмо всем владельцам систем котрые у вас располагаются с просьбой во исполнение требований 187 фз сообщить вам категорию обьекта а так же , сообщить вам в письменном виде как будут выполнчться требования 235,239 приказов. Далее берете свой перечень с копией письма из вашего выщестоящего органа и отпровляете во ФСТЭК. На флешку можно приложить сканы писем котрые вы направили владельцам систем котрые паркуются у вас.

А что за письмо?

insoob_17_21.pdf

👆Информационное сообщение,  п. 6. - шедевральное разъяснение)

Сделайте для себя перечень таких систем, и для каждой системы укажите, на каком основании вы считаете, что она не принадлежит вам, и кому на самом деле она принадлежит.

Если окажется, что в перечне нет собственно ваших систем, отправлять его никуда не нужно. Составьте для себя акт о том, что рассмотрели вот такой перечень критических процессов и не выявили принадлежащих вам (!) систем, нарушение работы которых могло бы негативно повлиять на эти процессы. Перечень систем с указанием их фактических собственников приложите к нему.

В дальнейшем, если получите предписания провести категорирование, ответите на него копией этого акта.

А что не так? Там написано, что при выполнении требований ФСТЭК понятие "автоматизированная система" из ГОСТ должно считаться стнонимом "информационной системы" из ФЗ. И?

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

Шедевральна последняя строчка - о том,  что применение понятий не влияет на конечную цель.

Проблема в том, что каждый новый закон зачастую вводит новые определения,  которые не в полной мере вписываются в действующие НМД,  а подзаконные акты не разъясняют однозначно применимость новых терминов по отношению к действующим документам.
Ранее после выхода 152-фз - термин ИС; теперь, после выхода 187-фз и термин ИТКС, который (на моей практике) ранее в НМД ФСТЭК не встречался.

Разговор о ЕМИАС в Москве. По положению о системе оператором является ДИТ Москвы. Мы являемся пользователями, но наши данные хранятся на нашей территории. в этом случае стоит емиас вклюяать  в объекты КИИ

По моему это все только усложнит жизнь админу МО ( мед. учреждения). Если МО не является владельцем КИИ, о чем вообще идёт речь? Я прекрасно понимаю их региональный Минздрав или как у них там...Все хотят с себя свесить ответственность. Ведь специалистов и финансов нет ни у кого

Речь идет о том, что после 01.09.2019 (рекомендованный срок составления переченя объектов КИИ) в любой момент может прийти предписание ФСТЭК о необходимости исполнить требования ФЗ-187. Потому что субъект вроде как есть, а никаких телодвижений с его стороны не наблюдается.

Эту работу (посмотреть вокруг и убедиться, что своих объектов нет) парни все равно проделали, так что имеет смысл задокументировать ее результаты. Чтобы не готовить такую же бумагу в авральном порядке, если такое предписание действительно придет.

В разных регионах региональный сегмент ГИСЗ построен по разному, у нас все централизованно, данные  хранятся в одном месте и МО через доверенный канал получает к ним доступ по веб интерфейсу. У кого-то вся инфраструкту децентрализирована. Тоесть данные частично хранятся в каждом МО. Если в регионе выбран второй вариант - да, на мой взгляд МО однозначно субъект КИИ и является владельцем объекта КИИ. А если вариант централизованный - то попадает только местный МИАЦ или Минздрав (зависит от организации)

Если коллеги из ДИТ Минздрава РФ имеют другое мнение, пусть тут выскажутся

У нас вот тоже централизовано, и вроде бы МИАЦ субъект, но система хостится у РТК (облако) и как рализовать требования по ЗИ мне не понятно, ибо субъект не управляет безопаностью объекта. Все таки прихожу к мысли, что несмотря на мнения тут озвученные, при таких архитектурах, именно прикладное ПО будет являться объектом КИИ для МИАЦ и инфраструктура ЦОД объектом КИИ для хостера, в итоге два субъекта КИИ должны совместно управлять безопаностью своих объектов по принадлежности. Ну не может РТК отвечать за уявзимости ППО, равно как и МИАЦ за уязвимости ЦОД, нету логики в этом.

наш УФСБ на это бы ответил - вы владельцы ИС (КИИ) вы и отвечайте. А вообше, у нас также, ЦОД где располагаются сресдва, не наш. Стойка наша на праве аренды. Никто же не мешает вам поставить туда IDS, сопку, WAF и др. Внести изменения в соглашение с ртк о физ. доступе к оборудованию своему и все, отвечать только вам!

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

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

Опять же, это мнение мое..я никому его не навязываю

Я исхожу из расследования не дай бог инцидента безопаности. Хотсер должен отвечать за периметр и системные вещи, регион за приклад и субд (всякие sql инъекции, права доступа и прочее).