Руководство по настройке PCI для Edge Public Cloud

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Чтобы клиент соответствовал требованиям PCI в общедоступном облаке Apigee Edge, он должен выполнить некоторые действия и процессы, принадлежащие ему в рамках «Модели общей ответственности». Следующие пункты должны быть проверены клиентами, которые приобрели пакет соответствия PCI и должны соответствовать требованиям PCI. Эти элементы являются самообслуживаемыми в Edge, и их необходимо решить, чтобы организация клиента соответствовала требованиям PCI. Общая концепция заключается в следующем: «Google защищает платформу, клиент защищает свои данные».

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

Клиенты должны использовать Матрицу ответственности Google Apigee PCI-DSS 3.2.1 и предоставить ее своему сертифицированному оценщику безопасности PCI при проведении собственного аудита PCI.

Сопоставление требований PCI

Чтобы получить сертификат соответствия стандарту безопасности данных PCI (AOC), откройте заявку в службе поддержки Apigee или обратитесь в отдел продаж Apigee.

Трассировка/отладка

Trace/Debug — это инструмент устранения неполадок, который позволяет пользователю просматривать состояние и содержимое вызова API по мере его обработки через процессор сообщений Apigee. Трассировка и отладка — это два названия одной и той же службы, но доступ к которым осуществляется с помощью разных механизмов. Trace — это имя этой службы внутри пользовательского интерфейса Edge. Debug — это имя той же службы, используемой через вызовы API. Использование термина «Трассировка» в этом документе справедливо как для трассировки, так и для отладки.

Во время сеанса трассировки применяется «Маскирование данных». Этот инструмент может блокировать отображение данных во время трассировки. См. раздел «Маскирование данных» ниже.

Зашифрованные карты значений ключей (KVM) могут использоваться для клиентов PCI. Если используется зашифрованный KVM, Trace по-прежнему можно использовать, но некоторые переменные не будут видны на экране дисплея Trace. Можно предпринять дополнительные шаги для отображения этих переменных во время трассировки.

Подробные инструкции по использованию Trace доступны в разделе Использование инструмента Trace .

Подробную информацию о KVM, включая зашифрованные KVM, можно найти в разделе Работа с картами значений ключей .

Использование/Разрешения

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

Поскольку у Trace есть доступ к полезной нагрузке вызовов API (формально называемой «Тело сообщения»), важно учитывать, у кого есть доступ для запуска Trace. Поскольку управление пользователями является обязанностью клиента, предоставление разрешений на трассировку также является обязанностью клиента. Apigee, как владелец платформы, имеет возможность добавлять пользователя в клиентскую организацию и назначать ему привилегии. Эта возможность используется только по запросу клиента на поддержку в ситуации, когда выясняется, что служба поддержки клиентов дает сбой, и считается, что просмотр сеанса трассировки предоставляет лучшую информацию о основной причине.

Маскирование данных

Маскирование данных предотвращает отображение конфиденциальных данных только во время сеанса трассировки/отладки, как в трассировке (пользовательский интерфейс Edge), так и в серверной части с помощью отладки (API Edge). Подробные сведения о настройке маскировки см. в разделе Маскирование и скрытие данных . Маскирование конфиденциальных данных является частью Требования PCI 3 — Защита хранящихся данных о держателях карт.

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

Кэш L1 и L2

Кэширование доступно клиентам PCI только для нерегулируемых данных. Кэш не следует использовать для данных держателя карты PCI (CHD); он не одобрен аудитом соответствия PCI Apigee в качестве места хранения CHD. В соответствии с рекомендациями PCI ( Требование 3: Защитите сохраненные данные держателей карт ) данные PCI должны храниться только в месте, совместимом с PCI. Использование кэша L1 также автоматически использует кэш L2. Кэш L1 предназначен только для памяти, а кэш L2 записывает данные на диск для синхронизации между несколькими кэшами L1. Кэш L2 — это то, что обеспечивает синхронизацию нескольких процессоров сообщений в регионе и во всем мире. В настоящее время невозможно включить кэш L1 без кэша L2. Кэш L2 записывает данные на диск, чтобы их можно было синхронизировать с другими процессорами сообщений клиентской организации. Поскольку кэш L2 записывает данные на диск, использование кэша для CHD или других данных с ограниченным доступом не поддерживается.

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

