Q&A
なんか、利用形態に前提があるっぽいのですが、ちゃんと書かないと伝わりません。
DB接続文字列を暗号化してファイルに保存して利用しようと考えているのですがどんな感じにすればよいでしょうか。
プログラムはWindows端末からDBを参照・更新する.Net Frameworkのプログラムです。
ツールの画面に設定ボタンでもつけて、そこから接続文字列を設定できるようにして、それで暗号化して保存がシンプルですが、実際のツール使用者に接続文字列を上書きされて接続できなくなってしまうなど考えると、嫌だなぁと思った次第です。
こういうことを勉強できる参考書やサイトなどあれば教えて頂けると幸いです。
知恵袋では、期限がある為やり取りが十分に出来なかったのでこちらで質問させていただこうと考えました。
すでに回答が付いているのですが、やり取りの途中だと考えています。
デコンパイルして云々という話が出てますが、プログラムの前提条件の認識が違うためか
私の認識では違和感があります。
暗号化の仕方で考えているのは
ProtectedData.Protect(Byte[], Byte[], DataProtectionScope) メソッド
です。
これでスコープを、CurrentUserにしようと考えています。
こうすることで、windows認証でログインしたユーザーのみが暗号を複合化できる事になる為
windows認証するだけよりもセキュリティー的には強固になると考えています。
まぁ。こういう暗号化ではなくても、テキストベースよりは良いと思うのですが
この暗号化はした方がいいのではないでしょうか。
＞なんか、利用形態に前提があるっぽいのですが、ちゃんと書かないと伝わりません。
プログラムの利用者は、ウィンドウズにログインしてプログラムを起動し、ファイルを指定してボタンを押すとファイルのデータをDBに取り込むだけのプログラムです。
＞その Windows 端末はどこで誰が使うものですか？
システム構築者（SEとか）、システム管理者（ユーザ企業の管理者）、一般ユーザ（ユーザ企業の一般ユーザ）という立場があるとすれば
システム管理者（ユーザ企業の管理者）がDBのデータ更新を行うための外部ツールになります。
DBに接続できる端末にリモートデスクトップか、直接ログインして使うことを想定しています。
その Windows 端末はどこで誰が使うものですか？ いろんな人がいろんな場所から使うなら、DB に直接アクセスさせるのではなく、アプリケーションサーバーを立てた方が良いかも。
管理者しか使用しないのだったら、実行時にユーザー・パスワードの接続情報を入力させればいいのではないですか？
そうすれば接続文字列を保存する必要もないですし、貴方が気にしている部分は無視できるのではないですか？
ユーザー ⇔ Web API ⇔ DB サーバー
という構成にはできないのですか？
DB サーバーは何ですか？ SQL Server? MySQL? Oracle? その他？
・・・と書いてよく見たら SQL Server のタグがついてましたね。失礼しました。
毎回パスワードの入力は、しなくて良いように。という要件だった気がしますが再度確認してみます
システム本体は、ユーザー ⇔ Web API ⇔ DB サーバーの構成だと思います。
小さい外部ツールでも、その構成にすべきなのでしょうか。
そもそもユーザーが DB サーバーに直接アクセスできるという環境を見直すべきだと思いますので、
ユーザー ⇔ Web API ⇔ DB サーバー
という構成をお勧めしました。
回答1件
0
こうすることで、windows認証でログインしたユーザーのみが暗号を複合化できる事になる為
windows認証するだけよりもセキュリティー的には強固になると考えています。
なるほど、そのファイルから接続情報を得るには、Windows アカウントを乗っ取って、複合化しなきゃいけないわけですね。
たしかにファイルのセキュリティは高いです。
ですが、肝心の DB はユーザID/パスワードで保護されているにすぎません。
まぁ。こういう暗号化ではなくても、テキストベースよりは良いと思うのですが
この暗号化はした方がいいのではないでしょうか。
暗号化するのは賛成です。
でも過信は禁物です。
投稿2022/07/10 22:34
総合スコア2730
そうですね。パスワードが漏洩したらどうにもならないですが、少なくとも自分の担当範囲からパスワードは漏洩して欲しく無いなぁというか、出来ることはやってますよ。と言える状態にはしたいと考えています
あなたの回答
tips
プレビュー
