Comments 9
Появилось пару вопросов:
1) При разворачивании виртуальных серверов под заказчика на них предустанавливаются сертифицированные СЗИ, всякие там секретнеты и т.д.?
2) На первой схеме не совсем понятно что отводится под ИС заказчика, сегмент с права что выделен пунктиром?
3) Виртуальные межсетевые экраны имеют сертификаты (Тип «Б» вроде)?
1) При разворачивании виртуальных серверов под заказчика на них предустанавливаются сертифицированные СЗИ, всякие там секретнеты и т.д.?
2) На первой схеме не совсем понятно что отводится под ИС заказчика, сегмент с права что выделен пунктиром?
3) Виртуальные межсетевые экраны имеют сертификаты (Тип «Б» вроде)?
1) При разворачивании виртуальных серверов под заказчика на них предустанавливаются сертифицированные СЗИ, всякие там секретнеты и т.д.?
Нет. Клиент получает набор виртуального железа (vCPU, vRAM, SSD, HDD и т.п.). Он сам решает, какие ОС и СЗИ в них ему использовать. ИС клиента — это его зона ответственности. Мы как провайдер ему можем только советовать и рекомендовать, но решать, что и как, — вопрос клиента.
2) На первой схеме не совсем понятно, что отводится под ИС заказчика, сегмент справа, что выделен пунктиром?
Да, клиент получает тенант (сегмент) внутри Облака.
3) Виртуальные межсетевые экраны имеют сертификаты (Тип «Б» вроде)?
МСЭ типа «А» — это МСЭ, применяемый на физической границе (периметре) информационной системы или между физическими границами сегментов информационной системы. Именно такое сертифицированное решение применяется для защиты всего Облака. МСЭ типа «Б» — это МСЭ, применяемый на логической границе (периметре) информационной системы или между логическими границами сегментов информационной системы.
Нет. Клиент получает набор виртуального железа (vCPU, vRAM, SSD, HDD и т.п.). Он сам решает, какие ОС и СЗИ в них ему использовать. ИС клиента — это его зона ответственности. Мы как провайдер ему можем только советовать и рекомендовать, но решать, что и как, — вопрос клиента.
2) На первой схеме не совсем понятно, что отводится под ИС заказчика, сегмент справа, что выделен пунктиром?
Да, клиент получает тенант (сегмент) внутри Облака.
3) Виртуальные межсетевые экраны имеют сертификаты (Тип «Б» вроде)?
МСЭ типа «А» — это МСЭ, применяемый на физической границе (периметре) информационной системы или между физическими границами сегментов информационной системы. Именно такое сертифицированное решение применяется для защиты всего Облака. МСЭ типа «Б» — это МСЭ, применяемый на логической границе (периметре) информационной системы или между логическими границами сегментов информационной системы.
Извиняюсь может я что то упустил, получается два виртуальных сегмента внутри облака, двух разных Клиентов, разделяются Физическим МСЭ?
В текущем материале эта тема не раскрыта. Я обсудил это на вебинаре, можно посмотреть запись. Если говорить кратко, то каждый клиент «ИТ-ГРАД» и #CloudMTS в аттестованном Облаке получает некоторую виртуальную серверную (сегмент или тенант) с набором виртуального железа (vCPU, vRAM, SSD, HDD) и виртуальным маршрутизатором. Для доступа в нее — один или несколько белых IP. Белые IP находятся на сертифицированном МСЭ (программно-аппаратное решение). Трафик с белых IP натируется на виртуальный маршрутизатор в тенанте клиента. Да, если два клиента одного такого аттестованного Облака захотят обменяться трафиком, то это возможно сделать только через внешний МСЭ. Настройками фильтрации на своих белых IP клиенты управляют по заявкам в ТП. В своем тенате на виртуальном маршрутизаторе можно настроить многое клиенту самому (за рядом исключений, например, L2 связь во внешний мир). Если клиенту нужно сделать какие-то сложные сетевые вещи, можно поставить VM с маршрутизатором/FW Cisco и т.п., а если сертифицированный крипто-туннель до его другой локации – VM с криптошлюзом С-Терра. В общем вариантов много ;)
Я не могу ничего сказать по поводу рекламной части статьи, но вот во вводной части однозначно присутствуют косяки, как минимум вводящие в заблуждение. Например:
А вот, что говорит закон:
Т.е. вот как раз первоначальный сбор можно производить на зарубежном сервере, объяснив это тем, что этот сервер работает исключительно как промежуточное звено при получении данных и сразу передает эти данные в базу в России. А актуальная база лежит именно на территории РФ. Например, интернет-магазин лежит на сервере в Германии, заказ падает сразу во внутреннюю базу, находящуюся в России и люди работают с локальной базой в России (т.е. подтверждают заказ, вносят уточнения в адрес доставки и т.п.) — вот это законно. Т.е. как раз где идет «первоначальный сбор» (такого понятия в законодательстве вообще нет) — это никого не интересует.
Намного интереснее бы было посмотреть экономику рекламируемого предложения. По опыту моего общения с РКН они почти ничего не имеют права проверить и ответственность для организации наступает только в случае утечки, причем сумма ответственности (исключаю вариант гражданских исков от субъектов) там просто несравнимо ниже, чем обращение к консультантам по внедрению решений по работе с ПД и уж тем более чем сумма рекомендуемых решений.
Агентство имеет право хранить эти данные и не в России, однако первоначальный сбор, согласно нашему законодательству, необходимо выполнять на территории РФ.… выполняете с ними какие-то иные операции — все это можно делать и на западных ресурсах. Ключевой момент с точки зрения законодательства — где происходит сбор ПДн. Поэтому важно не путать первоначальный сбор и обработку.
А вот, что говорит закон:
8. Невыполнение оператором при сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети «Интернет», предусмотренной законодательством Российской Федерации в области персональных данных обязанности по обеспечению записи, систематизации, накопления, хранения, уточнения (обновления, изменения) или извлечения персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, —
Т.е. вот как раз первоначальный сбор можно производить на зарубежном сервере, объяснив это тем, что этот сервер работает исключительно как промежуточное звено при получении данных и сразу передает эти данные в базу в России. А актуальная база лежит именно на территории РФ. Например, интернет-магазин лежит на сервере в Германии, заказ падает сразу во внутреннюю базу, находящуюся в России и люди работают с локальной базой в России (т.е. подтверждают заказ, вносят уточнения в адрес доставки и т.п.) — вот это законно. Т.е. как раз где идет «первоначальный сбор» (такого понятия в законодательстве вообще нет) — это никого не интересует.
Намного интереснее бы было посмотреть экономику рекламируемого предложения. По опыту моего общения с РКН они почти ничего не имеют права проверить и ответственность для организации наступает только в случае утечки, причем сумма ответственности (исключаю вариант гражданских исков от субъектов) там просто несравнимо ниже, чем обращение к консультантам по внедрению решений по работе с ПД и уж тем более чем сумма рекомендуемых решений.
Добрый день. В разделе с примером про «Рекламное агенство» вы пишете, что можно хранить данные на зарубежных облаках если первоначальный сбор выполняется на территории РФ. В разъяснениях Минцфиры digital.gov.ru/ru/personaldata/#1438174494141 в разделе «Трансграничность» (5-й вопрос) написано, что понятия «первичный сбор» не существует и, как следствие, сбор, обработка и хранение должны выполняться в базах данных, расположенных на территории РФ. Получается, что передавать за границу можно только обезличенные данные, либо передавать, обрабатывать, но не хранить (приложение в зарубежном облаке, СУБД с данным в РФ). Можете поделиться ссылкой на норму, которая позволяет утверждать, что допускается передача ПДн для хранения и обработки в зарубежных облаках которая подтверждает валидность вашего примера с агентством?
Вы правы. В примере про агентство говорится, что клиент планирует рассчитывать статистику. Речь не идет о создании или хранении всей базы и т.п. Вы правильно пишете, что передавать за границу можно только обезличенные данные, либо передавать, обрабатывать. В примере, вероятно, нечетко прописана цель передачи – обработка данных (расчёт статистики). Пример как раз приведен для того, чтобы показать, как клиенту трудно разобраться в деталях и корректно описать свою ИСПДн, да так, чтобы самого себя не “подвести”. Спасибо, что отметили этот момент.
Спасибо за материал! По поводу адреса ЦОД, кнчн, перегиб. Так можно и дальше влезать в тонкости провайдера. Отношения пусть регулируются соглашением. А те компании, которые до сих пор боятся, будут платить избыточные стоимости за свою инфраструктуру и постепенно станут неконкурентными. Ну и в целом все сказанное справедливо для всех данных, не только ПНд.
Ещё в кассу мифа, про "доступ сотрудников провайдера": исторически на рынке ИТ закупается огромная часть услуг по сопровождению той или иной инфраструктуры или ИС. В этом случае партнер также получает полный доступ к сопровождаемой части. Но компании слепо верят, что утечка по этому риску невозможна. И при переходе в облако провайдер сразу начнет данные перепродавать. Миф, верно.
Рынок облаков в мире (2019) по данным cnews $286 млрд. Именно по этой причине облачные провайдеры, как хорошо написано в статье, также будут "рьяно защищать данные своих клиентов, на которых держится в том числе и его бизнес.". А "утащить" данные из периметра компании зачастую проще значительно — достаточно замотивировать низкооплачиваемого ИТ-администратора.
Рад, что вам материал понравился. Соглашусь, что многие из мифов справедливы для всех ИС с любыми данными, а не только ПНд. Но, с другой стороны, очень мало компаний вывешивают на сайт в публичный доступ аттестаты на свои Облака. Демонстрация первой страницы аттестата вообще клиенту мало что говорит. При этом могут написать, что все Облака аттестованы по уровню УЗ-1/K1. Клиенты часто не в теме деталей и считают, что чем выше уровень или класс защиты, тем лучше. Хотя для 90% наших клиентов УЗ-3 — это необходимо и достаточно, а на что-то большее лучше не смотреть в силу дополнительных обременений. Другие провайдеры играют с «оценкой эффективности» и подменяют ей аттестат. Хотя сами понимают, что аттестат и оценка эффективности – совсем разные вещи, особенно в случае, если клиент предполагает в дальнейшем пройти аттестацию своей ИСПДн.
Sign up to leave a comment.
IaaS 152-ФЗ: итак, вам нужна безопасность