当前位置: 网站首页 > 新闻公告 > 通知公告 > 正文

系统安全管理制度

来源: 日期:2018-09-20 阅读:

四川工程职业技术学院

系统安全管理制度

1总则

1.1目的

为进一步强化四川工程职业技术学院应用系统运行维护管理工作,建立业务、技术支持相结合,规范、高效运转的综合运行维护管理体制,确保各类应用系统稳定、安全、高效运行,特制订本办法。

1.2范围

本办法适用于四川工程职业技术学院应用系统的运行维护。由于业务处理的特殊性,各应用系统的具体运维管理内容可根据本办法进一步细化。

1.3职责

技术部承担各类系统的技术运维工作,具体系统运维工作由技术部系统管理员负责。

2管理细则

2.1运维组织

  1. 技术部主管统筹安排力量,建立以业务、技术支持为主体、以总体运维为依托、以基础运维为基础的高效、有序的应用系统运行维护管理体系。

  2. 对于各个应用系统,应确定其运维负责主管,各应用系统有关的部门还应设立联络人。

  3. 重要应用系统,技术部确定两名以上技术人员担任系统管理员,实行AB岗制。

  4. 对于应用系统,由技术部指定多人成立负责小组,负责组织、协调该应用系统的日常运维。

  5. 技术部建立统一的应用系统运行维护管理平台(常规通过堡垒机实现),实现各类应用系统的日常运维管理、行为审核,并通过实现运维信息共享。

  6. 日常运维人员、第三方维护人员必须通过堡垒机系统来实现运维管理。

2.2数据修改流程

  1. 对于应用系统运行过程中出现的因录入错误或程序原因造成错误数据,需要进行修改的,适用本流程。

  2. 数据修改应尽量利用应用系统提供的前台功能模块进行,前台能够修改的数据一般不允许做后台修改。

  3. 对于按照应用系统的岗责权限设置,对本人录入数据具有修改权限的,可以直接使用修改功能进行操作。

  4. 对于本人无权进行修改的,参照《变更管理程序》规定执行:

  5. 对于无法通过前台软件修改、且不修改会造成后续业务无法运行的或者严重影响数据质量的特殊情况,可以进行后台数据修改。后台数据修改的提报和处理必须参照《变更管理程序》规定执行完成:

  6. 对于错误原因和处理方法比较明确的常见问题,为提高运行效率,可以由主管部门申请,经批准后可简化或取消部分流程。

  7. 对于因软件功能不完善或者程序错误造成的后台数据修改问题,主管业务部门和技术部门应及时向领导小组反映,争取通过修改软件来从根本上解决问题。

2.3系统配置调整流程

  1. 对于涉及应用系统日常运行的系统参数、初始化代码、业务参数、打印参数、批处理设置、工作流配置等系统配置调整工作,适用本流程。

  2. 对于按照应用系统的岗责权限设置,对本部门业务参数具有前台设置权限的,可以直接使用设置功能进行操作。

  3. 对于涉及全局性的系统参数、业务参数以及其它系统配置,按照《变更管理程序》规定执行。

2.4系统升级与版本管理

  1. 系统升级部分的所有审批和流程参照《变更管理程序》执行。

  2. 为保证应用软件版本的统一,应用软件的版本和升级补丁由应用系统的系统管理员集中统一管理。

  3. 系统管理员应对下载的程序和文档进行检查,检查版本是否包含修改说明和安装说明,程序及文档是否和说明中的文档清单相一致,如果缺少内容,联系业务主管部门了解原因并获取正确版本。

  4. 系统管理员搭建升级测试环境,在测试环境中完成版本升级和技术测试,并填写《补丁测试记录》。

  5. 主管(或牵头主管)业务部门运维岗应组织相关部门,对照升级文档,按照各自职责分工在测试环境中完成业务功能测试,并确定升级相关的业务调整。

  6. 技术测试和业务测试时应注意升级对其它相关应用系统的影响,并及时协调相关应用系统的系统管理员和业务运维岗进行相关调整。

  7. 系统管理员与相关业务运维岗根据升级测试情况以及业务应用的需要,共同确定正式升级时间。升级时间一般应避免选择应用系统的运行高峰时间。

  8. 系统管理员应在升级前发布升级通知,明确升级的时间,并将升级说明、注意事项告知相关部门。

  9. 系统管理员应制定应用系统升级操作规程,在正式升级时按照规程要求做好相关数据库、系统配置、软件版本的备份,并按照操作顺序完成数据库、应用程序等的升级及升级后的测试。

  10. 各部门及相关人员应按照发布的升级要求,做好软件升级以及升级前后的业务准备、调整工作。

  11. 对经技术或业务测试发现有问题的升级版本,由系统管理员联系业务主管部门或人员,确认是否属技术问题。如属技术问题,申请重新下发升级程序;如属业务需求问题,由主管业务处室提报二次需求。

