web-dev-qa-db-ja.com

HIPAA準拠のBLOBストレージアーキテクチャ

機密データを安全に保管するシステムを設計するタスクがあります（将来的にはHIPAAに準拠する必要があります）。これは単なるドラフトです。これは、近い将来、本番環境で使用されることはありません。 TrueVault に触発されたプロトタイプがあり、セマンティックセキュリティの欠如またはセキュリティ概念の違反があるかどうかを知りたいです。

したがって、システムは4つのサブシステムで構成されます。

Encryptor/Decryptor（Cryptor）は、ランダムキー/ ivの生成、AES-256-GCMアルゴリズム（OpenSSL実装）を使用したバイナリデータの暗号化と復号化を担当します。このサーバーはメモリ内操作のみを実行し、結果を他の3つのサブシステム内に保存し、IPSECまたはSSLVPNを介してそれらに接続します。他の3つのサブシステムは、相互に直接接続されていません。外部クライアントは、暗号化/復号化パブリックインターフェイスのみを使用し、他のサブシステムに直接接続されていません。

パブリックインターフェイス：

  • dump（client_binary_data）-> external_uuid
  • load（external_uuid）-> client_binary_data

データストアは[data_store_uuid、encrypted_data、auth_tag]トリプレットを格納します。

  • dump（encrypted_data、auth_tag）-> data_store_uuid
  • load（data_store_uuid）-> [encrypted_data、auth_tag]

KeyStoreは、[key_store_uuid、key、iv]トリプレットを格納します。

  • dump（key、iv）-> key_store_uuid
  • load（key_store_uuid）-> [key、iv]

MapsStoreは、DataStoreトリプレット、KeyStoreトリプレットおよびexternal_uuid間のマップを格納します：[external_uuid、data_store_uuid、key_store_uuid]。

  • dump（external_uuid、data_store_uuid、key_store_uuid）
  • load（external_uuid）-> [data_store_uuid、key_store_uuid]

ワークフロー：

  • Cryptor.dump（binary）
    1. external_uuidを生成します
    2. ランダムキーを生成する
    3. ランダムなivを生成する
    4. aES-256-GCMのAADとしてexternal_uuidを使用する
    5. client_binary_dataを暗号化-> encrypted_data
    6. auth_tagを派生させる
    7. KeyStore.dump（key、iv）-> key_store_uuid
    8. DataStore.dump（encrypted_data、auth_tag）-> data_store_uuid
    9. MapStore.dump（external_uuid、data_store_uuid、key_store_uuid）
    10. External_uuidをクライアントに返します
  • Cryptor.load（external_uuid）
    1. MapStore.load（external_uuid）-> [data_store_uuid、key_store_uuid]
    2. KeyStore.load（key_store_uuid）-> [key、iv]
    3. DataStore.load（data_store_uuid）-> [encrypted_data、auth_tag]
    4. データを復号化してクライアントに返します

私がすでに疑問に思っている主な質問：

  1. データを暗号化して保存するためのより良い/より一般的な/信頼できる方法はありますか？できるだけ速くする必要があります。最大50MBのblobが機能すると予想されます。
  2. ivキーストアサブシステムまたはデータストアサブシステムに保存する必要があります。これら2つのアプローチに違いはありますか？ NISTによると ここ （16ページ）ivはメッセージの一部です。 「メッセージ」という用語は、キーストアではなく、データストア内に格納されている情報に最も近いと思います。
  3. このスキームでAADとしてexternal_uuidを使用しても安全ですか？または、その目的のために別のランダムなuuidをMapVaultに追加する必要があります
  4. keyStoreのキーをクライアントの公開キーまたはマスターキーで暗号化する必要がありますか？このアプローチはOracleTDEスキームで使用されているようです。クライアントの公開鍵で暗号化すると、3つのサブシステムがすべて盗まれたとしても、データを復元できなくなると思います。
encryptionaesstoragehipaaarchitecture
2
Antiarchitect

実際には、既存の製品を使用するのが最善です。独自の暗号ストレージシステムをローリングすることには多くのリスクがあります。セキュリティやデータの整合性にエラーを起こす方法はたくさんありますが、面白くありません。私の頭から離れた商用製品の1つは、SafenetのStorageSecureです。彼らはこのようなものを専門としています。自作に固執している場合は、利用できる学術プロジェクトやオープンソースプロジェクトもかなりあります。

ファブリックプロジェクト
http://www.cs.cornell.edu/Projects/fabric/
安全なプログラミング言語、分散アーキテクチャ、計算の保護、およびデータの保護を備えています。無料のIIRC。

タホ-LAFS
https://tahoe-lafs.org/trac/tahoe-lafs
分散型のフォールトトレラントな暗号化されたストレージアーキテクチャ。これにより、クライアントは、ストレージノードが危険にさらされている場合でもデータのセキュリティを保証できます。自由。

ストレージ内のデータの保護：現在の調査のレビュー
http://arxiv.org/pdf/cs/0409034.pdf
一連のスキームと保護の比較。

グリッド上の医療データの暗号化されたストレージ
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.163.9593&rep=rep1&type=pdf
あなたの路地を右に曲がってくださいね？

ご存知のとおり、さまざまなフルシステム、ファイルシステム、およびファイルレベルの暗号化ツールは省略しています。ただし、アプリレベルのデータ暗号化に対する貧弱な解決策は、各アプリや分類カテゴリに暗号化されたボリュームをeCryptfsまたはTruecryptで提供することです。次に、アクセス許可、強制アクセス制御などを使用して、そのパーティションに制限します。ツールの使用方法とファイルの読み取り/書き込み方法を知っている場合は、ストレージが暗号化されています。また、それぞれが十分に戦闘テストされているため、確実に機能することもわかっています。

1
Nick P