company_banner

IaaS 152-ФЗ: итак, вам нужна безопасность

    Сколько бы ни разбирали мифы и легенды, которыми окружено соответствие 152-ФЗ, что-то всегда остается за кадром. Сегодня мы хотим обсудить не всегда очевидные нюансы, с которыми могут столкнуться как крупные компании, так и совсем небольшие предприятия:

    • тонкости классификации ПДн по категориям — когда небольшой интернет-магазин собирает данные, относящиеся к специальной категории, даже не зная об этом;

    • где можно хранить бэкапы собранных ПДн и производить над ними операции;

    • чем отличается аттестат и заключение о соответствии, какие вообще документы запрашивать у провайдера и все в таком духе.

    Напоследок мы поделимся с вами собственным опытом прохождения аттестации. Поехали!

    Экспертом в сегодняшней статье выступит Алексей Афанасьев, специалист по вопросам ИБ облачных провайдеров «ИТ-ГРАД» и #CloudМТS (входят в группу МТС).

    Тонкости классификации

    Мы часто сталкиваемся желанием клиента быстро, без аудита ИС определить требуемый уровень защищенности для ИСПДн. Некоторые материалы в интернете на эту тему создают ложное впечатление, что это простая задача и допустить ошибку достаточно сложно.

    Для определения УЗ необходимо понимать, какие данные будут собираться и обрабатываться ИС клиента. Иногда однозначно определить требования к защите и категорию ПДн, которыми оперирует бизнес, бывает непросто. Одни и те же типы персональных данных могут быть совершенно по-разному оценены и классифицированы. Поэтому в ряде случае мнение бизнеса может расходиться с мнением аудитора или даже проверяющего. Рассмотрим несколько примеров.

    Автопарк. Казалось бы, достаточно традиционный вид бизнеса. Многие автопарки работают десятилетиями, и их владельцы нанимают ИП, физлиц. Как правило, данные сотрудников подпадают под требования УЗ-4. Однако для работы с водителями необходимо не только собирать анкетные данные, но и производить медицинский контроль на территории автопарка перед выходом на смену, и собираемая в процессе информация сразу попадает в категорию медицинских данных – а это персональные данные специальной категории. Кроме того, автопарк может запрашивать справки, которые далее будут храниться в деле водителя. Скан такой справки в электронном виде — данные о состоянии здоровья, персональные данные специальной категории. Значит, УЗ-4 уже не обойтись, требуется минимум УЗ-3.

    Интернет-магазин. Казалось бы, собираемые имена, emailы и телефоны укладываются в общедоступную категорию. Однако, если ваши клиенты указывают гастрономические предпочтения, например, халяль или кошер, такая информация может быть расценена как данные о религиозной принадлежности и убеждениях. Поэтому при проверке или проведении других контрольных мероприятий проверяющий может отнести собираемые вами данные к специальной категории ПДн. Вот если бы интернет-магазин собирал информацию о том, предпочитает ли его покупатель мясо или рыбу, данные можно было бы отнести к категории иных ПДн. Кстати, а что делать с вегетарианцами? Ведь это тоже можно отнести к философским убеждениям, которые тоже относятся к спецкатегории. Но, с другой стороны, это может быть просто позицией человека, который исключил мясо из своего рациона. Увы, никакой таблички, которая однозначно определяла категорию ПДн в таких «тонких» ситуациях, нет.

    Рекламное агентство с помощью какого-либо западного облачного сервиса обрабатывает общедоступные данные своих клиентов — ФИО, адреса электронной почты и телефоны. Эти анкетные данные, конечно, относятся к ПДн. Возникает вопрос: легально проводить такую обработку? Можно ли вообще перемещать такие данные без обезличивания за пределы РФ, например, хранить бэкапы в каких-нибудь зарубежных облаках? Конечно, можно. Агентство имеет право хранить эти данные и не в России, однако первоначальный сбор, согласно нашему законодательству, необходимо выполнять на территории РФ. Если вы бэкапите такую информацию, рассчитываете на ее основе какую-то статистику, проводите исследования или выполняете с ними какие-то иные операции — все это можно делать и на западных ресурсах. Ключевой момент с точки зрения законодательства — где происходит сбор ПДн. Поэтому важно не путать первоначальный сбор и обработку.

    Как следует из этих коротких примеров, не всегда работа с ПДн однозначна и проста. Требуется не просто знать, что вы с ними работаете, но и уметь их правильно классифицировать, понимать, как работает ИС, чтобы правильно определить требуемый уровень защищенности. В некоторых случаях может стоять вопрос, какой объем ПДн реально необходим организации для работы. Возможно ли отказаться от наиболее «серьезных» или просто лишних данных? Кроме того, регулятор рекомендует обезличивать ПДн там, где это возможно. 

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

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

    Варианты построения ИСПДн

    Построение ИСПДн — не только технический, но и во многом юридический вопрос. ИТ-директор или директор по безопасности должен обязательно проконсультироваться с юристом. Поскольку в компании далеко не всегда есть специалист с нужным вам профилем, стоит посмотреть в сторону аудиторов-консалтеров. Многие скользкие моменты могут отнюдь не очевидны.

    Консультация позволит определить, с какими персональными данными вы имеете дело, какой уровень защищенности им требуется. Соответственно, вы получите представление об ИС, которую необходимо создать или дополнить средствами защиты и ОРД.

    Часто выбор для компании стоит из двух вариантов:

    1. Построить соответствующую ИС на своих программно-аппаратных решениях, возможно, в своей серверной.

    2. Обратиться к облачному провайдеру и выбрать эластичное решение, уже аттестованную такую «виртуальную серверную».

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

    • сложность масштабирования;

    • долгий срок реализации проекта: требуется выбрать, закупить, установить, настроить и описать систему;

    • масса «бумажной» работы, как пример — разработка полного пакета документации на всю ИСПДн.

    Кроме того, бизнес, как правило, разбирается только в «верхнем» уровне своей ИС — в используемых бизнес-приложениях. Иными словами, ИТ-персонал квалифицирован в своей узкой области. Отсутствует понимание того, как работают все «нижние уровни»: программно-аппаратные средства защиты, системы хранения, резервное копирование и, конечно, как с соблюдением всех требований настроить средства защиты, построить «железную» часть конфигурации. Важно понимать: это огромный пласт знаний, которые лежат за пределами бизнеса клиента. Именно тут и может пригодиться опыт облачного провайдера, предоставляющего аттестованную «виртуальную серверную».

    В свою очередь, облачные провайдеры обладают рядом преимуществ, которые, без преувеличения, способные закрыть 99% потребностей бизнеса в области защиты персональных данных:

    • капитальные затраты преобразуются в операционные;

    • провайдер со своей стороны гарантирует обеспечение необходимого уровня безопасности и доступности на базе проверенного типового решения;

    • нет необходимости содержать штат специалистов, которые будут обеспечивать работу ИСПДн на уровне «железа»;

    • провайдеры предлагают гораздо более гибкие и эластичные решения;

    • специалисты провайдера имеют все необходимые сертификаты;

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

    Старый миф о том, что размещать персональные данные в облаках нельзя, до сих пор необычайно популярен. Правдив он только отчасти: ПДн действительно нельзя размещать в первом попавшемся облаке. Требуется соблюдение некоторых технических мер, применение определенных сертифицированных решений. Если провайдер соответствует всем требованиям законодательства, риски, связанные с утечкой ПДн, сводятся к минимуму. У многих провайдеров есть отдельная инфраструктура для обработки ПДн в соответствии с 152-ФЗ. Однако к выбору поставщика тоже нужно подходить со знанием определенных критериев, их мы обязательно коснемся ниже. 

    Клиенты нередко приходят к нам с некоторыми опасениями по поводу размещения ПДн в облаке провайдера. Что ж, давайте сразу их обсудим.

    • Данные могут быть похищены при передаче или миграции

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

    • Приедут маски-шоу и унесут/опечатают/обесточат сервер

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

    • Хакеры взломают облако и украдут данные

    Интернет и печатная пресса пестрят заголовками о том, как очередное облако пало жертвой киберпреступников, а миллионы записей с ПДн утекли в сеть. В подавляющем большинстве случаев уязвимости обнаруживались совсем не на стороне провайдера, а в ИС жертв: слабые или вообще пароли по умолчанию, «дыры» в движках сайтов и БД, банальная беспечность бизнеса при выборе средств защиты и организации процедур доступа к данным. Все аттестованные решения проверяются на наличие уязвимостей. Мы тоже регулярно проводим «контрольные» пентесты и аудиты безопасности как самостоятельно, так и средствами внешних организаций. Для провайдера это вопрос репутации и бизнеса в целом.

    • Провайдер/сотрудники провайдера украдут ПДн в корыстных целях

    Это достаточно щепетильный момент. Ряд компаний из мира ИБ «пугают» своих клиентов и настаивают, что «внутренние сотрудники опаснее хакеров извне». Возможно, в ряде случаев это так, но бизнес нельзя построить без доверия. Время от времени мелькают новости о том, что собственные сотрудники организаций сливают данные клиентов злоумышленникам, а внутренняя безопасность подчас организована намного хуже, чем внешняя. Здесь важно понимать, что любой крупный провайдер крайне не заинтересован в негативных кейсах. Действия сотрудников провайдера хорошо регламентированы, разделены роли и зоны ответственности. Все бизнес-процессы построены так, что случаи утечки данных крайне маловероятны и всегда заметны внутренним службам, поэтому клиентам проблем с этой стороны опасаться не стоит.

    • Вы мало платите, так как оплачиваете услуги данными своего бизнеса.

    Еще один миф: клиент, арендующий защищенную инфраструктуру по комфортной цене, на самом деле платит за нее своими данными – так нередко думают специалисты, которые не прочь прочитать перед сном пару теорий заговора. Во-первых, возможность проведения каких-то операций с вашими данными помимо тех, что указаны в поручении, по сути равна нулю. Во-вторых, адекватный провайдер дорожит отношениями с вами и своей репутацией — кроме вас у него еще множество клиентов. Более вероятен обратный сценарий, при котором провайдер будет рьяно защищать данные своих клиентов, на которых держится в том числе и его бизнес.

    Выбираем облачного провайдера для ИСПДн

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

    • Провайдер должен быть готов заключить официальный договор с описанием обязанностей сторон, SLA и зон ответственности в ключе обработки ПДн. Фактически, между вами и провайдером, помимо договора на сервис, должно быть подписано поручение на обработку ПДн. В любом случае стоит внимательно их изучить. Важно понимать разграничение зон ответственности между вами и провайдером.

    • Обратите внимание, что сегмент должен соответствовать требованиям, а значит, иметь аттестат с указанием уровня защищенности не ниже, чем требуется вашей ИС. Бывает, что провайдеры публикуют только первую страницу аттестата, из которой мало что понятно, или ссылаются на аудит или прохождение процедур соответствия, не публикуя сам аттестат («а был ли мальчик?»). Стоит его запросить — это публичный документ, в котором указывается, кем была проведена аттестация, срок действия, расположение облака и т.п.

    • Провайдер должен предоставлять информацию о том, где находятся его площадки (объекты защиты), чтобы вы могли контролировать размещение ваших данных. Напомним, что первоначальный сбор ПДн должен выполняться на территории РФ, соответственно в договоре/аттестате желательно видеть адреса ЦОД.

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

    • Крайне желательно, чтобы облачный провайдер оказывал дополнительные услуги в сфере ИБ. Это могут быть различные сервисы: защита от DDoS-атак и WAF, антивирусный сервис или песочница и т.п. Все это позволит вам получать защиту как сервис, не отвлекаться на построение систем защиты, а заниматься бизнес-приложениями.

    • Провайдер должен быть лицензиатом ФСТЭК и ФСБ. Как правило, такая информация размещается прямо на сайте. Обязательно запросите эти документы и проверьте, правильно ли указаны адреса предоставления услуг, название компании провайдера и т.п. 

    Давайте подытожим. Аренда инфраструктуры позволит отказаться от CAPEX и оставить в своей зоне ответственности только свои бизнес-приложения и сами данные, а тяжелое бремя аттестации «железа» и программно-аппаратных средств передать провайдеру.

    Как мы проходили аттестацию

    Совсем недавно мы успешно прошел переаттестацию инфраструктуры «Защищенного облака ФЗ-152» на соответствие требованиям для работы с персональным данными. Работы проводил «Национальный аттестационный центр».

    На текущий момент «Защищенное облако ФЗ-152» аттестовано для размещения информационных систем, участвующих в обработке, хранении или передаче персональных данных (ИСПДн) согласно требованиям уровня УЗ-3.

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

    Тривиальным его назвать нельзя. Несмотря на то, что ГОСТ по программам и методикам проведения аттестационных мероприятий появился еще в 2013 году, жестких программ для облачных объектов до сих пор не существует. Аттестационные центры разрабатывают эти программы, основываясь на собственной экспертизе. С появлением новых технологий программы усложняются и модернизируются, соответственно, аттестатор должен иметь опыт работы с облачными решениями и понимать специфику.

    В нашем случае объект защиты состоит из двух локаций.

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

    • Вторая часть объекта — средства управления облаком. Это рабочие станции (АРМ администратора), с которых осуществляется управление защищенным сегментом.

    Локации связываются через VPN-канал, построенный на СКЗИ.

    Поскольку технологии виртуализации создают предпосылки для появления угроз, мы используем и дополнительные сертифицированные средства защиты.

    Структурная схема «глазами аттестатора»
    Структурная схема «глазами аттестатора»

    Если клиенту требуется аттестация его ИСПДн, после аренды IaaS ему останется только провести оценку информационной системы выше уровня виртуального ЦОД. Эта процедура подразумевает проверку инфраструктуры и используемого на нем ПО. Так как по всем инфраструктурным вопросам вы можете ссылаться на аттестат провайдера, вам останется только провести работы с ПО.

    Разделение на уровне абстракции
    Разделение на уровне абстракции

    В заключение приведем небольшой чек-лист для компаний, которые уже работают с ПДн или только планируют. Итак, как обрабатывать и не обжечься.

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

    2. На этапе выбора облачного провайдера обращайте внимание на наличие аттестата. Хорошо, если компания публично разместила его прямо на сайте. Провайдер должен быть лицензиатом ФСТЭК и ФСБ, а предлагаемый им сервис аттестован.

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

    Если для вас актуальны вопросы обработки ПДн, 18 сентября, в эту пятницу, будем рады видеть вас на вебинаре «Особенности построения аттестованных облаков».

    ИТ-ГРАД
    vmware iaas provider

    Комментарии 9

      0
      Появилось пару вопросов:
      1) При разворачивании виртуальных серверов под заказчика на них предустанавливаются сертифицированные СЗИ, всякие там секретнеты и т.д.?
      2) На первой схеме не совсем понятно что отводится под ИС заказчика, сегмент с права что выделен пунктиром?
      3) Виртуальные межсетевые экраны имеют сертификаты (Тип «Б» вроде)?
        0
        1) При разворачивании виртуальных серверов под заказчика на них предустанавливаются сертифицированные СЗИ, всякие там секретнеты и т.д.?

        Нет. Клиент получает набор виртуального железа (vCPU, vRAM, SSD, HDD и т.п.). Он сам решает, какие ОС и СЗИ в них ему использовать. ИС клиента — это его зона ответственности. Мы как провайдер ему можем только советовать и рекомендовать, но решать, что и как, — вопрос клиента.

        2) На первой схеме не совсем понятно, что отводится под ИС заказчика, сегмент справа, что выделен пунктиром?

        Да, клиент получает тенант (сегмент) внутри Облака.

        3) Виртуальные межсетевые экраны имеют сертификаты (Тип «Б» вроде)?

        МСЭ типа «А» — это МСЭ, применяемый на физической границе (периметре) информационной системы или между физическими границами сегментов информационной системы. Именно такое сертифицированное решение применяется для защиты всего Облака. МСЭ типа «Б» — это МСЭ, применяемый на логической границе (периметре) информационной системы или между логическими границами сегментов информационной системы.
          0
          Извиняюсь может я что то упустил, получается два виртуальных сегмента внутри облака, двух разных Клиентов, разделяются Физическим МСЭ?
            0
            В текущем материале эта тема не раскрыта. Я обсудил это на вебинаре, можно посмотреть запись. Если говорить кратко, то каждый клиент «ИТ-ГРАД» и #CloudMTS в аттестованном Облаке получает некоторую виртуальную серверную (сегмент или тенант) с набором виртуального железа (vCPU, vRAM, SSD, HDD) и виртуальным маршрутизатором. Для доступа в нее — один или несколько белых IP. Белые IP находятся на сертифицированном МСЭ (программно-аппаратное решение). Трафик с белых IP натируется на виртуальный маршрутизатор в тенанте клиента. Да, если два клиента одного такого аттестованного Облака захотят обменяться трафиком, то это возможно сделать только через внешний МСЭ. Настройками фильтрации на своих белых IP клиенты управляют по заявкам в ТП. В своем тенате на виртуальном маршрутизаторе можно настроить многое клиенту самому (за рядом исключений, например, L2 связь во внешний мир). Если клиенту нужно сделать какие-то сложные сетевые вещи, можно поставить VM с маршрутизатором/FW Cisco и т.п., а если сертифицированный крипто-туннель до его другой локации – VM с криптошлюзом С-Терра. В общем вариантов много ;)
        +1
        Я не могу ничего сказать по поводу рекламной части статьи, но вот во вводной части однозначно присутствуют косяки, как минимум вводящие в заблуждение. Например:
        Агентство имеет право хранить эти данные и не в России, однако первоначальный сбор, согласно нашему законодательству, необходимо выполнять на территории РФ.… выполняете с ними какие-то иные операции — все это можно делать и на западных ресурсах. Ключевой момент с точки зрения законодательства — где происходит сбор ПДн. Поэтому важно не путать первоначальный сбор и обработку.

        А вот, что говорит закон:
        8. Невыполнение оператором при сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети «Интернет», предусмотренной законодательством Российской Федерации в области персональных данных обязанности по обеспечению записи, систематизации, накопления, хранения, уточнения (обновления, изменения) или извлечения персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, —


        Т.е. вот как раз первоначальный сбор можно производить на зарубежном сервере, объяснив это тем, что этот сервер работает исключительно как промежуточное звено при получении данных и сразу передает эти данные в базу в России. А актуальная база лежит именно на территории РФ. Например, интернет-магазин лежит на сервере в Германии, заказ падает сразу во внутреннюю базу, находящуюся в России и люди работают с локальной базой в России (т.е. подтверждают заказ, вносят уточнения в адрес доставки и т.п.) — вот это законно. Т.е. как раз где идет «первоначальный сбор» (такого понятия в законодательстве вообще нет) — это никого не интересует.

        Намного интереснее бы было посмотреть экономику рекламируемого предложения. По опыту моего общения с РКН они почти ничего не имеют права проверить и ответственность для организации наступает только в случае утечки, причем сумма ответственности (исключаю вариант гражданских исков от субъектов) там просто несравнимо ниже, чем обращение к консультантам по внедрению решений по работе с ПД и уж тем более чем сумма рекомендуемых решений.
          0
          Добрый день. В разделе с примером про «Рекламное агенство» вы пишете, что можно хранить данные на зарубежных облаках если первоначальный сбор выполняется на территории РФ. В разъяснениях Минцфиры digital.gov.ru/ru/personaldata/#1438174494141 в разделе «Трансграничность» (5-й вопрос) написано, что понятия «первичный сбор» не существует и, как следствие, сбор, обработка и хранение должны выполняться в базах данных, расположенных на территории РФ. Получается, что передавать за границу можно только обезличенные данные, либо передавать, обрабатывать, но не хранить (приложение в зарубежном облаке, СУБД с данным в РФ). Можете поделиться ссылкой на норму, которая позволяет утверждать, что допускается передача ПДн для хранения и обработки в зарубежных облаках которая подтверждает валидность вашего примера с агентством?
            0
            Вы правы. В примере про агентство говорится, что клиент планирует рассчитывать статистику. Речь не идет о создании или хранении всей базы и т.п. Вы правильно пишете, что передавать за границу можно только обезличенные данные, либо передавать, обрабатывать. В примере, вероятно, нечетко прописана цель передачи – обработка данных (расчёт статистики). Пример как раз приведен для того, чтобы показать, как клиенту трудно разобраться в деталях и корректно описать свою ИСПДн, да так, чтобы самого себя не “подвести”. Спасибо, что отметили этот момент.
            0

            Спасибо за материал! По поводу адреса ЦОД, кнчн, перегиб. Так можно и дальше влезать в тонкости провайдера. Отношения пусть регулируются соглашением. А те компании, которые до сих пор боятся, будут платить избыточные стоимости за свою инфраструктуру и постепенно станут неконкурентными. Ну и в целом все сказанное справедливо для всех данных, не только ПНд.
            Ещё в кассу мифа, про "доступ сотрудников провайдера": исторически на рынке ИТ закупается огромная часть услуг по сопровождению той или иной инфраструктуры или ИС. В этом случае партнер также получает полный доступ к сопровождаемой части. Но компании слепо верят, что утечка по этому риску невозможна. И при переходе в облако провайдер сразу начнет данные перепродавать. Миф, верно.
            Рынок облаков в мире (2019) по данным cnews $286 млрд. Именно по этой причине облачные провайдеры, как хорошо написано в статье, также будут "рьяно защищать данные своих клиентов, на которых держится в том числе и его бизнес.". А "утащить" данные из периметра компании зачастую проще значительно — достаточно замотивировать низкооплачиваемого ИТ-администратора.

              0
              Рад, что вам материал понравился. Соглашусь, что многие из мифов справедливы для всех ИС с любыми данными, а не только ПНд. Но, с другой стороны, очень мало компаний вывешивают на сайт в публичный доступ аттестаты на свои Облака. Демонстрация первой страницы аттестата вообще клиенту мало что говорит. При этом могут написать, что все Облака аттестованы по уровню УЗ-1/K1. Клиенты часто не в теме деталей и считают, что чем выше уровень или класс защиты, тем лучше. Хотя для 90% наших клиентов УЗ-3 — это необходимо и достаточно, а на что-то большее лучше не смотреть в силу дополнительных обременений. Другие провайдеры играют с «оценкой эффективности» и подменяют ей аттестат. Хотя сами понимают, что аттестат и оценка эффективности – совсем разные вещи, особенно в случае, если клиент предполагает в дальнейшем пройти аттестацию своей ИСПДн.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое