Вообще ситуация с банком конечно маловероятна. Особенно с учетом того, что закон вышел более 10 лет назад, и за это время банки собрали согласия со всех своих клиентов. Также следует помнить, что согласно п.1 ст.6 152-ФЗ обработка ПДн допускается в том числе в случае если обработка персональных данных необходима для исполнения договора, стороной которого либо выгодоприобретателем или поручителем по которому является субъект персональных данных, а также для заключения договора по инициативе субъекта персональных данных или договора, по которому субъект персональных данных будет являться выгодоприобретателем или поручителем. То есть сослаться на отсутствие согласия и не отдавать кредит не получится :)
Тут принцип разумной достаточности. По факту, если в вашей системе обрабатываются только Ф.И.О., то просить согласия на их сбор вы не должны, уведомлять РКН тоже. При этом вы можете еще сделать протокол, в котором укажете, что нарушение конфиденциальности, целостности или доступности Ф.И.О. не принесет никакого ущерба субъекту ПДн. Соответственно, и защищать ничего не надо. Какой смысл защищать то, что никакой ценности не представляет?
Ответ на этот вопрос уже содержится в посте выше.
Согласие на съемку не требуется в следующих случаях (ст. 152.1 Гражданского кодекса РФ):
1) использование изображения осуществляется в государственных, общественных или иных публичных интересах;
2) изображение гражданина получено при съемке, которая проводится в местах, открытых для свободного посещения, или на публичных мероприятиях (собраниях, съездах, конференциях, концертах, представлениях, спортивных соревнованиях и подобных мероприятиях), за исключением случаев, когда такое изображение является основным объектом использования;
3) гражданин позировал за плату.
Классическим примером служит та же запись или видео трансляция судебного заседания: согласие гражданина на обнародование и дальнейшее использование его изображения в таком случае не требуется.
Новая редакция ФЗ-152 действует с 10.08.2017г. — я рекомендую опираться на судебную практику, сформированную уже по актуальному законодательству. Если вы пришлете пример судебного решения, принятого после 10.08.2017г., где будет указано, что номер паспорта сам по себе не является ПДн, то мы с удовольствием его изучим и дадим развернутый комментарий
Явно в 152-ФЗ, конечно, ничего не прописано, но есть требования по моделированию угроз безопасности персональных данных. При моделировании мы обязаны рассматривать угрозы, связанные с перехватом ПДн. Также есть 21 приказ ФСТЭК, в нем можно увидеть требование ЗИС.3, которое звучит следующим образом: «Обеспечение защиты персональных данных от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи»
На мой взгляд, нет. И защищать системы где из ПДн обрабатывается только e-mail по требованиям 152-ФЗ не нужно. Сам по себе email не позволит идентифицировать человека (в большинстве случаев) и по сути является информацией, которую сообщают всем подряд (при регистрации на сайтах, на визитках и т.п.). То есть ущерб субъекту от того, что его имейл узнают — никакой.
Другой вопрос, если вместе с email обрабатываются еще какие-то сведения, которые позволят идентифицировать человека, например, загружаются фотки, Ф.И.О., дата рождения из фейсбука или подтягиваются какие-то платежные данные. Вот тут уже точно нужно думать о защите. Тем более были инциденты, например с Sony, когда утекли данные пользователей Playstation Network.
Все зависит от результатов оценки угроз безопасности персональных данных. Если вы в рамках моделирования признаете (обоснованно!), что угрозы, связанные с перехватом информации являются неактуальными, то применение шифрования не требуется. В противном случае шифрование обязательно. Но отмечу, что для нейтрализации актуальных угроз должны применяться СЗИ, прошедшие в установленном порядке процедуру оценку соответствия. В случае с СКЗИ — это сертифицированные ФСБ России решения и алгоритм шифрования ГОСТ.
Логического противоречия здесь нет, но есть казусы, которые фактически никак нельзя зарегулировать и выявить, поэтому даже в таких случаях определенную информацию относят к ПДн.
Например, если два мальчика близнеца, родившиеся в один день, имеющие, соответственно, одинаковые имя и фамилию, вдруг решат еще и сменить в паспорте имя на одинаковое, то идентифицировать их будет крайне сложно не только имея в наличии их персональные данные, но и даже чисто физически — то есть визуально, в том числе с использованием биометрических средств.
Именно поэтому набор «ФИО + дата рождения + пол» традиционно относят к ПДн, о чем сложилась достаточно обширная судебная практика.
С удовольствием продадим вам все наши хосты для попытки проведения вами целевой атаки. Если серьезно, то злоумышленник не сможет перемещать свою VM между хостами, то есть, повторюсь, нужно будет выкупить очень много ресурсов и равномерно «размазать» их по облаку, что не очень реалистично. Это в случае, если нет обновленя. После обновления это вообще не сработает.
У нас основные клиенты используют MS. Мы писали о своих тестах, которые могут показаться кому-то полезными. На всеохватывающее мировое знание, естественно, не претендуем. Если вы проведёте тесты описанных инфраструктур, будет очень интересно взглянуть.
В облаках архитектуры подобных нашему практически невозможно было провести прямую атаку на конкретного клиента. В случае, если этот клиент пользуется персональным облаком уязвимость вообще не может быть реализована.
Мы не накатываем патчи без тестов.
Патчи, доступные 9-го ноября, находились еще в стадии тестирования. Так как в середине декабря мы заморозили работы на инфраструктуре перед НГ праздниками, они не были установлены.
Данные уязвимости не затрагивают СХД. Реализация возможна только на том физическом хосте, где развёрнуты и атакующая и атакуемая машины. В случае реализации успешной атаки можно вычитать только содержимое оперативной памяти с этого физического хоста, но не получить данные с других хостов. Патч для VMware ESXi включают в себя обновления микрокода для процессоров:
VIBs Installed: VMware_bootbank_cpu-microcode_6.0.0-3.81.7504637, VMware_bootbank_esx-base_6.0.0-3.81.7504637, VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-bootbank_esx-ui_1.22.0-6282878, VMware_bootbank_esx-xserver_6.0.0-3.76.6856897, VMware_bootbank_ipmi-ipmi-devintf_39.1-5vmw.600.3.79.6921384, VMware_bootbank_ipmi-ipmw.600.3.79.6921384, VMware_bootbank_misc-drivers_6.0.0-3.79.6921384, VMware_bootbank_vsan_6.0.0-3.81.7355197, VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.3.81.735519s-light_6.0.0-3.76.6856897
По нашему опыту нужно обязательно делать общую встречу, можно презентацию, для всей рабочей группы на старте проекта. По ходу проекта обязательно нужно собираться и делиться статусами. Важно поддерживать у всего коллектива одинаковое понимание ситуации, задач заказчика, последних вводных и так далее. В дополнение к этим встречам нужно ставить отдельное ТЗ каждому участнику. То есть не нужно выбирать что-то одно. И ещё обязательно нужно делать матрицу, где весь проект бить на задачи, каждую задачу приписывать конкретному исполнителю. Эта матрица всегда должна быть доступна всем участникам. Как-то так. А насчет вашего P.S., предлагаем вам написать сюда ISapozhnikova@technoserv.com, это мейл нашей коллеги из HR.
Тут предлагаем обратиться к 330 постановлению правительства. Но снова обращаем внимание на п.4 Приказа ФСТЭК 21: СЗИ, прошедшие процедуру оценки соответствия применяются для нейтрализации актуальных угроз безопасности персональных данных. Т.е. реализовывать базовый и адаптивный базовый набор мер теоретически можно и без применения СЗИ, прошедших процедуру оценки соответствия.
У нас есть модель нарушителя для каждого сегмента, в каждой модели определены возможности нарушителей и имеется вывод о классе необходимых к применению криптосредств для защиты ПДн. Соответственно, клиентам, которые размещают в нашем облаке свои ИСПДн, предоставляются сертифицированные ФСБ России СКЗИ для организации ГОСТ VPN.
При этом есть клиенты, которые размещают в нашем облаке системы, не являющиеся ИСПДн. Соответственно, обработки ПДн нет, а значит, защиту каналов связи они могут организовывать, как они считают правильным.
В итоге получаем следующее: те, у кого есть ПДн, защищают каналы связи с использованием ГОСТ VPN, те, у кого нет ПДн, защищают, как считают правильным.
Все действия по удаленному администрированию облачной платформы осуществляются через ГОСТ VPN, как показано на схеме в статье.
Полагаем, из таблички в статье это было не очевидно. Надеемся, это пояснение поможет.
Согласие на съемку не требуется в следующих случаях (ст. 152.1 Гражданского кодекса РФ):
1) использование изображения осуществляется в государственных, общественных или иных публичных интересах;
2) изображение гражданина получено при съемке, которая проводится в местах, открытых для свободного посещения, или на публичных мероприятиях (собраниях, съездах, конференциях, концертах, представлениях, спортивных соревнованиях и подобных мероприятиях), за исключением случаев, когда такое изображение является основным объектом использования;
3) гражданин позировал за плату.
Классическим примером служит та же запись или видео трансляция судебного заседания: согласие гражданина на обнародование и дальнейшее использование его изображения в таком случае не требуется.
Другой вопрос, если вместе с email обрабатываются еще какие-то сведения, которые позволят идентифицировать человека, например, загружаются фотки, Ф.И.О., дата рождения из фейсбука или подтягиваются какие-то платежные данные. Вот тут уже точно нужно думать о защите. Тем более были инциденты, например с Sony, когда утекли данные пользователей Playstation Network.
Например, если два мальчика близнеца, родившиеся в один день, имеющие, соответственно, одинаковые имя и фамилию, вдруг решат еще и сменить в паспорте имя на одинаковое, то идентифицировать их будет крайне сложно не только имея в наличии их персональные данные, но и даже чисто физически — то есть визуально, в том числе с использованием биометрических средств.
Именно поэтому набор «ФИО + дата рождения + пол» традиционно относят к ПДн, о чем сложилась достаточно обширная судебная практика.
Патчи, доступные 9-го ноября, находились еще в стадии тестирования. Так как в середине декабря мы заморозили работы на инфраструктуре перед НГ праздниками, они не были установлены.
VIBs Installed: VMware_bootbank_cpu-microcode_6.0.0-3.81.7504637, VMware_bootbank_esx-base_6.0.0-3.81.7504637, VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-bootbank_esx-ui_1.22.0-6282878, VMware_bootbank_esx-xserver_6.0.0-3.76.6856897, VMware_bootbank_ipmi-ipmi-devintf_39.1-5vmw.600.3.79.6921384, VMware_bootbank_ipmi-ipmw.600.3.79.6921384, VMware_bootbank_misc-drivers_6.0.0-3.79.6921384, VMware_bootbank_vsan_6.0.0-3.81.7355197, VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.3.81.735519s-light_6.0.0-3.76.6856897
При этом есть клиенты, которые размещают в нашем облаке системы, не являющиеся ИСПДн. Соответственно, обработки ПДн нет, а значит, защиту каналов связи они могут организовывать, как они считают правильным.
В итоге получаем следующее: те, у кого есть ПДн, защищают каналы связи с использованием ГОСТ VPN, те, у кого нет ПДн, защищают, как считают правильным.
Все действия по удаленному администрированию облачной платформы осуществляются через ГОСТ VPN, как показано на схеме в статье.
Полагаем, из таблички в статье это было не очевидно. Надеемся, это пояснение поможет.