152 фз сайт: Онлайн-сервис для создания политики конфиденциальности и других документов для сайта

Как привести сайт в соответствие ФЗ-152 и выполнить требования Роскомнадзора

Компания Б-152 запустила сервис для владельцев сайтов, который помогает выполнить требования закона №152-ФЗ «О персональных данных» и одновременно поддерживать безопасность сайта. Новый сервис интегрирует технологии SiteSecure для мониторинга безопасности и защиты сайта от заражения вирусами, взлома и перенаправления трафика, предупреждая блокировку сайтов клиентов поисковыми системами и антивирусами, а также утечку персональных данных пользователя.

 

«Удобный интерфейс и анкета, составленная экспертами, проходившими не одну проверку Роскомнадзора, позволяет владельцу сайта, не вдаваясь в детали законодательства, за несколько кликов привести сайт в соответствии с законом №152-ФЗ. Тысячи компаний уже пользуются продуктами Б-152, и мы рады, что теперь у нас есть специализированное решение для владельцев сайтов, что позволит еще большему числу сайтов соблюдать политики безопасности и требования закона» — комментирует Максим Лагутин, сооснователь компании Б-152.  «В последнее время данная функциональность активно востребована на рынке в связи с повышением штрафов и расширением полномочий Роскомнадзора по контролю за соблюдением закона «О персональных данных». Соответствие сайта закону №152-ФЗ позволяет избежать наложения штрафа Роскомнадзором, а также избежать блокировки» — добавляет Максим.

 

Новый сервис сформирует документы для сайта: уведомление о сборе персональных данных, политику обработки персональных данных, а также согласия пользователя для разных целей сбора и обработки.  Услуга предоставляется онлайн, пользователю достаточно зайти на страницу сервиса, заполнить несложные сведения о сайте, оплатить и получить уже готовую политику и уведомление о сборе персональных данных. Документы предоставляются в виде кода, который нужно просто добавить на сайт и виджет будет показывать всю необходимую для соответствия закону информацию. Для подготовки Согласий пользователя, сервис предложит пользователю выбрать типовые варианты, подготовленные экспертами, или создать свой, используя коллекцию шаблонов, которая была накоплена за 6 лет работы с 8 000 организаций и сайтов.

 

«Уникальная функциональность покрывает технические и юридические риски, с которыми сталкиваются владельцы сайтов и интернет-магазинов, и не имеет технических аналогов по полноте предоставляемых клиенту возможностей» — подводит итог Олег Михальский, сооснователь компании SiteSecure.

 

 

О Б-152

Компания Б-152 специализируется на защите персональных данных и занимается приведением бизнес-процесс компании в соответствии с ФЗ-152 «О персональных данных» с 2011 года. Более 8000 компаний доверили сервису Б-152 подготовку документации, в том числе такие операторы персональных данных как Aэроклуб, Philips, TimePad и другие. Многие из клиентов успешно прошли проверку Роскомнадзора. Компания Б-152 предлагает онлайн-сервис подготовки документов, а также консультационную поддержку и верификацию заполненных документов. Для крупных операторов персональных данных компания предлагает индивидуальные решения «под ключ». www.b-152.ru

 

O Sitesecure

Компания SiteSecure – поставщик сервиса для сканирования уязвимостей сайта и обеспечения его безопасности для более чем 35 000 интернет-ресурсов.  Sitesecure сигнализирует владельцу сайта о каждом факте подозрительной активности, оперативно лечит и восстанавливает интернет-сайт.  Мониторинг сайта осуществляется круглосуточно, и оповещения об опасностях на сайте отправляются на электронную почту владельца сайта или по SMS. C 2012 года SiteSecure ведет исследования и разработки в области безопасности сайтов, публикует регулярные аналитические отчеты, организует обучающие мероприятия. Более 100 веб-студий и агентств по продвижению сайтов являются партнерами Sitesecure. www.sitesecure.ru   

152ФЗ.рф — сервис для регламентации работы с персональными данными

{«id»:26053,»url»:»https:\/\/vc.ru\/tribuna\/26053-152-fz»,»title»:»152\u0424\u0417.\u0440\u0444 \u2014 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u0440\u0435\u0433\u043b\u0430\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u043f\u0435\u0440\u0441\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u043c\u0438″,»services»:{«facebook»:{«url»:»https:\/\/www.facebook.com\/sharer\/sharer.php?u=https:\/\/vc.ru\/tribuna\/26053-152-fz»,»short_name»:»FB»,»title»:»Facebook»,»width»:600,»height»:450},»vkontakte»:{«url»:»https:\/\/vk.com\/share.php?url=https:\/\/vc.ru\/tribuna\/26053-152-fz&title=152\u0424\u0417.\u0440\u0444 \u2014 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u0440\u0435\u0433\u043b\u0430\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u043f\u0435\u0440\u0441\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u043c\u0438″,»short_name»:»VK»,»title»:»\u0412\u041a\u043e\u043d\u0442\u0430\u043a\u0442\u0435″,»width»:600,»height»:450},»twitter»:{«url»:»https:\/\/twitter.com\/intent\/tweet?url=https:\/\/vc.ru\/tribuna\/26053-152-fz&text=152\u0424\u0417.\u0440\u0444 \u2014 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u0440\u0435\u0433\u043b\u0430\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u043f\u0435\u0440\u0441\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u043c\u0438″,»short_name»:»TW»,»title»:»Twitter»,»width»:600,»height»:450},»telegram»:{«url»:»tg:\/\/msg_url?url=https:\/\/vc.ru\/tribuna\/26053-152-fz&text=152\u0424\u0417.\u0440\u0444 \u2014 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u0440\u0435\u0433\u043b\u0430\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u043f\u0435\u0440\u0441\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u043c\u0438″,»short_name»:»TG»,»title»:»Telegram»,»width»:600,»height»:450},»odnoklassniki»:{«url»:»http:\/\/connect.ok.ru\/dk?st.cmd=WidgetSharePreview&service=odnoklassniki&st.shareUrl=https:\/\/vc.ru\/tribuna\/26053-152-fz»,»short_name»:»OK»,»title»:»\u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438″,»width»:600,»height»:450},»email»:{«url»:»mailto:?subject=152\u0424\u0417.\u0440\u0444 \u2014 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u0440\u0435\u0433\u043b\u0430\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u043f\u0435\u0440\u0441\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u043c\u0438&body=https:\/\/vc.ru\/tribuna\/26053-152-fz»,»short_name»:»Email»,»title»:»\u041e\u0442\u043f\u0440\u0430\u0432\u0438\u0442\u044c \u043d\u0430 \u043f\u043e\u0447\u0442\u0443″,»width»:600,»height»:450}},»isFavorited»:false}

6544 просмотров

Как владельцам сайтов работать с персональными данными, чтобы избежать штрафа

С 1 июля 2017 г. возбуждать дела об административных правонарушениях будут органы Роскомнадзора, а не прокуратура, как это делается сегодня. Уже сейчас понятно, что данные дела будут возбуждаться проще и быстрее, так как это будет делать сам орган, выявивший правонарушение.

В настоящее время за нарушение закона №152 ФЗ «О защите персональных данных» (сколько бы таких нарушений за 1 раз не было выявлено) можно привлечь только 1 раз. Начиная с 1 июля 2017 г. Роскомнадзор за один «визит» может составить сколько угодно протоколов об административном правонарушении по каждому нарушению. О размере возможно штрафа в таком случае можно только догадываться.

Расположение хостинга сайта

В соответствии с ФЗ № 152, все интернет-ресурсы, на которых хранятся и обрабатываются персональные данные, должны быть расположены на территории Российской Федерации. С учётом того, что контролирующие органы считают персональными данными также и данные о поведении пользователя на сайте, то это касается практически любого интернет-ресурса. За нарушение этого требования Роскомнадзор их блокирует.

Под расположением хостинга подразумевается физическое местонахождение ЦОДа, на котором размещен ваш сайт. То есть, если хостинг-провайдер зарегистрирован в России, а его ЦОДы расположены, к примеру, в Эстонии, вы нарушаете закон и попадаете под блокировку сайта.

Что нужно сделать на сайте, чтобы избежать штрафов

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

1.    Добавить текст согласия на обработку персональных данных

Под каждой формой ввода данных на сайте (регистрация, заявки на услугу, обратный звонок) разместить текст «Нажимая на кнопку «Название кнопки», я даю согласие на обработку персональных данных», где текст «согласие на обработку персональных данных» является ссылкой на документ. Примеры документов вы можете посмотреть на федеральных сайтах, например, ozon.ru и tinkoff.ru. 

