Управление журналом IIS

Если данные кредитной карты регистрируются IIS, то вы, очевидно, отправляете сообщения методом GET вместо метода method="POST". Аудиторы PCI будут проверять ваши журналы (хотя обычно они больше касаются журналов транзакций базы данных, а не журналов W3) - стандарт PCI утверждает, что журналы не могут представлять уязвимости. Если вы измените свои журналы (даже программно), вы будете обнаружены в результате несоответствия, что может повлечь за собой огромный штраф и большие неприятные проверки. Так что DJ Pon3 выше - это правильно, лучше начать заново с совершенно чистого листа бумаги.

Splunk - это хороший инструмент для анализа всех ваших журналов на предмет потенциальных уязвимостей, следует следить за журналами W3, AV, System, Error и DB.

Программисты, которые следуют ЛУЧШИМ практикам сегодня, пытаются программировать так, чтобы ваша система НИКОГДА не видела номер кредитной карты, даже в течение миллисекунды в памяти, тем более записывая ее в свою собственную базу данных. Как? Это на самом деле довольно легко, но при этом сохраняется идеальный контрольный журнал. Вы создаете последний экран, где указан номер кредитной карты, чтобы он НЕПОСРЕДСТВЕННО передавался на шлюз, например Authorize.net, Linkpoint или FirstData. У вас есть шлюз, настроенный для выполнения "обратного вызова" для каждой транзакции - вы даже можете указать с некоторыми шлюзами, где выполнять обратный вызов прямо в отправке транзакции в скрытом поле. Обратный вызов - это отправка формы (POST) обратно на ваш веб-сайт с результатами транзакции по кредитной карте, и она обычно будет довольно полной. У вас есть веб-приложение для обработки обратного вызова и вставки его в базу данных. Экран, на который смотрит ваш покупатель, чтобы убедиться, что его транзакция была одобрена, выглядит так, как будто он разговаривает с компанией-эмитентом кредитной карты, но на самом деле он опрашивает вашу базу данных "обратного вызова" локальной транзакции на предмет результата обратного вызова от шлюза. Все это занимает всего 2-4 секунды на хорошем шлюзе, как authorize.net. Обратный вызов будет содержать ВСЕ данные, необходимые для сохранения контрольного журнала для продавца, такие как номер авторизации и номер транзакции. Но обратный вызов НЕ будет иметь номер кредитной карты или CVV (конечно) - иногда вы получите обратно отредактированный номер CC, такой как ************5454, для удобства без ущерба для безопасности. Теперь вы и продавец можете честно сказать: "Мы никогда не увидим номер кредитной карты или CVV - даже за миллисекунду", и это верно и для ваших серверов.

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

Таким образом, вы получаете около 85% соответствия PCI, потому что вы никогда не видите, не должны видеть или даже обрабатывать один номер кредитной карты или CVV. На вас все еще лежит обязанность зашифровать большую часть информации о владельце карты (это просто хорошая практика) и позаботиться о ключах API продавца, которые позволяют им использовать шлюз. Но эти проблемы тривиальны наряду с бременем, налагаемым просмотром кредитной карты /CVV даже в течение миллисекунды - так что избегайте этого!

Stripe.com имеет в основном правильную идею, и у них есть некоторый хороший код, сохраненный на github, который вы можете адаптировать для своего проекта (ссылка на его сайте). Но Stripe.com требует, чтобы продавец перенес свою "учетную запись продавца" в свою службу и, в основном, перенастроил свою обработку кредитных карт, а это трудно для ИТ-разработчика. Большинство деловых людей действительно неохотно переносят свой торговый счет. Но вы можете воспользоваться некоторыми замечательными идеями, изучив код, который они публикуют / комментируют на github, и станут намного мудрее для хороших методов разработки для обработки кредитных карт.

но...

НЕ используйте GET для отправки транзакции по кредитной карте - это глупая ошибка, которую можно избежать, и ваш продавец станет известен как посткомпромиссный продавец, который заплатил большой штраф и должен был потратить десятки тысяч на судебные проверки PCI и " рекультивация.

НЕ ДОПУСКАЙТЕ, чтобы транзакции по кредитным картам вообще отправлялись на ваш собственный сервер, отправляли их непосредственно на шлюз, следите за обратным вызовом через веб-крюк, который вы настроили с помощью шлюза, и элегантно и совершенно юридически обходите многие проблемы соответствия PCI. Шлюзы начинают одобрять эту идею, и некоторые из них даже будут включать в обратный вызов каждое скрытое поле, которое вы указали в форме кредитной карты POSTED, так что у вас гораздо меньше программ для сохранения состояния и т. Д.

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

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

И да, вы связаны этими правилами PCI:

В: Для кого применяется PCI?
A: PCI применяется ко ВСЕМ организациям или торговцам, независимо от размера или количества транзакций, которые принимают, передают или хранят любые данные о держателях карт. Иными словами, если какой-либо клиент этой организации когда-либо платит продавцу напрямую с помощью кредитной или дебетовой карты, то применяются требования PCI DSS.

Стандарты.

Требование 3 стандарта PCI-DSS регулирует хранение конфиденциальных данных, включая номера кредитных карт и коды проверки карт.

Правило № 1 не должно хранить информацию, если вам не нужно (и есть некоторые данные, такие как CVV, которые никогда не должны храниться, даже если они зашифрованы). Правило № 2 - всегда шифровать информацию, если вы ее храните.

Если он достигает журналов IIS в виде открытого текста, то вы уже нарушаете требование 3, и простого прекращения регистрации IIS недостаточно, чтобы вернуться к соответствию. И, если вы не знаете, штрафы в размере до 500000 долларов могут быть начислены на организации, которые не соответствуют.

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

Другими словами, уход за xkcd...