152-фз

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• низкая эластичность;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2018 год. Россертификация

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

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

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

В самом вложении также в шапке красуется Россертификация. Пока не понятно, это действительно госконтора или ООО, или еще что-то другое. А вот ниже уже интереснее указаны реквизиты ИНН, КПП, ОГРН и ОКПО. Быстрый поиск в ЕГРЮЛ дает нам результат это данные некоего ООО Единый центр сертификации. Запомним это и едем дальше, осознавая, что подобные предписания без каких-либо договоров, например на аттестационные испытания, не имеет права выдавать ни одно ООО.

Далее нам вешают лапшу о начале внеплановых проверок с 1 апреля 2018 года, как будто ранее РКН не проводил внеплановых проверок по персональным данным. В этом же предложении жирным шрифтом акцентируется, что якобы все организации должны уведомить РКН об обработке персональных данных, хотя в части 2 статьи 22 Федерального закона 152-ФЗ О персональных данных приводится целых 9 пунктов исключений, когда оператор ПДн может не подавать такое уведомление.

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

И под конец моё любимое страшилка про закрытие предприятия на 90 суток за невыполнение закона О персональных данных. Я думал, что недобросовестные коллеги оставили эту байку в 2010 году как максимум. И, конечно же, такой нормы нет в упомянутой статье 13.11 КоАП РФ здесь просто прямое вранье (с этого момента можно начинать считать сколько раз в этой статье будет употреблено слово вранье)! А тем, кто не знает/не помнит откуда пошла эта страшилка, добро пожаловать под спойлер.

Смотрим дальше текст вложения.

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

Кстати, в этом месте документа по идее должна быть гиперссылка на сайт, но ее нет. Но тогда, в 2018 году, он нашелся методом беглого гугления, сайт находился по адресу 152-фз.россерт.рф. Находился, т. к. сайт больше недоступен, Wayback Machine выдает что-то внятное только за 2019 год. А мы их анализировали и успели наделать скриншотов в 2018-м (судя по архивному отпечатку, в 2019 году текст сильно поменялся, но не суть), и там тоже много чего важного, что поможет нам в будущем сделать кое-какие выводы, давайте посмотрим.

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

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

Дальше нас учат, как же соответствовать закону о персональных данных. Якобы нужно разработать пакет документов и получить на них сертификат соответствия ГОСТ. Стоп, чего? Про пакет документов, в общем-то, правда, да только вот кроме документов, чтобы соответствовать 152-ФЗ нужно еще и выполнить технические мероприятия, поэтому будем считать, что тут не вранье, а недоговорка. А вот про необходимость соответствия комплекта документов по защите персональных данных какому-либо ГОСТ это чистой воды вранье.

Далее нас ожидаемо пугают штрафами. То, что эти цифры не соответствуют действительности сейчас и не соответствовали тогда, мы уже разобрали, но обратите внимание что нижние и верхние границы штрафов не соответствуют таковым в спам-письме. Снова бородатая страшилка про закрытие организации на 90 суток. И лютейший бред про возможное лишение свободы руководителя на срок до 4 лет по 137 УК РФ за нарушение закона О персональных данных (эта статья о злонамеренном сборе и распространении данных о частной жизни физического лица с использованием служебного положения за уши конечно можно притянуть, но все же надо понимать, что такое деяние и отсутствие в организации необходимых документов по 152-ФЗ это совсем разные вещи).

Дальше нам предлагают скачать даже на тот момент сильно устаревшую версию 152-ФЗ. И, конечно же, классика мошенники предупреждают о мошенниках.

Но самое интересное ждало нас в конце сайта.

В разделе Лицензия и аккредитация собственно нет никакой лицензии (да неужели? нас опять обманывают?), зато есть свидетельство о регистрации системы добровольной сертификации Россертификация. Помните, в самом начале я говорил, что мы не понимаем что такое Россертификация и Россерт - теперь понятно, это СДС (система добровольной сертификации).

Что такое СДС? В соответствии с 21 статьей ФЗ О техническом регулировании любое юрлицо или ИП могут учредить такую систему сертификации, например орехов. Вы определяете параметры (вкус, форма, цвет) орехов, на которые вы будете выдавать сертификат и те, кто хотят сертифицировать свои орехи в вашей СДС (которую вы конечно же зарегистрировали в Федеральном агентстве по техническому регулированию и метрологии) заключают с вами договор, проводят необходимые испытания и получают или не получают сертификат.

Нужно еще отметить, что зарегистрировать ООО с приставкой Рос- ой как не просто. Есть целый список требований, чтобы это было возможно. Видимо, у СДС с этим все гораздо проще. Отмечаем так же, что свидетельство о регистрации СДС выдано ООО Единый центр сертификации. Реквизиты (ИНН, ОГРН) ООО с таким же названием фигурировали и в шапке спам-письма.