Вместо согласия можно использовать единую публичную оферту, но в ней будет нужно прописать, в каких целях, какие данные обрабатываются, то есть указать всё, согласно ч.4 ст.9 152-ФЗ. В этом случае обязательно хранить логи, чтобы, в случае чего, доказать Роскомнадзору, что тот или иной пользователь действительно заходил на сайт и оставлял там свои персональные данные.

2.    Составить документ «Политика в отношении обработки персональных данных»

Этот документ нужно разместить на сайте в свободном доступе. В данном документе должны быть описаны процедуры сбора, обработки и хранения персональных данных пользователей сайта. Хорошо проработанный документ о политике в отношении обработки персональных данных есть на ikea.com. При этом с данным документом регистрирующийся не должен соглашаться при заполнении формы.

3.    Узнать, где находится хостинг сайта

Узнать у хостинг-провайдера, где физически находится ЦОД, в котором расположен ваш сайт и, в случае, если он расположен не на территории РФ, перенести сайт на другой хостинг. Сделать это вы можете, отправив запрос в техническую поддержку сайта.

4.    Указать email для обращений пользователей по персональным данным

Укажите email, куда физическое лицо может обратиться за тем, чтобы его персональные данные были удалены, заблокированы и вообще, куда он может задать вопрос по персональным данным. Email можно указать в документах, описанных выше.

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

5.    Подать уведомление об обработке персональных данных в Роскомнадзор

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

6.    Заключить соглашение о безопасности персональных данных с разработчиком сайта

В случае если агентство-разработчик сайта имеет доступ к персональным данным из заявок или базы данных сайта (например, сайт находится на технической поддержке), вам необходимо заключить соглашение с агентством об обеспечении безопасности персональных данных. В соглашении должно быть указано, какие персональные данные агентство может обрабатывать, в каких целях и какие действия с ними выполнять. Также там должны быть требования по защите персональных данных.

7.    Поставить на сайте дисклеймер

До 1 июля 2017 года поставить на сайте дисклеймер, который будет уведомлять посетителей сайта, что его персональные данные обрабатываются на сайте в целях его функционирования и, если он не согласен, то должен покинуть сайт. Примеры дисклеймеров вы можете посмотреть на сайтах marykay.ru и bmw.ru. В противном случае это будет являться согласием на обработку его персональных данных.

Список внушительный, но не стоит бояться этих изменений. Специалисты Мэйка в течение 5 рабочих дней внесут изменения, которые обезопасят ваш сайт от штрафов Роскомнадзора.

Мы оказываем эту услугу как нашим клиентам в рамках технического обслуживания, так и сторонним сайтам.

ФЗ — закон о персональных данных для владельцев сайтов.

Что такое 152-ФЗ?

Это федеральный закон, который регулирует деятельность операторов персональных данных в области управления персональными данными. Закон посвящен регулировке данных граждан Российской Федерации. Требования ФЗ сообщают о том, что все сайты и блоги, на которых есть формы для отправки данных пользователей должны соответствовать ряду требований.

Под формами отправки данных имеются в виду онлайн-формы:

• обратной связи и отправки сообщений,

• регистрации пользователей,

• оформления заказов,

• подписки на рассылку,

• комментарии,

• любые другие формы, через которые пользователи отправляют какие-либо данные (текстовые, графические, голосовые и другие) с сайта.

Касается ли 152-ФЗ физлиц?

Да. Физлицо, владеющее сайтом и принимающее через него данные от пользователей, тоже является оператором персональных данных, а значит подпадает под действие закона.

Чем грозит нарушение закона?

Нарушение закона грозит владельцу сайта штрафом или даже блокировкой ресурса.

Как владельцу сайта избежать этой проблемы?

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

• Веб-форма ― способ получить это согласие. Необходима специальная форма, где пользователь ставит галочку в определенной графе, явно указывающей на его согласие с правилами обработки персональных данных.

• На сайте должен быть размещен документ с описанием политики вашего сайта по обработке данных. Политика должна соответствовать требованиям 152-ФЗ.

Вы должны позаботиться о размещении персональных данных пользователей из России на территории Российской Федерации.

Почему сайты на 1С-UMI соответствуют 152-ФЗ?

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

Далее необходимо заполнить саму страницу с правилами обработки персональных данных.

Как составить текст соглашения

Текст соглашения составляется в произвольной форме в соответствии с юридическими требованиями. Вот пример такого документа, который используем мы в UMI. Все необходимые данные и документы о техническом обеспечении сайта со стороны UMI мы предоставляем по запросу. 

Как разместить правила обработки персональных данных

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

Конструктор политики конфиденциальности и обработки персональных данных

2.1. Автоматизированная обработка персональных данных – обработка персональных данных с помощью средств вычислительной техники.

2.2. Блокирование персональных данных – временное прекращение обработки персональных данных (за исключением случаев, если обработка необходима для уточнения персональных данных).

2.3. Веб-сайт – совокупность графических и информационных материалов, а также программ для ЭВМ и баз данных, обеспечивающих их доступность в сети интернет по сетевому адресу httpsː//thismywebsite·com.

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

2.5. Обезличивание персональных данных — действия, в результате которых невозможно определить без использования дополнительной информации принадлежность персональных данных конкретному Пользователю или иному субъекту персональных данных.

2.6. Обработка персональных данных – любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных.

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

2.8. Персональные данные – любая информация, относящаяся прямо или косвенно к определенному или определяемому Пользователю веб-сайта httpsː//thismywebsite·com.

2.9. Персональные данные, разрешенные субъектом персональных данных для распространения, — персональные данные, доступ неограниченного круга лиц к которым предоставлен субъектом персональных данных путем дачи согласия на обработку персональных данных, разрешенных субъектом персональных данных для распространения в порядке, предусмотренном Законом о персональных данных (далее — персональные данные, разрешенные для распространения).

2.10. Пользователь – любой посетитель веб-сайта httpsː//thismywebsite·com.

2.11. Предоставление персональных данных – действия, направленные на раскрытие персональных данных определенному лицу или определенному кругу лиц.

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

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

2.14. Уничтожение персональных данных – любые действия, в результате которых персональные данные уничтожаются безвозвратно с невозможностью дальнейшего восстановления содержания персональных данных в информационной системе персональных данных и (или) уничтожаются материальные носители персональных данных.

Политика конфиденциальности

1.ВВЕДЕНИЕ

1.1. Политика конфиденциальности персональной информации (далее — Политика) действует в отношении всей информации, которую ООО «ГК СофтБаланс» и/или его аффилированные лица, включая все лица, входящие в одну группу с ООО «ГК СофтБаланс» (далее — Компания), могут получить о Пользователе (далее – Пользователь, субъект персональных данных) во время использования им любого из сайтов, сервисов, служб, программ, продуктов или услуг Компании (далее — Сервисы, Сервисы Компании) и в ходе исполнения Компанией любых соглашений и договоров с Пользователем. Согласие Пользователя с Политикой, выраженное им в рамках отношений с одним из перечисленных лиц, распространяется на все остальные перечисленные лица.

1.2. Настоящая Политика разработана в соответствии с действующим законодательством Российской Федерации о персональных данных.

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

2. СОСТАВ ПЕРСОНАЛЬНЫХ ДАННЫХ

2.1. Сведениями, составляющими персональные данные, является любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных), в том числе, но не ограничиваясь, ФИО, электронная почта, телефон.

2.2. К учетным данным относятся сведения, которые автоматически передаются Сервисам ГК СофтБаланс в процессе их использования с помощью установленного на устройстве Пользователя программного обеспечения, в том числе IP-адрес, данные файлов cookie, информация о браузере Пользователя (или иной программе, с помощью которой осуществляется доступ к Сервисам), технические характеристики оборудования и программного обеспечения, используемых Пользователем, дата и время доступа к Сервисам, адреса запрашиваемых страниц и иная подобная информация.

2.3. Все обрабатываемые Компанией персональные и учётные данные являются конфиденциальной, строго охраняемой информацией в соответствии с законодательством РФ.

2.4. Настоящая Политика применима только к информации, обрабатываемой в ходе использования Сервисов Компании. Компания не контролирует и не несет ответственность за обработку информации сайтами третьих лиц, на которые Пользователь может перейти по ссылкам, доступным на сайтах Компании, в том числе в результатах поиска.

2.5. Компания не проверяет достоверность персональной информации, предоставляемой Пользователем, и не имеет возможности оценивать его дееспособность. Однако Компания исходит из того, что пользователь предоставляет достоверную и достаточную персональную информацию и поддерживает эту информацию в актуальном состоянии. Пользователь берет на себя риски предоставления недостоверной или недостаточной информации.

3. ЦЕЛИ ОБРАБОТКИ ПЕРСОНАЛЬНЫХ ДАННЫХ

