PCI означает «Индустрия платежных карт», но для многих это скрытый набор стандартов, навязываемых секретным международным картелем, стремящимся похоронить неосторожную душу с помощью непосильных правил и правовых трудностей.
Правда в этом вопросе гораздо скучнее и пешеходнее. На самом деле PCI — это набор руководств по безопасности, разработанный консорциумом компаний, выпускающих кредитные карты, и отраслевых экспертов по безопасности, чтобы определить, как должны вести себя приложения при обработке информации о кредитных или дебетовых картах. Карточные компании навязывают эти стандарты банкам, которые затем навязывают их тем из нас, кто работает на сайтах электронной коммерции и тому подобном.
В этой статье мы расскажем о нескольких постоянных мифах о PCI, рассмотрим 20 000 футов того, что включает в себя PCI, а затем сосредоточимся на тех требованиях, которые наиболее тесно связаны с кодированием в целом и PHP в частности.
Мифы о PCI
Неудивительно, что существует ряд мифов о стандартах PCI. Одним из таких мифов является то, что они как правила поведения для мафии, нигде не записаны, поэтому их можно интерпретировать так, как вы хотите. Это, конечно, неправда. Для полного ознакомления со стандартами PCI все, что вам нужно сделать, это перейти на pcisecuritystandards.org .
Другой миф заключается в том, что стандарты безопасности PCI применимы только к «большим парням», таким как банки и крупные розничные продавцы. Они применяются к каждому человеку, который принимает данные карты для оплаты вещей. Если вы написали сайт на PHP для своей матери, чтобы продавать ее знаменитые лимонные пироги, у вас есть система, которая подпадает под рекомендации PCI.
Третий миф заключается в том, что если вы будете следовать стандартам PCI, то вы будете защищены от злонамеренного взлома, и ваши данные останутся в безопасности. Конечно, это было бы неплохо, но дело в том, что стандарты PCI — это руководящие принципы и идеи, а не конкретные методы (они должны быть расплывчатыми, чтобы соответствовать всем архитектурам и платформам). Очевидно, что чем больше внимания вы уделяете безопасности, тем меньше у вас шансов попасть под удар, но любой может быть скомпрометирован. Вас будут рассматривать как с юридической, так и с юридической точки зрения, лучше, если вы хотя бы попытаетесь оправдать ожидания PCI.
Наконец, PCI — это не то, что вы делаете один раз, а затем вздыхаете с облегчением. Стандарты требуют, чтобы вы проводили обзор PCI один раз в год, так что это то, что продолжается, например, меры по обеспечению качества или выслушивание вашего супруга.
Простая истина в том, что PCI — это то, о чем должен знать каждый программист, работающий над приложением, которое касается данных кредитной карты, независимо от того, насколько они малы. Да, поэтому дилеры берут только наличные.
Основы PCI
Стандарт PCI состоит из 12 основных требований. Стандарт обновляется примерно каждые два года, и в промежутке между выпускаются различные руководящие документы, которые являются более конкретными и касаются определенного подмножества мира PCI. Например, в феврале 2013 года сотрудники PCI выпустили официальный документ, в котором обсуждались вопросы PCI и облака. Эти специальные отчеты также доступны на веб-сайте PCI.
Как мы увидим, многие требования PCI в большей степени ориентированы на сеть, но какой смысл говорить об этом, если вы не отказываетесь хотя бы от базового представления о полном PCI? Требования следующие:
- Область 1 — Построить и поддерживать безопасную сеть
- Требование 1. Установите брандмауэр для защиты вашей среды.
- Требование 2. Не используйте стандартные профили или пароли поставщика.
- Область 2 — Защита данных держателя карты
- Требование 3 — защита сохраненных данных держателя карты.
- Требование 4 — Шифровать владельца карты. Данные, которые передаются через открытые общедоступные сети.
- Область 3 — Поддерживать программу управления уязвимостями
- Требование 5 — использовать и регулярно обновлять антивирусное программное обеспечение.
- Требование 6 — Разработка и поддержка безопасных систем и приложений.
- Область 4 — Внедрение строгих механизмов контроля доступа
- Требование 7 — Ограничить доступ к данным Держателя карты по мере необходимости.
- Требование 8. Назначьте уникальный идентификатор каждому человеку, имеющему доступ к компьютеру.
- Требование 9 — Ограничить физический доступ к данным держателя карты.
- Область 5 — Регулярный мониторинг и тестирование сетей.
- Требование 10 — Отслеживать и отслеживать / регистрировать весь доступ к сетевым ресурсам и данным о держателях карт.
- Требование 11 — Регулярно проверять системы безопасности и процессы.
- Область 6 — Ведение политики информационной безопасности.
- Требование 12. Поддерживать политику, касающуюся информационной безопасности.
Некоторые из этих элементов связаны с политическими решениями, а именно с решением о создании политик, в которых точно указано, как вы предпринимаете усилия для защиты информации о карте и обеспечения общей безопасности вашей сети и приложений. Другие требования касаются самой сети и программного обеспечения, которое вы можете использовать для ее защиты. Некоторые из них касаются фазы разработки процесса, того, как вы структурируете и настраиваете свое приложение. Вряд ли какое-либо из требований касается кода, и ни одно из них не описывает конкретные методы программирования, которые рекомендуются для обеспечения вашей безопасности. Чтобы быть относительно коротким, я ограничу свой сарказм и мудрость (это смесь 70:30) и сосредоточусь на последних двух группах.
Требование 2 — не использовать настройки по умолчанию для профилей / паролей
Во многих отношениях это почти легкая задача. Сотрудники службы безопасности говорят нам об этом с самого начала беспокойства о вещах. Но удивительно, как просто взять учетную запись и пароль по умолчанию (особенно когда вы сначала устанавливаете вещи, и все очень «тестируется») на многих программных продуктах, которые мы используем, MySQL, чтобы назвать только одну.
Опасность здесь возрастает, потому что большинство из нас строит свои приложения на базе базовых программ, а не делает все с нуля. Это может быть просто пакет, который мы используем для обработки шифрования и хранения ключей (см. Ниже), или это может быть основой для всего приложения. В любом случае, легко запомнить, легко реализовать: не используйте учетные записи по умолчанию.
Требование 3 — защита сохраненных данных держателя карты
Я помню, что большинство известных хакерских сайтов занимались кражей карт или других данных, которые хранились на сайте, поэтому я бы оценил это как довольно важную часть стандарта PCI.
Очевидно, что любые данные вашей карты должны быть зашифрованы. И вам нужно хорошо зашифровать его. Для тех, кто много знает о шифровании, вы знаете, что хорошая работа по шифрованию данных означает, что вы хорошо справились с управлением ключами шифрования.
Управление ключами связано с проблемой генерации, хранения и обновления ключей, используемых в процессе шифрования. Хранение их может быть большой проблемой, потому что вы хотите убедиться, что кто-то не может войти в систему и украсть ключи. Стратегии управления отличаются тем, как разделить и разделить ключ на несколько частей; Если вам нужно введение в управление ключами, я бы начал с этого документа Securosis, а затем пошел оттуда, хотя предупреждаю, что вода довольно быстро становится довольно глубокой.
Конечно, если вы используете коммерческий продукт для обработки шифрования, вы можете оставить управление ключами им, хотя вы хотите убедиться, что их процесс надежен и соответствует вашему подходу. Большинство коммерческих продуктов разрабатываются с учетом PCI и поэтому будут построены в соответствии со стандартами PCI, но это все равно не повредит дважды проверить.
Кроме того, задача защиты данных станет намного проще, если вы минимизируете или даже устраняете объем хранимых данных. То есть, данные держателя карты могут быть любыми: от имени, дня рождения, номера карты, даты истечения срока действия, кода подтверждения карты (CV) (трех или четырех цифр на обратной или лицевой стороне карты) и т. Д. чем меньше у вас шифрования и тем меньше ваша ответственность. К счастью, это одна из областей, где стандарт PCI довольно специфичен, поскольку именно он указывает, какие данные вы можете и не можете хранить. Вы можете сохранить номер карты (PAN — основной номер счета), имя владельца карты, дату истечения срока действия и код обслуживания. Если вы сохраняете PAN, вы должны замаскировать его, если собираетесь отображать, причем первые шесть и последние четыре цифры — это максимум, который вы можете показать. Вы не можете хранить ПИН-код, CV-код или всю магнитную полосу.
Вопрос, который вы должны задать себе на этапе проектирования, заключается в том, какую часть этих вонючих данных вы действительно хотите сохранить. Единственная реальная причина сохранить это в том, что вы хотите, чтобы в следующий раз вам было легко и просто позаботиться о своих клиентах. И вы можете держаться за день рождения, чтобы вы могли отправить им дружелюбное приветствие о дне рождения. Все эти данные должны быть зашифрованы и защищены, поэтому убедитесь, что вы извлекаете из этого пользу.
Требование 4 (для шифрования любых передаваемых данных) является своего рода частью этого, но я собираюсь рассмотреть эту часть инфраструктуры, а не останавливаться на ней.
Требование 6. Разработка и поддержка безопасных систем и приложений.
Это требование, которое связано с кодом. Не для определенных функций или классов, но, по крайней мере, убедитесь, что вы следуете общим стандартам безопасности и пытаетесь сделать свои вещи несколько пуленепробиваемыми. Таким образом, вы просто используете методы кодирования, независимо от языка, которые не открывают ваше приложение для очевидных взломов. Например, вы пытаетесь предотвратить SQL-инъекции, принимая меры предосторожности, когда принимаете данные формы, вы пытаетесь заблокировать XSS и т. Д. Для получения дополнительной информации об избежании некоторых из наиболее распространенных проблем безопасности обратитесь к другим опубликованным статьям. в SitePoint ( эта и эта, а также другие статьи доступны, если вы выполняете поиск по «безопасности»).
Требование 7 и 8 — ограничить доступ и уникальный идентификатор
Обе эти вещи связаны с тем, как вы получаете доступ к приложению, и поэтому лежат где-то между программированием и дизайном.
Требование уникального идентификатора для каждого посетителя не должно быть проблемой, если только вы не позволите людям входить в систему и делать покупки через профиль гостя. Я могу вспомнить пару сайтов из рук, которые позволяют вам сделать это, и само по себе это не зло, но использование групповых профилей опасно, и вы должны приложить дополнительные усилия, чтобы убедиться, что они не имеют большого авторитета , В общем, вы должны стремиться установить уникальные идентификаторы, даже если этот идентификатор не тот, который вы сохраняете. Например, вы можете позволить людям войти в систему как гость, но затем сразу же создать уникальный профиль за кулисами для события.
Мы также хотим ограничить физический доступ к данным держателя карты. Это может быть данью будущему, когда мы сможем сократить людей до субмикроскопического размера, как в «Фантастическом путешествии» Исаака Ассимова, и ввести их в устройство хранения, чтобы получить данные 1 и 0 данных карты… или это может также относиться к таким вещам, как закрытые серверные комнаты, значки для всех посетителей, недопущение того, чтобы кто-то подходил близко к лентам с резервными копиями, и тому подобное.
Требование 10 — Отслеживать и регистрировать весь доступ к ресурсам / данным.
Наконец, не стоит недооценивать важность отслеживания и регистрации всего, что обращается либо к ресурсу, либо к данным держателя карты … и я имею в виду все. События, которые должны быть зарегистрированы, включают вход в систему, выход из системы, доступ к данным; обновления данных, на самом деле все, что связано с ресурсом или элементом данных, и вы думаете, может быть полезным в качестве контрольного журнала или в качестве доказательства в уголовном процессе. Вы должны внедрить защищенный журнал, ежедневно просматривать журнал на наличие проблем и хранить журнал в течение одного года.
Для пользователей PHP было бы полезно ознакомиться со стандартом ведения журналов PSR-3, который пришел из группы PHP-FIG и предоставляет единый, но гибкий способ настройки ведения журналов. Вместо того, чтобы вдаваться в подробности, я бы порекомендовал вступительную статью Патрика Малви.
Резюме
Я думаю, что я хочу подчеркнуть, что PCI не обледенение. Это часть муки создания приложений, которые работают с данными кредитных карт. Если вы пишете приложение, которое принимает такие данные, оно относится к вам независимо от того, знают это ваши клиенты или нет. Большинство из них выше уровня кодирования, но это реально и на что вы все равно должны обратить внимание.
Изображение через Fotolia