2

自分のアプリケーション用に考え出したセキュリティ モデルについて、ベスト プラクティスのフィードバックをいただければ幸いです。Amazon の RDS を使用して、Microsoft Access フロントエンド/バックエンドを .NET WinForms/SQL Server にアップグレードすることに真っ先に飛び込みます。アプリケーションはマルチ ユーザー、マルチ サイト (異なるドメイン) であり、機密性の高い健康情報が含まれます。

これは 2 週間の調査の要約です。

  1. 混合認証と SSL を使用してアプリケーションに保存された暗号化された接続文字列。理想的ではありませんが、接続文字列が盗まれても大丈夫な方法を見つけたと思います (以下の #5 を参照)。

  2. SQL Server は、選択した IP アドレスからの接続のみを受け入れます (すべて静的になります)。

  3. 実行権限のみを持つ 1 人の SQL Server ユーザーに割り当てられたアプリケーション接続文字列。すべての DB 対話は、プロシージャーを使用して行われます。アプリケーション ユーザーを特定のプロシージャに制限するために使用されるスキーマ アクセス許可。

  4. SHA 256 ソルト化およびハッシュ化されたパスワードを含むユーザー テーブル。これにより、アプリケーション セキュリティの最初のレイヤーが提供されます。

  5. これは私が確信していない部分です: すべての手順は、exec 変数の 1 つとして送信されたユーザー名とパスワードを検索する IF ステートメント = True の場合にのみ完全に実行されます。UN/PW は、アプリケーションのセッションごとに一時的に保存されます。私の理論的根拠は、これにより、許可されたIPアドレスから何らかの形でログインしている接続文字列を持つユーザーが、有効なパスワードなしでデータを取得/変更できないようにすることです。

  6. AES_256 対称キーで暗号化された機密性の高い列は、データベース マスター キーを使用する証明書によって暗号化されます。アプリケーション ユーザーには、対称鍵と証明書を使用する権限があります。

  7. ユーザーのパスワードは、規則 (長さ、大文字と小文字の組み合わせ、特殊文字) に従う必要があります。

誰かがこれに穴を見たり、良い代替品を持っていますか? #5 は、Windows 認証を使用できない Windows アプリケーションに固有の接続文字列のセキュリティ ホールを解決しますか?

4

1 に答える 1

2

組み込み機能を信頼していないという理由だけで、あなたの設計は、組み込み機能 (認証、承認、許可制御) を自作の試みで複製しようとしているように思えます。

認証/承認に SQL ユーザー/パスワードを使用します。ユーザーとハッシュのテーブルを作成しないでください。各実行要求でユーザーとパスワードを送信しないでください (!)。

アクセス制御には SQL Server 権限を使用します。実行をきめ細かく制御するには、コード署名を使用します (署名付きプロシージャ)。並行して複製されたアクセス制御インフラストラクチャを構築しようとしないでください。セッションごとに一時的なユーザー/パスワードを保存しないでください。

AWS ファイアウォール インフラストラクチャを使用して、アクセス IP を制御します。自分自身を再発明しないでください。

列レベルの暗号化を使用する場合は、保護対象と目的を理解してください。偶発的なメディアの損失？次に、データベース マスター キー (つまり、貧弱な男性の TDE) で暗号化します。データの機密性? 次に、各セッションでユーザーに証明書の復号化パスワードを入力してもらいます。

固有の接続文字列のセキュリティ ホールを解決する

アプリケーションの起動時にユーザーにパスワードを入力してもらい、保管中のファイル (.config) にパスワードが公開されないようにします。それだけです。SQL Server はずっと前に、SQL auth のネットワーク上でのパスワードの交換を停止しました。

于 2012-12-04T18:36:53.350 に答える