3.1. Персональные данные обрабатываются Компанией в целях оформления трудовых и иных договорных отношений, кадрового, бухгалтерского, налогового учета, по снованиям, предусмотренным ст.22 Федерального закона от 27.06.2006 №152-ФЗ, 85-90 Трудового кодекса РФ, а также в целях организации и проведения Компанией (в т.ч. с привлечением третьих лиц) программ лояльности, маркетинговых и/или рекламных акций, исследований, опросов и иных мероприятий; исполнения Компанией обязательств в рамках договора розничной купли-продажи товаров, услуг, программ для ЭВМ в интернет-магазинах Компании; оказания иных услуг субъектам персональных данных; продвижения услуг, программ для ЭВМ и/или товаров Компании и/или партнеров Компании на рынке путем осуществления прямых контактов с клиентами Компании с помощью различных средств связи, в т.ч., не ограничиваясь, по телефону, электронной почте, почтовой рассылке, в сети Интернет и т.д.; в иных целях, если действия Компании не противоречат действующему законодательству.

4. СУБЪЕКТЫ ПЕРСОНАЛЬНЫХ ДАННЫХ:

• работники Компании;
• субъекты, с которыми заключены договоры гражданско-правового характера;
• кандидаты на замещение вакантных должностей Компании;
• клиенты Компании;
• зарегистрированные пользователи сайта Компании;
• представители юридических лиц;
• поставщики (индивидуальные предприниматели).

5. ПРИНЦИПЫ И УСЛОВИЯ ОБРАБОТКИ ПДн

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

5.2. Обработка и обеспечение безопасности персональных данных в Компании осуществляется в соответствии с требованиями Конституции Российской Федерации, Федерального закона № 152-ФЗ «О персональных данных», подзаконных актов, других определяющих случаи и особенности обработки персональных данных федеральных законов Российской Федерации, руководящих и методических документов ФСТЭК России и ФСБ России.

5.3. При обработке персональных данных Компания придерживается следующих принципов:

• законности и справедливой основы;
• ограничения обработки персональных данных достижением конкретных, заранее определенных и законных целей;
• недопущения обработки персональных данных, несовместимой с целями сбора персональных данных;
• недопущения объединения баз данных, содержащих персональные данные, обработка которых осуществляется в целях, несовместимых между собой;
• обработки персональных данных, которые отвечают целям их обработки;

5.4. Компания обрабатывает персональные данные только при наличии хотя бы одного из следующих условий:

• обработка персональных данных осуществляется с согласия субъекта персональных данных на обработку его персональных данных;
• обработка персональных данных необходима для достижения целей, предусмотренных законом, для осуществления и выполнения возложенных законодательством Российской Федерации на оператора функций, полномочий и обязанностей;
• обработка персональных данных необходима для исполнения договора, стороной которого либо выгодоприобретателем или поручителем по которому является субъект персональных данных, а также для заключения договора по инициативе субъекта персональных данных или договора, по которому субъект персональных данных будет являться выгодоприобретателем или поручителем;
• обработка персональных данных необходима для осуществления прав и законных интересов Компании или третьих лиц либо для достижения общественно значимых целей при условии, что при этом не нарушаются права и свободы субъекта персональных данных;
• осуществляется обработка персональных данных, доступ неограниченного круга лиц к которым предоставлен субъектом персональных данных либо по его просьбе;
• осуществляется обработка персональных данных, подлежащих опубликованию или обязательному раскрытию в соответствии с федеральным законом.

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

5.6. Лица, осуществляющие обработку персональных данных по поручению Компании, обязуются соблюдать принципы и правила обработки и защиты персональных данных, предусмотренные Федеральным законом № 152-ФЗ «О персональных данных». Для каждого лица определены перечень действий (операций) с персональными данными, которые будут совершаться юридическим лицом, осуществляющим обработку персональных данных, цели обработки, установлена обязанность такого лица соблюдать конфиденциальность и обеспечивать безопасность персональных данных при их обработке, а также указаны требования к защите обрабатываемых персональных данных.

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

5.8. Общество уничтожает либо обезличивает персональные данные по достижении целей обработки или в случае утраты необходимости достижения цели обработки.

6. ПРАВА СУБЪЕКТА ПЕРСОНАЛЬНЫХ ДАННЫХ

6.1. Гражданин, персональные данные которого обрабатываются Компанией, имеет право получать от Компании:

• подтверждение факта обработки персональных данных Компанией;
• правовые основания и цели обработки персональных данных;
• сведения о применяемых Компанией способах обработки персональных данных;
• наименование и местонахождения Компании;
• сведения о лицах, которые имеют доступ к персональным данным или которым могут быть раскрыты персональные данные на основании договора с Компанией или на основании федерального закона;
• перечень обрабатываемых персональных данных, относящихся к гражданину, от которого поступил запрос и источник их получения, если иной порядок предоставления таких данных не предусмотрен федеральным законом;
• сведения о сроках обработки персональных данных, в том числе о сроках их хранения;
• сведения о порядке осуществления гражданином прав, предусмотренных Федеральным законом «О персональных данных» № 152-ФЗ;
• информацию об осуществляемой или о предполагаемой трансграничной передаче персональных данных;
• наименование и адрес лица, осуществляющего обработку персональных данных по поручению Компании;
• иные сведения, предусмотренные Федеральным законом «О персональных данных» № 152-ФЗ или другими федеральными законами;
• требовать уточнения своих персональных данных, их блокирования или уничтожения в случае, если персональные данные являются неполными, устаревшими, неточными, незаконно полученными или не являются необходимыми для заявленной цели обработки;
• отозвать свое согласие на обработку персональных данных;
• требовать устранения неправомерных действий Компании в отношении его персональных данных;
• обжаловать действия или бездействие Компании в Федеральную службу по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) или в судебном порядке в случае, если гражданин считает, что Компания осуществляет обработку его персональных данных с нарушением требований Федерального закона № 152-ФЗ «О персональных данных» или иным образом нарушает его права и свободы;
• на защиту своих прав и законных интересов, в том числе на возмещение убытков и/или компенсацию морального вреда в судебном порядке.

7. ОБЯЗАННОСТИ КОМПАНИИ

7.1. В соответствии с требованиями Федерального закона № 152-ФЗ «О персональных данных» Компания обязана:

• предоставлять субъекту персональных данных по его запросу информацию, касающуюся обработки его персональных данных, либо на законных основаниях предоставить отказ;
• по требованию субъекта персональных данных уточнять обрабатываемые персональные данные, блокировать или удалять, если персональных данных являются неполными, устаревшими, неточными, незаконно полученными или не являются необходимыми для заявленной цели обработки;
• вести Журнал учета обращений субъектов персональных данных, в котором должны фиксироваться запросы субъектов персональных данных на получение персональных данных, а также факты предоставления персональных данных по этим запросам;
• уведомлять субъекта персональных данных об обработке персональных данных в том случае, если персональные данные были получены не от субъекта персональных данных.

Исключение составляют следующие случаи:

• субъект ПДн уведомлен об осуществлении обработки его ПДн соответствующим оператором;
• н получены Компанией на основании федерального закона или в связи с исполнением договора, стороной которого либо выгодоприобретателем или поручителем по которому является субъект ПДн;
• ПДн сделаны общедоступными субъектом ПДн или получены из общедоступного источника;
• компания осуществляет обработку ПД для статистических или иных исследовательских целей, для осуществления профессиональной деятельности журналиста либо научной, литературной или иной творческой деятельности, если при этом не нарушаются права и законные интересы субъекта ПДн;
• предоставление субъекту ПДн сведений, содержащихся в Уведомлении об обработке ПД нарушает права и законные интересы третьих лиц;
• в случае достижения цели обработки персональных данных незамедлительно прекратить обработку персональных данных и уничтожить соответствующие персональные данные в срок, не превышающий тридцати дней с даты достижения цели обработки персональных данных, если иное не предусмотрено договором, стороной которого, выгодоприобретателем или поручителем по которому является субъект персональных данных, иным соглашением между Компанией и субъектом персональных данных либо если Компания не вправе осуществлять обработку персональных данных без согласия субъекта персональных данных на основаниях, предусмотренных №152-ФЗ «О персональных данных» или другими федеральными законами;
• в случае отзыва субъектом персональных данных согласия на обработку своих персональных данных прекратить обработку персональных данных и уничтожить персональные данные в срок, не превышающий тридцати дней с даты поступления указанного отзыва, если иное не предусмотрено соглашением между Компанией и субъектом персональных данных. Об уничтожении персональных данных Компания обязана уведомить субъекта персональных данных;
• в случае поступления требования субъекта о прекращении обработки персональных данных в целях продвижения товаров, работ, услуг на рынке немедленно прекратить обработку персональных данных.

8. МЕРЫ ПО ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ ПЕРСОНАЛЬНЫХ ДАННЫХ ПРИ ИХ ОБРАБОТКЕ

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

9. ОТВЕТСТВЕННОСТЬ

