ГОСТ Р 59163-2020. Национальный стандарт Российской Федерации. Информационные технологии. Методы и средства обеспечения безопасности. Руководство по обеспечению безопасности при внедрении серверов виртуализации

(утв. и введен в действие Приказом Росстандарта от 10.11.2020 № 1039-ст)

Утвержден и введен в действие Приказом Федерального

Предисловие

1 РАЗРАБОТАН Федеральным государственным учреждением «Федеральный исследовательский центр „Информатика и управление“ Российской академии наук» (ФИЦ ИУ РАН) и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 10 ноября 2020 г. № 1039-ст

Введение

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

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

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

1 Область применения

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

Действие документа не распространяется на (исключения см. 5.3.2):

• виртуализацию настольных ПК, ОС, сетей и хранилищ;
• процедуру аттестации поставщиков.

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

2 Нормативные ссылки

ГОСТ ISO/IEC 17788 Информационные технологии. Облачные вычисления. Общие положения и терминология

ГОСТ Р 56938-2016 Защита информации. Защита информации при использовании технологий виртуализации. Общие положения

ГОСТ Р ИСО/МЭК 27002-2012 Информационная технология. Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального органа исполнительной власти в сфере стандартизации в сети Интернет или по ежегодно издаваемому информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячно издаваемого информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины и определения

Для целей настоящего стандарта применяются термины и определения из ГОСТ ISO/IEC 17788, а также следующие термины с соответствующими определениями.

3.1 домен (domain): Набор или кластер виртуальных машин (3.7), размещенных на одном или нескольких СВ (3.8).

3.2 гостевая операционная система (guest operation system): Операционная система, установленная на виртуальной машине (3.7).

3.3 хостовая система сервера (host operating system): Операционная система, в среде которой функционирует гипервизор (3.4).

Примечание - ОС сервера не является обязательным компонентом виртуализированного сервера.

3.4 гипервизор [вычислительных систем] (hypervisor): Программа, создающая среду функционирования других программ (в том числе других гипервизоров) за счет имитации аппаратных средств вычислительной техники, управления данными средствами и гостевыми операционными системами, функционирующими в данной среде (монитор виртуальных машин) (3.7).

3.5 подсистема управления (management subsystem): Компонент СВ (3.8), который позволяет администраторам настраивать компоненты СВ (3.8).

3.6 аппаратное обеспечение (hardware): Физические ресурсы, включая процессоры, память, устройства и соответствующее микропрограммное обеспечение.

3.7 виртуальная машина, ВМ (virtual machine): Виртуальная вычислительная система, которая состоит из виртуальных устройств обработки, хранения и передачи данных и которая дополнительно может содержать аппаратное обеспечение (3.6) и пользовательские данные.

3.8 сервер виртуализации, СВ (virtual server): Физический сервер, на котором установлен гипервизор (3.4), позволяющий запускать несколько виртуальных машин (3.7).

3.9 администратор серверов виртуализации, администратор СВ (virtualized server administrator): Лицо, обладающее правами и обязанностями по настройке и управлению компонентами СВ (3.8).

3.10 менеджер виртуальных машин, МВМ (virtual machine manager): Все программные продукты, которые позволяют ВМ (3.7) работать на виртуализированной платформе, включая гипервизор (3.4), служебные ВМ, драйверы виртуальных и физических устройств.

3.11 эталонный образ ВМ (golden VM image): Мастер-копия (исходная копия для тиражирования) образа диска ВМ (3.7) или сервера с определенной конфигурацией.

4 Обозначения и сокращения

5 Общие сведения о виртуализации серверов

5.1 Типы виртуализации серверов

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

Первый аспект касается полной виртуализации в сравнении с паравиртуализацией:

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

Второй аспект относится к платформе, на которой установлен гипервизор. Существует два типа гипервизоров:

• гипервизоры 1-го типа, также известные как «аппаратные гипервизоры», устанавливаются непосредственно на аппаратное обеспечение в качестве системного программного обеспечения;
• гипервизоры 2-го типа, устанавливаемые в среде хостовой операционной системы в качестве прикладного программного обеспечения.

5.2 Компоненты СВ

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

Рисунок 1 — Функциональные компоненты СВ

Как показано на рисунке 1, СВ состоит из следующих функциональных компонентов:

• гипервизор;
• ВМ;
• аппаратное обеспечение;
• ОС сервера (необязательно);
• другие компоненты, например, подсистема/подсистемы управления с функциями настройки и управления СВ для администратора.

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

5.3 Технические рекомендации

5.3.1 Общая информация

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

5.3.2 Исключения

5.3.2.1 Подтверждение поставщика

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

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

5.3.2.2 Рабочая среда

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

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

6 Обзор угроз безопасности и рисков

6.1 Общая информация

Угрозы и риски для виртуализированной инфраструктуры (в которой вычислительные узлы преимущественно состоят из СВ) можно разделить на два типа:

- общие угрозы: угрозы, актуальные для всех типов ИТ-инфраструктур (виртуализированных или не виртуализированных);

- риски, актуальные только для СВ: риски, которые затрагивают конфиденциальность, целостность и доступность СВ.

Сводные данные об угрозах и мерах защиты информации, обрабатываемой с помощью технологий виртуализации, приведены в ГОСТ Р 56938-2016, приложение Б.

6.2 Общие угрозы

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

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

- сторонний программный продукт: уязвимости стороннего программного продукта, используемого в качестве компонента СВ (например, драйверов устройств), могут поставить под угрозу безопасность всего СВ;

- несанкционированный доступ: пользователь может получить несанкционированный доступ к данным и исполняемому на СВ коду. Злоумышленник, процесс или внешний ИТ-объект могут сымитировать разрешенный объект для получения несанкционированного доступа к данным или ресурсам СВ;

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

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

6.3 Риски, специфичные для СВ

6.3.1 Общая информация

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

• риски, связанные с ВМ;
• риски, связанные с гипервизором;
• операционные риски, связанные с реализацией;
• риски, связанные с облачными службами.

6.3.2 Риски, связанные с ВМ

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

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

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

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

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

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

6.3.3 Риски, связанные с гипервизором

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

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

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

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

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

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

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

6.3.4 Операционные риски, связанные с реализацией

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

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

6.3.5 Риски, связанные с облачными службами

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

- риск, связанный с API поставщика облачных служб: реализация гибридной (приватной/публичной) облачной виртуализации может представлять угрозу безопасности интегрирования аутентификации и учетных записей. CSP предоставляют набор программных интерфейсов или API, который предприятие может использовать для управления облачными службами и взаимодействия с ними. Если подобные интерфейсы не разработаны с учетом защиты от случайных и злонамеренных попыток обойти корпоративные политики, они могут создавать дополнительные риски;

- использование ВМ в облачных службах: многие CSP предлагают услуги, основанные на функциональности ВМ. Требования к безопасности и обязанности по реализации таких требований различаются в зависимости от типа возможностей облачной службы (см. [1]). Например, в облачной службе на основе инфраструктуры CSC может отвечать за настройку и реализацию различных аспектов безопасности ВМ (а в некоторых случаях и безопасности гипервизора), тогда как в облачной службе на основе платформы часть этой ответственности может быть возложена на CSP;

- общая безопасность облачных служб: при организации защиты ВМ в облачной среде следует учитывать и другие аспекты безопасности. Дополнительные сведения приведены в [1] - [4].

7 Рекомендации по обеспечению безопасности жизненного цикла СВ

7.1 Общая информация

Целью безопасного проектирования и реализации СВ является обеспечение конфиденциальности, целостности и доступности информации, обрабатываемой и хранящейся на виртуальных серверах. Безопасное развертывание СВ требует выполнения нескольких стратегических задач на всех четырех этапах: предварительной подготовки, планирования и проектирования, реализации и вывода из эксплуатации. Эти задачи приведены в подразделах 7.2 - 7.5. Кроме того, в разделе 8 описаны существующие проблемы безопасности, а в разделе 9 содержится контрольный список для обеспечения безопасности СВ.

Приступая к виртуализации серверов, предприятие должно внедрить свою структуру управления информационной безопасностью в виртуализированных ИТ-системах и службах. Для того чтобы виртуализация позволила заинтересованным сторонам получать прибыль, необходимо организовать надлежащее управление и контроль над ИТ-активами. Организации, занимающиеся внедрением виртуализации, должны выбрать всеобъемлющую методологию, например COBIT 5, которая позволит им достичь своих технологических целей и получить прибыль, а также будет соответствовать требованиям законодательства Российской Федерации и национальным стандартам в области защиты информации и обеспечения информационной безопасности.