2.5运维安全与用户权限管理

  1. 仅系统管理员掌握应用系统的特权账号,系统管理员需要填写《系统特权用户的授权记录》,该记录由技术部文档管理员保管留存。

  2. 为保证应用系统安全,保证权限管理的统一有序,除另有规定外,各应用系统的用户及其权限,由系统管理员负责进行设置。

  3. 用户权限设置,按照确定的岗责体系以及各应用系统的权限规则进行。

  4. 新增、删除或修改用户权限,应通过运维平台的用户权限调整流程来完成:

  5. 应用系统的系统管理员应加强对各类用户账号与口令的管理,制定口令管理安全策略,加强对口令安全性的监督检查,强化系统的权限管理。

  6. 应用系统用户的登录密码,不得使用默认密码或弱口令。应定期更换口令。用户不得将自己的登录名与口令转交他人使用。

  7. 应定期至少每季度一次对应用系统进行漏洞扫描,生成扫描报告存档,并对扫描发现的问题及时进行处理。

  8. 需要安装补丁时,必须做好数据备份工作之后才可进行补丁安装实施工作。

  9. 加强系统运行日志和运维管理日志的记录分析工作,并定期至少每季度一次记录本阶段内的系统异常行为,记录结果填入《系统异常行为分析记录单》

2.6故障与应急管理

  1. 应用系统在建设、部署过程中应充分考虑系统的高可用性和可靠性要求,采取合理有效的技术手段,尽可能消除单点故障。

  2. 应用系统的系统管理员应协同其它技术岗位,制定应用系统的日常监控工作规程和技术应急预案,并做好应用系统的程序、数据、参数等的备份工作。

  3. 各应用系统的主管(或牵头主管)业务部门应制定各应用系统的业务应急预案,明确在应用系统无法使用时手工办理相关业务的处理流程。

3访问控制策略

3.1总体要求

信息系统访问控制管理的基本原则如下:

  • 隔离运行:对于不同重要等级、不同用途的信息系统,应采取物理隔离或逻辑隔离措施,确保各类信息系统稳定运行

  • 最小权限:用户应只被授予完成特定工作的最小访问权限,用户权限应与工作职责紧密关联并及时更新

  • 按需审批:在授予用户访问权限时,应根据用户的工作职责需求进行授权,避免用户访问权限过大,同时应每半年对用户权限进行一次评审

  • 职责分离:一个用户不能同时承担多个存在职责冲突的角色,以防止过大权限;关键系统的访问审批流程的请求者、授权者、管理者不能是同一个人

  • 默认拒绝:未经明确授权的用户,系统应默认采用禁止访问原则

3.1.1信息系统账户控制

        1. 应为不同用户创建不同账户。每一个用户账户必须属于一个用户,即该账户所有者。特殊情况需要使用共享账户、服务账户时,必须指定该账户的所有者。

        2. 账户所有者对所持有账户负责。

        3. 第三方合作厂商申请信息系统账户时应已签署包含保密条款的合作协议。

3.1.2信息系统角色及权限设计原则

        1. 信息系统角色及权限在设计时,应遵守以下原则:

  • 系统角色与业务岗位权限一致原则。业务岗位根据需要,可设置不同的系统权限,如访问权限,操作权限等,但一个系统权限不可以包含跨多个业务岗位的业务功能,如新业务的系统权限不能包括保全的业务功能。当业务岗位职能调整时,应同时调整系统权限设置

  • 最小特权(Least Privilege)原则。用户拥有的信息系统权限不应该超越他所在部门的业务范畴。当需要访问其他部门的业务功能时,必须得到相应部门负责人的授权。当用户发生离职、调岗时,应检查其业务权限并进行权限变更。服务账户不能是系统管理员账户

  • 职责分离(Segregation of duty)原则。有利益冲突的业务岗位必须由不同的人担任,如录入岗位和复核岗位属于不同岗位,因此录入功能和复核功能不能同时出现在一个系统权限里,且不能被赋予同一用户