2020 год. Росконтроль

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

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

Давайте посмотрим, чем это письмо отличается от образца 2018 года.

Во-первых, теперь это не предписание, а отчет по результатам проверки. Теперь не Россертификация, а Росконтроль и явно указано, что это СДС. Ссылка на другой сайт -rkn.expert (он по сравнению с предыдущим ну совсем маленький и не интересный, поэтому даже подробно анализировать там нечего). Другой телефон. Другой адрес (хотя тоже Питер). Также обращаем внимание на URL сайта, попахивает мимикрией под официальный сайт РКН (rkn.gov.ru).

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

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

Давайте закончим с шапкой письма, ведь здесь самое важное отличие от спама 2018 года теперь здесь фигурирует персоналия, некий Келлерманн А. М. Вот это уже интересно!

Давайте проверим по реестру, не связан ли этот Келлерманн А. М. с нашими старыми знакомыми ООО Единый центр сертификации? Идем в любой каталог организаций и ищем по ИНН. Вот черт! Генеральный директор этой организации некий Катричко Александр Максимович, мимо!

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

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

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

Дальше у меня глаз зацепился за этот блок:

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

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

В четвертом разделе нас пугают уже многомилионными штрафами. Вот как Гермиона штрафы измениласьись за лето два года!

Как вы догадались, тут тоже вранье. Такими штрафами наказывают за отказ хранить данные граждан РФ на территории РФ, так называемая статья против фейсбука и им подобных. Обычное ООО, которое хранит базы 1С у себя на локальном сервере таким санкциям уж точно не подвержено, но звучит-то страшно, правда? 6 миллионов! А чего тогда господин Келлерманн не ссылается на п. 9 статьи 13.11 КоАП РФ, там за повторное нарушение по п.8 штраф аж до 18 миллионов. Еще страшнее!

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

Еще в этом же четвертом пункте "отчета" приводится список документов. В целом, список как список. Почему нет единого стандарта по составу комплекта документов можно узнать из нашей статьи, но меня смутил вот этот пункт:

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

Ладно, долистываем это письмо до конца. Помните, я говорил про персоналию в этом письме? Ниже он подписывается уже более подробно, теперь мы знаем его имя и у нас есть его фото.

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

Сначала из найденного я зашел на fl.ru. Фото другое, но rossertrf кричит нам, что это он. Там 6 фрилансеров ставят этому заказчику +, мол, молодец, платит вовремя и все такое. Видимо, там он заказывает сайты типа старого уже закрытого и rkn.expert . Ну, что ж, я надеюсь, что фрилансеры искренне не понимали, что помогают дурить людей.

А потом я зашел в его Instagram (профиль открыт) и тут началось. То, что это именно он, сомнений нет, там есть та же фотка, что и в "отчете" и фото с fl.ru тоже имеется. Бегло пролистав фотки с тачкой и котиком (котик классный, да), взгляд, конечно, же остановился на этой фотке и на посте под ней:

Ну, во-первых - Росконтроль. Обратите внимание на сайт на табличке (rkn.moscow) опять мимикрия под официальный сайт РКН (он просто редиректит на rkn.expert). Во-вторых, сам пост в стиле Вы все дураки и не лечитесь. Тут я не удержался и написал комментарий. Я, честно говоря, ни на что не надеялся, был уверен, что комментарий проигнорируют или удалят, но нет.

На что было получено 2 ответа и второй говорит сам за себя.

Кстати, да, Роскомнадзор действительно в курсе.

А еще в курсе другой Росконтроль, который СМИ.

Вместо заключения

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

Дело в том, что когда наши добросовестные коллеги предлагают людям свои услуги, нам потом не пишут и не звонят с вопросами Нам позвонил лицензиат ФСТЭК, предлагает свои услуги по защите информации, подскажите, стоит ли с ними работать?. И совершенно другая картина, когда людей заваливает спамом от рос-гос-чего-то-там со словами предписание и штраф до 6 млн. рублей, вот тогда мы можем терять много драгоценного рабочего времени на такие консультации, за которые мы денег не берем.

Кто-то может сказать, что г-н Келлерманн правильно написал в комментарии, что у него все зарегистрировано и так далее, и называть его мошенником не правильно, но у нас регистрировать ООО и ИП могут и экстрасенсы с гадалками, а гомеопаты совершенно официально продают в аптеках сахар по цене золота.

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

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

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

• попытка замещения функций государственных органов с помощью несуществующих "Федеральных программ" и "Федеральных центров";

• притягивание за уши санкций для операторов персональных данных (штраф 6 миллионов, статья 137 УК РФ, закрытие организации на 90 суток), абсолютно не применимых или никак не связанных с услугами, предлагаемыми спамерами;

