Ⅰ 详解Yearning sql审核平台功能模块设计
Yearning SQL审核平台目前兼容99%的Mysql 标准SQL语法。
已知不支持的语句类型有:
下面对其中的功能模块做一下介绍，以下基于Yearning 2.0版本。
1、dashboard
dashboard主要展示Yearning各项数据包括用户数/数据源数/工单数/查询数以及其他图表,个人信息栏内用户可以修改密码/邮箱/真实姓名,同时可以查看该用户权限以及申请权限。
2、我的工单
展示用户提交的工单信息，对于执行失败/驳回的工单点击详细信息后可以重新修改sql并提交，对于执行成功的工单可以查看回滚语句并且快速提交SQL
3、工单-DDL
具有以下功能：
1)DDL相关SQL提交审核
2)查看表结构/索引
3)SQL语法高亮/自动补全
如果想获取表结构详细信息,必须选填表名并完整填写工单信息。所有的SQL只有在检测后错误等级为0时提交按钮才会激活,如下拉列表框内没有相关数据源显示请联系管理员是否赋予相应数据源权限
4、工单--DML
具备以下功能：
1）DML相关SQL提交审核
2）SQL语法高亮/自动补全
所有的SQL只有在检测后错误等级为0时提交按钮才会激活，如下拉列表框内没有相关数据源显示请联系管理员是否赋予相应数据源权限
5、查询
具备以下功能：
1）查询/导出数据
2）SQL语法高亮/自动补全
3）快速DML语句提交
如果开启查询审核,提交该查询申请后需对应审核人同意后方可查询，超级管理员在设置页面开启数据导出功能后,查询申请页面才会显示数据导出按钮（默认为.csv格式），获取表结构功能必须点击相应表名此为前置条件，快速提交功能仅支持DML语句，如下拉列表框内没有相关数据源显示请联系管理员是否赋予相应数据源权限
1、工单审核
功能：DDL/DML管理员审核并执行
实时刷新开关默认打开,如需删除记录请先关闭该开关。如定时工单的时间小于当前时间,执行该工单将会立即执行，目前仅支持延时工单中止,其他工单执行后无法中止！
2、查询审核
功能：用户查询审核
点击全部中止按钮将会中止所有用户的查询权限 如没有在设置页面开启查询审核开关，则默认用户查询申请提交后自动获得查询权限。 用户查询时限在设置页面进行设置
3、权限审核
功能：用户权限审核
权限由用户在首页个人信息处自主申请,管理员可在该审核页面决定是否给予用户申请的权限，由于用户可能存在胡乱申请权限的问题，所以 管理员在查看用户权限申请工单的同时可对工单申请的权限进行修改，确定具体的权限给予 。
1、工单审计
主要是审计工单的执行情况，记录工单的执行时间、申请人、执行人等信息。
2、查询审计
针对数据库查询记录做审计
1、用户
功能：创建/修改/删除用户
当多级审核关闭后系统并不会自动将角色为执行人的用户重置角色，需要自行重置相应用户角色
2、数据库
功能：添加/编辑/删除 数据源
所有添加的数据源应在添加之前点击测试连接按钮进行连接性测试,保证连接性。
数据源分为 查询数据源/非查询数据源 。查询数据源仅会出现在细粒度权限的查询数据源范围内。非查询数据源同理。（对于查询与执行数据源应拆分为二,保障线上执行数据源不会因为查询慢sql影响业务），此类别添加后 无法通过编辑进行修改 ，需要慎重添加。
3、用户权限
功能：用户权限修改/清空
批量赋权仅支持角色为使用人的用户。由于批量赋权为覆盖更新，仅适合在用户权限为空时使用。
4、设置
功能：
在配置填写无误后点击测试按钮进行相关测试, 使用消息推送前必须先打开对应消息推送开关,否则Yearning不会进行推送
5、审核规则
功能:设置SQL检测规则
保存后即时生效
后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~
Ⅱ 如何开启sqlserver2008数据库审计功能
SQLSERVER2008新增的审核功能
在sqlserver2008新增了审核功能，可以对服务器级别和数据库级别的操作进行审核/审计，事实上，事件通知、更改跟踪、变更数据捕获（CDC）
都不是用来做审计的，只是某些人乱用这些功能，也正因为乱用这些功能导致踩坑
事件通知：性能跟踪
更改跟踪：用Sync Services来构建偶尔连接的系统
变更数据捕获（CDC）：数据仓库的ETL 中的数据抽取（背后使用logreader）
而审核是SQLSERVER专门针对数据库安全的进行的审核，记住，他是专门的！
我们看一下审核的使用方法
审核对象
步骤一：创建审核对象，审核对象是跟保存路径关联的，所以如果你需要把审核操作日志保存到不同的路径就需要创建不同的审核对象
我们把审核操作日志保存在文件系统里，在创建之前我们还要在相关路径先创建好保存的文件夹，我们在D盘先创建sqlaudits文件夹，然后执行下面语句
--创建审核对象之前需要切换到master数据库
USE [master]
GO
CREATE SERVER AUDIT MyFileAudit TO FILE(FILEPATH='D:\sqlaudits') --这里指定文件夹不能指定文件，生成文件都会保存在这个文件夹
GO
实际上，我们在创建审核对象的同时可以指定审核选项，下面是相关脚本
把日志放在磁盘的好处是可以使用新增的TVF:sys.[fn_get_audit_file] 来过滤和排序审核数据，如果把审核数据保存在Windows 事件日志里查询起来非常麻烦
USE [master]
GO
CREATE SERVER AUDIT MyFileAudit TO FILE(
FILEPATH='D:\sqlaudits',
MAXSIZE=4GB,
MAX_ROLLOVER_FILES=6)
WITH (
ON_FAILURE=CONTINUE,
QUEUE_DELAY=1000);
ALTER SERVER AUDIT MyFileAudit WITH(STATE =ON)
MAXSIZE：指明每个审核日志文件的最大大小是4GB
MAX_ROLLOVER_FILES：指明滚动文件数目，类似于SQL ERRORLOG，达到多少个文件之后删除前面的历史文件，这里是6个文件
ON_FAILURE：指明当审核数据发生错误时的操作，这里是继续进行审核，如果指定shutdown，那么将会shutdown整个实例
queue_delay：指明审核数据写入的延迟时间，这里是1秒，最小值也是1秒，如果指定0表示是实时写入，当然性能也有一些影响
STATE：指明启动审核功能，STATE这个选项不能跟其他选项共用，所以只能单独一句
在修改审核选项的时候，需要先禁用审核，再开启审核
ALTER SERVER AUDIT MyFileAudit WITH(STATE =OFF)
ALTER SERVER AUDIT MyFileAudit WITH(QUEUE_DELAY =1000)
ALTER SERVER AUDIT MyFileAudit WITH(STATE =ON)
审核规范
在SQLSERVER审核里面有审核规范的概念，一个审核对象只能绑定一个审核规范，而一个审核规范可以绑定到多个审核对象
我们来看一下脚本
CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFile
FOR SERVER AUDIT MyFileAudit
ADD (failed_login_group),
ADD (successful_login_group)
WITH (STATE=ON)
GO
CREATE SERVER AUDIT MyAppAudit TO APPLICATION_LOG
GO
ALTER SERVER AUDIT MyAppAudit WITH(STATE =ON)
ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE=OFF)
GO
ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile
FOR SERVER AUDIT MyAppAudit
ADD (failed_login_group),
ADD (successful_login_group)
WITH (STATE=ON)
GO
我们创建一个服务器级别的审核规范CaptureLoginsToFile，然后再创建多一个审核对象MyAppAudit ，这个审核对象会把审核日志保存到Windows事件日志的应用程序日志里
我们禁用审核规范CaptureLoginsToFile，修改审核规范CaptureLoginsToFile属于审核对象MyAppAudit ，修改成功
而如果要把多个审核规范绑定到同一个审核对象则会报错
CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFileA
FOR SERVER AUDIT MyFileAudit
ADD (failed_login_group),
ADD (successful_login_group)
WITH (STATE=ON)
GO
CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFileB
FOR SERVER AUDIT MyFileAudit
ADD (failed_login_group),
ADD (successful_login_group)
WITH (STATE=ON)
GO
--消息 33230，级别 16，状态 1，第 86 行
--审核 'MyFileAudit' 的审核规范已经存在。
这里要说一下 ：审核对象和审核规范的修改 ，无论是审核对象还是审核规范，在修改他们的相关参数之前，他必须要先禁用，后修改，再启用
--禁用审核对象
ALTER SERVER AUDIT MyFileAudit WITH(STATE =OFF)
--禁用服务器级审核规范
ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE=OFF)
GO
--禁用数据库级审核规范
ALTER DATABASE AUDIT SPECIFICATION CaptureDBLoginsToFile WITH (STATE=OFF)
GO
--相关修改选项操作
--启用审核对象
ALTER SERVER AUDIT MyFileAudit WITH(STATE =ON)
--启用服务器级审核规范
ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE=ON)
GO
--启用数据库级审核规范
ALTER DATABASE AUDIT SPECIFICATION CaptureDBLoginsToFile WITH (STATE=ON)
GO
审核服务器级别事件
审核服务级别事件，我们一般用得最多的就是审核登录失败的事件，下面的脚本就是审核登录成功事件和登录失败事件
CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFile
FOR SERVER AUDIT MyFileAudit
ADD (failed_login_group),
ADD (successful_login_group)
WITH (STATE=ON)
GO
修改审核规范
--跟审核对象一样，更改审核规范时必须将其禁用
ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE =OFF)
ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile
ADD (login_change_password_gourp),
DROP (successful_login_group)
ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE =ON)
GO
审核操作组
每个审核操作组对应一种操作，在SQLSERVER2008里一共有35个操作组，包括备份和还原操作，数据库所有权的更改，从服务器和数据库角色中添加或删除登录用户
添加审核操作组的只需在审核规范里使用ADD，下面语句添加了登录用户修改密码操作的操作组
ADD (login_change_password_gourp)
这里说一下服务器审核的内部实际上使用的是SQL2008新增的扩展事件里面的其中一个package：SecAudit package，当然他内部也是使用扩展事件来收集服务器信息
审核数据库级别事件
数据库审核规范存在于他们的数据库中，不能审核tempdb中的数据库操作
CREATE DATABASE AUDIT SPECIFICATION和ALTER DATABASE AUDIT SPECIFICATION
工作方式跟服务器审核规范一样
在SQLSERVER2008里一共有15个数据库级别的操作组
7个数据库级别的审核操作是：select ,insert,update,delete,execute,receive,references
相关脚本如下：
--创建审核对象
USE [master]
GO
CREATE SERVER AUDIT MyDBFileAudit TO FILE(FILEPATH='D:\sqldbaudits')
GO
ALTER SERVER AUDIT MyDBFileAudit WITH (STATE=ON)
GO
--创建数据库级别审核规范
USE [sss]
GO
CREATE DATABASE AUDIT SPECIFICATION CaptureDBActionToEventLog
FOR SERVER AUDIT MyDBFileAudit
ADD (database_object_change_group),
ADD (SELECT ,INSERT,UPDATE,DELETE ON schema::dbo BY PUBLIC)
WITH (STATE =ON)
我们先在D盘创建sqldbaudits文件夹
第一个操作组对数据库中所有对象的DDL语句create，alter，drop等进行记录
第二个语句监视由任何public用户（也就是所有用户）对dbo架构的任何对象所做的DML操作
创建完毕之后可以在SSMS里看到相关的审核
Ⅲ 如何自动化完成SQL审核
sql审核主要完成两方面的目的.
1、避免性能太差的sql进入生产系统,导致整体性能降低
2、检查开发设计的索引是否合理,是否需要添加索引
第一点是SQL审核最核心的地方,避免乱七八糟的sql影响线上性能,甚至导致线上系统崩溃.
第二点是属于建模的范畴,要解决建模的最好办法是DBA参与项目前期审核,由DBA建模,如果DBA人力资源不足,那么就定期由DBA对开发人员进行培训.然后发现建模太烂的就扣KPI.
现在很多公司都是人肉来完成SQL审核的,人肉审核对dba的要求较高,需要懂一些代码,另外是费时费力,毕竟一般公司几十个开发,对应一个DBA，而且DBA还要干很多其他的事情.
如何将DBA从人肉SQL审核中解放出来呢?
思路其实很简单:
1、获取程序要执行的SQL
2、对要执行的SQL做分析,可以加各种分析条件来判断这个SQL是否可以自动审核通过,未通过审核的需要人工处理.
3、配合后期的慢查询日志分析系统完成长期的监控.
开源的解决方案主要有淘宝丹臣sqlautoreview系统.可以在github上搜索到.
但是这个系统主要是基于java sqlmapfile.xml解决自动创建索引的问题,对源数据有要求,并且是通过解析SQL结构来假设SQL的执行计划,不是特别准确,并且不能够很好的区分新sql还是老sql.
所以产生了一个新的方案:
1、为所有的执行过的sql产生一个figerprint
2、基于慢查询提供的数据,加上explain 提供的数据来判断这个sql的性能是否可接受,或者可优化.
3、自动审核通过性能可接受的部分,给DBA展示性能较差的sql,然后进行优化.
方案的优点在于:
基于用户真正执行的SQL,并且可以观察SQL执行频率.
基于MySQL真正的执行计划和执行结果,分析更准确.
每个SQL都有一个fingerprint,只需要增量处理新加的SQL,效率和性能提高.
基于Box anemometer二次开发,让慢查询和sql审核同平台,增加工具集成性,提高用户体验(DBA和开发人员)。
方案实施:
既然咱是DBA，肯定会有更DBA的思维方式.基于现有软件二次开发完成,减少开发成本,整合管理平台.
基于Box anemometer.安装Box anemometer
Box anemometer是一款B/S架构,图形化的MySQL慢查询分析工具.功能强大易用,设计简单直接.anemometer是基于pt-query-digest的二次封装得来.
核心处理流程:
mysql node–>计划任务通过pt-query-digest收集慢查询信息–>结果写入到数据库中–>anemometer按条件去展示慢查询的结果,并且提供了图形化和趋势分布图等功能.
所以anemometer已经帮我们完成了数据收集,包括每个sql的fingerprint信息,以及相关的信息,我们在测试环境,基于anemometer,将long_query_time设置为0,就可以收集到所以的SQL及相关信息.
在我们收集到所有SQL以后,我们就要来分析这个SQL是否可以自动审核通过.这里开始我们就要定制了.
定制内容如下:
一、
设置一个单独的datasources,可以命名为audit_sql.
这个datasources里面只放置开发环境或者测试环境的慢查询(你要做sql审核基于哪个环境),将此环境的long_query_time设置为0,接收所有的sql查询.
二、修改anemometer
ALTER TABLE `global_query_review` ADD audit_status VARCHAR(255) NOT
NULL DEFAULT ‘refuse’ comment ‘sql审计的状态 refuse未通过 pass审核通过’;
修改PHP代码.
在report模块的where条件中增加一个Ait Status的选项框,可以过滤audit_status的状态
在show_query模块中增加一个Audit Status的选项框,可以人工设置audit_status的状态
三、增加两个额外的脚本,准实时的分析audit_status为refuse的sql,如果sql的满足自动审核通过的条件,那么就设置audit_status为pass,表示自动审核通过.
自动审核未通过的sql,由DBA人工在anemometer上检索和处理.
这里就涉及到一个自动审核通过的算法:
算法分两种.
第一种是准实时,也就是可以几分钟或者一个小时运行一次,主要是根据每个sql的执行效率判断是否pass.
对应的脚本名字叫做:audit_sql.py
第二种是一天一次,弱化执行效率判断,增加一天执行的频率判断.
对应的脚本名字叫做:audit_sql_day.py
各家根据自己的实际情况调整或者优化这两个脚本.
至此,你已经可以让99%以上的代码自动审核通过了,审核不通过的代码你可以让开发自己来tracking也可以主动推给开发.
对于才搭建的环境,可能会有一些乱七八糟的sql,不过使用一段时间稳定以后,异常的sql指纹都有了,那么每天产生的sql指纹就比较少了,而这部分SQL指纹也就是程序员编写新的代码产生的.
Ⅳ sql server 2005 怎么开启C2审核策略
在ssms中右键点服务器属性
在安全性中选择启动C2审核跟踪
Ⅳ 如何通过SQL语句设置数据库登录审核的状态
刚好上次讲三层架构.有现成的例子
以一个验证登陆为例子
这里是界面层一般叫UIL
protected void Button1_Click(object sender, EventArgs e)
{
List<User> Users = BAL.GetUserInfo(txtUserName.Text,txtPassword.Text);
if(Users.Length > 0)
{
Response.Write("登陆成功");
}
else
{
Response.Write("登陆失败");
}
}
以下是逻辑层代码,业务逻辑层一般叫BLL
public static List<User> GetUserInfo(string user,string password)
{
string newPassword = GetMD5Hash(password); //这里对密码进行加密处理,数据库中存放的是经过MD5加密后的密,业务逻辑层一般都是处理复杂的逻辑.例如加密逻辑
List<User> Users = DAL.GetUserInfo(user,newPassword);
return Users;
}
以下是数据访问层代码,数据访问层一般叫DAL
public static List<User> GetUserInfo(string user,string password)
{
List<User> Users = new List<User>();
string sql = "select * from User where Password = '"+password+"' and User = '"+user+"'"; //写where子句的时候把Password放前面.因为Password经过加密,所以可以防止SQL注入攻击
SqlDataAdapter da = new SqlDataAdapter(sql,"这里是数据库连接字符串");
DataSet ds = new DataSet();
da.Fill(ds);
for(int i=0;i<ds.Tables[0].Rows.Count;i++)
{
User user = new User(ds.Tables[0].Rows[i]["ID"].ToString(),ds.Tables[0].Rows[i]["User"].ToString(),ds.Tables[0].Rows[i]["Password"].ToString());
Users.Add(user);
}
return Users;
}
还会有一个Model层.叫做模板层.是数据表结构的印射.Model层是共用层,其他三层都要用到.
比如数据库中有张表User,里面有3个字段ID,User,Password
那么在模板层中应该有一个类,数据库中User表的一行对应一个User对象,一张表对应User对象的集合.
public class User
{
string ID;
string User;
string Password;
//重载构造函数
User(string id,string user,string password)
{
this.ID=id;
this.User=user;
this.Password=password;
}
}
Ⅵ 如何自动化完成SQL审核
很多游戏项目都是通过每周更新大版本来维持用户的粘性和活跃度，而更新版本必然伴随着数据库的新建create、改表alter的SQL。
运维或者dba负责审核这类sql是否合理、高效，因为很多开发同事特别是经验少的新人是不考虑sql性能、是否合乎MySQL的最佳实践。
经常很多建表语句漏加索引或者加错索引（不满足最左匹配等情况），需要等到开服后数据库负载过高引起告警才发现问题。
MySQL的配置中有一个日志是记录没有使用索引的sql，记录进slow log日志中，不过实际使用过程中，的确存在着很多合理的不使用索引的情况，所以这个日志一般不打开。
为了避免人工审阅的重复劳动，所以运维可以通过写程序、脚本来自动审核sql，而审核的条件一般如下：
1、表结构是否合法 //不合法当然不能通过
2、表名、列名长度超过 16 //主要跟我们自己的授权有关系
3、必须有 unsigned //业务最容易忘记添加，当然如果一定要负值，那么就走人工审核;
4、必须为 InnoDB //当然了，我已经忘记还有MyISAM了，统计日志表除外
5、int bigint(10) 不能小于 10 //大家见过int（1）的情况么？
6、varchar 长度小于 3000 // 这也算是一个人为规定，没有任何意义
7、text 字段个数不能大于 3 //人为规定而已
8、主键必须为 int 类型 //不int，真的会死人
9、索引不能有重复 //见过key（id）,key(id,uid)的情况吗？
10、索引个数不能大于 5 个（包括主键） //人为定义而已
11、索引字段必须为 not null，并且有 default 值 //参照高性能那本书说的，其实不一定影响性能
12、SQL 是否使用到索引 //不能用到索引的SQL，真的很惨
13、SQL 中不能有 * //由于* 经常导致流量、O巨大，所以，也强制了
14、自增字段必须为 int 或者 bigint //见过自增用smallint的吗？然后一下就溢出了
15、请不要使用MySQL的保留字(Reserved Words) //写脚本，大家讨厌<`>符号么？
开发提交sql后，会直接调用后端审核程序，程序根据以上规则，进行审核，就极大的降低了运维、DBA的工作量。
当sql审核通过后，是否马上执行？
根据以下情况判断：
1、表小于10w行，小于10M空间大小，那么直接执行SQL;
2、如果不满足1，并且满足percona online-schema-change条件，那么通过osc工具，进行在线修改;
3、如果1、2都不行，走人工上线流程;
Ⅶ 如何用sql语句查询单据是否审核
IFEXISTS(SELECTTOP11FROM表名WHERE审核字段='审核'AND单号='单号001')
SELECT'已审核'
ELSE
SELECT'未审核'
Ⅷ MSsqlserver 审核失败
哦，这是数据库登录失败，是有人攻击你的数据库吧