ナビゲータのEVEです。
昨日も寝苦しく現在睡眠不足です。気温も下がり寝やすいはずなんですが・・・。ただ、今日はプログラム修正をしました。ただ、途中で手が止まった・・・。それは、 データベース関連クラス ・・・。
[データベース関連クラス]
データベース関連クラスは、以前このブログで紹介したクラスです。そのときから多少変えましたが、大きく変更はしていません。ただ、そのロジックを見て、ちょっと悩みました。それは、データベースに接続するユーザーIDとパスワードの扱いです。
[情報処理安全確保支援士2次試験]
情報処理安全確保支援士 2次試験で度々出題されるのですが、リモートで保守するシステムへログインするときの、ユーザーID、パスワードの扱いです。普通に作ると、ログインするためのユーザーID、パスワードの情報は、リモート保守対象のハードウェアの何処かに保存することになるのですが、それを ハッキング されることがあります。その場合、リモート保守対象のシステムは、 ハッカー の思うがままです。そうならないために、いろいろな手段を講じるのですが、 Prototype EVE では何もしていませんでした。これから本番機を製造するにおいてどうしようかなって、プログラムの修正の手が止まってしまいました。
[システムから自動で変更する]
そのとき考えたのが、 公開鍵暗号 で利用される ハイブリッド方式 です。公開鍵そのモノは、パスワードを保護するために利用し、パスワードそのものは 共通鍵
この方式を、WebサーバーとDBサーバーとの通信に当てはめると、Webサーバーに保存したパスワードはテキストファイルに保存されていますが、暗号化されている状態です。そのパスワードを利用して、WebサーバーからDBサーバーへ接続する場合、暗号化されたパスワードを復号しDBへ接続します。
ここでの問題は、Webサーバーに暗号化されたパスワードの復号方法です。あるシステムでは、 Base64 でやっていますが、これBase64の関数があれば、すぐに復号できてしまいます。
そこで、思い出したのが、Prototype EVEで利用している、クライアントとWebサーバー間のパスワードの暗号方式・・・。
この方式は、クライアント側がログイン時、画面にパスワードを入力しますが、そのパスワードはあらかじめクライアントに渡した暗号化情報に基づき暗号化し、その暗号化したものをサーバーへアップロードします。アップロードしたパスワードは、Webサーバーでは、暗号化情報対となる復号情報により復号しログインすると言う方式です。ただ、この方式の場合、データベースに格納された、数万件の暗号化情報に基づき、無作為に選択され、その情報に基づきパスワードを暗号化するから意味があります。予め、テキストファイルにエクスポートするという方法がありますが、それを、公開鍵暗号化ハイブリット方式と同様に短時間で行うとなれば、この部分だけに、かなりのリソースを割かなければならなくなると思われます。
[システムで変更する]
パスワードをシステムから定期的に変更するというのもよく考えるとあまりよくありません。それは、サーバー上にプログラムを配置すれば、ハッカーもDBへアクセスできると言うことを意味しています。今現在Prototype EVEにおいて、 システムコマンド を利用する場合、メールが届くようにしていますが、これを短期間で行うと、受け取る側としては、ハッキングと言った問題が発生した場合、気づかない可能性があります。
そこで、また、 ChatGPT に聞いてみました。そうしたら、 MySQL で利用しているユーザーが root 権限を持っている場合、システムコマンドを利用しなくても、DBのパスワードは ALTER コマンドで容易に変更できるようです。rootユーザーを標準で使用するかどうかという問題はありますが、まっ、標準で利用できるモノは仕方がありません。これは、別の対応策を考えるとして、何となくいけそうだという印象を持つことができました。
[あとがき]
まだ、問題はありますが、今日で方向性が決まった気がします。しかし、まだ考えが足りていない部分もありそうなので、いきなり作りこむのではなく、ある程度作り終えてから、追加ロジックとして作りこんでいきたいと思います。これにより、Web、DB間の通信のセキュリティは確保できそうです。
ちょっと、考えるばかりで修正が全くできない一日でした。
では、また！！！
