PCI DSS: что это такое и как под него сертифицироваться + наш опыт

Изначально у каждой платёжной системы — Visa, MasterCard, American Express, JCB и Discover — имелись свои программы с минимальным набором требований по безопасности при работе с данными держателей карт, и эти требования пересекались. Затем был сформирован Совет Payment Card Industry Security Standards Council (PCI SSC), в который вошли платёжные системы, указанные раньше. В 2004 году была выпущена первая версия PCI DSS 1.0. В ней были описаны минимальные требования ко всем участникам процесса хранения, обработки и передачи данных держателей карт.

Где-то во второй половине 2000-х стали активно развиваться облачные вычисления. Выяснилось, что некоторые нюансы облаков как относительно нового типа хостинга не учитываются в текущей версии стандарта PCI DSS. Например, не учитывается архитектура, в которой идёт постоянное изменение набора компонентов и их количества, а также реализация некоторых технических решений. Часть требований может быть неприменима из-за отсутствия различных процессов. Например, требования раздела 4 про шифрование платёжных данных при передаче через сети общего пользования. В нашем случае данная задача ложится полностью на клиента. По большей части одни и те же требования применяются как к площадке хостинга, так и к виртуальной инфраструктуре клиента.

В целом все пункты очень здравые и на первый взгляд понятные. Вот прямо взять и сделать. Но когда начинаешь делать — начинаются сложности и толкования. Например, в требованиях стандарта есть пункт о необходимости статического анализа кода. У нас большая часть кода написана на языке Python, в настоящий момент статических анализаторов кода нет — точнее, есть, например, Bandit, но конкретно к нашей истории он не подходил. Поэтому выполнять анализ кода на безопасность стал человек Пётр. Именно его мы сдавали как статический анализатор. Человек Пётр требованиям к анализатору соответствовал. Примерно в том же ключе шли некоторые другие пункты.

Наши заказчики используют облако для решения своих задач. Например, решили добавить какой-то сервис в банке, а потом через полгода выяснилось, что он в продакшине жрёт слишком много ресурсов, и надо дозакупать железо. Железо едет долго, оно дорогое, согласования мучительные. Естественно, с облаком в разы удобнее — да и все уже давно привыкают платить за ресурсы по мере потребления и быстро масштабироваться.

Но просто так взять и встать в облако нельзя — площадка облачного провайдера (то есть в данном случае наша), на которой заказчики хранят, обрабатывают и передают данные держателей карт платёжных систем Visa и MasterСard, должна соответствовать стандарту PCI DSS. Иначе с ним нельзя работать. Если клиент не работает с такими данными, то сертификация ему не нужна.

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

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

Мы готовились к аудиту больше года.

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

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

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

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

Шли по пунктам.

Вот, например, нужно вести учёт всех системных компонентов документированно. Сюда входит всё, что относится к платформе: сетевое оборудование, средства мониторинга, все инфраструктурные серверы, средства защиты и т. д. Для каждого компонента требуется указать его расположение, версию ПО, IP-адрес. Когда у тебя таких компонентов 50 — проблем нет, но что делать, если их 500? Вдобавок количество компонентов постоянно меняется — и не только в разрезе числа серверов, но и по ролям на каждом сервере. Всё облако построено на ролях, может добавиться сервер с ролью, может добавиться роль к серверу. И всё это многообразие постоянно движется, причём, как правило, в большую сторону. Понятное дело, что ручным трудом тут не обойдёшься, пока будешь составлять актуальный список, он уже изменится, возможно, несколько раз. Пришлось внедрять самописную автоматизацию — систему сбора данных по облаку, чтобы в любой момент времени получить подробный отчёт о всех компонентах. Такая же была проблема с сетевыми схемами. Стандарт требует отображения всех компонентов на уровне L2-L3-модели модели OSI. Их также больше 500, и их тяжело отобразить на одной схеме. А главное, схема будет совсем нечитаемой. Искали варианты, как сгруппировать, чтобы просто это можно было охватить взглядом. Схему сделать надо, а это сложно (и порой кажется почти нереализуемым). Тоже нашли выход.

Есть проблемы мониторинга — расширенные журналы регистрации событий и система контроля целостности на всех компонентах.

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

Вторая проблема — механизм контроля целостности. Для начала нужно было определить список критичных конфигураций и логов, за которыми нужно следить, создать под них шаблоны и разлить согласно ролям. В принципе задача достаточно тривиальная — за одним но… Из-за объёма триггер может сработать на автоматизированный процесс. Поначалу мы получали тонны писем о срабатывании системы контроля со всех компонентов. Ушло немало трудочасов, чтобы всё настроить.

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

Перед проведением внутреннего сканирования в первый раз надо очень аккуратно настроить профили сканирования и прогнать их на тестинге по многу раз, чтобы выявить любые отклонения от нормальной работы сервисов. Расчётная часть была довольно интересная. То же касается и тестирования на проникновение — нужно обговорить все детали, прежде чем начнут ломать прод. Во время теста пришлось пристально смотреть на системы мониторинга, чтобы заметить любые отклонения.

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

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

В итоге в проекте было поставлено 478 Jira-тикетов, потребовался 1 год. Аудитора мы постоянно дёргали вопросами, он отвечал, толковал и делился мировым опытом. Результат — сертификат на облачную платформу на базе KVM. И сразу несколько заказчиков, которые хотят обрабатывать свои платёжные данные там.

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