В случае неисполнения положений настоящей Политики Компания несет ответственность в соответствии действующим законодательством Российской Федерации.

ОБРАЩАЕМ ВАШЕ ВНИМАНИЕ!

Получить разъяснения по интересующим Вас вопросам обработки Ваших персональных данных можно путём личного обращения в Компанию либо, направив официальный запрос по Почте России по адресу: 195112, Санкт-Петербург, Заневский проспект, дом 30, корпус 2, литера А. В случае направления официального запроса в Компанию в тексте запроса необходимо указать:

• ФИО;
• сведения, подтверждающие Ваше участие в отношениях с Компанией либо сведения, иным способом подтверждающие факт обработки персональных данных Компанией;
• подпись гражданина (или его законного представителя). Если запрос отправляется в электронном виде, то он должен быть оформлен в виде электронного документа и подписан электронной подписью в соответствии с законодательством РФ.

На настоящем сайте публикуется актуальная версия Политики конфиденциальности.

Политика информационной безопасности 152-ФЗ — kgsp3.ru

Политика информационной безопасности (редакция 2019)

Запись в реестре операторов перс данных

Обращение к субъектам персональных данных

      «КГАУЗ Красноярская городская стоматологическая поликлиника N3» (далее по тексту – Учреждение), владелец сайта kgsp3.ru (далее  — Сайт) с уважением относится к правам посетителей сайта. Мы безоговорочно признаем важность конфиденциальной личной информации посетителей нашего сайта. С целью соблюдения конфиденциальности разработана и утверждена Политика в отношении обработки персональных данных. Указанная Политика содержит сведения о том, какую информацию мы получаем и собираем, когда Вы пользуетесь нашим сайтом. Мы надеемся, что эти сведения помогут Вам принимать осознанные решения в отношении предоставляемой Вами личной информации. Политика в отношении обработки персональных данных распространяется только на сайт  и на информацию, указываемую Вами на нашем сайте. Она не распространяется ни на какие другие сайты и не применима к сайтам третьих лиц, на которые имеются ссылки на наш сайт.

   Посетитель сайта может свободно просматривать сайт Учреждения, но для обращения с вопросом или направления комментария администрации Учреждения через сайт Учреждения посетителю сайта необходимо предоставить личную информацию: имя, фамилию, адрес электронной почты, номер телефона.

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

Посетитель сайта гарантирует:

— информация, им предоставленная, является полной, точной, достоверной;

—  при предоставлении информации не нарушается действующее законодательство Российской Федерации, законные права и интересы третьих лиц;

— что им не используются чужие контактные данные, включая номер телефона, адрес электронной почты и т.п.

Новые правила обработки общедоступных персональных данных — Информационные бюллетени

Введение
Новое понятие «общедоступные персональные данные»
Особые условия и ограничения для обработки общедоступных персональных данных
Комментарий

Введение

Федеральный закон 152-ФЗ от 27 июля 2006 г. «О персональных данных» (Закон о персональных данных) является основным законом, регулирующим операции по обработке персональных данных и связанные с ними вопросы защиты в России.Среди особых режимов, установленных в Законе о персональных данных, есть режим, который касается обработки персональных данных, которые становятся общедоступными субъектом данных.

30 декабря 2020 года президент подписал закон (после его принятия парламентом) Законопроект 1057337-7 о внесении поправок в Закон о персональных данных, который вносит определенные поправки в существующие положения, касающиеся общедоступных персональных данных. Новый закон был опубликован на российском юридическом портале 30 декабря 2020 года и вступит в силу 21 марта 2021 года (с точки зрения нового определения публичных персональных данных) и 1 июля 2021 года (с точки зрения основных аспектов обработки данных, касающихся к публичным персональным данным) (даты вступления в силу).

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

Новое понятие «общедоступные персональные данные»

Новый закон вводит конкретное понятие «публично доступные личные данные». Это определяется как персональные данные, к которым субъект данных предоставляет доступ неограниченному количеству лиц, давая согласие на обработку данных для дальнейшего распространения в соответствии с порядком, установленным Законом о персональных данных.

Согласно действующему Закону о персональных данных, публичный доступ к персональным данным относится к частным случаям регулирования защиты данных (статья 6). Согласно новому закону для обработки этой конкретной категории данных потребуется согласие субъекта данных. Требования к содержанию такого согласия устанавливаются Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор).

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

Особые условия и ограничения обработки общедоступные персональные данные

Новый закон также вводит статью 10.1 Закона о персональных данных, которая конкретно предусматривает следующие условия и ограничения для обработки публично доступных персональных данных:

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

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

Комментарий

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

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

За дополнительной информацией по этой теме обращайтесь к Сергею Медведеву или Илье Горячеву в «Городисский и партнеры» по телефону (+7 495 937 6116), электронной почте ([email protected]) или [email protected]). Сайт «Городисский и партнеры» доступен по адресу www.gorodissky.com.

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

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

Зашифруйте свои данные, чтобы обеспечить совместимость GDPR и российского закона о локализации данных

Российский закон обязывает контроллеров данных хранить и обновлять данные, полученные от граждан России, с использованием российских серверов.Это обязательство не только технически сложно и часто дорого с точки зрения бизнеса, но и является головной болью для сотрудника по защите данных. В конце концов, хранение части вашей базы данных пользователей, расположенной за пределами ЕС, в стране, которая не считается адекватной в соответствии со статьей 45 Общего регламента ЕС по защите данных, может противоречить минимизации данных и может негативно повлиять на ваши законные оценки и т. Д.

Целью статьи является создание хранилища зашифрованного экземпляра базы данных в России без доступа к ключу дешифрования в качестве стратегии, которая формально соответствовала бы российскому законодательству о персональных данных при сохранении высокого уровня защиты прав и интересов субъектов данных.Анализ также может быть полезен для разработки дополнительных мер по обеспечению действительности стандартных договорных положений с местным хостинг-провайдером с учетом решения «Schrems II».

Краткий обзор требований к локализации данных для России

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

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

Лаконичная формулировка закона, а также отсутствие ясности в отношении цели, которую он преследует, создали массу неуверенности. Было неясно, требуется ли для локализации база данных граждан России, расположенная исключительно в России, или будет достаточно ее копии.

Однако местный регулирующий орган Роскомнадзор, которому было поручено обеспечить локализацию, быстро поделился своей позицией по некоторым из горячо обсуждаемых вопросов. В последующие годы некоторые аспекты локализации также были прояснены в официальных инструкциях Минкомсвязи и в комментариях Роскомнадзора к закону о локализации.

В соответствии с этими устными разъяснениями органа по защите данных и письменными инструкциями, главный принцип, который необходимо соблюдать, заключается в том, что база данных в России всегда должна содержать больше или столько же данных, что и базы данных за рубежом. Следовательно, запись данных непосредственно на зарубежный сервер и зеркальное копирование изменений обратно в Россию не вариант, потому что между двумя событиями будет задержка в доли секунды.

С другой стороны, требования к локализации применяются только к данным, собранным от граждан России, то есть они не касаются данных, сгенерированных на стороне сервера.Например, если вы приобрели виджет на веб-сайте электронной коммерции, указанный вами адрес доставки будет считаться собранным и, следовательно, храниться в России, в то время как последующие обновления статуса отслеживания доставки выходят за рамки.

С момента вступления в силу требования к локализации повлекли за собой как минимум одну серьезную жертву — LinkedIn, который был заблокирован в России с 2016 года. После этого местные и международные компании стали более серьезно относиться к локализации.Дополнительная причина не игнорировать локализацию была введена парламентом в декабре 2019 года в виде штрафов в размере до 77000 долларов за первое нарушение и до 231000 долларов за последующие нарушения. В последние годы DPA требовало ответов от Twitter и Facebook о соответствии локализации, хотя этот вопрос все еще не решен.

Проблемы связанные с локализацией

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

Технические проблемы

Многие предпочитают иметь базу данных местного производства, расположенную в России. Очевидно, что это гигантские вложения, которые создают значительную нагрузку на внутренние ресурсы контролера и являются тяжелым финансовым бременем.

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

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

Также стоит упомянуть, что закон о локализации не делает никаких исключений для файлов cookie и других наборов данных, которые обычно выполняются на стороне пользователя. С формальной точки зрения, метрики, которые вы собираете с помощью пикселей, маяков и JS-скриптов, внедряемых на вашу страницу, также подлежат локализации.

Соображения о конфиденциальности

Конечно, на технической стороне проблемы не заканчиваются. С точки зрения конфиденциальности и совместимости с GDPR в России довольно сложно.

Во-первых, Комиссия ЕС не считает Россию подходящей для целей передачи данных за пределы Европейской экономической зоны, несмотря на то, что Россия подписала и ратифицировала Конвенцию 108. Это, в частности, потому, что российское DPA не является формально независимым, но подчиняется Министерству цифрового развития, связи и массовых коммуникаций.