Неотъемлемой частью структуры управления безопасностью является процедура оценки рисков. Процедура оценки рисков в контексте виртуализированной инфраструктуры состоит из выявления рисков (см. раздел 6), оценки вероятности их возникновения и анализа их последствий с целью установления надлежащих мер контроля для их заблаговременного устранения. Более подробную информацию о процедуре, которую предприятия различных размеров и уровней сложности могут использовать без изменений или адаптировать под свои нужды см. в [5], [6]. Некоторые ключевые элементы, которые следует учитывать при оценке рисков для виртуализированной инфраструктуры, приведены в приложении А.

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

7.2 Этап предварительной подготовки

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

• идентификация активов;
• сбор требований;
• обзор требований;
• оценка технических возможностей и ограничений;
• оценка существующих систем и методов реализации с учетом требований безопасности;
• разработка модели угроз безопасности СВ.

Более подробная информация о том, как перечисленные этапы позволяют получить исходные данные для проектирования и реализации безопасности сети см. в [7]. Тем не менее их можно использовать и при разработке, реализации и выводе из эксплуатации системы безопасности СВ.

7.3 Этап планирования и проектирования

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

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

Вопросы безопасности на этапе планирования и проектирования описаны в подразделе 8.2.

7.4 Этап реализации

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

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

Список контрольных вопросов по безопасности этапа реализации приведен в подразделе 9.2.

7.5 Этап вывода из эксплуатации

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

8 Этап планирования и проектирования: вопросы безопасности

8.1 Общая информация

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

8.2 Вопросы безопасности и соответствующие рекомендации

Вопросы безопасности и соответствующие рекомендации приведены в таблице 1.

Таблица 1

Вопросы безопасности (этап планирования и проектирования)

9 Этап реализации: список контрольных вопросов по безопасности

9.1 Общая информация

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

9.2 Список контрольных вопросов по безопасности

Список контрольных вопросов по безопасности приведен в таблице 2.

Таблица 2

Список контрольных вопросов по безопасности (этап реализации)

Приложение А (справочное)

ОЦЕНКА РИСКОВ ДЛЯ СВ

А.1 Общие сведения

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

а) оценка вероятности возникновения риска с использованием таблицы А.2;

б) оценка значимости последствий для предприятия с учетом конфиденциальности/целостности/доступности данных по таблице А.3;

в) оценка общей значимости последствий по таблице А.4, основываясь на максимальном уровне риска, связанного с нарушением конфиденциальности/целостности/доступности данных трех таблиц А.1 - А.3;

г) определение мер для устранения или снижения риска до приемлемого уровня;

д) оценка остаточного уровня риска после принятия мер;

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

А.2 Матрица оценки рисков

В таблице А.1 приведен образец шаблона для оценки риска.

Таблица А.1

Матрица оценки рисков

А.3 Вероятность

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

Таблица А.2

Оценка вероятности для связанной уязвимости

А.4 Уровень значимости

В таблице А.3 приведены критерии для определения уровня значимости риска с учетом нарушения конфиденциальности/целостности/доступности.

А.5 Матрица оценки риска

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

ПО БЕЗОПАСНОСТИ (см. таблицу 2)

Б.1 Были ли реализованы политики и функции управления, которые предотвращают неконтролируемое увеличение количества ВМ?

На этапе реализации организация должна предусмотреть:

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

Б.2 Защищены ли конфиденциальные данные в ВМ?

На этапе реализации организация должна:

