IBM Optim 数据生命周期管理解决方案
Optim 测试数据管理解决方案
- 建立大小适中、目标明确的测试环境
- 提高新应用程序开发质量与上线速度
- 加速测试流程中的交互性与可控性
Optim 隐私数据保护解决方案
- 敏感数据脱密、漂白
- 保护客户隐私数据，遵循企业内外部数
- 据安全管理规范
Optim 控制数据增长解决方案
- 提升核心业务系统性能
- 控制数据增长并节省存储投资
- 支持数据的长期合规性保留
- 为应用淘汰、退出提供有效的历史
- 数据访问能力
- 为应用系统升级提供支持
IBM Optim 数据增长(数据库归档) 解决方案
控制核心系统数据增长——“扩容”还是“瘦身”？
- 绿色数据中心——节能减排？
- 生产系统瘦身后历史数据如何管理、如何访问、如何存储、成本如何？
- 如何归档、清理历史/低访问频度数据，为企业核心数据库“瘦身”
- 如何保证数据格式固化，确保数据长期的延续性和访问一致性
- 如何应对应用版本变更、升级、淘汰过程中的下线数据管理问题
IBM Optim 数据归档解决方案
OPTIM数据增长管理
数 复
- 据 程，需要在新的 境中 建 史 据 数 审计过 环 创 历 数 库
- 由于 更，生 系 需要恢 部分 史 据 业务变 产 统 复 历 数
据 案例 数 归档
- 某城市商 行系 由于 据 的要求，需要恢 某用 在 业银 统 数 审计 复 户 2008全年的交易 据 数
Optim 据恢 特点 数 复
- 性恢 ，恢 据 选择 复 复关联业务数
- 同 恢 据和 据 时 复数 数 结构
- 跨越 据 恢 异构数 库 复
Optim 部署架构
Optim 归档实施成果——生产环境持续优化
归档和备份 —— 特征与区别
归档——用于清理与保持
- 用于检索。
- 移动数据。
- 提高运营效率。
- 长期存在。
- 通常可以保护数据的安全。
- 有助于满足法规遵从需求。
归档系统用于从数据库中清理访问频率极低并且占用大量系统资源与运维代价的历史数据，并对归档后的数据提供合理的数据访问机制，实现数据价值与相应的存储技术和管理相匹配。
备份——用于恢复
- 用于运营支持和恢复(HA)。
- 复制数据。
- 支持可用性。
- 短期保存。
- 通常需要覆盖数据。
- 对于满足法规遵从需求来说，并不是一个理想的解决方案。
备份系统仅用于保障数据库系统出现意外损坏时的及时恢复，备份后的镜像只能通过恢复操作才能访问，备份或恢复响应时间与数据库大小成正比。
Optim 数据库归档市场份额——竞争分析
客户痛点
- 生产环境数据库大小持续增长，系统性能与服务保障能力难以保障。
- 数据库规模不断膨胀，备份恢复能力显著下降，系统高可用性能力难以保障。
- 生产环境服务器、存储等投资持续增加，成本高居不下。
- 银监会、人民银行以及内部审计部门对数据的监管、访问需求，对系统运维带来沉重负担。
- 大量业务交易数据需要长期保留，生产环境难以实现合规性数据保持。
- 现有数据库备份方式保留历史数据，历史数据的访问、恢复代价极大，存在较大风险
建议访谈客户目标
如何向客户提问？
- a) 您的核心银行系统、信贷系统是何时上线的？
- b) 是否有哪些应用性能较低，近期计划硬件升级或扩容？
- c) 目前的数据库大小？平均年增长率？系统备份或恢复平均时间，是否能满足高可用性需求？
- d) 对于司法机关提出需访问超过10年前某些账户下的特定交易数据，您是如何应对的？
- e) 您是否需要经常面临银监会(局)的审计，是否有内部审计需求？
- f) 审计监管数据从哪里获得？是否占用了运维部门较多的精力，是否对生产环境有影响？
应该向客户阐述的基本观点：
- a) 绝大多数核心应用访问的数据都是近期的数据。
- b) 大量历史数据占用了大量生产系统的高端服务器和存储资源，但其实访问频率极低。
- c) 数据库越大，系统恢复难度越高，一旦系统宕机需要恢复数据，系统服务难以短时间恢复。
- d) 生产环境下的服务器和存储普遍采用高端设备，升级、扩容成本极高，软件成本也会相应增加。
- e) 您需要面对的数据审计、监管需求会越来越多，您需要专门的方案支持多样的审计需求。
- f) 历史数据访问难以事先规划，时间跨度和灵活性要求可能极大，您很难在通过应用和技术手段满足。
结论：您需要建立一套成熟稳定的历史数据清理和归档技术方案，以便削减IT成本、提高系统可用性、并满足各类审计需求。
IBM Optim 测试数据与隐私数据漂白解决方案
IBM Optim 测试数据管理与隐私数据保护解决方案
从生产环境抽取出符合业务逻辑的数据集合，帮助用户迅速构建大小适中的测试、开发、培训环境，并保护隐私数据的安全性。
- 子集管理——条件与抽样
- 隐私保护——规则与逻辑
- 版本管理——创建与异构
- 元数据管理——恢复与比对
- 成本控制——压缩与迭代
Optim —— 数据漂白 漂白后数据依然保证可用！
为什么客户会对Optim TDM&DP感兴趣？
——现有测试数据准备方法与缺陷分析
“备数据”——从生产全库备份，手工或脚本方式批量漂白
- 恢复到测试环境后漂白，漂白规则简化，数据逻辑无法保障
- 难以周期性获取，无法获得最新数据(更新的结构、新业务数据)
- 无法实现版本管理，获取成本与使用(恢复)成本都较高
- “造数据”——测试环境中手工模拟业务流程，生成少量测试数据
- 测试人员工作量巨大，仅能验证少量特定规则；而由于业务规则的复杂性，业务场景往
往丢失(规则校验导致数据模拟出现多条路径），覆盖度不足。
- 不适用于自动化测试或性能测试等需要大量测试数据的场景
- 对测试人员的业务知识背景要求较高
- 访谈客户目标
- 运维部门、测试、开发中心主管
- 不宜与现有客户应用的开发商讨论
如何向客户提问？
- a) 您如何准备开发、测试环境中的数据？
- b) 开发、测试进度能否保证？导致进度无法保证的原因是什么？什么工作花费的时间最长在哪里？
- c) 您是否已对测试环境的数据进行了漂白？谁在做这些漂白操作？漂白质量如何？
- d) 您的开发、测试环境是否安全？开发商是否能在开发测试环境中获得敏感数据？
应该向客户阐述的基本观点：
- a) 备份方式或手工方式获取测试数据，普遍存在成本、安全和数据质量问题。
- b) 测试数据准备过程往往是测试、开发过程中工作量最大、最消耗时间的部分。
- c) 大量跨数据库的测试场景，测试数据准备难度极大，往往不得不使用真实数据。
- d) 大多数客户都已经对测试环境中的数据做了基本漂白，但存在如下问题：
- 1. 漂白手段简单(如使用同一个客户名测批量业务)，数据质量无法满足测试需求。
- 2. —— 往往是开发商自己做漂白，然后自己做测试，大多数敷衍了事。 没有人愿意为自己添麻烦！
- 3. 手工漂白方式，漂白规则通过手工配置，存在逆向推导可能，无法真正保证数据安全。
结论：您需要一个简单、提供大量已封装漂白规则的自动化测试数据管理与漂白工具。
有关测试数据管理——问题与解决方案
IBM Optim 价值与优势
- 数据库归档方案：全球排名第一，压倒性优势产品！
- 数据漂白方案：除自主开发外，国内基本没有竞争厂商。
- 风险小：对现有生产环境、现有应用无需任何改造需求
- 实施容易：以产品、规则配置为主，基本无需二次开发量，实施周期短。
- 效果直观：漂白效果直观、压缩效果明显；可计算、可评估对存储、服务器资源的节省。
- 通用性：支持所有主流数据库，唯一支持Teradata的厂商。
- 国内已有金融行业客户案例
- ICBC，BOC ，国开行，PICC—— Optim TDM & Data Privacy
- —— 成都银行、锦州银行 Optim TDM & Data Privacy
- —— 山东农信 Optim Data Growth
Optim 报价方式—— 根据源数据库配置计算Optim PVU
- Optim Data Growth Solution ：
- D08BFLL IBM OPTIM DATA GROWTH SOLUTION ( 归档主模块)
- D08BKLL IBM OPTIM OPEN DATA MANAGER Option ( 归档文件访问选件)
- Optim Test Data Management (TDM) &Data Privacy Solution：
- D08E9LL IBM OPTIM TDM Solution (测试数据管理主模块)
- D08FJLL IBM OPTIM DATA PRIVACY OPTION (隐私数据保护选件)
- 针对套装软件Oracle EBS, Siebel等Optim Part Number有所不同。
- 最新版本: Optim v8.1
- PVU 计价方式：根据被抽取源系统的Core数量计算Optim PVU数量，即按被抽取的数据库CPU数量计算Optim报价数量。
- 大部分银行客户往往同时具备归档与漂白的需求，可以打包销售。
- Lesson Learned：推动客户立项流程和紧跟客户项目进度是落单关键！
IBM Guardium 数据库安全监控、审计解决方案
——数据库与特权用户的数据访问监控、报警与安全审计
IBM Guardium: 数据库安全、风险管理和管治解决方案
Guardium 实时数据库监控技术——网络旁路式监控
S-TAP:数据库服务器低负载, 高安全的驱动程序。
- 非入侵、网络旁路的方式
- 数据库引擎之外部署
- 性能影响极小(2-3%)
- 无需DBMS及应用的任何变更
- 跨DBMS类型及平台
- 对包括DBA本地访问在内的所有用户的数据
- 库访问行为提供100%可见性
Span-Port：路由器侧映射端口
- 仅负责审计、监控，不与DBA存在任何职责覆盖
- 不依赖任何DBMS的事务、审计日志，如上两
- 种日志本身也极容易遭受攻击精细粒度的实时安
- 全策略、审计能力
- Wh, what, when, how
- 自动化合规及审计报表生成、升级、签报等
漏洞评估，识别风险
3种类型的安全规则 (Guardium Policy)
- 访问规则(access rule):用于客户端请求判定
- 挤出规则(extrusion rule): 用于检查服务器端输出结果
- 异常规则(exception rule):用于评估服务器端返回的异常信息
可伸缩的多层架构——支持多级部署架构
Guardium 能在最短时间内审计到以下场景
- 谁在修改数据库模式或删除表?
- 何时发生非法程序修改数据?
- DBA和外包用户对数据库做了什么操作?
- 发生多少次登陆失败?
- 谁在提取敏感信息?
- 哪个节点在访问数据?
- 哪个应用在访问数据?
- 数据如何被访问?
- 基于时间的访问模式如何?
- 数据库报什么错?
- 敏感数据暴露给谁?
- 何时有人在使用SQL命令?
客户痛点
- 防火墙、加密机等安全手段或技术无法防范合法用户或合法应用的非法、非授权操作。
- 大量应用系统、数据库实例，无法实现统一监控、统一安全策略定制与统一报警、报表。
- 无法获知客户信息、交易信息等敏感数据何时被何人通过何种渠道访问过？
- DBA 等特权用户操作完全无法控制或被有效监控。
- 对数据库中发生的违规操作缺乏实时报警手段和机制。
- 对如用户登录攻击、SQL注入式等攻击，无法识别和获知。
- 客户无法获知数据库、操作系统等是否存在已知的安全漏洞？
- 数据库自身审计手段会对数据库性能造成极大影响，基本不可用。
- 审计日志也可能被DBA，操作系统用户等进行篡改。
- 关注数据安全，但缺乏数据安全性策略指导意见，不知道如何收集或发布审计报表。
建议访谈客户目标
如何向客户提问？
- a) 您是否了解DBA等内部运维人员每天都做过哪些操作？是否有违规操作？
- b) 您对数据库采取了哪些安全防范措施？
- c) 您是否了解操作系统和数据库存在哪些安全漏洞？
- d) 您是否尝试过数据库自身审计日志作为数据库安全手段？效果如何？
- e) 您遇到过数据库遭遇攻击的情况？
- f) 如果数据发生泄漏，您是如何进行调查的，需要哪些部门参与？
- g) 您是否需要向某些部门或机构提供数据库安全相关的审计报表？您现在是如何应对的？
应该向客户阐述的基本观点：
- a) 数据安全审计工作不应由DBA、Root用户等负责，应采取独立的审计手段。
- b) 应提供有效手段监控DBA等授权用户的操作，有效控制内部风险。
- c) 现有数据库、操作系统版本中，存在许多大量安全漏洞已在升级版本中发现和补救，您应该了解现有
- 系统中的已知漏洞。
- d) 数据库安全必须具备实时监控、报警能力，审计日志必须具备不可删除、不可更改特性。
- e) 数据库安全审计不应影响现有数据库、应用系统架构或配置，不应对生产环境负载影响过大。
- f) 数据库中的客户信息、交易日志等需要重点监控，是防范数据泄漏的关键对象。
结论：您应该建立一套具备权责分离、实时监控、实时报警、集中管理、集中配置的数据库安全监控与审计平台。
基于监控信息分析, Guardium 进而帮助企业应对风险挑战
IBM Guardium 对客户的价值定位
- 确保关键数据的隐私性和完整性
- 强制执行对关键系统中所有敏感数据的存取控制与变更管理
- 强制执行关键系统中所有用户行为的访问控制
- 涵盖所有应用和数据库基础设施
- · Oracle, SQL Server, IBM DB2 & Informix, Sybase, MySQL, Teradata
- · SAP, Oracle Financials, PeopleSoft, Siebel, Business Objects, …
增加运作效率
- 将内部控制自动化、集中化
- 涵盖各种不同和分布式的环境
- 迅捷地排除性能问题和应用错误等故障
- Guardium平台高强的扩容性在世界各地要求最高的数据中心得以证实
对基础设施和商务程序无不良影响
为什么选择Guardium 数据库安全、审计解决方案 ？
—— “绝对的市场领导地位” by Forrester
Guardium 金融行业典型客户
