IIS日志管理

Question 1

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

Splunk 是一个很好的解析工具全部您的日志中是否存在潜在漏洞，W3、AV、系统、错误和 DB 日志都应该受到监视。

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

在我从事网上信用卡交易的 20 年里，我从未遇到过一位商人向我提出无法使用我上面建议的模型来处理的业务需求或模型。如果一位商人说服你，他有合法的需要存储信用卡号并遵守必要的规定，那么你和他都需要了解信用卡系统的实际运作方式。

因此，您无需再承担 85% 的 PCI 合规性责任，因为您永远看不到、不需要看到甚至处理任何信用卡号或 CVV。您仍然需要加密大部分持卡人信息（这只是一种良好做法），并小心处理允许他们使用网关的商家 API 密钥。但与查看信用卡/CVV 哪怕一毫秒所带来的负担相比，这些担忧微不足道 - 所以请避免这种情况！

Stripe.com 的想法基本正确，他们在 github 上存档了一些很好的代码，您可以将其用于您的项目（链接在他们的网站上）。但是 Stripe.com 要求商家将其“商家帐户”转移到他们的服务上，并基本上重新登陆他们的信用卡处理，这对 IT 开发人员来说很难接受。大多数商人真的不愿意转移他们的商家帐户。但是，您可以通过研究他们在 github 上发布/评论的代码来获得一些好的想法，并更加明智地制定信用卡处理的良好开发实践。

但...

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

完全不允许信用卡交易提交到您自己的服务器，直接将它们提交到网关，监视您与网关一起设置的 webhook 的回调，并优雅且完全合法地避开许多 PCI 合规性问题。网关开始支持这个想法，有些网关甚至会在回调中包含您在 POSTED 信用卡表单中提交的每个隐藏字段，这样您就不需要在自己这边进行太多编程来保存状态等。

不要伪造或更改日志 - 查询字符串中的信用卡号将要做出妥协非常微不足道，系统将要受到损害，你的客户将要支付数万美元，让法务审计师在公司里四处奔走，像对待罪犯一样对待员工，而你的律师会因为他为你辩护而寄给你的所有账单而让你非常非常高兴。

Answer

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

Splunk 是一个很好的解析工具全部您的日志中是否存在潜在漏洞，W3、AV、系统、错误和 DB 日志都应该受到监视。

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

在我从事网上信用卡交易的 20 年里，我从未遇到过一位商人向我提出无法使用我上面建议的模型来处理的业务需求或模型。如果一位商人说服你，他有合法的需要存储信用卡号并遵守必要的规定，那么你和他都需要了解信用卡系统的实际运作方式。

因此，您无需再承担 85% 的 PCI 合规性责任，因为您永远看不到、不需要看到甚至处理任何信用卡号或 CVV。您仍然需要加密大部分持卡人信息（这只是一种良好做法），并小心处理允许他们使用网关的商家 API 密钥。但与查看信用卡/CVV 哪怕一毫秒所带来的负担相比，这些担忧微不足道 - 所以请避免这种情况！

Stripe.com 的想法基本正确，他们在 github 上存档了一些很好的代码，您可以将其用于您的项目（链接在他们的网站上）。但是 Stripe.com 要求商家将其“商家帐户”转移到他们的服务上，并基本上重新登陆他们的信用卡处理，这对 IT 开发人员来说很难接受。大多数商人真的不愿意转移他们的商家帐户。但是，您可以通过研究他们在 github 上发布/评论的代码来获得一些好的想法，并更加明智地制定信用卡处理的良好开发实践。

但...

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

完全不允许信用卡交易提交到您自己的服务器，直接将它们提交到网关，监视您与网关一起设置的 webhook 的回调，并优雅且完全合法地避开许多 PCI 合规性问题。网关开始支持这个想法，有些网关甚至会在回调中包含您在 POSTED 信用卡表单中提交的每个隐藏字段，这样您就不需要在自己这边进行太多编程来保存状态等。

不要伪造或更改日志 - 查询字符串中的信用卡号将要做出妥协非常微不足道，系统将要受到损害，你的客户将要支付数万美元，让法务审计师在公司里四处奔走，像对待罪犯一样对待员工，而你的律师会因为他为你辩护而寄给你的所有账单而让你非常非常高兴。

Question 2

我建议你不要试图从日志中清除信用卡号，而是首先做你应该做的事情，那就是根本不要以纯文本形式存储或处理这些信息。实际上，这样做违反了许多管理信用卡处理器和信用卡交易的规则，而从 IIS 日志中删除信息不足以满足要求。

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

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

标准。

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

规则 1 是，除非万不得已，否则不要存储信息（有些数据，如 CVV，绝不存储信息，即使已加密）。规则 2 是，如果您确实要存储信息，则务必对其进行加密。

如果以明文形式进入 IIS 日志，则您已经违反了要求 3，仅阻止 IIS 记录它不足以恢复合规性。如果您不知道，不合规的组织可能会被处以高达 500,000 美元的罚款。

所以，基本上，你需要修复处理信用卡数据的整个流程，而不只是堵住这一个漏洞。如果你做得对，你甚至不需要担心 IIS 日志记录的内容，因为日志中捕获的任何信用卡号都将被打乱或加密。

换句话说，由 xkcd 负责……

在此处输入图片描述

Answer