文章目录
 
API安全风险与防范
前言
API安全风险与防范
未授权访问
越权问题
数据窃听
DDoS攻击
资源耗尽攻击
重放攻击（Replay Attack）
注入攻击
篡改数据
代码泄漏
数据泄漏
API URL泄漏
服务端被黑
   
攻击者的常用手段
API安全小结
安全三要素
参考文档
扩展阅读
 

 
API安全风险与防范
 
前言
 
本文就API安全面临的常见风险和如何防范，浅谈了一下个人见解，供API设计和开发时参考。
 
API安全风险与防范
 
未授权访问
 
风险：攻击者知道API地址和传入参数后，访问未授权的数据或操作。
 
防范：
 
前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；
系统对系统的接口，需要用身份认证机制（比如，appId和appSecret机制、token机制）
 
参见：
 
移动应用微信登录开发指南
 
越权问题
 
风险：攻击者试图访问权限范围外（水平越权或垂直越权）的数据或操作。
 
防范：
 
不信任接口调用传入参数，必须由后端对访问作严格的权限控制，不要偷懒；
前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；
不相信前端传进来的和权限有关的参数（或者不要让前端传进来和权限有关的参数），而是后端自动获取当前登录用户的权限相关的信息；
后端不能只判断用户是否登录，而是还要判断当前用户是否有权限；
特别小心传入id来查询或操作的场景，一定要校验当前用户是否有该id的权限；
 
参见：
 
Web业务安全测试方法（1）—越权测试
 
数据窃听
 
风险：在调用API的传输过程中，数据可能会被窃听，比如恶意WIFI、DNS劫持、网络设备被黑等。
 
防范：
 
尽量在安全的网络中传输，比如内网、专线等；
采用HTTPS协议对传输过程加密；
对传输的数据进行加密。
 
DDoS攻击
 
风险：攻击者控制一群肉鸡，发起DDoS攻击（分布式拒绝服务攻击），导致接口被网络请求堵塞，无法正常服务。
 
防范：
 
采用WAF和防火墙；
采用流量清洗和黑洞技术；
设置IP白名单；
对接口调用频率和调用次数进行限制。
 
资源耗尽攻击
 
风险：攻击者利用接口漏洞来耗尽服务端资源。
 
防范：
 
限制上传文件类型和文件大小；
限制分页查询时每页的最大记录数；
限制接口调用频率和调用次数；
限制其它可能耗尽服务端资源的行为。
 
重放攻击（Replay Attack）
 
风险：攻击者获取一段报文后，重复多次请求接口。
 
防范：
 
在请求报文中加入随机数（nonce）和签名，如果随机数重复则服务端认为是无效请求；(该方法的不足是需要维护一张随机数的全表记录，如果用Redis来存储可能会占用较大内存)
在请求报文中加入时间戳（timestamp）和签名，如果请求报文的时间戳与服务端的时间差较大（比如1分钟），则认为是无效请求；（该方法的不足是在允许的时间差内，仍然有被重放攻击的风险）
结合nonce和timestamp机制（只在允许的时间差内维护随机数的全表记录，比如在Redis中随机数全表记录有效期只保留1分钟，这样就可以节约内存）；
一次性token机制，token使用一次后就失效。
 
参见：
 
防止重放机制
https://www.kaspersky.com/resource-center/definitions/replay-attack
 
注入攻击
 
风险：攻击者传入一些畸形数据，让接口执行一些意想不到的操作。
 
防范：
 
程序和数据分离，不允许调用者来控制如何执行程序；
使用预编译SQL，而不是动态拼接SQL；
在接口入参对象中只放必要的属性，且操作时只修改必要的属性。（防止利用JSON字符串和Object自动绑定特性，来传入多余的JSON属性，来更新整个对象）。
 
篡改数据
 
风险：攻击者获得一段报文后，篡改报文中的内容，再请求接口。
 
防范：
 
采用API签名（sign）方式来防止数据被篡改；
客户端对请求报文进行签名，服务端验签通过后，才响应请求；
服务端对响应报文进行签名，客户端验签通过后，才相信响应报文；
常用的签名算法包括SHA256或MD5，推荐使用SHA256（哈希算法，签名不可逆计算出原始值）；
签名时需要同时考虑防止签名被预测和重放攻击，需要将nonce和timestamp一起签名，保证每次签名（sign）值都不同；
 
参见：
 
微信支付-小程序支付安全规范
 
代码泄漏
 
风险：代码或程序中含有敏感信息，当代码或程序泄漏后，敏感信息也被泄漏。
 
防范：
 
不要在前端代码中存放secret等敏感信息，即使已经加密过的secret；
正确配置.gitignore，不要将一些不应该提交的代码或配置文件放到了Web服务器上，特别是前端代码；
代码中含有一些测试用的管理用的“秘密”API URL；
代码中含有一些过时且保护不当的API URL；
防止泄漏代码到互联网上，比如GitHub；
在后端服务器上，在受控的服务配置中心来配置敏感信息；
 
数据泄漏
 
风险：接口返回了过多的数据，包括敏感数据。
 
防范：
 
只返回必要的数据给前端，不要依赖前端来隐藏数据；
由后端来对敏感数据进行脱敏，不要依赖于前端进行脱敏。
 
API URL泄漏
 
风险：使用HTTP GET调用API时，API URL上带有参数，因为API URL是明文传输的，因此网络中的网络节点都可能窃取这些参数数据。
 
防范：
 
不要在API URL中放敏感信息；
尽量使用HTTP POST，来在HTTP Request body中传输参数，再采用HTTPS协议对传输过程加密；
 
服务端被黑
 
风险：虽然大多数攻击都发生在客户端向服务端的调用过程，但是如果服务端被黑，也会导致客户端面临风险。
 
防范：
 
做好服务端安全防范工作，最小权限原则，网络隔离，开放最少端口，设置安全组，漏洞扫描，入侵检测，告警等；
客户端对服务端的返回数据也要验签，防止响应数据被篡改（比如攻击者在服务端前安插了一个代理服务器来篡改返回的数据）；
 
攻击者的常用手段
 
攻击者的常用手段：
 
网络窃听；
抓包工具；
Chrome浏览器开发者工具；
编写Python程序进行来请求接口；
病毒程序。
 
API安全小结
 
互不信任原则：接口提供方不信任接口调用方的请求参数，接口调用方不信任接口提供方的返回数据；
不信任网络原则：假设网络传输过程是不安全的，网络中的每一个节点都是不安全的；
采用HTTPS协议，保证传输过程安全；
作最坏的打算，即使数据被窃听，也无法解密；
设立网络安全边界，采用WAF、防火墙、网络隔离、IP白名单、流量清洗和黑洞技术来防止DDoS攻击；
使用API网关，在API网关上实现安全机制和限流，简化API实现；
采用包含了nonce和timestamp的API签名来防止数据被篡改和重放攻击；
时刻关注水平越权问题；
注意编码安全，防止代码泄漏和API URL泄漏；
 
安全三要素
 
简化的安全三要素：
 
加密（Encryption）：数据传输过程加密，敏感数据存储加密。
认证（Authentication）：识别是谁，定义哪些是公开资源，哪些是需要用户登录后才能访问的资源。
鉴权（Authorization）：允许或拒绝用户的某些操作。
 
参考文档
 
移动应用微信登录开发指南
微信支付-小程序支付安全规范
 
扩展阅读
 
OWASP TOP 10
OWASP Top 10 Web Application Security Risks

做好的apk文件，被检测工具检测出一大堆风险问题，是不是感觉自己的付出白费了，今天咱就聊聊android的安全防范问题。
 
一，先说安全检查方面的吧
 
1，源文件安全问题方面
 
1 篡改和二次打包风险
2 应用签名未校验风险
3Java代码反编译风险检测
4代码未混淆风险检测
5资源文件泄露风险检测
2，数据存储安全问题方面
 
     2.1 WebView明文存储密码风险检测
 
     2.2Internal Storage数据全局可读写风险检测
 
     3.3加密算法不安全使用风险
 
     4.4日志数据泄露风险
 
     4.5URL硬编码风险
 
3，组件风险
 
     3.1Activity组件导出风险
 
     3.2Service组件导出风险
 
     3.3Content Provider组件导出风险
 
     3.4Broadcast Receiver组件导出风险
 
     3.5WebView远程代码执行漏洞
 
     3.6Intent Scheme URL攻击风险
 
4，安全防护能力
 
     4.1Java层代码动态调试风险
 
     4.2C层代码动态调试风险
 
      4.3动态注入攻击风险
 
      4.4模拟器运行风险
 
      4.5启动隐藏服务风险
 
      4.6Root设备运行风险
 
5，内容风险
 
     5.1自定义词汇
 
     5.2敏感文本
 
     5.3敏感图片
 
这种类型的风险存在于发布文章类或信息类应用，“涉黄”，“赌博”等词汇与图片需要进行敏感内容识别或过滤。为了节约成本，可以人工审核信息来完成，当然，这样工作量太大，要是有Money的话可以介入专业的
 
检测公司API，来让应用的内容安全做的更严密些。
 
二，在自己没钱的情况下，看我们能做哪些事吧
 
1，打包应用，基本要加的就是混淆了，当然，我们还要再创建一个签名文件
 
2，要是我们应用体积大了，还可以再压缩一下资源文件，我用 的是 AndResGuard
 
3，没钱，没办法啊，那就来个免费的加固服务吧。
 
做到这些，是不是大家都觉得，我也是这样做的。是的，一般我们程序都会做这些基本的操作，但是我们还可以再做些什么？
 
情况1，应用被反编译后二次打包了----apk在正式打包后生成hash签名保存在服务端。应用每次启动后校验当前应用hash与服务端保存的是不是一致，以此来校验应用是不是合法的。嘿嘿，是不是解决问题的一种方法了
 
上代码：
 
/**
 * 根据apk MD5摘要获取对应的哈希值
 *
 * @param context
 * @return
 */
public static String getApkHashValue(Context context) {
    String apkPath = context.getPackageCodePath(); // 获取Apk包存储路径
    try {
        MessageDigest dexDigest = MessageDigest.getInstance("MD5");
        byte[] bytes = new byte[1024];
        int byteCount;
        FileInputStream fis = new FileInputStream(new File(apkPath)); // 读取apk文件
        while ((byteCount = fis.read(bytes)) != -1) {
            dexDigest.update(bytes, 0, byteCount);
        }
       /* BigInteger bigInteger = new BigInteger(1, dexDigest.digest()); // 计算apk文件的哈希值
        String sha = bigInteger.toString(16);*/
        //解决MD5在特殊情况下丢失0的情况
        StringBuffer buf = new StringBuffer();
        byte[] b = dexDigest.digest();
        int i;
        for (int offset = 0; offset < b.length; offset++) {
            i = b[offset];
            if (i < 0) {
                i += 256;
            }
            if (i < 16) {
                buf.append("0");
            }
            buf.append(Integer.toHexString(i));
        }
        fis.close();
        return buf.toString();
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
        return "";
    } catch (FileNotFoundException e) {
        e.printStackTrace();
        return "";
    } catch (IOException e) {
        e.printStackTrace();
        return "";
    }
}
 
情况2；很多时候apk被反编译或被破坏，多通过模拟器或者获取root权限来操作
 
没办法，只能给模拟器说再见了。正式发布程序后，代码检测运行设备是否是模拟器，如果是的话，就不让运行了，root 设备一样的验证逻辑，简单粗暴!!!
 
但是root或模拟器检测并没有官方的或权威的检测代码，谁让android品牌太多太杂了捏，没办法。真遇到这种兼容性问题的话，没事，我们可以再做检查逻辑时，留一手服务端验证，
 
由服务端来控制这个版本或者某个用户走不走这部分验证逻辑额~~~~~，后边的可以自行发挥解决。
 
情况3，动态调试，内存读取......
 
和情况2思路一致，均是通过代码来检测是否有调试等工具在调试程序，然后做出相应的判断处理
 
其他情况都比较常见了，随便百度就能找到解决方法，这里就不啰嗦了。嘿嘿
 
最后，要是你们公司很有钱，那就不考虑那么多了，来个专业机构加密，一下风险就降到最低，只要有money~
 
 
 
没有绝对的安全，我们能做的就是把安全风险降到最低，欧力给！
 
 
 
Activity 劫持介绍请转至https://blog.csdn.net/weixin_56945835/article/details/115699931
 
账号与设备绑定问题请转至https://blog.csdn.net/weixin_56945835/article/details/116497478

前言
 
 
 
 
北邮 博士研究生学位论文
 作者：吴金宇
 指导老师：方
 2013/3/31
 
 
摘要
 
 
主要包括三个方面：定性评估、定量评估、实时评估。
 
定性评估：
 
 
 
在定性评估方面，针对攻击图分析中的两个重要问题：最优原子攻击修复集问题和最优初始条件修复集问题，定义了原子攻击拆分加权攻击图和初始条件拆分加权攻击图，将最优原子攻击修复集问题和最优初始条件修复集问题分别归结于原子攻击拆分加权攻击图中的最小割集问题和初始条件拆分加权攻击图中的最小割集问题，并证明其等价性。在此基础上提出了基于网络流的具有多项式复杂度的算法。实验表明，与己有成果相比，该算法具有较高的性能和很好的可扩展性，能应用于大规模攻击图的分析中。
 
 
定量评估：
 
 
 
在定量评估方面，（针对己有的贝叶斯攻击图模型无法表达网络运行环境因素对攻击发生可能性的影响，提出了广义贝叶斯攻击图模型，该模型涵盖了攻击者利用网络或信息系统中存在的脆弱性发动一步或多步攻击的各种可能性，攻击发生的不确定性，以及环境影响因素对攻击发生可能性的影响，在保留贝叶斯攻击图已有优点的基础上，进一步拓展了语义，引入了攻击收益和威胁状态变量，使得广义贝叶斯攻击图能够包括被评估网络或信息系统的业务应用环境和环境威胁信息对攻击可能性的影响，以及这些影响在广义贝叶斯网络上的传播，使得广义贝叶斯攻击图能够更真实地反映网络或信息系统中的网络攻击发生可能性的现实情况。（提出了基于广义贝叶斯攻击图的层次化定量评估方法，该方法利用广义贝叶斯攻击图表达被评估网络或信息系统中攻击者利用存在的脆弱性发动一步或多步攻击的各种可能性，攻击发生的不确定性，以及环境影响因素对攻击发生可能性的影响。在构建广义贝叶斯攻击图的基础上，提出了节点攻击概率、主机攻击概率、网络攻击概率三个层次攻击概率的计算方法，以及节点风险值、主机风险值和网络风险值三个层次风险值计算方法，使得安全管理员能够在节点、主机和网络三个层次了解网络的安全风险状况。实验表明，该方法更加切合被评估网络或信息系统的攻击发生可能性的真实情况，使得评估结果更客观准确。并且从理论和实验都证明了已有的基于贝叶斯攻击图的方法是本方法的一个特例，因此，本方法具有更广泛的应用价值。
 
 
实时评估：
 
 
 
在实时评估方面，(1)针对入侵检测系统产生的警报存在大量的误报问题和漏报问题，提出D-S证据攻击图模型，该模型利用D-S证据理论将安全警报得到的证据融合到攻击图中所关联的节点上，并在攻击图中进行前向和后向的信度传递，更新相应节点的预测支持因子和后验支持因子，进而计算节点攻击信度和节点预测信度。该模型既利用了D-S证据理论对不确定信息的融合处理能力，又利用了攻击图上脆弱点利用之间的关联关系优势，使得该模型能够有效地抑制安全警报中存在的误报和漏报问题。(2)提出基于D-S证据攻击图模型的增量式实时评估方法，该方法从空间上分为检测层、攻击图层、主机层和网络层四个层次，在时间上分为初始化阶段和实时更新阶段。该方法由于利用D-S证据攻击图模型很好地抑制了安全警报中存在的误报和漏报问题，对安全警报进行关联和融合，然后计算节点、主机和网络三个层次的攻击信度和预测信度，从而能够准确地进行攻击场景还原和攻击行为预测，并计算相应的威胁值和最终的网络安全态势值，从而获得了网络或信息系统在节点、主机以及网络三个层面的安全威胁态势状况，具有完善的功能。由于该方法是一种增量式的评估方法，并且具有线性的算法复杂度，实时性能较高。实验表明，该方法能够客观准确地进行攻击场景还原和攻击行为预测，并得出符合客观情况的实时网络安全威胁态势，并且，该方法具有高性能高可扩展性的特点，能应用于大规模网络或信息系统的实时评估之中。
 
 
关键字
 
 
 
 
网络安全风险评估；攻击图；网络流；广义贝叶斯攻击图；D-S证据攻击图模型
 
 
主要内容
 
 
论文的主要内容组织结构如下图：
 
 
 
 
 
论文的创新点：
 
 
 
网络流攻击图分析方法；
 广义贝叶斯攻击图模型
 广义贝叶斯攻击图的层次化定量评估方法
 D-S证据攻击图模型
 基于D-S证据攻击图模型的增量式实时评估方法
 
 
创新点之间的关系
 
 
 
 
 
网络安全脆弱性分析技术
 
a) 脆弱行描述方法
 
 
 
 
为了能够存储、共享、交换以及使用脆弱性信息，各个标准组织以及研宄机构，提出了各种脆弱性描述方法，其中有两种方法最具有代表性，分别是基于巴科斯范式和基于XML的描述语言。
 
 
基于巴科斯范式的描述方法的优点是避免脆弱性信息直接利用文字描述所带来的模糊性、冗余性以及不利于自动化关联性等问题。基于巴科斯范式的描述方法具有效率高、描述能力强等优点，但是可能存在符号体系和语法规则不统一的问题，使得互操作方面比较差。
 
 
基于的描述方法则避免了巴克斯范式方法的不足之处，XML语言是具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言，由于基于XML的描述方法具有成熟的体系和良好的开放性，使得脆弱性信息的表达和互操作得到了很好的实现。正是基于XML的脆弱性描述方法具有多方面的优点，使得基于XML的脆弱性描述方法成为脆弱性描述方法的主流方法之一。
 
 
b) 脆弱性检测方法
 
 
 
脆弱点检测的方法主要是基于主机的检测方法和基于网络的检测方法。
 
 
基于主机的检测方法，主要是通过在被检测的主机上安装相应的代理，然后通过该代理检测主机上所有的文件和进程，发现违反安全规则的对象，从而检测出相应的脆弱点。基于主机的脆弱性的检测方法能够准备的检测到相应主机上的脆弱点，而且只对被检测的主机有所影响，但该方法需要在被检测的主机上均安装相应的代理，并且发现远程渗透弱点的能力较差。
 
 
基于网络的检测方法又分为主动检测方法和被动检测方法。
 其中主动检测方法通过发送特定的数据包到被检测的一个或多个主机当中，通过这种方法来判断被检测主机上是否存在相应的脆弱点。由于无需在被检测主机上安装相应的代理，并且可以给多个主机发生数据包，因此，这种方法的效率比较高。但由于主动发送的数据包有可能被防护墙等设备栏截，导致无法检测目标主机是否存在相应的脆弱性。并且主动检测方法产生的数据包会增加网络旳负荷，对网络的正常使用造成一定程度的影响。
 被动检测方法则通过抓取网络中的数据包进行分析，从而判断相应主机上是否存在脆弱性。由于被动检测方法不产生数据包，因此不会增加网络的负荷，从而不会对网络的正常使用造成影响，因此被动检测方法可以一直“透明式”的在线。但当检測主机由于服务不在线或其他原因导致没有发送数据包，或者只发送了具有部分脆弱点特征的数据包时，被动检测方法就不能检测或只能部分检测到目标主机上存在的脆弱性。
 通过上述的分析我们可以得知，在脆弱性检测的方面，每一种方法都有优缺点，在实际应用中需要根据网络或者信息系统的实际情况，采用某种或结合多种脆弱性检测方法来检测网络或信息系统上存在的脆弱性。
 
 
c) 脆弱性的评估方法
 
 
 
目的是为了评估网络或者信息系统上面脆弱点之间的关联，国内外比较经典的几个模型：比较典型的有故障树((Fault Tree)模型、攻击树(Attack Tree)模型、基于Petri Net的模型、特权图(Privilege Graph)模型、以及攻击图(Attack Graph)模型。
 
 
故障树((Fault Tree)模型：是用于描述系统内部的故障及其原因之间关系的模型。Helmer提出用于攻击者的入侵行为建模，Helmer对攻击者的入侵的描述、标识和检测。故障树模型用于脆弱性评估之中可以从逻辑上清晰地表达脆弱点之间的关系，然而故障树会随着逻辑门和基本事件数目的增加而呈指数增长，产生组合爆炸问题。
 
 
攻击树(Attack Tree)模型： 攻击树模型最早是由Schneier基于故障树模型的概念提出的。攻击树中的叶子节点表示攻击方法，根节点表示了攻击者的最终目标。攻击树中的节点分为AND节点和OR节点，其中AND节点表示只有所有孩子节点都实现，父节点才能实现，OR节点表示任意一个孩子节点实现了，父节点就能实现。
 攻击树对各种可能的攻击路径有清晰的逻辑表达能力，并且便于才攻击树上的攻击概率计算等量化计算工作，然而在攻击树的具体应用中，其结构可能变得非常庞大而复杂。攻击树模型的规模问题制约了该模型在实际脆弱性评估中的应用。
 
 
Petri Net的模型：基于Petri Net的模型方面，McDermott提出了攻击网(Attack Net)模型，该模型使用Petri Net来表达攻击行为，其中位置表示攻击的目标和状态，变迁表示攻击行为。Petri Net可以很好地对网络攻击行为对脆弱性的利用进行建模和分析，并且具有灵活的结构，但Petri Net同样受限于规模问题，使得其难以应用于规模较大的网络或信息系统的评估中。
 
 
特权图(Privilege Graph)模型：特权图模型首先由Dacier提出，特权图模型中的节点表示一组权限集合，特权图模型中的有向边表示使得权限集合发生变化的脆弱性。特权图上的一条路径表示攻击者利用一系列的脆弱性使得其获得的权限发生变化的过程，即表达了一条攻击路径。然而特权图只考虑了权限提升类的脆弱性，却依然存在着状态爆炸的问题，使其在实际应用中受到了一定的限制作用。
 
 
d) 攻击图技术
 
 
 
攻击图模型在脆弱性的表达和评估方面具有很多方面的优势，在脆弱性评估和评先评估方面都有着较为广泛的应用。针对脆弱性分析主要采用攻击图的技术。
 
 
攻击图生成方法
 典型的攻击图的生成方法包括有：基于模型检测的方法、基于图论方法、基于逻辑编程的方法。
 在基于模型检测的攻击图生成方法中，Ramakrishnan使用模型检测方法对系统及所有安全策略及属性等进行形式化描述，然后在其上查询反例，每一个反例即为一条攻击路径。
 Ammann首次提出了非常重要的攻击图的单调性假设，将生成攻击图的复杂度从指数级别的复杂度降为多项式级别的复杂度，并提出了一个基于图论的方法来生成攻击图。Ingols提出多先决条件图(multiple-prerequisite graph)形式的攻击图，并采取剪枝技术来降低攻击图的复杂度，使得生成的攻击图的规模得到有效的降低。
 Ou等提出一个脆弱性分析引擎Mu1VAL，该引擎使用逻辑语言描述系统的相关属性以及存在的脆弱点，并使用逻辑推理分析网络的脆弱性。在此基础上，Ou提出了基于MuIVAL的攻击图生成方法，该方法使得攻击图的生成复杂度降低到了O(n2)(其中n为网络中的主机数量)。由于该方法的性能较好，具有较好的可扩展性，使得该方法能够应用于较大规模网络的攻击图的生成当中。Ou的研究团队提供了基于该方法的攻击图生成工具。Saha对Ou的方法进行进一步的拓展，使得拓展后的Mu1VAL能够表达更多的安全策略，并且实现了增量式的算法，从而能够根据变化了的脆弱点高效地更新攻击图。
 
 
攻击图分析方法
 基于攻击图的分析方法主要可以解决在定性评估问题中使用最少代价的安全措施集合达到保护目的。
 
 
网络安全定量评估方法
 a) 攻击概率计算方法
 
 
 
攻击概率反映了网络或信息系统的安全状况，并预测将会发生的攻击及其可能性大小，也是后续风险值计算的基础。攻击概率计算的准确性不仅影响了对网络安全状况和攻击预测的判断，并影响风险值的计算结果，以及后续的风险控制措施的选择，因此，攻击概率计算的准确性是网络安全定量评估的关键问题之一。
 
 
状态攻击图中：攻击图的提出者Phillips等提出对攻击图上的攻击路径上的脆弱点的利用复杂度的乘积来计算攻击图的节点攻击概率。但是这些不能用于属性攻击图中。由于状态攻击图存在状态爆炸的问题，状态较小的网络可能生成的状态攻击图的网络规模也非常庞大，因此这种攻击概率的计算方法在实际应用中没有得到很好的应用。
 
 
Dantu等对攻击能力和行为进行描述，并使用基于贝叶斯网络的方法计算节点攻击概率。Wang等提出一种基于攻击图的定量评估方法，该方法采用攻击阻力(attack resistance)来表示脆弱点利用的复杂度。Frigault等采用贝叶斯网络的方法网络的内在风险进行分析，并提出动态贝叶斯网络来包含脆弱性随着时间变化等时间特性。叶云等针对基于攻击图的概率计算中循环路径导致的攻击图的难以理解和概率重复计算问题，提出了最大可达概率的概念和计算方法。Xie利用贝叶斯网络对攻击发生的不确定性进行建模。Poolsappasit基于前人利用贝叶斯网络进行定量分析的方法的基础上，提出了贝叶斯攻击图的概念，并利用该贝叶斯攻击图进行静态评估和动态评估。
 
 
b) 风险值计算

风险值计算的阶段经理三个阶段：手工评估、定性计算、定量计算。	
这里主要介绍的是定量计算。由于定性计算方法存在不足之处，美国国家标准局提出一个风险值计算方法：
![这里写图片描述](https://img-blog.csdn.net/20180205094913270?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvR2VyYWxkX0pvbmVz/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)![这里写图片描述](https://img-blog.csdn.net/20180205095052495?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvR2VyYWxkX0pvbmVz/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
 
 
网络安全实时评估系统
 
  
 
   
网络安全的实时评估方法包括有：基于关于警报关联的方法、基于D-S证据理论的方法、基于数据挖掘的方法、基于隐马尔可夫模型（HMM）的方法、基于贝叶斯网络的方法。
 
   
在基于警报关联的方法中，Ning等人提出一种警报的关联方法，该方法利用了入侵攻击的前提条件和后置条件对相应的警报进行关联，并提出超警报(Hyper alert)的概念，通过将基本警报融合到超警报当中，然后根据超警报的前提条件和后置条件对超警报进行关联，得到超警报关联图(Hyper-alerts correlation graphs) 。
 
   
基于D-S证据理论的方法对警报赋予了可信度，不同警报根据对应的检测器的准确率等不同其可信度不同。Sabata, Sudit和Quy等都提出基于D-S证据理论的评估方法对分布式的攻击事件进行融合，从而实现对网络态势的感知。
 
   
在基于数据挖掘的方法中，Lu等人采用支持向量机(Support VectorMachine ，SVM)的方法对多源、多属性的信息进行融合，从而获得网络态势的感知。Braun和Jeswani也采用SVM作为融合技术，从而实现了多数据源信息的融合，并讨论了高维输入处理的有效性问题。Zhang等人采用人工神经网络(Artifical Neural Network，ANN)的方法对数据进行融合，该方法利用了ANN处理非线性问题方面的能力进行评估。在基于隐马尔科夫模型(HMM)的方法中，Ourston和Ames等人都提出采用HMM对网络攻击过程进行建模，将网络安全状态的变化过程采用隐马尔可夫模型来描述，然后利用该模型评估网络的安全态势。基于数据挖掘的方法和基于隐马尔科夫模型的方法都需要大量的训练数据来学习模型中的参数，而一般网络或信息系统往往较难获得这些数据，并且这些方法由于没有利用攻击关联等先验知识，从而难以实现具体攻击的预测。
 
   
由于基于贝叶斯网络的方法能够充分利用攻击图的结构和脆弱点利用复杂度等信息，从而不需要对结构和参数进行学习，加上贝叶斯网络在概率逻辑关联推理方面的优势，使得基于贝叶斯网络的方法成为了网络安全威胁态势评估的热点之一。然而，基于贝叶斯网络的方法由于需要对所有节点(包括大量的警报节点)都建立条件概率表，因此需要较多的先验知识，并且已有的方法中并没有将攻击发生概率和攻击预测概率进行区分，不利于区分攻击己经发生的可能性和攻击将要发生的可能性。另外很重要的一点是，受贝叶斯网络推理算法复杂度的限制，基于贝叶斯网络的实时评估方法的性能不高，难以满足大型网络或信息系统实时评估的性能要求。
 
  
 
 
总结
 
 
 
 
风险评估和风险管理技术仍然是信息安全领域不断在发展的课题，仍然存在一些不足之处需要不断地进行完善。结合作者在网络安全风险评估的实践和体会，在将来的研究工作中，还有如下问题有待于进一步解决:
 
 
根据定量评估的结果，研究最优的风险控制方案，从而能够使用最少的风险控制代价将总的风险控制在可接受范围之内。这是一个最优化理论问题，需要结合风险评估和风险管理技术本身的特点来研究和完善相应的理论和算法。
根据实时评估的结果，研究最优的实时风险控制方案，从而能够及时地控制和遏制网络安全态势，并设计高性能的算法计算得到代价最小的防御方案，以确保关键资源避免受到攻击。由于实时评估对性能的要求较高，如何研究和设计有效并且高性能的算法是实时风险控制面临的一个挑战。
进一步提高网络安全风险评估和风险控制过程中的自动化实现方法，包括进一步提高风险评估过程中的复杂连接关系的识别等的自动化程度，以及根据评估结果自动化地生成网络安全风险控制建议报告，甚至根据实时风险评估结果自动化地采取有效的风险控制措施对攻击行为进行控制和防御。
本文主要是从技术上对可能的威胁利用脆弱性造成的影响进行评估，如何进一步结合管理上存在的风险等人为因素进行评估是风险评估和风险管理领域面临的难点之一。

原文链接
 
01.混合云架构下的安全风险分析
 
1. 混合云架构下的安全风险分析
 
企业混合云环境，一般包括一个或多个公有云厂商以及自建的私有云平台，从信息安全风险管理角度来看，实施混合云涉及到IT基础架构和应用架构的重大变更，因此需要重新进行风险评估。混合云环境下需要考虑到的安全风险包括：
 
公有云厂商及其安全服务的选择
私有云安全防护能力建设
混合云环境下的服务器、容器、无服务器应用安全
混合云环境下的数据安全
统一的混合云安全管理和运营平台
统一的混合云运维管理通道
混合云环境下的安全合规需求
云原生安全产品的选择
 
1.1 公有云厂商及其安全服务的选择
 
1) 公有云厂商是否具备合适的认证资质
 
认证资质体现了公有云服务商自身在信息安全管理、云平台基础架构管理、安全运维和运营、用户个人信息保护、特定行业领域安全保障、灾难恢复和业务连续性管理及法律合规风险等方面的服务能力。
 
如果企业上云业务涉及到用户信用卡支付，则需要提供基础架构服务的公有云厂商具备PCI DSS认证资质；如果企业上云业务需要通过国家等级保护认证，则需要需要提供基础架构服务的公有云厂商具备不低于企业应用系统等保定级级别的网络安全等级保护资质。因此企业需根据自身单位性质，行业要求，业务模式和具体安全需求选择合适的公有云厂商。
 
公有云厂商申请的常见安全资质包括：ISO 20000（IT服务管理体系），ISO 27001认证（信息安全管理体系），ISO 22301（业务连续性管理），ISO 27017（云计算信息安全），ISO 27018（公有云个人身份信息安全防护），CSA STAR金牌认证（BSI+CSA云安全认证），ITSS（工信部云计算服务能力评估）(1级）网络安全等级保护（3级，4级），可信云服务认证资质等。
 
一般来说，公有云厂商拥有的资质种类多少，某种程度上表明其对云平台基础建设和保障、用户服务、信息安全和法律法规遵循性方面的重视，从而能够为云租户提供更好的运维和安全服务。
 
2) 公有云厂商是否能够提供企业需要的安全服务项目
 
不同公有云厂商由于战略目标和业务发展规划不同，在信息安全理念、安全团队、安全技术能力沉淀、安全软硬件产品线等方面也存在差别，因此对外提供的安全产品和安全服务内容也会不一样。如阿里云的IDaaS可以为混合云应用提供统一的身份认证和授权管理，腾讯云防病毒引擎服务可以对用户上传文件进行安全扫描等，但并非所有的公有云厂商均可提供类似的安全服务。
 
因此企业选择公有云厂商之前，应预先通过公有云厂商网站对其能够提供的安全产品和安全服务进行全面了解，并根据自身的业务安全风险、安全需求和安全技术经验，初步规划后续需要使用的安全产品和安全服务，对可能使用到的一些安全产品或安全服务内容存在疑问时，应积极和公有云厂商或其服务代理商进行深入沟通，比如支持的数据库类型，是否提供网络层的流量入侵检测服务，是否提供虚拟化补丁服务，是否提供统一的安全管理平台等，以便后续有需求时能够确保选择的公有云厂商可以提供需要的服务能力。
 
3) 公有云厂商安全服务协议和SLA是否满足自身安全需求
 
上云企业应仔细检查公有云厂商提供的各类安全服务协议和SLA内容，确认是否满足自身的安全基线、安全检查、安全审计、安全合规、事件处理、灾难恢复时的服务要求。
 
1.2 私有云安全防护能力建设
 
1）私有云产品选型
 国内私有云解决方案包括商业性质的VMware vCloud Suite产品 ，以及基于开源云计算管理平台Openstack进行二次开发的多家私有云厂商产品，如EaskStack，青云等。与此同时，不少公有云厂商也推出了自己的混合云解决方案，包括华为云Stack、阿里云Apsara Stack、腾讯云TCE、AWS Outposts、Azure Stack等，以帮助企业用户解决私有云产品选型，并可通过一致的产品和服务控制台统一管理企业混合云，同时进一步提升自己的公有云市场占比。
 
2）如何构建私有云安全能力
 企业自建私有云时，应同时考虑私有云平台的自身安全性以及可以提供给云租户的安全服务内容，私有云安全能力和私有云产品的最终选型紧密相关。
 
私有云安全体系建设包括整体网络架构设计、安全硬件设备部署、服务器硬件安全加固（安全引导技术如TPM，UEFI等）、网络设备安全、操作系统安全、通信安全、统一身份认证和授权、应用安全、中间件安全、存储和数据安全、API安全等多方面内容。如使用原生openstack自建私有云，可参考https://docs.openstack.org/security-guide/进行安全检查和安全加固，如使用第三方厂商的私有云解决方案，需要参考厂商提供的私有云平台安全要求进行检查和加固。
 
对于为租户提供的安全服务，使用openstack构建的私有云，可考虑集成一些安全开源软件（如pfsense，VeryNginx等）实现基本的防火墙和WAF安全服务。
 
传统的国内外硬件安全厂商（如绿盟，山石网科等）也开始提供软件化的安全产品和服务，通过软件定义安全SDS架构，可以提供相应的API和openstack等私有云平台进行集成，实现防火墙、负载均衡、入侵检测、入侵防御、WAF等安全功能集中管控的同时，也可为租户提供所需的安全服务。也有一些硬件安全厂商（如深信服，天融信等），通过超融合系统设备，直接在私有云环境中整合自身的各类安全产品，为租户提供一体化安全服务。
 
相对而言更具竞争力的是那些推出混合云解决方案的公有云厂商，基于其自身公有云安全建设和安全服务经验，也许可以为私有云租户提供更加合适、可靠的安全产品和安全服务能力。
 
因此对于混合云环境下的私有云安全能力建设，企业需要在传统安全厂商和公有云厂商的安全产品解决方案中做出艰难抉择。
 
1.3 混合云环境下的服务器、容器、无服务器应用安全
 
混合云环境下,企业业务运行的支撑环境包括服务器、容器或无服务器应用（如AWS上基于事件驱动的Lambda函数），这些业务运行环境的安全是企业需要重点考虑的安全问题。Gartner在 17 年提出了云工作负载安全平台CWPP (Cloud Workload Protection Platforms)的概念，主要就是致力于解决云环境下业务运行环境的安全性问题。根据产品聚焦的不同安全内容，CWPP产品又可细分为以下7类：
 
支持多种类型操作系统功能
漏洞扫描，配置和合规性功能
基于身份的细分，可见性和控制能力
应用程序控制/所需的状态执行功能
服务器EDR，工作负载行为监控和威胁检测/响应功能
容器和Kubernetes保护功能
无服务器保护功能
 
混合云环境下，企业应根据自身业务系统实际运行环境，如操作系统类型，是否使用容器，是否使用k8s，是否使用无服务器应用，是否有合规需求等，选择合适的CWPP产品。此类产品包括青藤云、安全狗、阿里云等多家独立安全厂商或公有云厂商产品。需要特别注意的是，选择的CWPP产品是否支持或如何支持混合云方式部署，以便后续的统一管理和维护。
 
1.4 混合云环境下的数据安全
 
其实不管是混合云环境，还是传统IDC环境，数据安全都是信息安全的重中之重。
 
混合云环境下，企业数据会同时在公有云和私有云中传输和存储，从而增加了数据被监听窃取或被篡改的风险。因此公有云厂商一般都会提供数据加密、密钥管理、敏感数据发现、敏感数据脱敏、数据库审计、数据库防火墙等安全技术和安全服务以保护云租户的数据安全。
 
另一方面，由于公有云厂商自身也会出现如服务器宕机或服务中断事件，从而导致云租户数据丢失的事件也有发生，所以实际操作过程中，大多数企业仍然倾向于划分公有云环境和私有云环境为不同安全等级（或信任级别）的区域，公有云环境更多用于部署业务前端应用并按需扩展，业务敏感数据仍然选择在企业可控的私有云环境进行存储。
 
一些传统数据安全厂商（如美创，昂凯科技等）也已推出自己的混合云数据安全解决方案，涉及数据库运维管理平台，数据库审计系统，数据库脱敏系统，数据库防火墙，数据库加密系统等多种软硬件产品。
 
对于企业信息安全或者是数据安全管理部门而言，混合云场景下的数据安全仍应遵循数据全生命周期安全管理理念，需要对公司各类数据进行梳理和分类分级，从数据生成和采集，数据传输，数据存储，数据处理，数据交换，数据备份和恢复，数据销毁整个生命周期进行风险评估，选择和实施适合混合云场景的数据安全技术、数据安全产品和安全管理措施，从而真正保障企业数据安全的同时，也可以满足企业需要遵循的各类数据安全标准、法律法规和行业合规要求。
 
1.5 统一的混合云安全管理和运营平台
 
混合云架构下的信息安全运维和运营管理涉及到公有云和私有云环境中的多种安全产品和安全实现技术，从信息安全管理部门的运维和运营效率，以及安全管理的一致性体验角度考虑，需要可以通过一个统一的安全管理平台实现集中化管理。
 
如果选择公有云厂商提供的私有云安全解决方案，厂商通常会提供统一的安全管理平台实现对公有云和私有云安全设备和安全服务的集中管理。
 
对于一些安全产品线较为完善的硬件安全厂家（如绿盟，深信服等），也会推出基于自有安全设备的混合云安全解决方案。通过在公有云环境开辟一个单独的安全管理区域，部署自有各类软硬件安全产品来替换公有云厂商提供的防火墙、WAF、DDOS、堡垒机、入侵检测设备、漏洞扫描系统、日志审计等安全服务，同时在私有云环境同样部署一套类似环境，实现对自有安全产品的统一管理。此类解决方案通常实施成本较高，存在重复部署问题，同时安全防护能力依赖于厂商现有的安全软硬件产品体系完善程度，不一定能够真正满足企业的实际安全需求。
 
如果选择原生Openstack或基于openstack二次开发的私有云平台，如需实现统一的混合云安全管理平台，就会涉及公有云厂商安全服务API接入开发，所选硬件安全厂商提供的安全API接入开发，甚至需要硬件安全厂商的二次支持开发，目前来看，开发工作量和实现难度很大。
 
1.6 统一的混合云运维管理通道
 
