IIS日志pipe理

如果信用卡数据正在被IISlogging，那么你显然是通过GET方法而不是method =“POST”方法发布的。 PCI审计员将检查您的日志（虽然他们通常更关心数据库事务日志而不是W3日志） – PCI标准确实指出日志不能代表漏洞。 如果你改变你的日志（甚至以编程的方式），你会被捕获，发现不合规，并可能带来巨大的罚款和大的讨厌的审计。 所以上面的DJ Pon3是对的，你最好从一张完全干净的纸上重新devise。

Splunk是parsing所有日志以查找潜在漏洞的好工具，W3，AV，系统，错误和数据库日志都应该被监视。

今天遵循最佳实践的程序员尝试编程，以便系统永远不会看到信用卡号码，即使只有毫秒级的内存，也不会logging到自己的数据库。 怎么样？ 这实际上很容易，同时仍然保持完美的审计线索。 您制作了信用卡号码的最终屏幕，以便直接向网关（如Authorize.net或Linkpoint或FirstData）提交。 您的网关设置为每个交易执行一个“callback”，您甚至可以指定一些网关在隐藏字段中的交易提交中的回拨权限。 callback是一个表单提交（邮政）回到您的网站与信用卡交易的结果，它通常会相当完整。 您有一个Web应用程序来处理callback并将其插入到数据库中。 您的购物者正在观看的屏幕，看看他们的交易是否被批准看起来像是在与信用卡公司交谈，但是真正的js轮询您的本地交易“回拨”数据库，以获得网关回拨的结果。 所有这一切只需要2-4秒，像一个好的网关，如authorize.net。 callback将拥有所有需要的信息来保存商家的审计线索，例如授权号码和交易号码。 但是，callback不会有信用卡号码或CVV（当然） – 有时你会得到一个像************ 5454编辑CC号码为方便而不牺牲安全性。 现在你和商家可以诚实地说：“我们从来没有看到信用卡号码或CVV，甚至毫秒”，这也是你的服务器。

在网上进行信用卡交易的20年中，我从来没有和一个商人谈过一个商业要求或模型，而这个商业要求或模型不能用我上面build议的模型来处理。 如果一个商人说服你，他有一个合法的需要存储信用卡号码，并承受必要的合规性，那么你和他都需要了解信用卡系统是如何真正起作用的。

因此，您不必再看到，甚至不需要处理单个信用卡号码或CVV，就可以减轻约85％的PCI合规性。 您仍然有责任encryption大部分持卡人信息（这只是一个好习惯），并注意允许他们使用网关的商户API密钥。 但是，这些担心是微不足道的，看到一个信用卡/ CVV甚至毫秒的负担 – 所以要避免！

Stripe.com大多是正确的想法，他们有一些好的代码在github上提出，你可以适应你的项目（链接到他们的网站）。 但是Stripe.com要求商家将他的“商户账户”转移到他们的服务上，并且基本上重新登记他们的信用卡处理，这对于IT开发人员来说是一个艰难的select。 大多数商人真的不愿移动他们的商人帐户。 但是，通过研究他们在github上发布/评论的代码，您可以获得一些很棒的想法，并成为信用卡处理良好开发实践的一个明智之举。

但…

不要使用GET来提交信用卡交易 – 这是一个愚蠢的，可避免的错误，您的商家将被称为“妥协后”的商人，他们付出了巨额罚款，不得不花费数万美元进行法医PCI审计，整治”。

不要让信用卡交易完全提交给你自己的服务器，直接提交给网关，注意你使用网关设置的webhook的callback，并且优雅地完全合法地避开许多PCI合规性问题。 网关开始赞成这个想法，有些甚至会在callback中包含你在POSTED信用卡表格中提交的每一个隐藏字段，所以你很less有很多的编程来保存状态等等。

不要伪造或改变日志 – 您的信用卡号码查询string将作出一个非常微不足道的妥协，系统将被破坏，您的客户将支付数以万计的法医审计员运行的特权企业对待员工就像犯罪分子一样，你会让你的律师非常非常高兴他所有的账单，他会派你去捍卫你。

我build议不要试图从日志中清除信用卡号码，而是首先做你应该做的事情，而不是以纯文本的forms存储或处理这些信息。 实际上，您实际上违反了许多有关信用卡处理器和信用卡交易的规则，并且从您的IIS日志中对信息进行修改将不足以符合规定。

是的，你受到PCI规定的约束 ：

问：PCI适用于谁？
答：PCI适用于所有组织或商户，无论交易规模大小，接受，传输或存储任何持卡人数据。 换句话说，如果该组织的任何客户曾经使用信用卡或借记卡直接向商户支付费用，则适用PCI DSS要求。

标准。

PCI-DSS要求3pipe理敏感数据的存储，包括信用卡号和卡validation码。

规则1不是存储信息，除非必须（并且存在一些数据，如CVV，即使encryption也不会被存储）。 规则＃2总是encryption信息，如果你存储它。

如果它以纯文本forms达到IIS日志，则已经违反了要求3，并且仅仅停止IIS的日志logging是不够的，无法恢复到合规性。 而且，如果你不知道，高达50万美元的罚款可以评估不符合的组织。

所以，基本上， 你需要解决你处理信用卡数据的整个过程和stream程 ，而不仅仅是堵住这个漏洞。 如果你做得对，你甚至不用担心IISlogging的内容，因为在日志中捕获的任何信用卡号码将被打乱或encryption。

换句话说，照顾xkcd …