インメモリデータベースのストレージとセキュリティ（MemSQL、Spark、Redis、Geodeなど）
ビッグデータ分析（Spark）からより高速な処理能力（MemSQL）、最も頻繁にアクセスされるデータをキャッシュ（Redis）してディスクベースのRDBMSに移行するまで、さまざまなユースケースでより多くのインメモリストレージを利用する傾向が高まっています。 。 AWS Elasticacheはこの例です。最近聞いたアーキテクチャの「ベストプラクティス」の1つは、最初にすべてをキャッシュすることです。次に、使用頻度の低い（コールド）データに対してのみディスクにアクセスします。
より多くのインメモリストレージを活用する傾向が高まっているため、securingこれらのデータストア、およびそれに付随する潜在的な関連する脆弱性について、あまり書かれていません。 Elasticacheデータに利用できる暗号化があるかどうかをAmazonに尋ねたところ、彼らはノーと答えました。
さらに、規制対象の機関に対して、従来のデータストレージのセキュリティガイドラインがディスクベースのストレージと同じように適用されるかどうかはわかりません。たとえば、保存データ（DAR）の暗号化は、クラウド内の機密データ（PII、PHIなど）のNIST要件です。この同じ基準は、存在するデータにのみ適用されますかin-memory？そうでない場合、それは本当に良いアイデアですか？ NISTや他のセキュリティ組織は、この分野での潜在的な攻撃ベクトルをまだ検討していますか？もしそうなら、メモリ内ストレージに関して公開されているガイドラインはありますか？それとも、古いルール/規制/ガイドラインから推測して、このストレージ環境に外挿することになっていますか？
Secure In-Memory Data Storesについての考えは、特にサードパーティの評価者を通じてシステムのセキュリティを証明しなければならなかった人々から高く評価されています。
すべての作業データがRAMに保存されているため、メモリ内のデータストア/キャッシュの暗号化は通常行われません。そのため、暗号化キーはある時点で、攻撃者がメモリのメモリにアクセスできる場合、システムでは、彼はデータを復号化する手段にアクセスするか、復号化後にデータにアクセスする手段を持っているため、追加のセキュリティは提供されません。
ベストプラクティスは、アプリケーションに対して Threat Modeling を実行して、外部プロセスまたはマシンからの不正アクセスを防止することです。これにより、攻撃者がデータにアクセスしたり、データを攻撃したりするすべての方法が明らかになります。脅威モデリングにはいくつかの方法論があり、私が使用した方法は [〜＃〜] stride [〜＃〜] です。 Microsoftが提供する 無料のツール があり、この方法論を使用して脅威モデルを作成するのに役立ちます。これはインメモリデータベースに固有のものではなく、特定のアプリケーションのセキュリティの側面をカバーするため、より包括的です。