Azure SQL数据库审计应对云安全

云计算 云安全
很多技术产品都支持你控制监管状态和对驻留Azure其中服务的访问,足以缓解这类安全问题的大部分。SQL 数据库审计就是这种技术之一

[[126416]]

你或许已经把按需定制的系统迁移到了微软Azure平台,这种迁移通常会引起安全和保密问题。因为至少在一定程度上,离开了完全托管环境自然存在的监管,这是在所难免的。控制级别的降低肯定是一个要考虑的因素,尤其是在处理PaaS(平台即服务)资源(比如Azure SQL数据库)时,你有很多可选技术,这些技术产品都支持你控制监管状态和对驻留Azure其中服务的访问,足以缓解这类安全问题的大部分。SQL 数据库审计就是这种技术之一,也是本文的讨论主题。

你应该会注意到,这个功能还是相对较新的,但是其相对近期的亮相主要是为了跟得上Azure更新的步伐。在经历过三个月的试用阶段后,在2014年11月12日它达到了一般可用的程度,因此它现在支持在生产环境可用。然而,它不能在传统的定价层次上应用,因此如果你的数据库配置用于Web或者业务,你首先需要将其升级为基本配置,标准配置或者增强配置。你可以在两个版本的Azure门户中直接操作来修改配置(传统版本门户从Scale标签页操作,也可以从预览版门户报价层次操作)。其主要目的是实现数据库级别的安全相关事件跟踪,同时处理合规需求。日志可以根据事件类型选择性地打开或者关闭,其中包括数据访问、库结构变化、数据变化、安全故障和权限授予收回。

一旦启用了功能,响应这些事件的条目会自动记录并存储在任意指定的Azure存储账户指定的审计表中(表名是“SQLDBAuditLogs20140928”),这也意味着由于其消耗的资源会存在额外的成本。另外,也会存在轻微的延迟影响(大概几毫秒之内),但是不会对数据库的计算性能有负面影响(因为审计服务是自给自足的,占用独立的计算资源)。在指定存储账户的时候,你可以选择指定是否使用主密钥或者辅助密钥来设置对内容的安全访问。这项设置意在遵守一些内部法规或者安全程序,加密保护存储内容的周期性变化。在此期间有一个键值会重新生成,而其他键值则保持不变。这样的话,你可以确保与安全相关的事件审计不中断地持续进行。这种机制使用你选择的密钥自动生成共享访问签名(SAS),它的访问被限制在表“SQLDBAuditLogs20140928 ”上,而且只有写权限。

另外,我们还可以指定记录到SQL Server级的事件类型。设置配置结果可以被应用到托管在同一个SQL Server中的所有SQL数据库,只需要选择数据库继承审计设置就可以了,菜单在传统门户页的“审计与安全”标签页,如果用预览版门户则在“审计”页,该功能可提高配置效率。在以上各操作界面,你都可以把审计保存为传统门户命令栏的默认命令(在预览版门户的标签是“保存为默认”),该操作会重置SQL Server审计设置,向当前数据库审计设置同步保持一致。

此外,为了审计切实产生效用,你必须修改客户端或者用户与SQL数据库交互的连接串。正确的配置串格式可以从门户页面获得,只需要点击“显示启用安全的连接串”链接就可以了,两种版本中都一样,界面会展示适用于ADO.NET,ODBC(包括Node.js),PHP和基于JDBC连接方式的各类连接串示例。它们与原来的连接串只有一个地方不同,就是其中增加了secure关键字来区分以安全模式连接到目标SQL Server。例如,如果针对ADO.NET的连接串原来是下面形式:

  1. Server=tcp:server_name.database.windows.net,1433
  2. Database=AdventureWorks2012;UserID=login_name; 
  3. Password=login_password;Encrypt=True;TrustServerCertificate=False; 
  4. ConnectionTimeout=30

 

其中“server_name, login_name,and login_password”分别代表服务器名,主数据库中定义的登录用户名以及对应密码,增加了审计设置的新连接串示例如下:

  1. Server=tcp:server_name.database.secure.windows.net,1433
  2. Database=AdventureWorks2012;UserID=login_name; 
  3. Password=login_password;Encrypt=True;TrustServerCertificate=False; 
  4. ConnectionTimeout=30; 

 

要记得带审计配置的连接,与无审计连接一样,都必须能通过网络防火墙设置。

很明显,以上这些设置尚不足以完全满足你的审计需求,因为默认的不带审计标识的连接字符串仍然是有效可用的。要堵住这个安全漏洞,你可以禁用无审计标识的连接。在两种门户界面把“启用安全访问”选项由“可选”改为“必须”就可以了。

