Novo Nordisk 如何大规模建立分布式数据治理和控制

这是一篇与诺和诺德的乔纳坦·塞尔辛和摩西·亚瑟共同撰写的客座文章。

这是由三部分组成的系列文章的第二篇文章，该系列详细介绍了大型制药企业 N ovo Nordisk 如何与 亚马逊云科技 专业服务 合作构建可扩展且安全的数据和分析平台。本系列 的第一篇文章 描述了整体架构以及Novo Nordisk如何构建去中心化数据网格架构，包括 作为数据查询引擎的 Amazon A thena。第三篇文章将展示最终用户如何在不影响数据治理的情况下使用他们选择的工具中的数据。这将包括如何配置 Okta、 亚马逊云科技 Lake Formation 和商业智能工具 ，使企业商业智能活动能够基于 SAML 联合使用 Athena。

在 亚马逊云科技 上构建可扩展的数据架构时，赋予数据域的自主权和所有权对于平台的成功至关重要。通过向具有业务领域知识的人员提供自由和控制的正确组合，您的企业可以尽快有效地从数据中获得最大价值。但是，组织面临的挑战是如何在自由与控制之间取得适当的平衡。同时，数据是一项战略资产，需要以最高程度的严格保护。组织如何在自由与控制之间取得适当的平衡？

在这篇文章中，您将学习如何使用 Lake Formation 和 亚马逊云科技 身份和访问管理 (IAM) 使用基于属性的访问 控制 (ABAC) 建立去中心化治理。我们将讨论我们使用的一些模式，包括在权限策略中使用ABAC的 Amazon Cognito 身份池联合，以及基于Okta的SAML联合，ABAC强制执行角色信任策略。

解决方案概述

在本系列 的第一篇文章 中，我们解释了 Novo Nordisk 和 亚马逊云科技 专业服务如何基于数据网格原则构建现代数据架构。该架构支持对分布式数据域进行数据治理，使用端到端解决方案来创建数据产品并提供联合数据访问控制。这篇文章深入探讨了解决方案的三个要素：

• 如何使用 IAM 角色和 Lake Formation 管理跨数据域的数据访问权限
• 如何使用具有 ABAC 模式的群组成员映射大规模实施数据访问控制
• 系统如何维护不同层次的状态，以便正确配置信任生态系统

从最终用户的角度来看，本文中描述的机制的目的是简化来自Novo Nordisk采用的不同分析服务的数据访问，例如由Databricks等软件即服务 (SaaS) 供应商或JupyterHub等自托管服务供应商提供的分析服务。同时，平台必须保证数据集中的任何更改都会立即反映在服务用户界面上。下图从较高的层面上说明了预期的行为。

按照 第一篇文章 中确立的层级命名法 ，服务是在消费层创建和管理的。域帐户是在数据管理层中创建和管理的。由于两层都可能发生变化，因此需要双向持续通信。状态信息与通信协议一起保存在虚拟化层中。此外，在登录时，服务需要有关提供数据访问抽象所需的数据资源的信息。

管理数据访问权限

该架构中的数据访问控制是围绕核心原则设计的，即所有访问都封装在隔离的 IAM 角色会话中。我们在 第一篇文章 中描述的层级模式 确保可以将所涉及的 IAM 角色策略的创建和管理委托给不同的数据管理生态系统。集成的每个数据管理平台都可以使用自己的数据访问机制，其独特要求是通过特定的 IAM 角色访问数据。

为了说明数据管理解决方案可以使用的潜在机制，我们举了两个不同的数据管理解决方案使用的数据访问权限机制的示例。这两个系统都使用与以下各节中描述的相同的信任策略，但权限空间完全不同。

示例 1：基于身份的 ABAC 策略

