推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > IMPERVA > 数据库安全概述:运行方法篇

数据库安全概述:运行方法篇

IMPERVA 2018-10-18

近期新加坡最大的医疗机构集团SingHealth健康数据遭到黑客攻击,导致约150万人的个人信息被非法获取。其后,新加坡网络安全机构发布了一系列安全措施旨在加强个人身份信息(PII)数据保护。

该机构推荐的几项安全措施主要涵盖以下几个IT安全要点:

  • 数据管控与数据管理生命周期

  • 用户访问身份管理

  • 最小访问权限与执行权的控制

  • 定期更新软件补丁

  • 敏感数据加密

  • 监控全部数据访问活动

  • 及时发现可疑数据查询行为

数据安全管控涉及面广,如:双重认证、DLP、数据加密、数据库安全等,本文主要介绍数据库安全问题,这也是大多数安全团队较头疼的问题,因为他们没有解决数据库安全问题的解决方案,也一直忽略了数据库系统性能问题。


保护数据的目标很明确,但数据库安全却往往是被忽略的一环,缺少充分保护,也未能对数据访问活动进行彻底检查。这并不是由于人力不足、或技术能力问题等导致,主要原因是未能进行尽职调查、渎职甚至懒惰。


下面我们总结了大部分客户在做处数据库安全时遇到的常见问题:

  • 如何确定哪个SQL查询是“可疑的”?在每周的CSV日志报告中有上千行SQL查询项,看起来都差不多。

  • 我们发现有位用户居然能够直接访问数据库服务器中的数据,而他的ID甚至并不存在于该服务器内。我们花了三天的时间进行调查,数据库管理员后来才告诉我在主节点与副结点间有一个数据库链接。这就解释了为何会发生前述事件。这让我们浪费了足足三天的时间,真希望自己Oracle数据库知识水平能更好些,处理速度能更快些。

  • 由于会影响CPUI/O磁盘以及存储能力的性能,因此数据库管理员不允许我们对所有数据库服务器进行本地审计。我们只能根据SQL异常情况在本地检查所有登录/登出活动。因此,无法对数据库服务器的所有SQL活动进行检查。面对诸如可疑查询活动是如何进行的呢?是否未触发任何SQL异常?我们该如何管理这种固有风险呢?这类的问题,我们也回答不了。

  • 我们进行了本地审计,并将所有数据库日志发送给SIEM,对其进行解析。但在检查部分SQL语句时,还是遇到了运行问题。例如:某个有权限用户执行“select * from psx64;”命令,这看起来很可疑。那这个psx64究竟是个表格、图片还是代名词呢?该对象中是否包含有敏感APP数据呢。我和负责数据库/应用管理的同事无法把这个问题弄明白。也无法对此类查询活动进行及时评估,因此有时干脆就不去想它了。

  • 每台数据库服务器的日志报告文件中都有数千行的SQL查询活动等待我们去检查。我们根本无法搞清所有的查询活动。只一台数据库服务器的审计工作就能让我们焦头烂额了。

  • 不同应用拥有非常多的数据库服务帐号。我们不知道每个帐号的正常数据访问活动是什么样。也无法判断哪个服务帐号是否被恶意滥用了。

  • 整个企业员工数量达5000人,但IT安全组只有10名工作人员。我们一直面临各种困难,包括了解、分析及记录每位员工的正常行为。也无法回答诸如当某个用户访问的数据比其在过去一年里访问的数量还多时,为何不能发出预警?之类的问题。

  • 虽然知道网络安全的重要性,但完全不了解数据库安全领域。也不敢冒险在数据库服务器上进行风险控制,只怕会对服务器运行产生不良影响。因此只能选择忽略潜在的数据风险问题,因为我们处理不了类似情况。

  • 我们企业有下列数据存储设备:CIFS文件服务器、MS SQL, Oracle, MySQL, DB/2 on Windows, DB/2 on z/OS, DB/2 on AS/400, Cloudera,以及SAP HANA。近期,将部分不是特别重要的数据迁移到了AWS RDS上。这些数据平台都采用不同语言搭建,甚至在这些平台上无法统一部署一个简单的安全策略,更无法追踪所有数据库配置变更活动。所以我们不得不只专注于更为熟悉的平台保护工作。


如何才能清除这些数据库安全保护障碍呢?

从积极的方面来说许多企业在安全监管方面的工作都已比较成熟,也知道该如何保护自己。

