Привет! Меня зовут Влад, я — системный администратор в Selectel. В июне этого года наше публичное облако на базе VMware прошло оценку эффективности принимаемых мер по обеспечению безопасности персональных данных до первого уровня защищенности, УЗ-1.
Теперь вы можете безопасно размещать любые категории персональных данных в публичном облаке. Selectel самостоятельно проводит оценку потенциальных угроз и обеспечивает безопасность инфраструктуры до уровня виртуализации публичного облака VMware.
Мы стремимся делать все, чтобы ваши данные были под надежной защитой. И хотим больше рассказывать «о внутренней кухне». В этот раз я поделюсь, как мы проходили путь оценки эффективности мер безопасности, с какими трудностями столкнулись и как их решали.
Почему именно УЗ-1
Уровень защищенности персональных данных — это показатель, который характеризует выполнение требований по нейтрализации угроз безопасности информационных систем персональных данных.
Для того чтобы узнать, какой уровень защищенности предъявляется к облаку на базе VMware, нам было необходимо определить категорию персональных данных, которое оно может обрабатывать, форму отношений между субъектами и организацией, количество обрабатываемых субъектов и типы угроз, которые могут возникнуть.
Все это — определения из действующего законодательства. И хоть звучит все запутанно и непонятно, давайте по порядку.
Категории персональных данных и другое
Действующее законодательство России предусматривает несколько категорий персональных данных:
- специальные — это информация о религиозных или политических взглядах, гендерная или расовая принадлежность и другие интимные сведения.
- биометрические — физиологические данные, по которым можно идентифицировать человека: отпечатки пальцев, рисунки сетчаток, радужные оболочки глаз и другое.
- общедоступные — это данные, которые может получить любой человек при согласии субъекта, к которому они относятся.
- иные — категория, для которой в законодательстве нет четкого определения. По сути, это то, что просто не попадает под предыдущие категории.
Компании-клиенты облака на базе VMware могут обрабатывать данные всех категорий, поэтому здесь проблем не возникало. Но вопрос в том, кому эти данные могут принадлежать. Варианта два: сотрудникам компаний-клиентов или их пользователям. Именно это определяет форму отношений между субъектами.
Здесь нам также не пришлось проводить исследования, чтобы выяснить, какие данные обрабатывают наши клиенты. Поэтому ответ был однозначный: облако на базе VMware должно защищать данные всех лиц и любых категорий.
Притом, согласно законодательству, уровень защищенности также зависит от количества субъектов, данные которых обрабатывает информационная система. Существует две категории — до 100 000 и более.
Сегодня Selectel пользуются более 24 000 клиентов, часть из которых арендует публичное облако на базе VMware. У них есть свои клиенты, поэтому наш продукт попадает именно под вторую категорию — более 100 000 субъектов.
Типы актуальных угроз
Уровень защищенности учитывает не только специфику обрабатываемых данных, но и типы актуальных угроз, которые необходимо нивелировать.
В любом программном обеспечении есть уязвимости. Нормативно-правовая база предусматривает всего три типа угроз персональных данных, причем самым низким считается третий, а самым высоким — первый.
Угрозы первого типа связаны с наличием недекларированных возможностей в системном ПО. Это могут быть закладки в системном софте, прошивки и драйверы оборудования — в общем, все то, что может стать причиной неправомерной блокировки, изменения, удаления и распространения личных сведений граждан.
Угрозы второго типа связаны с наличием недекларированных возможностей в прикладном ПО вроде Notepad и различных ERP-систем типа 1C или SAP.
Угрозы третьего типа — это комбинация факторов, которые не связаны с функциональностью системного и прикладного ПО информационной системы, обрабатывающей персональные данные.
С учетом того, что клиенты могут арендовать виртуальный сервер и установить любой софт, для облака на базе VMware актуальны все типы угроз. Значит, оно попадает под описание первого уровня защищенности, который необходимо обеспечить для безопасносного хранения персональных данных.
Как проходит оценка эффективности
Миф: во время этого мероприятия к вам придут «серьезные дяди», будут изучать каждый сантиметр машинного зала, проверять, задекларирована ли пылинка на сервере, и заполнять много бумаг. А потом еще и штраф выпишут!
Реальность: оказывается, — барабанная дробь — оценить эффективность может буквально любая организация.
В студенческие годы аттестация информационных систем мне казалась чем-то сильно официальным, чем «простые люди» заниматься не могут. Однако реальность полна сюрпризов и об этом я сейчас расскажу подробнее.
Согласно приказу ФСТЭК России №21 от 18 февраля 2013 года, оценка эффективности принимаемых мер может производиться двумя способами: самостоятельно или с помощью специализированный компаний-лицензиатов.
«Оценка эффективности реализованных в рамках системы защиты персональных данных мер по обеспечению безопасности персональных данных проводится оператором самостоятельно или с привлечением на договорной основе юридических лиц и индивидуальных предпринимателей, имеющих лицензию на осуществление деятельности по технической защите конфиденциальной информации. Указанная оценка проводится не реже одного раза в 3 года».
Мы выбрали путь самостоятельной оценки эффективности, проводимой в виде приемочных испытаний. Их суть заключается в том, что на основании подходящего уровня защищенности мы должны выполнить требования (о них чуть ниже) и проверить соответствие. По окончании этих испытаний выпускается специальный акт.
Самостоятельный подход нельзя назвать менее безопасным, он просто более простой. Требования в обоих случаях выдвигаются одинаковые, но при нашем подходе не требуется участие сторонних компаний.
Конкретно у нас в компании большую часть работы сделали сотрудники из отдела информационной безопасности (ИБ). Они проанализировали нашу инфраструктуру и составили список недочетов, которые необходимо было исправить. Спустя некоторое время мы перешли к реализации мер безопасности, которой занимался я и мой коллега-тезка из ИБ.
Почему самостоятельная оценка — это нормально?
За последние полтора года утечки данных и взломы информационных систем увеличились многократно. Количество производимых атак, а также их направленность на конкретные города и страны, можно увидеть в режиме реального времени на карте киберугроз Касперского.
И любая такая утечка или успешная атака может привести к репутационным и материальным потерям. Поэтому не подводить клиентов, разрабатывать качественные и безопасные сервисы — это в интересах бизнеса.
Минус самостоятельной проверки
Однако в самостоятельной проверке эффективности есть минус: могут быть компании, которые ничего не сделали для улучшения безопасности собственной системы, но выпустили акт а-ля «филькина грамота». Поэтому особенно важно изучить выписку из модели угроз и меры, которые предпринял и реализовал провайдер. Так можно понять, что действительно он сделал для безопасности своих клиентов.
Семь шагов проверки эффективности
Вернемся к тому, как проходит оценка эффективности принимаемых мер информационной безопасности. Вне зависимости от того, какую информационную систему вы хотите проверить, будь то облако на базе VMware или OpenStack, нужно сделать несколько шагов.
- Проведите полный анализ информационных средств. Разбейте ее по принципу «Разделяй и властвуй»: выделите программные, программно-аппаратные и аппаратные средства вашей системы, а также связи между ними.
- Подготовьте модель угроз в соответствии с методикойо ФСТЭК.
- Выработайте рекомендации по устранению недочетов. После моделирования угроз для своих систем необходимо изучить результаты и «залатать дыры», опираясь на базовый набор мер для необходимого уровня защищенности в соответствии с приказом ФСТЭК России №21.
- Выберите решения для реализации требований и нейтрализации угроз безопасности.
- Разработайте документацию. Параллельно работе над вторым, третьим и четвертым пунктами необходимо разрабатывать документацию, в которой будут описаны все реализованные меры.
- По возможности улучшите механизмы защиты или внедрите новые.
- По возможности улучшите механизмы защиты или внедрите новые.
- Проведите испытания и обработайте результаты. После тюнинга механизмов защиты необходимо провести повторные испытания на безопасность. Так вы сможете лишний раз убедиться в безопасности информационной системы.
Какие к нам выдвигались требования
Полный список требований к информационным системам есть в 21 приказе ФСТЭК. Он включает самые разные группы мер, начиная от управления логинами и средствами аутентификации (паролями, ключами и другим), заканчивая security-related изменениями в инфраструктуре.
Для примера рассмотрим часть требований, которые нужно было реализовать для проверки облака на базе VMware на соответствие УЗ-1:
- сбор и анализ событий безопасности,
- проверки соответствия политикам безопасности,
- защита от вредоносного кода и выявление атак (IDS),
- инвентаризация ПО и выявление уязвимостей,
- контроль целостности критичных компонентов.
В силу того, что все продукты VMware проприетарные, то есть с закрытым исходным кодом, выполнить все требования было довольно непросто. Мы не можем устанавливать специфичный софт на гипервизоры, если только вендор заранее не позаботится об этом.
Чем отличается облачная платформа на OpenStack от облака на базе VMware? Мы собрали команду системных администраторов, разработчиков и продакт-менеджеров, чтобы обсудить этот вопрос и подискутировать на тему того, что лучше. Посмотрели на платформы с позиции пользователя, разработчика, менеджера.
Перед нами встала, на первый взгляд, невыполнимая задача. Однако если есть много кофе и поддержка от отдела ИБ, справиться можно. Конкретно про наши решения рассказать не получится, иначе по мою душу придут безопасники. Но могу поделиться рекомендациями по решению некоторых из требований ФСТЭК.
Сбор и анализ событий безопасности
С этим требованием более-менее все понятно: нужно всегда собирать логи и хранить их в течение необходимого срока — например, до трех месяцев на горячем хранении и до года на холодном. При этом они должны содержать все необходимые события, связанные с безопасностью.
С формированием списка логов может помочь отдел ИБ. Если у вас в компании есть своя SIEM-система, это сильно упростит процесс. К событиям безопасности относятся попытки авторизации, активные и завершенные сессии, действия пользователей, изменения паролей и другое.
На самом деле, анализ логов и security-ивентов — само по себе полезное занятие, хоть и затратное по ресурсам. Для настройки и работы системы по сбору логов могут понадобиться квалифицированные специалисты и мощное железо. Зато вы всегда будете в курсе происходящего в ваших информационных системах и оперативно реагировать на любые инциденты.
Все продукты VMware поддерживают возможность отправки собственных логов на syslog в соответствие с RFC 3164 и RFC 5424, поэтому сложностей с обработкой «стандартизированных» логов не возникает.
Проверка соответствия политикам безопасности
Соответствие политике безопасности — это когда ты не просто развернул систему и начал ей пользоваться, а задумался о ее безопасности и начал скрупулезно настраивать «эталонный» образ.
Компания VMware выпускает собственные рекомендации по улучшению продуктов, Hardening Guide, что дословно переводится как «Руководство по закалке». Например, они рекомендуют ограничить использование сервисов, которые не задействуются в инфраструктуре, использовать только защищенные протоколы. А также — делегировать права доступа, чтобы доступ к root был только у администратора. Применение этих простых рекомендаций может дать существенный прирост в защищенности систем, однако придется потратить немало времени, чтобы изучить этот гайд.
Помимо родного руководства, есть также рекомендации от некоммерческой организации CIS. Она разрабатывает стандарты и инструменты в области информационной безопасности. Например о том, как правильно настроить операционную систему, выбрать авторизованный NTP-сервер, модифицировать ядро или предотвращать атаки TCP SYN-flood.
Рекомендации по ESXi занимают 253 страницы, но выбора не было: хочешь сделать работу качественно — изучи от корки до корки. Радовало только одно: большинство рекомендаций уже были выполнены нашими администраторами. Со своей стороны мы дополнительно настроили систему для большей безопасности клиентов, а также отключили неиспользуемые протоколы на уровне профиля кластера и добавили различные улучшения.
Защита от вредоносного кода и выявление атак, IDS
Без специализированных решений эти требования не выполнить. Необходимо использовать антивирусы и средства обнаружения и предотвращения атак. Последние можно разделить на два класса — NIDS (Network Intrusion Detection System) и HIDS (Host-based Intrusion Detection). Первые мониторят сетевой трафик, в то время как вторые — анализируют события хоста, в том числе приходящий и уходящий трафик внутри систем.
Как видно из названия, NIDS необходимо ставить на хосты для управления трафиком. А HIDS больше подходят для endpoint-хостов с локальными сервисами. Более подробно о классификации и особенностях IDPS-систем мы рассказали в отдельной статье.
С защитой от вредоносного трафика и выявлением атак нам повезло. VMware предоставляет собственные продукты для реализации необходимого функционала. Но если повезло не работать с «проприетарщиной», вам может пригодиться IDPS-система — Snort или Suricata.
Инвентаризация ПО и выявление уязвимостей. Контроль целостности критичных компонентов
Сразу оговорюсь, что эти два пункта я решил объединить в один из-за того, что нам удалось закрыть необходимые требования одним продуктом.
Современные комплексные решения типа Wazuh могут собирать информацию об установленных программах на хостах и выявлять уязвимости, сравнивать их с актуальными базами данных CVE. Контроль целостности легко обеспечить с помощью того же Zabbix или Wazuh, но только если ваш endpoint — не ESXi.
Нам с этим не повезло, поэтому к Wazuh мы прикрутили функцию контроля целостности. Управляющий сервер подключается к хостам по SSH, считывает хеш необходимых файлов (модулей ядра, boot.cfg и других системных файлов), а затем — сравнивает и определяет, были ли они изменены.
Мы сконцентрировали свое внимание только на тех файлах, которые никогда не должны меняться, иначе будут повально сыпаться алерты. Также мы добавили мониторинг SSH-сессий, чтобы отслеживать, удалось ли управляющему серверу подключиться к хостам и выполнить необходимые действия.
Заключение и результаты
Надеюсь, у меня получилось пролить свет на основные этапы оценки эффективности принимаемых мер безопасности. Но сейчас мы не ответили на главный вопрос: что клиенту дает защищенное облако? На мой взгляд, можно выделить несколько бенефитов.
Клиент уверен, что инфраструктура безопасная. Эффективность системы защиты контролируется квалифицированными сотрудниками провайдера. Кроме того, если облако защищено, оно актуально не только для клиентов с требованиями по безопасности, но и простым пользователям. Безопасность персональных данных будет плюсом для всех.
Провайдер разделяет ответственность за безопасность. За реализацию части требований по безопасности полностью отвечает провайдер. В его зоне ответственности — физическая безопасность, защита среды виртуализации и другое. От клиента требуется только защищать свои операционные системы и сети. Таким образом, он может больше сфокусироваться на задачах своего бизнеса.
