1. 数据库安全审计系统的市场分析
1、以色列的Imperva，该系统功能还是满强大的，通过IDP探针，串联部署，阻断数据库数据安全威胁。但国内用户使用由于全英文界面，加上配置数据库安全策略很复杂，非专业数据库DAB操作起来很困难。更重要的是国内使用该产品，其技术手段需要依靠合作的数据库厂商来做支持。
2、IBM的Guardium：该系统强过国内的大部分产品，但由于其设计思路的原因，部署上需要在数据库服务器端安装“S-TAP” 轻量级系统探针；分级部署时需在数据库服务器端安装“S-GATE”，在总控服务器安装“Z-TAP”。该系统按照国外的审计需求，只针对满足国外需求的审计数据进行审计。过滤了大部分可能对国内用户有实用价值的审计信息。也是全英文界面，数据库安全审计策略配置很复杂，非专业数据库DAB操作起来很困难。
以上两个产品是国外的主流产品，国内市场上基本数据高端专业客户使用，价格很高。对国内绝大多数用户来说，具有有用性，但缺乏实用性，操作维护困难。只记录“关注”事件，逃避“IO”，失去“事后”追踪有用性， 增加“事前”管理和使用难度。 国内数据库产品主要厂商：
1、上讯信息——数据库安全审计系统；
2、北京安信通——数据库审计系统；
3、北京国都兴业——慧眼数据库审计系统；
4、深圳昂楷科技——数据库多重审计系统AAS；
5、安华金和——数据库监控与审计系统；
6、安恒信息——明御数据库审计和风险控制系统；
7、北京天融信——网络卫士数据库审计系统TopAudit-DB （简称 TA-DB）
8、北京启明星辰——天玥网络安全审计系统
9、北京莱克斯科技——ClearNet DBA数据库审计系统
10、杭州思福迪——LOGBASE业务数据库审计系统
11、杭州帕拉迪——DBxpert数据库审计系统
12、福建海峡信息——黑盾数据库安全审计系统
主要分为：国内原先具有网络审计产品的厂商，在网络审计产品的基础上经过简单包装，推出的数据库审计产品；国内厂商专门针对数据库通讯协议的特点，开发出专门的数据库审计产品；国外的数据库审计产品；OEM第三方的数据库审计产品，OEM对象可能是国内的产品，也可能是国外的产品。
区分这些数据库安全审计产品可以从几个方面来测试：
1、双向审计：只能实现单包返回状态分析，不能实现对查询结果进行分析。
2、长sql语句漏审：超长SQL语句无法解析记录，提供逃避审计通道；
3、完全协议解析：解析协议解码不完全（无会话技术就不可能完全解码）；
4、参数值与SQL语句匹配：变量绑定不支持或不完整（审计素材有用性缺失）；
5、海量数据分析：无法全部存储分析审计数据，记录之后，不能查询；
6、海量存储：无法记录下原始数据包，缺乏最原始的审计依据；
7、及时警告：事后报警，做不到事前防范，事中报警；
8、多语句无法有效分割：长会话记录分散记录，审计困难；
9、客户影响：部分产品需要改变网络拓扑，甚至需要在数据库服务器上安装采集器，易造成安全漏洞。
10、应用用户关联：三层应用用户关联有20%以上会出现漏审和错审，尤其在高并发下更是如此。
这里重点评价一下好的数据库审计系统要求：能展现数据库完整会话操作的系统。采用数据库访问协议完全解析技术，能实现对超过1460字节长度的SQL语句完整解析。除了能解析数据库绑定变量，还能解析该绑定变量的值。能完整记录SQL语句的返回结果集。同时由于是国内厂家自主知识产权，技术支持也比国外产品更直接、更有效。
如果说好的数据库审计系统的特征如下：
1、能展现数据库完整会话操作；
2、具备对超过1460字节长度的SQL语句完整解析；
3、具备解析数据库绑定变量和该绑定变量的值；
4、能完整记录SELECT语句的返回结果集； 上市公司：萨班斯法案的要求
电信、军工、烟草、电力等行业需求
等级保护、分级保护的要求
2. 如何使用 websphere mq fte 数据库 logger
本教程详细地介绍了 IBM WebSphere MQ FTE 所提供的数据库 logger 功能以及配置过程。本文首先介绍 IBM WebSphere MQ FTE 中的日志功能，并通过具体实例演示如何进行数据库 logger 的配置。
目标
希望读者通过本教程，能够了解：
WebSphere MQ FTE 中所提供的数据库 logger 功能；
配置 WMQ FTE 数据库 logger 的详细过程；
先决条件
本教程要求读者具备 WebSphere MQ、WebSphere MQ FTE 以及数据库的基本概念、基本功能和基本操作步骤。
回页首
前言
目前，大多数企业都存在着文件传输需求，文件尺寸从大到上百兆，小至十几 K 不等；文件传输频度不一；传输技术复杂多样，通常采用 FTP、NFS 或来自多家厂商的中间件，甚至包括自主开发的文件传输工具。这些解决方案构基本上都会存在构建、管理、维护以及应用能力方面的问题。IBM WebSphere MQ File Transfer Edition（简称 MQFTE）结合 WebSphere MQ 的消息传输解决方案，提供了受管的文件传输功能，实现了消息传输平台与文件传输平台的完美统一，逐步成为信息传输领域的主流解决方案。
受管的文件传输中一个重要的环节是对传输日志的记录与管理。MQFTE 提供两种机制，一种是将文件传输信息发布的特定的主题，以供订阅；另一种是将文件传输信息存储在数据库中，以备日后查询、跟踪或审计。本文将详细介绍后一种技术手段，即 MQFTE 的数据库 logger 功能。
回页首
WebSphere MQ FTE 数据库 logger 介绍
WebSphere MQ FTE 简介
MQFTE + WebSphere MQ 是目前最有效的并且经过市场验证的受管文件传输产品 (Managed File Transfer Suites)。MQFTE 与 WebSphere MQ 提供了可靠的通信、审计、日志、管理等能力，使之成为受管的文件和数据传输的基础性平台。
MQFTE 可以实现如下功能：
在异构系统间提供可靠的文件传输
对于传输的文件没有大小限制
集中式监控，产生状态和日志信息帮助审计传输过程
支持定制传输时间表和有条件的触发传输
实现与 SOA 架构的整合
MQFTE 组件架构如图 1 所示，其中各组件功能总结如下：
图 1. MQFTE 组件图
代理 代理构成了文件传输任务的端点。代理所存在的系统有文件传输需求，代理必须连接队列管理器。每个代理在其相关联的队列管理器上都有自己的队列集合，因此一个队列管理器可以驻留一个或多个代理。代理不必与命令队列管理器或代理队列管理器位于相同主机上。
代理队列管理器 每个代理都需要位于一个 MQ 队列管理器之上的一组队列。这些队列是 FTE 内部队列系统，对于最终用户而言是透明的。与代理相关联的队列管理器称为代理队列管理器，它可能是本地或远程的。
命令队列管理器 命令行和 WebSphere FTE MQ Explorer 插件工具允许将命令发送到 FTE 代理。在发送这些命令时工具所连接的队列管理器称为命令队列管理器，它可能与代理队列管理器有所不同。每个命令都在该队列管理器上创建临时动态队列，该队列管理器可能来自 WebSphere MQ V6.0 或更新版本。代理不必连接到相同的命令队列管理器上，此队列管理器可能是本地或远程的。
协调队列管理器 协调队列管理器必须是 WebSphere MQ V7.0 或更新版本的队列管理器，具有发布 / 订阅特性。在设置过程中，在协调队列管理器上创建一个称为 SYSTEM.FTE 的主题，代理将文件传输流程信息发送到此主题，并且当订阅者存在时，信息会保存在 WebSphere MQ 队列中。
WebSphere MQ FTE 数据库 logger
典型的基于 MQFTE 的文件传输过程中，代理将文件传输流程信息发送到具有发布 / 订阅功能的协调队列管理器之上的 SYSTEM.FTE 主题，当订阅者存在时，信息会保存在 WebSphere MQ 队列中以备其他应用订阅使用。MQFTE 的数据库 logger 是 MQFTE 日志功能的拓展，是 MQFTE 的可选组件，它将 SYSTEM.FTE 主题中的文件传输信息拷贝到数据库中，便于日后的审计、分析等操作，如图 1 中红色虚线区域所示。
MQFTE 的数据库 logger 是独立的 java 应用，必须安装在具有协同队列管理器以及数据库的机器上，数据库 logger 采用队列管理器的 XA 支持功能作为事务管理器，保证跨队列管理器以及数据库的全局事务完整性。
数据库 logger 采用 MQ binding 方式与本地协调队列管理器连接，采用 type 2 JDBC 驱动程序连接数据库。
数据库 logger 安装
用户可以选择单独安装数据库 logger，也可以在安装 WMQFTE Remote Tools 时安装数据库 logger。
数据库 logger 支持平台
数据库
－ DB2 或 ORACLE 数据库
－ Type 2 JDBC 驱动程序
支持平台
－ WMQ7.0.0.1
－ AIX/DB2 9.5
－ Windows2003 (32-bit) /DB2 9.1 , DB2 9.5, Oracele10.2
－ Windows XP (32-bit)/DB2 9.1, DB2 9.5, Oracle10.2
数据库 logger 相关队列
数据库 logger 使用两个特定队列作为其运行与管理的基础。如果是 WMQ FTE7.0.0.1 或以后版本，这两个队列将在 fteSetupCoordination 命令所产生的 MQSC 文件中定义；如果使用之前版本，则需要手工定义。
3. 数据仓库的技术发展
从数据库到数据仓库
企业的数据处理大致分为两类：一类是操作型处理，也称为联机事务处理，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。另一类是分析型处理，一般针对某些主题的历史数据进行分析，支持管理决策。
两者具有不同的特征，主要体现在以下几个方面。
1、处理性能
日常业务涉及频繁、简单的数据存取，因此对操作型处理的性能要求是比较高的，需要数据库能够在很短时间内做出反应。
2、数据集成
企业的操作型处理通常较为分散，传统数据库面向应用的特性使数据集成困难。
3、数据更新
操作型处理主要由原子事务组成，数据更新频繁，需要并行控制和恢复机制。
4、数据时限
操作型处理主要服务于日常的业务操作。
5、数据综合
操作型处理系统通常只具有简单的统计功能。
数据库已经在信息技术领域有了广泛的应用，我们社会生活的各个部门，几乎都有各种各样的数据库保存着与我们的生活息息相关的各种数据。作为数据库的一个分支，数据仓库概念的提出，相对于数据库从时间上就近得多。美国着名信息工程专家WilliamInmON博士在90年代初提出了数据仓库概念的一个表述，认为：“一个数据仓库通常是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，它用于对管理决策过程的支持。”
这里的主题，是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。
集成，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。
随时间变化，是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。
数据库安全
计算机攻击、内部人员违法行为，以及各种监管要求，正促使组织寻求新的途径来保护其在商业数据库系统中的企业和客户数据。
您可以采取八个步骤保护数据仓库并实现对关键法规的遵从。
1. 发现
使用发现工具发现敏感数据的变化。
2.漏洞和配置评估
评估数据库配置，确保它们不存在安全漏洞。这包括验证在操作系统上安装数据库的方式(比如检查数据库配置文件和可执行程序的文件权限)，以及验证数据库自身内部的配置选项(比如多少次登录失败之后锁定帐户，或者为关键表分配何种权限)。
3. 加强保护
通过漏洞评估，删除不使用的所有功能和选项。
4. 变更审计
通过变更审计工具加强安全保护配置，这些工具能够比较配置的快照(在操作系统和数据库两个级别上)，并在发生可能影响数据库安全的变更时，立即发出警告。
5. 数据库活动监控(DAM)
通过及时检测入侵和误用来限制信息暴露，实时监控数据库活动。
6. 审计
必须为影响安全性状态、数据完整性或敏感数据查看的所有数据库活动生成和维护安全、防否认的审计线索。
7.身份验证、访问控制和授权管理
必须对用户进行身份验证，确保每个用户拥有完整的责任，并通过管理特权来限制对数据的访问。
8. 加密
使用加密来以不可读的方式呈现敏感数据，这样攻击者就无法从数据库外部对数据进行未授权访问。
如何应对监控需求
数据，作为企业核心资产，越来越受到企业的关注，一旦发生非法访问、数据篡改、数据盗取，将给企业带来巨大损失。数据库作为数据的核心载体，其安全性就更加重要。
面对数据库的安全问题，企业常常遇到以下主要挑战：数据库被恶意访问、攻击、甚至遭到数据偷窃，而您不能及时地发现这些恶意的操作； 不了解数据使用者对数据库的访问细节，从而不能保证您对数据安全的管理；
信息安全同样会带来审计问题，当今全球对合规/ 审计要求越来越严格，由于不满足合规要求而导致处罚的事件屡见不鲜。美国《萨班斯法案》的强制性要求曾导致2007年7月5日中国第一家海外上市公司—华晨中国汽车控股有限公司从美国纽约证券交易所退市。
有关信息安全的合规/审计要求，中国政府也进行了大量的强化工作，例如，为了加强商业银行信息科技风险管理，银监会出台了《商业银行信息科技风险管理指引》规则，中国政府——财政部、证监会、银监会、保监会及审计署等五部委会联合发布“中国版萨班尼斯－奥克斯利法案（以下简称‘C-SOX法案’）”——《企业内部控制基本规范》。
面对合规/审计要求，企业往往面临以下挑战：
·不能做到持续性审计
用户审计主要是针对数据库、应用系统日志做审计，这些日志内容非常庞大，DBA（数
据库管理员）和信息安全审计人员的审计工作就只能做事后分析，分析时间也长。不能做到持续性审计。
·审计并不规范
用户审计的内容和表格主要是根据外部审计人员要求和内部安全管理要素来考虑，这些
审计工作的好坏基本上取决于DBA和信息安全审计人员的经验和技能，这些不能有效成为公司规范和满足外部审计要求。
·数据库管理员权责没有完全区分开，导致审计效果问题
数据库管理和审计原始数据的收集实际上都是由DBA来做的，这就导致了DBA的权责不明确，DBA没办法客观审计自己所做的工作，尽管用户设置了信息安全审计人员，但该角色的审计工作的部分证据建立在DBA初步审计基础上，因此审计效果与可靠性存问题。
·审计并不完整
人工审计需要面对海量的日志，不可能对所有数据进行细致审计；审计报告就未必能满足
100%可见性。
为了满足企业的信息安全、合规、审计等需求，IBM公司推出了“CARS”企业信息架构，该架构主要从“法规遵从”（Compliance）、“信息可用”(Availability)、“信息保留”(Retention)、“信息安全”(Security) 四个方面进行了全面的满足和保护。不仅如此，IBM Guardium数据库安全、合规、审计、监控解决方案的推出，针对了“法规遵从”和“信息安全”进行了专项治理和加强。
Guardium数据库安全、合规、审计、监控解决方案，以软硬件一体服务器的方式，大大增强数据库安全性，满足并方便审计工作，提升性能，并简化了安装部署工作。可以防止对数据库的破坏、恶意访问、偷窃数据，可帮助判断客户关键敏感的数据在什么地方；谁在使用这些数据；控制对数据库中数据的访问，并可监控特权用户；帮助企业强制执行安全规范；检查薄弱环节、漏洞，防止对数据库配置的改动；满足合规/审计的要求，并可简化内部和外部审计、合规的过程并使其自动化，增强运作效率；管理安全的复杂性。
4. 数据库有哪几种
一、关系数据库
关系型数据库，存储的格式可以直观地反映实体间的关系。关系型数据库和常见的表格比较相似，关系型数据库中表与表之间是有很多复杂的关联关系的。
常见的关系型数据库有Mysql，SqlServer等。在轻量或者小型的应用中，使用不同的关系型数据库对系统的性能影响不大，但是在构建大型应用时，则需要根据应用的业务需求和性能需求，选择合适的关系型数据库。
虽然关系型数据库有很多，但是大多数都遵循SQL（结构化查询语言，Structured Query Language）标准。 常见的操作有查询，新增，更新，删除，求和，排序等。
查询语句：SELECT param FROM table WHERE condition 该语句可以理解为从 table 中查询出满足 condition 条件的字段 param。
新增语句：INSERT INTO table （param1，param2，param3） VALUES （value1，value2，value3） 该语句可以理解为向table中的param1，param2，param3字段中分别插入value1，value2，value3。
更新语句：UPDATE table SET param=new_value WHERE condition 该语句可以理解为将满足condition条件的字段param更新为 new_value 值。
删除语句：DELETE FROM table WHERE condition 该语句可以理解为将满足condition条件的数据全部删除。
去重查询：SELECT DISTINCT param FROM table WHERE condition 该语句可以理解为从表table中查询出满足条件condition的字段param，但是param中重复的值只能出现一次。
排序查询：SELECT param FROM table WHERE condition ORDER BY param1该语句可以理解为从表table 中查询出满足condition条件的param，并且要按照param1升序的顺序进行排序。
总体来说， 数据库的SELECT，INSERT，UPDATE，DELETE对应了我们常用的增删改查四种操作。
关系型数据库对于结构化数据的处理更合适，如学生成绩、地址等，这样的数据一般情况下需要使用结构化的查询，例如join，这样的情况下，关系型数据库就会比NoSQL数据库性能更优，而且精确度更高。
由于结构化数据的规模不算太大，数据规模的增长通常也是可预期的，所以针对结构化数据使用关系型数据库更好。关系型数据库十分注意数据操作的事务性、一致性，如果对这方面的要求关系型数据库无疑可以很好的满足。
二、非关系型数据库（NoSQL）
随着近些年技术方向的不断拓展，大量的NoSql数据库如MongoDB、Redis、Memcache出于简化数据库结构、避免冗余、影响性能的表连接、摒弃复杂分布式的目的被设计。
指的是分布式的、非关系型的、不保证遵循ACID原则的数据存储系统。NoSQL数据库技术与CAP理论、一致性哈希算法有密切关系。所谓CAP理论，简单来说就是一个分布式系统不可能满足可用性、一致性与分区容错性这三个要求，一次性满足两种要求是该系统的上限。
而一致性哈希算法则指的是NoSQL数据库在应用过程中，为满足工作需求而在通常情况下产生的一种数据算法，该算法能有效解决工作方面的诸多问题但也存在弊端，即工作完成质量会随着节点的变化而产生波动，当节点过多时，相关工作结果就无法那么准确。
这一问题使整个系统的工作效率受到影响，导致整个数据库系统的数据乱码与出错率大大提高，甚至会出现数据节点的内容迁移，产生错误的代码信息。
但尽管如此，NoSQL数据库技术还是具有非常明显的应用优势，如数据库结构相对简单，在大数据量下的读写性能好；能满足随时存储自定义数据格式需求，非常适用于大数据处理工作。
NoSQL数据库适合追求速度和可扩展性、业务多变的应用场景。
对于非结构化数据的处理更合适，如文章、评论，这些数据如全文搜索、机器学习通常只用于模糊处理，并不需要像结构化数据一样，进行精确查询，而且这类数据的数据规模往往是海量的，数据规模的增长往往也是不可能预期的；
而NoSQL数据库的扩展能力几乎也是无限的，所以NoSQL数据库可以很好的满足这一类数据的存储。
NoSQL数据库利用key-value可以大量的获取大量的非结构化数据，并且数据的获取效率很高，但用它查询结构化数据效果就比较差。
目前NoSQL数据库仍然没有一个统一的标准，它现在有四种大的分类：
1、键值对存储（key-value）：代表软件Redis，它的优点能够进行数据的快速查询，而缺点是需要存储数据之间的关系。
2、列存储：代表软件Hbase，它的优点是对数据能快速查询，数据存储的扩展性强。而缺点是数据库的功能有局限性。
3、文档数据库存储：代表软件MongoDB，它的优点是对数据结构要求不特别的严格。而缺点是查询性的性能不好，同时缺少一种统一查询语言。
4、图形数据库存储：代表软件InfoGrid，它的优点可以方便的利用图结构相关算法进行计算。而缺点是要想得到结果必须进行整个图的计算，而且遇到不适合的数据模型时，图形数据库很难使用。
安全
数据库安全涉及保护数据库内容、其所有者和用户的所有各个方面。它的范围从防止有意的未经授权的数据库使用到未经授权的实体（例如，个人或计算机程序）无意的数据库访问。
数据库访问控制涉及控制谁（一个人或某个计算机程序）可以访问数据库中的哪些信息。该信息可以包括特定的数据库对象（例如，记录类型、特定记录、数据结构）;
对特定对象的特定计算（例如，查询类型或特定查询），或者使用到前者的特定访问路径（例如，使用特定索引）或其他数据结构来访问信息）。
数据库访问控制由使用专用受保护安全 DBMS 接口的特别授权（由数据库所有者）人员设置。
这可以在个人基础上直接管理，或者通过将个人和特权分配给组，或者（在最复杂的模型中）通过将个人和组分配给角色，然后授予权利。数据安全可防止未经授权的用户查看或更新数据库。使用密码，用户可以访问整个数据库或它的子集，称为“子模式”。
例如，员工数据库可以包含有关单个员工的所有数据，但一组用户可能仅被授权查看工资数据，而其他用户仅被允许访问工作历史和医疗数据。如果 DBMS 提供了一种交互式输入和更新数据库以及查询数据库的方法，则此功能允许管理个人数据库。
数据安全通常涉及保护特定的数据块，包括物理保护（即免受损坏、破坏或移除；例如，参见物理安全），或将它们或它们的一部分解释为有意义的信息（例如，通过查看它们组成的位串，得出特定的有效信用卡号；例如，参见数据加密）。
更改和访问日志记录谁访问了哪些属性、更改了什么以及何时更改。日志服务通过保留访问发生和更改的记录，允许以后进行取证数据库审计。有时应用程序级代码用于记录更改而不是将其留给数据库。可以设置监控以尝试检测安全漏洞。
以上内容参考网络-数据库