本章主要讨论部分企业正在实施或已实施的安全实践措施。当前网络环境复杂,随时可能被攻击、或因用户疏忽或恶意或配置问题出现各种漏洞,因此企业网络一直暴露在数据风险之中。如果能实施下列措施,则可为还没有部署风险控制措施的用户提供保护。


步骤1:实现数据访问活动的全透明监控

不可见则无从保护。因此需要完全了解数据库访问情况,才能实现取证、审计检查以及不可否认性的目的。

需要注意的是,在大部分的数据库系统上进行本地审计时,可能会导致数据库系统性能降级。

为避免发生此类情况,可以考虑采用独立数据库审计与保护解决方案,这样即可避免启用本地审计功能,又能使企业了解到全部数据访问活动。关于此功能,将在步骤3中详述。

步骤2:优先处理安全监控要点

虽然数据库服务器是企业最重要的所在,但他们也只是安全团队在日常工作中需要检查与保护的企业众多资产之一。

由于人力有限,无法对所有原始审计数据或宏数据(无法完全展示SQL查询背后的数据背景)进行逐一检查分析。

因此,需要对风险管理实行优先级分类。无论是何类资产,安全监控与审计检查通常只关注于以下三点:

  1. 谁在访问企业的数据资产?

  2. 访问活动是否属于正常行为?

  3. 如果发现异常情况,如何才能迅速响应?


要回答前述三个问题,曾与我们合作过的一名首席信息官给我做了一个有趣的比喻:

 “老鼠天性爱吃奶酪。企业中的数据就像奶酪一样吸引着企业内外的老鼠。为了防止奶酪被偷走,需要设立防护边界,并准备老鼠药,这样就能在他们企图靠近奶酪时消灭他们。

但老鼠总会伪装成不同样子来偷奶酪,所以我设置的保护机制就得一直想尽办法识别出伪装过的老鼠。所以我不禁想,为什么不能直接在奶酪上面加装一个酷似奶酪的外罩呢?

这样我就不用担心老鼠伪装了。我只要看住奶酪外罩,就能发现试图偷奶酪的老鼠踪迹,或是之前未发现过的任何未知种类的老鼠。

那问题来了,如何构建一个支持数据感知与应用感知的智能奶酪外罩呢?

在处理这类问题时,我们发现下列方法非常有用。虽然可能并不详尽,但确实是个好的开始。

在提及解决方案与工具前,应先在企业的安全检查过程中学会下列方法。否则如果缺少最基本的认知,再好的工具也没用。

  1. 根据业务影响分析(BIA)结果,重点关注最重要的数据库资产。因为即使企业中投入大量资源部署了最多的工具,也无法防范一切可能影响企业资产的风险。因此需要将有限的时间与资源都用于保护企业业务免受最大负面影响的风险。同时,将影响按照运营、财务、声誉等分类。如果还未做BIA,则建议一定要进行该分析,否则将无法确定哪类资产是最需要关注的资产。

  2. 关注敏感数据的访问:对数据库中的所有敏感数据进行分类并创建一个数据字典。应在开发每个新应用的流程手册中规定必需创建数据字典。由于每天的工作时间有限,数据访问检查的关键是要关注谁在访问企业的敏感数据以及用什么工具访问敏感数据?。耗费大量的时间来检查对企业业务影响力低的数据访问活动是无意义的。因此需要针对敏感数据访问控制与检查确定管理政策与控制措施。这使得整个安全审计过程更具可管理性与针对性。

  3. 关注权限用户的活动,因为权限用户对数据拥有极大的访问权。注意他们的活动情况。他们是否在使用非法工具访问数据?是否绕过应用或绕过主机直接获取了敏感数据?如果是,他们对数据做了何种操作?

  4. 如果不想只得到那种由60行原始日志组成的日志报告,则第一步应制作基于图表的报告。因为没有分析师能够及时对60k的原始日志进行完全穿透审查,也就无法对数据库审计日志进行适当检查。一般情况下,需要生成图表型的高级报告以了解关键数据库内的情况。这种报告能够帮助分析师在10分钟内完成任何数据库的数据访问检查工作。报告的基本内容包括源数据库ID、用户共享帐户(如有)、与数据库相关的IP与应用,以及各用户在数据库内的操作类型详情。基于图表的报告可帮助分析师轻松发现任何异常事件,如:为何Microsoft Office 2010的源应用会关联到我的工资单数据库?。如发生这种情况,分析师可打开原始日志报告,查看与“Microsoft Office 2010”访问工资单数据库相关的具体日志条目,从中能够发现更多有用的调查与数据线索,且再不必逐行检查原始日志。这种方法能够帮助清晰有效的检查数据库访问活动。