• шифровать данные, хранящиеся на виртуальных и облачных серверах, чтобы сделать их нечитаемыми. Необходимо найти решение, предусматривающее простое управление ключами, хранящимися на физических, виртуальных и облачных серверах, с учетом применяемых политик. Выпускать ключи шифрования/дешифрования можно только для проверенных и авторизованных физических и виртуальных серверов. Следует предоставить службы для управления ключами на объекте и (или) в облачной среде. Соответствующая применяемым политикам система управления ключами должна определять, где и когда можно получать доступ к зашифрованным данным. Проводить проверки подлинности и целостности в случае, когда ВМ запрашивают доступ к защищенным секторам хранилища. Рекомендуется шифровать как загрузочный том, так и том данных;
• разрабатывать политики для ограничения возможности хранения образов и снимков ВМ. Если требуется хранить образы и снимки, необходимо получить надлежащее разрешение (например, вторичного уровня) и внедрить соответствующие процессы мониторинга и контроля. Чтобы снизить риск, следует тщательно продумать, где хранить копии образов и снимков. Для проведения проверок или аудитов необходимо обеспечить ведение журнала действий, а также внедрить формальную процедуру изменения образа, в которую входят его создание, распространение, хранение, использование, вывод из эксплуатации и удаление;
• внедрять политики, гарантирующие сброс систем резервного копирования и восстановления после сбоя, включая временные экземпляры для обновления/исправления, в случае удаления и стирания (заполнения нулями) образов ВМ. При использовании твердотельных накопителей следует соблюдать особую осторожность, чтобы избежать появления «остаточной информации»;
• рассмотреть возможность использования криптографической защиты контрольных сумм для обнаружения несанкционированных изменений образов и снимков ВМ;
• выявить критически важные файлы данных в ВМ, требующие более тщательного мониторинга и ведения журналов.

Б.3 Применяются ли меры безопасности для автономных и неактивных ВМ?

На этапе реализации организация должна:

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

Б.4 Реализуются ли меры безопасности в отношении предварительно настроенных (с помощью эталонного образа) и активных ВМ?

На этапе реализации организация должна:

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

Б.5 Обеспечена ли прозрачность трафика и внедрены ли элементы управления виртуальными сетями?

На этапе реализации организация должна:

• осуществлять мониторинг виртуальных сетей и трафика данных по аналогии с физическими сетями. Организация должна тщательно отобрать инструмент, который будет использоваться для этой задачи, а также настроить его для зеркального отображения сетевых портов, чтобы по возможности обеспечить единое представление трафика как физических, так и виртуальных сетей;
• рассмотреть возможность использования гипервизора, который сможет в ходе работы контролировать все гостевые ОС (самоанализ ВМ), если отдельные инструменты для мониторинга каналов связи между ВМ не установлены;
• внедрять технологии безопасности физических и виртуальных сред и согласованную структуру управления политиками и их реализации;
• согласовать политику обеспечения безопасности и конфигурацию физической/виртуальной сети;
• использовать предназначенные для ВМ механизмы безопасности, встроенные в API гипервизора, для осуществления детального мониторинга трафика из плоскостей данных и управления ВМ. Использовать инструменты, основанные на современных технологиях, например SDN, NFV или OpenFlow. Традиционные средства контроля безопасности сети не могут анализировать такие механизмы.

Б.6 Внедрены ли меры контроля и политики для предотвращения нехватки ресурсов?

На этапе реализации организация должна:

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

Б.7 Внедрены ли меры для обеспечения безопасности гипервизора?

На этапе реализации организация должна:

• использовать гипервизоры, занимающие меньше памяти (1-го, а не 2-го типа), для сокращения числа уязвимостей и направлений атаки;
• повысить степень защиты настроек гипервизора, для сокращения числа потенциальных уязвимостей (например, отключить совместное использование памяти ВМ, работающими на одних серверах с гипервизором);
• где возможно, применять рекомендуемые поставщиком методики работы;
• отсоединять неиспользуемые физические устройства, отключать буфер обмена и службы обмена файлами;
• проводить самостоятельные проверки целостности при загрузке с целью обнаружения нарушений в защите гипервизора. Использовать технологии контроля целостности гипервизора, например, Intel Trusted Platform Module/Trusted Execution Technology;
• отслеживать признаки нарушения безопасности, постоянно анализируя журналы гипервизора;
• подписаться на получение материалов/предупреждений по безопасности от производителя гипервизора и своевременно внедрять обновления безопасности;
• убедиться в наличии эффективной методики установки исправлений для гипервизора;
• внедрить и поддерживать эффективные средства идентификации и контроля доступа для всех инструментов, сценариев и приложений, которые вызывают API управления гипервизором.

Б.8 Внедрены ли меры по предотвращению несанкционированного доступа к гипервизору?

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