3.1.3缺省权限和用户账户的管理

        1. 对于应用系统中的公用功能,默认为缺省权限。缺省权限无需包含在申请表,每个应用信息系统的用户都会拥有。应用系统中的公用功能,由对应应用系统决定。

3.1.4信息系统账户申请管理

        1. 新增、修改、关闭信息系统的账户,需联系相关系统管理员。

  • 临时账户:申请临时账户时应提供临时账户的用途与有效使用时间,便于系统管理员对账户失效时间进行管理

  • 共享账户:申请时需说明共享范围,应避免超出范围的人员使用

  • 服务账户:申请服务账户时应详细说明用途和范围,应根据模块的划分,专块专用,避免混淆使用导致信息泄露

3.2共享账户、服务账户和紧急账户

有2个或2个以上用户使用的账户被定义为共享账户。共享账户的申请必须符合以下规定:

  • 共享账号只允许存在于测试环境中

  • 共享账户必须明确的所有者

  • 共享账户必须明确实际的使用者

  • 特权共享账户不允许通过远程登录的方式进行操作

服务账户是应用系统与操作系统或其它应用系统交互时使用的账户,服务账户没有交互式登录功能。系统管理员应维护服务账户清单,服务账户必须明确使用者。

信息系统提供有特殊权限的紧急账户。系统管理员必须制定流程来管理紧急账号。该流程必须得到管理员的批准并进行相关的记录。该流程必须被定期进行评审。紧急账户申请流程必须进行详细的记录,记录必须包含以下内容:

  • 使用理由

  • 申请内容

  • 管理者的审批

  • 账号到期时间

  • 账户只能由被授权人使用,而且每次使用必须进行记录

3.3特权管理

特权账户是指有特殊访问权限需求的账户,如技术支持人员、安全和系统管理人员的账户。所有特权账户都需要建立说明文档,并通过建立一个流程来定期对特权账户的使用进行监控和评审。

特权账户的管理必须遵循以下规则:

  • 每个信息系统(例如,操作系统、数据库管理系统和每个应用程序)的特殊权限和被授权的用户应进行标识;

  • 特殊权限应基于“按需使用”和“一事一议”的原则进行分配,即仅当需要时,才为其职能角色分配最低权限;

  • 在未完成授权过程之前,严禁授予特殊访问权限;每个特殊权限的授权过程应进行记录和维护;

  • 特殊权限应分配给非日常业务活动的用户,日常业务活动不宜使用特权账;

  • 当特权用户离职或者特权账户口令泄露时,必须更改特权账户的口令;

  • 对于通用管理用户,当共享时宜维护秘密鉴别信息的保密性(例如经常变更口令、尽可能当一个特权用户离开或变化职位时也变更口令,使用适当的机制在特权用户中进行传达)。

3.4权限管理

变更权限时,必须进行用户身份验证和审批。用户工作内部变动时,其权限必须被评审,并根据评审结果作相应调整,在更新系统口令前必须进行身份验证。

3.5账户管理

系统管理员必须建立账户及权限的变更流程来管理账户及权限的变更,流程必须遵循以下规则:

  • 包含账户及权限的变更申请和审批;

  • 口令更新前的身份确认;

  • 用户工作内容发生变化时,用户的权限的修改。

账户使用管理应包含以下要求:

  • 信息系统的账户失效后,该账户在两年内不应分配给其他用户;

  • 测试环境、开发环境和用于演示、培训环境的账户不能用于登陆生产环境;

  • 用于远程登录和操作的系统管理员账户不应被共享;

  • 个人账户不得与他人共享,由于分享个人账户而造成的非授权访问和误操作所导致的一切后果,公司将追究账户所有者的责任。

3.6账户审核

