最小化公共访问。
减少代码量——删除未使用的代码
遵循其他原则 – 请参阅下一节
安全默认值
我们的开发人员确实根据许可而不是排除来做出访问决策。这意味着，默认情况下，访问被拒绝，而保护方案会确定允许访问的条件。
例子：
如果创建了新角色，用户必须选择该角色能够执行的所有功能。
使用纵深防御
纵深防御的原理是分层的安全机制可以提高整个系统的安全性 德国手机号码数据库 如果攻击导致一种安全机制失效，其他机制仍可以提供必要的安全性来保护系统。
例子：
防范 SQL 注入可能包括几种对策：
正确的输入验证
实施准备好的语句
在数据库服务器上应用有关权限的最低特权级别
记录/监控数据库事务
使用最小特权原则
只需将访问限制在允许正常运行的最低级别即可有效减轻任何身份盗窃的影响。
例子：
如何实施最小特权来保护您的云环境？
对于访问管理使用RBAC。
在尽可能小的范围（资源集、资源组或订阅）上分配访问权限。
如果仍然需要，请定期检查系统的权限和访问权限。
非常类似的方法适用于任何系统配置等。
从错误中吸取教训
人无完人，有时我们也会犯错。当我们发现代码中的漏洞时，我们会立即采取适当的措施。作为调查过程的一部分，我们会问自己几个问题：
安全错误是如何发生的？
代码的其他区域是否也重复了相同的错误？
我们如何才能防止这个错误的发生？
我们如何确保将来不再发生此类错误？
一步一步地 - 识别漏洞，分析整个解决方案（如果它不包含相同/相似的问题）并实施代码改进 - 例如编写新的测试，创建新的自定义脚本，扫描解决方案以查找类似问题或编写最佳实践。
实施——迭代周期
在每个迭代周期中，当实现新功能时，我们的开发人员都会利用他们在安全培训课程中学到的知识。实施和代码审查不仅涵盖 OWASP 的十大漏洞，而且我们还会寻找业务逻辑中的安全问题。
实施——迭代周期
我们的安全团队会自动化所有重要活动，以便在出现安全问题时获得更快的反馈。自动化活动：
REST API（后端）每天定期使用自动化 Web 漏洞扫描程序进行扫描。
当创建新的公共或内部端点时，我们的自定义工具会通知团队有关更改。
安全团队手动审查所有新端点，以确保代码已由开发人员正确审查并且不包含任何安全问题。
验证 – 审核
最终安全审查有助于确保新功能的所有相关安全方面都得到考虑。当新功能（通常在实施过程中分为几个子任务）完成并准备发布时，将审核安全工具的所有输出，以确保未发现任何安全问题。如果自动化工具未发现任何问题，安全团队将进行最终的手动审查。下图显示了整个过程。
最终安全审查
最终安全审查可能出现两种结果。如果没有发现安全问题，新功能就可以发布了。否则，安全团队会创建相应的错误，跟踪错误进度，并在错误修复后重新执行整个过程。
想了解更多有关 Kontent.ai 安全性的信息？请查看我们的安全政策。
