安全速查

数据库篇

1. 对类似访问令牌、电子邮箱地址或账单详情进行加密处理，尤其是用户的身份识别信息（密码）。

2. 如果你的数据库支持低成本加密，请确保开启这项功能并保护主机磁盘中的数据。与此同时，确保所有的备份文件都进行了加密存储。

3. 按照最小权限原则给数据库访问账号分配权限，不要使用数据库的root账号。

4. 使用密钥存储器来保存或派发密钥，不要直接将密钥硬编码在你的应用之中。

5. 通过使用SQL预处理语句来避免SQL注入攻击。比如说，如果你使用的是NPM，那么请不要使用npm-mysql，你应该用的是npm-mysql2，因为它支持SQL预处理语句。

开发篇

1. 确保你软件中所有组件的每一个版本都进行了漏洞扫描，包括接口、协议、代码以及数据包。

2. 对产品中所有使用到的第三方工具时刻保持警惕性，选择一款安全系数较高的开发平台。

身份验证篇

1. 使用合适的加密算法（例如bcrypt）来计算并存储密码哈希，在初始加密时选择合适的随机数据，还有就是千万不要自己去写一个加密算法。

2. 使用简单但健壮的密码规则，以鼓励用户设置长度足够安全的随机密码。

3. 在服务的登录机制中引入多因素身份验证功能。

DoS保护篇

1. 确保那些针对API的DoS攻击不会严重影响你网站的正常运行，至少要限制API的请求访问速率。

2. 对用户所提交的数据和请求进行结构和大小的限制。

3. 使用类似CloudFlare这样的缓存代理服务来为你的Web应用添加DDoS缓解方案。

Web流量篇

1. 使用TLS，不只是你的登录表单和网站响应数据，而是你的整个网站都应该使用TLS。

2. Cookie必须为httpOnly。

3. 使用CSP（内容安全策略），虽然配置过程比较麻烦，但这是值得的。可以有效防止xss。

   网站通过发送一个 CSP 头部，来告诉浏览器什么是被授权执行的与什么是需要被禁止的。

4. 在客户端响应中使用X-Frame-Option和X-XSS-Protection头。

5. 使用HSTS响应，使用HTTPS。

6. 在所有的表单中使用CSRF令牌。

API篇

1. 确保你所有的公共API中没有可以枚举的资源。

2. 确保用户在使用你的API之前，对他们的身份进行验证。

验证篇

1. 在客户端对用户的输入进行验证，并即使给予反馈，但永远不要相信用户输入的数据。

2. 在服务器端再对用户所输入的每一个字符进行一次彻底的验证，永远不要直接将用户输入的内容注入到响应数据中，永远不要直接在SQL语句中插入用户提供的数据。

云端配置篇

1. 确保所有的服务只开启必要的端口，关闭不用的端口，并对常用端口进行强制性的安全保护，因为通过非标准端口来进行攻击对于攻击者而言相对来说是比较困难的。

2. 确保服务器后台数据库和后台服务无法通过公网查看到。

3. 在单独的VPC节点配置逻辑服务或提供服务内通信。

4. 确保所有的服务只接受来自有限IP地址的数据。

5. 限制输出数据的IP地址以及端口。

6. 使用AWS IAM角色，不要使用root凭证。

7. 对所有的管理员和开发人员提供最小的访问权限。

8. 定期更换密码和访问密钥。

基础设施篇

1. 确保可以在主机不下线的情况下进行更新操作，确保部署了全自动化的软件更新策略。

2. 使用类似Terraform这样的工具来创建所有的基础设施，不要使用云端console（控制台）来进行创建。

3. 对所有服务的日志进行集中记录，不要允许通过SSH来访问或获取日志。

4. 不要让AWS服务组的端口22保持开启状态。

5. 一定要部署入侵检测系统。

操作篇

1. 关闭不用的服务和服务器，因为最安全的服务器是那些关闭着的服务器。

测试篇

1. 开发完成之后，对你的设计和代码实现进行多次安全审查。

2. 进行渗透测试，也就是自己黑自己，但你也要让别人来对你的网站进行渗透测试。

计划篇

1. 创建一个安全威胁模型，用来描述你可能会遇到的威胁以及攻击者。

   威胁模型的含义是通过建立模型来处理企业所面临的安全威胁问题。它涉及到对安全风险的识别、评估等过程，从而帮助企业的信息安全管理人员合理有效得开展工作。

   1. 明确目标

      企业需要达到的安全目标是什么？结合企业的业务需求，根据以上安全目标和业务需求，缩小与之相关的技术范围。

   2. 分解系统

      获得一份易受攻击目标的清单。首先，对系统细节的掌握是至关重要的。系统细节包括系统架构，各个子系统的功能，以及子系统之间是如何相互作用的，甚至还要了解整个信息系统是怎样同外界交互的。

   3. 确定威胁

      枚举所有可能的威胁以及与威胁相关的系统组件，并对这些威胁进行记录。对于威胁的记录要全面，不允许有任何的错误和遗漏。

   4. 评估威胁

      到此为止，应该已经掌握了针对该系统的威胁情况和攻击场景。接下来，就要对威胁结果的分类赋予相应的权重，得到一份关于威胁严重程度的优先级排序以及相应安全措施的优先级。

      在威胁排序过程中，可以从企业资产的种类、攻击造成的严重程度、攻击发生的可能性大小等方面进行考虑。在排序过程中，要紧密结合企业的自身特性和所面临的具体情况。针对企业比较关心的某个特定威胁应该提升其优先级。

   威胁源：

     攻击者可以分为四类：
         以特权用户为代表的内部受信任者、
         以常规用户为代表的内部非受信任者、
         以合作伙伴为代表的外部受信任者和竞争对手、
         网络罪犯为代表的外部非受信任者。
   

2. 设计一个安全应急响应方案，你总有一天会用到的。