我们讨论的第一个机制是ABAC角色，它提供对家庭式数据存储区域的访问权限，用户可以在模仿组织结构的结构中与部门内部以及更广泛的组织共享。在这里，我们不使用群组名称，而是通过声明覆盖将用户属性从公司 Active Directory 直接转发到权限策略中。为此，我们让公司活动目录作为 Amazon Cognito 用户池的身份提供者 (IdP)， 并将相关的 IdP 属性映射到用户池属性 。 然后，在 Amazon Cognito 身份池中，我们将 用户池属性 映射到会话标签 ，以使用它们进行访问控制。通过使用 代币生成 前 Lambd a 触发器，可以将自定义覆盖包含在声明映射中。 这样，来自 AD 的声明可以映射到 Amazon Cognito 用户池属性，然后最终在 Amazon Cognito 身份池中使用来控制 IAM 角色权限。以下是带有会话标签的 IAM 策略的示例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "",
                        "public/",
                        "public/*",
                        "home/",
                        "home/${aws:PrincipalTag/initials}/*",
                        "home/${aws:PrincipalTag/department}/*"
                    ]
                }
            },
            "Action": "s3:ListBucket",
            "Resource": [
                "arn:aws:s3:::your-home-bucket"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:GetObject*",
                "s3:PutObject*",
                "s3:DeleteObject*"
            ],
            "Resource": [
                "arn:aws:s3:::your-home-bucket/home/${aws:PrincipalTag/initials}",
                "arn:aws:s3:::your-home-bucket/home/${aws:PrincipalTag/initials}/*",
                "arn:aws:s3:::your-home-bucket/public/${aws:PrincipalTag/initials}",
                "arn:aws:s3:::your-home-bucket/public/${aws:PrincipalTag/initials}/*",
                "arn:aws:s3:::your-home-bucket/home/${aws:PrincipalTag/department}",
                "arn:aws:s3:::your-home-bucket/home/${aws:PrincipalTag/department}/*",
                "arn:aws:s3:::your-home-bucket/public/${aws:PrincipalTag/department}",
                "arn:aws:s3:::your-home-bucket/public/${aws:PrincipalTag/department}/*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": "s3:GetObject*",
            "Resource": [
                "arn:aws:s3:::your-home-bucket/public/",
                "arn:aws:s3:::your-home-bucket/public/*"
            ],
            "Effect": "Allow"
        }
    ]
}

然后，该角色被嵌入到分析层（与数据域角色一起），并代表用户担任。这使用户能够在数据域之间进行混合和匹配，也可以利用不一定与任何数据域关联的私有和公共数据路径。有关如何将 ABAC 与权限策略一起使用的更多示例，请参阅 如何通过在 S3 中使用基于属性的访问控制来扩展您的授权需求 。

示例 2：基于湖群名称的访问控制

在我们在 第一篇文章 中介绍的名为Novo Nordisk Enterprise Datahub（NNEDH）的数据管理解决方案中 ，我们使用Lake Formation来实现标准化数据访问。NNEDH 数据集在湖泊形成数据目录中注册为数据库和表，并使用 命名资源 方法授予权限。 以下屏幕截图显示了这些权限的示例。

在这种方法中，将数据访问管理委托给 Lake Formation。NNEDH 中的每个数据域都有 NNEDH 作为中央治理管理层合成的隔离权限。这与其他面向域的数据管理解决方案所采用的模式类似。有关 Lake Formation 中基于标签的访问控制示例，请参阅 使用事件驱动架构在 亚马逊云科技 上构建数据网格 。

这些模式不排除点对点类型的数据共享机制的实现，例如可以使用 亚马逊云科技 资源访问管理器 (亚马逊云科技 RAM) 实现的那些机制，其中单个 IAM 角色会话可以拥有跨账户的权限。

稍后将角色访问权限委派给消费者

下图说明了来自外部服务的数据访问工作流程。

工作流程步骤如下：

