Clever Geek Handbook

多租户解决方案中数据仓库的隔离和孤岛



在上一篇文章中，我们探讨了建立Amazon EKS多租户（以下称为多租户）集群的几个关键点。就安全性而言，这是一个非常广泛的话题。重要的是要理解安全性不仅与应用程序集群有关，而且与数据存储有关。AWS作为SaaS解决方案的平台，其数据仓库的可变性很大。但是，像其他地方一样，称职的安全配置，为此制定一个多租户架构，设置各种级别的隔离要求对工作的某些知识和理解。







多租户数据仓库



通过料斗Silo方便地 管理多租户数据。主要特征是在多租户SaaS解决方案中将租赁数据（以下称租户）分离。但是在讨论具体案例之前，让我们先谈一些一般性的理论。



隐藏文字
“ bunker”一词尚未在俄罗斯IT专家语中扎根，但我们将类似于“数据湖”来使用它。



只有房客才能访问



数据安全是SaaS解决方案的优先事项。有必要保护数据不仅免受外部入侵，而且还应防止与其他租户的交互。即使在两个租户彼此合作并根据业务逻辑控制和配置对共享数据的访问的情况下。



加密和安全性行业标准



租户 标准可能因行业而异。有些需要以明确定义的密钥更改频率进行数据加密，而另一些则需要面向租户的密钥而不是共享密钥。通过标识具有特定租户的数据集，可以将不同的加密标准和安全设置作为例外应用于单个租户。



基于租户订阅的性能调优



通常，SaaS提供商建议所有租户使用通用的工作流程。从实践的角度来看，相对于特定的业务逻辑，这可能并不总是很方便。因此，它可以以不同的方式完成。根据TIER标准，为每个租户分配了一组不同的属性和性能限制。为了使客户获得SaaS协议中规定的性能，提供商必须监视单个租户的使用。这使所有客户都可以平等地访问资源。



隐藏文字
当然，这会影响客户的帐户。任何使用更多资源的人都会付出更多。



数据管理



随着SaaS服务的增长，租户数量也随之增加。如果客户更改了提供者，则大多数情况下，他希望将所有数据上载到另一个资源，并删除旧的数据。如果可以挑战第一个需求，那么欧盟通用数据保护规则将保证第二个需求的实现。为了正确执行规则，SaaS提供者必须首先识别单个租户的数据集。



隐藏文字
?! , , . . .


如何将常规数据仓库变成多租户



我想立即指出，没有魔术代码。您不能只是拿起并配置租户数据仓库箱。应考虑以下方面：



  • 服务协议;
  • 读写方式
  • 遵守法规；
  • 花费。


但是，有许多公认的分离和隔离数据的做法。以Amazon Aurora关系数据库为例，考虑这些情况。



在共享存储库和实例中对租户数据进行分区





该表供所有租户使用。单个数据由密钥tenant_id分隔和标识。关系数据库授权是在行级安全性上实现的。对应用程序的访问基于访问策略，并考虑了特定的租户。



优点：



  • 不贵


缺点：



  • 数据库级授权。这意味着解决方案中的几种授权机制：AWS IAM和数据库策略；
  • 为了识别租户，您将必须开发应用程序逻辑；
  • 没有完全隔离，将无法执行TIER服务协议；
  • 数据库级授权使用AWS CloudTrail限制访问跟踪。这只能通过添加外部信息来补偿。更好地进行跟踪和故障排除。


共享实例上的数据隔离





租约（租期）在实例级别仍为rassharivat。但同时，数据加仓发生在数据库级别。这将启用AWS IAM身份验证和授权。



优点：



  • 它并不昂贵；
  • AWS IAM完全负责身份验证和授权；
  • AWS IAM允许您将审计日志保留在AWS CloudTrail上，而不会像单独的应用程序那样cru脚。


缺点：



  • 租户之间的基本实例DB sharyatsya ，与可能未完全满足有关服务的TIER协议的资源外流有关。


租户的数据库实例隔离





该图显示了用于实例隔离的租户数据库的实现。今天，它可能是结合安全性和可靠性的最佳解决方案。有AWS IAM，AWS CloudTrail审核和完整的租户隔离。



优点：



  • AWS IAM提供身份验证和授权；
  • 有完整的审核；
  • tenant.


:



  • tenant — .


multitenant



与以符合业务需求的租户模型中存储数据相比，确保应用程序有权访问数据更为重要。如果您使用AWS IAM进行访问控制并不难（请参见上面的示例）。为租户提供数据访问的应用程序也可以使用AWS IAM。在Amazon EKS的示例中可以看到这一点。



为了在EKS中提供Pod级IAM访问，OpenID Connect（OIDC）以及Kubernetes帐户注释是完美的。结果，JWT将与STS，它将为应用程序创建对必要的云资源的临时访问。使用这种方法，您无需为基本的Amazon EKS worker节点输入扩展权限。相反，您只能为与Pod相关的帐户配置IAM权限。这是根据作为pod的一部分运行的应用程序的实际权限来完成的。结果，我们可以完全控制应用程序和pod的权限。



隐藏文字
, AWS CloudTrail EKS pod API, .


IAM 集成支持用于租户访问数据存储的全面授权系统。在这种情况下，仅通过身份验证来控制对数据库的访问，这意味着必须引入另一安全级别。



Amazon EKS访问多租户AWS DynamoDB







仔细研究多租户访问，这两个应用程序都运行在Amazon的EKS上，并且可以访问多租户数据库Amazon的DynamoDB。在许多情况下，Amazon DynamoDB中的多租户流程是在表级别上实现的（表与租户的比例为1：1）。例如，请考虑AWS IAM原则（aws-dynamodb-tenant1-policy），该原则完美地说明了访问模式，其中所有数据都与Tenant1相关联。 



{
   ...
   "Statement": [
       {
           "Sid": "Tenant1",
           "Effect": "Allow",
           "Action": "dynamodb:*",
           "Resource": "arn:aws:dynamodb:${region}-${account_id}:table/Tenant1"
       }
   ]
}




下一步是将此角色与使用OpenID的EKS群集帐户关联。 



eksctl utils associate-iam-oidc-provider \
      --name my-cluster \
      --approve \
      --region ${region}



eksctl create iamserviceaccount \
      --name tenant1-service-account \
      --cluster my-cluster \
      --attach-policy-arn arn:aws:iam::xxxx:policy/aws-dynamodb-tenant1-policy \
      --approve \
      --region ${region}


包含必需的serviceAccountName规范 的pod定义将帮助您使用新的tenant1-service-account service account。 



apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
serviceAccountName: tenant1-service-account
 containers:
 - name: tenant1
…


尽管IAM租户帐户和策略是使用Terraform和Ansible之类的工具定向，静态和管理的，但可以动态配置Pod规范。如果使用的模板生成器（例如Helm），则可以将serviceAccountName设置为适当的服务租户帐户的变量。结果，每个租户将拥有自己专用的同一应用程序部署。实际上，每个租户都应该有一个专用的名称空间，用于运行应用程序。



隐藏文字
Amazon Aurora Serverless, Amazon Neptune Amazon S3.


结论



对于SaaS服务，请仔细考虑如何访问数据，这一点很重要。考虑存储，加密，性能和租户管理要求。在多租户中具有任何一种优选的数据分区方法。运行多租户AWS工作负载的优势是AWS IAM，可用于简化租户数据的访问控制。此外，AWS IAM可以帮助您动态配置应用程序对数据的访问。



所描述的特性和技术可能会在一些理论上派上用场。但是在特殊情况下，始终有必要独立分析源信息并创建个性化解决方案。


More articles:


All Articles