Q&A
サービス起動時に入力されたパスワードは、その後どのように保持するのがよいでしょうか?
こんにちは。
情報系の大学生です。
大学の教育の一環でアプリを開発しているのですが、
セキュリティに関して疑問が生じたので質問させていただきます。
例えば、ブログをWebアプリで開発しており、
データベース（MySQL）にアクセスしようとした場合、以下のように書いたとします。
Python
1import MySQLdb 2 3hostname = 'localhost' 4dbname = 'db_name' 5username = 'root' 6password = 'hogehoge' 7connector = MySQLdb.connect(host=hostname, db=dbname, user=username, passwd=password, charset='utf8')
この時、思ったのが
セキュリティ的にパスワードをこのようにベタ書きして大丈夫なんでしょうか？
企業では、そもそもrootを使わずユーザを作成していると思うんですが、
その場合、作成したmysqlユーザにはどのような権限を与え、
一方、rootユーザはどのような使い方をしているんでしょうか？
分かりづらい質問で申し訳ありませんが、
ご回答よろしくお願いいたします。
回答6件
0
ベストアンサー
一般的なセキュアコーディングのガイドラインでは、パスワードをハードコーディングすることを禁じています。例えば、以下は SEI CERT Oracle Coding Standard for Javaからの引用で、世界的に権威ある団体の文書の翻訳です。
パスワードやIPアドレス、暗号化鍵等センシティブな情報をハードコードすると、それらの情報を攻撃者に晒してしまう可能性がある。クラスファイルにアクセスできる者であれば誰でも、クラスファイルを逆コンパイルし、センシティブな情報を取り出すことができる。したがって、プログラムにセンシティブな情報をハードコードしてはならない。
【中略】
違反コード (ハードコードされたデータベースのパスワード)
以下の違反コード例では、SQL接続要求にユーザ名とパスワードフィールドがハードコードされている。
【中略】
適合コード
以下の適合コードでは、セキュアなディレクトリに保存された設定ファイルからユーザ名とパスワードを読み取っている。
ということで、まさにご懸念の内容が書いてありますね。
しかし、私はこの「適合コード」に疑問を持っています。そもそも「セキュアなディレクトリ」ってなによ、具体的にどうするということが書いていないのです。
というのは、設定ファイルに書かれたパスワードをアプリケーションを読み取らなければなりません。しかし、仮にハードコートされたパスワードが読まれるような状況…ディレクトリトラバーサルやOSコマンドインジェクション等の攻撃を受けている状況では、攻撃者は、アプリケーションが読み取れるファイルは全て読めるので、結局「セキュアなディレクトリ」に保存されたパスワードを読むことができます。
ファイル名やディレクトリを隠せば…となりそうですが、駄目です。ハードコートされたパスワードが読まれる状況では、設定ファイルを読み込むロジックも漏洩するので、どこにパスワードが置かれているかはすぐに分かります。
そもそも、データベースのパスワードがばれたところで、それだけでは攻撃はできません。通常データベースのポートはインターネットに公開されていないので、データベースのパスワードを悪用するためには、サーバーに侵入してコマンドを実行する必要があります。すなわち、ディレクトリトラバーサルではパスワードまでは分かりますが実際にはデータベースにアクセスできず、OSコマンドインジェクション相当の攻撃ができないと、パスワードを悪用できないのです。
これ自体が非常に「やばい」状況です。この状態では、別ファイルのパスワードを読み取られるでしょうし、その後のデータベース接続もできます。その他、迷惑メールを送信したり、他のサーバーへの攻撃もできます。この状況で、パスワードを別ファイルに記述しても、リスクはあまり軽減されません。
ちょっとマシな方法として、パスワードの「難読化」という方法があります。パスワードを平文でおかないで、暗号化等の複雑な処理を入れるのです。ただし、攻撃者はソースコードを閲覧できるので、これも時間かせぎにしかならず、絶対ということではありません。単に暗号化する程度では全然駄目で、わざとロジックを複雑にしたり、C言語等のリバースエンジニアリングしにくい言語を混ぜたりします。そこまでしても、絶対ということにはなりません。なので「難読化」であって、解読を難しくできるだけなのです。
このように、データベースのパスワードをハードコーディングしないと決めたとしても、ハードコーディングよりも十分安全な状態にするのは難しいのです。
そういう事情もあってだと思いますが、著名なオープンソースソフトウェアの場合、多くがデータベースパスワードをハードコーディングしています。たとえば、WordPressの場合は、wp-config.phpにパスワードが平文で書かれています。Movable Type等も同様です。
シンプルで安全な方法がもしあれば、その方法が普及してもよさそうなものですが、おそらくそのような方法は見つかっておらず、現状は上記の通りです。
※ なので、私は引用したドキュメントについては、かなり不満を抱いています。権威ある文書だからといって、鵜呑みにしてはいけない例でしょう。
以上は外部からの攻撃を想定して書いたものであり、SEI CERTの文書も外部からの攻撃を想定して書かれているようですが、サーバーにログインする権限を持つエンジニアによる悪用というシナリオを想定すると、意味がなくはないですね。
つまり、サーバー管理者はサーバーに自分のアカウントでログインはできるが、アプリケーションが用いるデータベースアカウントは、その管理者が閲覧できないディレクトリに書いてあるという想定です。
しかし、これが意味をもつためには、たとえばサーバー管理者は root 権限では作業しないとか、データベースのアカウントは作業者毎に分けてある（本来そうすべきだがあまりできていない）等の運用管理ができて初めて意味を持つことになります。
投稿2017/07/26 14:18
編集2017/07/26 14:51総合スコア11701
0
セキュリティ的にパスワードをこのようにベタ書きして大丈夫なんでしょうか？
これは、観点によってYesにもNoにもなります。
まず、「パスワードを機械可読にすること」ですが、そうしないとDBにアクセスできませんので、そうせざるを得ません。
一方で、「パスワードをソースコードに直書きする」ことは、gitに混入すると除去が厄介なことになってしまいますし、うっかり公開してしまうリスクもあるので、あまり推奨はされません。「gitに入らない、設定専用のファイル」あるいは「環境変数」で設定するのが定石となっています。
投稿2017/07/26 07:48
総合スコア145183
0
権限の分離、難読化、別クラス化やパスワードの分散(16文字迄をAファイル、17～32文字迄をBファイルにし別箇所で結合など)など色々と見てきましたが、
実際のところはこれに対する有効な答えは今のところ無いと思われます。
パスワードを見ることができる = 既に中に侵入されている
という見方が成り立つことが多く、難読化していても複合のプロセスを記載した場所を見ればわかることもあります。
平文で大丈夫か？
ということに関しては大丈夫ではないが、解読を難しくすることで解読を手間取らせることができます。
また権限を分けて、読み込めるだけの権限を持つユーザー、書き込みができる権限を持つユーザー、削除ができるユーザーやに分けることで被害を減らしたり
データベースそのものに閲覧の権限を持たせたりすることで、全容を掴みにくくするといった手法の方が効果があると思います。
（Aテーブルは閲覧できるが、Bテーブルは別のユーザーでないと見れないなど）
また、サーバーへアクセス出来る端末を制限したりする(rootログイン出来る端末を制限するなど)ことでセキュリティーを高めたりすることも多いため、私個人としては
平文保存では危ないため難読化は行うが、難読化では不完全なため、それ以外の部分で補完することでセキュリティーを確保する
というのが良いと思っています。
投稿2017/07/28 01:06
総合スコア161
0
問題がないかあるかで言うと問題があるという認識の人が多いと思いますが、
そもそもそのパスワードを見られるケースってどんなケースでしょうか。
webサーバにsshでログインして、対象のソースを見れるってことなので、
そこまで懸念する必要はないと思います。
（もちろんgithubでソースを公開するなんてことは考慮に入ってません。）
例えばwebサーバの実行プロセスの環境変数にパスワードを設定して、
アプリは環境変数からパスワードを取得すれば、ベタ書きは防げます。
root権限のユーザはDBの作成やユーザの作成など全ての権限。
（webアプリのリリースとかでしょうか。）
webアプリから繋ぐユーザは、select,update,insert(,delete)権限じゃないでしょうか。
運用で使うユーザは、create tableとかtruncateとか出来てもいいかと思います。
投稿2017/07/26 07:52
総合スコア1400
0
セキュリティ的にパスワードをこのようにベタ書きして大丈夫なんでしょうか？
セキュリティだけを考えるのであればリスクがあります。また、回避策もあります。
サービス起動時にパスワードを管理者が手入力するロジックに変更します。これでサーバ上からパスワードを読み取られるリスクはほぼなくなります。ただしデメリットは大きく、サービス再起動時にパスワードを入力する人間が必要になるため、全自動サービス復旧ができません。一般のブログなどでこのデメリットを許容することはまず考えられませんが、銀行のインターネットバンキングならありうるかもしれません。
他の方も指摘されていますが、このパスワードが漏れただけですぐに外部から攻撃可能となるわけではありません。内部の人間にもパスワードを知られたくない理由があるかどうかで対応が必要となります。
投稿2017/07/27 02:33
総合スコア372
0
ソース側は
password = 'changeit'
などとし、リポジトリから流出しないようにします。
デプロイ時の設定でこれを変更し、実際に接続可能なパスワードに変更します。
どこかしらにはパスワードを記載しなければならないので、環境変数に書いて参照しようが、他の仕組みでソースと分離しようが、大した差はないと考えています。
運用の観点からは出来る限りソースコード本体と、設定ファイルは分離してほしいとは思いますが、これでセキュリティ的な差が出るわけではありません。
投稿2017/07/28 01:16
総合スコア6621
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。