目录

  • 安全切面是什么

    • 来源于编程概念

    • 以Spring Security示例

  • 安全领域的切面

    • 解读

    • 能解决什么？

    • 难点在什么？

  • 切面安全的未来是Security Mesh

安全切面是什么

来源于编程概念

在实际企业架构中，业务拥有mvc层次：web接入访问、业务实现处理、数据持久化，各个阶段都需要考虑到应用安全措施。

但是如果在开发的后期才考虑安全的问题，就可能陷入一个两难的境地：一方面，应用存在严重的安全漏洞，无法满足用户的要求，并可能造成用户的隐私数据被攻击者窃取；另一方面，应用的基本架构已经确定，要修复安全漏洞，可能需要对系统的架构做出比较重大的调整，因而需要更多的开发时间，影响应用的发布进程。

正确的做法从应用开发的第一天就应该把安全相关的因素考虑进来，并在整个应用的开发过程中，这个时候安全sdl、devsecops都仅仅局限于研发安全。面向切面的编程防御理念提供了这样改造的可能。

切面的理念是一个编程的范式，在面向过程，面向对象的历史长河中，逐步出现了切面思维。比如安全人员调试漏洞查看线程堆栈报错信息，就是一个典型的面向切面场景。

以Spring Security示例

下面以目前成熟的，使用了切面理念的spring security框架演示，如何为业务保驾护航建立无需考虑具体的通用日志、安全审计等需求，无需每个功能点都自己实现安全能力，大概进行合理配置和接入，就实现了安全管控。

通过切面介入安全措施

用户名username参数未严格过滤输入输出，页面需要进行xss过滤处理，原始的做法是安全基于esapi提供安全sdk进行改造，在编程模式上属于耦合在类方法级别。编码在输出的位置过滤特殊字符。检查对每个输出点进行esapi.securityhtml(username,output)。

在切面的理念之上，可以改造为由业务定义接入从数据库取出来的username资源和方案数据

 <bean id="userDetailsService"
class="org.springframework.security.core.securityXSS..JdbcDaoImpl">
<property name="dataSource" ref="dataSource" />
</bean>
<sec:securityXSS>
<sec:sec-provider user-service-ref="userDetailsService" />
<if:acttrackcallback waf="waf.seccurity.com" />
<if:acttrackcallback audit="log.security.com" />
</sec:securityXSS>

项目中定义资源使用的url地址，完成。

<sec:http>
<sec:intercept-url pattern="/**" access="ROLE_USER" />
<sec:form-login />
<sec:logout />
</sec:http>

安全领域的切面

在上面的Spring Security 示例中，并不是各种配置xml的行为就是表示应用了切面，而是背后的esapi.securityhtml(usernam,output)方法替换改造为由org.springframework.security.core.securityXSS.jdbc.JdbcDaoImpl是切面的关键，采用面向切面的软件安全架构思路来进行安全切入，具体编程方法可以预编译、运行时动态代理或者注入的方式等，实现在不修改源代码的情况下给程序动态添加安全功能。

这样下来安全防御体系的理念不再是单点的防御，形成了重新定义如何获取数据，如何贴合业务，如何部署安全措施的防御框架。

重新结合上图理解下安全切面需要关注的实现技术：

切面（Aspect）:定义安全的切入点和通知对象，形成成熟的安全产品和机制。

连接点（Joint Point）:指被’感知‘到的安全事件、方案、对象、服务、业务数据。这个概念类似于rasp的hook点，sql审计的对象。

切入点 （Pointcut）：对连接点进行全部操作的定义，对于需要安全看护的点进行环绕增强。需要对数据透视能力，如arms、tlog、链路跟踪、EagleEye，workload之间的访问、授权、认证、加密，MOSN。

通知（Advice）:对拦截到连接点之后要执行的处理。基于智能计算和处理实现管控，包含安全从业人员的日常工作应急的原则+soar等。

代理（Proxy）：对目前服务进行安全能力的增强。如日志记录，性能监控，异常处理、熔断限流这样的非核心功能，单独被抽取出来，与业务代码分离，横切在核心业务代码之上。实现形式是多样如sidecar、proxy、gateway。

解读

在云原生、物联网、移动互联网、微服务体系、数据安全、AI安全的时代，单独的安全能力不再能由安全团队自己独立完成，必须融入到整体技术体系内，同时要剥离业务复杂，实现安全自主性。安全建设的特点是基于当前企业IT技术架构能力，但是需高于架构视野高标准建设安全能力，完成安全治理。