对运维人员来说，混合云架构意味着需要在一个或多个公有云环境和私有云环境分别进行系统安装、服务部署、应用发布及日常的更新维护工作。针对私有云环境进行运维时，需要登录公司内部堡垒机进行操作，针对公有云环境进行运维时，需要登录公有云厂商提供的管理平台进行操作。同时对于公司安全管理部门来说，也需要在多点部署安全设备或安全工具，实现运维账号和运维权限管理，用户登录和操作日志审计等方面的安全管理工作。
 
混合云环境下，运维或安全管理部门，可选择一款多云管理平台（如新钛云服提供的TiOps多云管理平台等），运维人员可以通过统一的平台入口，实现多云资源（包括公有云、私有云、物理机和容器）管理、自动化运维、k8s管理、公有云成本管理、CMDB、监控告警等运维工作，同时实现用户角色和权限管理、用户登录和操作审计及回放等安全功能。
 
1.7 混合云环境下的安全合规需求
 
不同类型的信息安全法律法规条款或安全合规认证内容，都是基于其关心的安全目标和定义的安全检查对象，通过具有不同安全侧重点和不同安全要求的多个检查项，对信息系统及其支撑、运行环境进行安全检查、测试和审计，以确认信息系统及其支撑运行环境中，采取的各类安全措施是否符合需要的安全要求。混合云环境的合规检查对象，一般都会涉及公有云厂商基础架构、公有云业务、私有云平台和私有云业务。
 
比如混合云环境下的等保2.0合规认证，需要分别考虑公有云环境和私有云环境下的等保合规问题。对于公有云业务，首先要求作为提供基础设施服务（云计算平台）的公有云厂商，必须具备不低于应用系统等保定级级别的网络安全等级保护资质，然后再对企业的公有云业务（云租户信息系统）进行等保测评工作。对于自建私有云业务，也是首先需要对云计算平台进行定级和测评，然后再对私有云用户业务系统（云租户信息系统）进行定级测评，同样需要私有云平台的安全保护等级不低于其所支撑的业务系统的最高等级。
 
类似地，混合云环境下的应用系统如果计划申请PIC-DSS认证、需要满足欧盟GDPR数据保护条例等合规或法律要求时，也是需要提供基础架构服务的公有云厂商具备相应的PCI-DSS认证资质、符合GDRP合规要求，同时对私有云基础架构（云计算平台）和用户业务系统（包括公有云和私有云上的云租户信息系统）进行对应的合规性检测。
 
因此混合云环境下，企业需要根据自身合规需要，选择具有对应资质的公有云厂商，同时根据不同合规检查项，对自建私有云平台进行安全自查、安全加固或安全整改，以确保私有云平台和运行的用户业务系统符合合规要求。
 
1.8 云安全产品的选择
 
混合云环境下，许多传统的安全理念、安全产品和安全解决方案已经不再适合，或者说是不能有效解决混合云环境下产生的各类安全风险问题。与此同时，业界对云安全的研究，也促进了不少新的，更加适合云环境的安全理念、安全模型、云原生安全产品和针对性的混合云安全解决方案，比如gartner推荐的多种安全技术，包括多云管理平台，云工作保护平台（CWPP），云访问安全代理（CASB），云安全配置管理（CSPM），零信任安全解决方案（SDP）等等。
 
对于计划或已经采用混合云架构的企业安全管理、安全技术人员，特别是安全架构师而言，需要不断跟进最前沿的云安全技术，熟悉不同的云安全产品功能和特性，以及水平参差不齐的混合云安全解决方案，同时结合企业自身的业务特性、安全目标和实际风险情况，进行测试并谨慎选择合适的云安全服务、云安全产品或混合云安全解决方案，这同样是一件具有很大挑战性和很高风险的任务。
 
02.混合云安全解决方案建议
 
考虑到混合云环境下安全服务、安全技术、安全产品、安全平台、安全合规等安全风险的复杂性，建议企业在规划、构建和实施混合云架构时，可以使用第三方云服务商的安全咨询服务（如新钛云服等），从专业角度帮助企业了解不同公有云厂商、公有云产品和服务、私有云平台选型、私有云安全能力建设以及不同混合云安全解决方案的优缺点、适用场景、实施成本等，以减少混合云选型、落地实施及后续运维运营管理等多方面的安全问题。
 
合理的混合云安全解决方案，仍然应该遵循最基本的安全建设理念，即合理的安全规划，分阶段进行实施，关注和防范重点风险。从实际项目经验来看，我们建议混合云安全解决方案大体可以分四个阶段进行实施：
 
第一阶段：混合云安全架构调研、测试、规划和实施。包括公有云服务商及公有云安全服务的测试和选型，私有云平台选型、私有云安全解决方案的测试和选型，统一的混合云安全管理平台等；
第二阶段： 混合云架构下的基础安全防范和服务能力建设。一般需要包括FW、WAF、CWPP、数据库审计服务或产品、多云管理平台等，以至少覆盖网络层安全、主机/容器安全、应用层安全、数据安全和运维通道的安全管理，从而构建基本的纵深安全防范体系；
 
 
第三阶段：根据企业自身业务特性，加强重点风险防范能力。如针对游戏业务的抗DDOS服务、基于SDK的安全解决方案，针对电商行业的风控平台和数据安全解决方案等，需要重点考虑。
第四阶段：适合企业混合云具体应用特性的安全强化,日常安全运维运营及安全合规工作。如针对SaaS业务的CASB产品，对高安全要求应用考虑实施SDP解决方案，敏感数据自动发现和动态脱敏，统一的安全中心和合规工作等。
 
信息安全本身就是一个不断进化的动态过程，不可能一蹴而就，也不存在百分百的安全保障。如何科学的构建和管理混合云安全，需要更多的风险评估、安全管理、安全研究、安全运营、安全开发等多方经验的总结和交流，也非常欢迎各位就混合云安全涉及到的方方面面多多交流！