Хотя местный закон о персональных данных чем-то напоминает Директиву ЕС о защите данных, есть множество причин считать, что хранение данных в России создает дополнительный риск для прав и свобод субъектов данных по сравнению с ЕС.

Как подробно описано в главе «Руководство по основным европейским гарантиям», посвященной Российской Федерации, российский закон о расследованиях не в полной мере соответствует уровню гарантий, предоставляемых европейским законодательством. Возможно, даже более актуальным для обсуждаемого вопроса является то, что закон предписывает (часть так называемого пакета Яровой), чтобы операторы связи сохраняли трафик, который они передают, в течение определенного периода времени и раскрывали его российским правоохранительным органам по запросу.

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

Преимущества шифрования

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

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

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

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

Такая настройка может рассматриваться как дополнительная гарантия для целей оценки рисков субъекта данных в соответствии с GDPR и, таким образом, снимет по крайней мере некоторые из опасений, поднятых в предыдущем разделе этой статьи.

Важно отметить, что предлагаемое решение сопряжено с риском и должно быть тщательно продумано перед внедрением.Невозможно исключить, что суды встанут на сторону регулирующего органа в том, что контролер не смог продемонстрировать соблюдение требований к удовлетворению регулирующего органа и, следовательно, должен быть оштрафован. Также стоит отметить, что правила шифрования в России довольно непрозрачны, и перед их применением следует обратиться за профессиональной юридической консультацией.

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

В написании статьи приняли участие начальник управления по связям с общественностью Вадим Перевалов и соучредитель РППА Алексей Мунтян.

Фото Ирины Гроткьяер на Unsplash

Конфиденциальность, защита и кибербезопасность данных — Россия

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

Субъекты российской «критической информационной инфраструктуры» имеют обременительные меры по обеспечению кибербезопасности и нарушают обязательства по отчетности в соответствии с Федеральным законом о безопасности критической информационной инфраструктуры Российской Федерации (187-ФЗ от 2017 г.), вступившим в силу в июле. 2017. Этот закон регулирует, как отечественные и иностранные операторы финансовых услуг, телекоммуникаций, транспорта (включая порты), энергетики, добывающей промышленности, здравоохранения, химической промышленности и других секторов должны защищать свои данные.Лица, подпадающие под действие закона, должны установить адекватные средства защиты информации и сообщать о некоторых кибератаках и аналогичных инцидентах регулирующим органам. Этот закон похож, но не идентичен аналогичным законам, принятым в Европейском Союзе и Китае: поэтому компании должны обеспечивать соответствие своих глобальных программ кибербезопасности российскому законодательству.

Также существуют значительные ограничения на сбор и обработку личной информации граждан или жителей России.В частности, Федеральный закон «О персональных данных» (152-ФЗ от 2006 г.) регулирует поведение тех, кто обрабатывает и использует персональные данные в России и / или в отношении российских граждан. Особое внимание уделяется регистрации в регулирующем органе, получению согласия субъектов данных и предоставлению субъектам данных доступа к данным по запросу.

Eversheds Sutherland дает своим клиентам практические советы по соблюдению требований в этой области. Если местное законодательство неоднозначно, мы используем опыт фирмы в других юрисдикциях.Это позволяет нашим клиентам иметь оправданную политику соблюдения нормативных требований в соответствии с передовой международной практикой.

Семинар «152-ФЗ. Защита персональной информации. Как избежать проблем?» — Объявления

Семинар «152-ФЗ. Защита персональной информации. Как избежать проблем?»

Защита личных данных становится все более важной. Что такое классификация персональных данных, меры по их защите и штрафы за нарушение закона.Об этом и многом другом будет рассказано на семинаре «152-ФЗ. Защита персональной информации. Как избежать проблем?» , которая состоится в АНО «ПАПП» 25 сентября 2018 года в 15:00.

Среди вопросов для обсуждения:

• Защита персональных данных: мифы и реальность.
• Основные понятия
• Классификация персональных данных
• Какие личные данные?
• Перечень документов по защите персональных данных
• Шаги по защите ваших личных данных
• Результаты проверки Роскомнадзора
• Штрафы за нарушение закона
• GDPR — новые правила обработки персональных данных
• 10 мифов о персональных данных
• Советы по обработке персональных данных

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

Для получения дополнительной информации по телефону звоните по телефону 8 (863) 308-19-11 (доб. 313) или по [email protected] (контактное лицо: Наталья Хатламаджиян).

Опубликовано: 21.09.2018, 12:04:45

| Обновлено: 21.09.2018, 12:18:17

В Россию с любовью: развертывание Kubernetes в зарубежных странах

20-03-2019 / CloudOps

Несколько лет назад CloudOps начала работать с крупным европейским клиентом, который хотел перенести свои рабочие нагрузки на Google Cloud Platform (GCP).Они стремились модернизировать свое приложение с помощью контейнеров и использовать наиболее зрелый на то время дистрибутив Kubernetes: Google Kubernetes Engine (GKE). Они также хотели, чтобы их платформа приложений использовала библиотеки рецептов автоматизации на основе Terraform и Ansible. CloudOps помогла им пройти этот процесс миграции, и архитектура была завершена в марте 2018 года.

Развертывание Kubernetes в экзотических местах

Существующая архитектура, показанная на изображении слева, имела аппаратный балансировщик нагрузки, который служил в качестве точка входа и могла обслуживать контент как из нашей CDN, так и из фактического приложения, работающего внутри Kubernetes.Архитектура состояла из множества компонентов. Redis использовался для кеширования сеанса. Fluentd был контейнером журналов, который напрямую интегрировался с GCP StackDriver. Мы создали настраиваемый контейнер Fluentd, который вошел в настраиваемый стек ELK. Все эти компоненты пришлось перенести на локального провайдера в России.

Архитектура соответствовала ключевым техническим и бизнес-требованиям наших клиентов. Однако у них было большое количество клиентов в Российской Федерации, что требует суверенитета российских данных для всех лиц в России (через 152-ФЗ).Поэтому нашему клиенту потребовалось расширить свою контейнерную инфраструктуру в GCP с помощью решения, размещенного в России. На пути было несколько шагов.

Как найти облачного провайдера

На сегодняшний день в России нет гипермасштабируемых облачных провайдеров, включая GCP, поэтому традиционное локальное решение для виртуальных машин было единственным вариантом.

Первым шагом был поиск локального провайдера в России. Мы оценили около пяти, и все они сильно различались по качеству. В конце концов мы выбрали поставщика на основе VMWare CloudDirector, который имеет полностью совместимую среду 152-FZ и может похвастаться несколькими плагинами Terraform.

Автоматизация и / или инициализация виртуальных машин

У облачного провайдера был плагин провайдера Terraform, но его было сложно использовать из-за географического расстояния между их серверами API и нашими командами. Это делало состояния ненадежными и приводило к множеству тайм-аутов. Кроме того, плагины использовали устаревшие версии продуктов VMWare, которые были несовместимы.

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

Нашим хостам требовалось работать с двумя разными вариантами базовых образов Debian 9, с корневыми дисками 40 и 100 гигабайт соответственно. Мы создали базовый образ для запуска автоматизации, чтобы защитить виртуальные машины, которые можно было бы использовать для построения инфраструктуры. Это был очень ручной и трудоемкий процесс, но он позволил нашим вычислительным ресурсам добраться до России. Со временем пользовательский интерфейс стал проще в использовании.

Интерфейс сам по себе был забавной историей. Это была старая версия Cloud Director с административным пользовательским интерфейсом на основе Flash.Они рекомендовали нам использовать Internet Explorer, чтобы убедиться, что все его функции работают. Это должно вызвать у читателя множество красных флажков, как и у автора. Выбирая осторожность, мы запускали пользовательский интерфейс внутри выделенной виртуальной машины в течение нескольких месяцев, прежде чем доверять приложению. К счастью, пользовательский интерфейс работает без проблем уже больше года. Нам удалось подготовить все виртуальные машины и перейти к следующему шагу.

Выбор дистрибутива Kubernetes

Поскольку мы не могли использовать или расширять какой-либо сервис Kubernetes, управляемый общедоступным облаком, а именно GKE, EKS или AKS, нам пришлось найти дистрибутив Kubernetes, который был бы полностью автономным и простым в эксплуатации.

Мы не хотели использовать Kubespray или Kubeadm, поскольку оба они слишком долго устанавливаются и сложны в настройке и запуске. У них обоих исторически были проблемы с созданием конфигураций с несколькими мастерами, и они были известны тем, что в долгосрочной перспективе усложняли работу с кластерами.

