キーを保存せずに機密の暗号化されたデータを提供するにはどうすればよいですか？キーにユーザー定義のパスワードを使用する必要がありますか？
システムの背景
機密データを保存する必要があります（つまり、クレジットカード番号またはSSN）。
誰でも機密データを挿入できます。 特定のユーザーのみが取得を許可されています。
アプリケーションおよび補助サービスを保護する際に講じた予防措置。 （つまり、HTTPS接続、定期的なセキュリティ更新プログラムのインストール、研究/セキュリティで保護された認証/セッション管理、バックエンドSSH、XSS、SQLiなどに対するアプリケーション全体のセキュリティ保護など）
機密データにアクセスすることを許可されているが、サーバー側から強制することができない場合があるエンドユーザーのPCとネットワークでの安全なプラクティスの奨励。
アプリケーションはゼロから設計です。 （遡及的セキュリティアップグレードではありません）
暗号化されたデータは常に安全であるとは限らない
セキュリティの専門家なら誰でも、製造中であっても、マシン上の機密データ（SSNまたはクレジットカード番号など）を暗号化するように言われると思います。 、データが漏洩したり、サーバーがハッキングされたり、アプリケーションが悪用されたりする可能性があります。
私が目にする問題はwith encryptionです。つまり、-サーバーはキーへのアクセスも持っている必要がありますです。これはSQLデータベースの外に保存できます。また、これは通常の電子アーカイブの代わりに紙にバックアップすることができます。 SQLインジェクションやバックアップの盗難以外にも多くの攻撃が考えられます。その場合、キーも盗まれ、暗号化が無効になります。
私はソリューションのキー管理 少し前 を想定していましたが、今日だけ質問としてこれを投稿していますプロのフィードバックを要求する。
解決策、フィードバックを要求する。
ユーザーアカウントがAuthorizedで機密データにアクセス/エクスポートする場合：
非常に強力なチェックにより、パスワードのリセットが必要です。
serに対して非対称（RSA）鍵ペアが生成されます。公開鍵は平文で保存されます。
秘密serキーは、ユーザーの（強力な）パスワードから導出された対称暗号化を使用して暗号化されます。
→このユーザーのプライベートユーザーキーにアクセスするには、ユーザーのパスワードを推測する必要があります。
いつものように、パスワードはBCryptで保存され、キーの派生とはまったく別のものです。
機密データは、権限の低いユーザーから送信されます。
Dataに対して非対称鍵ペアが生成されます。公開Dataキーは平文で保存されます。
プライベートデータキーは、すべての許可ユーザーのパブリックユーザーキーを使用して暗号化されます。
機密データはData keyを使用して暗号化されます。
→機密データにアクセスするには、プライベートデータキーを決定する必要があります。これは直接保存されませんが、許可ユーザーのパスワードを推測するとアクセスできます。
同じデータキーが最大90日間再利用されます。
データが関連付けられていない場合、古いキーは削除されます。
承認されたユーザーがサインインしたとき。
サインインは、BCryptを使用して確認されます。
セッショントークンは、少なくとも72ビットのエントロピーで生成され、ブラウザに渡されます。
プライベートユーザーキーは一時的に復号化され（パスワードから導出された対称キーを使用）、現在のセッションで再暗号化されます。 （セッショントークンから派生した対称キーを使用）
→機密データにアクセスするには、ユーザーのパスワードを推測するか、セッショントークンを盗みます。
サーバー側には、セッショントークンの単純なSHA-256ハッシュのみが格納されます。
サインイン中、承認されたユーザーのブラウザーは、ユーザーキーの復号化に使用されるセッショントークンを渡し、適切なデータキーの復号化に使用されます。その後、適切な場所に機密データを提供できます。
したがって、サーバーまたはデータベースが侵害されたとすると、攻撃者は機密データにアクセスするために次のことを行う必要があります。
- Authorized個人の小さなプールの中で弱いパスワードの1つを推測する、または
- Authorizedの個人が現在使用しているマシンからセッションキーを盗みます
- または、運用ソフトウェアを編集して、プレーンテキストでのデータの保存を開始します（侵入が読み取りと書き込みのアクセスを提供する場合にのみ可能）
私にとっては、これが可能な限り最も堅牢な安全な実装です。
A）これはお勧めですか？
B）これはメインストリームのライブラリまたはアプリケーションに実装されていますか、それともかなりユニークなアイデアですか？
攻撃対象領域を減らすためにより多くのサーバーを使用できる場合の大きなアーキテクチャーに関する一般的な考慮事項を以下に示します。上記のシナリオで、単一のサーバーが侵害された場合、管理者ユーザーがログインしていると、長期間にわたって機密データが漏洩する可能性があります。
- 2つのWebサーバーが存在する可能性があります-1つはクライアント用、もう1つは管理者用
- 別のサーバーにデータベースがある可能性があります
クライアントサーバーはデータベースサーバーに機密情報を挿入しますが、何も読み取ることができません。
現在、機密情報を取得する権限は、データベースレベルで管理者のみが持っています。
上記は、多くの方法で実現できます。たとえば、-データベースはデータ自体を暗号化し、その組み込みルーチンに基づいて複数のバージョンを保存します。 SQL Server、ただし、これにはSQL Server自体でのビットコーディングが必要です。これにより、各管理者がSQL Serverへの独自の資格情報を使用している場合の監査が改善されるため、管理者のWebサーバーが侵害された場合でも、sysadminはどの機密レコードが表示されたかを確認できます。
クライアントのWebサーバーは、公開鍵を使用してデータを暗号化し、SQL Serverに挿入します。管理Webサーバーには秘密鍵がありますが、管理者の1人が不正にアクセスして管理Webサーバーをハッキングした場合、1つの管理者がすべての機密データを読み取る可能性があります。データベースユーザーと復号化キー
クライアントのWebサーバーが危険にさらされた場合、すべての情報を取得するためにSQL Serverに追加の攻撃が仕掛けられる可能性があります。このため、追加の中間コピーが使用される場合があります。機密データは暗号化され、APIを介してクライアントサーバーに保存および公開されます。その後、管理サーバーはクライアントマシンのAPIに接続し、SQL Serverにデータを保存します。これにより、クライアントサーバーからSQL Serverへのアクセスが削除されます。
リソースが制限されている場合、クライアントと管理Webサーバーは同じ物理サーバー上で実行できます。または、異なるコンテナのクラウド内で実行できます。
クライアントのWebサーバーが危険にさらされた場合、悪意のあるソフトウェアをインストールすることにより、すべての機密データを読み取ることができるため、ブラウザに組み込まれているPKIまたはJavaScriptを使用して、クライアントで情報が暗号化されるようにすることをお勧めします。側で、公開鍵を使用してすでに暗号化されているサーバーに送信されます。ただし、クライアントサーバーが侵害された場合、公開キーが置き換えられるか、Webサイト全体が置き換えられる可能性があります。これにより、クライアントブラウザーがアプリケーションと公開キーの信頼性をどのように検証できるかという別の疑問が生じます。これは、たとえばクライアント側のアプリケーションを求めています。ウェブサイトを読み込みます。組み込みブラウザー（ブラウザーコンポーネントが組み込まれた、プレインストールされたexeファイルのようなもの）を作成し、そのアプリケーションの整合性を確認します。私はしばらくそのようなアプリをやっていますが、ここにそれを行う正当な理由があります:-) Webブラウザーがそれをサポートしているかどうかはわかりませんが、組み込みのブラウザーで実行可能なアプリを実行していますクロスプラットフォームの動的ユーザーインターフェイスを実行する。
ここに役立つかもしれないものがあります。 サブリソースの整合性
とにかく、クライアントサーバー自体のWebサイト、ソフトウェア、およびキーで継続的なスキャンを実行することにより、NagiosまたはRundeckでWebサイトの整合性を単に監視するだけで実装できます。もう1つは、キーが置き換えられると、管理者がデータを復号化できないため、システム全体が機能しなくなることです。
特定のWebサイトがドメインに署名され、その署名がサードパーティに対してチェックされると、すばらしいでしょう。たぶんブラウザ拡張はこれを行うのに良いものでしょう。したがって、Google.comをロードすると、HTMLとJavaScriptはサードパーティによって署名されるため、置き換えられた場合、ブラウザは実行しません。
これは少し話題から外れていますが、ユーザーが送信した機密データを基本的に処理する方法について、いくつかのアイデアを得る可能性があります。