标签：style blog c tar http color
当组织把关键信息委托给无法直接控制的、分散在各地的云平台时，安全是其首先要考虑的因素。在SDLC中，将安全贯穿到云软件开发的每个环节，可以在很大程度上降低云被攻击的范围，SDLC中与云安全相关的有信息生命周期管理、应用程序安全、存储，具体见csaguidev3.0
接下来的内容为：
0x01 信息安全目标
0x02 云安全服务
0x03 云安全设计原则
0x04
安全云软件需求
0x05 安全云软件测试
0x06 业务连续性规划
0x01 信息安全目标
软件安全设计原则构成了软件确保的依据：对所期望的软件功能的信任程度，以及不受软件漏洞影响的信任程度
软件必须具备以下3个属性才能认为是安全的：
1. 可靠性 -> 在各种情况下都能正常运行
2. 可信性 ->
能抵御恶意逻辑
3. 可生存性 -> 能抵御或容忍攻击，且有尽可能降低伤害和快速恢复的能力
机密性、完整性和可用性同样是软件确保的重要支撑，其对立面为泄露、变更和破坏
0x02 安全云服务
认证：对用户身份证据进行验证和达成一致的过程
授权：授予用户或进程权限，使其能访问计算机资源和信息资产
审计：分为系统审计和系统监控，前者是单次或周期性事件，后者是一项持续性活动。
审计员需要审计的功能有：(a) 系统和交易控制 (b) 系统开发标准 (c) 备份控制 (d) 数据资料流程 (e) 数据中心安全 (f) 应急计划
可追究性：不仅能辨识出云计算系统中实体的动作和行为，还能辨识其身份
0x03 安全设计原则 [the protection of information in computer systems]
a. 最小特权：为个人、进程或其他类型实体赋予完成一项任务所需的最小特权、资源及时间
b. 权限分离：某个敏感活动的完成或访问有赖于满足多个条件
c. 纵深防御：采用多层安全防护——在多个位置防御、分层防御、部署KMI/PKI、入侵检测系统
d. 故障保护：如果云计算系统发生故障，那它在故障时应处于系统安全状态，其数据不会遭到破坏
e. 机制的经济性：促进防护机制的设计与实现是简单、易于理解的
f. 完全仲裁：系统中主题对客体的每一个访问都必须经过一个正当有效的授权过程
完全仲裁完成如下功能：(1) 标识每一个发出请求的实体 (2) 验证请求自发起后未被修改 (3) 实施恰当授权过程 (4) 重新检查已认证的实体请求
g. 开发设计：将安全设计开放给社区监视和评估，促进发现脆弱性
h. 最小公共机制：尽可能少地采用公共机制为大多数用户服务
i. 心理可接受性：用户在无需解析复杂指令的情况下了解和使用用户界面
j. 最弱链接：系统中的最脆弱部分决定整个系统的安全性
k. 利用现有组件：安全配置、发挥最大功能
0x04 安全云软件需求
SDLC中，有两个阶段安全性需要首先考虑：需求定义阶段和测试阶段，安全代码开发有几个反方面需要予以重视：
1) 数据处理：敏感信息加密处理，最好使用单向加密
2)
代码实践：云服务器中所包含的必要信息要尽可能少
3) 语言选项：不同的编程语言自身具备不同的安全性，要区别对待
4)
输入验证和内容注入：对数据和命令进行区分和隔离
5) 物理安全：服务器隔离防护、确保可用性
4.1 软件需求工程方法
从资源角度来看，云软件安全需求要满足SMART基本属性：
Specific: 需求尽可能详尽
Measurable:
通过分析或测试，可判断需求是否被满足
Appropriate：需求应被验证且确保没有其他需求比它更合适
Reasonable：
当实现一个需求的方法或方法集没确定时应尽可能采取验证手段，确定在现实中需求是否可被满足
Traceable： 需求应独立出来，使其在SDLC中易于跟踪和验证
面向目标的范式可作为实施安全需求工程的另一种补充方法，要解决的目标类型有功能性/非功能性目标、安全健壮性及代码正确性
需求验证人员应从内部和外部两方面对与软件确保相关的信息系统安全策略需求进行分析，确保需求的一致性和正确性
4.2 云安全策略的实现和分解
对于一个高级安全策略需求—服务器应既存储公共访问网页也存储首先网页，应推导出如下活动：
a. 导出细化的功能需求 b. 标识出相关的约束需求 c. 导出功能性安全需求 d. 标识出相关的负面需求
信息安全策略在很大程度上关注定义规则集，通过这些规则集允许主体改变系统中数据对象的状态。在实践中，这意味着每一个系统主体定义其是否可以存储、传输、创建、修改和删除一个给定的数据对象，以及如何存储、传输、创建、修改和删除一个给定的数据对象。，所有系统通用的3个主要目标如下：
a) 安全策略必须运行对系统授权的访问和链接，同时阻止非授权的访问和链接
b)
安全策略必须允许对数据正当的读取、修改、破坏和删除，同时阻止未授权的读写操作
c)
安全策略必须阻止可能包含攻击模式和恶意逻辑的输入内容，防止其威胁到系统依据安全策略运行及保护信息的能力
信息系统安全策略需要处理机密性、完整性、可用性、标识、认证、授权和审计等关键问题，这些关键问题可以分解为对应的安全软件需求
0x05 安全云软件测试
5.1 安全质量确保性测试
ISO 9126使用6个主要属性及21个子特性给出了软件质量的特性描述，6个主要属性为：
a) 功能性 b) 可靠性 c) 可用性 d) 有效性 e) 可维护性 f) 可移植性
1. 一致性测试：评估某个软件产品是否满足某个特定的规范或标准的需求，可促进不同云计算产品间的互操作性
2. 功能测试：测试云软件是否满足了它的功能性需求并指出软件不应做什么，另外还需要进行逻辑测试，确保在正确假设条件下业务逻辑是可预期的
3. 性能测试：根据标准数据集或场景运行一个软件元素，对吞吐率、处理延时、负载等度量值进行测试得出一个数值
4. 安全测试：验证云软件能否展现出如下属性和行为>>
a) 软件的行为是可预期、安全的
b) 软件没有漏洞和缺陷
c)
软件的错误和异常处理机制使其在面对攻击模式和随机故障时仍能保持一个安全状态
d) 软件能满足其所有指定的与隐含的非功能性安全需求
e)
软件没有违背任何指定的安全约束
f) 尽可能将运行时可译源代码与字节代码混淆以阻止逆向工程
常见安全测试技术有如下几类：
a) 故障注入：将错误注入到软件中模拟无意识的用户错误和有意识地攻击，主要分为源代码故障注入和二进制故障注入
1.源代码故障注入：又称故障传播分析，测试人员可以决定什么时候触发环境故障，主要包括扩展传播分析和接口传播分析。扩展传播分析中，测试人员先将源代码生成故障树，然后将故障注入到故障树中，跟踪每一次的故障，看起如何传播，这可以展现出一个故障如何影响软件的整体行为。接口传播分析中，测试者在组件间的数据输入中注入一个故障，查看导致的故障如何传播，观测是否出现新的异常，下列几种情况源代码故障注入十分有用：Ⅰ) 指针和数组的不正确使用 Ⅱ) 使用危险调用 Ⅲ) 竞争条件
b) 二进制故障注入：软件运行时，使用二进制故障注入可对注入的云应用执行情况进行监控，识别出系统调用的名称、参数、返回值。注入工具包括注入器和暴力测试器
c) 动态代码分析：对软件进行操作，从而暴露由于与用户交互、配置文件改变等行为所引发的漏洞 [动态分析工具：http://valgrind.org/info/tools.html]
d) 基于属性的测试：通过检测源代码所透露出的安全相关属性，验证软件所实现的功能是否满足它的规约
e) 互操作性测试：用于评估一个云计算应用是否能与其他觅或应用程序交换数据，测试发那个发有3个：(1) 测试所有节点 (2) 测试某些组合 (3) 利用参考实现进行测试
**云软件组件集成的一个难点在于如何在个体可能不安全的组件集成的基础上构建一个安全的复合系统**
**[analyzing security interoperability during component integration]**
5.2 云渗透测试
渗透测试是整个安全审计的一部分，包括如下几项：
1. 高层评估 ——>
自顶向下地检测组织的策略、流程、标准和指南，作为第一级评估，不会对系统安全性进行实际测试
2. 网络评估 ——>
除了包含第一级评估的一些活动外。还加上更多的信息收集和扫描
3. 渗透测试 ——> 不关注策略，从攻击者角度出发，更关注于破坏
渗透测试通常从信息侦查开始，由3个测试前的阶段组成：踩点、扫描、枚举，在这个过程中依照如下7个步骤：
(1) 收集初始化信息 (2) 判断网络范围 (3) 识别活动主机 (4) 发现开放端口和访问点AP (5) 操作系统踩点 (6) 发现端口上的服务 (7) 得出网络拓扑图
渗透测试过程的工具及技术：
VisualRoute、SmartWhois、SamSpade [追捕垃圾邮件制造者、提供目标相关信息]
端口扫描 —> Nmap、SATAN、VeteScan、SARA、PortScanner、CGI Port Scanner、CGI Sonar [Linux]
密码破解 —> Brutus、WebCracker、ObiWan、Burp Intruder
缓冲区溢出 —> 三种常用测试缓冲区溢出漏洞的方法：(1) 在函数和方法中查找声明为本地变量的字符串，在源代码中验证是否有边界检查 (2) 检查输入输出或字符串函数 的不当引用 (3) 应用大量数据对应用程序测试，检查异常行为 [StackGuard\ProPolice\Proventia]
...balabala...
5.3 回归测试
选择性地对系统或组件技进行测试，验证对软件的修改没有产生意想不到的后果。
故障再次出现的原因包括：(1) 版本控制实施较差 (2) 软件的脆弱性 (3) 重复的错误
0x06 业务连续性规划
业务连续性规划(Business Continuity Planning)和灾难恢复规划(Disaster Recovery Planning)用于防止因主要系统和网络故障所导致的关键业务流程中断，包括计划的准 备、测试、更新等活动。从云计算角度来说，这些业务流程严重依赖于基于云的应用与软件的健壮性和安全性
对于灾难，云服务提供商能解决的特定领域如下：
a) 避免组织出现主要计算机服务故障
b) 在中断时提供扩展的备份操作
c)
提供在备用场所实现关键流程的能力
d) 通过测试和模拟分析确保备用系统的可用性
e)
通过执行快速回复流程，快速回归主系统，尽量减少业务损失
f) 灾难发生时尽可能减少需要人员参与的决策支持
g)
灾难发生时提供一种有条理的决策方案
a) 降低组织延迟交付服务的风险
6.1 目标和实践
灾难恢复的主要目标是提供以下能力：(1) 在备份站点上实现关键业务流程 (2) 执行快速恢复流程减小损失
灾难恢复应涉及的信息处理领域：
(1) 使用的云资源 (2) 局域网、广域网和服务器 (3) 电信连接和数据通信链接 (4)
工作站和工作空间
(5) 应用程序、软件和数据 (6) 介质和记录存储 (7) 员工职责和生产流程
规划过后，还要对灾难恢复规划进行测试，主要原因：
a. 表明组织在回复能力方面的管理
b. 验证恢复流程的精确性，找出差距
c.
招收培训和相关人员完成应急响应工作
d. 验证后备站点或云提供商的处理能力
测试过程一定不能干扰正常业务功能，其次应从最简单的情况做起，逐渐达到实际仿真程度
/***业务连续性规划：
范围和规划启动 —> 创建范围和其他基本信息，以供定义规划参数所需
业务影响评估
—> 帮助业务单元了解灾难事件的影响
业务持续性规划制定
规划批准和实施 ***/
使用云进行BCP/DRP: (1) 通过云提供冗余 (2) 安全远程接入 (3) 集成到常规业务流程
参考：Cloud Security：A Comprehensive Guide to Secure Cloud CoMputing
标签：style blog c tar http color
原文地址：http://www.cnblogs.com/r00tgrok/p/3734044.html
