company_banner

Мифы о защите персональных данных в облаке


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

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

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

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

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

    Вводная


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



    Можно выделить три основных элемента, подлежащих защите:
    • Совокупность АРМ пользователей на стороне организации;
    • Канал связи между офисом организации и облаком (Интернет);
    • Совокупность виртуальных машин в «облаке», на которых функционирует серверное ПО соответствующей ИСПДн.


    FAQ


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

    — Какие основные направления угроз необходимо учесть при построении системы защиты ИСПДн?



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

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

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

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

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

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

    5. Внешние злоумышленники, реализующие атаки из-за пределов ЦОД облачного провайдера на ресурсы «облака» и, соответственно, на ресурсы ИСПДн, размещенные в «облаке».

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

    6. Соседи по «облаку», которые используют слабые места платформы для атаки из своей облачной среды

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

    Иллюстрация соответствующих принципов защиты приведена на следующем рисунке:



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

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

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

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

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

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

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

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

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

      +10
      Все эти сертификации защищают только от одного типа злоумышленников — проверяющих из госорганов.

      От всех остальных должна защищать грамотно построенная архитектура. Жаль что такой большой игрок как КРОК вместо того, что бы показывать как делать правильную архитектуру впаривает как важно сертифицироваться.
        0
        Вы правы в части того, что прежде всего необходимо думать об архитектуре защиты. Элементы архитектуры в посте приводятся:
        1) механизмы разграничения ресурсов и прав доступа самой облачной платформы;
        2) средства периметровой защиты облака;
        3) средства защиты, предлагаемые клиентам облака в виде ИБ-сервисов;
        4) средства защиты, разворачиваемые на виртуальных машинах внутри облака.
        Кроме того, любая, даже сверхзащищённая система не подойдёт для бизнеса (в части обработки и защиты персональных данных), если ее механизмы защиты не будут сертифицированы. То есть толку от неё не будет, пока не будет бумаг, подтверждающих для контролирующих органов, что она реально работает. Это требование регуляторов.
          +1
          Если сертифицированное оборудование\софт выполняет свою прямую задачу (защиту) ничуть не лучше своих аналогов, то его преимущества сводятся к защите от регуляторов. Каким бы ценным не был этот плюс для некоторых игроков — это свойство не имеет ровным счетом ничего общего с защитой данных.
          Требование сертификации диктуется экономическими мотивами и иногда желанием подсадить бэкдор.

          Судя по заголовку топика можно ожидать что речь пойдет про защиту данных от злоумшленников, а не про защиту бизнеса от нападок проверяющих.
            0
            Вы начинаете не с той стороны. Чтобы система защиты ПДн обеспечивала действительно необходимый уровень защиты для БИЗНЕСА нужно полностью отказаться от РД ФСТЭК и разработать совершенно другие документы. Эти документы создавались для защиты совершенно других систем, далеких от бизнеса, которые попытались почти без изменений переложить на защиту и бизнеса и гос.
            Вот после этого можно ожидать статей, в которых «речь пойдет про защиту данных от злоумшленников», а в суровые будни имеем то, что имеем. Без бумажки мы…
              +3
              Подождите. разработать документы? Я-то, дурак, думал, что разрабатывают софт. Ан, нет, оказывается только разработка документов позволяет защитить пользователя от сертифицированного взломщика…
                0
                Давайте определимся, кто такой сертифицированный взломщик?
                Давайте так же определимся, что мы все-таки защищаем — пользователя, как Вы пишите или таки персональные данные этого пользователя?
                Какими средствами Вы хотите защищать пользователся? Софтом?
                Так вот, чтобы такой каши в голове не возникало, прежде, чем разрабатывать софт, профессионалы разрабатывают кучу технических документов, чтобы для начала определить хотябы функции защиты, а потом место применения этого софта.
                  0
                  Определяемся: сертифицированный взломщик — взломщик, который отказывается взламывать сертифицированные системы защиты информации, у которых хорошо разработаны документы.
                    0
                    И где этот сертифицированный взломщик определен в РД ФСТЭК? О чем Вы?
                      +2
                      У сертифицированных взломщиков свои методы сертификации взломщиков.

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

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

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

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

                А если начать копать глубже, выяснится, что эта бумажка полезна только при общении с госорганами и служит неким образом отпугивающим средством, не более.
                  0
                  Какой ответ Вы ожидали получить? Вы абсолютно правильно ответили на свой же вопрос. У кого-то были иллюзии, что бумажка защищает данные? ))
                    0
                    По тому, что мне тут отвечают — есть острое ощущение, что кто-то именно так и считает. Потому я и вынужден доводить сию композицию до катарсиса.
                      0
                      Читайте законы )
                        0
                        А, ну в ЭТОЙ области, сертификация, конечно, важна. Как и было сказано первым оратором в комментариях.
                0
                их собирали одним компилятором из одного и того же сырца

                Сейчас буду занудствовать…

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

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

                Так что техническая возможность для разного поведения есть.
                  +1
                  И разумеется, только Сертификация позволяет получить полное покрытие кода Сертификатами. После этого код становится Сертифицированным.
              +1
              Такой большой игрок как Крок делает то, что должен — зарабатывает деньги, а если в текущих реалиях нужно создавать «бумажную защиту» от госорганов, то значит придётся создавать бумажную защиту.
              +1
              «Само «облако» находится на территории РФ»
              Вот здесь ошибка зашиты ИСПДн в облаке:)
              Перевести серверы за пределы РФ и проблема решена.
              Защита нескольких ИСПДн в рамках одного физического сервера для нашего любимого ФСТЕКа это неразрешимая задача, а вы еще хотите и в облаке. Это же в начале надо им объяснить, что такое облако, а потом показать сертификат соответствия механизмов разграничении доступа между категоризированной информацией. И потом, в ПДн явного указания нет, но в РД ФСТЕК есть ссылки про изоляцию категоризированной информации на отдельных серверах
                +1
                По ряду данных, готовятся требования по защите облачных технологий.
                  0
                  Неужели ФСТЭК что-то пообещал и дело ушло дальше «Как напишите МУ, так и защищайте» :)
                  0
                  Перевести серверы за пределы РФ и проблема решена

                  Для этого нужно иметь разрешение субъекта персональных данных на трансграничную передачу персональных данных. Его может не быть, если об этом не позаботились заранее.
                    0
                    Покажите мне пример ИСПДн, где в тексте электронного соглашения нет упоминания о трансграничной передаче?
                  0
                  А распространяются ли требования закона на на системы расположенные за пределами РФ?
                    +1
                    Спасибо за статью, не обращайте внимания на агрессивно настроенных)
                    У меня два вопроса:
                    Вы пишете, что размещать ИСПДн в облаке можно при соблюдении требований регуляторов, но никаких требований к облакам у регуляторов сейчас нет, насколько я знаю.

                    И второй, я так и не поняла, как аттестовывать ИСПДн, размещенную в облаке, понятно, что нужны сертифицированные СрЗИ, т.е. вы собираетесь сертифицировать все ваше облако или как это будет выглядеть? по частям? непонятно)
                    спасибо
                      0
                      А Вам спасибо за поддержку )! По пунктам:
                      1. ФСТЭК уже «задумалась» о создании таких требований, так что ждем… На текущий момент основным требованием является необходимость использования сертифицированных средств защиты (152-ФЗ, ст.19, п.2.3), на него мы и ориентируемся.
                      2. В посте как раз говорится, что аттестовать ИСПДн в публичном облаке не представляется возможным. В нашем публичном облаке мы предлагаем заказчикам сервисы безопасности на базе сертифицированных средств защиты.
                        0
                        ох, сомневаюсь, что ФСТЭК в каком-то обозримом будущем такие документы издаст:)
                        Про требования сертификации понятно, но выходит, что ИСПДн на базе того, что вы предлагаете «сервисы безопасности на базе сертифицированных средств защиты» — аттестовать нельзя, так?
                          0
                          На данный момент, да. К тому же, коммерческим организациям нет необходимости выполнять аттестацию ИСПДн.

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

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