云数据仓库中的数据安全思考 译文
近年来,由于云计算与云存储具有一定的廉价性和可扩展性,云数据仓库(Cloud data warehouses,CDW)得到了广泛的应用并飞速发展。同时,CDW不但能够存储比本地数据库更多的数据,而且可以通过现代化数据管道,简化了ETL的各种流程,因此许多企业都开始用它来开展大规模的数据分析业务。
其实,早在十多年前,公有云服务提供商便开始以平台即服务(PaaS)的模式发布云端数据仓库了。其中,Google的BigQuery和Amazon的Redshift都能够让组织在几分钟内,完成对CDW的部署,而无需额外安装数据库,或配置服务器。通过将数据从本地迁移到CDW(已被认为是现代数据栈的一部分),数据消费者和生产者在数据的访问过程中,获得了极大的便利性。在某些CDW平台中,企业甚至不需要DBA去维护数据的索引。其整个数据库的管理工作会变得异常简单。
当然,此类技术也面临着包括敏感数据的泄漏、隐私的暴露、数据结构的治理,以及满足合规等方面的挑战。在本文中,我们将和您讨论在将数据迁移到CDW过程中的各种安全注意事项。
迁移到云数据仓库后的安全性问题
我们之所以要将数据迁移到云端数据仓库中,就是为了允许更多的用户去访问我们的数据,并能够从数据中创造更大的价值。这就是业界常说的?“数据民主化(data democratization)”。与此同时,由于CDW是在所谓的“共享责任模型”上实现的,因此云服务提供商需要承担诸如:物理安全、操作系统安全和补丁、甚至是维护基本数据库软件等责任。而这些并非租户企业所需要参与的。因此,他们应当将注意力放在云端的数据安全上。这些往往不只是企业中安全专业团队的责任,而需要数据工程师,乃至业务团队的参与,需要大家共同制定和践行相关的安全策略。?
加密
租户企业必须确保存储的静态数据、以及连接的传输中数据,都得到必要的加密。从安全的角度来说,这些不但对于降低中间人(MITM)的攻击、肆意访问到存储数据的风险是必需的;而且对于满足合规性,也是非常必要的。在一些主流的CDW平台中,它们会在默认情况下,对静态和传输中的数据进行加密。而其他的平台,则需要您手动配置对存储数据的加密,并在访问数据的过程中,强制采用加密协议。?
网络访问控制
在大多数情况下,设置网络访问策略是降低CDW风险级别的一种简单而有效的方法。有些平台在默认情况下,根本没有公共互联网的访问权限;而在某些平台中,您需要额外配置网络访问规则。而一些特定的应用场景中,您还需要为特定的用户或用户组,设置更加具体的网络访问策略。下面是以Snowflake为例,制定的网络访问策略,并需要将其应用到特定的用户上:?
CREATE OR REPLACE NETWORK POLICY us_employees
ALLOWED_IP_LIST =( '1.1.1.0/24', '2.2.2.0/24', '3.3.4.5' )
BLOCKED_IP_LIST =( '1.1.1.128', '2.2.2.128' )
COMMENT = 'US employees offices, excluding guest WiFi gateways';
/* Assigning the policy to a user */
ALTER user us_marketing_analysts SET NETWORK_POLICY=US_EMPLOYEES;
验证
CDW对于用户的身份验证,会因平台而异。例如,并非所有平台都支持在BI(业务智能化)工具中,将OAuth用于个人用户的身份验证。此外,有些平台会趋向采取“避重就轻”的途径,绕开那些最适合达到安全效果的身份验证方式。例如,在许多公司中,明明应用程序可以使用更强的、基于密钥(PKI)的身份验证方式,它们却仅使用“用户名+密码”去连接数据仓库。对此,数据和安全团队(有时还应包括IT团队)需要通过协作,来解决并确保有明确的安全指导策略,来具体规定应该使用哪种身份验证的类型。例如:应尽可能地使用与身份提供商(Identity Provider)相集成的方式,让用户遵守组织已有的双因素身份验证策略。?
授权
在数据仓库安全性中,最难管控的部分莫过于授权了。此处的授权是指:一旦用户通过了数据仓库的身份验证,就应该准确授予他们可以访问哪些数据、以及在什么级别上进行访问。不同的CDW有着不同的授权机制。例如,Snowflake具有严格的、基于角色的访问控制模型(RBAC),而Amazon的Redshift最近也推出了自己的RBAC模型。?
总的说来,CDW在授权过程中往往面临着如下安全挑战:?
- 由于用户量和数据种类比较庞大,因此许多用户往往需要频繁地更改其数据访问的相关权限,这就会给数据工程团队造成工作量上的压力。
- 企业通常会忽略执行“撤销对用户不再需要的数据访问权限”的流程。
- 难以出于合规性和安全性的通用需求,及时、准确地跟踪用户对于敏感数据的访问。
- 用户经常被授予过多的访问权限。
在CDW运行一段时间后,如果我们无法恪守明确的访问规则,他们的访问权限就会很快变得复杂、且难以管理。对此,企业需要启用自动化的数据访问授权、创建和执行明确的安全策略,以及应用到不同数据仓库环境的安全访问规则。?
细粒度的访问控制
在云数据仓库的语境中,我们认为针对诸如:表、视图、模式、以及数据库的访问控制,属于“粗粒度”对象管理。除此之外,我们还会碰到居多“细粒度”管理的安全需求。也就是说,我们需要对于某些用户是否能够仅访问表中的特定行(即,行级别安全性),以及根据用户或其角色,对数据的操作能力予以动态屏蔽。同样,在此方面,不同的CDW也具有不同的能力。在某些平台中,您可以通过使用现成的函数和视图,来设计并实现此类策略;而在其他的平台上,您可能需要自行创建策略,并将其应用于数据对象上。当然,如果数据量和类型过大的话,则需要通过自动化控制机制,来实现大规模数据访问的全覆盖。?
审计和监控
审计和监控既是数据访问平台内部安全的重要组成部分,也是合规性的基本要求。同样,不同的CDW提供不同级别的审计日志,以及启用它们的不同步骤。例如,在Snowflake中,数据访问日志是开箱即用的snowflake.account_usage架构(可使用SQL的选择查询),而对于Amazon的Redshift,您需要通过配置查询日志,以导出到S3存储桶。?
优先级和保护敏感数据
和过去保存在本地的数据类似,在确保CDW的数据安全性时,我们离不开与业务、运维团队的协作,以了解企业的敏感数据到底被存放在哪里,并且根据实际情况排定资源的安全优先级。
下面,我总结了当前四大主流的CDW平台,在上面提到的各项安全控制要点上的显著特点:?
AMAZON REDSHIFT | SNOWFLAKE | AZURE SYNAPSE | GOOGLE BIGQUERY? | |
网络访问控制 | 已作为AWS账户网络策略的一部分 | 使用SQL予以定义 | 已作为Azure中Synapse工作区配置的一部分 | 已在G-Suite管理面板中定义 |
访问控制 | 已使用SQL配置,对用户、组或角色进行授权 | 已使用SQL配置,仅使用角色授权(严格的RBAC) | 使用Azure(用于添加用户)和SQL(用于授予对特定对象的访问权限)对用户或角色进行配置 | 使用GCP的UI/API来配置,以授予用户或组的访问权限 |
细粒度的安全性 | 作为平台一部分,实现列级访问 | 作为平台一部分,实现动态屏蔽和行级策略 | 作为平台一部分,实现动态屏蔽、列级和行级策略 | 作为平台一部分,实现列级和行级策略 |
审计和监控 | 提供将审计日志导出到S3所需的配置 | 虚拟数据库模式(snowflake.account_usage)中的自动访问和查询日志 | 提供启用对Azure存储的审核所需的配置 | 作为GCP一部分的自动访问和查询日志(可以使用REST API实现拉取) |
小结
云数据仓库能够使数据团队更加专注于增加本企业数据的驱动价值。而随着更多的用户能够访问更多、且不断变化的海量数据,我们对数据访问的安全性保护也需要越来越重视。因此,在将数据迁移至CDW之前,我们需要对平台的安全性做好评估。而在完成迁移并开始使用CDW平台时,安全团队既要能够使用由平台提供的安全管控措施,又要善于使用其他安全元素(如,BI工具或数据访问处理方法),来补齐CDW的本身不足。?
当然,无论您选择了上面提到的何种CDW(可能不仅会考虑平台的安全能力,也会综合考量各种其他因素),请通过明确的安全策略、数据和安全团队之间的紧密协作、以及持续降低数据风险的方案,实现对企业数据的妥善管理。?
译者介绍
陈峻?(Julian Chen),51CTO社区编辑,具有十多年的IT项目实施经验,善于对内外部资源与风险实施管控,专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式,分享前沿技术与新知;经常以线上、线下等方式,开展信息安全类培训与授课。
原文标题:??Data Security Considerations in Cloud Data Warehouses??,作者:Ben Herzberg