• фишинговые техники. Вряд ли рядовой пользователь помнит точно домен РКН, в крайнем случае, если он ходил когда-то на их сайт, может помнить, что это rkn."че-то там". Таким образом, использование доменов rkn.expert и тем более rkn.moscow призваны ввести пользователей в заблуждение;

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

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

• оказание услуг по разработке проектной документации на систему защиты информации (Модель угроз) без лицензии ФСТЭК России;

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

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

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

Если у вас есть знакомые бухгалтеры, руководители небольших фирм (или даже больших) и другие лица, которым могла быть интересна эта статья, покажите им её.

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

Провайдеры же в качестве подтверждения соответствия требованиям регуляции демонстрируют на своих ресурсах два вида документов: аттестат или оценку эффективности. Сегодня вместе с Алексеем Афанасьевым ( #CloudMTS, ИТ-ГРАД), Дмитрием Пойгиным и Игорем Яковлевым (ООО НАЦ) разберемся, в чем отличия и какой вариант предпочтительнее и беспроблемнее.

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

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

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

Специфика работы с ПДн в облаке

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

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

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

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

• В аттестате фиксируется точное соответствие тому или иному уровню защищенности (УЗ) и классу защиты (К) с учетом всех требований ГОСТ, а ОЭ может лишь обозначать данное соответствие.

• Если сервисы провайдера аттестованы, разграничение зон ответственности можно, как правило, провести более четко.

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

Когда без аттестата не обойтись

Когда клиенту принципиально необходимо выбирать именно аттестованное решение?

• Если клиент планирует размещать в облаке ГИС. Оценка эффективности здесь не подойдет при прохождении процедуры аттестации самой информационной системы сослаться на ОЭ будет проблематично.

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

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

Оценка эффективности vs. аттестат

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

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

Как выбрать между аттестованным решением и сервисом с оценкой эффективности и не пожалеть о своем решении в будущем? Сравним оба документа.

Оценка эффективности

В первую очередь, необходимо понимать, что оценка эффективности не является документом по ГОСТу. Это документ, предполагающий оценку мер, которые были произведены для защиты ПДн, размещаемых в этой ИС.

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

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

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

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

Ситуация чем-то похожа на старую-добрую сказку.

Владелец ИС спрашивает:

Свет мой, зеркальце, скажи: я ль на свете самый облачный и защищенный?

Его собственное отражение отвечает:

Ты, конечно, спору нет. Вот тебе оценка эффективности. Твои клиенты будут рады;)) Аттестатом здесь и не пахнет, но в целом все надежно и утечь ничего не должно. Ну, по идее...

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

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

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

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

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

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

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

Аттестат

Чем же отличается аттестат?

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

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

Наличие у провайдера аттестата гарантирует некую неизменность условий функционирования системы, оказывающих влияние на информационную безопасность, в течение всего периода его действия. Иными словами, для конечного клиента не имеет значения, когда именно был аттестован облачный сервис, вчера или полгода назад. Если аттестат действителен, значит, требования регуляторов выполняются и решение соответствует требованиям безопасности. Так, например, облачные сервисы, имеющие аттестаты УЗ-1 и К1, проходят контрольные мероприятия ежегодно согласно требованиям регулятора.

Если так случится, что в аттестованном сервисе провайдера обнаружится уязвимость и регулятор обратит на нее внимание, то претензий к клиенту не возникнет. Ответственность несут, как мы уже писали выше, лаборатория, выдавшая аттестат, и сам провайдер.

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

Подведем итоги:

Итак, что дает наличие аттестата клиенту:

• возможность сослаться на него при аттестации собственной ИСПДн и при подключении к ГИС;

• гарантию неизменности системы на период действия аттестата;

• отсутствие вопросов при проверке со стороны регулятора.

Изучаем аттестат

Предположим, вы сделали выбор в пользу аттестованного решения. Разобраться в аттестате, понять описанные в нем детали и применить его это уже зона ответственности клиента.

Соответственно, возникает вопрос: на что стоит обращать внимание конечным клиентам? Самый простой и резонный ответ позволяет ли имеющийся у провайдера аттестат обеспечить требуемый уровень защищенности и/или класс защиты.

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

Важен и срок действия аттестата. Он может быть и ограниченным (обычно 3 года), и бессрочным. К примеру, при аттестации в рамках 17-го приказа ФСТЭК РФ (от 11.02.2013) аттестат действует в течение всего периода эксплуатации системы.

Облачный провайдер, как правило, является лицензиатом ФСТЭК и ФСБ. Соответственно, предлагая рынку аттестованные сервисные решения, провайдер не захочет рисковать ни своей репутацией, ни доверием со стороны регуляторов.

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

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

