2021-09-02

你可能认为你有圆木。很可能，您只能在跟踪异常和调试时依赖它们。但你不能依赖他们的遵从，法医，或任何法律问题。作为一名工程师，这可能与你无关，但这是那些重要的非功能性要求之一，如果不满足，

因为我我显然有偏见，也有资格讨论日志(我之前描述过虽然它们只是安全方面的一部分，当然也不是很令人兴奋，但它们是重要的，特别是从法律的角度来看。这就是为什么许多标准和法律--包括ISO 27001，PCI-DSS，HIPAA，SOC 2，PSD 2，GDPR--都需要审计跟踪功能。而且他们中的大多数都有非常特殊的安全要求。

PCI-DSS有一堆与审计跟踪相关的要求：

10.2.3
“恶意用户经常尝试更改审计日志以隐藏其操作，访问记录允许组织将日志的任何不一致或潜在篡改跟踪到单个帐户。[.]“

10.5 确保审计跟踪的安全，使其不能被更改。。进入网络的恶意个人通常会尝试编辑审计日志以隐藏其活动。没有对审计日志的充分保护，审计日志的完整性、准确性和完整性就无法得到保证，而且经过妥协后，审计日志作为调查工具可能变得毫无用处。

10.5.5
在日志上使用文件完整性监视或更改检测软件，以确保如果不生成警报，则无法更改现有日志数据。(虽然添加的新数据不应引起警报)。

ISO 27001附件A还谈到保护审计跟踪不受篡改

A.12.4.2保护日志信息
测井设施和日志信息应为防篡改和未经授权的访问

遗憾的是，根据我的经验，日志很少。然而，审计人员对此基本没有意见，并且给出了认证，即使日志可能会被篡改。我决定收集并列出典型的解决方案--安全、篡改明显/受篡改保护的审计日志。

https://www.douban.com/note/811237689/

• 我们不需要他们的保护-你几乎肯定是这样的.如果你需要顺从-你需要。如果您不需要遵从，但您有一个高价值/高影响的系统，您可以。如果它不一定要符合，它是低价值或低影响，比是。无论如何，你不需要太多的安全性(但要小心不要低估所需的安全性)。
• 我们将它存储在多个地方，有不同的访问权限。-这是基于这样一种假设，即多个管理员不会合谋篡改日志。当然，你不能保证这一点。但即使你确信他们不会，你也无法向外部各方证明这一点。假设有人起诉你，你提供原木作为证据。如果原木不被篡改--很明显，另一方可以很容易地声称你有伪造的原木，并使它们成为不可接受的证据。
• 我们的系统如此复杂，没有人知道如何在不破坏完整性检查的情况下修改数据。-这是“通过默默无闻的安全”方法，它可能会很好地工作，…直到它没有。
• 我们将它与外部提供者存储在一起。-外部日志提供者通常声称它们提供了遵守情况。它们确实提供了遵从性的许多方面，主要是围绕日志收集系统的操作安全性。此外，在这种情况下，您(或您的管理员)无法轻松地修改外部存储的记录。有些提供者可能会给您删除记录的选项，这对于审计跟踪来说并不太好。这些服务的问题是，它们使日志在相对较短的时间内运行，然后以可以被篡改的形式导出它们。此外，您不能真正确定日志没有被篡改。是的，提供者不太可能关心您的日志，但是以它作为主要保证听起来并不完美。
• 我很好，它涵盖了日志完整性的许多方面。AWS正在对他们的CloudTrail日志文件进行时间戳，这无疑是一个很好的实践。然而，它只是在一个场景中的不足-某人删除了一个完整的时间戳文件。因为这是一个完整的文件，而不是逐条记录，所以你不知道哪条记录是目标。还有另一个警告--如果TSA在您的控制之下，您可以追溯时间戳，因此无法证明您没有伪造日志。

这些方法是有效的，并且在遵从谱上处于非零点.对于不同的管理员来说，拥有四份数据副本比只

https://m.douban.com/mip/note/811237689/

有一份好吗？是啊。使用本地TSA的时间戳比没有时间戳好吗？好的。使用外部服务比使用本地服务更安全吗？是。它们是否足以获得认证？显然是的。这是最好的办法吗？没有。你需要最好的吗？有时候是的。

这些措施大多是组织性的，而不是技术性的，组织措施比技术性措施更容易逆转或规避。我可能太多疑了，但当我是一个当涉及到安全问题时，我不得不疑神疑鬼。

我认为什么是不解决的办法？有大量的研究围绕篡改明显的测井，篡改明显的数据结构，默克尔树，哈希链。现在它应该已经成为主流了，但事实并非如此。我们显然已经决定了不太理想的程序(即使是在成本方面)，我们对标准的解释也很松散，我们在寻找一种低挂的果实。对一些组织来说这很好。我想是吧。

某种良好做法要成为主流需要时间，而且必须是显而易见的。篡改-明显的伐木是不明显的。我们逐渐意识到如何正确地存储密码，使用TLS，多因素认证。但安全性很少是业务优先事项，正如关于安全投资的驱动因素的报告(主要是“遵从性”)所示。

作为一个实际的结论-如果你要满足于一个解决办法，至少选择一个更好的。没有审计跟踪或者没有采取任何措施保护它不被篡改应该是不可能的。

通过切换DNS记录指向以前“备用”组的负载均衡器。但在切换DNS之前，我检查了新发布的版本的日志，发现了一些奇怪的东西--Web框架(SpringMVC)中的持续HTTP错误，即某个端点不支持HTTP方法。

https://m.douban.com/mip/note/811141093/

奇怪的是-我根本就没有这样的终点。我启用了进一步的日志记录，结果发现请求URL与我的域无关。备用组，还没有针对它的流量，收到的请求指向一个完全不同的领域，我没有拥有。

我给域名所有者和AWS发了条消息，告诉他们这个问题。域名所有者说，他们不知道这是什么，他们没有任何未使用或被遗忘的AWS资源。然而，AWS的答复如下：

随着流量需求的变化，ELB服务将动态扩展，因此，当扩展发生时，ELB服务将从AWS未使用的公共IP地址池中获取IP地址，并将它们分配给为您提供的ELB节点。您在这里看到的外部域名可能属于另一个AWS客户，后者的AWS资源不再使用您的ELB节点现在拥有的IP地址之一，因为它在某个阶段被发布到AWS未使用的IP池中，它们的Web客户端很可能过度缓存这些DNS名称(不尊重DNS TTL)，或者他们自己的DNS服务器配置了静态条目，因此正在与现在属于您的ELB的IP地址通信。ELB在[链接1]中简要描述了从Route 53添加和删除IP的过程，附加在DNS名称上的TTL是60秒。只要客户尊重TTL，就不应该有这样的问题。

我可以简单地忽略流量，但是如果我在这个角色中--在我的IP被释放之后，会发生什么，但是一些客户端(或者某个中间DNS解析器)缓存信息的时间比指示的要长。然后，对我的服务的请求，包括密码、API密钥等，将被转发给其他人。

在浏览器情况下，使用HTTPS可能会有所帮助，因为新负载均衡器的证书将与我的域不匹配，但如果其他工具不执行此验证或缓存它，则HTTPS不会有帮助，除非存在证书钉扎实现。

AWS说他们不能在负载均衡器上修复这个问题，但是实际上他们可以通过保持IP、所有者和主机头之间的映射来修复这个问题。这不会是微不足道的，但如果我的经验不是一个特殊的情况，这是值得探讨的。如果HTTPS解决了这个问题，它是否值得修复--可能不值得。

因此，这是经常使用HTTPS并在HTTP上连接时强制使用HTTPS的另一个原因。但也提醒您不要做聪明的客户端IP缓存(让DNS解析器处理)，并始终验证服务器证书。