.. Kenneth Lee 版权所有 2020
:Authors: Kenneth Lee :Version: 1.0
安全问题的本质
完成这篇总结以后：:doc:怎样写标准提案 ，我发现我有了一个讨论安全问题的概念空
间了。
对于系统安全，我发现很多人有这样一个误解，他们承认绝对的安全是无法达到的，但他 们认为安全是可以无限逼近的，类似这样：
.. figure:: _static/安全问题模型.jpg
这个其实是用现在想未来。就好像我们看到一根木棍，总觉得可以“日取其半，万世不竭” ，但其实等你进入微观的时候，你就发现在微观上，这个世界不是连续的，而是离散的。 你不要问“为什么”，我都没有问你“为什么你非要认为世界是连续的？”。从来没有人给你 承诺过，你在宏观世界看到的东西，在微观世界呈现一样的Pattern啊。
安全就是这样一个问题，在系统设计的初期，你觉得你在一步步消除你的安全漏洞。但一 旦所有的细节依附上去了。那么安全漏洞和新特性是一个东西。
在前面提到的这个如何写提案的文本中，我们举了一个奶茶加盟店的例子。假设我们已经 有了一个这样的系统，而且成功运作起来了，它就会包含很多的细节，这些细节，有些定 义在我们的标准中，有些甚至是没有定义出来的，比如你要求每个奶茶店在特定的时间接 原材料，奶茶店可能通过轮班的方式让不同的人在特定的时间片内接班，也有些店可能是 和送原材料的司机关系好，让货车司机提前一个小时给老板打电话，老板在这个时间内调 度人力过来接货。还有可能某些成批奶茶店在小巷子里，货车开不进去，他们多家招了一 个接货员，骑单车接了货，再一家家送。
你调整你的标准，就可能影响所有这些细节，导致某些奶茶店失去竞争力，从而离开你的 标准（和生态）。所以，做架构，做标准的人，永远都不能离开细节在那里说什么“我没有 违背标准啊，你倒闭是你的错”，用这种冰清玉洁的思维去做架构，只会“死得干干净净， 清清白白”。这看你怎么看了，在我看来，这种“清清白白的”架构师最脏了。
所以，新功能就是在一个这样的，被明确定义的标准，和没有被明确定义的细节中，找到 一条路（就是那个文档中提到的“提案”），在不大幅改变原来的模型的情况下，解决新的 需求。而这个新的解决方案如果被接纳了，就会成为下一个功能解决问题时的障碍。
而所谓攻击，也是从这个定义好的逻辑空间中，找到一条路，还是在解决一个问题，但这 个问题不是这个系统的使用者希望的，而是攻击者希望的。解决的不是使用者的问题，而 是攻击者的问题。
要把这条路关上，还是需要在这个复杂系统中增加约束，让这些路不存在。但关上更多的 路，关上的不但是攻击者的路，还有使用者的路。
.. figure:: _static/安全问题模型2.jpg
所以，只要你要优化系统，不管这种优化是增加功能，还是填补漏洞。你增加的逻辑都会 自相矛盾。对于逻辑的关联关系，你永远都是一个逐步发现的过程，逻辑漏洞也是一个逐 步发现的过程，发现后你就会需要对比，牺牲部分逻辑，所以，一旦细节开始依附上去， 安全漏洞就是一个反复增加和减少的过程，而根本不是一个连续的增函数。
所以，不要挣扎，所谓安全的系统，是一个信任和有问题解决问题的过程，不要尝试用什 么方法去逼近完美，这个方法不存在。不承认这一点，实施的方法就是错的（比如要求产 品线固化安全手段）。