1. 用户在他们尝试访问的分析工具使用的 IdP 上进行身份验证。Novo Nordisk 平台支持各种分析工具，例如 Databricks 和 JupyterHub，根据第三方工具的功能，IdP 可以是 SAML 或 OIDC 类型。在此示例中，使用 Okta SAML 应用程序登录第三方分析工具，并在数据域 亚马逊云科技 账户中配置 IAM SAML I dP 以与外部 IdP 联合。本系列的第三篇文章描述了如何在 Athena 上为 IAM 角色联合设置一个 Okta SAML 应用程序。
2. 在登录过程中获得的 SAML 断言用于通过 AssumeRole 操作请求 IAM 角色的临时安全证书。 在此示例中，在 Ass um eRoleWithSAML 操作中使用了 SAML 断言。对于兼容 OpenID Connect 的 IDP，操作必须与 JWT 一起使用 A ssumeRoleWithWebidentity 。对于以下部分中描述的 ABAC 策略模式，可以在登录时生成断言中的 SAML 属性或令牌中的声明，以确保转发组成员资格。
3. 诸如Databricks或JupyterHub之类的分析工具在工具本身中抽象了IAM角色会话证书的用法，并且可以根据所承担的IAM角色的权限直接访问数据。这种模式本质上与Databricks实现的 IAM直通 模式类似，但在Novo Nordisk中，它已扩展到所有分析服务。在此示例中，分析工具通过 Athena 查询访问 亚马逊 Simple Storage Ser vice (Amazon S3) 上的数据湖。

随着数据网格模式在涵盖更多下游服务的域中扩展，我们需要一种机制来持续更新 IdP 和 IAM 角色信任。我们将在文章后面再来讨论这一部分，但首先我们将解释如何大规模管理角色访问权限。

基于属性的信任策略

在前面的章节中，我们强调该架构依赖于 IAM 角色进行数据访问控制。每个数据管理平台都可以使用 IAM 角色实现自己的数据访问控制方法，例如基于身份的策略或 Lake Formation 访问控制。对于数据消耗，至关重要的是，只有属于具有使用该角色的适当权限的 Active Directory 群组中的用户才能担任这些 IAM 角色。为了大规模实现这一点，IAM 角色的信任策略使用 ABAC。

当用户在消费层的外部 IdP 上进行身份验证时，我们会在访问令牌中添加一项源自其 Active Directory 群组的声明。此声明由 A ssumeRole 操作传播到 IAM 角色的信任策略中，然后将其与预期的 Active Directory 组进行比较。只有属于预期组的用户才能担任该角色。下图说明了这种机制。

将群组成员资格转换为属性

为了在角色假设级别强制执行群组成员资格，我们需要一种方法将所需的群组成员资格与用户在 IAM 角色会话中获得的群组成员资格进行比较。为了实现这一点，我们使用了 ABAC 的形式，我们可以在单个属性中表示与上下文相关的群组成员的总和。单个 IAM 角色会话标签值限制为 256 个字符 。SAML 断言的相应限制为 100,000 个字符 ，因此对于需要大量角色或组类型映射的系统，SAML 可以支持更广泛的配置。

在本例中，我们选择了压缩算法，该算法采用组名并将其压缩为 4 个字符的字符串哈希。这意味着，再加上分组分隔字符，我们可以在单个属性中放置 51 个组。由于 PackedPolicySize，在 OIDC 类型角色假设中，该值被下推到大 约 20 个组 ，但对于基于 SAML 的流程，则更高。事实证明，这对我们的情况来说已经足够了。两个不同的组有可能哈希到相同的字符组合；但是，我们已经检查现有组中没有冲突。为了降低未来的这种风险，我们在多个地方引入了护栏。首先，在虚拟化层中添加新的组权限之前，我们检查是否存在与任何现有组的哈希冲突。当尝试添加重复的群组时，我们的服务团队会收到通知，我们可以做出相应的反应。但是如前所述，发生冲突的可能性很低，因此它提供的灵活性超过了与管理冲突相关的开销（我们还没有发生冲突）。此外，我们还会在创建 SAML 断言时强制执行此操作，以确保用户组列表中没有重复的组，如果出现重复，我们会将两者全部删除。这意味着恶意行为者最多可以限制其他用户的访问权限，但无法获得未经授权的访问权限。

跨会话强制执行审计功能