一旦启用了审计功能,并设置为必选项,所有连接事件就都会记录在“SQLDBAuditLogs20140928”表中,存储在你选择的账号里。你可以利用任何现有可以访问Azure表存储的工具去查看其中保存的原始数据。在MSDN博客上有他们的完整列表。此外,你可能还需要使用预配置计分板模板,你可以在传统门户的“审计与安全”标签中点击“下载审计日志报告模板”或者在预览版门户“审计”页选择“在Excel中打开”链接。该模板包含有交互和定制的Power View和基于 PowerPivot的报表,利用Excel 2013中的商业智能功能可以非常有效地简化审计日志数据的分析。该模板包含有样例数据,它们是对七个数据库三个月范围内的审计示例。

下载了该模板之后,你还需要下载并安装Excel的Power Query插件。具体可以参考Excel手册浏览文档《02如何在Excel中查看Azure SQL DB审计日志报表》。它会要求你配置事件源,指向指定存储账号的“SQLDBAuditLogs20140928”表,可能还需要调整记录数限制(默认限制是一百万,但是如果需要的话,这个值可以增加到六百万)。该手册还包含有多个表格页,其中包括以下内容(请注意默认只有前五项可以直接显示,其它项可以通过电子表格右键菜单中的“取消隐藏”全部显示出来):

  1. 整体定位。包括配置模板需要的步骤清单,都有超链接指向详细介绍;还包含有与每个可视表格关联的报表简述。
  2. 异常信息。显示事件概览。需要的话可以进一步研究,比如大数据集的变化或者无效登录尝试,还有对不常用的安全原则的触犯。它还对数据访问异常提供报表展示百分比,它可能代表了不正常的应用程序用法。
  3. 向下钻取。它提供了获取更多明细统计数据的支持,展现审计事件的不同侧面,比如事件类型、目标数据库或者用于访问的安全原则名称。
  4. 事件类型分布。它提供了审计事件类型分布的综合视图,基于几方面纬度。比如:目标数据库、月份和日期,周某天或小时规律等。
  5. 事件时间分析。它帮助分析一段时间内的事件类型。默认情况下,它由两个图表组成:***个显示数据访问量、数据变化和存储过程执行事件;第二个显示了成功登陆的统计。指定区域范围的事件类型可以很容易地添加或者去除,使用每个图标独立配置的事件类型切片就可以做到。
  6. 数据库位置信息。它包含有数据库位置列表(在我们的例子中是相应的Azure数据中心位置)。这些信息必须把电子表格设置为“显示隐藏表格”之后才可以看到。
  7. 研究视图。它根据数据库位置表生成基于映射的可视化统计。它主要是为了帮助识别事件类型的变化趋势。
  8. 时间分析Upper Pivot和Lower Pivot。它充当基础支持数据的角色,在时间类型分析统计表中会用到它,这个表不应该修改。
  9. 工作日统计。它充当基础支持数据的角色,在事件类型分布统计表会用到它,这个表不应该修改。
  10. 事件访问时段统计。它提供一段时间内总的事件统计技术,用于预测分析。

数据访问时段统计,数据变更时段统计,成功登陆时段统计,库结构变更时段统计,存储过程时段统计。这些信息分别提供一段时间内数据访问,数据变更,成功登陆,库结构变化和存储过程调用事件的统计,也是用于预测分析。

值得注意点是,在web应用中,使用相同的认证凭据代表它们的用户对数据库建立连接是相对常见的做法。这些凭据是在应用级别配置的。虽然所有这些连接事件都会记录到相应安全原则的审计日志中,但是你并不能有所区分它们。因此你可以在应用中获取实际应用用户名,把该用户名信息已参数的形式也发送到SQL数据库中去,可以解决这个问题。

对SQL数据库审计功能的介绍到这里就结束了。在以后的文章中,我们还会探索此PaaS服务最近发布的其它增强功能。

原文链接:www.searchdatabase.com.cn/showcontent_87269.htm

责任编辑:Ophira 来源: TechTarget中国
相关推荐

2010-05-13 14:14:45

2011-03-02 17:09:20

2011-08-02 15:04:49

2015-03-27 13:02:17

Azure SQL D微软云数据库

2012-01-05 09:45:31

微软云数据库SQL Azure

2010-12-29 09:50:06

数据库安全审计数据库审计

2010-12-29 09:46:32

2019-05-31 12:13:49

MySQL数据库安全

2016-09-07 14:08:01

AzureSQLJSON

2016-10-09 10:59:26

Azure SQL数据库JSON

2011-02-28 14:40:40

2009-08-11 13:21:34

2010-12-27 14:45:27

2010-11-30 11:26:49

2015-07-28 13:57:52

2010-11-11 10:46:20

微软SQL Azure云端

2013-03-28 11:07:46

Windows AzuSQL AzureWindows Azu

2010-11-16 11:27:53

SQL Azure数据

2010-10-09 10:34:12

SQL Azure云数

2010-11-16 11:26:20

SQL Azure数据
点赞
收藏

51CTO技术栈公众号