Может ли быть вирус на облаке

Обновлено: 24.04.2024

При этом традиционные политики безопасности требуют от нас, чтобы антивирус был запущен на каждой ВМ. Однако ни одно антивирусное решение не обеспечивает 100% защиту. А значит, его тоже можно отключить или не устанавливать вовсе?

Ландшафт: облачная и традиционная инфраструктура

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

Нужен ли контроль виртуальной машины?

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

Давайте разберемся, можно ли полагаться на эту концепцию, — и для этого рассмотрим ряд сценариев.

Вирусы не запустятся в виртуальной среде

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

Существует множество способов обнаружения виртуальных машин:

VMware and Hyper-V VMs have a (default) MAC address starting with 00-05-69, 00-0c-29, 00-1c-14 or 00-15-5D
Записи реестра содержат “VMware” or “esx”
Communications bus with embedded “secret” such as “VMXh”
Hyper-V: CPUID leaves 0x40000000 — 0x40000006
VMware BIOS серийный номер начинается на “VMware-” или “VMW
Memory locations of data structures в IDT и ACPI таблицах
Benchmarking: discontinuities between ICMP and TCP timestamps, IP ID header values
Вспомогательные инструменты: Red Pill, ScoopyNG, VMDetect, virt-what, metasploit/check-vm

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

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

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

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

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

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

Одна зараженная ВМ — это не страшно

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

Escape to Host
Escape to VM
Escape to vNet

Cloudburst: эксплойт с повреждением памяти, который позволяет гостевой виртуальной машине выполнять вредоносный код на базовом хосте SubVirt, BluePill
VMcat, VMChat, VM Drag-n-Sploit
VENOM (CVE-2015-3456): уязвимость в коде виртуального дисковода гибких дисков позволяет злоумышленнику убежать от гостевой виртуальной машины и потенциально получить доступ к хосту с выполнение кода
SNAFU (XSA-135): выход через ошибки в эмулируемом сетевом адаптере pcnet QEMU.

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

Было бы прекрасно, если бы это было правдой.

На демонстрации в режиме реального времени, показанная еще на BlackHat 2017 в Азии, была продемонстрирована атака на облако, включая интерактивные сеансы SSH и потоковое видео между двумя виртуальными машинами.

Исследователи создали высокопроизводительный скрытый канал, который может поддерживать скорость передачи более 45 Кбит/с на Amazon EC2, и даже зашифровали его: этот метод устанавливает сеть TCP внутри кеша и передает данные с использованием SSH.

Помимо самих ВМ, есть ряд уязвимостей у самой среды виртуализации:

VMM имеет большую и сложную кодовую базу и, таким образом, обладает потенциально широкой поверхностью атаки.
Между 2012-2018 было обнаружено ~170 уязвимостей высокой степени опасности* (CVSS score >7) в Xen (74), KVM (47), VMware ESXi (33), Hyper-V (46) и XenServer (26).
Наиболее распространенным источником триггера для атак является Пользовательское пространство гостевой VM, но существуют и другие типы, такие как атаки канала управления (например, API VMM).

Идеальный антивирус: волки целы, овцы сыты

Иными словами, для защиты наших ВМ в облаке нам необходимо специализированное решение, которое:

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

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

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

Наш опыт использования антивируса

Сейчас у Лаборатории Касперского есть два специализированных решения — безагентский антивирус и решение на базе легкого агента. Эти решения отличаются по функциональности и принципу работы.

Безагентское решение предназначено только для VMware — у VMware есть специализированный API, который он предоставляет сторонним вендорам. Через этот API в ВМ, где стоит драйвер-перехватчик, передаются файлы для анализа, а программа сама решает, какие из них блокировать. Это решение не требует установки внутрь ВМ какого-либо специфичного софта, что снимает вопрос инсталляции и долгих тестирований на совместимость. Однако такой подход влияет на работу самого антивирусного решения, потому что у него просто связаны руки. Безагентский антивирус может получать данные, анализировать и отдавать вердикт, но не имеет возможности проводить исследования внутри ВМ и применять современные логики. Очевидно, ограниченность функционала сильно перевешивает его плюсы, поэтому он нам не подходит.

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

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