步骤3:投资采购支持步骤2所述功能的独立数据库审计与保护工具

目前,还无法单纯依靠人力来监控数据库中的敏感数据访问与权限用户的活动。因此需要依靠各种解决方案与工具尽可能加快检查速度并自动化监控。

独立数据库审计与保护解决方案一般会从数据库服务器中收集审计数据,但无需启动数据库服务器的本地审计功能。因此在进行数据库安全监控时,可提高并节省数据库服务器性能,同时减少来自数据库管理员的阻力。

这些解决方案可利用各种方法来收集数据库活动信息,将对数据库服务器性能的影响降至最低:

  • 绕开负责控制数据流量的交换机上的SPAN/TAP端口或网络聚合TAP

  • 部署轻型代理,负责收集本地数据库访问活动或所有数据库活动。

建议所采用的工具能够支持下列几项关键的运行要素:

  • 将低级SQL语言转化为人类易懂的语言:用户无需了解各类型数据库上使用的1001 SQL命令,该工具应能将相关的SQL命令分组转化为人类可读命令组,如:备份数据库代码变更数据对象管理权限操纵用户及权限授权创建对象等。因此无需安全管理员担任数据库专家的角色,依靠这种工具就能实现数据库保护。除了拥有各种具体的备份命令与各种类型数据库流程外,还能简单的创建一个安全审计策略,即:如有非法源应用对我的任何DB2/MS SQL/Oracle数据库进行备份时,向我报警。

  • 支持一次定义、多次合规功能,满足审计与合规管理性的需求:合规法规与审计机构一般不会理会数据库的运行环境。他们只关心企业实施的系统性应对数据资产风险的流程以及是否有适当的安全控制措施来降低此类风险。为满足审计规定而投入的人力、时间与资金都称之为合规成本。审计与安全工具应支持:只需一次定义安全审计策略,即可在由各种数据库组成的整体环境中统一应用。此功能主要基于满足一次定义、多次合规的管理、风险与最佳合规实践需求。通过此方法,在数据库服务器数量或类型发生变化时,或在未来两年内需要迁移到基于云的数据库时,用户再无需担心当前的安全审计策略在不同数据库环境中的关联性。


步骤4:利用机器学习与分析法解决难题

即使采用最适当的审计工具与流程,安全审计数据检查是一个极为冗长的流程,需要消耗大量人力。

如果能了解服务帐户活动的特性(如前述步骤3中所述),服务ID活动检查工作就简单多了。用户ID行为之所以最难检查是因为需要了解每个员工的动态行为以及其数据访问形式。但这种数据访问形式可能会因工作、心情或部门调动等工作需要而发生变化。但与数据库服务ID行为分析不同的是,用户行为有时并不能简单的以访问矩阵的方式记录。

无论多频繁的进行数据访问活动检查,仍可能会有漏洞或可疑访问活动被忽略。因此,此工作始终受限于人类的处理能力。

随着机器学习技术近年来的快速发展,已能够弥补一些人力不足。

机器学习安全探测技术可帮助用户解决可疑数据访问活动类似的模糊逻辑问题。

  • 在安全审核过程中,是否遗漏了某些关键的数据访问违规事件?

  • 在步骤2中是否遗漏了任何敏感数据?是否未能对该敏感数据进行监控?

  • 是否有任何用户曾异常频繁的访问过数据?

  • 上述情况是否发生成正常工作时间以外的时间?


机器学习安全探测技术的要点在于:

  1. 收集数据的质量(无用输入与输出概念)

  2. 正确了解数据背景(在不同情景下各数据点的作用是什么?)

  3. 构建适用某些使用案例的专用数据模型

客户们都比较喜欢拥有内置数据模型的解决方案。这样出现新的安全使用案例时,就不必再另外采购专业的数据模型构建服务。


数据库安全问题涉及面极广,因此需要拥有应用、服务IDACL、数据库系统以及各类管控、风险、合规理念相关的运行知识。并不是在本文中一两句话就能概述明白。因此,本文希望成为受数据库安全问题困扰的用户安全之路的起点。

欲了解更多信息请访问www.imperva.com


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《数据库安全概述:运行方法篇》的版权归原作者「IMPERVA」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注IMPERVA微信公众号

IMPERVA微信公众号:gh_8ff2977b2430

IMPERVA

手机扫描上方二维码即可关注IMPERVA微信公众号

IMPERVA最新文章

精品公众号随机推荐