3

Azure でセキュリティ アーキテクチャにアプローチする方法についてアドバイスを求めています。

バックグラウンド：

非常に安全な (個人の機密データ) 必要があるマルチテナント アプリを Azure 上に構築することを検討しています。このアプリは、標準のブラウザとモバイル デバイスからアクセスできます。

セキュリティ アクセスの種類:

3種類のユーザー/アクセスタイプがあります...

1 - https を介した単純な古いユーザー/パスワードは問題なく、一般的な非プライベート SQL とホストされたファイルの両方にアクセスできます

2 - ユーザー/https を通過しますが、ユーザーのマシン/デバイスにインストールされる証明書によるユーザーの認証が必要です。このレベルのユーザーは、データベースとアップロードされたファイルの両方で保存時に暗号化する必要がある機密データにアクセスする必要があります。

3 - (2) と同じですが、いくつかの 2 要素認証が追加されています (他の目的で YubiKey を使用しました - 電話 OTP の提供も検討する可能性があります)。

ほとんどのユーザーは自分のテナント データベースにしかアクセスできませんが、選択したテナント データにアクセスする必要がある「アカウント マネージャー」タイプのユーザーがいるため、サービスを提供するテナントごとに 1 つの証明書のコピーが必要になると予想されます。ある種のマスター証明書を使用する必要があります。

データベースの種類:

マルチテナントの観点からは、Azure Federated SQL が適しているように思われます。(a) 各テーブルに "TenentID" キーを使用して 1 つのアプリを記述し、ログイン後に分離を処理するグローバル フィルターを設定するだけだからです。 (b) Azure フェデレーション SQL が実際にはバックグラウンドでテナントごとに個別の SQL データベース インスタンスを維持していることを理解しています。 -to-build-multi-tenant-databases-with-sql-databases.aspx )

ファイル共有のセットアップと管理、保存中の SQL とファイル データの暗号化、ユーザーの認証など (新しいユーザー サインアップ設定での自動管理) に必要なアプローチに関して、リンクを示したり、アドバイスを提供したりできます。

4

1 に答える 1

1

私は証明書についてはあまり役に立ちませんが、確かに「マスター証明書」が必要になります。Azure Web サイトの使用を計画している場合、現在、独自の証明書を使用することはできません。

データベースのセットアップについて。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 に答える