Решение работает на базе нескольких компонентов.

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

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

Благодаря своей функциональности решение:

Не антивирусом единым

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

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

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

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

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

Вот часть самых распространенных проблем облачной безопасности.

Проблемы безопасности в облаке

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

К сожалению, стремительное распространение COVID-19 внесло свои коррективы, и компаниям пришлось переводить своих сотрудников на работу из дома в срочном порядке. Инфраструктура для такой работы строилась хаотично, часто без полноценных комплексных политик безопасности – например, в отношении доступа к облачным серверам. Широкое использование облачных платформ для совместной работы и видеоконференций также усложнило жизнь IT-специалистам.

По данным опроса компании Fugue, у 3 из 4 команд, работавших с облачными системами, случалось более 10 инцидентов в день просто из-за их неправильной настройки. Утечки данных из облачных хранилищ, слишком мягкие политики доступа к инфраструктуре и другие факторы заставляют 84% IT-отделов подозревать, что сети их компаний уже скомпрометированы, хотя точных сведений об этом и нет. Более того, решать проблемы безопасности облачных сред приходится вручную, что, во-первых, неэффективно, а во-вторых, повышает риск ошибок, вызванных человеческим фактором.

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

Угрозы для безопасности в облаке

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

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

Конфигурация облака

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

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

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

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

Политики удаленной работы на личных устройствах

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

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

В пределах компании локальная сеть защищена сетевым экраном, Wi-Fi-роутеры стоят в защищенном помещении. Корпоративные мобильные телефоны тоже находятся в ведении IT-отдела. Его сотрудники снижают поверхность атаки, используя самые свежие протоколы безопасности и устанавливая последние обновления ПО.

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

Социальная инженерия и другие виды киберугроз

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

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

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

Как защитить данные в облаке

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

Если вы хотите защитить личные данные на домашних устройствах.

Используйте безопасное соединение. Виртуальная частная сеть защитит ваши данные при передаче между устройством и облаком.Шифрование – это базовая функция большинства сервисов, предоставляющих соединение по безопасному каналу, защищающая трафик от посторонних глаз.
Проверьте, есть ли у вас данные, которые стоит зашифровать. Не все данные нужно шифровать, но для защиты конфиденциальной информации этот метод незаменим. Его советуют использовать, например, для защиты личных документов, а также того, чем вы не готовы делиться. А вот файлы в открытом доступе шифровать необязательно. Однако будьте осторожны: потеряв ключи шифрования, вы навсегда лишитесь доступа к своим файлам.
При шифровании будьте бдительны. Если ваш поставщик услуг не хранит ключи у себя, вам нужно будет самостоятельно найти для них надежное место. Встроенная память того же компьютера, где лежат зашифрованные данные, – не лучший выбор.
Используйте защитное решение с функцией мониторинга личных данных. Некоторые решения, такие как Kaspersky Security Cloud, предупредят вас, если данные, которые вы храните в облаке, будут скомпрометированы.В случае взлома одного из ваших зашифрованных хранилищ решение оповестит об инциденте и предложит эффективный план защиты.

Для защиты корпоративных сетей.

Как повысить безопасность облачных служб

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

Другие продукты

Больше информации по теме:

Какие опасности подстерегают в облачных сервисах

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

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

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

В Облаке существует дедупликация, то есть файл с конкретным содержимым присутствует лишь в одном экземпляре (на самом деле в двух, так как существует резервная копия). Если 200 человек зальют один и тот же файл, то в хранилище не будет находиться 200 одинаковых файлов. Просто всем этим пользователям будут раздаваться копии одного файла. Зачем? Во-первых, это позволяет нам эффективнее использовать место на дисках и, как следствие, предлагать пользователям больше бесплатного пространства для хранения информации. Кроме того, мы экономим мощности для проверки файлов. На данный момент дедупликация позволяет нам снизить нагрузку на хранилище примерно на 15%.

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

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

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

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

Также мы посчитали, какие заблокированные вредоносные программы наиболее распространены:

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

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