理解切面防御的关键在于明白它不是安全防御的目标，而是建设的过程和手段。虽深入业务逻辑，但是各自独立发展，整体安全目标依然是“实现治理感知攻防和审计的安全目标。”和零信任、纵深防御等理念并不冲突。我们的日常工作可以说很多都是在做切面安全防御。

传统的塔防、河防安全防御侧重静态，名词，状态，组织，数据，载体是空间；切面防御侧重动态，动词，行为，调用，算法，载体是时间空间。切面一定需要代理，有了代理好处多多。

能解决什么？

安全建设能力

通过安全切面理念把安全能力系统化地融入到技术基础设施和应用服务的内部，同时保持安全响应能力与复杂业务逻辑的结构，形成独立的功能切面，安全既在应用内部，它又是解耦的。比如dauth身份认证的实现就是一个很好的例子。

业务可见

支持从业务方面透视已完成的全方位的安全治理工作。系统足够复杂，防守方会不知道有多少资产，在大体量的组织内，业务复杂性得像一个分布式操作系统，一点点的技术负债就会导致安全管控能力的严重缺失。我们不自觉的，已经在做很多从切面的日常处理工作，如数据安全治理、操作审计、RBAC。

链路跟踪

获取全链路信息是切面安全的核心。由于是融入到整个系统内部的，所以安全可以获得大量的这种真实的、完整的、细致的数据来建设异常检测能力、攻击阻断能力，跨应用追溯能力和沙箱隔离能力。这个思路是目前所有甲方的痛点。采集业务方流量数据的稳定性、可靠性、实时性很重要，考虑到应用内外部两部分数据的流动性和量级，属于很难做到但是重要的事情，有余力的可以看下。

方法论

因为外挂落后了，内生搞不动了，所以那就平行吧。建立一套和业务相交织且平行的安全层，让安全能够深入业务逻辑，实现细致的观测和攻防。能够不依赖于业务代码更新，进行安全治理。

难点在什么？

安全系统自身的安全性。就像Spring Security看起来很美，但是如果背后的shiro组件出现漏洞，会导致认证绕过漏洞。没有完美的体系，软件是迭代引进的，名为高内聚低耦合，但是安全组件如果“打铁不能自身硬”，自己就会变为攻击者的高价值目标。

技术难度大。对公司的安全建设来说，干的活还是一样。还得是一步一步解决安全漏洞，逐步进行加固，该响应急的还是得应急。要实现“数据降维视角”，比如通过对调用链路的还原，实现安全内视和追溯，通过代码节点信息，分析和定位的应用内部更精细化的角色信息，需要基础设施整齐划一。安全团队在基本功都具备了的情况下，才有能力寻求新理念打动老板。给出个能不能干成的简单判断标准：没有service mesh，就搞不定。

非一日之功。不仅需要足够的知识，还需要一定的内部资源，可能并不适合能力不足的团队，不依赖业务能独立安全空间做事情 ，同时具备这样的业务平衡能力和建设时间，几乎是不可能的事情。

切面安全的未来是Security Mesh

从上面的描述中可以看到新架构解决旧架构中的哪些问题，能否在进一步深入呢？

切面防御的初心是现实中遇到的问题：一、由大量的微服务构成的分布式应用架构也会增加运维、调试、数据可见、和安全管理的复杂性；二、如果说一台服务器可以在宿主机部署检测进程异常调用，在服务级别的业务docker容器中，安全难以再强加于业务；三在互联网公司应急不能像Google一样实现极致的快速发布。

在业务的服务架构中，一般可以分为数据面和控制面。在和安全接触的点既然要避免外挂式的安全，折中的方案是做业务面和安全控制面的切入，这个说法就被称为切面安全。

Goolge把安全和sre统称为SRS，BeyondProd把安全做没了，同样可以把面向切面的作为安全生态的基础架构当做临时解决方案给做没了，让切面的思路扩展为终极目标：Security Mesh。（笔者自己发明的安全新名词，留言轻喷）

Security Mesh的目标是让安全切面落地的新理念，解决容器和云原生时代的安全挑战，是保障新基建的安全运营基础设施服务。

Security Mesh概念总结为：作为专用的安全基础设施层，提供提供安全的、快速的、可靠地服务间通讯和资产服务发现，与实际应用部署一起但对应用是透明的，实现了源到服务的安全性，数据链路追踪，热补丁，一系列的完备安全功能

声明：本文来自安全乐观主义，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。