Пришел ко мне хороший приятель с просьбой помочь разобраться с защитой персональных данных, так как недавно к нему заглянули ответственные товарищи и напугали огромной ответственностью типа штрафы выросли за прошлый год в 6000 раз. Я в этой теме поковырялся и обнаружил, что многие валят в одну кучу и требования к защите персональных данных в соответствии со 152 ФЗ и уровнями защищенности от 4-го до 1-го (уровни указаны в порядке возрастания ответственности: 1-й ответственность самая высокая, а 4-й - на усмотрение оператора персональных данных), и требования по 242 ФЗ в части локализации обработки персональных данных граждан РФ.

Так что же обнаружил, делюсь выводами и практикой:

1. Да штрафы за нарушение в части локализации обработки персональных данных выросли очень-очень сильно (и это ох как сильно напрягло моего товарища CIO): за повторное нарушение для должностного лица до 800000 руб, а для юридического - 18000000 руб! Facebook, если помните уже заплатил в прошлом году в РФ первый штраф, в Twitter сейчас в очень опасном положении, если, конечно, наша территория для него что-то значит, а Linkedin уже давно заблокирован :(
Немного подробней об этой части закона:
Особенности применения закона о локализации персональных данных на практике: рекомендации для бизнеса https://www.garant.ru/article/748180/

2. Требуемый уровень защищенности зависит от категории персональных данных, количества обрабатываемых субъектов, субъектов обработчиков и типа угроз. Например, при большом количестве (более 100000 специальных субъектов при 3-м типе угроз требуется 2-й уровень защищенности, а менее 100000 субъектов 3-й уровень), т.е. в нашем случае получилось, что для маленькой стоматологии требуется 3-й уровень защищенности. И при переносе данных из Azure в РФ, где они обрабатывались у моего товарища, все угрозы штрафа в 18000000 руб быстро рассосались :)
Мало того, забегая вперед, скажу, что достаточно было организовать редактирование персональных и хранение копии данных в локальном облаке. Мы просто до конца не разобрались в процессах обработки и перестраховались.

3. Почему в облаке? Оказалось, что организовать защиту в офисе нам бы стоило в 10-15 раз дороже от 1000000 руб. А в облаке 12000 руб в месяц. Даже за 3 года выплат получится в 3 раза дешевле!

4. Да, практически все персональные данные в наших бухгалтериях, CRM-ках, ERP-шках, управленческих учетах, адресных книгах, 1С-ках и других информационных системах, если они содержат полные данные ФИО и адреса жительства, ИНН или еще какие-либо атрибуты, которые явно указывают на конкретную личность, являются персональными данными, которые надо защищать. Есть простенькая таблица, легко гуглится, могу выслать, если надо. НО! Оказалось, что самолечение точно не всегда решает проблемы эффективно. Нам совершенно бесплатно все объяснили и помогли определить необходимый уровень. Можете обратиться к любому облачному поставщику они делают этот консалтинг БЕСПЛАТНО! :)

5. Оказалось, что есть еще скрытые затраты надо обязательно делать пакет организационно-распорядительной документации (ОРД). Можно сделать его самому, но тогда проверяющие будут придираться к каждой запятой. Если отдать немного денежек или взять у облачников в составе услуги, ОРД делают лицензированные подрядчики, и их подписи и печати магическим образом отпугивают шершн проверяющих :)

6. Оказалось, что, как всегда, есть защита от реальных угроз и от проверяющих. В 99% случаев нужна 2-я защита :)

7. И самое важное, что обнаружил в 90% случаев требуется соответствовать 152 ФЗ УЗ 3 (3-й уровень защищенности), а далее самое потрясающее 99% компаний нарушают эти требования. Поэтому и решил всех предупредить: предупрежден, значит вооружен значит задумайтесь и спросите экспертов, как проще вам защититься от этих 2-х типов угроз :)

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

Для расследования инцидентов мы используем не только журналы c конечных устройств, но и систему контроля действий поставщиков ИТ-услуг (СКДПУ). Она записывает все действия инженеров DataLine с Cloud-152. Это облако аттестовано по требованиям ФЗ-152 и Приказа 17 ФСТЭК России к ГИС, сертифицировано по стандарту PCI DSS и входит в область действия сертификата по ISO/IEC 27001:2013. Так что СКДПУ еще и помогает выполнять требования законов и стандартов.

Также система используется, если нужно помочь клиенту и подключиться к серверам в его информационной системе персональных данных (ИСПДн). Доступ наших администраторов к S3 и некоторым другим системам тоже контролируем через СКДПУ.

В статье покажу, за какой уровень защиты облака у нас отвечает СКДПУ, чем и как он может помочь клиентам.

