第2章 アクセス制御対策
ユーザ認証対策
アクセス制御は、ユーザ認証とアクセス認可の 2段階で構成するのが一般的である。
- ユーザ認証
アクセスしてきた人物が本人であることを確かめる手続き - アクセス認可
認証されたユーザに、コンピュータのリソースへのアクセスを許可あるいは禁止する仕組み
Webアプリケーションのユーザ認証においては次のような点を考慮する(図4)。

常にユーザIDとパスワードを求める
ユーザ認証とは、認証の対象となるユーザが本人であることを確認する仕組みであり、ユーザ固有の識別子である「ユーザID」とユーザのみが知っていると仮定される「パスワード」を照合することにより判断が行われる。
ユーザの個人情報や秘密情報等へのアクセスは、許可されているユーザのみに限定する。
そのためにユーザの個人情報や秘密情報等を扱う場合には、必ずユーザ認証を行うべきである。
なお認証時のユーザIDとパスワードの照合処理をクライアント側で行ってしまうと、その処理の回避や改ざんのおそれがあるため、必ずサーバで行うことが重要である。
アカウントのロックアウト
ユーザ認証時に、一定時間内のログイン失敗回数が基準値を超えた場合には、そのアカウントを使用禁止にするべきである。
例えば、あるアカウントに対するログインが10回連続して失敗した場合に、そのアカウントのログインを数時間禁止する。
ロックアウトを行わずに無制限にログイン失敗を許容してしまうと、パスワードやユーザIDを総当りで検証する攻撃「ブルートフォースアタック」により、認証を突破されてしまうおそれがある。
このように、ログイン失敗時にアカウントの使用を禁止する仕組みを「ロックアウト」と呼び、ログインの失敗回数やロックアウト期間等を任意に設定することができる。
ログイン失敗回数やロックアウト期間は、利用上の利便性との兼ね合いにより設定する。
ロックアウトは、同じユーザIDや同じパスワードでのログイン試行に対して反応する方がよい。またロックアウトは、そのアカウントが実在することの証明にもなってしまうので「ロックアウトした」旨のエラーメッセージは表示すべきではない。
パスワードフィルタ
パスワードの発行・登録時には「パスワードフィルタ」を用い、文字数が少なかったり、文字種が単純すぎる安易なパスワードが使用されるのを防ぐべきである。パスワードフィルタとは、あらかじめ決めた規則(最低文字数、最低使用文字種等)に従ってパスワードの検証を行うものであり、安易なパスワード(ユーザIDと同じもの、生年月日、一般名詞等)を設定しようとした場合に、そのパスワードを拒否するものである。もしパスワードがユーザIDと同じであったり、一般名詞を使用している場合には、類推、辞書攻撃、総当り攻撃で容易にパスワードが盗まれてしまうおそれがあるからである。
パスワードフィルタの規則として、例を挙げる。
- ユーザIDが含まれるものは許可しない
- 生年月日が含まれるものは許可しない
- 8文字以上で英字と数字と記号がそれぞれ1文字以上含まれるものを許可する
- 前回と同じパスワードは許可しない
パスワードの有効期限
一定の期間が経過したパスワードは、その変更をユーザに強制するとともに、過去に使用したパスワードの再使用は禁止すべきである。パスワードは、その使用期間が長くなるにつれて、攻撃者にパスワードを盗まれる可能性も高くなっていくからである。
ただしパスワードの変更頻度が、あまりにも高い場合はユーザの混乱を招くこともあるので、例えば2〜3ヶ月毎に行うようにするとよい。またパスワードを変更する際には、現行パスワードで認証を行い、意図せずパスワードが変更されてしまう攻撃を防ぐようにすべきである。
また、変更があったことをユーザがあらかじめ登録している電子メールアドレス宛へ通知する等を行うことが望ましい。
管理者側は、いつどのユーザのパスワードの変更があったかをログ等に記録するべきである。
ランダム化桁とチェック桁
パスワードのみならず、ユーザIDも、ランダム桁やチェック桁を含ませる等を行い、推測が困難なものとすべきであり、シーケンシャルな数値を含むものや、他人に知られている可能性のあるもの(電子メールアドレス、口座番号、社員番号、会員番号等)を使用すべきではない。なぜならば、攻撃者にユーザIDが知られた場合、総当り攻撃でパスワードが盗まれるおそれがあり、またユーザIDをいくつか採取された場合に、それらを比較することで他のユーザIDの推測が可能となり、攻撃の対象が広がるおそれもあるからである。
ログインエラーメッセージ
ログイン場面に限ってはエラーメッセージの説明については、あいまいにし、具体的に何を間違えたのかをユーザに伝達すべきではない。例えば、数組のユーザIDとパスワードを用いて、ログインを試行した結果、以下のメッセージが表示されたとする。
1組目のエラーメッセージ:ユーザIDが正しくありません
2組目のエラーメッセージ:パスワードが正しくありません
3組目のエラーメッセージ:ユーザIDが正しくありません
これらのメッセージから、1組目と3組目のユーザIDは存在せず、2組目に入力したユーザIDは存在することが判明してしまう。
このように具体的な内容をエラーメッセージに含めることは、攻撃の手がかりを与えてしまうことになり避けるべきである。上記の場合は「ユーザIDまたはパスワードが正しくありません」とした方がよい。
パスワードリマインダの慎重な設置
パスワードリマインダとは、ユーザがパスワードを忘れた際の救済措置である。本人しか知らない秘密情報(合言葉)をユーザに登録してもらい、パスワード忘れの際には、その情報をユーザ認証の代用とすることで、パスワードを再発行する仕組みである。
パスワードリマインダは、認証の機会が増えることでセキュリティが弱くなるため、できればパスワードリマインダを設けない方がよい。もし設ける場合には、次のようにすることを推奨する。
- パスワードリマインダのリスクをユーザに説明するとともに、「合言葉」として本人しか知らないような情報を選ぶようユーザを指導する
- パスワードリマインダを使う・使わないをユーザが選べるようにする
- パスワードリマインダの「合言葉」をWebページ上に表示しない
- パスワードリマインダの「合言葉」を平文メールでユーザに通知しない
- 一定回数試行に失敗したらパスワードリマインダをロックする(ロックアウト機能)
パスワード再設定/再発行手順
パスワードリマインダの「合言葉」が一致したら、パスワード再設定に次の手順を踏むことを推奨する。なお、要求されるセキュリティレベルによっては手続きを簡略化してもよい。
- パスワードリマインダのWebページ上(https:)で1回限り有効なキー(短め)をユーザに発行する。
- 1回限り有効な別のキー(長め)を含むURL(https:)を、ユーザがあらかじめ登録している電子メールアドレス宛送信する。
- ユーザにそのURLのWebページにアクセスしてもらい、先ほどのキーを入力してもらう。
- キーが照合できたらパスワードの再設定あるいは再発行を行う。
- 一定回数以上照合に失敗したら2つのキーは無効にする(ロックアウト機能)。
管理者権限の制限
管理者が個人情報を漏洩したり、一般ユーザに成りすましたりする機会を与えないよう、以下のように考慮すべきである。
- パスワードファイルを暗号化する。
- データベースへのアクセスを制御する。
- ひとりの管理者が多くの情報へアクセスできないよう権限の分割を行う。
- 不正なアクセスがないか、管理者以外の人間が定期的に監査する。