確認環境のセキュリティ対策について

Question

Webアプリケーションを作っています。
本番環境と確認環境を運用する際、確認環境を守る対策として下記の２つは思いつきます。

• Basic認証
• IP制限

他に取れる対策、取るべきな対策は何があるでしょうか？

確認環境について

• webサーバーは、nginxを使っています。
• ドメインは、サブドメインを使っています。
  取り急ぎ用意したため、今思うと不用心かと思っています。

Answer 1

セキュリティは何か要件があってそれを守るために実装するものなので、
まずは

• 確認環境に求められるセキュリティ要件とは何か？(何をどういう条件で守らないといけないか)

を明確にする必要があります。
（極端な話、「Basic認証のID/PWが漏れたら諦める」という要件なら、IP制限すら必要なくって、HTTPS＋Basic認証だけでも十分です）

要件が決まっていない場合、適当に考えても

• https化はしておかないと通信経路でbasic認証が盗聴される可能性がある
• サブドメインは類推出来ない複雑なものにした方が良いのでは？
• 現在設定されているBasic認証のID/PWは十分に安全な長さと複雑度をもっているのか？
• そのIPからアクセスできる人のうち、Basic認証が漏れた場合に対応出来ないのはどうしよう？

- basic認証よりDigest認証の方が原理的には安全なのでは？

• クライアント証明書で認証した方が良くない？
• ポートは変えておいた方がいいのでは？
• そもそも確認するとき以外はサーバを落としておいた方が安全
• 認証情報は一定期間ごとに変更した方が良いのでは？
• 不正っぽいアクセスがあったらアラートを出した方が・・・
• 不正っぽいアクセスがあったらそのIPを一時的に遮断した方が・・・

等々、設定する必要のあるであろうものから運用や利便性を考えたら難しいものまで色々思いつきますが、どれが適切であるかはまずは要件が決まらないと決められるものではありませんし、漏れがあっても検出することが出来ません。

Comments

[hasshy]

ご回答いただきありがとうございます。
曖昧な質問でしたのに、詳細に利用ケースを考えていただきありがとうございます。

漫然と対策をしていたため選択肢がほとんどない状態でしたが、とても勉強になりました。
必要な時以外はサーバーを落とすと言うのは盲点でした。

要件については練ってみようと思います。

[tanat]

そうですね。
最終的に今のIP制限＋Basic認証でOKとなったとしても、
要件が明確になっていれば、仮に不正アクセスがあったとしてもの対策の方向とコスト負担、責任の所在なんかは明確にすることが出来るので、漠然とした不安というのは無くなると思いますよ。

[ockeghem]

「basic認証よりDigest認証の方が原理的には安全なのでは？」というのはあたっていないと思います。HTTPSが前提であれば、Basic認証の方がまだマシ…という要素もあります。
その理由は、Digest認証の一般的な実装(Apache等)では、サーバー上の認証情報が保護されていないからです。

[tanat]

> ockeghemさん

ご指摘ありがとうございます。
HTTP前提だった場合の思い込みがありました。
Digest認証の実装について確認してみます。