8 сентября 2014

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

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

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

То, что за облачный сервис взимается плата, вовсе не означает, что он будет защищен лучше, чем бесплатный аналог

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

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

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

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

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

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

В этой статье ответим на такие вопросы:

Где проходит граница между зонами ответственности клиента и провайдера?

Можно ли ее двигать и как ее закрепить?

Как выбрать облачного провайдера и конечный перечень услуг, чтобы быть уверенным в выполнении требований стандартов и законов в должной степени?

Абсолютная защита: миф или реальность?

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

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

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

Но инциденты ИБ – это не деградация производительности, которую сравнительно легко измерить, или отключение системы (хотя и так бывает); они в конечном итоге, связаны с данными или процессом их обработки. И измерять их критичность, да и просто понять, что является просто лог-записью, а что инцидентом — тяжело. Например, антивирус среагировал на вредоносный вирус или на легитимный скрипт? Если это был вирус, а антивирус его заблокировал — это же хорошо. А если не заблокировал, то сколько компьютеров заразилось, и кто несет ответственность за то, что специальное средство защиты от вирусов не справилось?

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

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

Граница зон ответственности – кто и за что отвечает?

Ответ на этот вопрос зависит от вида самой услуги и ее практической реализации.

Базово здесь применима такая логика:

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

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

На практике же есть еще несколько дополнительных факторов:

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

Описать это проще на примерах с конкретными видами услуг

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

Таким образом, провайдер контролирует:

Помещения, в которых расположено облако (ЦОД). И отвечает за физическую защиту этих помещений;

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

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

Управление доступом собственных администраторов;

Защиту рабочих мест собственных администраторов;

Сбор и хранение логов, созданных компонентами облака.

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

Клиент получает виртуальные мощности, на которых разворачивает свои виртуальные машины, устанавливает свое ПО и пускает туда своих пользователей.

Таким образом, именно клиент контролирует:

Сегментирование и защиту доступа в интернет;

Антивирусную защиту ВМ;

Контроль и устранение уязвимостей в ВМ;

Авторизацию и настройку доступа к ОС и к ПО;

Защищенность приложений: их обновленность, отсутствие уязвимостей;

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

Настройки логирования в приложениях. Выявление и анализ инцидентов ИБ.

Защиту данных в движении. Фактически – действия легальных пользователей.

Шифрование данных, при необходимости.

В серой зоне оказываются следующие меры защиты:

Управление доступом сотрудников клиента в ЦОД. Если у сотрудника был пропуск в ЦОД, и сотрудник уволился, а пропуск забыли отозвать – то провайдер не может узнать о факте увольнения.

С технологической точки зрения, провайдер автоматически предоставляет клиентам какой-то межсетевой экран.

Но, во-первых, этот межсетевой экран может не обладать каким-то функционалом, требующимся для стандарта: например, базовый межсетевой экран VMWare NSX Edge не умеет работать как IPS. А стандарт PCI DSS требует наличия IPS.

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

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

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

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

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

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

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

Часто клиенты спрашивают:

Что же такого сложного в передаче услуги по обновлению ОС, или в выполнении мер по контролю конфигураций?

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

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

Наиболее распространенные примеры: DBaaS, сервис контейнеризации, S3.

Провайдер контролирует:

Все, что было описано для IaaS;

Защищенность доступа собственных администраторов к администрированию платформы (антивирусная защита, обновленность и т.д.);

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

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

Сбор и хранение логов платформы

Клиент контролирует:

Корректность настроек и конфигураций того, что работает внутри платформы: нода в случае с контейнеризацией; логической структуры БД в случае с DBaaS; настроек публичного доступа в случае с S3.

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

Настройки логирования в приложениях. Выявление и анализ инцидентов ИБ.

Защиту данных в движении. Фактически – действия легальных пользователей

В серой зоне оказываются следующие меры защиты:

Межсетевое экранирование. По уже описанным причинам

Резервное копирование. По тем же причинам.

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

Применение необязательных средств защиты, установка которых требуется на уровне ОС (вне контроля пользователя). Например, нужен ли антивирус для S3? Не всем, и не обязательно его реализовывать на уровне S3.

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

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

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

