业务安全架构的一些见解 从研发到白盒渗透测试

业务交互流程实际上取决于具体提供的功能、数据和逻辑。例如，从业务层面来看，它是否会涉及敏感数据、涉及的数据是否已经处理等。；应用和中间部件、应用和中间部件是承载整个业务的具体体现，也是应用安全和数据安全关注的焦点。从安全研发培训到安全包SDK，从代码白盒扫描到卡发布，数据生产如何提供给应用，如何应用消费，如何实现相应的权限控制等。基础网络架构，一个请求如何从客户端到服务，服务是通过哪些路由直接完成的。这可能是个问题。需要注意的是，软件架构师给你的评估文件中的网络架构图可能只是他所知道的一部分，更多的时候，他们似乎不关注；物理部署状态，IDC还是云，刀片服务器还是ECS？云服务器还是一个问题。除了自个的设置之外，还需要考虑APS系统本身的设置范围和其他所有不同的设置，还需要考虑APS系统的设置。

尽管如此，即使能够真正遵守规范，建立起评审机制，但是在大型企业中，结构评审的工作仍然可能很多。商业迭代变化很快，每周都会有几次结构评审，如何提高效率？先将可自动化的自动化掉，比如安全产品的部署，以及黑白盒的扫描。第二，将无法自动化的能力转移到测试部门、研发部门，使之具有安全属性。使研究与开发能够理解安全包的使用，并具有编写安全代码的能力，同时使测试部门能够具备一些基本的渗透测试能力。较终将既不能自动化也不能转移的能力沉淀在知识库和案例库(踩坑经验的Checklist)中。它是第一步，第二步是跟踪结果，根据结果建立积极的反馈，驱动或推动其他团队继续跟进。

当然，还有一些细节没有写，相关的结构评估表也没有贴出来，那么如何才能成为一名合格的安全结构师呢？相信大家都心里同样有自个的答案。当你有这样的视野时，许多事情并不难自己做。

安全性结构不能一蹴而就，企业也不能仅仅依靠渗透性测试来完善安全防御建设。随着技术的进步，更需要能准确地辨别是炒作还是跟风。作为企业安全部门的重要角色，安全架构师在具备相应能力的同时，不断学习也是一个不容忽视的方面。但愿以后安全行业的从业人员中能有更多合格的安全架构师。身为安全行业的小朋友，还有很多地方需要学习。一路上，谢谢。夜深人静，搁笔。