IIS日志管理

Question

是否有可能阻止IIS记录指定类型的数据(即信用卡数据)？我的意思是，我可以对IIS说；-If一个信用卡号码被搜索，不记录这个，或者不记录所有的信用卡号码(掩码)。

或者可以加密iis日志吗？

提前感谢

Answer 1

如果IIS正在记录信用卡数据，那么您显然是通过GET方法而不是method="POST“方法发布的。PCI审计师将检查您的日志(尽管它们通常更关注数据库事务日志而不是W3日志)-- PCI标准确实声明日志不能表示漏洞。如果你改变你的日志(甚至以编程的方式)，你会被抓到，并被发现在不符合规定，这可能带来一个巨大的罚款，大麻烦的审计。所以上面的DJ Pon3是对的，你最好从一张完全干净的纸开始重新设计。

Splunk是一个很好的工具，可以解析所有可能存在漏洞的日志，W3、AV、System、Error和DB日志都应该被监视。

今天遵循最佳实践的程序员尝试编程，这样您的系统就不会看到信用卡号码，即使是内存中的一毫秒，更不用说将其记录到您自己的数据库中了。多么?实际上，在保持完美的审计线索的同时，这是相当容易的。您可以制作出信用卡号码的最后一个屏幕，这样它就可以直接提交到网关，如Authorize.net、Linkpoint或FirstData。您已经将网关设置为对每个事务执行“回调”--甚至可以在隐藏字段中使用一些网关指定在事务提交中执行回调的位置。回调是一个表单提交(张贴)回您的网站与信用卡交易的结果，它通常是相当完整的。您有一个web应用程序来处理回调并将其插入数据库。你的购物者正在看的屏幕，看他们的交易是否被批准，看起来像是在和信用卡公司交谈，但实际上是js在轮询本地事务“回调”数据库，以了解网关回调的结果。在像authorize.net这样的好网关上，所有这一切只需要2-4秒。回调将包含为商家保留审计跟踪所需的所有信息，例如授权号和事务号。但是，回调将没有信用卡号码或CVV (当然)--有时您会得到一个经过修改的CC号码，比如*5454，而不牺牲安全性。现在，您和商家可以诚实地说：“我们从来没有看到一个信用卡号码或CVV -甚至是一毫秒”，这也是对您的服务器。

在网上做信用卡交易的20年里，我从来没有和一个商人谈过，他向我提出了一个商业要求或模型，而这些需求或模型无法用我上面建议的模型来处理。如果一个商人让你相信，他有合法的信用卡号码，他需要存储信用卡号码并忍受必要的遵从性，那么你和他都需要学习信用卡系统是如何真正运作的。

因此，您将从大约85%的PCI遵从性中解脱出来，因为您从未看到、不需要查看，甚至处理单个信用卡号码或CVV。你仍然有责任加密大部分持卡人的信息(这只是一个很好的做法)，并且要小心让他们使用网关的商人API密钥。但是，除了看到信用卡/CVV甚至一毫秒之外，这些担忧都是微不足道的--所以请避免这样做！

Stripe.com基本上有正确的想法，而且他们在github上有一些很好的代码，您可以为您的项目进行调整(链接在他们的站点上)。但是Stripe.com要求商家将他的“商人账户”转移到他们的服务中，基本上重新启动他们的信用卡处理，这对IT开发人员来说是很难的。大多数商人真的不愿意转移他们的商人帐户。但是，通过研究他们在github上发布/评论的代码，您可以获得一些很好的想法，并且在信用卡处理的良好开发实践方面变得更加明智。

但是..。

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

不要允许信用卡事务向您自己的服务器提交，直接将它们提交到网关，监视您在网关上设置的web钩子的回调，并优雅地、完全合法地避开许多PCI遵从问题。网关开始支持这一想法，有些甚至会在回调中包括您在已发布的信用卡表单中提交的每个隐藏字段，这样您就可以少做大量的编程来保存状态，等等。

不要伪造或更改日志--你的信用卡号码查询串会使一个非常微不足道的妥协，系统会被破坏，你的客户将支付数以万计的费用，让法医审计人员在企业中运行，像对待罪犯一样对待雇员，你会让你的律师对他寄给你的所有账单非常、非常、非常满意。

Answer 2

我建议你不要试图从你的日志中清除信用卡号码，而是首先做你应该做的事情，而不是用明文存储或处理这些信息。实际上，这样做违反了许多关于信用卡处理器和信用卡事务的规则，从IIS日志中编辑信息将不足以满足要求。

是的，你受那些PCI法规的约束：

问: PCI适用于谁？ A: PCI适用于所有接受、传输或存储任何持卡人数据的组织或商家，无论交易规模或数量如何。另一种说法是，如果该组织的任何客户直接使用信用卡或借记卡向商家付款，则适用PCI的要求。

标准。

PCI的要求3控制敏感数据的存储，包括信用卡号码和卡验证代码。

规则1不存储信息，除非您必须这样做(还有一些数据，比如CVV，即使是加密的，也永远不会被存储)。第二条规则是，如果存储信息，则始终对其进行加密。

如果它以明文形式到达IIS日志，则您已经违反了需求3，并且仅仅阻止IIS登录是不够的，不足以恢复到遵从状态。而且，如果你不知道，对不遵守规定的组织可以处以高达50万美元的罚款。

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

换句话说，照顾xkcd.