С точки зрения пользователя все просто – все контролирует провайдер.

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

Можно ли двигать границу зоны ответственности

Можно, но заказчику нужно к этому подготовиться.

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

Если провайдер должен контролировать обновленность, то:

Каких пакетов (только ОС, или еще какое-то ПО)?

Что провайдер должен делать с выявленными не обновленными машинами?

Если провайдер должен их обновлять – должен ли он тестировать совместимость с ПО? И как?

Если ПО не совместимо с обновлениями – что должен сделать провайдер.

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

Фактически – необходимо описать процедуры управления ИБ, состоящие из:

Определения зоны действия. Например, все обновлять, или только ОС;

Определения мер контроля выполнения и метрик;

Определения пути информирования о случившихся событиях, в случае, если работы прошли по плану

Определения пути информирования о случившихся негативных событиях (т.е. когда что-то пошло не по плану)

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

Как выбрать подходящего облачного провайдера

На практике, клиенту нужно выбрать облако, обеспечивающее достаточный уровень качества, быстродействия и соответствия нужным требованиям по ИБ. И вот с последним есть некоторое количество хитростей. Их проще описать на примерах.

Во-первых, стандарты PCI DSS и ГОСТ Р 57580.1 значительно более продвинутые, чем 152-ФЗ. Так что облака, соответствующие этим стандартам, при прочих равных можно считать более защищенными.

Во-вторых, для каждого из стандартов существуют свои способы подтверждения соответствия.

152-ФЗ — Защита персональных данных

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

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

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

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

Сложность в том, что аттестат не позволяет изменять аттестованное облако. А при изменениях в облаке – аттестат необходимо получать заново.

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

Защита данных платежных карт — PCI DSS

Стандарт PCI DSS описывает разные типы компаний, подпадающих под действие стандарта, и разные уровни соответствия.

Облачные провайдеры попадают в тип “service providers”, и для публичного облака актуален уровень Level 1. Он требует проведение сертификационного аудита.

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

Документ AOC. В этом документе описано – какие именно услуги провайдера прошли сертификацию.

Это достаточно важно понимать, потому что сертификат, выданный, например, для услуги Co-location (т.е. размещения оборудования в ЦОД) никак не поможет клиенту, размещающему виртуальные машины в облаке.

Еще нужно не забывать, что услуги S3, администрирование ресурсов в облаке, DBaaS и т.д. – это все отдельные от самого облака (хостинга виртуальных ресурсов) услуги, и они должны быть отражены в AOC.

И перед размещением систем, клиенту нужно подписать с провайдером соглашение о разделении зон ответственности – это стандартный для PCI DSS документ, по сути подобный поручению в 152-ФЗ.

Требования ЦБ РФ – ГОСТ Р 57580.1-2017

Привести себя в соответствие провайдер может и самостоятельно, а вот подтвердить соответствие должна сторонняя компания, имеющая лицензию ФСТЭК ТЗКИ.

А вот стандарта такого подтверждения пока нет. Есть стандарт проверки – ГОСТ Р 57580.2-2017, но он был написан для использования в банках, и для облачных провайдеров несколько избыточен.

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

Подтверждение качества системы управления собственной ИБ провайдера – ISO 27001

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

Легкую неразбериху вносит то, что есть оригинальный стандарт – ISO\IEC 27001:2013, а есть его переводная версия: ГОСТ Р ИСО\МЭК 27001. Оба стандарта действующие, но Российская версия является локализацией устаревшего стандарта ISO 27001:2005.

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

Краткие итоги

Самые важные вещи:

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

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

Также, с точки зрения ИБ, провайдер может подтвердить качество своих собственных процессов управления защищенностью с помощью сертификата соответствия требованиям стандарта ISO 27001:2013 (версия стандарта ISO 27001:2005 уже, к сожалению, сильно устарела).

В следующей статье мы рассмотрим, как же совместить все эти стандарты и зоны ответственности вместе, и сделать так, чтобы при размещении в облаке система была защищена. Не переключайтесь!

Читайте также: