服务器日常安全运维管理手册培训课件.docx
《服务器日常安全运维管理手册培训课件.docx》由会员分享，可在线阅读，更多相关《服务器日常安全运维管理手册培训课件.docx（58页珍藏版）》请在冰豆网上搜索。
服务器日常安全运维管理手册培训课件
安全日常运维管理
河北连益成信息技术有限公司
编写人
陈磊
时间
2014-12-2
版本
Version1.0
第一章安全运维管理体系分析
1.1安全日常运维管理的必要性
IT系统是否能够正常运行直接关系到业务或生产是否能够正常运行。
但IT管理人员经常面临的问题是：
网络变慢了、设备发生故障、应用系统运行效率很低。
IT系统的任何故障如果没有及时得到妥善处理都将会导致很大的影响，甚至会造成可怕的经济损失。
但是什么原因导致IT系统屡出问题？
是产品、技术、还是缺乏有效的、系统化的安全运维管理？
随着电信IT系统的发展，业务应用的持续增加，其IT基础设施的架构越来越复杂，单纯凭某个工具或某个人不可能有效地保护自己的整体网络安全;信息安全作为一个整体，需要把安全过程中的有关各层次的安全产品、分支机构、运营网络、管理维护制度等纳入一个紧密的统一安全管理平台（系统）中，才能有效地保障企业的网络和信息安全。
IT环境的复杂性，使更多的安全威胁被揭示出来。
很多企业尝试通过部署“最佳”安全产品来保护自己，比如防病毒网关、防火墙、入侵防护系统、VPN、访问控制、身份认证等。
在这种极度复杂的情况下，需要的是一个集成的解决方案，使得企业能够收集、关联和管理来自异类源的大量安全事件，实时监控和做出响应，需要的是能够轻松适应环境增长和变化的管理体系，需要的就是企业完整的安全管理平台解决方案。
总而言之，对于企业安全运维管理来说，三分技术，七分管理，在企业内部建立一套完善的安全管理规章制度，使管理机构依据相应的管理制度和管理流程对日常操作、运行维护、审计监督、文档管理等进行统一管理，同时加强对工作人员的安全知识和安全操作培训，建立统一的安全管理体系，帮助企业识别、管理和减少信息通常所面临的各种威胁，架构企业的安全保障体系。
1.2安全运维管理的技术支撑体系
1.3PPDRR模型包括策略（Policy）、防护（Protection）、检测（Detection）、响应（Response）和恢复（Recovery）5个主要部分，其中，防护、检测、响应和恢复构成一个完整的、动态的安全循环，在安全策略的指导下共同实现安全保障信息安全的重要理论模型包括信息安全的概念范畴、信息安全保障体系的结构框架、信息安全的三维结构和PPDRR模型
1.制定网络和系统层面的整体安全技术保护方案和技术规范；
2.逐步实现安全自评估，全面掌握安全风险；
3.提供重大安全预警信息发布和解决方案；
4.协调响应网络层面的各类重大安全事件；
5.对各类安全事件有关数据进行综合分析，形成安全运行分析报告；
6.对生产层面的安全策略进行集中控制；
7.跟踪研究各种安全问题和技术，收集各种基础信息资源。
8.进行7×24小时的日常安全安全事件监测，负责受理安全投诉。
9.对安全事件进行收集汇总，进行事件预处理。
10.系统日常口令维护，加载安全补丁和梳理服务端口等
11.实施各类安全设备和配套管理设备的日常维护。
12.实施一般安全预警和安全应急事件的处理。
13.落实系统自身安全应急预案，并参加安全应急演练
1.3安全运维管理遵循的PDCA周期
1.4安全日常运维管理的目标
安全工作的目的就是为了在安全法律、法规、政策的支持与指导下，通过采用合适的安全技术与安全管理措施，完成下述网络与信息安全的保障任务。
Ø进不来：
使用访问控制机制，阻止非授权用户进入网络，从而保证网络系统的可用性
Ø拿不走：
使用授权机制，实现对用户的权限控制，即不该拿走的“拿不走”，同时结合内容审计机制，实现对网络资源及信息的可控性。
Ø看不懂：
使用加密机制，确保信息不泄漏给未授权的实体或进程，即“看不懂”，从而实现信息的保密性
Ø改不了：
使用数据完整性鉴别机制，保证只有得到允许的人才能修改数据，而其它人“改不了”，从而确保信息的完整性。
Ø跑不了：
使用审计、监控、防抵赖等安全机制，使得攻击者、破坏者、抵赖者“走不脱”，并进一步对网络出现的安全问题提供调查依据和手段，实现信息安全的可审查性。
为保障IT系统的正常运行，应能做到如下所示
总结：
安全日常运维管理可总结为高效管理能力、全面运维能力、安全保护能力、隐患发现能力、应急响应能力、快速恢复能力
第二章帐户口令管理
为什么有这么多人钟情于窃取帐号口令？
攻击者窃取帐号有着非法的目的、意图，恶意毁坏操作等行为，他们或以出名，或以炫耀技术为目的。
而目前，窃取帐号的行为都与窃取商业机密和机密信息、数据、经济利益相关，大都有着利益化的倾向犯罪行为。
帐号衩窃取的常见原因
2.1职责定义
2.2口令账号五个保密等级
2.2.1【最低等级】等级一
只有基本的甚至没有保障措施，用于电子系统的帐号。
在第一等级的保障的情况下，只有基本的甚至没有保障措施用于电子系统的帐号，等级一的情况下，错误的口令、帐号和权限管理可能导致给公司、客户或者第三方带来最小的不便。
不会给公司、客户或者第三方带来直接的经济损失
不会给公司、客户或者第三方带来不快
不会给公司、客户或者第三方带来名誉或者地位的损失
不会破坏公司、客户或者第三方需要执行的商业措施或者交易
不会导致民事或者刑事犯罪
不会向XX的组织或个人暴露个人、公司、政府、商业的敏感信息
未验收和未投入使用的系统，工程过程中的系统（假设没有涉及知识产权，例如软件代码泄密的问题的情况下）
2.2.2【低等级】等级二
通过常用的措施即可保护系统的可信认证，必须充分考虑代价和认证安全性的平衡
这种等级的认证被误用或者破坏可能导致：
给公司、客户或者第三方带来较小的不便
给公司、客户或者第三方带来较小直接的经济损失或者没有直接经济损失
会给公司、客户或者第三方带来较小的不快
会给公司、客户或者第三方带来较小名誉或者地位的损失
存在一定的风险，可能破坏公司、客户或者第三方需要执行的商业措施或者交易不会导致民事或者刑事犯罪。
存在一定风险，可能少量向XX的组织或个人暴露个人、公司、政府、商业的敏感信息
举例：
一台常用办公电脑，该电脑上没有存储任何机密文件，他的帐号被窃取可能导致公司常用信息例如通讯录被泄漏。
一个有查询系统的帐号，用户可以通过Internet注册来查询自己的帐单。
该帐号失窃可能导致用户信息的泄漏。
2.2.3【中等级】等级三
如果该级别的帐号被破坏，攻击者往往可以通过这种系统作为中转，进而对部分关键的系统主机进行破坏。
这种级别的帐号口令虽然不是直接的业务系统或者数据库的帐号，但是，如果该级别的帐号被破坏，攻击者往往可以通过这种系统作为中转，进而对部分关键的系统主机进行破坏，该等级被误用的主要风险有：
通过中转可能给公司、客户或者第三方带来较大的不便
通过中转有可能给公司、客户或者第三方带来较大直接的经济损失或没有直接经济损失
通过中转会给公司、客户或者第三方带来较大的不快
通过中转会给公司、客户或者第三方带来较大名誉或者地位的损失
存在一定的风险，会破坏公司、客户或者第三方需要执行的商业措施或者交易
可能会导致民事或者刑事犯罪
存在一定风险，可能大量向XX的组织或个人暴露个人、公司、政府、商业的敏感信息
举例：
维护终端的用户帐号，由于一些业务系统会对终端做特定限制，维护终端被破坏后，导致攻击者可以进一步破坏业务系统，重要的可信网络设备的帐号等。
2.2.4【坚固级】等级四
通常等级四意味着正式的业务流程使用的帐号，通常需要较高信心来保证身份的认证和正确的授权。
通常等级四意味着正式的业务流程使用的帐号，通常需要较高信心来保证身份的认证和正确的授权，这种等级的认证被误用或者破坏可能导致：
给公司、客户或者第三方带来较大的不便
给公司、客户或者第三方带来较大直接的经济损失或者没有直接经济损失
会给公司、客户或者第三方带来较大的不快
会给公司、客户或者第三方带来较大名誉或者地位的损失
存在较大的风险，会破坏公司、客户或者第三方需要执行的商业措施或者交易
会导致民事或者刑事犯罪
存在较大风险，可能大量向XX的组织或个人暴露个人、公司、政府、商业的敏感信息
举例：
一般的主机操作系统、数据库、和路由器的高权限帐号，例如root、administrator、dba等。
业务系统的关键管理帐号，可以读写重要的用户信息、业务信息和帐单信息。
2.2.5【最高级】等级五
等级五的保障通常对应需要非常大的信心保障的系统。
等级五的保障通常对应需要非常大的信心保障的系统这种等级的认证被误用或者破坏可能导致：
给所有公司、客户或者第三方带来巨大的不便
给公司、客户或者第三方带来极大直接的经济损失或者没有直接经济损失
会给公司、客户或者第三方带来极大的不快
会给公司、客户或者第三方带来巨大名誉或者地位的损失
破坏公司、客户或者第三方需要执行的商业措施或者交易
会导致民事或者刑事犯罪
大量向XX的组织或个人暴露个人、公司、政府、商业的敏感信息
举例：
关键系统，例如计费系统数据库主机的操作系统和数据库。
用于存储公司最高商业机密或密级为绝密的系统的认证。
2.3账号管理
2.3.1账号角色分配目的
（一）加强网络与信息安全管理，明确各级系统用户权的职责。
（二）根据业务系统的要求及网络信息管理规范，进一步完善各级用户在系统中的职能划分与角色定位。
（三）强化系统帐户和密码的管理，降低帐户和密码泄漏对系统和数据安全产生的影响，确保各相关信息报告系统安全、有效运行。
系统管理员和超级用户是有权限对系统的配置、系统最核心信息进行更改的帐号和角色，
普通帐号是用户用于访问业务系统，实现日常业务操作的用户，是最为常见的用户类型，
第三方帐号通常指由于某种特殊情况，系统允许移动以外的人员和组织访问的帐号。
在核心系统中，应该设置安全审计员帐号，该帐号可以对系统安全设置和日志信息进行专门的审计。
2.3.2建立的原则
（1）不同类型用户的建立应遵循满足其工作需要的原则，而用户的权限分配则应以保障网络与信息的高效、准确、安全为原则。
（2）用户的权限分配应尽量使用系统提供的角色划分。
如需特殊的操作权限，应在准确理解其各项操作内容的基础上，尽量避免和减少权限相互抵触、交叉及嵌套情况的发生，经测试成功后，再创建相应的角色赋予本级用户或直报用户。
（3）通过对用户进行角色划分，分配审计账号、用户权限，合理限制对其他角色用户、数据的修改权限，将审查数据与配置数据相对剥离，即原始配置数据与统计查看查看信息分开。
（4）系统内所有涉及查看数据的帐户信息均必须采用真实信息，即有查询机制确认审计人员信息准确。
2.3.3账号建立的过程
帐号管理贯穿帐号创建、授权、权限变更及帐号撤销或者冻结全过程
Ø帐号设置应与岗位职责相容；
Ø坚持最小授权原则，避免超出工作职责的过度授权；
Ø应制定严格的审批和授权流程，规范帐号申请、修改、删除等工作，授权审批记录应编号、留档（表格命名规则及格式参见附件，各省公司可重新制定相关表格）；
Ø帐号创建、调整和删除申请审批通过后，应及时更新系统中的帐号状态，确保与审批结论保持一致；
Ø原则上，除低权限的查询帐号外，各系统不允许存在其它共享帐号，必须明确每个帐号责任人，不得以部门或用户组作为最终责任人。
Ø在完成特定任务后，系统管理员应立即收回临时帐号。
帐号创建、变更、删除审批流程
超级帐号由主管领导以授权的方式授予具体的系统管理员，授权书至少应包括系统名称、超级帐号名、授予人姓名、职责描述、有效期等；
所有帐号，包括系统管理员帐号、普通帐号、程序帐号的责任人，应按规定的申请表格式要求提出申请，申请表至少包含申请人姓名、联系方式、申请人职责描述、申请时间、申请目的、申请帐号所属系统名称、帐号类型、创建或者变更或者删除操作类型、帐号权限描述、主管领导审批意见、系统管理员变更操作记录及签字确认、权责描述备注栏目等；
主管领导进行审批，重点检查所申请权限与申请人职责的一致性；
系统管理员负责创建、变更或者删除帐号，保留审批表格、并备案。
如因系统能力或者管理原因无法按用户创建帐号时，应采取如下管理措施：
Ø明确共享帐号责任人，责任人负责按照上述流程要求提出共享帐号审批表，并在审批表中注明该共享帐号的所有用户名单；
Ø限制共享帐号的使用人数，建立相关管理制度保证系统的每项操作均可以对应到执行操作的具体人员；
Ø限定使用范围和使用环境；
Ø建立完善的操作记录制度，对交接班记录、重要操作记录表等等；
Ø定期更新共享帐号密码。
Ø对于程序运行或者程序自身由于管理需要访问其它系统所使用的专用帐号，应符合如下要求：
Ø只允许系统和设备之间通信使用，不得作为用户登录帐号使用；
Ø将此类帐号的维护管理权限统一授权给该系统的系统管理员，由后者归口管理；
2.4口令管理
2.4.1口令管理原则
Ø口令至少由6位及以上大小写字母、数字及特殊符号等混合、随机组成，尽量不要以姓名、电话号码以及出生日期等作为口令或者口令的组成部分。
Ø应以HASH或者加密技术保存口令，不得以明文方式保存或者传输；
Ø口令至少每90天更换一次。
修改口令时，须保留口令修改记录，包含帐号、修改时间、修改原因等，以备审计；
Ø5次以内不得设置相同的口令；
Ø由于员工离职等原因，原帐号不能删除或者需要重新赋予另一个人时，应修改相应帐号的口令。
Ø如系统能力支持，应开启并设置自动拒绝不符合上述口令管理规则帐号和口令的参数；
Ø对于无法建立口令规则强制检查的系统，帐号用户应在每次口令修改后留有记录。
Ø对于无法进行定期修改口令的帐号，如内置帐号、专用帐号等，由系统管理员负责在系统升级或重启时督促落实口令修改工作，负责督促落实调用该帐号的程序与所访问系统两侧的口令同步工作。
当发生下述情况时，应立即撤销帐号或更改帐号口令，并做好记录：
Ø帐号使用者由于岗位职责变动、离职等原因，不再需要原有访问权限时；
Ø临时性或阶段性使用的帐号，在工作结束后；
Ø帐号使用者违反了有关口令管理规定；
有迹象，表明口令可能已经泄露等。
2.4.2口令设置原则
Ø口令必须具有足够的长度和复杂度，使口令难于被猜测
Ø口令在一定时间或次数内不能循环使用
Ø不同帐号的口令应当不同，并且没有直接联系，以保证不可由一个帐号的口令推知其它帐号的口令
Ø同一帐号前后两个口令之间的相同部分应当尽量减少，减低由前一个口令分析出后一个口令的机会
Ø口令不应当取过于简单的字符串，如电话号码、使用者的姓名、宠物、生日或其倒序，6位字符都相同、6位连续字符等易于猜测的信息
Ø开户时设定的初始口令必须是随机产生的口令，而不能是相同或者有规律的口令
Ø所有系统管理员级别的口令（例如root、enable、NTadministrator、DBA等）在没有使用增强口令的情况下，必需按照较短周期进行更改，例如每三个月更换一次。
应该注意关键性帐号信息的定期行备份。
Ø用户所使用的任何具备系统超级用户权限（包括并不限于系统管理员帐号和有sodu权限帐号）帐号口令必需和这个用户其他帐号的口令均不相同。
Ø如果有双要素认证机制，则以上的要求和下面关于强口令选择的要求可以不考虑。
Ø口令不能在电子邮件或者其他电子方式下以明文方式传输。
Ø当使用SNMP时，communicationstring不允许使用缺省的Public、Private和system等，并且该communicationstring不应该和系统的其他口令相同，应该尽量使用SNMPv2以上的版本。
2.4.3口令设置最低标准
Ø如果技术上支持，口令至少要有6位长
Ø口令必须是字母和非字母的组合
Ø口令第1位和最后1位至少应包含1个非数字字符
Ø与前次口令比较，在任何位置不能有超过3个字符连续相同
Ø口令不能包含超过2个连续相同的字符
Ø用户名不能作为口令一部分
Ø与前4次相同的口令不能重复使用
Ø口令不能被共享除非每个口令的行为都能被区分
Ø对于级别要求很高的系统，普通用户口令要求8位以上
Ø管理员/超级用户帐号最近20个口令不可重复，口令的长度不可小于7位，口令中必须包含大写字母、小写字母和数字中的两类，口令中同一个符号不得多于2次，且不得有1个以上的字符出现两次，前后2个口令中相同位置的字符相同的不得多于2个；口令不得有明显的意义修改
Ø帐号的使用人应当定期修改帐号口令，修改口令的间隔应小于本标准的相关规定，对于本标准没有规定的用户，其间隔应当小于6个月
Ø不同用户的修改口令的最大间隔为：
1）普通帐号应当小于6个月
2）管理员帐号和超级管理员帐号应当小于3个月
Ø匿名用户帐号可以不修改口令
2.5权限管理
2.5.1概述
按照“谁主管，谁负责”、“谁使用、谁负责”、所有帐号均应落实责任人的原则制定本办法。
帐号和口令管理包括基于帐号的操作或访问控制权限的管理。
帐号是作为访问的主体。
而基于帐号进行操作的目标就是访问的客体。
通常这个客体被当成为资源。
对资源的访问控制权限的设定依不同的系统而不同。
从移动帐号管理的角度，可以进行基于角色的访问控制权限的设定。
即对资源的访问控制权限是以角色或组为单位进行授予。
2.5.2确定最小权限
1、所谓最小特权（LeastPrivilege），指的是“在完成某种操作时所赋予网络中每个主体（用户或进程）必不可少的特权”。
最小特权原则，则是指“应限定网络中每个主体所必须的最小特权，确保可能的事故、错误、网络部件的篡改等原因造成的损失最小”。
2、最小特权原则一方面给予主体“必不可少”的特权，这就保证了所有的主体都能在所赋予的特权之下完成所需要完成的任务或操作；另一方面，它只给予主体“必不可少”的特权，这就限制了每个主体所能进行的操作。
最小特权原则要求每个用户和程序在操作时应当使用尽可能少的特权，而角色允许主体以参与某特定工作所需要的最小特权去签入（Sign）系统。
被授权拥有强力角色（PowerfulRoles）的主体，不需要动辄运用到其所有的特权，只有在那些特权有实际需求时，主体才去运用它们。
如此一来，将可减少由于不注意的错误或是侵入者假装合法主体所造成的损坏发生，限制了事故、错误或攻击带来的危害。
它还减少了特权程序之间潜在的相互作用，从而使对特权无意的、没必要的或不适当的使用不太可能发生。
这种想法还可以引申到程序内部：
只有程序中需要那些特权的最小部分才拥有特权。
3、基于角色的访问控制是一种新型访问控制模型，它的基本思想是将权限与角色联系起来，在系统中根据应用的需要为不同的工作岗位创建相应的角色，同时根据用户职务和责任指派合适的角色，用户通过所指派的角色获得相应的权限，实现对文件的访问。
它支持最小特权、责任分离以及数据抽象三个基本的安全原则。
4、最小权限原则规定：
每个用户/任务/应用在必需知情的前提下被赋予明确的访问对象和模块的权限。
遵循最小权限原则运行的系统要求授予用户访问对象的明确权限。
准许或拒绝访问数据库或服务器对象的第一步是认证和授权
Ø对帐号的授权，应以其能进行系统管理、操作的最小权限进行授权。
比如这个帐号作为系统帐号只能进行数据备份的操作，那就只授权其可以进行数据备份操作的命令。
别的诸如进行系统网络状态监控的命令则不授权其可以进行。
Ø对于授权，应该支持一定的授权粒度控制，从而控制用户的访问对象和访问行为，保证用户的最小授权。
2.5.3建立权限体系
基于角色访问控制（RBAC）模型是目前国际上流行的先进的安全访问控制方法。
它通过分配和取消角色来完成用户权限的授予和取消，并且提供角色分配规则。
安全管理人员根据需要定义各种角色，并设置合适的访问权限，而用户根据其责任和资历再被指派为不同的角色。
这样，整个访问控制过程就分成两个部分，即访问权限与角色相关联，角色再与用户关联，从而实现了用户与访问权限的逻辑分离。
由于实现了用户与访问权限的逻辑分离，基于角色的策略极大的方便了权限管理。
例如，如果一个用户的职位发生变化，只要将用户当前的角色去掉，加入代表新职务或新任务的角色即可。
研究表明，角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，并且给用户分配角色不需要很多技术，可以由行政管理人员来执行，而给角色配置权限的工作比较复杂，需要一定的技术，可以由专门的技术人员来承担，但是不给他们给用户分配角色的权限，这与现实中的情况正好一致。
基于角色访问控制可以很好的描述角色层次关系，实现最小特权原则和职责分离原则
2.6账号口令审计管理
2.6.1概述
号口令管理的执行情况，在很大程度上取决于帐号口令审查的监督力度。
在公司内部推行帐号口令管理制度的很大一部分工作需要通过不断的监督、审查再配合相关的奖惩规定来保证。
因此完善的帐号口令审查制度对于整个帐号口令管理至关重要。
2.6.2账号审查通用要求
Ø对于保障等级一、二类帐号的普通用户，可以根据实际情况决定是否进行定期审查
Ø对于保障等级一、二类帐号的超级用户，定期审查的时间间隔不超过六个月
Ø对于保障等级三、四类帐号的普通用户，定期审查的时间间隔不超过三个月
Ø对于保障等级四、四类帐号的超级用户，定期审查的时间间隔不超过一个月
Ø对于保障等级五类帐号的所有用户，定期查的时间间隔不超过一个月
Ø任何变化发生后应进行审查，如：
发生非法入侵、人员变动等；
Ø对于审查过程中出现的多余、闲置或非法的帐户，应及时予以冻结或删除
Ø对核查中发现的问题，应督促相关人员采取必要措施予以纠正通用原则
Ø对于已经实施集中认证系统，审计的主要工作是对于认证和授权的日志进行检查，审核是否有非法登陆事件，是否有越权使用的行为等
Ø对于操作系统级的帐号口令审计分为两种：
第一种可以设置帐号登陆和权限使用事件的追踪，这种帐号口令的审计也是对系统日志和防火墙等访问控制设备日志的审计；对于不能实现帐号登录和权限追踪的系统，需要人工进行审计，应该根据业务系统的属性制定详细的审计checklist，由专门的安全组织进行定期或者不定期的帐号随机抽查审计
Ø对于应用系统的帐号审计工作也是参照操作系统的分类进行处理
Ø对于网络设备的帐号审计工作，由于大部分的设备帐号都是没有日志记录的，所以主要审计方式是人工审计，由专门的信息安全组织根据设备的风险等级规定审计的频度和审计的checklist
Ø审计checklist的内容主要依据审计对象的帐号口令管理规定制作，审计的关键点是帐号口令的复杂度，权限，更改的要求等等
Ø在制作审计checklist设计的时候，需要区别不同业务系统不同级别帐号的差异，对于关键业务系统和关键帐号的审计频度和审计的内容要求更加严格
Ø审计的结果应该和奖惩规定挂钩，对于多次审计不合格或者优秀的员工和分公司要按照奖惩规定进行相应的奖惩
Ø专门的信息安全部门或者组织应该对审计的结果定期进行公布，力争将审计的威慑力逐步提高，让帐号使用者提高安全使用帐号口令的意识
2.6.3账号口令审计流程设计建议
Ø帐号口令的审计流程以业务系统的风险等级做为差异定制，针对不同的风险等级制定不同的审计checklist
Ø帐号口令的审计可以结合现有的IT技术，尽可能通过日志文件等方式进行审计，但是有部分系统没法提供电子审计对象，对于高风险等级的系统，必须制定替代的审计方法，包括手工的方法
Ø帐号口令审计工作应该以省为单位由省公司安全部门牵头，各业务系统维护单位负责的方式，涉
升级会员 