IIS日志管理

Question

是否可以阻止 IIS 记录指定类型的数据（即信用卡数据）？我的意思是我可以对 IIS 说吗？- 如果搜索到信用卡号，请不要记录此信息，或者不要记录所有信用卡号（屏蔽它）。

或者是否可以加密 iis 日志？

提前致谢

Answer 1

如果 IIS 正在记录信用卡数据，那么您显然是通过 GET 方法而不是 method="POST" 方法进行发布。PCI 审计员将检查您的日志（尽管他们通常更关心数据库事务日志而不是 W3 日志）——PCI 标准确实声明日志不能代表漏洞。如果您更改您的日志（甚至以编程方式），您将被抓到并被发现不合规，这可能会导致巨额罚款和令人讨厌的审计。所以上面的 DJ Pon3 是对的，你最好从一张完全干净的纸开始重新设计。

Splunk 是一个很好的工具，可以解析所有日志中的潜在漏洞，W3、AV、系统、错误和数据库日志都应该被监视。

今天遵循最佳实践的程序员试图进行编程，以便您的系统永远不会看到信用卡号码，即使在内存中也不会看到一毫秒，更不用说将其记录到您自己的数据库中。如何？这实际上很容易，同时仍然保留了完美的审计跟踪。您制作给出信用卡号的最终屏幕，以便它直接提交给像 Authorize.net 或 Linkpoint 或 FirstData 这样的网关。您已将网关设置为对每笔交易进行“回调”——您甚至可以使用某些网关在隐藏字段中的交易提交中指定在哪里进行回调。回调是将信用卡交易结果提交回您的网站的表单（POST），它通常是相当完整的。您有一个 Web 应用程序来处理回调并将其插入到数据库中。您的购物者正在查看他们的交易是否获得批准的屏幕看起来像是在与信用卡公司交谈，但实际上是 js 轮询您的本地交易“回调”数据库以获取来自网关的回调结果。所有这些在像 authorize.net 这样的好网关上只需要 2-4 秒。回调将包含您为商家保留审计跟踪所需的所有信息，例如授权号和交易号。但是回调不会有信用卡号或 CVV（当然） - 有时你会得到一个像 ************5454 这样的编辑过的 CC 号码，为了方便而不牺牲安全性。现在您和商家可以诚实地说“我们从未看到信用卡号或 CVV - 甚至一毫秒都没有”，您的服务器也是如此。

在网上进行卡交易的 20 年中，我从未与一位商人交谈过，他们向我提出了无法使用我上面建议的模型处理的业务需求或模型。如果一个商人让你相信他有合法的需求来存储信用卡号并忍受必要的合规性，那么你和他都需要了解信用卡系统的实际运作方式。

因此，您可以免除大约 85% 的 PCI 合规性，因为您永远不会看到、不需要看到甚至处理单个信用卡号或 CVV。您仍然需要对大部分持卡人信息进行加密（这只是一个很好的做法）并注意让他们使用网关的商家 API 密钥。但是，这些担忧与看到信用卡/CVV 甚至一毫秒所带来的负担相比都是微不足道的——所以要避免这种情况！

Stripe.com 的想法大多是正确的，他们在 github 上归档了一些很好的代码，您可以根据自己的项目进行调整（链接到他们的网站）。但是 Stripe.com 要求商家将他的“商家帐户”转移到他们的服务上，并且基本上重新登录他们的信用卡处理，这对 IT 开发人员来说是一个艰难的卖点。大多数商人真的不愿意移动他们的商家帐户。但是您可以通过研究他们在 github 上发布/评论的代码来获得一些很棒的想法，并成为信用卡处理良好开发实践的明智之举。

但...

不要使用 GET 提交信用卡交易 - 这是一个愚蠢的、可以避免的错误，您的商家将被称为“妥协后”商家，他支付了巨额罚款并且不得不花费数万美元进行法医 PCI 审计和“补救”。

根本不允许信用卡交易提交到您自己的服务器，将它们直接提交到网关，注意来自您使用网关设置的 webhook 的回调，并优雅且完全合法地避开许多 PCI 合规性问题。网关开始支持这个想法，有些甚至会将您在 POSTED 信用卡表单中提交的每个隐藏字段都包含在回调中，这样您就可以减少很多编程工作来保存状态等。

不要伪造或更改日志 - 您的信用卡号在查询字符串中的妥协将变得非常微不足道，系统将被入侵，您的客户将支付数万美元以获得法医审计员四处奔波的特权公司对待员工就像对待罪犯一样，你会让你的律师非常、非常、非常满意他会寄给你来为你辩护的所有账单。

Answer 2

我建议与其尝试从您的日志中清除信用卡号，不如做您应该做的事情，这根本不是以明文形式存储或处理该信息。您这样做实际上违反了许多管理信用卡处理程序和信用卡交易的规则，并且从您的 IIS 日志中编辑信息将不足以符合规定。

是的，您受这些 PCI 法规的约束：

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

标准。

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

规则 #1 是除非您必须存储信息（并且有一些数据，例如永远不会存储的CVV ，即使加密）。规则#2 是如果您确实存储信息，则始终对其进行加密。

如果它以纯文本形式到达 IIS 日志，则您已经违反了要求 3，并且仅阻止 IIS 记录它并不足以恢复合规性。而且，如果您不知道，可以对不遵守规定的组织处以最高 500,000 美元的罚款。

因此，基本上，您需要修复处理信用卡数据的整个过程和流程，而不仅仅是堵住这个漏洞。如果您做得对，您甚至不必担心 IIS 日志记录了什么，因为日志中捕获的任何信用卡号都将被加扰或加密。

换句话说，照顾xkcd...