Мы решили использовать Rancher Kubernetes Engine (RKE), который я считаю лучшим пользовательским установщиком Kubernetes на сегодняшний день. Все, что RKE требует для установки кластеров Kubernetes, — это виртуальная машина, которая запускает Docker и предпочтительно совместима с версией Kubernetes.Вы все еще можете запускать несовместимые версии, но есть больше рисков. Вам также понадобится вход по SSH, но это действительно так!
Есть много причин, по которым RKE все чаще рассматривается как лучший дистрибутив Kubernetes с открытым исходным кодом. Chick-fil-A написал интересную статью, объясняющую, почему они тоже пришли к такому выводу.

Operating Rancher Kubernetes Engine

Чтобы запустить RKE, мы загрузили единственный двоичный файл «rke» и создали единственный файл YAML, который будет определять наш кластер Kubernetes.

RKE имеет набор команд для работы, установки или вывода кластеров из эксплуатации. Основная команда «rke up» подключит туннели SSH, определит состояние вашего кластера, а затем запустит установку Kubernetes.

Это все вместе позволяет вам запускать Kubernetes полностью внутри образов Docker, которые поступают из Rancher. У нас ушло пять минут на загрузку кластера Kubernetes с тремя главными узлами и пятью рабочими узлами. Мультимастер работал «из коробки» с полностью распределенным etcd.После подготовки кластера двоичный файл RKE завершит работу и выведет сертификат клиента KUBECONFIG, который можно использовать для взаимодействия с кластером. Настройка конфигурации была простой с RKE.

 спецификации:
        imagePullSecrets:
        - имя: my-gcr-secret
      узлы:
        адрес: мастер
        порт: «22»
        роль:
        самолет управления
        etcd
        рабочий
      Сервисы:
        Кубе-апи:
        Service_cluster_ip_range: 10.43.0.0/21
      сеть:
        плагин: канал
      аутентификация:
        стратегия: x509
      ssh_key_path: «/ путь / к / ключу»
      авторизация:
        режим: rbac
      ignore_docker_version: правда
      докер
      имя_кластера: «мой-кластер»
 

На изображении слева показан минимальный файл конфигурации RKE, показывающий, что необходимо установить.По крайней мере, вам понадобится один узел, который вы определяете как плоскость управления, etcd, рабочий узел или любую их комбинацию. Определите диапазоны IP-адресов для ваших модулей и служб. В нашем случае мы использовали канал CNI. Это означало, что нам не нужно было выбирать адреса, которые можно маршрутизировать за пределы кластера, поскольку они были инкапсулированными пакетами. Выберите любой разумный диапазон — я считаю, что 10,43 — хороший диапазон. Определите кластерный DNS-сервер (11-й IP диапазона адресов службы является стандартным, поэтому.10). Наконец, включите RBAC и скажите ему игнорировать версии Docker.

RKE прост в установке и известен своим простым управлением жизненным циклом.

Чтобы добавить новые узлы, просто добавьте их в соответствующий раздел в cluster.yaml и снова запустите «rke up».

Чтобы списать узлы, удалите их из cluster.yaml и запустите «rke up».

Вы также можете исправить определенные компоненты Kubernetes без обновления всего кластера, изменив образ Docker на нужную версию.
Чтобы полностью обновить Kubernetes, настройте cluster.yaml, добавьте новый двоичный файл и запустите «rke up». RKE выполнит циклические перезапуски и обновления. Что бы вы ни делали, помните, что при обновлении нельзя пропускать промежуточные версии.

Поиск ключевых функций облака

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

— Возможность взаимодействия с Google Container Registry для извлечения образов
— Аналог CloudSQL
— Интерфейс хранилища контейнеров (драйвер CSI), который может включать постоянные тома и требования к постоянным томам
— Балансировщик нагрузки
— Аналог для Google Object Storage
— Аналог для CloudCDN

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

Реестр контейнеров Google

Для получения изображений из реестра контейнеров Google мы использовали удаленный секрет Kubernetes из GCR за пределами GCP. Мы смогли это сделать, потому что ни одно из этих изображений не содержало данных о клиентах. Имея правильный секрет Kubernetes, легко включить удаленное извлечение изображений из GCR за пределами GCP:

 apiVersion: v1
      данные:
        .dockerconfigjson: BASE64_ENCODED_SERVICE_ACCOUNT_JSON_KEY
      вид: Секрет
      метаданные:
        имя: my-gcr-secret
        пространство имен: по умолчанию
      тип: кубернетес.io / dockerconfigjson
 

И затем используйте этот секрет манифест развертывания:

 spec:
            imagePullSecrets:
            - имя: my-gcr-secret
 

Аналог для CloudSQL

Чтобы решить, как запустить CloudSQL в локальной среде, нам просто нужно было установить MySQL.

Мы использовали тот же образ Debian 9, что и в кластерах Kubernetes. Мы смогли использовать некоторые из наших существующих сценариев Ansible для настройки MySQL 5.7.

Мы выполнили стандартное развертывание одного ведущего устройства с двумя ведомыми устройствами.Один был рабом в реальном времени для составления отчетов и аварийного переключения. Другой был рабом с задержкой по времени, который отправлял бинарные журналы мгновенно, но не применял их в течение тридцати дней. Это позволило нам восстановить их на определенный момент времени, даже если имело место репликационное повреждение.

CloudSQL и Google Container Registry были довольно простыми проблемами для решения.

Storage Solution — CDN

Object Storage требовало более интересного решения.

В то время Rook / Ceph не были готовы к производству в локальной среде, поэтому мы использовали GlusterFS, готовую технологию от RedHat, чтобы обеспечить функциональность объектно-подобного хранилища.

Мы настроили два узла NGINX Ingress для обслуживания контента из GlusterFS в качестве сети доставки контента (CDN), а также в качестве обратного прокси для портов NodePorts и Ingress службы кластера Kubernetes.

Каждый узел Ingress получает реплицированные данные в GlusterFS на выделенном блоке устройства и обслуживает данные из GlusterFS по определенному пути для всех данных CDN.

Затем том GlusterFS будет смонтирован на рабочих узлах Kubernetes для чтения / записи и добавлен в развертывание как том HostPath в / cdn-data.Это позволит каждому модулю записывать контент для CDN.

Это подходящее решение для объектного хранилища и CDN.

Storage Solution — Redis

В зависимости от того, какой вариант Redis вы используете, вам может потребоваться использование утверждений постоянного тома для хранения его данных в кэшах сеанса. Мы использовали версию Redis для Helm в качестве кеша сеанса, для которого требуются PVC. Поскольку у нас не было возможности PVC, мы временно перенастроили приложение для использования базы данных SQL в качестве кеша сеанса вместо Redis в качестве обходного пути.

Окончательное решение для хранения — Rook / Ceph

В декабре 2018 года на Kubecon в Сиэтле Rook / Ceph был продвинут в CNCF как «инкубирующий» проект, а драйвер Ceph был помечен как готовый к производству. Мы решили, что пришло время начать использовать эту технологию, хотя и в ограниченном объеме: для обеспечения постоянного хранилища для Redis Session Cache и, возможно, для компонентной части ElasticSearch ELK. Таким образом, если мы столкнемся с операционными трудностями с Rook / Ceph, мы в лучшем случае потеряем данные регистрации (а не конец света), а сеансы станут недействительными (что также не имеет большого значения, условно говоря).

Для файла cluster.yaml RKE требуется небольшое изменение конфигурации, чтобы позволить ему использовать драйвер CSI, который Rook установит после запуска:

 kubelet:
       extra_args:
        объем-плагин-каталог:
      / usr / libexec / kubernetes / kubelet- плагины / объем / exec
       extra_binds:
        -
/ usr / libexec / kubernetes / kubelet-plugins / volume / exec: / usr / libexec / kubernetes / kubelet-plugins / volume / exec
 

Запуск «rke up» в существующем кластере исправит это на месте.

Наконец, мы можем добавить репозиторий Rook Helm Chart в нашу локальную установку Helm и установить Rook Operator (v0.9.3 на момент написания):

 helm repo add rook-stable https://charts.rook.io/ stablehelm install --namespace rook-ceph-system rook-stable / rook-ceph
 

Оттуда мы использовали примеры в дереве исходных текстов Rook, расположенном в / cluster / examples / kubernetes / ceph , чтобы создать ‘кластер Ceph’ (cluster.yaml) и класс хранения (storageclass.yaml) для выделения Ceph Replica Pool и свяжите его вместе с классом хранения Kubernetes (называемым rook-ceph-block ).

ВАЖНО : значения по умолчанию здесь определенно не готовы к производству. В частности, элемент конфигурации replicated.size в storageclass.yaml по умолчанию равен 1. Это означает, что каждый бит данных, хранящихся в кластере Rook / Ceph, существует только один раз. В зависимости от количества узлов в вашем кластере вы можете увеличить это количество. Для нашего случая использования в производстве мы использовали replicated.size: 3

