阿里云数据库安全
发布日期:2016-1-29 14:1:3
阿里云数据库安全 本文根据目前国内外数据库安全的发展现状和经验,结合亚马逊AWS[1]、阿里云、腾讯云、UCloud、华为云等国内外云服务厂商,和IBM、微软等IT巨头的云服务情况,从云数据库安全角度,介绍了阿里云环境下数据库安全四种技术路线与安全模型架构,和云数据库安全的关键技术。 每个公司对私有云、公有云的定义都不一样,但是CIO们却在不断重演莎翁经典对白:“公有云还是私有云,这是个问题”,政府、企业、金融、公共事业等都在建设或者规划上云。引发这一问题的核心是:云环境的安全合规性问题,也就是云环境的法规遵从、云数据的安全如何保障、云环境风险管理。 云数据(库)安全之技术路线 从法规遵从和企业、个人敏感信息防护的角度,相比私有云环境和传统企业IT环境,公有云和混合云环境中的数据面临着前所未有的,来自开放环境和云运维服务环境的安全挑战。笔者认为抓住主要矛盾,围绕核心敏感数据,进行最彻底有效的加密保护,比较典型的敏感数据包括身份证号、姓名、住址、银行卡、信用卡号、社会保险号等等,以及企业的核心资产数据。在此观点下,笔者提出以加密保护为基础的技术路线: 以敏感数据加密为基础 以三权分立、敏感数据访问控制为主要手段 以安全可靠、体系完善的密钥管理系统为核心 辅助数据库防火墙、数据脱敏、审计等边界系统,规范和监控数据的访问行为 云数据(库)安全之模型和架构 实现以敏感数据加密为基础的技术路线,最关键的是“密钥由谁控制、在哪管理”;同时需要解决数据加密防护和密钥管理引起的对系统运行效率,系统部署和改造的代价,自动化运维的影响等一系列问题。对此,亚马逊AWS的解决方案中采用多种密钥管理模型: 模型A:加密方法,密钥存储,密钥管理全部由用户控制,典型的是整个KMS[2](密钥管理系统)部署在用户的数据中心。 模型B:与模型A中的加密方法是一样的,区别在于密钥的存储是在云的KMS而不是在用户端的数据中心。 模型C:本模型提供了完整的服务器端加密,加密方法和密钥的管理对于用户是透明的。 AWS云数据安全模型 如下图所示:
围绕三种安全模型,我们可以在多个层上实现数据加密防护—多层数据加密防护架构,具体如下: 1、 磁盘加密:采用的是Block-Level加密技术,需要云存储卷采用Block存储机制,例如AWS的EBS[3],阿里云的ECS[4]等。这种加密最大的好处在于,它对操作系统是透明的。 2、 文件加密:通过堆叠在其它文件系统之上(如 Ext2, Ext3, ReiserFS, JFS 等),为应用程序提供透明、动态、高效和安全的加密功能。典型的是用于加密指定的目录。需要关注的是这种加密方式可能会产生较大的性能损失。 3、 应用层加密:在数据到达数据库和RDS之前,甚至发送到云端之前,实时保护用户的敏感数据;这里关键需要提供良好的应用透明性,保证绝大多数应用无需改造。云用户(企业)没有必要信任云计算提供商以保护企业的数据安全。数据安全是由企业自己控制的。 4、 数据库加密:(1)以亚马逊AWS的RDS[5]为例,典型的是使用DBMS[6]提供的数据库透明加密,自动的对数据库表空间数据进行加密,密钥管理也是由DBMS提供的API或组件实现,应用透明。由于RDS没有对外开放RDS用于存储数据的磁盘,因此前面提到的“透明”磁盘、文件加密技术无法在RDS上使用。(2)对于用户在云上自行部署使用的DBMS,可以使用第三方专业数据库加密厂商提供的产品,如安华金和的数据库保险箱DBCoffer,可提供应用透明的按列加密能力,独立的密钥管理、三权分立、静态数据掩码能力。 5、 密钥管理和加解密组件:作为数据加密保护的核心组件,KMS负责进行密钥生成、管理和销毁,并提供加解密能力;同时根据需要提供密钥的生命期管理、开放的API接口。 综上,云用户(企业)可以根据自身的安全合规性需求,选择适合的云数据安全模型和相应的数据安全技术(产品),对敏感数据进行加密防护。 多层云数据加密防护架构 如下图所示: 阿里云数据(库)安全之关键技术 笔者提出了一套云环境下的“多层数据加密防护架构”。下面针对实现该安全防护架构与相关关键技术进行具体分析。需要说明的是,由于整盘加密和TDE[7]属于云服务商和数据库厂商的范围,不在本文中讨论。 KMS密钥管理和加解密算法 密钥管理包含了密钥的创建、存储、生命期管理、保护。密钥的安全性直接决定了加密数据的安全性。建议密钥独立存储,并采用根密钥保护,根密钥受硬件加密卡保护,或者被KMS服务的密码保护。 密钥安全体系如下图所示: KMS密钥管理通过用户的口令保护主密钥,口令正确主密钥解密;主密钥对密钥文件进行保护,只有主密钥成功解密后,密钥文件才能使用,最后通过密钥文件生成可用的密钥。 加解密算法方面,除了必要的强加密算法(如AES256)和相关机构认证的硬件加密算法外,这里特别需要提出,为了实现应用的透明性,需要根据应用系统的需求提供专门的加密算法,如FPE[8],Tokenization,SSE[9]等。 FPE加密算法,是一种格式保留的加密算法,主要面向身份证、银行卡号、信用卡号、社会保险号等具有数据特征的信息进行加密,该算法加密后的数据能够保留原有的数据格式,从而对应用的业务逻辑不会产生任何影响,保证了应用的透明性。 Tokenization,是一种数据掩码算法。与FPE[8]类似,通过对数据的“扰乱”,并保留数据的原有格式,达到加密的效果,同时保证应用的透明性。 FPE加密算法的效果如下图所示: 应用层透明加密 应用透明加密分为两种实现技术:JDBC[10]/ODBC[11]加密驱动,和云访问安全代理。其中最关键的是用于支撑应用透明的加密技术:FPE、Tokenization。 1、JDBC/ODBC加密驱动 应用层JDBC/ODBC加密驱动,可以通过在原有DBMS提供的JDBC/ODBC上,以Wrapper方式实现,部署时替换JDBC/ODBC加密驱动,实现对应用透明的数据加解密,实现数据在到达DBMS/RDS之前进行加密,和数据离开DBMS/RDS到达Application之后进行解密,最终保证多数应用系统无需改造;同时在JDBC/ODBC加密驱动层实现独立的权限控制,密钥的获取。 对敏感数据,通过JDBC/ODBC加密驱动实现完整的敏感数据访问审计能力。 JDBC/ODBC加密驱动技术如下图所示: 优势: 实现按字段加密,数据在到达DBMS/RDS之前就完成加密,安全性好 实现对应用的透明性,只需更换JDBC驱动即可完成 实现对数据库帐户细粒度控制,包括DB用户,客户端IP,客户端MAC地址,应用程序或工具等 部分实现应用用户控制,包括应用帐号、应用客户端的IP等 限制: 对第三方数据工具(如PLSQL,TOAD等)无法实现透明,数据为密文 对服务器端程序,如存储过程、驻留在DBMS主机的自动化脚本等,无法实现透明 需要针对不同的数据库实现相应的JDBC/ODBC Wrapper 数据库透明加密 数据库透明加密是按列对数据进行加密的,针对指定的列,采用指定的加密算法和密钥、盐值等进行加密处理。加密后的数据以密文的形式存储在DBMS[7]的表空间中。 只有经过授权的用户才能看到明文数据,并且授权也是按列进行的,这种方式具备很好的灵活性和安全性。非授权用户,将无法读取加密列(查询)和更改加密列的数据。 权限管理上,数据库透明加密采用了分权的机制,实现了三权分立,有效制约了数据库管理员(DBA)这样的特权用户对数据的访问。同时这种保护又是透明的,不会对管理员的日常工作造成不便。 最重要的是数据库透明加密应用透明,应用系统和外围维护工具无需改造,涵盖SQL语句透明、存储程序透明、开发接口透明、数据库对象透明、管理工具透明。 数据库透明加密防护技术如下图所示: 优势: 对应用系统和数据库管理工具透明 对数据库帐户细粒度控制,包括DB用户,客户端IP,客户端MAC地址,应用程序或工具等 对敏感数据访问细粒度审计 限制: 需要针对不同的数据库分别实现 需要实现专门的密文索引技术和透明访问技术,以满足性能和应用透明性 无法适用于RDS、用户在ECS上部署的DBMS实例 2、云访问安全代理 云访问安全安全代理(CASB),往往采用的是应用网关的方式,作为HTTP或HTTPS的反向代理服务网关,对HTTP页面中的敏感数据进行加密和Tokenization两种不同的保护方式。通过处理HTTP的请求和响应,实现面向字段的数据和上传内容的加密和解密,实现在数据发送到云端之前进行加密,密文数据离开云端到达客户端之前进行解密。 云访问安全代理网关典型部署在用户数据中心侧,用户完全控制数据的加密密钥和加解密过程。可以采用任意的inline proxy方式进行部署。 云访问安全代理网关可以提供细致的面向应用系统用户和组的访问控制能力,同时提供面向应用系统用户的细粒度访问审计能力。 云访问安全代理技术如下图所示: 优势: 实现按字段的加密,可以在数据到达云端之前就完成加密,安全性最好 具有高安全性,能够提供面向应用用户的解密权限控制,有效防止DBA的高权限和SQL注入攻击行为 最大限度满足合规性能力 限制: 对应用系统可能无法实现真正的应用透明,需要对应用进行部分改造 对第三方数据工具(如PLSQL,TOAD等)无法实现透明,数据为密文 对服务器端程序,如存储过程、驻留在DBMS主机的自动化脚本等,无法实现透明 文件级透明加密防护 文件级透明加密防护通过在云主机操作系统上部署专门的加解密agent,实现对专门的数据文件或卷(Volume)的加解密。对操作系统帐户具有权限控制能力。只有专门的DBMS系统帐户才有对文件或卷进行加解密。 文件级透明加密防护技术如下图所示: 优势: 对数据库系统(DBMS)和应用透明 同时支持结构化和非结构化文件的加密 有效控制操作系统用户的访问,满足通常的控制需求 限制: 无法提供细粒度的数据访问审计能力 需要针对不同的操作系统平台提供专门的agent 无法控制数据库帐户对敏感数据的访问 数据库防火墙 数据库防火墙,是基于数据库协议分析与控制技术的数据库安全防护技术。基于主动防御机制,数据库防火墙实现了对数据库的访问行为控制、危险操作阻断、可疑行为审计。是集数据库IPS、IDS功能为一体的综合数据库安全防护技术。 数据库防火墙技术如下图所示: 数据自动脱敏 随着云计算、弹性计算的广泛使用,会出现两种系统研发和测试的趋势: 1)系统研发和测试在本地环境完成,然后部署在云端。 2)系统研发和测试也在云端进行,充分利用云端的弹性计算资源,和方便简洁的云化部署能力。 以上无论哪种方式,都面临将生产数据全部或部分转移到测试和研发环境中,出于合规性和安全性需求,转移的数据必须进行“脱敏”处理。 数据自动脱敏技术能够对测试库中的数据、迁移过程中的数据、导出成文件的数据进行“脱敏”处理;并能保证数据关系一致性,例如分散在不同表中的相同身份证号数据脱敏后仍然是相同的。 数据自动脱敏技术如下图所示: 实施云数据(库)防护的6个步骤 由于云环境、企业云应用系统、核心数据的复杂性,选择适合的云数据保护方案变得尤为重要。那么什么样的方案是适合的?笔者认为应该涵盖以下几个关键点:(1)满足安全需求和相关法规;(2)对各种危害来源进行有效防护;(3)可接受的部署和维护复杂性。 因此,为了保护云端的数据,需要有计划、有步骤的实施云数据(库)安全防护,这里结合前面的架构和关键技术,提出以下实施云数据(库)防护的6个基本步骤: 步骤1:首先分析并确定需要保护的关键数据 在对云数据进行保护前,首先需要准确的分析哪些数据需要保护,和为什么要保护这些数据;评估和划分哪些数据需要放置在云端,从而确定哪些数据是关键的必须保护的数据,例如用户身份证号码、银行卡或信用卡号码、社保号码等。另一个需要关注的就是法规遵从性需求。 步骤2:选择适合的技术方案和加密算法 作为云数据防护是否能够成功实施的关键,企业需要在关键数据的安全性、保持云应用系统的功能可用性,和系统可维护性方面综合考虑,来确定适合企业需要的加密保护的技术方案。下面的两张图表对前面提到的加密防护的关键技术能够提供的防护效果,安全性和部署复杂性进行了对比,供读者参考。 多层云数据加密防护效果分析如下图所示: 安全性和实施部署复杂性分析如下图所示: 加密方法的选择也很重要,这里举个典型例子,在很多应用系统中会对银行卡号数据进行格式校验,如果数据不符合格式会造成应用系统无法接受“错误”的银行卡号数据,因此对银行卡号加密同时,还需要保留其格式特征,可供选择的加密算法包括FPE和Tokenization。而姓名等数据则可以采用AES256等更通用的加密算法。 步骤3:需要保护好数据的加密密钥 为了保护密文数据不会被非法窃取,避免云服务厂商和第三方维护人员访问到明文数据,最好的做法是将密文数据的密钥控制在云用户自己手中;读者可以参考前面的图1云数据安全模型和表1 安全模型对比。 步骤4:实施必要的防数据泄漏措施 虽然采取了必要的数据加密措施,但并不能彻底解决来自应用系统环境和云运维环境的安全威胁,典型的如来自云应用系统的SQL注入攻击、后门程序、利用数据库漏洞的攻击行为、第三方运维人员的误操作等。因此需要采用数据库防火墙这样的数据边界防护技术,利用其细粒度的访问控制、防攻击、防批量数据下载等特性,实现有效的防数据泄漏。 步骤5:监控并审计数据的访问行为 一方面,黑客攻击行为千变万化,另一方面,系统的复杂性带来的数据正常维护和管理行为往往也是不可预期的。因此,需要对重要数据的访问行为采取持续、及时的监控和审计,形成有效的风险报告提供给用户发现新的风险,帮助用户更好的进行数据保护。 步骤6:最后利用自动脱敏防止测试环境数据泄漏 除了云环境的数据防护,企业内部的测试环境也是一个重要的信息泄漏源,特别是需要“抽取”云端生产数据用于测试系统时;利用数据自动脱敏技术可以在有效的保护生产数据的同时,为测试环境提供可用的符合用户预期的测试数据。 名词术语解释 [1]AWS:本文主要指亚马逊的云计算服务 [2] KMS:Key Managerment System,是一种基于软件或硬件加密卡技术的密钥管理系统,实现了密钥的生命期管理,提供丰富的加解密算法和接口 [3] EBS:Elastic Block Store,本文主要指亚马逊的弹性块存储服务 [4] RDS:Relational Database Service,本文主要是指阿里的云数据库服务 [5] ECS:Elastic Compute Service,本文指阿里的云服务器服务 [6] DBMS:Database Management System,数据库管理系统 [7] TDE:Transparent Data Encryption,数据库透明加密,一种由数据库厂商提供的数据库加密技术 [8] FPE:Format Preserving Encryption,是一种保留数据格式的加密算法,加密后的数据格式与明文数据的格式保持一致。 [9] SSE:Searchable StrongEncryption,一种加密后数据可查询检索的加密算法,类似同态加密的结果 [10] JDBC:Java Data Base Connectivity,一种用于连接多种关系型数据库的Java数据库连接 [11]ODBC:Open Database Connectivity,开放数据库互连,是Microsoft提出的数据库访问接口标准
|