28 June 2020
本周感想集中在初创团队的架构思维一个维度上面 - 安全
假如有一个由工程师组成的创始团队，这个团队决定超越产品的概念验证阶段，或者打算退出当前的PaaS（例如Remind或Coinbase），所以需要从头开始设计AWS计划。
那么团队可以进行以下讨论：
如果团队在日志记录方面没有统一的策略，那么如果发生安全事故，那团队将几乎毫无用处，并且也没有任何数据可以用于基于基础架构的实际使用情况而制定的决策。 更重要的是，日志对产品可用性的帮助还胜于安全风险，这就是日志处理成为一种团队的架构和开发重中之重的原因。
首先安全通常是日志基础架构所关注的地位。具体做法就是分解问题：整个系统，这些系统会产生截然不同的日志。没有人愿意浪费时间在所有不同位置的日志进行故障排除。 默认情况下，系统将在本地登录，或者根本不登录。日志记录通常不提供用于bug排除，除非计划将日志存储到集中式和可查询的系统中。 与整个团队的交流应考虑以下几个方面：
比如现在生产环境下的outage了，一个工程师想ssh到生产服务器上，sudo到root上，并且执行tcpdump命令查看网络情况，行不行？
工程师有时会希望直接与生产服务器进行交互以解决问题，这是侵入性比较强的访问，有时候将可用来解决问题的根源，比如在危机中应该可以使用此通道， 但这个策略应精心设计，应将生产访问视为特殊情况，而正常情况可以极大地限制生产访问：
尽早在初创早期特别考虑生产疑难解答的风险，将有助于技术债务带来的整体损失。
一些通常开始的时候的工程团队会围绕其产品实施严格规范的纪律文化，但随后会在其选择的云基础架构的控制面板中搞得一团糟。 而这些基础架构本应该像应用程序一样，成为部署管道的一部分。编写的基础结构的代码，应该像构建应用程序一样。
人为地限制工程师对基础结构控制台的访问将有助于提升基础结构的工程标准并防止漂移。不能随便地漂移是一个强大的试金石测试，可以帮助证明基础架构可以抵抗对恶意更改或团队忘记恢复的更改造成的影响。
一旦基础结构基本上位于代码库中，就可以强制执行代码审查，添加单元测试或其他必须强制测试已经在产品中强制执行的整体代码质量的策略。
可以将修改基础架构的能力限制为类似于可能已经熟悉的构建服务器或CI/CD管道，并且可以更好地确定服务器是否因错误或恶意更改而保持不变。
向网络公开一个负载均衡器，但肯定不希望公开内部的Jenkins配置。
网络的布局需要标准，所以要考虑公有和私有网络，确定网络布局后，可以避免任何可能暴露敏感服务器（例如缓存服务器或数据库）的offset。 在临时故障排除过程中，或者当某人地向安全组允许任何带有0.0.0.0/0规则的协议时，这些则通常会暴露出来。 在基于网络的新型攻击肆虐之时，对安全组和网络ACL采取有条理的方法可以节省很多时间。
早期团队的常见不规范做法是将token和API密钥存储在源代码中，或者环境变量或工程师电脑的复制粘贴缓冲区里。泄露的机密是安全事件的主要原因。 比如API密钥位于粘贴板或Github上。
但对公司推进如何存储和使用密钥，或进行全面重构，可能是最困难的事情之一。
这个过程可能需要对工程师维护的自定义应用程序进行返工，或者对系统的总体构建方式进行全面检查。尽早解决此问题将有助于推动标准制定并完全消除未来的债务领域。 最高优先级的问题是通过任何必要的方法将机密保存在数据库。
涉及云基础架构的安全事件其实可以预测。不得到解决由于长期存在的多个技术债务就会暴露。 早期做法可以如上面所说，但基础设施还是会变得越来越复杂。
但，需要注意的是，如果安全目标在早期初创时没有架构，通常会在后面发生几何级的损失。