3

我正在尝试就如何在 Azure 上处理安全架构获得一些建议。

背景：

我们正在考虑在 Azure 上构建一个需要非常安全（个人敏感数据）的多租户应用程序。该应用程序将由标准浏览器和移动设备访问。

安全访问类型：

我们有三种类型的用户/访问类型...

1 - 通过 https 的普通旧用户/密码很好，访问通用、非私有 SQL 和托管文件

2 - 用户/通过 https，但需要通过将安装在用户机器/设备上的证书对用户进行身份验证。此级别的用户将需要访问敏感数据，这些数据应在数据库和任何上传的文件中进行静态加密。

3 - 与 (2) 相同，但增加了一些两因素身份验证（我们已将 YubiKey 用于其他事情 - 也可能会考虑提供电话 OTP 产品）

大多数用户只能访问他们自己的租户数据库，但是我们有“客户经理”类型的用户需要访问选定的租户数据，因此我们希望他们需要为他们服务的每个租户提供一份证书的副本，或者我们将必须使用某种主证书。

数据库类型：

从多租户的角度来看，Azure Federated SQL 似乎是一个不错的选择，因为 (a) 我们只需在每个表中编写一个带有“TenentID”键的应用程序，然后在登录后设置一个全局过滤器来处理隔离我们 (b) 我们了解 Azure 联合 SQL 实际上在后台为每个租户维护单独的 SQL 数据库实例。（参考： http: //msmvps.com/blogs/nunogodinho/archive/2012/08/11/tips-amp-tricks -to-build-multi-tenant-databases-with-sql-databases.aspx )

任何人都可以指向任何链接或就设置和管理文件共享所需的方法、SQL 和静态文件数据的加密、用户身份验证等（新用户注册首选项的自动管理）提供建议。

4

1 回答 1

1

我对证书无能为力，但您确实需要一些“主证书”。如果您计划使用 Azure 网站，目前您不能使用自己的证书。

关于数据库设置。SAAS 应用程序建立在信任之上，因此您永远（永远）不希望向其他用户显示或编辑使用的数据。因此，我强烈建议您不要为每个表使用 TenantID。这仍然有可能受到恶意用户的攻击或某些开发人员的错误。

规避这些风险的唯一方法是

  1. 广泛的测试
  2. 物理不同的表来存储每个租户的数据。

我个人认为，即使进行了非常广泛的+自动化测试，您也无法对恶意用户进行 100% 的代码覆盖。我想我并不孤单。

恕我直言，唯一的出路是物理不同的表。让我们看看选项：

  1. 不同的服务器：有效，但在 azure 中相当昂贵
  2. 不同的数据库：有效，管理开销更少，但与前一个选项相同的反对意见 - 如果您有很多租户，则成本很高
  3. 不同的架构：解决方案。想一想...
    • 您只需要管理用户和默认架构
    • 您可以使用 powershell 备份架构
    • 您可以通过一些工作将架构移动到其他数据库
    • 如果需要，您仍然可以深入研究 SQL 联合。
    • 主要缺点是您需要支持每个租户的数据库升级。

您是否在 azure.com 上阅读过任何有关多租户的文章？ http://msdn.microsoft.com/en-us/library/windowsazure/hh689716.aspx

于 2012-11-25T12:54:00.087 回答