信息安全系统运营管理程序.docx
- 文档编号:26816737
- 上传时间:2023-06-23
- 格式:DOCX
- 页数:14
- 大小:24.67KB
信息安全系统运营管理程序.docx
《信息安全系统运营管理程序.docx》由会员分享,可在线阅读,更多相关《信息安全系统运营管理程序.docx(14页珍藏版)》请在冰豆网上搜索。
信息安全系统运营管理程序
种类:
信息安全管理程序
文件编号:
名称:
系统运营和维护管理程序
总
页
数
10
页
No
1
起稿
校核
承认
批准
批准日
年月日
修订履历
修订履历编号
修订
批准日
修订
页
修订内容及理由
起稿印
校核印
承认印
批准印
种类:
信息安全管理程序
文件编号:
名称:
系统运营和维护管理程序
总
页
数
10
页
No
2
1.目的
2.适用范围
3.制定、修订、废止
4.定义
5.日常运营
5.1服务台
5.2事件管理
本程序旨在规范应用系统在使用过程中的管理行为,以充分发挥系统的使用效率,以及确保系统的运行安全。
所有和信息安全相关的系统。
本程序的制定、修订和废止由信息部提案,并最终经总经理批准生效。
1.本程序中的对象系统是指:
①已经发布的正式系统;②为确保变更正确性而设置的测试系统;③和信息安全相关的支持系统(下称支持系统,如门禁、中控和其他基础供电系统)
2.信息部是公司信息系统运营维护的管理部门。
3.其他支持系统由相关部门进行运营和维护。
1.设立用户服务台(热线电话、邮件),受理用户在系统使用过程中出现的各类问题及相关咨询工作。
2.将用户提交的问题按应用模块及应用系统类别进行分类,并按事件影响、重要度、紧急度进行处理级别划分,并依次填写《事件记录单》后分派给相应担当进行处理。
3.服务台负责跟进用户提交问题的处理情况,并将处理阶段的相应信息回馈用户。
4.问题处理完毕后,服务台负责将处理结果通知用户并跟进,直到用户确认提交的问题已经处理成功并将此事件关闭。
1.事件是指引起用户在系统操作过程中出现的可能引起服务中断或服务质量下降的不稳定现象。
这里所指的事件不仅包括系统故障,还包括服务请求,例如:
系统操作、误操作对应、重置口令等。
2.当多个事件需要同时处理时,必须根据事故所造成的影响、事故的紧急程度、解决的难易程度等因素确定事件对应策略及联络对应体制。
3.事件管理的目标:
在尽可能小地影响用户业务的情况下使系统尽快恢复到正常状态。
当此事件的影响面大而且在约定的时间内无法解决,事件处理担当必须将此事件升级,报告上司并请求相应的协助。
4.在处理事件的过程中要详细的记录事件现状、发生时间、发生地点、发生的原因等信息,以便为其它的管理提供支持。
5.当重要紧急事件发生时:
如月末/年末结算,MRP运行,采购订单下达、业务交易数据丢失等影响公司正常经营生产的重大事件发生时,必须在第一时间报告上司(课长、部长),并在1小时内电话或邮件通知相关业务部门
领导,如需关闭系统进行检查,需要出具书面联络到受影响部门。
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营维护管理程序
总
页
数
10
页
No
3
5.3问题管理
6.变更管理
6.1变更控制
6.2变更处理
6.3变更测试
6.事件处理完成后,必须对恢复正常后的结果进行确认,并取得用户部门确认。
1.问题定义:
在尚未查明事件产生的原因前,事件所对应的潜在原因被称为问题。
问题管理强调的是找出事件产生的根源,从而制订恰当的解决方案
2.运营维护组根据应用系统出现的事件分析产生的原因,并根据《问题记录表》进行详细的记录并跟进问题解决进度直到得到根本性解决。
3.如果遇到无法查找到的问题原因,需要进行问题升级,报告上司并寻求外部协助。
4.如果在解决问题时需要对已有应用系统的业务流程及程序、配置进行变更,需要参考变更管理。
1.对用户请求中涉及到的应用系统程序、配置之变更需要严格审订,分析变更的必要性及变更可能带来的风险及是否可通过管理手段解决用户请求。
2.运营维护组和责任部门有责任协助用户分析他们的需求,并且根据用户需求整理出《用户需求处理意见书》,此处理书应详细记录用户需求及初步的解决方案并需得到相关用户部门长确认;如涉及到系统变更则提交项目组进行处理。
1.所有的系统变更处理只允许在开发系统中进行,变更完成后要传输到测试系统进行测试,测试确认后方能传输到生产环境。
2.原则上,系统变更由项目组进行处理,运营维护组只需将用户需求及解决方案通过《信息部用户需求处理意见书》提交;但是运营维护组有责任跟进变更的处理过程及指导项目组进行相关操作。
3.运营支持组有责任要求项目组在进行系统变更时进行详细的记录和提交《系统变更报告书》,如为程序、配置变更,还需提供《程序说明书》及《配置项说明书》。
4.其他支持系统的变更由责任部门负责,需编制相关的变更计划。
1.项目变更处理完成后并进行了初步测试,详细的测试工作由运营维护组担当和责任部门为主导进行测试并出具详细的《测试报告》。
2.如测试得到用户确认,运营维护组还需提交用户进行测试,并得到用户出具的《测试确认书》方可认为变更测试完成并可进行发布。
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营维护管理程序
总
页
数
10
页
No
4
6.4发布管理
7.系统管理
7.1系统日志审查
7.2系统故障
1.当项目组根据变更的具体需求出具相关的《系统变更记录》、如有程序及配置变更则出具《变更程序说明书》、《配置项说明书》后,并且测试结果得到信息部上司及用户部门确认后,由项目组填写《系统变更记录表》提交运营维护组进行发布。
2.运营维护组相关担当对从测试系统传输到生产系统的相关变更与《系统变更记录》里的内容确认一致后,并将《系统变更请求书》交由信息部部门长确认后,系统管理员方可进行传输。
系统管理员是系统变更传输的指定用户,其它用户不能进行此操作。
3.传输完成后通知用户已在生产环境发布,运营维护组相关担当在用户使用过程中需要至少进行一周的跟进以确保变更成功完成。
4.其他支持系统变更测试通过后,由责任部门实施变更,必要时通知公司其他的部门做好变更期间和变更后的相应对策。
1.所有的系统的运行日志必须开启,系统管理担当每天需对重要系统日志进行检查并填写好《系统日志检查记录》。
系统日志审查时系统管理担当需根据本系统的说明对日志进行分类,对日志中指示的异常状况要及时分析,根据分析结果对不同的异常状况采取不同的对应方法。
并做好异常处理报告。
2.系统管理担当应依据日志检查的结果,制作《系统运行状态报告》并提交直接上司进行确认。
1.如果系统运行日志出现不正常情况必须在第一时间将问题现状、风险、影响以《故障报告书》形式汇报上司,如需采取紧急对策对系统进行关闭处理,务必得到部门长确认并且通知各相关部门。
2.如服务器出现硬件故障,通过《故障报告书》记录清晰故障现状,并迅速通知硬件维护供应商进行处理。
要求供应商的对应时间:
硬件故障导致宕机:
2小时进驻现场对应;冗余硬件故障:
2小时进驻现场对应;两天内新硬件到货。
3.如SAP软件;DB2出现无法自行解决的故障,通过《故障报告书》记录清晰故障现状,并迅速在SAP网站发送Message与SAP服务中心取得联系,并通过Message进行故障对应。
影响业务正常进行的重要而非紧急事件,Message级别设置为HIGH;如是重要而紧急或宕机事件,Message级别设置为VeryHigh。
必要时应迅速联系外部顾问公司进行进驻现场的对应。
4.故障对应完成后须进行严格确认,确保恢复后的系统正确性。
5.针对特定系统,制作《信息系统故障紧急联络图》。
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营维护管理程序
总
页
数
10
页
No
5
7.3作业运行
7.4时钟同步
7.5系统补丁管理
7.5其他管理
8.用户管理
8.1用户分类
1.用户如需信息部在应用系统中帮助运行关键的业务处理程序,如:
财
务结算相关程序、报表;MRP运行程序等,用户部门务必提交《程序运行请求书》并交由用户部门长、信息部部门长确认后,系统管理担当方可按照《程序运行请求书》内写明的运行时间、运行条件、结果提交时间等关键条件进行运行调度安排。
2.用户如需在应用系统后台提交周期性作业,如:
一些接口程序的数据提取/发送/接收程序;业务数据的更新程序等。
用户部门务必提交《后台作业申请表》并交由用户部门长、信心中心部门长确认后,系统管理担当方可按照《后台作业申请表》内写明的运行程序名、运行周期安排、运行条件等关键要素,并通过系统内固定用户进行作业的调度和运行。
公司采用域控技术保证所有的系统的时钟同步。
1.操作系统(含服务器和两用机)补丁:
为防止恶意代码和其他移动代码的入侵,操作系统补丁须经过业务系统管理者和服务器管理者经过测试共同确认后,方能由服务器管理者和业务系统管理者进行实施安装;(参见服务器管理程序5.6.2)
2.业务系统补丁:
未完善系统功能和防止恶意攻击,业务系统补丁需经过业务系统管理者经过测试确认后,方能由业务系统管理者进行实施安装;
3.补丁安装前按系统变更进行准备和控制。
1.系统管理担当需要定期(每周一次)对应用系统内的打印请求和打印假脱机号进行整理和清除,以保证系统打印的正常运行。
2.系统管理担当每月要对应用系统的运行状况出具月报,包括:
系统变更、用户、性能报告、故障报告、数据增长报告、数据备份报告等信息。
3.系统管理担当需要定期对系统内的外付(Customization)程序进行盘点,原则上是每年度进行2次,并出示《外付程序盘点清单》交由直接上司、课长进行确认。
4.不使用的程序经由用户部门确认、信息部模块运营担当确认、信息部课长确认后,系统管理担当方能在系统内进行删除,并及时更新《外付程序盘点清单》。
1.业务用户:
用于管理常规业务数据,负责常规业务数据的输入与确认的用户。
2.查询用户:
应用系统中用于查询与岗位业务各种相关信息的用户。
信息查询用户主要用户各部门相关干部。
3.管理用户:
即特权用户,用于系统的用户权限管理、系统作业调配,系
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营维护管理程序
总
页
数
10
页
No
6
8.2帐号的申请与注销
8.3权限管理
8.4用户要求
统数据管理等业务的特殊用户。
系统管理用户通常由信息部指定担当管理。
4.开发用户:
信息部的开发人员用户系统开发或变更的专类用户。
开发用户的使用必须在开发环境使用,生产环境禁止使用开发用户。
1.用户部门需要使用应用系统时,必须向信息部申请系统帐号,填写《业务系统帐号申请表》,并需征得用户部门责任者、信息部总监同意;
2.信息部在接到申请后,应及时确认并办理。
3.信息部在审核系统帐号及统计用户使用数量时必须确认是否符合软件版权法或与软件开发公司的软件使用协议。
4.系统帐号的日常使用与管理由业务部门具体使用担当管理,该系统帐号进行的所有系统操作责任由该帐号所有人承担。
5.当用户离职或其它原因不再需要使用系统帐号时,用户应及时通知信息部,信息部在收到注销申请时应及时注销该用户的系统帐号。
1.用户权限是指用户在操作应用系统时所具备的由信息部系统管理员
所指定的使用许可范围。
2.应用系统的应用是基于用户权限而进行的。
用户权限的大小都是根据用户的业务需求来决定的。
3.业务部门必须针对各担当的业务内容向信息部申请用户和用户权限,当系统操作业务出现跨部门的情况时,还须获得对方部门的同意。
(特别强调,由于系统应用的集成性,SAP系统用户权限的设置与增加须在常规申请手续过程中,增加财务确认)
4.用户权限的申请包括权限的增加和权限的减少,业务部门负责人应根据各担当的岗位内容变化及时联络信息部进行调整。
5.信息部负责各应用系统用户资料及用户权限的维护。
6.SAP系统用户权限申请或添加基本流程:
用户申请→信息安全推进主管确认→部门上司确认→(对方部门确认)→财务确认→信息部担当权限码填写→上司确认→系统管理员用户权限维护→申请表存档。
1.系统用户上岗前必须经过培训和考核,严禁未经培训或考核不合格的人员操作应用系统。
2.系统用户的培训原则上由信息部组织实施,条件许可时也可由用户部门进行内部培训,但培训结果必须经信息部考核认可。
3.系统用户应具备良好的责任心,系统操作时必须按照用户手册所规定的
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营维护管理程序
总
页
数
10
页
No
7
8.5安全管理
9.系统操作
9.1主数据维护
9.2业务数据录入
9.3系统作业管理
要求进行,严禁违规操作。
4.系统用户应具备协同作业的意识,为了不影响其它部门的系统业务,业务数据必须及时正确地输入应用系统,在严把质量关的同时,做到“日日完结”。
5.系统用户的作业提交与运行必须服从信息部系统管理员的统一调度与安排,严禁擅自提交作业。
1.用户在初次获取系统帐号后,应及时更改初始密码;
2.严禁将系统帐号借给他人使用;
3.系统帐号的密码设置:
密码长度不低于8位,至少采用大写字母、小写
字母、数字及特殊符号中的三种字符,帐号密码要定期变更;
4.连续输入3次错误密码时,系统应自动锁定该帐号;
5.每年至少应对系统帐号盘点2次,盘点结果需提交用户部门责任者确认;信息部对盘点结果汇总,并报送信息部总监承认。
1.主数据是应用系统的基础数据。
主数据维护是系统应用的基础。
2.主数据维护必须由专人负责,主数据维护担当的确定必须经过相关业务部门以及信息部共同检讨并达成一致意见。
3.主数据担当的管理范围必须依据该岗位担当的具体责任范围确定。
主数据维护担当必须有强烈的责任心,保障主数据的准确度。
4.通常各部门主数据维护岗位只能设置一个主数据担当,特殊情况时可视业务量的多少申请设置两名或多名。
5.应用系统的各部门的主数据担当必须进行在注册管理。
6.主数据担当维护的各种主数据必须依据原始记录卡进行。
1.业务数据是指用于输入应用系统的各种交易数据,如出库、入库、生产实绩、销售实绩、报销单等等。
业务数据是应用系统进行管理、统计分析的原始资料。
2.业务部门必须按照系统操作手册及时真确的把各项业务数据输入应用系统,以确保系统的及时性、正确性以及其它关联部门能够及时处理。
3.业务数据输入用的原始单据必须按规定保存完好以备各项检查。
1.用户对系统操作的任何一个确认动作都属于系统作业。
系统作业可分为交互作业和后台作业。
交互作业通常在当前系统画面就可完成,时间非常短。
后台作业通常指用户提交后由系统调度运行的或系统内部调度运行的作业。
后台作业通常与用户操作画面无关。
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营维护管理程序
总
页
数
10
页
No
8
9.4报表和单据管理
9.5信息查询
10.备份管理
10.1备份管理
10.2备份介质
10.3数据归档
2.当交互式作业占用时间和资源较长时,用户应该将其提交到后台运行。
3.用户提交作业到后台必须服从信息部系统管理员的调度安排。
要有节约系统资源的良好意识,不得随意提交无效作业。
1.报表和系统表单是用户部门用于管理有关数据的汇总资料以及编制相关凭证的载体,报表及表单运行和打印出来后应妥善装订保管,对无用的报表和单据应妥善处置,严禁随意丢弃,防止信息泄露。
2.报表及系统单据的打印应遵循各用户部门的岗位操作规程。
3.需要耗费较长时间运行的报表应服从信息部系统管理员的作业调度
1.系统信息的查询是系统应用效率化的重要手段之一。
系统信息查询只有当用户得到相应权限后方可进行。
2.信息查询人员必须遵守岗位规程,注意信息密级。
1.备份是将系统数据库及系统服务器上的重要数据从磁盘转储到磁带上,以便当应用系统或服务器出现灾难性故障后能将数据恢复到故障前的状态。
2.需要备份的数据包括:
系统配置参数、数据库、重要程序、操作系统以及其它必须备份的数据。
3.备份要求:
信息部应通过正当渠道购买具有质量保证的磁带,磁带投入使用前必须清楚标明备份数据的内容(分类)和备份的时间。
4.数据库备份应至少使用2盘以上的磁带,对磁带进行编组,按照备份策略周循环使用。
1.成功备份后必须及时将磁带存放在指定的保险柜内,每个星期五将当前最新的全备份磁带转移到异地进行保管(必须是不同建筑物内的另一场所)。
2.备份数据为公司重要的信息资产。
保险柜密码要定期修改,保险柜钥匙一份由系统管理担当保管,一份由其直接上司保管。
3.备份磁带要定期进行更换,磁带更换周期请参照“备份策略”。
1.系统数据量的大小直接影响到系统效率,系统管理员必须针对系统负荷状况以及系统运行效率酌情考虑系统历史数据的归档。
2.系统历史数据归档前必须寻求好可恢复或可回查等措施。
系统历史数据的归档通常由信息部担当负责,对于部门内部使用的应用历史系统数据的归档工作可由部门系统管理员担当。
3.历史数据归档后应做好必要的登记备案管理,以方便日后查看。
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营和维护管理程序
总
页
数
10
页
No
9
10.4恢复测试
10.5数据恢复
11.系统升级
12.系统容量
1.备份数据要定期进行恢复测试以检验备份数据是否可用,并保证当应用系统出现灾难性故障后不会出现无数据可用的重大损失。
2.各类备份数据恢复测试的周期为:
操作系统全恢复:
1次/年;数据库全恢复:
1次/年。
1.数据恢复是指当系统发生灾难性故障并无法通过常规手段修复时使用备份数据还原到故障前状态的特殊处理方法。
2.数据恢复应尽可能选择使用最近的备份数据。
3.恢复处理前必须充分检讨,出具详细的技术解决方案,必要时委托专业顾问公司处理。
恢复用数据和解决方案需经过信息部责任者检印确认。
4.恢复处理前必须将故障情况及处理方法报告相关业务部门及公司经营层干部。
1.当现行系统存在重大隐患(BUG)或者不能满足公司业务需求时,应检讨系统新版本功能以及异常修正情况,策划考虑系统升级。
2.应用系统升级前,应设立专门项目组,组织完成项目的企画(业务影响度分析)、升级方案书、实施风险和防范对策、实施计划等,经信息部总监确认后提交公司经营层审批。
3.系统升级前项目组必须制定严格的风险防控措施以及周密的测试计划,必要时与软件供应商或技术咨询商签定升级合同,确保升级的正常、有序与安全。
4.升级实施前,项目组须与相关业务部门协商,确定最佳升级时间并将升级实施计划通知相关部门,同时要完成相关用户的系统操作培训。
正式实施前必须对系统进行全备份,升级实施时必须记录升级的详细过程,并指定专人对升级后的系统及数据正确性进行确认。
5.系统升级完成后,项目组应设立热线对应升级后出现的应用问题
6.系统升级资料必须完整保存,直到系统停止使用后3年。
7.系统升级一旦失败,必须实行系统恢复方案,将系统恢复到升级前的状态。
系统管理员根据系统规划和系统运行要求,设定各种系统的容量管理程序,并上报部门总监进行批准。
系统容量包括:
系统硬盘、CPU、内存、网络带宽、中心机房电力容量、UPS、CallCenter、监控系统容量等。
系统容量状况应及时进行监控,当发现异常时应及时分析处理。
需要时应及时报告部门领导进行处理。
批准日
年月日
修订批准日
种类:
信息安全管理程序
文件编号:
名称:
系统运营维护管理程序
总
页
数
10
页
No
10
13.超时中断
14.系统审计
15.附录:
信息部系统管理担当针对公司重要系统制定《重要系统超时中断策略表》,并上报部门主管和信息部最高责任者进行批准。
系统管理担当按策略表规定做好系统设置,保证系统超时中断和连接时间限制策略得到实施。
1.信息部每年至少进行一次对信息系统进行审计,已确定信息系统的运行符合系统规定的要求。
2.信息系统的审计时需提前编制审计计划,计划编制时应尽量减少对业务系统运行的影响,同时应考虑审计工具的应用。
3.系统审计工具需由信息部指定部门和人员进行管理,工具存放在指定的服务器中,审计工具的访问和使用必须由指定人员负责,其他人员未经过信息部责任者的批准,不得使用。
4.审计完成后必须编制审计报告,审计报告中对审计中存在的问题进行分析并制定改进措施。
报告提交信息部责任者和公司管理评审会议进行评审,。
5.如果系统审计是由外部公司实施,必须按要求编制计划,经过批准后实施。
审计报告
1.《系统变更记录表》
2.《业务系统帐号申请表》
3.《后台作业申请表》
4.《信息系统故障紧急联络图》
5.《故障报告书》
6.《系统变更记录》
7.《测试报告书》
8.《重要系统超时中断策略表》
批准日
年月日
修订批准日
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息 安全 系统 运营 管理程序