33、1安全分析
33、2建设需求54设计原则及依据
64、1设计原则
64、2设计依据65解决方案
95、1部署拓扑示意图
95、2安全实现过程105、3产品列表及性能1
15、3、1产品列表1
15、3、2产品性能参数1
15、4产品上线给企业带来的优势121 前言作为企业的IT技术主管，经常会被一些问题所困扰，如：业务系统数量越来越多，且安全管理相对分隔，不利于故障的准确定位；IT系统 的关键配置信息登记不完善，不利于IT运维人员的整体管理和把控；故障处理解决方案的知识不能得到有效沉淀，发生类似问题不能及时调用成型解决方案，对人员依赖性问题严重；IT运维人员的技能要求不断增高，繁多的业务系统需要业务人员进行更多的维护和管理，而工作却无法得以量化。另外，目前计算机及网络风险日益突出，计算机犯罪案件就以每年成倍增长，发案原因多以有章不循、屡禁不止、检查监督不力等内部风险控制和运行管理方面的安全漏洞为主。 因此加强计算机及网络内部管理和监控是保证计算机系统安全生产的重中之重，为此，各单位都采用了多种技术手段，如会话加密、数字证书、防火墙、虚拟专用网等，但运维管理仍存在较多的安全隐患，特别体现在针对核心服务器、网络基础设施的运维管理上。2 运维现状目前公司内部日常运维的安全现状如下：1)
针对核心服务器缺乏必要的审计手段，仅能通过监控录像、双人分段或专人保存密码、操作系统日志结合手工记录操作日志等管理办法，无法追溯操作人员在服务器上的操作过程、了解操作人员行为意图，并且这样的管理成本很高，很难做到长期照章执行。2) 对服务器的维护和管理依赖于操作系统的口令认证，口令具有可被转授、被窥探及易被
遗忘等弱点，另外，在实际环境中还存在经常使用Root权限帐户而导致授权不方便等现象，使得管理困难，成本较高。3)
针对许多外包服务商、厂商技术支持人员、项目集成商等在对内部核心服务器、网络基础设施进行现场调试或远程技术维护时，无法有效的记录其操作过程、维护内容，极容易泄露核心机密数据或遭到潜在的恶意破坏。3 安全分析及需求
HOST 格式 3、1 安全分析
（一）、IT系统口令管理复杂且存在隐患IT系统口令对IT系统的安全是非常重要的，因此随着IT系统数量庞大，IT系统的口令管理工作量越来越大，复杂度也越来越高。另外，在实际管理中，由于管理和使用的矛盾导致IT系统口令管理存在很多安全隐患。主要表现如下：l 为了满足安全管理要求，IT系统的口令需定期修改（一般半个月或一个月），这大大加大了口令管理的工作量。l 口令强度要满足安全要求，其复杂性也有一定要求。一方面加大了修改口令的工作量和复杂度，同时对维护人员来说也很不方便，经常是将口令记录在记事本上，造成口令泄露问题。l 在实际操作中，经常将口令设置为很有规律性，一旦知道一个口令，很容易知道其他系统的口令。
（二）、多入口操作现象频繁l 随着IT系统构成的复杂，在运维过程中可通过多种入口对IT系统进行维护，导致无法统一管理、设置统一安全策略等而引起各种安全隐患。l 操作人员复杂、操作习惯不同以及故障情况下，都导致通过不同入口（如：远程、KVM、主机本身）去维护系统。
（三）、交叉运维操作现象l 在IT系统运维过程中，存在多种管理角，如设备管理员、系统管理员、安全管理员和应用系统管理员等，同时对于同一个角也同样存在多个管理员。对于这些管理员进行维护时，可能是使用IT系统的同一个帐号，这样一旦出现问题很难定位具体某个人的操作。l 存在交叉维护时的口令传递问题，容易泄露。
（四）、越权和违规操作l 根据最新的统计资料，11%的安全问题导致网络数据破坏，14%的安全问题导致数据失密，而从恶意攻击的特点来看，70%的攻击来自组织内部。尤其面对拥有特权的维护用户，由于以前没有一种技术手段来监控、控制其操作，所以出现越权或违规操作的现象时有出现。l 无法保证可信的用户才能访问其拥有权限的资源，无法规避越权或违规操作，导致安全事件发生。
办公桌隔断
（五）、无详细的操作、审计记录针对运维操作，IT系统是靠系统日志方式进行记录的。
它存在以下问题：l 系统日志不独立，无法防止被篡改；l 系统日志记录信息不全面，目前系统日志记录的信息相对简单，多数仅记录登陆、退出、时间、部分事件，而且检索不方便。l 系统日志较复杂，一般审计人员根本无法解读，无法再现当时的操作场景。
（六）、无法满足合规性检查l IT系统的重要性和对业务系统影响越来越大，相关的法律、法规对其安全性、可持续性工作、IT操作风险以及企业内控等都有明确的要求。电网均有内审和外审来评估IT系统的安全性。目前面对这些合规性检查，只能是制度上的检查，极需要有效的技术手段来体现这些制度的落实。l 目前国家等级保护要求，国际诸如萨巴斯法案、巴塞尔协议等均在全世界推广，但多数安全维护方面无法满足该安全要求。
（七）、缺乏运维安全分析报告l 目前运维管理方面，由于没有监控审计数据，无法实现定期的运维安全情况的分析报告。l 对于运维过程存在的问题无法有定量或定性的分析数据，只能简单从安全事件方面进行描述，发现潜在安全风险。
3、2 建设需求金融机构对信息安全建设比较重视，处于同行业较高水平，但是其运维安全管理、内控机制等方面也存在上述问题，因此针对运维管理的具体需求如下：1)
支持日常维护人员针对AIX、Linux主机设备，主流网络设备、Windows服务器的进行的运行维护操作审计；2)
可以支持针对外部厂商远程运行维护时，进行操作审计；3)
审计协议支持Telnet、FTP、SSH、SFTP、RDP、VN
C、HTTP、HTTPS等；4)
详细的权限分配功能，可以根据时间、登录IP、目标资源等进行详细授权，并可集成公司内部AD域认证；5)
支持按时间、用户名、被审计设备、命令等进行的定制报表，并可以导出Excel或PDF等格式报表；6)
设备支持硬件冗余方式，并支持HA。4 设计原则及依据
4、1 设计原则1)
符合政策的原则系统设计要遵循国家的相关安全政策，参照国家标准、国际标准、行业标准及相关安全指南，避免安全政策风险和运行风险。2)
安全目标与效率、投入之间的平衡原则 要综合考虑安全目标与效率、投入之间的均衡关系，确定合适的平衡点，不能为了追求安全而牺牲效率，或投入过大。3)
标准化与一致性原则 产品方面必须遵循一系列的业界标准，充分考虑不同系统之间的兼容一致性。4)
动态发展原则 安全建设不是一个一劳永逸的工作，而是一个长期不断完善的过程，所以产品技术要能够随着安全技术的发展、外部环境的变化、安全目标的调整而不断升级发展。5)
高可用性和可靠性产品要满足高可用性要求，系统应具有高可靠性设计，以满足业务持续性运行要求。6)
易管理原则产品尽量使用易管理、易维护，避免管理的复杂和难于集成，减少运维成本等。
高建钢
4、2 设计依据本方案设计依据的标准、规范和需求主要有：n 《中华人民共和国银行业监督管理法》；n GB17859-1999 计算机信息系统安全保护等级划分准则；n GB/T18336 IDT ISO/IEC15408:1999 信息技术安全性评估准则；n ISO/IEC17799-2000；n BS/7799；n 《商业银行操作风险管理指引》
第七条 商业银行应当将加强内部控制作为操作风险管理的有效手段，与此相关的内部措施至少应当包括：
部门之间具有明确的职责分工以及相关职能的适当分离，以避免潜在的利益冲突； 密切监测遵守指定风险限额或权限的情况； 对接触和使用银行资产的记录进行安全监控；n 《商业银行内部控制指引》
第四条 商业银行内部控制应当贯彻全面、审慎、有效、独立的原则，包括： 内部控制应当渗透商业银行的各项业务过程和各个操作环节，覆盖所有的部门和岗位，并由全体人员参与，任何决策或操作均应当有案可查。
陶瓷灯头
密封杯
第一条 商业银行应当建立涵盖各项业务、全行范围的风险管理系统，开发和运用风险量化评估的方法和模型，对信用风险、市场风险、流动性风险、操作风险等各类风险进行持续的监控。
第一百二二条 商业银行应当建立和健全网络管理系统，有效地管理网络的安全、故障、性能、配置等，并对接入国际互联网实施有效的安全管理。
带灯放大镜
第一百二四条 商业银行应当对计算机信息系统的接入建立适当的授权程序，并对接入后的操作进行安全控制。 输入计算机信息系统的数据应当核对无误，数据的修改应当经过批准并建立日志。
第一百二六条 商业银行的网络设备、操作系统、数据库系统、应用程序等均应当设置必要的日志。 日志应当能够满足各类内部和外部审计的需要。
第一百二八条 商业银行运用计算机处理业务，应当具有可复核性和可追溯性，并为有关的审计或检查留有接口。n 《金融机构计算机信息系统安全保护工作暂行规定》
第二五条 金融机构应当实行权限分散原则。明确系统管理员、系统操作员、终端操作员、程序员的权限和操作范围。建立系统运行日志，每天打印重要的操作清单。日志信息长期保存，以备稽查。
第二八条 金融机构应当用软、硬件技术严格控制各级用户对数据信息的访问权限，包括访问的方式和内容。5 解决方案
5、1 部署拓扑示意图运维安全审计系统部署示意图如下：部署说明：l 针对运维审计系统的工作特点，推荐在金融机构交换机划分出“安全运维网段”，并使该网段路由可达到任何区域；l 在安全运维网段部署2台运维安全审计系统1000P，单臂部署，且工作为双机热备模式；l 通过设置ACL（访问控制列表），只允许主机、网络、安全等维护人员（行内、行外）通过运维安全审计系统访问服务器，而不允许直接访问这些关键资源；
5、2 安全实现过程实现过程为：1)
主机维护人员（行内、行外）首先经过运维安全审计系统进行身份认证；2)
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议