Hacker
Professional
- Messages
- 1,044
- Reaction score
- 822
- Points
- 113
Облачные вычисления создают некоторые уникальные проблемы для создания и обслуживания безопасных систем. Когда кто-то говорит, что использует «облако», на самом деле они говорят, что используют «чужой компьютер». Когда вы вспоминаете, что облако - это на самом деле просто чей-то компьютер, это ясно показывает, насколько сложной может быть безопасность.
В этой новой модели никто не несет ответственности за безопасность всей системы. Вместо этого эта ответственность делится между поставщиком и его клиентом (вами!). У Amazon AWS есть полезная диаграмма, иллюстрирующая это разделение в их среде, но большинство облачных сервисов схожи.
Модель общей ответственности Amazon AWS
Многие компании преодолевают трудности и добиваются соответствия требованиям PCI DSS с помощью облачных вычислений. Бизнес, занимающийся этим, варьируется в широком спектре платежей - от обработчиков-эмитентов до продавцов. Некоторое время назад PCI SSC выпустил руководство по облачным вычислениям для соответствия стандарту PCI DSS, что является действительно позитивным шагом. К сожалению, они еще не выпустили версию самого стандарта, полностью охватывающую облако.
При развертывании в облаке у вас нет возможности увидеть физическую безопасность этой среды. Если у поставщика облачных услуг нет AOC, покрывающего хотя бы физическую безопасность, вам действительно будет сложно соблюдать требования. Я уверен, что кто-то найдет способ опровергнуть это с помощью желающего поставщика облачных услуг, но он делает вашу жизнь намного сложнее, идя по этому пути.
Ограничения AOC
Но вам также необходимо знать об ограничениях зависимости от AOC. Тот факт, что поставщик соответствует требованиям PCI DSS, не означает автоматически, что все, что вы делаете в этой среде, также соответствует требованиям. Вы по-прежнему будете сертифицированы самостоятельно, но сможете передать ответственность за определенные аспекты поставщику облачных услуг. Области, в которых такая передача возможна, прописаны в AOC.
Облачный провайдер AOC
В любом AOC, который вы просматриваете, будет перечислено, какие услуги и объекты входят и не входят в область оценки, в результате которой был получен AOC.
При работе с поставщиками облачных услуг у AOC может быть страница за страницей только для тех объектов, которые покрываются. Как правило, в рамках оценки будут охвачены все объекты провайдера, если только они не рекламируют четко дифференцированные на региональном уровне услуги. Поставщикам облачных услуг имеет смысл строить все объекты по единой модели. Это означает, что клиенты могут зависеть от аналогичных возможностей и функций во всех регионах, и на самом деле является свидетельством возможностей этих компаний в области проектирования инфраструктуры.
AOC поставщика облачных услуг также перечислит, какие услуги включены в объем оценки. Как правило, это будет список продуктов торговой марки, например « AWS S3 » или « AWS EC2». Вы вряд ли найдете более подробные описания каких-либо конфигураций сервисов, которые были протестированы в самом AOC.
При разработке среды, соответствующей стандарту PCI DSS, для облачного развертывания, вы должны очень внимательно выбирать, какие облачные сервисы вы используете! Список услуг, на которые распространяется AOC, длинный, но не исчерпывающий. У известных поставщиков есть множество облачных сервисов, которые не входят в их ежегодную оценку PCI - это создало бы проблемы, если бы вы использовали эти сервисы для хранения или обработки данных держателей карт.
На раннем этапе планирования вам следует запросить AOC у ваших потенциальных поставщиков облачных услуг и внимательно изучить регионы и услуги, входящие в область действия.
Модель совместной ответственности
Как QSA узнает, за какие услуги и даже за какие аспекты этих услуг несут ответственность поставщик облачных услуг или их заказчик? Поставщики услуг в области PCI DSS публикуют так называемую матрицу общей ответственности. На высоком уровне это документ, отображающий требования PCI DSS к тем, кто за них отвечает.
Пример такой матрицы от Twilio, поставщика телекоммуникационных услуг, показан ниже:
Пример матрицы совместной ответственности PCI DSS для Twilio.
Каждая запись в матрице совместной ответственности помечена как одна из следующих:
Ответственный поставщик услуг
Для тех пунктов, которые помечены как «только поставщик облачных услуг», вы можете с уверенностью предположить, что QSA обратится к поставщику облачных услуг, AOC, чтобы оценить, соответствуете ли вы требованиям. Ваш QSA может по-прежнему задавать вам вопросы по этой проблеме, чтобы понять, все ли в рамках этого теста выполняется в облаке.
Классическим примером здесь является физическая безопасность: если поставщик облачных услуг может повлиять на вашу физическую безопасность, он несет исключительную ответственность за это. Тем не менее, QSA все равно должен будет понять, связаны ли ваши единственные потребности в физической безопасности в рамках вашей облачной инфраструктуры. Если у вас есть физический офис, который обрабатывает или хранит CHD, он будет оцениваться отдельно от облака.
Ответственный заказчик
Для тех, кто входит в матрицу, за которых отвечает только клиент, вы будете подвергнуты процессу, аналогичному традиционной оценке.
Соединение
Реальный интерес кроется в вещах, в которых разделяется ответственность. Здесь также обычно находится большинство элементов матрицы. Причина этого проста: большинство услуг, предоставляемых поставщиком облачных услуг, требуют конфигурации клиента. Поставщики облачных услуг поддерживают и регулярно обновляют свои системы и компоненты инфраструктуры, поскольку они хотят поддерживать безопасную среду для клиентов. Но их ответственность за PCI заканчивается на том этапе, когда они передают интерфейс конфигурации клиенту.
Рассмотрим облачный балансировщик сетевой нагрузки. Облачный провайдер предоставляет балансировщик нагрузки, но клиент может выбрать политику SSL в зависимости от своих потребностей. Даже в AWS, на момент написания, политика SSL балансировщика нагрузки по умолчанию не соответствует требованиям PCI, поскольку допускает более ранние версии протокола, чем TLS v1.2. Таким образом, вам нужно внимательно посмотреть на принимаемые вами значения по умолчанию, влияющие на безопасность. То, что конфигурация работает, не означает, что она соответствует требованиям.
Точно так же облачные брандмауэры. Все облачные провайдеры обычно предлагают какую-то фильтрацию пакетов с отслеживанием состояния, которая соответствует требованиям для межсетевых экранов PCI DSS. Однако фактическая политика, разрешающая трафик через брандмауэр, определяется клиентом. Вряд ли облачный провайдер виноват, если клиент открывает telnet-порт для всего Интернета!
Выберите правильный QSAC
Облачные вычисления существуют уже несколько лет, и большинство компаний стремятся перенести хотя бы некоторые рабочие нагрузки в облако. Из-за этой тенденции все чаще встречаются QSA, которые действительно проводили оценку облачной инфраструктуры. Но не все QSA имеют, поэтому, когда вы хотите выбрать QSAC, убедитесь, что вы понимаете осведомленность фирмы об облачных технологиях и, в идеале, вашу команду по работе с клиентами.
Также помните, что каждое общедоступное облако - это собственная частная экосистема. В области сетевых технологий Cisco и Juniper производят устройства с похожей функциональностью, но очень разными способами их настройки. Даже для таких основ, как IP-маршрутизация, между двумя платформами могут быть серьезные пробелы: Cisco определила протокол EIGRP и имеет все доступные проприетарные компоненты; не все конкуренты имеют такой уровень поддержки.
Точно так же в облаке вы обнаружите, что все поставщики предоставляют вам доступ к хранилищу, вычислениям и сетям. Кроме того, они включают компоненты управления и безопасности. Ваш индивидуальный QSA должен будет провести углубленный анализ некоторых из этих конфигураций, и будет полезно, если они действительно видели облачную среду, подобную вашей, раньше. Зная, как взаимодействуют роли AWS IAM и модель развертывания с несколькими учетными записями (текущая передовая практика AWS), можно избежать большой потенциальной путаницы при понимании вашей модели развертывания.
Сделайте правильный выбор
Вы действительно можете упростить внедрение и сертификацию, сделав правильный выбор с самого начала:
В этой новой модели никто не несет ответственности за безопасность всей системы. Вместо этого эта ответственность делится между поставщиком и его клиентом (вами!). У Amazon AWS есть полезная диаграмма, иллюстрирующая это разделение в их среде, но большинство облачных сервисов схожи.
Модель общей ответственности Amazon AWSМногие компании преодолевают трудности и добиваются соответствия требованиям PCI DSS с помощью облачных вычислений. Бизнес, занимающийся этим, варьируется в широком спектре платежей - от обработчиков-эмитентов до продавцов. Некоторое время назад PCI SSC выпустил руководство по облачным вычислениям для соответствия стандарту PCI DSS, что является действительно позитивным шагом. К сожалению, они еще не выпустили версию самого стандарта, полностью охватывающую облако.
Прочный фундамент
Успех любого проекта в срок и в рамках бюджета действительно помогает начать с прочного фундамента. Что это означает для PCI DSS в облаке? Используйте облачного провайдера, у которого уже есть собственный PCI DSS AOC .При развертывании в облаке у вас нет возможности увидеть физическую безопасность этой среды. Если у поставщика облачных услуг нет AOC, покрывающего хотя бы физическую безопасность, вам действительно будет сложно соблюдать требования. Я уверен, что кто-то найдет способ опровергнуть это с помощью желающего поставщика облачных услуг, но он делает вашу жизнь намного сложнее, идя по этому пути.
Ограничения AOC
Но вам также необходимо знать об ограничениях зависимости от AOC. Тот факт, что поставщик соответствует требованиям PCI DSS, не означает автоматически, что все, что вы делаете в этой среде, также соответствует требованиям. Вы по-прежнему будете сертифицированы самостоятельно, но сможете передать ответственность за определенные аспекты поставщику облачных услуг. Области, в которых такая передача возможна, прописаны в AOC.
Облачный провайдер AOC
В любом AOC, который вы просматриваете, будет перечислено, какие услуги и объекты входят и не входят в область оценки, в результате которой был получен AOC.
При работе с поставщиками облачных услуг у AOC может быть страница за страницей только для тех объектов, которые покрываются. Как правило, в рамках оценки будут охвачены все объекты провайдера, если только они не рекламируют четко дифференцированные на региональном уровне услуги. Поставщикам облачных услуг имеет смысл строить все объекты по единой модели. Это означает, что клиенты могут зависеть от аналогичных возможностей и функций во всех регионах, и на самом деле является свидетельством возможностей этих компаний в области проектирования инфраструктуры.
AOC поставщика облачных услуг также перечислит, какие услуги включены в объем оценки. Как правило, это будет список продуктов торговой марки, например « AWS S3 » или « AWS EC2». Вы вряд ли найдете более подробные описания каких-либо конфигураций сервисов, которые были протестированы в самом AOC.
При разработке среды, соответствующей стандарту PCI DSS, для облачного развертывания, вы должны очень внимательно выбирать, какие облачные сервисы вы используете! Список услуг, на которые распространяется AOC, длинный, но не исчерпывающий. У известных поставщиков есть множество облачных сервисов, которые не входят в их ежегодную оценку PCI - это создало бы проблемы, если бы вы использовали эти сервисы для хранения или обработки данных держателей карт.
На раннем этапе планирования вам следует запросить AOC у ваших потенциальных поставщиков облачных услуг и внимательно изучить регионы и услуги, входящие в область действия.
Модель совместной ответственности
Как QSA узнает, за какие услуги и даже за какие аспекты этих услуг несут ответственность поставщик облачных услуг или их заказчик? Поставщики услуг в области PCI DSS публикуют так называемую матрицу общей ответственности. На высоком уровне это документ, отображающий требования PCI DSS к тем, кто за них отвечает.
Пример такой матрицы от Twilio, поставщика телекоммуникационных услуг, показан ниже:
Пример матрицы совместной ответственности PCI DSS для Twilio.
Каждая запись в матрице совместной ответственности помечена как одна из следующих:
- Ответственный поставщик услуг
- Ответственный заказчик
- Общий
Ответственный поставщик услуг
Для тех пунктов, которые помечены как «только поставщик облачных услуг», вы можете с уверенностью предположить, что QSA обратится к поставщику облачных услуг, AOC, чтобы оценить, соответствуете ли вы требованиям. Ваш QSA может по-прежнему задавать вам вопросы по этой проблеме, чтобы понять, все ли в рамках этого теста выполняется в облаке.
Классическим примером здесь является физическая безопасность: если поставщик облачных услуг может повлиять на вашу физическую безопасность, он несет исключительную ответственность за это. Тем не менее, QSA все равно должен будет понять, связаны ли ваши единственные потребности в физической безопасности в рамках вашей облачной инфраструктуры. Если у вас есть физический офис, который обрабатывает или хранит CHD, он будет оцениваться отдельно от облака.
Ответственный заказчик
Для тех, кто входит в матрицу, за которых отвечает только клиент, вы будете подвергнуты процессу, аналогичному традиционной оценке.
Соединение
Реальный интерес кроется в вещах, в которых разделяется ответственность. Здесь также обычно находится большинство элементов матрицы. Причина этого проста: большинство услуг, предоставляемых поставщиком облачных услуг, требуют конфигурации клиента. Поставщики облачных услуг поддерживают и регулярно обновляют свои системы и компоненты инфраструктуры, поскольку они хотят поддерживать безопасную среду для клиентов. Но их ответственность за PCI заканчивается на том этапе, когда они передают интерфейс конфигурации клиенту.
Рассмотрим облачный балансировщик сетевой нагрузки. Облачный провайдер предоставляет балансировщик нагрузки, но клиент может выбрать политику SSL в зависимости от своих потребностей. Даже в AWS, на момент написания, политика SSL балансировщика нагрузки по умолчанию не соответствует требованиям PCI, поскольку допускает более ранние версии протокола, чем TLS v1.2. Таким образом, вам нужно внимательно посмотреть на принимаемые вами значения по умолчанию, влияющие на безопасность. То, что конфигурация работает, не означает, что она соответствует требованиям.
Точно так же облачные брандмауэры. Все облачные провайдеры обычно предлагают какую-то фильтрацию пакетов с отслеживанием состояния, которая соответствует требованиям для межсетевых экранов PCI DSS. Однако фактическая политика, разрешающая трафик через брандмауэр, определяется клиентом. Вряд ли облачный провайдер виноват, если клиент открывает telnet-порт для всего Интернета!
Выберите правильный QSAC
Облачные вычисления существуют уже несколько лет, и большинство компаний стремятся перенести хотя бы некоторые рабочие нагрузки в облако. Из-за этой тенденции все чаще встречаются QSA, которые действительно проводили оценку облачной инфраструктуры. Но не все QSA имеют, поэтому, когда вы хотите выбрать QSAC, убедитесь, что вы понимаете осведомленность фирмы об облачных технологиях и, в идеале, вашу команду по работе с клиентами.
Также помните, что каждое общедоступное облако - это собственная частная экосистема. В области сетевых технологий Cisco и Juniper производят устройства с похожей функциональностью, но очень разными способами их настройки. Даже для таких основ, как IP-маршрутизация, между двумя платформами могут быть серьезные пробелы: Cisco определила протокол EIGRP и имеет все доступные проприетарные компоненты; не все конкуренты имеют такой уровень поддержки.
Точно так же в облаке вы обнаружите, что все поставщики предоставляют вам доступ к хранилищу, вычислениям и сетям. Кроме того, они включают компоненты управления и безопасности. Ваш индивидуальный QSA должен будет провести углубленный анализ некоторых из этих конфигураций, и будет полезно, если они действительно видели облачную среду, подобную вашей, раньше. Зная, как взаимодействуют роли AWS IAM и модель развертывания с несколькими учетными записями (текущая передовая практика AWS), можно избежать большой потенциальной путаницы при понимании вашей модели развертывания.
Сделайте правильный выбор
Вы действительно можете упростить внедрение и сертификацию, сделав правильный выбор с самого начала:
- выберите облачных провайдеров, которые уже соответствуют требованиям PCI и могут продемонстрировать это
- использовать только те услуги, которые входят в объем AOC поставщиков
- работать с QSA, которые знакомы с дивным новым миром корпоративных облачных вычислений
