Эта статья была сделана в рамках подготовки к вебинару на эту тему. Вы можете посмотреть запись этого вебинара на BrightTalk.

Что такое PCI-DSS?

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

Что такое соответствие PCI-DSS?

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

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

Какие существуют уровни PCI-DSS?

  • Уровень 1: Продавцы, обрабатывающие более 6 миллионов карточных транзакций в год.
  • Уровень 2: Продавцы, обрабатывающие от 1 до 6 миллионов транзакций в год.
  • Уровень 3: Продавцы, обрабатывающие от 20 000 до 1 миллиона транзакций в год.
  • Уровень 4: Продавцы, обрабатывающие менее 20 000 транзакций в год.

Как избежать соответствия PCI-DSS?

Используйте интеграцию, совместимую с PCI. Даже если соответствие PCI-DSS может быть достигнуто в бессерверном контексте, мы настоятельно рекомендуем вам не развертывать собственную систему, совместимую с PCI, а вместо этого полагаться на интеграцию уровня 1, совместимую с PCI, такую ​​как Stripe.

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

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

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

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

Что произойдет, если я обработаю данные держателя карты?

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

Как только данные держателя карты коснутся вашей системы, вы попадете под SAQ-D или опросник для самооценки D. SAQ-D является самым строгим из всех SAQ: с более чем 40 страницами требований, которые вы должны выполнить, чтобы оставаться PCI соответствует.

Определение того, кто подпадает под SAQ-D в соответствии с PCI-DSS, включает всех, кто подпадает под эту классификацию:

  • Продавцы электронной коммерции, которые принимают данные держателя карты на своем веб-сайте
  • Продавцы с электронным хранением данных держателей карт

Это означает, что если вы создаете сайт электронной коммерции или ваше веб-/мобильное приложение должно просто принимать платежи, и вам не нужно принимать платежи в прошлом, тогда используйте что-то вроде Stripe или Braintree.

Рекомендация Serverless Guru — вообще избегать обработки данных карты. Однако, если вам нужно обрабатывать данные карты, давайте теперь рассмотрим несколько областей бессерверного приложения, которые должны быть совместимы с PCI.

Соответствие PCI-DSS с бессерверным доступом

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

Основные области

  • Доступ к данным
  • Шифрование данных
  • Ведение журнала и аудит
  • Высокая доступность и аварийное восстановление

Доступ к данным

Мы рекомендуем всем нашим клиентам использовать Serverless Framework или Serverless Components (beta) для построения инфраструктуры приложений. Мы специально используем роль IAM Serverless Framework для каждого подключаемого модуля функции, чтобы гарантировать, что каждая функция Lambda работает с наименьшими привилегиями.

Мы также изолируем учетные записи AWS на основе этапов/сред, чтобы обеспечить четкие границы производственных данных. В зависимости от размера клиента мы даже ограничиваем учетные записи AWS отдельными разработчиками. Однако обычно мы можем добиться аналогичной изоляции, если каждый разработчик в учетной записи devAWS выполняет развертывание на своей собственной стадии.

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

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

При работе с AWS большинство сервисов либо шифруются по умолчанию, либо дают вам возможность включить шифрование. При работе с AWS S3 у нас есть возможность включить шифрование вручную, а с таким сервисом, как Amazon DynamoDB, шифрование включено по умолчанию.

Еще одна область, которую мы рассматриваем в Serverless Guru, — это ограничение доступа к данным внутри консоли AWS, даже если у вас может быть шифрование AWS S3 или шифрование DynamoDB. При просмотре этих данных в консоли AWS данные по-прежнему будут видны. Одной из стратегий защиты от этого является использование правил отказа IAM.

Ведение журнала и аудит

У каждого облачного провайдера должны быть услуги, связанные с ведением журналов и аудитом. У AWS есть сервис под названием AWS CloudTrail, который будет отслеживать все действия внутри вашей учетной записи AWS, что будет иметь неоценимое значение для аудита и пост-мортемов.

Если вы используете AWS S3 для хранения активов или даже статического веб-хостинга, вам также необходимо убедиться, что у вас есть следующие журналы:

Для бессерверных приложений, использующих AWS Lambda, журналы приложений будут автоматически передаваться в Amazon CloudWatch.

В CloudWatch мы подпишемся на поток Amazon Kinesis Data Firehose, который будет обрабатывать отправку журналов в AWS S3 в режиме реального времени. Мы можем стать более изощренными и использовать другой процесс функции AWS Lambda и анализировать эти журналы по мере необходимости.

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

Высокая доступность и аварийное восстановление

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

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

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

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

После того, как у вас есть очереди, вам нужно провести нагрузочное тестирование и посмотреть, как ваша система реагирует на большое количество запросов.

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

Однако DLQ — отличный способ обеспечить некоторый уровень аварийного восстановления. Другие части вашей системы также должны быть спроектированы с учетом аварийного восстановления.

Например, если вы используете MySQL или PostgreSQL на AWS, вы можете выбрать что-то вроде Amazon Aurora, которая имеет распределенную, отказоустойчивую, самовосстанавливающуюся систему хранения.

Дополнительное чтение

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

Есть ли какие-либо полезные ссылки по бессерверной безопасности, которые вы хотели бы добавить в эту статью? — напишите нам

Вывод

Защита бессерверных приложений для PCI-DSS во многих отношениях намного проще, чем для виртуальных машин или контейнеров. Это связано с меньшими накладными расходами и более полностью управляемыми альтернативами. Снижение общей нагрузки на отдельную компанию по внедрению в качестве поставщика облачных услуг, такого как AWS, решит проблему такого типа для тысяч компаний.

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

Нужна дополнительная помощь?

Serverless Guru предлагает БЕСПЛАТНЫЙ 30-минутный обзор архитектуры, в ходе которого эксперты по бессерверным технологиям из команды Serverless Guru зададут вам вопросы о вашей архитектуре и процессах разработки/развертывания. Мы видели, что это неоценимо для тех, кто подписался.

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

Что мы пропустили?

Когда вы оставите свой ответ, обязательно либо прокомментируйте его ниже, либо напишите свой ответ @serverlessgurux в Твиттере, потому что тогда мы сможем быстро ответить вам!

Райан Джонс

Основатель, CEO/CTO — Serverless Guru

LinkedIn — @ryanjonesirl

Твиттер — @ryanjonesirl

Спасибо за прочтение 😃

Если вы хотите узнать больше о Serverless Guru, подпишитесь на нас в Medium, Twitter, Instagram, Facebook или LinkedIn!