Не только статья 272, но и 274.1. Можно посмотреть на этот счет накопленную судебную практику, интересные прецеденты уже были. Вот пример из блога моего коллеги, Валерия Комарова: valerykomarov.blogspot.com/2020/11/2741.html
Если коротко — сотрудник сдавал экзамен для допуска к выезду и решил воспользоваться программой для обхода системы тестирования. Использование такой программы приравняли к «использованию компьютерных программ либо иной компьютерной информации, заведомо предназначенных для неправомерного воздействия на критическую информационную инфраструктуру Российской Федерации».
Так что, к сожалению, закон в этом случае может сработать, если применить аналогичную аргументацию. Но надеюсь, что предупрежден — значит вооружен, и автора это не коснется.
Мы сервис-провайдер, level1, в области сертификации IaaS Cloud-152 и colocation. Версия стандарта 3.2.1, сертификацию проводит независимый QSA ежегодно и ASV ежеквартально.
Не видел ни разу обоснования настройки FW на основании МУ. Скорее видел, что в МУ определяется необходимость сертифицированного FW, поэтому в результате появляется отечественный на периметре, пропускающий все на следующий несертифицированный, на котором все правила фильтрации и осуществляются. Подход с МУ нормальный, но такого не встречал просто на практике.
Я бы предложил уточнить следующее:
1. Подход большинства ИТшников, утрирую, – «открыть все, лишь бы работало», у ИБшников – «закрыть все и открывать по запросу». Если бы Регулятор определил подход, меньше вопросов было бы при настройке FW в ИСПДн.
2. Обоснование правил настройки нужно документировать, это было бы полезно и проверяющим.
3. Глубину хранения логов FW тоже не мешало бы определить, это позволило бы более верно модели FW подбирать и обеспечивать расследование инцидентов в случае необходимости. Тут ведь есть срок исковой давности 3 года, есть лучшие практики 90 дней, есть размер диска, и т.д.
4. Не все обязательно нужно через FW пускать, бэкапы внутри корп.сети (разные сегменты) избыточно через FW запускать в ряде случаев. УПД.3 исключений не предусматривает.
Да, можно и на 5 лет у кого-то, наверно, получить аттестат, ФСТЭК допускает. Но вот у нас аттестат свежий от 26.04.2019 г., ООО «НАЦ» выдали на 3 года.
Конечная организация говорит своему аудитору по PCI DSS, что ИС расположена в облаке таком-то, показывает Договор с провайдером. Аудитор запрашивает сертификат по PCI DSS на облако и документ AoC – Attestation of Compliance, в котором указано кто и когда проводил сертификацию облака по PCI DSS, какой версии стандарта, что входит в область сертификации. Если все ок, то аудитор не проверяет облако (оно уже проверено другим аккредитованным аудитором по PCI DSS), проверяет только ИС. Область сертификации очень важна, так как бывает только co-location входит, тогда к среде виртуализации, сети, хранилищам и т.д. доверия у аудитора быть не может и тут несколько вариантов исхода. У нас, например, в область сертификации входят (как в AoC напишу):
— infrastructure/network
— physical space (co-location)
— storage
— shared hosting provider
— other hosting (specify).
Cloud-152 у нас находится в ЦОД NORD-1, а сертификат co-location покрывает все наши ЦОД, в любом можно разместить оборудование и будет на уровне ЦОД обеспечено соответствие PCI DSS, а вот облако только в NORD-1 и только Cloud-152.
На нашей IaaS-платформе размещаются банковские системы, разные порталы с оплатой, программы лояльности и т.д., в общем на ней могут быть размещены ИС, требующие обеспечения соответствия PCI DSS. Да, к IaaS требований меньше, чем к самой ИС, но сильно больше, чем к ЦОД (по сути: СКУД, видео, охрана), например, при colocation.
В качестве примера могу назвать добровольную сертификацию ГОСТ Р, можно оценить соответствие ТУ (самое главное), ГОСТ 19781, ГОСТ 28195, ГОСТ Р ИСО/МЭК 9126, ГОСТ Р ИСО/МЭК 15408 1,2,3 и т.д.
Знаю про компании среди наших клиентов, которые пошли таким путем, но о факте проведения проверок и успешности их прохождения не знаю (они нам не докладывают:)). Эти компании продолжают присутствовать на рынке и быть нашими клиентами, поэтому верю, что все хорошо).
Вам явно есть, что сказать. Напишите статью, это будет полезно для людей).
Цель 152-ФЗ – защитить персональные данные граждан, а не обобрать российский бизнес. Я ничего не имею против СЗИ от НСД, прошедших контроль НДВ, но давайте все же применять их там, где это действительно нужно, т.е. в ГИС, КИИ (не всех), ГТ. Какой-нибудь ИП Иванов и так с трудом платит налоги, оплачивает лицензии ОС и прикладного софта, не стоит доводить его бизнес до банкротства во имя 152-ФЗ. А еще я верю в то, что регуляторы написали свои документы (а точнее внесли позже в них правки), чтобы сделать требования хоть как-то выполнимыми.
И про СКЗИ чуть-чуть: AES ничуть не хуже ГОСТ, а западные вендоры давно умеют ускорять работу крипты. Если канал 10 Гб/с, и по нему передаются ПДн, то наличие AES всяко лучше, чем ничего. Отечественные СКЗИ очень дорогие, за них заплатит – конечный потребитель услуг. Если по каналам связи передается гостайна, то защита отечественными криптоалгоритмами оправдана.
РКН ходит планово и по жалобам. Если Вася Пупкин оскорблен и напишет жалобу в РКН, то возможно они и отреагируют. Только вряд ли назовут владельца забора Оператором и наложат штраф. Скорее ответят сухим бюрократическим языком Васе о том, куда ему отправиться с жалобой).
Если просто будете использовать, но не разработаете Модель Угроз и Нарушителя, не создадите документацию, подтверждающую разумность и достаточность вашего выбора мер защиты, то да, будут придирки и штрафы. В первую очередь проверяют документы. Ни РКН, ни ФСТЭК, ни ФСБ не будут проводить pentest в отношении вашей системы защиты, это ваша обязанность. Опять же, есть компенсирующие меры в п.10 Приказа ФСТЭК №21, не забывайте и о них — SDLC, pentest.
Регуляторы – это РКН, ФСТЭК и ФСБ (МВД, Прокуратура и т.д. не рассматриваем). Системы сертификации есть у ФСТЭК и ФСБ, требования про применение сертифицированных СЗИ и СКЗИ (если нужны именно они) как раз в приказах ФСТЭК и ФСБ. Если у вас ГИС, КИИ, ГТ, то да, нужны будут сертифицированные СЗИ. Для коммерческих компаний можно использовать и несертифицированные.
Важно не просто использовать, а иметь внутри организации документы о том, что вы осознанно выбрали эти СЗИ и/или встроенный функционал, провели его испытания (ПМИ по сути нужно) и пришли к выводу о том, что его достаточно для нейтрализации актуальных угроз, описанных в МУ. Так вы обеспечите выполнение требований 152-ФЗ и 1119-ПП в части «оценки соответствия».
То есть вы не просто берете несертифицированные СЗИ и используйте их. Нет. Нужно обязательно провести работу для выполнения требований п.2 ст.19 152-ФЗ и пп. «г» п.13 1119-ПП.
Если делать аттестацию, то нужен «Технический паспорт».
«Описание ИСПДн» по сути это вступительная часть документа «Модель угроз», ведь угрозы нужно моделировать в отношении понятной ИС. Либо, если подразумевается описание бизнес-процессов, то консультанты часто делают документ «Отчет об анализе» или схожее название, в котором описывают процесс получения ПДн, обработки, уничтожения.
Маловато информации, чтобы делать выводы и давать рекомендации, но скорее всего танцы с бубном будут нелишними.
ПДн – это любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных). У вас получается нет цели определения субъекта, они сами вам все загружают, по собственному желанию.
Сделайте политику на сайт, распишите там все по полочкам, что грузить, а что нет, укажите как обрабатывается (где хранится и сколько) информация, зачем она нужна (как раз, что она не нужна), как защищаете (что https, например) и т. д. и сделайте галочку «Согласен на обработку персональных данных».
Может быть такая ситуация, что загрузят фото и информацию о другом человеке, он это обнаружит и пожалуется в РКН. Придется с ними разбираться, и лучше подготовиться.
PS: промахнулся — это ответ к предыдущему комментарию)
Четкого списка нет. Компании, работающие с ПДн, создают и инструкции, и регламенты, и политики. В 152-ФЗ, ПП-1119, 21 Приказе ФСТЭК, 378 Приказе ФСБ есть намеки на то, что должно быть. Будете вы прописывать все в одном документе под названием “Регламент” или разобьете на кучу инструкций, решать вам.
Можно пойти от ответственности: если за это есть ответственность, значит нужно под это разработать отдельный документ. Как он будет называться, дело ваше.
valerykomarov.blogspot.com/2020/11/2741.html
Если коротко — сотрудник сдавал экзамен для допуска к выезду и решил воспользоваться программой для обхода системы тестирования. Использование такой программы приравняли к «использованию компьютерных программ либо иной компьютерной информации, заведомо предназначенных для неправомерного воздействия на критическую информационную инфраструктуру Российской Федерации».
Так что, к сожалению, закон в этом случае может сработать, если применить аналогичную аргументацию. Но надеюсь, что предупрежден — значит вооружен, и автора это не коснется.
Я бы предложил уточнить следующее:
1. Подход большинства ИТшников, утрирую, – «открыть все, лишь бы работало», у ИБшников – «закрыть все и открывать по запросу». Если бы Регулятор определил подход, меньше вопросов было бы при настройке FW в ИСПДн.
2. Обоснование правил настройки нужно документировать, это было бы полезно и проверяющим.
3. Глубину хранения логов FW тоже не мешало бы определить, это позволило бы более верно модели FW подбирать и обеспечивать расследование инцидентов в случае необходимости. Тут ведь есть срок исковой давности 3 года, есть лучшие практики 90 дней, есть размер диска, и т.д.
4. Не все обязательно нужно через FW пускать, бэкапы внутри корп.сети (разные сегменты) избыточно через FW запускать в ряде случаев. УПД.3 исключений не предусматривает.
— infrastructure/network
— physical space (co-location)
— storage
— shared hosting provider
— other hosting (specify).
Cloud-152 у нас находится в ЦОД NORD-1, а сертификат co-location покрывает все наши ЦОД, в любом можно разместить оборудование и будет на уровне ЦОД обеспечено соответствие PCI DSS, а вот облако только в NORD-1 и только Cloud-152.
Цель 152-ФЗ – защитить персональные данные граждан, а не обобрать российский бизнес. Я ничего не имею против СЗИ от НСД, прошедших контроль НДВ, но давайте все же применять их там, где это действительно нужно, т.е. в ГИС, КИИ (не всех), ГТ. Какой-нибудь ИП Иванов и так с трудом платит налоги, оплачивает лицензии ОС и прикладного софта, не стоит доводить его бизнес до банкротства во имя 152-ФЗ. А еще я верю в то, что регуляторы написали свои документы (а точнее внесли позже в них правки), чтобы сделать требования хоть как-то выполнимыми.
И про СКЗИ чуть-чуть: AES ничуть не хуже ГОСТ, а западные вендоры давно умеют ускорять работу крипты. Если канал 10 Гб/с, и по нему передаются ПДн, то наличие AES всяко лучше, чем ничего. Отечественные СКЗИ очень дорогие, за них заплатит – конечный потребитель услуг. Если по каналам связи передается гостайна, то защита отечественными криптоалгоритмами оправдана.
Важно не просто использовать, а иметь внутри организации документы о том, что вы осознанно выбрали эти СЗИ и/или встроенный функционал, провели его испытания (ПМИ по сути нужно) и пришли к выводу о том, что его достаточно для нейтрализации актуальных угроз, описанных в МУ. Так вы обеспечите выполнение требований 152-ФЗ и 1119-ПП в части «оценки соответствия».
То есть вы не просто берете несертифицированные СЗИ и используйте их. Нет. Нужно обязательно провести работу для выполнения требований п.2 ст.19 152-ФЗ и пп. «г» п.13 1119-ПП.
«Описание ИСПДн» по сути это вступительная часть документа «Модель угроз», ведь угрозы нужно моделировать в отношении понятной ИС. Либо, если подразумевается описание бизнес-процессов, то консультанты часто делают документ «Отчет об анализе» или схожее название, в котором описывают процесс получения ПДн, обработки, уничтожения.
ПДн – это любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных). У вас получается нет цели определения субъекта, они сами вам все загружают, по собственному желанию.
Сделайте политику на сайт, распишите там все по полочкам, что грузить, а что нет, укажите как обрабатывается (где хранится и сколько) информация, зачем она нужна (как раз, что она не нужна), как защищаете (что https, например) и т. д. и сделайте галочку «Согласен на обработку персональных данных».
Может быть такая ситуация, что загрузят фото и информацию о другом человеке, он это обнаружит и пожалуется в РКН. Придется с ними разбираться, и лучше подготовиться.
PS: промахнулся — это ответ к предыдущему комментарию)
Можно пойти от ответственности: если за это есть ответственность, значит нужно под это разработать отдельный документ. Как он будет называться, дело ваше.