• развернуть платформы виртуализации, поддерживающие управление доступом к административным функциям на основе ролей. Также можно рассмотреть возможность использования заимствованных инструментов для осуществления более единообразного и строгого административного контроля в среде и для упрощения аудита. Для обеспечения дополнительного контроля в средах с общим доступом к функциям следует применять правило двойного контроля. Например, уполномоченный подрядчик сможет создать сетевой коммутатор только после проверки и одобрения запроса уполномоченным сетевым инженером;
• ограничить доступ к консоли управления гипервизором и важным API/CLI с помощью специальных межсетевых экранов;
• после внедрения контроля доступа на основе ролей необходимо проверить работу функций политик контроля доступа;
• максимально ограничить количество учетных записей пользователей (включая привилегированные), требующих прямого доступа к серверу гипервизора. Объединить учетные записи пользователей с надежными системами управления учетными данными и аутентификации для обеспечения соблюдения политик безопасности (т.е. политик использования паролей и двухфакторной аутентификации);
• использовать многофакторную аутентификацию или двойной контроль для ограничения доступа (см. 9.1.1 и 11.1.2 в ГОСТ Р ИСО/МЭК 27002-2012);
• внедрить надежную процедуру управления изменениями для всех компонентов инфраструктуры (например, настроек), которые могут непреднамеренно предоставить несанкционированный доступ к гипервизору;
• обеспечить защиту всех интерфейсов управления гипервизором, доступных через локальную сеть и удаленно. Отключить удаленное управление гипервизорами. Если это невозможно, рассмотреть возможность предоставления доступа по безопасному сетевому соединению и использования двухфакторной аутентификации. Кроме того, следует внедрить политики сеансов управления. Например, следует обрывать простаивающие/неактивные соединения, чтобы предотвратить злоупотребление функциями управления/клиентом;
• развернуть отдельную сервисную локальную компьютерную сеть для управления доступом к гипервизорам.

Б.9 Внедрены ли элементы управления и политики для предотвращения взлома учетных записей и служб?

Уязвимости портала могут привести к атакам с превышением полномочий. На этапе реализации организация должна:

• выборочно применять административный контроль, в зависимости от ролей и потребностей пользователей;
• по возможности применять строгие методы аутентификации, защищая как клиентскую, так и серверную часть оборудования для облачных вычислений от потенциальных атак. Для ограничения доступа необходимо использовать многофакторную и (или) разделенную аутентификацию. Например, организация может использовать двухфакторную аутентификацию (см. 9.1.1 и 11.1.2 в ГОСТ Р ИСО/МЭК 27002-2012);
• использовать проактивный мониторинг для обнаружения несанкционированных действий;
• провести анализ политик безопасности и соглашений об уровне обслуживания поставщика облачных служб;
• рассмотреть возможность управления порталами самообслуживания с помощью политик;
• добавить в политики и руководящие указания пункты о создании и использовании порталов самообслуживания;
• обеспечить безопасное управление учетными записями, личными и учетными данными;
• регулярно проводить тестирование портала самообслуживания на предмет возможности проникновения с целью выявления уязвимостей.

Б.10 Внедрены ли меры безопасности для надлежащего и безопасного разделения обработки информации различных категорий на физических серверах?

На этапе реализации организация должна:

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

Б.11 Внедрены ли меры для обеспечения безопасности API поставщика облачных услуг?

На этапе реализации организация должна:

• внедрить строгую систему аутентификации и контроля доступа с зашифрованной передачей данных;
• использовать две разные зоны аутентификации — для внутренних организационных систем и внешних систем;
• передавать трафик, связанный со службами каталогов, через частный/внеполосный зашифрованный канал, который отделен от обычного интернет-трафика (при передаче по сети Интернет);
• изучить возможность использования федерации удостоверений, для которой могут потребоваться:
• формальные интернет-стандарты, например спецификация языка разметки декларации безопасности OASIS;
• технологии с открытым исходным кодом и (или) другие опубликованные спецификации, например информационные карты, OpenID, Higgins trust framework или проект Novell Bandit;
• применить корпоративные политики безопасности, соответствия требованиям и управления к активам, используемым в гибридных облачных средах, а также внедрить инструменты для комплексного мониторинга и отчетности.

Б.12 Используются ли автоматизированные процессы для проверки выпускаемых версий исправлений и их установки в программный продукт гипервизора и программные модули гостевой ОС?

На этапе реализации организация должна:

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

БИБЛИОГРАФИЯ