マルチテナントデータアーキテクチャ - 共有スキーマ - セキュリティ

Question

新しいプロジェクトを開始するには、MultiTenancyが必要です。ストレージレベルでは、これはいくつかの方法で実行できます。 （個別のデータベース/別々のスキーマ/共有スキーマ）

運用コストを抑えるため、「共有スキーマ - 共有テーブル」は継続するのに最適です。したがって、すべてのテナントは同じデータベース/スキーマスキーマで同じテーブルを共有します。

しかし、制約は良いテナントの分離とセキュリティを提供することです。このために私たちは暗号化を使うことができます。各テナントに独自の鍵ペアを提供できる場合は、優れたセキュリティと良好な分離性を提供します。各テナントは自分のデータだけを読むことができ、各テーブルにも弁別子フィールドを追加する必要はありません。

これを技術的にどのように実装できますか？テーブルを照会すると、復号化できないデータ（他のテナントからのデータ）が得られます。また、結合などでは、データベースにある他のレコードのために負荷が高くなります。

私はすでにMSDNでいくつかの記事を読んで、いくつかのプレゼンテーションを見てきましたが、それは非常に高いレベルと抽象的なままです。これについての考えは？ 上記のようなものがありますか？ Amazon RDSで何かできると思ったのですか？いくつかの例を提供することは可能ですか？例えばgithub？

Answer 1

あなたが共有した内容と、行間の読み方に基づいて、私はこのアプローチに注意しています。共有スキーマはそれだけでマルチテナントのための非常に合理的な設計です。私は問題が暗号化の示唆された使用にあると思うどこに。

PostgreSQLは暗号化をサポートしていますが、これはpgcryptoモジュールの関数を介して行われます。 PostgreSQLのマネージドサービスとしてのRDSは、暗号化されたボリュームも簡単にプロビジョニングする機能を追加しますが、データベースのユーザ/開発者には、ほぼ同じように見えます。

フィルタリングや結合が不要なデータの小さなサブセットのみを暗号化する必要がある場合は、pgcryptoを使用することをお勧めしますが、暗号化しようとするデータの量は不明です。一握りの列しかフィルタリングする必要がない場合、これは機能するかもしれません。さもなければ、pgcrypto関数を広範囲に使用すると、ほぼすべての標準データベース操作が不可能になります。 where句は列の解読を必要とし、順番に全テーブルをスキャン/解読する必要があります。インデックスの使用はゼロになります。あなたのパフォーマンスは非常に速くクロールするのが遅くなります。

あなたが提供していない主な考慮事項は、Webアプリケーションなど、アクセスをどのように提供しているかです.1つの信頼できるアカウントで完全にアクセスを調整しますか？顧客がデータベースに直接接続できるようにするか？前者の場合、あなたのコードはすべてのアクセスを管理していて、常にすべてのキーにアクセスする必要があります。なぜオーバーヘッドが発生するのですか？後者の場合、標準のクエリツールはすべて使いにくいため、データベースを顧客に使用できなくなる可能性があります。

私の経験によれば、テナントごとのスキーマアプローチは、分離、効率性、開発オーバーヘッドのバランスをとることができます。そして、PostgreSQLの役割を慎重に使用することで、直接アクセスのための合理的なアクセス制御を行うことができます（私の見解では行を同じにすることができますが、

一般的に使用されているアプリケーションフレームワークをいくつか見てみましょう。詳細は、Railsのアパートメントの宝石（https://github.com/influitive/apartment）をご覧ください。 Djangoには、django-tenantsライブラリ（http://django-tenants.readthedocs.io/en/latest/）があります。 Hibernateには、プラグイン可能なテナントフレームワーク（例えば、、https://docs.jboss.org/hibernate/orm/4.2/devguide/en-US/html/ch16.html）

これは役立ちます。