正如第一篇文章所提到的，除了治理之外，对数据访问的可审计性也有严格的要求。这意味着，对于所有数据访问请求，必须能够跨服务跟踪特定用户并保留这些信息。我们通过 为所有角色会话设置（和强制执行） 源身份 来实现此目的，并确保将企业身份传播到该属性。我们使用 Okta 内联挂钩 和 SAML 会话标签 的组合 来实现这一点。这意味着 IAM 角色会话 的 亚马逊云科技 CloudTrail 日志包含以下信息：

{
    "eventName": "AssumeRoleWithSAML",
    "requestParameters": {
        "SAMLAssertionlD": "id1111111111111111111111111",
        "roleSessionName": "user@novonordisk.com",
        "principalTags": {
            "nn-initials": "user",
            "department": "NNDepartment",
            "GroupHash": "xxxx",
            "email": "user@novonordisk.com",
            "cost-center": "9999"
        },
        "sourceIdentity": "user@novonordisk.com",
        "roleArn": "arn:aws:iam::111111111111:role/your-assumed-role",
        "principalArn": "arn:aws:iam,111111111111:saml-provider/your-saml-provider",
        ...
    },
    ...
}

在 IAM 角色级别，我们可以使用以下示例信任策略强制执行所需的属性配置。这是基于 SAML 的应用程序的示例。我们通过 OpenID Connect IDP 支持相同的模式。

现在，我们基于以下示例介绍 IAM 角色信任策略的元素：

{
    "Version": "2008-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": {
            "Federated": [SAML_IdP_ARN]
        },
        "Action": [
            "sts:AssumeRoleWithSAML",
            "sts:TagSession",
            "sts:SetSourceIdentity"
        ],
        "Condition": {
            "StringEquals": {
                "SAML:aud": "https://signin.aws.amazon.com/saml"
            },
            "StringLike": {
                "sts:SourceIdentity": "*@novonordisk.com",
                "aws:RequestTag/GroupHash": ["*xxxx*"]
            },
            "StringNotLike": {
                "sts:SourceIdentity": "*"
            }
        }
    }
}

该政策包含以下详细信息：

• 主要 声明应指向通过消费层提供的应用程序列表。这些可以是 Azure 应用程序注册、Okta 应用程序或亚马逊 Cognito 应用程序客户端。这意味着，如果剩余元素也得到满足，则可以使用从这些应用程序中生成的 SAML 断言（如果是基于 SAML 的流）来运行 A ssumeRoleWith Saml 操作。
• 操作 语句包括成功执行 A ssumeRole 调用所需的权限，包括向角色会话添加上下文信息。
• 在第一个条件下，断言的受众必须以 亚马逊云科技 为目标。
• 在第二个条件中，有两个 StringLik e
  • 要求： 要求将 源身份 作为诺和诺德遵循的命名惯例（用户必须根据我们的审计要求提供企业身份）。
  • aws: requesttag/groupHash 必须为 xxxx ，它代表上面提到的哈希组名称。
• 最后，我们强制规定，如果不设置源身份，就无法启动会话。

该政策强制要求所有呼叫均来自公认的服务，包括可审计性，有正确的目标，并强制用户拥有正确的组成员资格。

建立治理和信任的核心概览

在本节中，我们将讨论 Novo Nordisk 如何跟踪相关的群组角色关系并在登录时映射这些关系。

应享权利

在 Novo Nordisk 中，所有访问权限都基于 Active Directory 群组成员资格。没有基于用户的访问权限。由于这种模式非常重要，因此我们将这种访问理念扩展到了我们的数据访问中。如前所述，在登录时，考虑到给定用户的群组成员资格，挂钩需要能够知道该用户要扮演哪些角色。我们已经在 Amazon DynamoDB 中对这些数据进行了建模，其中即时配置可确保只有所需的用户组成员资格可用。通过围绕群组的使用来构建应用程序，并通过应用程序代码完成群组传播，我们可以避免进行更通用的Active Directory集成。对于像Novo Nordisk这样规模的公司来说，这仅仅是由于用户和群组的数量而严重影响应用程序。