Теперь мы можем использовать Redis, указав ему использовать этот класс хранилища с помощью Helm.

 helm install --name = redis stable / redis \
      --set master.persistence.storageClass = ладья-цеф-блок \
      --set slave.persistence.storageClass = rook-ceph-block
 

Найдите решение для ведения журнала

Fluentd — это фактический стандартный агент ведения журнала для Kubernetes, который также используется GKE. Он реализован на Ruby и имеет в разработке нединамический агент на основе языка (называемый fluent-bit).

Он имеет множество подключаемых модулей ввода и вывода и находится в активной разработке в течение нескольких лет.Нам нужно, чтобы наше решение для ведения журналов представляло собой комплексную конфигурацию мониторинга для Kubernetes, имело нормальный анализ журнала приложений из коробки и переходил в ElasticSearch (E от ELK).

Для этого нам пришлось использовать специальную конфигурацию. Версия 1.2 зависит от нестандартной библиотеки Debian, которая существует на рабочем узле, и в случае ее отсутствия вызывает очень высокую нагрузку. Готовый JSON при синтаксическом анализе JSON не работал. Мы обнаружили, что это лучшая версия образа FluentD для нашего варианта использования:

 fluent / fluentd-kubernetes-daemonset: v1.3.1-debian-elasticsearch-1.3
 

Мы добавили следующую конфигурацию к образу Fluentd kubernetes.conf , чтобы включить правильный анализ JSON журналов наших приложений и привести некоторые типы элементов журнала для облегчения поиска в ElasticSearch:

 @type parser
 
  @type json
    json_parser json
    типы elapsed_time: float, status_code: integer, bytes_sent: integer
  
  replace_invalid_sequence истина
  emit_invalid_record_to_error false
  key_name log
  Reserve_data истина
  

Мы поместили все содержимое в конфигурационную карту под названием «fluentd-config» с единственным ключом «kubernetes».conf ’, который содержал всю конфигурацию fluentd. Затем мы смонтировали эту конфигурацию в FluentD, переопределив kubernetes.conf изнутри образа:

 тома:
- имя: fluentd-config
configMap:
имя: fluentd-config
 
 Объем 
    - имя: fluentd-config
      subPath: kubernetes.conf
      mountPath: /fluentd/etc/kubernetes.conf
  

Дополнительные вычислительные ресурсы

В российской установке изначально был отдельный выделенный кластер ELK (3 виртуальных машины для высокой доступности).Он был как недоиспользованным, так и избыточным.

Мы хотели использовать вычислительные ресурсы в кластере Kubernetes и запустить ELK внутри. Для этого мы смогли использовать официальную диаграмму Elastic-Stack Helm.

Мы стерли виртуальные машины кластера ELK с помощью свежего образа Debian 9, а затем добавили старые узлы ELK в файл RKE ‘cluster.yaml’ в качестве ‘рабочих’ узлов и затем запустили ‘rke up’. Через несколько минут вычисление мощность из кластера ELK была перемещена в кластер Kubernetes.

Наконец, мы установили ELK с помощью Helm:

 helm install –name elk stable / elastic-stack 
 –set elasticsearch.data.persistence.size = 50Gi 
 –set elasticsearch.data.persistence.storageClass = rook-ceph-block 
 –set elasticsearch.master.persistence.storageClass = rook-ceph-block 
 –set kibana.env.ELASTICSEARCH_URL = http: // elk-elasticsearch-client: 9200
 

ВАЖНО: Настройки Kubernetes по умолчанию для ELK предполагают определенный профиль производительности. Конфигурация памяти JVM Heap по умолчанию для ElasticSearch довольно низкая по сравнению с автономным (за пределами Kubernetes) кластером, поэтому имейте в виду, сколько данных вы отправляете туда ежедневно.Вы ДОЛЖНЫ использовать куратора для закрытия индексов и, в конечном итоге, их очистки. Для нашего случая использования мы решили хранить в памяти 3 дня открытых индексов и обрезать данные старше 90 дней. Вы можете оставить индексы в памяти дольше и, следовательно, увеличить размер кучи JVM для ElasticSearch Server, который можно установить с помощью значения переопределения на диаграмме Helm.

Балансировка нагрузки

У российского поставщика облачных услуг не было возможности назначить аппаратные балансировщики нагрузки для инфраструктуры.В решении, которое мы решили использовать, было два узла NGINX Ingress и циклическое разрешение DNS для каждого запроса. Это было адекватное решение, которое могло реверсировать весь трафик через прокси на 80 и 443, обслуживая трафик CDN на другом пути. В нашем решении не использовалось завершение SSL, что могло привести к сбросу некоторых сеансов SSL. Вместо этого мы использовали контроллер NGINX Ingress в Kubernetes.

Конечное состояние

На пути возникло несколько неожиданных проблем, но мы смогли успешно создать локальное расширение для российской инфраструктуры GCP нашего клиента.Нам пришлось адаптировать наши обычные процессы, и развертывание в России сильно отличалось от основной инфраструктуры, но в итоге все работало хорошо. Процесс развертывания Kubernetes on prem занял немного больше времени, поскольку мы не могли полагаться на наши проверенные и проверенные рецепты и процессы. Тем не менее было приятно видеть, как инфраструктура работает.

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

Россия: Страновой отчет о свободе в сети за 2020 год

Российские власти регулярно ограничивают доступ к конфиденциальному политическому и социальному контенту в Интернете. Ссылаясь на ряд оправданий, они также ограничивают или пытались ограничить многие социальные сети и коммуникационные платформы. По неофициальным данным, на конец 2019 года в России было заблокировано более 4,74 млн интернет-ресурсов. Официально в черный список попало всего около 315 000 интернет-ресурсов.

Популярное приложение для обмена сообщениями

Telegram оставалось официально заблокированным в России до конца периода покрытия. В апреле 2018 года районный суд постановил заблокировать Telegram за отказ соблюдать Закон Яровой, который обязывает приложение предоставлять свои ключи шифрования правительству (см. C4). Официальные лица неоднократно заявляли, что Telegram используется в террористических целях. Telegram использовал различные методы для преодоления первоначальной блокировки, в том числе использование альтернативных услуг облачного хостинга.Затем Роскомнадзор нацелился на многие из этих сервисов, включая Alibaba Cloud, Amazon Web Services, Google Cloud и Microsoft Azure, что привело к обширной блокировке залогового обеспечения. В какой-то момент было заблокировано более 18 миллионов IP-адресов, что повлияло на интернет-магазины, банки, системы продажи авиабилетов, новостные сайты и другие социальные сети и коммуникационные платформы, такие как Viber и Odnoklassniki (OK). В январе 2019 года Роскомнадзор дал понять, что ослабляет режим блокировки, объявив, что он разблокировал 2.7 миллионов IP-адресов Amazon Web Services. Однако в конце мая 2020 года более 675000 IP-адресов оставались заблокированными в связи с заказом Telegram, согласно проекту мониторинга.

После периода освещения в июне 2020 года правительство внезапно отменило запрет на Telegram, сославшись на «готовность» его основателя «противостоять терроризму и экстремизму». Причины этого поворота неясны. Наблюдатели предположили, что правительство, осознав практическую невозможность ограничения доступа к приложению, искало подходящий момент, чтобы разблокировать его.Момент наступил после кадровой перестановки в Роскомнадзоре — уходящий в отставку глава Александр Жаров публично заявил, что Telegram будет оставаться заблокированным до тех пор, пока он не будет соответствовать закону Яровой, чего, по всей видимости, до сих пор нет, — и на фоне пандемии COVID-19, во время которого власти использовали Telegram для общения с общественностью.

Несмотря на попытки властей ограничить доступ к нему, Telegram оставался доступным для российских пользователей. В течение периода покрытия большинство из них продолжало достигать Telegram без виртуальной частной сети (VPN), поскольку его разработчики реализовали функцию автоматического прокси для обеспечения неограниченного доступа.

Другие приложения для обмена сообщениями оставались заблокированными в течение периода действия покрытия. В 2017 году Zello был заблокирован Роскомнадзором за отказ передать свои ключи шифрования в соответствии с Законом Яровой и за отказ зарегистрироваться в качестве «организатора распространения информации» в соответствии с Законом об информации, информационных технологиях и защите информации, который предоставлял властям доступ к большая часть данных службы (см. C6). BlackBerry Messenger, Imo, Line и Vchat были заблокированы по аналогичным причинам в 2017 году.

