Webサイトの管理画面は、記事の公開やページの編集など、サイトを運営するための大切な入口です。
一方で、ログイン画面はインターネット上からアクセスできることが多く、不正ログインの標的にもなります。
金風株式会社では、自社ブログの管理画面のログイン方法を見直し、Cloudflare Turnstile・パスワード・認証アプリによる二段階認証を組み合わせた対策を導入しました。さらに、CMS本体の更新、管理者アカウントの確認、秘密情報の管理、バックアップの見直しなども実施しています。
この記事では、実際に行った対策をもとに、管理画面が狙われる理由、Turnstileと二段階認証の役割、認証アプリの仕組み、導入時の注意点を図解とスクリーンショットを交えて解説します。
管理画面のURLが公開されている場合、第三者でもログイン画面にアクセスできます。攻撃者は、次のような方法でログインを試みます。
管理画面を乗っ取られると、記事を書き換えられるだけでなく、不正なページやプログラムを設置されるおそれがあります。訪問者が不審なページに誘導されたり、サイトの信頼性が損なわれたりする可能性もあるため、ログイン対策は会社の信用を守るうえでも重要です。
管理者が少ない小規模なサイトでも、管理者アカウントが乗っ取られれば、サイト全体に大きな影響が出ます。
サイトの規模だけで判断せず、管理画面の入口を複数の対策で守ることが大切です。
金風株式会社が自社サイトで実施した主な対策は次のとおりです。
ここでは、ログイン対策だけでなく、サイト全体の安全性と復旧に関わる対策も紹介します。
| 分類 | 実施した対策 | 目的 |
|---|---|---|
| CMS本体 | セキュリティ修正を含む更新版へアップデート | 既知の脆弱性を悪用されるリスクを減らす |
| ログイン | ログイン画面とパスワード再設定画面にTurnstileを追加 | ボットによる自動送信を抑制する |
| ログイン | 管理者に認証アプリによる二段階認証を必須化 | パスワードだけに依存しないログインにする |
| ログイン | パスワード再設定時に二段階認証を省略できる設定を無効化 | 再設定手順が認証の抜け道になるリスクを減らす |
| ログイン | 短時間にログインを何度も失敗した場合の制限を設定 | 認証コードやパスワードを繰り返し試す攻撃を抑制する |
| アカウント | 管理者アカウントを棚卸し | 不要なアカウントや見覚えのないアカウントがないか確認する |
| 秘密情報 | 鍵や設定ファイルを公開フォルダの外に置き、アクセス権限を必要最小限にする | Web経由での露出や不要なアクセスを防ぐ |
| 秘密情報 | システム連携用の鍵を交換し、用途やサイトごとに分離 | 漏えい時の影響範囲を抑える |
| お問い合わせ | フォームにTurnstileを追加し、入力内容をURLのクエリ文字列に含めない送信方式にする | 自動送信を抑制し、入力内容がURLに現れることを避ける |
| バックアップ | 日次バックアップに加え、サーバー外にも保管 | 障害や侵害が起きた場合に復旧できる可能性を高める |
なお、入力内容をURLに含めないことだけで、個人情報の安全性がすべて確保されるわけではありません。
通信のHTTPS化、アクセス権限、ログへの記録、保存先の保護なども合わせて確認する必要があります。
また、バックアップは保管するだけでなく、暗号化やアクセス制限、復元テストも重要です。
この記事では、このうち管理画面のログイン対策を中心に解説します。
今回の設定で、管理画面にログインするには、次の3つの関門をすべて通る必要があります。
| 関門 | 役割 | 主に対策するリスク |
|---|---|---|
| 1. Turnstile | アクセスが自動化された不正な操作ではないかを判定する | ボットによる自動送信やログイン試行 |
| 2. パスワード | 本人が知っている情報を確認する | パスワードを知らない第三者によるログイン |
| 3. 認証アプリのコード | 登録した認証アプリを使えることを確認する | パスワードだけを入手した第三者によるログイン |
厳密には、Turnstileは本人確認のための認証要素ではなく、自動化されたアクセスを判定するための仕組みです。
パスワードと認証アプリを組み合わせることで、異なる種類の確認を行い、パスワードだけに依存する場合よりも不正ログインのリスクを低減できます。
ログイン画面には、Cloudflare Turnstileを追加しました。
今回の設定では、多くの場合、利用者が操作しなくても自動で判定され、「成功しました」と表示されます。
判定に迷う場合だけ、チェックボックスが表示されます。
Turnstileを設置したのは、ログイン画面とパスワード再設定画面だけです。
ブログの記事を読むだけの訪問者には表示されません。
Turnstileは、すべての不正アクセスを止める万能な仕組みではありません。
導入時は、サーバー側でのトークン検証やログイン試行回数の制限なども適切に設定することが重要です。
二段階認証は、ログイン時に複数の段階で本人確認を行う仕組みです。
今回導入した方式では、次の2種類の情報を組み合わせています。
パスワードだけでログインする場合、パスワードが漏えいすると第三者に悪用されるおそれがあります。
認証アプリによる確認を追加すれば、パスワードだけを知られた場合に不正ログインされるリスクを低減できます。
ただし、二段階認証を導入すれば、あらゆる攻撃を防げるわけではありません。
偽のログイン画面に誘導され、パスワードと認証コードをリアルタイムで入力してしまうフィッシングなどには注意が必要です。
ログイン先のURLを確認し、不審なリンクからログインしないことも大切です。
2つ目の確認方法には、SMSやメールでコードを受け取る方式もあります。
今回は、スマートフォン上でコードを生成する認証アプリ方式を選びました。
認証アプリでよく使われるTOTP方式では、スマートフォンとサーバーが、あらかじめ共有した秘密鍵と現在時刻を使って、それぞれ6桁のコードを計算する仕組みになっています。
設定時に表示されるQRコードには、認証アプリへの登録に必要な情報が含まれています。スマートフォンの認証アプリで読み取ると、アプリに認証用の秘密情報が登録されます。サーバー側にも対応する情報が保存され、両者が同じコードを計算できるようになります。
この秘密情報は重要です。第三者に知られると認証コードを生成されるおそれがあるため、QRコードや設定用の秘密情報を他人に見せたり、公開場所に保存したりしないでください。
認証アプリは、登録された秘密情報と現在時刻をもとにコードを生成します。
サーバー側も同じ方式でコードを検証し、入力された値が許容される時間範囲内のコードと一致すれば、追加の認証が成功します。
認証アプリはコードを表示するために、毎回インターネット通信を行う必要はありません。
そのため、通信できない場所でもコードを確認できます。
TOTPのコードは通常30秒ごとに更新されますが、許容する時間差やコードの再利用をどう扱うかは、サーバー側の実装や設定にも左右されます。
パスワードの使い回しや、ほかのサービスからの情報漏えい、端末への不正なプログラムの侵入などによって、パスワードが第三者に知られる可能性があります。認証アプリによる確認を追加すると、パスワードだけではログインできなくなるため、不正ログインのリスクを低減できます。
ただし、認証アプリの秘密情報が漏れた場合や、偽サイトを使って認証コードをだまし取られた場合など、二段階認証だけでは防ぎきれないケースもあります。ほかのセキュリティ対策と組み合わせて運用しましょう。
TOTP方式のコードは通常30秒ごとに更新されます。
ただし、更新までの短い時間内にコードを盗み見られた場合や、偽のログイン画面に入力してしまった場合には悪用される可能性があります。
コードを第三者に伝えず、正規の管理画面でのみ入力することが重要です。
6桁の数字には100万通りの組み合わせがあります。
さらに今回は、短時間にログインを何度も失敗すると、一時的にログインできなくなる設定にしました。
こうした対策を組み合わせることで、コードを当てずっぽうで試す攻撃を難しくできます。
ただし、6桁であることだけを根拠に安全性を判断するのではなく、試行回数の制限やサーバー側の検証も含めて考える必要があります。
認証アプリはスマートフォン上でコードを生成するため、コードを表示するたびにSMSやメールを受信する必要がありません。
一方、SMS方式では電話番号の乗っ取り、メール方式ではメールアカウントの侵害などがリスクになる場合があります。
認証アプリにも、スマートフォンの紛失や認証情報の流出などのリスクはあります。
端末の画面ロックやアカウント保護、回復手段の準備も忘れないようにしましょう。
Google AuthenticatorやMicrosoft Authenticatorなど、公式の認証アプリは無料で利用できます。
今回のDrupal環境では、二段階認証に対応するTFAモジュールを利用しました。ほかのCMSでも、対応する機能やプラグインを使って同様の仕組みを導入できます。
導入前には、利用中のCMSやモジュールの対応状況、更新状況、設定方法を確認してください。
設定を誤ると、管理者本人がログインできなくなるおそれがあります。
設定作業中は、ログイン済みのブラウザをすぐに閉じず、別のブラウザやプライベートウィンドウでログインできることを確認してから作業を終えると安心です。
また、認証アプリを使えなくなった場合に備えて、回復コードや、管理者が安全に復旧する手順を事前に確認しておきましょう。
復旧手段は、通常の認証を簡単に迂回できる抜け道にならないよう、アクセス権限を限定して管理する必要があります。
今回は、二段階認証の設定の最後に、回復コードを10個発行しました。
回復コードは、スマートフォンを紛失したり、認証アプリが使えなくなったりしたときに、ログインを復旧するための予備手段です。
今回使っているモジュールでは、1つのコードは1回使うと無効になります。
仕様はCMSやモジュールによって異なるため、導入するときは説明を確認してください。
| 回復手段が必要になる場面 | 例 |
|---|---|
| スマートフォンを紛失した・盗まれた | 外出先での紛失、置き忘れ |
| スマートフォンが壊れた | 画面の破損、水没 |
| スマートフォンが手元にない | 充電切れ、自宅への置き忘れ |
| 認証アプリを利用できなくなった | アプリの削除、機種変更時の移行失敗 |
回復コードは、スマートフォンやパソコンだけに保存すると、その端末が使えないときに確認できなくなります。
今回は、紙に書き写して、パソコンとは別の場所に保管しました。端末の紛失と同時に失わない方法で保管することが大切です。
写真やクラウドに保存する場合も、保存先のアカウント保護とアクセス権限に注意してください。
アプリストアで「認証」「Authenticator」と検索すると、公式アプリに似た名前のアプリが表示されることがあります。
インストール前に、アプリ名だけでなく提供元や料金体系、プライバシー情報も確認しましょう。
実際に今回の作業中にも、公式アプリに似た名前で、無料体験のあとに週単位の料金が自動で発生するアプリが表示されました。
公式の認証アプリは無料なので、課金の画面が出た時点で、提供元を確かめ直すのが安全です。
Google Authenticatorは「Google LLC」、Microsoft Authenticatorは「Microsoft Corporation」が提供元であることを確認してください。
公式アプリの配布状況や名称は変更されることがあるため、アプリストアの公式提供元情報を確認してからインストールするのがおすすめです。
CMSや認証モジュールの構成によっては、パスワード再設定の手順が二段階認証とどのように連携するかを確認する必要があります。
再設定のメールだけで認証を省略できる設計になっている場合、メールアカウントが侵害された際に、ログインの抜け道になる可能性があります。
今回の環境では、パスワード再設定から二段階認証を省略できる設定を無効にしました。
ただし、この動作や設定項目はCMS本体やモジュールのバージョン、構成によって異なります。
実際の環境で仕様を確認し、通常のログインとパスワード再設定の両方をテストしてください。
認証アプリを使うには、登録した秘密情報を安全に保管する必要があります。
スマートフォンの画面ロックを設定し、認証アプリの情報をGoogleアカウントなどに同期・保存する場合は、そのアカウント自体にも強固なパスワードと多要素認証を設定しましょう。
機種変更の際は、古いスマートフォンを初期化したり手放したりする前に、新しい端末でコードを生成でき、実際にログインできることを確認してください。
管理画面はWebサイトの運営に欠かせない入口であり、万一乗っ取られると、サイトの内容や訪問者にまで影響が及びます。
今回、金風株式会社では、次のように対策を重ねました。
二段階認証は、パスワードだけに依存しないための有効な対策です。ただし、導入するだけでセキュリティ対策が完了するわけではありません。CMSの更新、アクセス権限の見直し、ログイン試行の制限、バックアップ、復旧テストなどを合わせて運用することが重要です。
自社サイトの管理画面やログイン対策が十分か気になる方は、Webサイトのセキュリティ診断もご相談ください。
あわせて読みたい
ログイン時に認証アプリを開き、6桁のコードを入力する手間が増えます。
一方、パスワードだけでログインする場合と比べて、不正ログインのリスクを低減できます。
管理画面の重要性や利用状況を考慮し、利便性と安全性のバランスを取ることが大切です。
Google AuthenticatorやMicrosoft Authenticatorなど、公式の認証アプリは無料で利用できます。
似た名前のアプリもあるため、提供元や料金体系を確認してからインストールしてください。
回復コードを用意しておけば、それを使ってログインできます。ログイン後は、新しいスマートフォンに認証アプリを登録し直してください。
回復コードも使えない場合は、CMSや認証モジュールの仕様に沿った管理者側の復旧手順が必要になります。
SMSによる認証もパスワードだけの場合より安全性を高められますが、電話番号の乗っ取りなどのリスクがあります。
利用できる方式や管理環境に応じて、認証アプリなど適切な方法を選びましょう。
はい。WordPressでも、対応するプラグインなどを利用して二段階認証を導入できます。
導入時には、利用中のWordPressやプラグインの更新状況、管理者全員の設定完了、回復手段の保管、パスワード再設定時の動作を確認してください。