Подробные инструкции по использованию кэша доступны в разделе Добавление кэширования и персистентности .

Аудиторский след

Клиенты имеют возможность просматривать журнал аудита всех административных действий, выполняемых в организации клиента, включая использование Trace. Подробные инструкции доступны здесь и в разделе Использование инструмента «Трассировка» . ( Требование PCI 10: Отслеживание и контроль любого доступа к сетевым ресурсам и данным держателей карт )

Сложные требования к паролю или SAML

Клиенты с особыми требованиями к паролям должны использовать SAML для удовлетворения своих индивидуальных требований. См . Включение аутентификации SAML для Edge . Edge также предлагает многофакторную аутентификацию ( Требование PCI 8: Назначьте уникальный идентификатор каждому человеку, имеющему доступ к компьютеру ). См. раздел Включение двухфакторной аутентификации для вашей учетной записи Apigee .

Безопасность конечных точек

Сканирование конечных точек

Сканирование и тестирование хостов необходимы для соответствия PCI ( Требование 11: Регулярно тестировать системы и процессы безопасности ). В случае Edge Cloud клиенты несут ответственность за сканирование и тестирование своих конечных точек API (иногда называемых «компонентами среды выполнения») в Edge. Тестирование клиентов должно охватывать фактические прокси-сервисы API, размещенные в Edge, где трафик API отправляется в Edge перед обработкой и последующей доставкой в ​​центр обработки данных клиента. Тестирование общих ресурсов, таких как пользовательский интерфейс портала управления, не одобрено для отдельных клиентов (отчет третьей стороны, охватывающий тестирование общих служб, доступен клиентам в соответствии с соглашением о неразглашении и по запросу).

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

Клиенты, тестирующие свои конечные точки, должны искать любые проблемы, связанные с API, любые проблемы, связанные со службами Apigee, а также проверять TLS и другие настраиваемые элементы. Любые элементы, связанные с услугами Apigee, следует сообщать Apigee посредством запроса в службу поддержки.

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

Конфигурация TLS

Согласно стандартам PCI , SSL и ранние версии TLS необходимо перенести на защищенные версии. Клиенты несут ответственность за определение и настройку своих собственных конечных точек TLS для прокси-серверов API. Это функция самообслуживания в Edge. Требования клиентов к шифрованию, выбору протоколов и алгоритмов широко варьируются и специфичны для отдельных случаев использования. Поскольку Apigee не знает подробностей о конструкции API каждого клиента и полезных данных данных, клиенты обязаны определить подходящее шифрование для передаваемых данных. Подробные инструкции по настройке TLS доступны на TLS/SSL .

Хранение данных

Хранение данных в Edge не требуется для правильной работы Edge. Однако в Edge есть сервисы для хранения данных. Клиенты могут использовать кэш, карты значений ключей или аналитику для хранения данных. Ни одна из этих служб не имеет права хранить CHD согласно аудиту Apigee PCI. Согласно Требованию PCI 3 (Защита хранимых данных о держателях карт) данные PCI должны храниться только в местах, совместимых с PCI. Использование этих услуг доступно клиентам для хранения данных, не относящихся к PCI, или других неограниченных данных, при условии соблюдения требований безопасности и законодательства клиента. Эти службы являются элементами самообслуживания клиента, поэтому клиент несет ответственность за настройку их таким образом, чтобы они не фиксировали и не хранили CHD. Администраторам клиентов рекомендуется проверять конфигурацию, политики и развертывания, чтобы избежать случайного или злонамеренного использования служб хранения данных в Edge несоответствующим требованиям образом.

Шифрование данных

Инструменты шифрования данных не предлагаются клиентам для использования внутри Edge. Однако клиенты могут зашифровать свои данные PCI перед отправкой в ​​Edge. Требование PCI 4: (Шифрование передачи данных о держателях карт в открытых общедоступных сетях) рекомендует шифровать данные о держателях карт в открытых общедоступных сетях. Зашифрованные данные в полезных данных (или теле сообщения) не мешают работе Edge. Некоторые политики Edge могут быть неспособны взаимодействовать с данными, если они получены клиентом в зашифрованном виде. Например, преобразование невозможно, если Edge не может изменить сами данные. Но другие политики, а также политики и пакеты, созданные клиентами, будут работать, даже если полезные данные зашифрованы.