系统管理员必须对用户权限进行定期评审,评审包括以下内容:

  • 用户账户应至少90天登录一次,超过90天未登录将禁用账户;

  • 用户账户是唯一的不重复,权限符合最小化原则;

    用户权限应符合权限分离原则。

    无效账户处置

  • 系统管理员必须对无效账户进行管理,包括以下内容:

    • 离职用户的账户必须立即被关闭或删除;

    • 若没有技术部负责人的批准,账户连续三个月未使用将被禁用。

    令牌和PIN码管理

    个人识别号(Personal Identifying Numbers)和PIN码必须与令牌一起使用。PIN码应至少使用4位。令牌文件的保护应包含如下:

    • 限制访问令牌文件;

    • 将令牌备份文件加密后保存在安全的环境下。

    令牌硬件的分配:

    • 令牌启用前必须确认用户身份;

    • 应记录和保存用户令牌的serial number并保障记录的安全。

    软件令牌的分配:

    • 令牌分发必须在加密通信或采取文件加密的方式进行;

    • 将令牌与系统进行绑定,限制令牌使用范围。

    令牌丢失处置:

    • 确认用户身份;

    • 禁用令牌;

    • 记录丢失令牌尝试登录的日期及日志;

    • 处置任何尝试登录行为。

    证书管理

    IT管理员必须确保证书的安全。证书管理须包含以下内容:

    • 发布的安全,包括验证用户身份;

    • 分发的安全;

    • 更新和失效;

    • 备份和存储的安全;

    • 证书必须由可信赖的权威机构发布。

    3.7登录和口令管理

    注:对于已投运系统择时改进,从而符合以下控制要求;对于新系统应满足以下要求。

    登录过程控制/Login Process Control

    用户必须使用自己已授权的账号来登录信息系统。登录控制必须符合以下规则:

    • 显示只有已授权的用户才能访问计算机的一般性的告警或通知;

    • 登录成功后才显示系统的详细信息,并提示用户上次成功登录时间;

    • 仅在所有输入数据完成时才验证登录信息;

    • 登录失败时各信息资产必须执行以下措施:

    • 记录失败的登录尝试;

    • 在登录期间不提供任何帮助信息;

    • 最大尝试登录次数超过5次后账户被临时锁定。

    用户登录系统时不得使用记录密码功能。

    口令管理策略/Password Management Policy

    用户在设口令时需要遵循以下规则:

    • 不能基于别人容易猜测或获得的与使用人相关的信息,例如,名字、电话号码和生日等等;

    • 修改密码时,新密码应与旧密码完全不同,不应存在容易被猜测的规律,例如apple1a, apple2b, apple3c。

    • 口令严禁明文保存,必须加密保存。除紧急和服务账户,口令不能被打印;

    • 除了紧急账号或服务账户,口令不得被共享给其他用户;

    • 口令若被泄漏,用户应立即修改口令,并根据安全事件汇报流程上报;

    • 使用口令时必须进行身份验证。

    口令认证控制/Password Authentication Management

    公司所有的信息系统都要遵循以下口令认证控制管理规则:

    • 在第一次登录时强制用户变更临时口令;

    • 在输入口令时,不在屏幕上显示;

    • 口令严禁明文保存,口令在传输时必须被加密;

    • 在修改口令时,必须正确输入旧的口令;

    • 口令长度不得低于8位,包括数字和字符;

    • 记录用户10次口令使用记录,并防止重复使用;

    • 口令最短使用期限为一天。除紧急账户和服务账户,口令最长使用期限为90天;

    4附则

    附1:系统特权用户的授权记录

    系统特权用户授权记录

    服务器类

    服务器IP

    运行业务系统

    账号名

    权限角色

    用户姓名

    登记时间

    备注

    应用系统类:

    应用系统名称

    账号名

    权限角色

    用户姓名

    登记时间

    所属部门

    备注

    *此表主要登记业务系统用户权限,记录其姓名、及部门

    附2:补丁测试记录

    序号

    补丁编号

    补丁测试时间

    测试系统

    测试人员

    补丁安装时间

    安装系统

    安装人员

    验证结果

    附3:系统异常行为分析记录单

    系统异常行为分析记录

    注:每月填写一次

    违规行为详细记录(含违规时间)

    处理措施

    记录人

    记录时间