Веб-сайты, содержащие контент, затрагивающий множество деликатных тем, также подлежат блокировке в соответствии с Законом об информации, информационных технологиях и защите информации и соответствующим законодательством. Запрещенный веб-контент формально включает изображения сексуального насилия над детьми; контент, связанный с незаконной продажей алкоголя; информация о запрещенных наркотиках; информация о незаконных азартных играх; призывы к самоубийству; призывает к экстремистской деятельности, беспорядкам или несанкционированным протестам; нарушения авторских прав; нарушения законодательства о защите данных; и информацию об обходе цензуры в Интернете (см. B3).В октябре 2019 года независимое информационное агентство Fergana News было заблокировано за сообщение о самоубийстве. Другие категории контента также подвергаются цензуре на менее формальной основе.

Ряд различных государственных органов имеют право распоряжаться о блокировке веб-контента (см. B3). Например, в 2019 году МВД заблокировало почти 21 тысячу интернет-ресурсов, содержащих информацию о запрещенных наркотиках. В том году Генеральная прокуратура заблокировала 81 тысячу веб-сайтов, на которых якобы размещался экстремистский контент.Однако Федеральное агентство по делам молодежи, которое может приказать заблокировать контент, побуждающий несовершеннолетних к нарушению закона, в этом отношении относительно бездействует, инициировав всего 10 блокировок к марту 2020 года. Суды также имеют широкие полномочия для блокировки веб-контент.

VPN недавно столкнулись с давлением со стороны властей. В письме от марта 2019 года Роскомнадзор попросил 10 поставщиков услуг VPN ограничить доступ пользователей к сайтам, заблокированным в России. Если они не выполнят этого требования, Роскомнадзор пригрозил «ограничить доступ» к самим VPN-сервисам.В июне 2019 года Роскомнадзор объявил, что только одна компания, российская Kaspersky Secure Connection, выполнила его запрос. Агентство заявило, что остальные девять VPN-сервисов будут в ближайшее время заблокированы, но несколько дней спустя Жанов заявил: «Мы можем дождаться принятия нового закона о штрафах» за несоблюдение правил, связанных с Интернетом. Однако рассматриваемый закон, принятый в конце 2019 года (см. B3), не содержал никаких положений, касающихся услуг VPN. К маю 2020 года Роскомнадзор не предпринимал попыток заблокировать эти сервисы.

Другие инструменты обхода цензуры и шифрования подверглись официальной проверке. В марте 2019 года выяснилось, что два крупнейших российских интернет-провайдера, МТС и Ростелеком, ограничили трафик на несколько узлов анонимного веб-браузера Tor, а также на серверы простого протокола передачи почты (SMTP) ProtonMail, зашифрованного почтового сервиса. Это дело создало прецедент для ограничения доступа к зашифрованным сервисам, поскольку Федеральная служба безопасности (ФСБ) прямо потребовала, чтобы поставщики телекоммуникационных услуг наложили блокировку на ProtonMail, не прося Роскомнадзор сначала попытаться зарегистрировать сервис в качестве «организатора распространения информации».«Согласно установленной процедуре, отказ ProtonMail в регистрации позволил бы Роскомнадзору инициировать процедуру блокировки. Впоследствии ProtonMail ввел специальные технические функции для предотвращения ограничений трафика в России.

В начале 2020 года органы национальной безопасности России инициировали новую кампанию по блокировке зашифрованных почтовых сервисов, якобы в ответ на растущее количество ложных и анонимных электронных писем, в которых сообщается о наличии взрывных устройств в общественных местах.Официальные лица нацелены на такие службы, как Tutanota, SCRYPTmail, StartMail и ProtonMail, утверждая, что они способствуют призыву к экстремистской деятельности.

В феврале 2020 года ProtonMail согласился соблюдать Закон об информации, информационных технологиях и защите информации, удалив поддельные учетные записи из своей службы. В то же время компания со штаб-квартирой в Швейцарии заявила, что будет предоставлять данные о пользователях российским властям только на основании решений швейцарских судов.По состоянию на май 2020 года некоторые российские интернет-провайдеры все еще ограничивали доступ к ProtonMail. Также в феврале 2020 года Mailbox.org, другой сервис зашифрованной электронной почты, которому угрожала блокировка, согласился зарегистрироваться в качестве «организатора распространения информации».

Попытки заблокировать эти сервисы не полностью поддерживаются российским законодательством. Помимо блокировки их по IP-адресам, власти потребовали, чтобы российские почтовые службы не позволяли своим пользователям получать сообщения от StartMail и ProtonMail.Этот механизм блокировки не отражен в действующем законодательстве, но будет предусмотрен законопроектом, внесенным в нижнюю палату парламента в октябре 2019 года, который еще не прошел даже первое чтение (см. B3). Поскольку органы национальной безопасности сочли ложные и анонимные сообщения очень деликатной проблемой, они предприняли меры для ограничения таких сообщений до того, как была создана необходимая правовая основа.

Закон 2015 года позволяет правительству относить иностранные организации к категории «нежелательных», что запрещает им распространять информацию (см. B3).По состоянию на май 2020 года всего 22 иностранные организации, в том числе «Открытая Россия», неправительственная организация, основанная кремлевским критиком Михаилом Ходорковским, и Фонд «Открытое общество», созданный филантропом Джорджем Соросом, были перечислены как нежелательные; в некоторых случаях их веб-сайты заблокированы. В течение периода освещения Генеральная прокуратура добавила в список семь иностранных организаций, в том числе базирующийся в США Атлантический совет, Фонд «Свободная Россия» и Фонд Джеймстауна, а также базирующуюся в Чехии организацию «Люди в нужде».Были заблокированы сайты Фонда «Свободная Россия» и «Люди в беде», а сайты Атлантического совета и Фонда Джеймстауна остались доступными.

Правила локализации персональных данных (см. C6) используются правительством в качестве предлога для ограничения доступа к определенным веб-сайтам. В 2016 году LinkedIn стала первой крупной международной платформой, заблокированной в России за несоблюдение требований локализации данных, и остается самой заметной блокировкой в ​​своем роде.Руководство Роскомнадзора неоднократно заявляло о необходимости применения аналогичных мер в отношении Twitter и Facebook. Однако в апреле 2019 года обе компании были оштрафованы на символическую сумму в 3000 рублей (45 долларов США) за несоблюдение требований. Законодательные поправки, принятые в конце ноября 2019 года и подписанные президентом Путиным в декабре, постепенно увеличивают такие штрафы до тех пор, пока они не станут достаточно большими, чтобы повлиять на доходы компаний, не подвергая их платформы угрозе блокировки. Помимо неоднократных нарушений требований локализации данных, более строгие штрафы могут быть наложены за незаконную деятельность аудиовизуальных сервисов, несоблюдение поисковыми системами системы черного списка России и отказ приложений для обмена сообщениями предоставить органам национальной безопасности ключи шифрования по их запросу (см. B3).В феврале 2020 года суд оштрафовал Twitter и Facebook на 4 миллиона рублей (62000 долларов США) каждый после того, как они не успели уложиться в срок, чтобы сообщить Роскомнадзору о соблюдении правил локализации данных. Однако по состоянию на конец периода страхового покрытия обе компании, как сообщается, не уплатили штрафы.

Практическое руководство по законам о конфиденциальности данных по странам

В США нет единого всеобъемлющего законодательства о конфиденциальности данных. Вместо этого страна придерживается секторального подхода к конфиденциальности данных, полагаясь на лоскутное одеяло отраслевых законов и законов штата.

Фактически, США полагаются на «сочетание законодательства, регулирования и саморегулирования», а не только на вмешательство государства. Существует около 20 отраслевых или отраслевых федеральных законов и более 100 законов о конфиденциальности на уровне штата (фактически, только в Калифорнии существует 25 законов о конфиденциальности).

Закон Калифорнии о конфиденциальности потребителей (CCPA) дает жителям Калифорнии четыре права, которые дают им больше полномочий в отношении своих личных данных: право на уведомление, право на доступ, право выбора (или отказа) и право на равные услуги.Любая организация, которая собирает персональные данные жителей Калифорнии, а не только предприятия, расположенные в штате, должна соблюдать CCPA. Подробнее о соблюдении CCPA см. Здесь .

1 января 2023 года в Вирджинии вступит в силу Закон о защите данных потребителей (CDPA). По закону компании, ведущие бизнес в штате, должны получать разрешение от пользователей на обработку своих данных. Это также дает потребителям право просматривать, получать, удалять и исправлять свои данные.В отличие от CCPA, компании должны разрешить резидентам отказаться от участия только в том случае, если они будут продавать данные для получения финансовой выгоды. Подробнее о CDPA здесь .

Наиболее известные национальные законы включают Закон о конфиденциальности 1974 г., Закон о защите конфиденциальности 1980 г., Закон Грэмма-Лича-Блайли 1999 г., Закон 1996 г. о переносимости и подотчетности медицинского страхования, Закон о справедливой кредитной отчетности 2018 г.

No related posts.