您现在的位置： 
ASP 的安全策略
ASP 为什么需要安全策略？
在 ASP 的安全管理过程中，必须有一个通道来及时地传递任何一个给定点的现有状态。安全策略充当了这一角色。它们是对 ASP 一贯使用的当前安全要求和指导方针以及步骤的书面表示。一致的策略将使 ASP 内部清楚在安全方面必须做什么。如果 ASP 要看到在安全状态上的迅速改进，则建立安全策略是评估之后的逻辑步骤，并且应当启动而作为安全规划的一个辅助因素。
当安全管理的规划展开时，环境中的特定因素将会改变。出现变化时，策略将被检查并修改，以确保它们传递的是保护 ASP 环境的当前规划。在六到十二个月之间必须至少对安全策略检查一次，当然每当由于各种原因需要对策略进行更改时也要如此。因此，安全策略是一项持续进行的工作。
开发 ASP 安全策略的步骤
下列步骤是定义安全策略中的基本步骤。
了解安全策略由什么组成。
安全策略定义 ASP 如何管理、保护和分配敏感的信息和资源
在连接到 Internet 之前，任何 ASP 都应当开发出一个策略，其中要明确地指定将使用的解决方案以及如何使用这些解决方案
该策略应当明确、简洁并易于理解，同时有更改策略的内置机制（灵活性）
默认策略：除非明确允许，否则不使用它
理解安全策略必须要遵守什么要求。
在“服务级别协议”中定义的外部客户要求
涉及安全性的外部法律要求
外部供应商安全策略
内部 ASP 安全策略
在 ASP 和客户环境的集成情况下，内部/外部的安全策略
理解应如何考虑安全策略；确定要保护什么。
计算机资源
关键系统
敏感系统
客户和公司数据
关键数据
敏感数据
公用数据
确定安全策略指导方针。
开发一个双级别的策略
高级别策略
从客户的角度编写
保持简单
避免技术术语并包含对它的解释
低级别策略
为实施者而编写
有关如何执行的详细技术说明
包括筛选规则等
安全策略必须以 ASP 客户的实际条件为基础；它应当明确、一致、简洁和易于理解。
提供定期检查和检验
ASP 服务的管理
客户关系管理
客户关系管理的内容是发展及培养客户和 ASP 之间良好的职业工作关系。客户关系管理人员必须介入 MOF 的所有其它层面。例如，客户关系管理人员在 SLA 协商期间促进 ASP 与客户之间的互动，并参与解决客户对所提供服务的不满。如果客户关系管理人员提供给客户的解决方案确实安全，那么这对客户关系管理人员而言就是一个卖点。
与客户的沟通是 CRM 进行安全管理的的主要方面。
服务管理
在安全管理过程中采取的所有操作都取决于“服务级别协议”中协商一致的服务级别。“服务等级管理”确保指定并实现有关提供给客户的服务方面的协议。目的是创建最优的 IT 服务，使得客户对 IT 服务的期望和要求都能得到满足，并且能为 ASP 和客户双方调整相关的成本。
因此 SLA 还必须包括一段内容，规定有关要采取的安全措施的协议（参见附录中有关安全部分的框架）。从安全的角度来看，对于“服务等级管理”，需要检查某些活动。
对客户的安全要求和期望的认定。
对客户的这些安全要求和期望的可行性验证。
对建议和 IT 服务所需安全级别记录的协商。
确定、起草和建立 IT 服务的安全标准。
监视这些安全标准。
报告所提供服务在安全方面的有效性和状态。
获得安全方面的反馈和评估。
有关 CRM 和“服务管理”之间关系方面的详细信息，请参见 ITIL Library： http://www.itil.co.uk/
更改管理
管理更改是维护系统正常运行和完整性的重要方面。更改控制过程提供了批准更改并对请求的更改进行全面考虑的机会。这种分析可实现安全风险的评估。
已定义的更改和目的
对于所要进行的工作或要实现的更改，应当完成其成文的定义。这应包括更改的目的、更改将产生的结果以及预计对其它系统产生的影响。安全过程将通过该定义来确定安全的效果。
风险评估
对于将要进行的更改，需要完成有关的风险评估。此安全风险评估的范围可以从无风险到高风险。作为风险评估的一部分，安全风险也需要进行评估，并需确定其对 ASP 业务的影响。
批准过程
安全管理员负责批准更改的安全考虑事项。没有他的批准，更改将被拒绝（除非定义了可以满足应急条件的附加安全对策）。
验证更改的步骤
需要用有关步骤的信息来验证进行的更改是否具有所需的安全性。实施更改后，应当执行该步骤，并根据预先定义的结果采取措施。
安全事件管理
“安全事件管理”是常规“事件管理”的一个特殊部分。最重要的是 ASP 有一个安全事件的主要联系位置。这意味着必须要有一个位置，所有的安全事件都在该位置注册，而且所有的 ASP 雇员和客户（在必要情况下）都必须知道此位置，这样他们可在该位置处理安全事件。必须要有一个针对安全事件的步骤，使人明白当宣称出现安全事件出现时究竟发生了什么情况。
事件控制员必须有一个任务报告脚本，其中描述安全事件问题。依照此任务报告脚本，事件控制员将得出结论：这是安全事件、不是安全事件或者他不能断定该事件。在肯定或不能断定安全事件的情况下，必须执行安全事件进程和步骤。涉及安全事件时，不要冒险。对安全事件进程和步骤的说明需要安全管理和事件管理的共同努力。
发现事件后需要采取的步骤为：
注册；需要对基本的事件细节进行注册，并根据需要向专家组发出警报。
分类和初始支持；有必要获得来自最新的“配置管理数据库”(CMDB) 的信息，以确定正在发生的是何种类型的安全事件。还将执行对上次事件信息的检查。
调查和诊断；如果较早的检查没有提供所需的信息，则开始对更新后的安全事件细节和配置细节进行更严格的调查，以确定这是什么类型的安全事件。开始诊断，并且必须制定出明确的解决方案。
解决和恢复；此时必须要有一个解决方案。当解决安全事件需要进行任何更改时，“更改过程”必须对更改请求作出紧急响应。
事件结束；此时初始事件已经得到解决。有关该事件的信息已经正确地记录下来，以备在该安全事件可能再次出现时使用。
此“安全事件管理过程”中涉及的人员（突发事件管理员、安全管理员、事件控制员、支持人员）必须都明白出现安全事件时需要如何去做。他们还必须意识到可用于解决安全事件的时限。在 ASP 和客户规定的 SLA 中有这些时限（服务级别）的说明。
应急规划
“应急规划”过程负责制定灾难恢复计划。但是从安全的角度来看，ASP 希望确保出现灾难时采取准确的行动。因此，需要定义一些内容，如应急规划的安全方面、ASP 或客户组织中有可能被灾难摧毁的部分、组织中不允许被灾难摧毁的部分（因为这将意味着该组织不再存在）。SLA 对此有何规定？
该过程中关键是对应急过程中所涉及的所有员工进行培训。危机当中，几乎没有时间作出决定，因此大家必须如熟悉日常工作一样熟悉应急过程。
有关 ASP 应急规划的白皮书更深入地介绍了如何管理应急过程。
ASP 为什么需要安全策略？
在 ASP 的安全管理过程中，必须有一个通道来及时地传递任何一个给定点的现有状态。安全策略充当了这一角色。它们是对 ASP 一贯使用的当前安全要求和指导方针以及步骤的书面表示。一致的策略将使 ASP 内部清楚在安全方面必须做什么。如果 ASP 要看到在安全状态上的迅速改进，则建立安全策略是评估之后的逻辑步骤，并且应当启动而作为安全规划的一个辅助因素。
当安全管理的规划展开时，环境中的特定因素将会改变。出现变化时，策略将被检查并修改，以确保它们传递的是保护 ASP 环境的当前规划。在六到十二个月之间必须至少对安全策略检查一次，当然每当由于各种原因需要对策略进行更改时也要如此。因此，安全策略是一项持续进行的工作。
开发 ASP 安全策略的步骤
下列步骤是定义安全策略中的基本步骤。
了解安全策略由什么组成。
安全策略定义 ASP 如何管理、保护和分配敏感的信息和资源
在连接到 Internet 之前，任何 ASP 都应当开发出一个策略，其中要明确地指定将使用的解决方案以及如何使用这些解决方案
该策略应当明确、简洁并易于理解，同时有更改策略的内置机制（灵活性）
默认策略：除非明确允许，否则不使用它
理解安全策略必须要遵守什么要求。
在“服务级别协议”中定义的外部客户要求
涉及安全性的外部法律要求
外部供应商安全策略
内部 ASP 安全策略
在 ASP 和客户环境的集成情况下，内部/外部的安全策略
理解应如何考虑安全策略；确定要保护什么。
计算机资源
关键系统
敏感系统
客户和公司数据
关键数据
敏感数据
公用数据
确定安全策略指导方针。
开发一个双级别的策略
高级别策略
从客户的角度编写
保持简单
避免技术术语并包含对它的解释
低级别策略
为实施者而编写
有关如何执行的详细技术说明
包括筛选规则等
安全策略必须以 ASP 客户的实际条件为基础；它应当明确、一致、简洁和易于理解。
提供定期检查和检验
ASP 服务的管理
客户关系管理
客户关系管理的内容是发展及培养客户和 ASP 之间良好的职业工作关系。客户关系管理人员必须介入 MOF 的所有其它层面。例如，客户关系管理人员在 SLA 协商期间促进 ASP 与客户之间的互动，并参与解决客户对所提供服务的不满。如果客户关系管理人员提供给客户的解决方案确实安全，那么这对客户关系管理人员而言就是一个卖点。
与客户的沟通是 CRM 进行安全管理的的主要方面。
服务管理
在安全管理过程中采取的所有操作都取决于“服务级别协议”中协商一致的服务级别。“服务等级管理”确保指定并实现有关提供给客户的服务方面的协议。目的是创建最优的 IT 服务，使得客户对 IT 服务的期望和要求都能得到满足，并且能为 ASP 和客户双方调整相关的成本。
因此 SLA 还必须包括一段内容，规定有关要采取的安全措施的协议（参见附录中有关安全部分的框架）。从安全的角度来看，对于“服务等级管理”，需要检查某些活动。
对客户的安全要求和期望的认定。
对客户的这些安全要求和期望的可行性验证。
对建议和 IT 服务所需安全级别记录的协商。
确定、起草和建立 IT 服务的安全标准。
监视这些安全标准。
报告所提供服务在安全方面的有效性和状态。
获得安全方面的反馈和评估。
有关 CRM 和“服务管理”之间关系方面的详细信息，请参见 ITIL Library： http://www.itil.co.uk/
更改管理
管理更改是维护系统正常运行和完整性的重要方面。更改控制过程提供了批准更改并对请求的更改进行全面考虑的机会。这种分析可实现安全风险的评估。
已定义的更改和目的
对于所要进行的工作或要实现的更改，应当完成其成文的定义。这应包括更改的目的、更改将产生的结果以及预计对其它系统产生的影响。安全过程将通过该定义来确定安全的效果。
风险评估
对于将要进行的更改，需要完成有关的风险评估。此安全风险评估的范围可以从无风险到高风险。作为风险评估的一部分，安全风险也需要进行评估，并需确定其对 ASP 业务的影响。
批准过程
安全管理员负责批准更改的安全考虑事项。没有他的批准，更改将被拒绝（除非定义了可以满足应急条件的附加安全对策）。
验证更改的步骤
需要用有关步骤的信息来验证进行的更改是否具有所需的安全性。实施更改后，应当执行该步骤，并根据预先定义的结果采取措施。
安全事件管理
“安全事件管理”是常规“事件管理”的一个特殊部分。最重要的是 ASP 有一个安全事件的主要联系位置。这意味着必须要有一个位置，所有的安全事件都在该位置注册，而且所有的 ASP 雇员和客户（在必要情况下）都必须知道此位置，这样他们可在该位置处理安全事件。必须要有一个针对安全事件的步骤，使人明白当宣称出现安全事件出现时究竟发生了什么情况。
事件控制员必须有一个任务报告脚本，其中描述安全事件问题。依照此任务报告脚本，事件控制员将得出结论：这是安全事件、不是安全事件或者他不能断定该事件。在肯定或不能断定安全事件的情况下，必须执行安全事件进程和步骤。涉及安全事件时，不要冒险。对安全事件进程和步骤的说明需要安全管理和事件管理的共同努力。
发现事件后需要采取的步骤为：
注册；需要对基本的事件细节进行注册，并根据需要向专家组发出警报。
分类和初始支持；有必要获得来自最新的“配置管理数据库”(CMDB) 的信息，以确定正在发生的是何种类型的安全事件。还将执行对上次事件信息的检查。
调查和诊断；如果较早的检查没有提供所需的信息，则开始对更新后的安全事件细节和配置细节进行更严格的调查，以确定这是什么类型的安全事件。开始诊断，并且必须制定出明确的解决方案。
解决和恢复；此时必须要有一个解决方案。当解决安全事件需要进行任何更改时，“更改过程”必须对更改请求作出紧急响应。
事件结束；此时初始事件已经得到解决。有关该事件的信息已经正确地记录下来，以备在该安全事件可能再次出现时使用。
此“安全事件管理过程”中涉及的人员（突发事件管理员、安全管理员、事件控制员、支持人员）必须都明白出现安全事件时需要如何去做。他们还必须意识到可用于解决安全事件的时限。在 ASP 和客户规定的 SLA 中有这些时限（服务级别）的说明。
应急规划
“应急规划”过程负责制定灾难恢复计划。但是从安全的角度来看，ASP 希望确保出现灾难时采取准确的行动。因此，需要定义一些内容，如应急规划的安全方面、ASP 或客户组织中有可能被灾难摧毁的部分、组织中不允许被灾难摧毁的部分（因为这将意味着该组织不再存在）。SLA 对此有何规定？
该过程中关键是对应急过程中所涉及的所有员工进行培训。危机当中，几乎没有时间作出决定，因此大家必须如熟悉日常工作一样熟悉应急过程。
有关 ASP 应急规划的白皮书更深入地介绍了如何管理应急过程。