Место СКДПУ в Cloud-152

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

На уровне Cloud-152 СКДПУ работает, как такая камера с датчиком:

• в один файл идет запись всех действий на экране администратора,

• в другой файл пишется весь ввод с клавиатуры.

Два файла синхронизируются с помощью временной метки. Это позволяет посмотреть все, что делал сотрудник во время пользовательской сессии.

На общей схеме Cloud-152 это выглядит так: облако оборудовано не только забором в виде защищенного сетевого сегмента с межсетевым экраном, но и камерами для наблюдения за каждым инженером:

У администраторов IaaS нет прав доступа к клиентскому сегменту, только к сегменту управления. Если клиент заказывает дополнительные сервисы по администрированию, инженер тоже подключается через СКДПУ.

Мы рассматривали несколько подобных систем и выбрали СКДПУ по нескольким критериям:

• поддерживает основные протоколы администрирования Windows, Linux и сетевых устройств

• хорошо оптимизирована и не особо требовательна к железу;

• небольшой объем файлов с сессиями, к примеру: восьмичасовая сессия весит 100 Мб, за год одна из групп админов израсходовала 140 Гб;

• хорошая поддержка на российском рынке: большинство проблем решаются в первый час;

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

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

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

Какие записи и как храним

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

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

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

Когда наш сотрудник заходит в Cloud-152, он получает оповещение о записи сессии:

Параллельно с этими записями мы храним журналы входа в Cloud-152 и проверяем, совпадают ли они по времени. Если кто-то попытается обойти СКДПУ, произойдет рассинхрон: система зафиксирует вход в IaaS, но не увидит запись в СКДПУ.

Записи сессий администраторов Cloud-152 хранятся не менее 360 дней. Дополнительно мы делаем резервные копии записей средствами Veeam и отправляем их на хранение в другой наш ЦОД. Бэкапы храним 30 дней.

Как используем записи

Расследуем любые нештатные ситуации. Если какой-то инцидент произошел после подключения нашего сотрудника к серверу клиента, просматриваем записи и перепроверяем корректность работы. Речь не только про ИБ, но и про любые другие проблемы.

Следим за соблюдением правил работы с оборудованием. Многие защиты и права доступа настраиваются на самом оборудовании. Например, в случае с сетевыми устройствами может использоваться протокол TACACS+: с его помощью можем ограничить доступ к оборудованию, прописать права и запретить выполнение определенных команд. Тем не менее, если кто-то из инженеров попытается совершить запрещенную команду, в СКДПУ мы увидим соответствующее событие. Как минимум, появится повод для беседы.

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

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

Помогаем следить за админами клиента внутри его систем. Размещение клиента в Cloud-152 не позволяет автоматически выполнить все требования 152-ФЗ. На совести клиента остается сама ИСПДн ее тоже нужно приводить в соответствие с законом. В виртуальных машинах клиента могут работать его подрядчики: настраивать 1С, систему документооборота и т. д. За работой администраторов-аутсорсеров лучше тоже на всякий случай приглядывать. Для этого предлагаем клиентам аренду СКДПУ на месяц и более и помогаем ему настроить внутреннее наблюдение за своими администраторами.

СКДПУ подходит не только для Cloud-152. Если клиентам захочется поставить такую систему в любом другом нашем облаке, то скоро запустим новый сервис с ежемесячными лицензиями. Следите за обновлениями!

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

Банковские приложения и сами банки ведут себя очень наглым образом. Уже при установке они запрашивают права доступа, которые им необязательны или совсем не нужны для работы. Например, приложение Сбербанка сразу требует доступ к звонкам и фоткам. Я категорически против. Отказываю. А приложение не хочет работать при таком раскладе.

Банки, конечно, говорят, что всё во благо народа.

Нам же и пенсионный возраст, и НДС повышают по просьбам трудящихся, и даже старого деда до 2036 года продлили. Мы не хотим. А они делают всё, чтобы нам было им проще дать, чем объяснить почему не хочется.

Ответ Сбера просто поражает.

Сбер не одинок. Такая же ситуация и с ВТБ, с которым мы год судимся за закрытие счёта.

Ответ ВТБ

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

Когда сталкиваешься со СПАМом целенаправленным и понимаешь, что кое-кто слил персональные данные, то уже начинаешь относиться к ним куда бережнее.

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

Анализ приложений известных банков

Мы решили сделать анализ приложений основных банков. Проанализировать три типа мобильных приложений банка:

1. для физических лиц;

2. для юридических лиц;

3. и брокерские приложения для инвестиций в ценные бумаги.

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

Скрины тестов.

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

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

Проблема копий паспорта