DynamoDB 授权表包含所有角色和服务的所有相关信息，包括角色 ARN 和 IdP ARN。这意味着，当用户登录其分析服务时，登录挂钩可以为 Roles SAML 属性构造 所需的信息 。

将新的数据域添加到数据管理层时，数据管理层需要传达角色信息和提供角色访问权限的组名。

分析服务的单点登录中心

当将这种权限模型和数据管理模式扩展到像 Novo Nordisk 这样的大型企业时，我们最终创建了分布在不同账户中的大量 IAM 角色。然后，需要一个解决方案来映射并向最终用户提供对所需的 IAM 角色的访问权限。为了简化用户对多个数据源和分析工具的访问，Novo Nordisk 开发了分析服务的单点登录中心。从最终用户的角度来看，这是一个网络界面，它将不同的产品粘合到一个统一的系统中，使其成为满足数据和分析需求的一站式工具。登录每个分析产品时，会转发经过身份验证的会话，因此用户无需重新进行身份验证。

消费层支持的所有服务的共同点是，我们可以在登录时运行一段应用程序代码，从而计算登录时间权限。例如，实现此功能的挂钩可以由 Okta 内联挂钩 运行。这意味着每个目标分析服务都可以有自定义代码来翻译相关的上下文信息或为角色转发提供其他类型的自动化。

登录流程如下图所示。

工作流程步骤如下：

1. 用户在诺和诺德分析中心访问诸如Databricks之类的分析服务。
2. 该服务使用 Okta 作为基于 SAML 的 IdP。
3. Okta 调用了一个基 于 亚马逊云科技 Lambda 的 SAML 断言内联挂钩 。
4. 该挂钩使用授权数据库，将与应用程序相关的组成员资格转换为角色权限。
5. 相关的上下文信息从授权数据库返回。
6. 基于 Lambda 的挂钩为 SAML 断言添加了新的 SAML 属性，包括经过哈希处理的组成员资格和其他上下文信息，例如源身份。
7. 修改后的 SAML 断言用于使用户登录分析服务。
8. 用户现在可以在活跃的 IAM 角色会话中使用分析工具。

同步角色信任

上一节概述了联合在此解决方案中的工作原理。现在，我们可以了解如何确保所有参与的 亚马逊云科技 环境和账户与最新配置保持同步。

从最终用户的角度来看，同步机制必须确保每个实例化的分析服务都能访问分配给用户所属群组的数据域。此外，数据域的更改（例如向 Active Directory 群组授予数据访问权限）必须立即对所有分析服务生效。

如本节所述，使用两种基于事件的机制来保持所有层的同步。

将数据管理层上的数据访问控制与消费层中服务的更改同步

如上一节所述，用于数据访问的 IAM 角色由数据管理层创建和管理。这些 IAM 角色具有信任策略，提供对消费层分析工具使用的外部 IdP 的联合访问权限。这意味着，对于使用不同 IDP 创建的每项新分析服务，必须更新用于数据域数据访问的 IAM 角色以信任这个新的 IdP。

以 NNEDH 作为数据管理解决方案的示例，同步机制如下图所示。

以创建新分析服务的场景为例，此工作流程中的步骤如下：

1. 有权访问消费层管理控制台的用户可以实例化新的分析服务，例如 JupyterHub。
2. 在 亚马逊云科技 Fargate 上运行的任务 会创建这项新分析服务所需的资源，例如 JupyterHub 的 亚马逊弹性计算云 (Amazon EC2) 实例，以及所需的 IdP，例如新的 SAML IdP。
3. 在上一步中创建 IdP 时，将在 亚马逊简单通知服务 (Amazon SNS) 主题中添加一个事件及其详细信息，例如名称和 SAML 元数据。
4. 在 NNEDH 控制平面中，Lambda 任务是由此 SNS 主题上的新事件触发的。如果需要，此任务会创建 IAM IdP，并更新所有用作数据域的 亚马逊云科技 账户中必需 IAM 角色的信任策略，同时添加对新分析服务使用的 IdP 的信任。

