Руководство по виртуализации PCI DSS. Часть 3

Стандарт: Стандарт безопасности данных PCI (PCI DSS)
Версия: 2.0
Дата: Июнь 2011
Автор: Специальная группа по Виртуализации Совет Стандартов Безопасности PCI
Дополнительная информация: Руководство по виртуализации PCI DSS

Руководство по виртуализации PCI DSS. Часть 1
Руководство по виртуализации PCI DSS. Часть 2

4 Рекомендации

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

4.1 Общие рекомендации

4.1.1 Оцените риски, связанные с виртуальными технологиями

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

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

4.1.2 Понимайте воздействие виртуализации в рамках CDE

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

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

4.1.3 Ограничьте физический доступ

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

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

4.1.4 Реализуйте глубоко эшелонированную защиту

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

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

4.1.5 Изолируйте функции безопасности

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

4.1.6 Обеспечьте наименьшие привилегии и разделение обязанностей

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

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

4.1.7 Оцените технологии гипервизора

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

4.1.8 Укрепите безопасность гипервизора

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

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

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

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

4.1.9 Укрепите безопасность виртуальных машин и других компонентов

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

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

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

4.1.10 Определите правильное использование инструментов управления

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

4.1.11 Признайте динамический характер виртуальных машин

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

4.1.12 Оцените функции безопасности виртуализированной сети

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

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

4.1.13 Четко определите все размещенные виртуальные сервисы

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

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

4.1.14 Понимайте технологию

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

• Центра Интернет-безопасности (CIS)
• Международной Организации по Стандартизации (ISO)
• ISACA (бывшая Ассоциация аудита и контроля информационных систем)
• Национальный Институт Технологии Стандартов (NIST)
• SysAdmin Audit Network Security (SANS) Institute

4.2 Рекомендации для сред смешанного режима

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

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

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

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

4.2.1 Сегментация в средах смешанного режима

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

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

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

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

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

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