И чтобы два раза не вставать поговорим про копии паспортов ещё. Нигде никаким законом не предписано коллекционировать копии паспортов. Смысла в их коллекционировании нет. Например, у нас в ITSOFT были перегибы на местах, когда сотрудники брали копии паспортов, но я это запретил делать категорически.

Рынку вообще нужна система идентификации по одному ИНН+TOTP вместо кучи реквизитов и персональных данных.

Никогда никому старайтесь не давать копии паспортов. Всегда требуйте законное обосновании, чтобы потом кредит на вас не повесили или ещё что, а вам не пришлось доказывать, что подпись не ваша. Если же там упираются, то когда снимаете копию с паспорта нужно приложить 2-3 листочка на пустое место в паспорте с указанием куда предоставляется копия паспорта. Потом такой копией невозможно воспользоваться, если она уйдёт на чёрный рынок. А у вас будет хотя бы теоретическая возможность привлечь виновника к ответственности в суде.

Банки пока в массе не применяют ЕБС (единую биометрическую систему).

63-ФЗ об электронной подписи принят уже лет 10 как. Но банки его игнорируют и упорно не хотят работать с документами подписанными УКЭП, хотя согласно п. 1 ст. 6 63-ФЗ они обязаны. По сути мы уже год с ВТБ за это и судимся.

Возможные решения проблемы

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

Если вы не пишите видео со звуком из Facebook и Instagram, то этим приложениям не нужен доступ к микрофону.

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

Зачем доступ к камере смартфона имеют некоторые банковские приложения вообще непонятно. Ещё они доступ к диску имеют. Они вполне могут работать и без него.

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

С этим нужно что-то делать на законодательном уровне. Отчасти даже сделано ст. 5 152-ФЗ. Там сказано, что собирать персональные данные можно только те, которые реально нужны. Есть ст. 15 152-ФЗ, где запрещено без нашего согласия использовать наши данные для того, чтобы нам что-то впарить. Но банки в своих кабальных договорах уже получают от нас согласие и большинство это подписывает не глядя. Хотя согласно закону мы можем отказать банку в части его хотелок. Тут нужно внимательно читать договор и приложения к нему.

Совсем отвратительно то, что согласно ст. 14 152-ФЗ мы не можем получить информацию об обработке наших данных указанную в п. 7., так как согласно подпункту 3) п. 8 наше право может быть ограничено. Банк же всегда может сослаться, что он залезает к нам в трусы смартфон не чтобы лучше нам рекламу показывать и продвигать свои услуги, а чтобы с терроризмом бороться. Мало ли кто чего не то думает про власть.

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

Сейчас пора предвыборных кампаний начинается. Можно обратиться к депутатам и к кандидатам в депутаты, что есть конкретная проблема. Отличный повод с ними познакомиться. Со своими я знакомился в битве за поправками против судебных приказов. В очередной раз напишу письма со ссылкой на данную статью. Тема очень больная. Статей и откликов много. Давно пора навести порядок в том, какие данные банки могут получать, а какие не могут. Ст. 5 152-ФЗ должна работать, а те, кто без необходимости собирает данные должны за это дело отвечать очень серьёзно и не перед государством, а перед физическими лицами. А то права нарушаются наши, а штрафы собирает государство обычно. В результат я, конечно, не верю, но времени это тоже много не занимает.

В ЦБ РФ жалобы писать бесполезно, они там одни отписки дают, что не вправе вмешиваться в деятельность банков.

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

Не светите личную мобилу для банков.

В идеале СМС принимать на одном телефоне, а приложение банка на другом.

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

Дата-центр ITSOFT размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.

Приглашаем авторов к сотрудничеству.

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

Требования со стороны регуляторов

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

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

Если как следует ознакомиться с основным регулирующим законом, 152-ФЗ О персональных данных, а именно со ст. 19, можно увидеть следующее:

Статья 19. Меры по обеспечению безопасности персональных данных при их обработке

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

2. Обеспечение безопасности персональных данных достигается, в частности:

7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;

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

Вывод 1, очевидный. Бэкапы не являются задачей на усмотрение оператора ПДн, а, согласно требованиям 152-ФЗ, лежат в его зоне ответственности: резервное копирование ПДн его прямая обязанность.

Строя свою ИС, работающую с ПДн и ГИС, важно учитывать требования приказов ФСТЭК 17 и 21, которые относят средства резервного копирования к средствам защиты информации.

Приказ ФСТЭК 17:

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

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

Приказ ФСТЭК 21:

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

ОДТ.4 Периодическое резервное копирование персональных данных на резервные машинные носители персональных данных

ОДТ.5 Обеспечение возможности восстановления персональных данных с резервных машинных носителей персональных данных (резервных копий) в течение установленного временного интервала

Вывод 2. Клиент, работая с ПДн в облаке, обязан решить вопрос доступности информации и, как следствие, регулярно выполнять резервное копирование.

