Как соблюсти требования 152-ФЗ, защитить персональные данные своих клиентов и не наступить на наши грабли  



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

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

    Как мы помогали защитить данные по 152-ФЗ


    В начале 2019 года к нам обратилась компания ООО «Смарт-Сервис», разработчик платформы для управления сервисным обслуживанием HubEx и приложения для обмена контактами myQRcards.
     
    Первое решение позволяет автоматизировать процесс обслуживания оборудования в самых разных областях – от настройки кофемашин и кондиционеров в офисных помещениях до ремонта газовых турбин. Второе – онлайн-конструктор для создания электронных визитных карточек на базе QR-кодов. 


    Онлайн-визитка myQRcards.

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

    КАК УСТРОЕНО ЗАЩИЩЕННОЕ ОБЛАКО


    Любая информационная система, обрабатывающая персональные данные, должна удовлетворять трем основным требованиям: 

    • доступ к серверам хранения и обработки данных должен производиться через VPN-канал с шифрованием согласно ГОСТ;
    • серверы хранения и обработки данных должны находиться под постоянным мониторингом антивирусной защитой на отсутствие уязвимостей;
    • СХД должен быть расположен в изолированных сетях. 

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


    Архитектура защищенной виртуальной инфраструктуры для ООО «Смарт Сервис».

    Ход работ


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

    Поэтому был составлен и согласован четкий план действий, разделенный на 4 этапа:

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

    На всякий случай мы предусмотрели процедуру восстановления в случае непредвиденной ситуации (DRP). По первоначальному плану работы не занимали много времени и ресурсов и должны были завершиться в июле 2019. Каждый из этапов предусматривал в конце полное тестирование сетевой доступности и функциональности систем.

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

    Нежданно-негаданно


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

    Поскольку каждая виртуальная машина занимает 500 — 1 000 ГБ, копирование таких объемов даже в рамках одного дата-центра заняло около 3-4 часов на каждую машину. Как итог, мы не уложились в отведенное временное окно. Это произошло по причине физических ограничений дисковой подсистемы при переносе данных в vCloud.

    Баг используемой версии vCloud не позволил организовать Storage vMotion в отношении виртуальной машины с разными типами дисков, поэтому диски пришлось менять. В результате перенести виртуальные машины получилось, но это заняло больше времени, чем планировалось. 
     
    Второй момент, который мы не предусмотрели, — ограничения по перемещению кластера БД (Failover Cluster MS SQLServer). В результате пришлось перевести кластер в работу с одним узлом и оставить его за рамками защищенной зоны. 

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

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

    Попытка №2


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

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

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

    Результативный исход и полезный урок



     
    В итоге, совместными усилиями вместе с заказчиком удалось внести значительные изменения в существующую серверную инфраструктуру, что позволило повысить надежность и защищенность хранения ПДн, существенно снизить риски несанкционированного доступа к ним, получить аттестат выполнения требований к хранению — достижение, к которому пришли еще далеко не все разработчики аналогичного ПО.
     
    В сухом остатке комплекс работ по проекту выглядел так:
     
    1. Организована выделенная подсеть;
    2. Суммарно мигрировано два кластера, состоящих из пяти виртуальных машин: Failover кластер баз данных (две виртуальные машины), Service Fabric кластер приложений (три виртуальные машины);
    3. Произведены настройки систем защиты и шифрования данных.

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

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

      +2
      Закон нужно соблюдать, но «Смарт-Сервис» не планировал развивать у себя внутри компетенции по защите ПДн. Поэтому сервисы и данные, которыми делились их пользователи, «переехали» в Linxdatacenter. «Смарт-Сервис» перенес серверные мощности рабочего окружения в отдельную защищенную сетевую зону нашего дата-центра, аттестованную в соответствии с заявленными в 152-ФЗ требованиями – так называемое «Защищенное облако».

      Тот факт, что «Смарт-Сервис» хостит свои информационные системы в вашем "защищенном" датацентре, не снимает с него лейбл Оператора персональных данных, а следовательно «Смарт-Сервис» должен выполнить :


      требования Федерального закона от 27.07.2006 N 152-ФЗ (ред. от 31.12.2017) 'О персональных данных'

      Глава 4. Обязанности оператора
      Статья 18. Обязанности оператора при сборе персональных данных
      Статья 18.1. Меры, направленные на обеспечение выполнения оператором обязанностей, предусмотренных настоящим Федеральным законом
      Статья 19. Меры по обеспечению безопасности персональных данных при их обработке
      Статья 20. Обязанности оператора при обращении к нему субъекта персональных данных либо при получении запроса субъекта персональных данных или его представителя, а также уполномоченного органа по защите прав субъектов персональных данных
      Статья 21. Обязанности оператора по устранению нарушений законодательства, допущенных при обработке персональных данных, по уточнению, блокированию и уничтожению персональных данных
      Статья 22. Уведомление об обработке персональных данных
      Статья 22.1. Лица, ответственные за организацию обработки персональных данных в организациях


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


      Любая информационная система, обрабатывающая персональные данные, должна удовлетворять трем основным требованиям:

      доступ к серверам хранения и обработки данных должен производиться через VPN-канал с шифрованием согласно ГОСТ;
      серверы хранения и обработки данных должны находиться под постоянным мониторингом > антивирусной защитой на отсутствие уязвимостей;
      СХД должен быть расположен в изолированных сетях.

      Интересно было бы узнать из каких нормативно-методических документов ФСТЭК или ФСБ России вами были сделаны выводы о достаточности этих мер для приведения ИСПДн в соответствие требованиям 152-ФЗ…
      И последнее — вы не думаете, что штрафы от контролирующих органов могут быть в судебном порядке взысканы с вас за введение в заблужение ваших клиентов, в части выполнения последними требований законодательства РФ (захостил ИС у нас в облаке = выполнил требования 152-ФЗ)?

        0
        Данный пост о технической стороне вопроса, о том, как это делалось по отношению к существующей инфраструктуре.

        Из документов: 152-ФЗ, ПП-1119, приказ ФСТЭК № 21 и приказ ФСБ № 378. Более того, у нас имеются лицензии ФСТЭК на ТЗКИ и ФСБ на работу с СКЗИ и документы, подтверждающие соответствие требованиям безопасности информации по 3 уровню защищенности персональных данных. Компетенциями обладаем, спасибо.

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

        По части соблюдения 21 приказа ФСТЭК и технических мер защиты – добро пожаловать.
        +1
        Закон нужно соблюдать, но «Смарт-Сервис» не планировал развивать у себя внутри компетенции по защите ПДн.

        Я бы сказал, что это почти уникальный случай: всего в третий раз в моей жизни (и первый раз публично) компания заявляет, что не хочет заниматься безопасностью данных пользователей, вот бы кто за них заполнил все бумажки. Интересно, как у такой компании могут быть дела с уязвимостями, утречками данных из-за багов в коде, а не из-за проблем с инфраструктурой?

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

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

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

              –1
              Если я правильно понимаю, то даже контакты менеджера, который согласует сроки обслуживания

              Если там ФИО и день рождения, то да, это ПД. Но оно зачем? И очень сомневаюсь, что у этого менеджера (чужого) брали согласие на обработку ПД.

              данные инженера по ремонту турбин, которые нужны для оформления пропуска, уже являются ПД.

              Для пропуска необходимо ФИО. Просто ФИО — это не ПД.
              0
              Но такие платформы обрабатывают ПД на уровне юрлиц. Так, если в компании трудоустроены инженеры и менеджеры, они подписывают ряд документов, в том числе на обработку ПД. Потом компания регистрирует их в срм или хеплдеске, и там оказываются их ФИО, почта, телефон.
              +1
              СХД должен быть расположен в изолированных сетях

              а какая именно изоляция тут подразумевается, не физическая же?


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

                0
                Нет, не физическая.
                Мы используем сертифицированный дистрибутив Лаборатории Касперского. Очевидно, с сертификацией каким-то образом данный вопрос решался. Если наши регуляторы считают это приемлемым, то почему бы и нет. По умолчанию у нас отключена синхронизация с KSN (тут находится конспирологическое пояснение, что Касперский все равно шлет данные). Сервис как раз создан для того, чтобы избавить заказчиков от проблем с частью требований регуляторов.

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

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