在此架构中，所有更新步骤均由事件触发且可扩展。这意味着新分析服务的用户可以在创建数据集时几乎立即访问这些数据集。同样，删除服务时，如果未被其他服务使用，则会自动移除与 IdP 的联合。

将数据域上的更改传播到分析服务

对数据域的更改，例如创建用作数据集的新 S3 存储桶，或添加或删除对群组的数据访问权限，必须立即反映在消费层的分析服务上。为此，使用了一种机制将授权数据库与NNEDH中所做的相关更改同步。下图演示了此流程。

以向新组授予对特定数据集的访问权限的场景为例，此工作流程中的步骤如下：

1. 数据所有者使用 NNEDH 管理控制台批准数据集共享请求，该请求向 Active Directory 群组授予对数据集的访问权限。
2. 在相关数据域的 亚马逊云科技 账户中，S3 存储桶和 Lake Formation 等数据集组件已更新，以提供对新组的数据访问权限。 Lake Formation 中的跨账户数据共享 使用 亚马逊云科技 RAM。
3. SNS 主题中添加了一个事件，其中包含有关该数据集的当前详细信息，例如 S3 存储桶的位置以及当前有权访问该存储桶的群组。
4. 在虚拟化层中，来自数据管理层的更新信息用于更新 DynamoDB 中的授权数据库。

这些步骤可确保对数据域的更改自动立即反映在授权数据库上，该数据库用于为消费层的所有分析服务提供数据访问权限。

局限性

其中许多模式依赖分析工具来支持巧妙地使用 IAM 角色。如果情况并非如此，平台团队本身需要在主机级别开发自定义功能，以确保正确控制角色访问权限。例如，这包括为 JupyterH ub 编写自定义身份验证器 。

结论

这篇文章介绍了一种构建可扩展且安全的数据和分析平台的方法。它展示了Novo Nordisk使用的一些机制以及如何在自由与控制之间取得适当的平衡。本系列第一篇文章中阐述的架构实现了层级独立性，并公开了一些用于数据访问和治理的极其有用的原语。我们大量使用上下文属性来调节会话级别的角色权限，从而提供即时权限。这些权限在数据域之间大规模传播。好处是，与管理数据访问权限相关的许多复杂性可以委托给相关的业务组，同时使数据的最终用户可以尽可能少地考虑数据访问问题，专注于为业务用例提供价值。就诺和诺德而言，它们可以为患者提供更好的疗效并加速创新。

本系列的下一篇文章介绍最终用户如何使用他们选择的分析工具中的数据，并结合本文中详述的数据访问控制。

作者简介

乔纳坦·塞尔辛 是前研究科学家，拥有天体物理学博士学位，现已转向云端。他目前是 Novo Nordisk 的首席云工程师，负责大规模支持数据和分析工作负载。他的重点是降低基于云的工作负载的总拥有成本，同时充分利用云的优势，他设计、构建和维护解决方案，使未来药物的研究成为可能。

哈森·里亚希 是 亚马逊云科技 专业服务的高级数据架构师。他拥有大规模数据管理的数学和计算机科学博士学位。他与 亚马逊云科技 客户合作构建数据驱动的解决方案。

亚历山德罗·费奥 是 亚马逊云科技 专业服务的高级数据架构师。他热衷于设计和构建现代且可扩展的数据平台，以加速公司从数据中提取价值。

摩西·亚瑟 来自数学和计算研究背景，拥有专门研究图形挖掘的计算智能博士学位。他目前是诺和诺德的云产品工程师，负责为生产数字化医疗产品的诺和诺德全球工厂构建符合 GxP 标准的企业数据湖和分析平台。

Anwar Rizal 是一位驻巴黎的高级机器学习顾问。他与 亚马逊云科技 客户合作开发数据和 AI 解决方案，以可持续地发展他们的业务。

Kumari Ramar 是 亚马逊云科技 专业服务部敏捷认证和 PMP 认证的高级参与经理。她提供数据和人工智能/机器学习解决方案，加速跨系统分析和机器学习模型，使企业能够做出数据驱动的决策并推动新的创新。