Помимо приказов выше, необходимо обратить внимание на следующие нормативные документы:

• Приказ ФСБ 416, ФСТЭК 489 от 31.08.2010

• Постановление Правительства от 18.05.2009 424

Эти документы указывают на необходимость использования средств оперативного восстановления информации и фиксируют максимальное время восстановления доступа к потерянным или измененным вследствие несанкционированного доступа данным не более 8 часов.

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

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

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

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

Как решаются вопросы бэкапа со стороны провайдера

Наше облако аттестовано по требованиям УЗ-1 и К1, соответственно, в нем уже решены два типа задач:

• резервное копирование непосредственно облачной инфраструктуры и обеспечение высокой доступности данных;

• предоставление бэкап-сервисов пользователям этого облака.

В части обеспечения доступности информации (ОДТ) мы как провайдер решаем следующие задачи:

• Периодическое резервное копирование конфигурации компонентов инфраструктуры защищенного сегмента на резервные носители информации (ОДТ.4).

• Обеспечение возможности восстановления конфигурации компонентов инфраструктуры защищенного сегмента облака с резервных носителей (т.е. из резервных копий) в течение установленного временного интервала (ОДТ.5).

В части защиты среды виртуализации (ЗСВ):

Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры защищенного сегмента облака (ЗСВ.8).

Технически эти требования по резервному копированию облачной инфраструктуры реализуются на базе продуктов Veeam. Они хорошо зарекомендовали себя в системах виртуализации. Но это не единственная причина, почему для сегмента 152-ФЗ мы выбрали именно это решение:

• Veeam Backup & Replication имеет сертифицированную версию с классификацией по 4-му уровню отсутствие декларированных возможностей;

• благодаря наличию сертификата с ним легко проходить аттестацию.

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

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

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

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

Бэкап персональных данных с собственной локальной площадки в облако

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

Рассмотрим каждый из этих вопросов подробнее на практике.

1. Как выполнить безопасный обмен данными между площадкой клиента и облаком?

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

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

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

2. Как защитить площадки, участвующие в обмене данными, при подключении к публичным сетям?

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

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

3. Реализация отказоустойчивой архитектуры решения

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

Своим клиентам мы предлагаем решение на базе продуктов С-Терра. Этот инструмент решает все задачи организации высоконадежной и защищенной связности двух площадок для передачи бэкапов ПДн. В линейке продуктов С-Терра имеются различные варианты программно-аппаратных и виртуальных криптошлюзов. Благодаря широкой линейке можно подобрать оптимальное решение как по производительности, так и по и отказоустойчивости. Производительность шлюзов С-Терра в зависимости от модификации варьируется от 100 Мбит/c до 10 Гбит/с, поэтому и клиент, и мы как провайдер всегда сможем подобрать наиболее оптимальное для своих задач решение.

Варианты подключения локальной площадки клиента к BaaS-сервису

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

1. Veeam Cloud Connect Backup

   Схема используется в том случае, когда у клиента есть сервер Veeam Backup & Replication. Он выполняет резервное копирование объектов со своей площадки, а облако используется как репозиторий. Связь организуется между самим Veeam Backup & Replication и репозиторием через описанный выше защищенный канал связи.

   

2. С использованием агентов

   В случае, когда у клиента отсутствует сервер Veeam Backup & Replication на своей площадке, вместо него для резервного копирования используются агенты на серверах и ВМ. Управление осуществляется через Veeam Service Provider Console.

   

Эти сценарии в дальнейшем могут обеспечить и другие возможности.

• Восстановление в облако провайдера

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

• Миграция инфраструктуры

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

Всем привет,

Я последние несколько лет очень часто сталкиваюсь с проектами по адаптации под 152-ФЗ и он мне, честно, порядком надоел. Поэтому, прочитав опять весь закон, все комментарии различных ведомств и трактовки уважаемых людей, а также проанализировав ряд решений, которые прошли успешно аудит. Я, кажется, нашел простой технический вариант как сделать ваш web-site, API или приложение, соответствующее закону о персональных данных 152-ФЗ в разрезе требования о сборе пнд на территории России.

Я даже автоматизировал развертывание этой штуки и это занимает не больше 10-ти минут. Давайте обсудим применимость данного подхода!?

Чуть-чуть про сам закон, 152-ФЗ

Я уже и не помню зачем он на самом деле создавался, толи для того, что бы фейсбук и твиттер хранили данные о Российских граждан в РФ и таким образом к ним был бы более простой способ доступа у правоохранительных органов. Возможно, для того, чтобы они были в безопасности. Назначение самого закона оставим за скобками, а углубимся сразу в его требования. Сам закон обширный, но самый большой камень преткновения описан в статье 18, п.5:

"При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети "Интернет", оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных впунктах 2,3,4,8 части 1 статьи 6настоящего Федерального закона."

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

• Собирать персональные данные нужно в РФ, дальше можно их отправлять куда захочется.

• Вообще нельзя отправлять персональные данные за пределы РФ.

• Вообще ничего нельзя никуда отправлять и нельзя нигде ничего размещать за пределами РФ.

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

Варианты реализации

Ниже список вариантов как компании этот закон исполняют с технической стороны и что я встречал:

1. Вообще его игнорируют. Привет Facebook и Twitter.

2. Доказывают себе и другим, что у них нет персональных данных. Закон, кстати, так себе описывает, что такое персональные данные.

3. Арендуют сервер или виртуальную машину в РФ, кладут на него excel фаил - "персональные данные.xls" и отчитываются документально перед проверяющими органами.

4. Вносят руками данные локально в excel или в локальную систему перед тем как внести их в систему размещенную за пределами РФ.

5. Просто разворачивают копию системы в РФ и пользователей маршрутизируют на уровне DNS между площадками.

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

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

Описание реализации - Reverse Proxy

Концептуально выглядит он примерно как на архитектуре ниже.

Ничего сложного и логика работы следующая:

1. DNS на основе гео принадлежности пользователя маршрутизирует запросы. Если пользователь из РФ, то он идет по правой части картинки на прокси сервер. В данном случае на картинке Route53, но может быть и другой DNS сервис.

2. Reverse proxy, в данном случае это nginx принимает HTTP/HTTPS запрос и если он (POST, PUT, DELETE и тд), то кладет его локально в лог и в базу данных (PostgreSQL) с помощью плагина - rsyslog-pgsql в json формате.

3. Дальше запрос отсылается в первичную систему, получает ответ и отдает его пользователю.

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

"Постойте, так ведь это просто сбор логов HTTP/S запросов, разве это считается?" - спросите вы. С точки зрения закона он никак не регламентирует формат и структуру сбора и хранения данных и только говорит про использование базы-данных. Поэтому с логической точки зрения тут все по букве закона. Похоже, примерно так же SAP доработал свою систему, вот тут можно почитать более подробно в их блоге. Там очень часто упоминается, что пишется лог изменений в РФ.

В базе данных будут храниться HTTP/S логи запросов на создание и изменения, что-то вроде changefeed. Но это легко можно расширить если известна модель пересылаемых данных и встроить эту логику в виде python скрипта или просто сделать trigger в базе данных, которая будет схлопывать changefeed в нужную структуру, где запись об одном человеке будет одна.

Как развернуть это себе?

Я автоматизировал развертывания и настройки этого модуля и опубликовал его тут на Github как open source проект. Если кто-то хочет дополнить или расширить этот проект то смело пишите мне или создавайте pull request.

Краткое пояснения как развернуть:

1. Пропишите в вашей DNS записи A-record с айпи адресом на ваш сервер, который будет выступать reverse-proxy.

2. Зайдите на вашу виртуальную машину или свой сервер и сделайте: git clone https://github.com/Gaploid/FZ-152-Reverse-Proxy

3. Сделайте файл executable: chmod +x install.sh

4. Запустите скрипт: sudo ./install.sh <incoming_domain> <url_to_forward_traffic> Пример: sudo ./install.sh example.com http://example.com где <incoming_domain>это домен на который пользователь будет заходить, он может быть существующим. <url_to_forward_traffic> это адрес первоначальной системы.

5. Все, после этого если вы зайдете на <incoming_domain> все запросы POST, DELETE, PUT буду складываться локально в лог фаил - /var/log/nginx/reverse-access.log и в базу: proxy_logs в таблицу: accesslog.

Если вы хотите добавить HTTPS, то это можно сделать несколькими способами:

• Добавить свой существующий сертификат в nginx. Вот пример инструкции.

• Добавить новый сертификат от let's encrypt. Я для этого сделал скрипт ./add_ssl.sh вам нужно просто его будет запустить на этом же сервере. Сертификат получается с помощью бота от let's encrypt автоматически, но валидацию, что это действительно ваш домен он проводит путем проверки доступности по указанному домену <incoming_domain> вашего сервера, который вы указали на первом шаге.

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

Как еще это можно улучшить?

1. На nginx можно дополнительно выставить фильтр какие запросы перехватывать и вы можете указать, например, что нужно перехватывать если URL - myapp.com/profile/ в таком случае только запросы связанные с профилем будут сохраняться, что сильно уменьшит объем хранимых данных.

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

3. Можно еще добавить веб интерфейс с поиском, который будет показывать все записи по поисковой строке, например по ФИО или айди человека.

Послесловие

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

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