在未发生安全事件的时候，安全方案推进落地往往困难重重；而当发生安全事件时，安全方案的重要性被抬的很高，希望能够快速上线止损。这种尴尬的局面让很多安全工程师或安全接口人很为难，很多时候重要性非安全人员说了算，而最后为安全事件买单的反而是安全人员。我想造成此类现状的原因，主要是以下2点：
- 业务有KPI，无开发资源支持安全方案落地；
- 安全方案不够透明，可能影响用户体验、性能，或业务侵入性太重，导致实施成本过大；
其中第1点，任何业务、任何团队都会遇到，因为“资源永远是不够的，有多少人，就会出现多少需求”，因为每个人都可能是个创造者，希望创造更多的业绩。
针对第2点，在安全方案的设计时需要换位思考，站在用户的视角设计优秀的安全方案，也就是说优秀的安全方案设计应该是对用户透明，同时能够有效抵抗威胁，而且不改变用户使用习惯，不影响产品性能体验，把安全作为产品的必要补充属性，让用户感受到可以安全地使用我们的产品，而无需用户付出额外很多的努力，或者付出很小的成本后让用户感知到这样做其实是在保护用户信息安全。
基于以上的现状、原因及思考，安全方案的设计原则需要把握4个核心原则。这4个原则在我们做设计时非常重要，能够让我们更理性地设计相对优秀的安全防御能力。
1.Secure By Default
在设计安全方案时，最基本最重要的原则就是Secure By Default，在任何时候都需要牢记该原则，该原则有2层含义：
第一层含义是“白名单、黑名单原则”：可以解释为“巧用白名单，慎用黑名单”，比如上一篇《安全篇：安全方案设计理念》中提到的“信任边界”，如果机场安检采用黑名单原则：“哪类人不可以进入机场”，那么有可能无法穷举所有有危险特征的人，当安检采用白名单原则，哪类人可以进入机场，这就简单很多了，只要符合机场安检部门定义的安全项即可。同样放在系统设计中，遵循白名单原则，比如哪些端口允许对外提供服务，其他端口一律关闭就是好的产品设计。
第二层含义是“最小权限原则”：这条相对来说好理解，授予主体必要的权限，不要过度授权。比如申请权限可以申请1年，但是不要申请长期；申请线上机器正常情况下申请guest权限，但是不要申请root权限；最小权限原则的意义是保护权限过大带来的误操作、恶意行为。
2.纵深防御原则
古代的城市保卫战中，若所有兵力只防守一个城门，结果只有一个：城市很快被攻陷。所以我们在电视剧中看到的城市保卫战，都是全城防御，涉及各城门，城墙，防空，城内巡视，低下通道等，虽然最终可能被攻陷，但是让供方付出了很多的努力和成本。而我们线上系统和城市一样，要求我们以一种全面的视角看问题，在正确的地方做正确的安全方案，避免疏漏，方案间相互配合，形成一个整体。
线上系统一般有哪些特点呢？比如数据传输、中心化、信息私密性、架构分层等，以上不是一个维度的分类，但却可以为我们提供防御设计的切入点。比如数据传输可以做好数据传输的加密，加签等；针对中心化的特点，做好防DDos攻击，避免大流量打趴系统；针对信息私密性需要我们做好权限隔离或验权设计；针对架构分层，在各层部署安全方案，比如服务层不开放80端口，WEB层做输入输出的过滤等。
3.数据和代码分离原则
这一原则广泛适用于各种由于“注入”而引发安全问题的场景，从漏洞成因角度提炼出的安全设计原则。脱离该原则引发安全问题的原因是程序把用户的输入作为代码来执行，比如常见的XSS漏洞：
<html>
<head> 展示用户名字</test>
<body>
$name
</body>
</html>
如果name字段未做编码或过滤，html页面在渲染的时候会去解释$name，如果name是<script>alert(1)</script>，会把<script>当作代码来解释，则显然不是开发者希望看到的结果。
如果实现上要求alert（name），那么根据数据和代码分离原则，html代码应该如下：
<html>
<head> 展示用户名字</test>
<body>
alert($name)
</body>
</html>
4.不可预测性原则
如果说数据和代码分离是从漏洞成因上设计（比如避免xsss漏洞）、纵深防御原则是从全局防御视角，避免单个薄弱点带来整个系统被攻陷；那么不可预测性原则是从让攻击者失效的角度来进一步保护系统的安全，比如接口调用中的关键参数（如ID、email）进行加密、APP登录使用的随机Token等，都是为了让攻击者找不到攻击的规律，使得攻击失效，在实施时可能需要用到加密算法、随机函数、哈希函数。为了进一步提升攻击失效，还可以对加密串，Token进行过期失效保护。
以上是从安全方案的设计4原则做了信息的梳理，下一次总结下安全评估的方法。
