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

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

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

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

Клиентам следует ссылаться на матрицу общей ответственности Google Cloud Plaform: PCI DSS v4.0.1 и предоставить ее своему квалифицированному оценщику безопасности PCI при проведении собственного аудита PCI.

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

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

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

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

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

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

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

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

Использование/Авторизации

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

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

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

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

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

Кэш L1 и L2

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

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

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

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

Клиенты имеют возможность просматривать аудиторский след всех административных действий, выполненных в организации клиента, включая использование Trace. Подробные инструкции доступны здесь и в разделе Использование инструмента 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. Но другие политики и политики и пакеты, созданные клиентом, будут работать, даже если полезная нагрузка данных зашифрована.