ナビゲータのEVEです。
昨日までは、Webサーバー側からDBに接続するための、ユーザーID、パスワード保存するためにどんなセキュリティがあるのか検討し、そのセキュリティの問題点について考えてきました。そして、パスワードをPHPから定期的に更新することについては、リスクの軽減になるが、同ユーザーIDとパスワードの保存方法について細心の注意が必要だと ChatGPT から指摘がありました。同4項目の指摘について、現在のPrototype EVEでの対応方法について考えてみました。?〜?までは見通しがたったのですが、?のユーザーIDとパスワードの ハードコーディング について問題が解決できていないので、引き続き検討していきます。
?権限の過剰な付与:
?SQLインジェクションのリスク
?暗号化されていない通信
?ハードコーディングの問題:
[ユーザID、パスワードのハードコーディングの検討]
では、ChatGPTはどのような保管方法が高いセキュリティで保護されるといっているのでしょうか？
セキュアな設定ファイルは、機密情報（データベースのユーザー名、パスワード、APIキーなど）を保持し、アプリケーションがそれらの情報を安全に利用できるように設計されたファイルです。以下は、一般的なアプローチとファイルの形式のいくつかの例です。ただし、重要なことは、どのようにそれを利用し、保管するかです。
?@INIファイル
INI形式のファイルは、設定情報をキーと値のペアとして保存するのに適しています。例えば、config.iniというファイルを作成し、そこにデータベース接続情報を保存することができます。
JSON形式のファイルもキーと値のペアを使用して構成でき、設定情報を格納するのに適しています。
?B環境変数
環境変数を使用して機密情報を設定する方法もあります。これは特にクラウド環境などで一般的です。
?CPHPファイル
PHPファイルに設定情報を含めることも可能です。ただし、この場合はファイルが外部から直接アクセスされないようにするなどのセキュリティ対策が必要です。
では、重要だといっていることについてChatGPTに再質問をしてみました。
1)ファイルのアクセス権限
設定ファイルには機密情報が含まれる可能性があるため、適切なファイルアクセス権限を設定する必要があります。これにより、不正なユーザーやプロセスからのアクセスを制限できます。
2)機密情報の暗号化
パスワードなどの機密情報は、可能な限り暗号化された形で保存されるべきです。ファイルそのものは平文であるため、機密情報を保護するためには別途暗号化の手段を検討する必要があります。
3)ファイルの場所
セキュリティの観点からは、設定ファイルは外部から直接アクセスされないように配置されるべきです。また、Webサーバーなどが公開するディレクトリ内には配置しないようにしましょう。
4)サーバーのログに記録されないように
設定ファイルには機密情報が含まれるため、サーバーのログに出力されることがないようにすることが重要です。
安全な設定管理は、設定ファイルだけでなく、それを扱うアクセス権、暗号化、およびアプリケーションの実装にも依存します。
最初の解答は、セキュリティのことは一切考えておらず、DBサーバーへのアクセスするためのユーザーIDとパスワードを格納しやすいファイルとして紹介してくれたようです。この場合、?@?Aは、DBサーバーへのアクセスするためのユーザーIDとパスワードを保管する方法としては不適切だと思ったのですが、「3)ファイルの場所」を見てはっとしました。当該ファイルを Apache のルートフォルダに設定する必要はないのです。もしかしたら、etcでもいいかもしれません。それを考えたら、別に PHP ファイルで保管する必要はないようです。
なんで、こんなこと今まで気づかなかったのでしょうか？これが、1人で開発する場合の限界です。ただ、今は、ChatGPTがいます。何かあればChatGPTに相談し、問題点を洗いだし、その問題を解決しています。
[あとがき]
今日も時間となってしまったので、この辺までとさせていただきます。
このような検討をしていると、いろいろな部分に配慮しないといけないことが分かります。
「4)サーバーのログに記録されないように」とありますが、これについて、Microsoft社がやってしまったことがありました。それは、システム障害が発生したとき、公開鍵暗号方式の秘密鍵をログに書き込んでしまったのです。そして運悪く、そのログを中国人ハッカーに見られてしまったということがありました。そのあとは、ハッキングのし放題です。多分ですが、機密情報を窃取されたのでしょう？
現在は、セキュリティは、必要不可欠なもので、リリースする前には、セキュリティチェックは必須です。ただ、Microsoft社のような大企業になると、システムも巨大で、かつ、それの全てを監査するのは難しいと思われます。結局は、問題が発覚してからの対処になるのでしょうか？どうしたら、いいのか引き続き考えていきたいと思います。
では、また！
【このカテゴリーの最新記事】
