近年来，由于云计算与云存储具有一定的廉价性和可扩展性，云数据仓库（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
