「多層防御」の穴になるアカウント管理 ―― なぜ今ルールが必要か
WAF、ネットワーク制限、IPアドレス制限、監査ログ――WordPressサイトのセキュリティというと、こうしたインフラ層・ネットワーク層の対策が語られることが多くあります。しかし、どれだけ堅牢な多層防御を積み重ねても、管理画面のログインID/パスワードが「admin/admin」だったら、みすみす防御壁を一枚減らしていることになります。
これは極端な例ではありません。Wordfenceが観測した大規模なパスワードブルートフォース攻撃では、ピーク時に1時間あたり1,410万件という規模の攻撃が確認されています。攻撃者は総当たりでパスワードを試すのではなく、過去の情報漏洩から集約した「よく使われるパスワードリスト」を使うため、単純なパスワードほど短時間で突破されます（WPScan Blog）。
また、WordPressの脆弱性統計を見ると、脆弱性タイプの内訳でクロスサイトスクリプティング（40.52%）に次いで多いのが「アクセス制御の不備」で13.28%を占めます（Patchstack Vulnerability Statistics）。この分類には、本来持つべきでない権限を取得してしまう「権限昇格」の脆弱性が数多く含まれます。つまり、脆弱性そのものだけでなく、権限がどう設計・運用されているかが、被害の大きさを左右するということです。
さらに見落とされがちなのが、外部からの攻撃ではなく「内部に残った穴」です。退職者のアカウントが削除されずに残っている、複数人で同じログイン情報を使い回している、必要以上の人が管理者権限を持っている――こうした状態は、脆弱性診断や監査ログの整備だけでは防げません。アカウント管理は、技術的な対策と組織運用の両方にまたがる、地味ながら最も効果の大きいセキュリティ対策のひとつです。
権限設計の基本 ―― 最小権限の原則をWordPressにどう落とし込むか
WordPressの標準ロールと権限範囲
WordPressには、Administrator（管理者）、Editor（編集者）、Author（投稿者）、Contributor（寄稿者）、Subscriber（購読者）という5つの標準ロールがあります。マルチサイトだとSuper Admin（特権管理者）がありますね。それぞれ「サイト設定やプラグインの管理まで行えるか」「他人の投稿を編集できるか」「自分の投稿を公開できるか」といった範囲が異なります。多くのサイトで見られる問題は、この使い分けをせず、実際の業務に必要な範囲を超えてAdministrator権限を配布してしまうことです。
「管理者を増やさない」というシンプルだが強力なルール
権限設計の第一歩は、「管理者権限を持つアカウントを必要最小限に抑える」というルールを明文化することです。タロスカイでも、社内・顧客サイトの双方で管理者を増やさないことを基本ルールにしています。Administrator権限は、プラグインのインストールやユーザー管理、サイト全体の設定変更ができてしまうため、乗っ取られた場合の被害範囲が最も大きいロールです。日常的な投稿・編集業務であればEditorやAuthorで十分なケースがほとんどです。
権限昇格リスクとロール設計が果たす防御の役割
すでに触れた「アクセス制御の不備」由来の脆弱性は、たとえばSubscriber権限のユーザーがAdministrator権限相当の操作を行えてしまう、といった形で顕在化します。この場合、そもそも不要な権限を持つアカウントが少なければ、悪用された際の実害も小さくなります。ロール設計は、脆弱性を「ゼロにする」対策ではなく、突破された場合の被害を「小さくする」対策であるという理解が重要です。
権限付与のワークフローを決めておく
誰が・どのタイミングで・どのロールを付与するかを、属人的な判断に任せないことも大切です。「管理者権限の付与には上長の承認を必須にする」「権限変更は記録に残す」といった簡単なルールだけでも、権限の肥大化を防ぐ効果があります。
退職時対応 ―― オフボーディングをルール化する
「アカウントは即削除」を徹底できない組織の共通点
退職者のアカウントが残り続けてしまう組織には、共通点があります。それは、アカウント削除が「退職手続きの一部」として明文化されていないことです。人事・総務の退職フローと、システム側のアカウント管理が別々に運用されていると、担当者の記憶やその場の判断に依存してしまい、抜け漏れが発生します。
タロスカイでは、退職者のアカウントは削除することをルールとしています。これは非常にシンプルですが、放置された退職者アカウントは、パスワードの使い回しや個人メールアドレスの流出経路など、外部からは把握しづらいリスクの温床になります。
オフボーディングチェックリストの作り方
退職時対応をルールとして機能させるには、次のようなチェックリストを退職手続きのフローに組み込むことが有効です。
- WordPress管理画面アカウントの削除（または権限のRevoke）
- 共有していたパスワードマネージャー上のアクセス権の削除
- SFTP/SSHなどサーバー側アカウントの削除
- 業務で利用していた外部連携サービス（GA4、GSC等）のアクセス権の削除
引き継ぎとアカウント削除、どちらを先にすべきか
「引き継ぎが終わっていないのでアカウントを残しておく」という判断は、退職者アカウントが長期間放置される典型的な原因です。引き継ぎが必要なコンテンツやデータは、退職日前に別アカウントへ移管する、またはエクスポートしておく運用にし、退職日にはアカウントを削除できる状態にしておくことが望ましい順序です。以前の外注パートナーの情報がずっと残っている、というのもよくあるパターンです。顧客との連携を密にしておきましょう。
人事・総務プロセスとの連携がカギ
システム管理者だけでこのルールを回そうとすると、退職の情報を把握できずに対応が漏れます。退職が決まった時点で人事・総務からシステム管理者へ通知が行くフローを作ることが、ルールを「絵に描いた餅」にしないための鍵になります。
認証まわりの運用ルール ―― パスワードと多要素認証
多層防御の話に戻ります。インフラ層でどれだけ対策をしていても、アカウント層のパスワードが弱ければ、そこが最も破られやすい入口になります。ここでは、権限設計・退職時対応と並ぶ、もう一つの柱である認証ルールを扱います。
パスワードの使い回しはなぜ危険か
複数のサービスで同じパスワードを使い回していると、どこか一つのサービスで情報漏洩が起きた際に、そのパスワードリストがWordPressサイトへの攻撃にも転用されます。これは「クレデンシャルスタッフィング」と呼ばれる攻撃手法で、WordPress側にどれだけ対策をしていても防ぎきれません。
パスワードマネージャーでの一元管理
タロスカイでは、パスワードは使い回さず、Lastpassなどのパスワード管理ツールで管理することをルールにしています。パスワードマネージャーを使えば、サイトごとに複雑で推測されにくいパスワードを設定しつつ、利用者側の負担を増やさずに済みます。
また、Chromeなどのブラウザに付属しているパスワードマネージャーにも使い回し・漏洩についての警告が出るので、こちらもおすすめです。特に組織単位でツールを導入することが難しい場合には積極的に導入しましょう。
会員制・EC機能があるサイトでの2FA推奨
会員制サイトやEC機能を持つWordPressサイトでは、顧客側の反対がない限り二要素認証（2FA）を推奨するというのも、有効なルールです。パスワードだけに依存しない認証を管理者アカウントに導入することで、パスワードが万一漏洩した場合でも不正ログインのリスクを大きく下げられます。顧客情報を預かるサイトでのセキュリティ責任は非常に重大です。
パスワードポリシーを「仕組み」として強制する
ルールとして周知するだけでなく、パスワード強度を強制するサービス・プラグインの導入や、初期パスワードの使い回しを禁止する運用など、人の注意力に頼らない仕組み化も併せて検討する価値があります。WordPressのコアでサポートされているパスワード強度判定機能などもしっかり利用しましょう。
ルールを「社内に浸透」させる方法
ここまでのルール（権限設計・退職時対応・認証）は、作るだけでは機能しません。多くの組織でアカウント管理がなし崩しになる理由は、ルールが存在しないからではなく、「浸透していない」からです。
ドキュメント化だけでは浸透しない理由
社内Wikiにルールを書いて終わり、という状態はよくある失敗パターンです。ドキュメントは、業務フローに組み込まれて初めて機能します。読む機会がなければ、存在しないのと同じです。
入退社フローにアカウント管理を組み込む
前述のオフボーディングチェックリストのように、入社時・退職時の手続きの中にアカウント管理の項目を正式なステップとして組み込むことで、担当者の記憶に頼らずルールを実行させられます。人事のオンボーディング/オフボーディングのチェックリストに、システム側の項目として明記するのが実務的です。
定期的なアカウント棚卸し
半年に一度など、定期的に「今、誰がどの権限を持っているか」を棚卸しする機会を設けることも効果的です。棚卸しのタイミングで、不要な管理者権限や、削除し忘れた退職者アカウントを発見できます。
責任者・運用担当を明確にする
最後に、これらのルールを「誰が守らせるか」の責任者を決めておくことです。責任の所在が曖昧なルールは、時間の経過とともに形骸化します。小規模な組織であれば、インフラ担当や情報システム担当がこの役割を兼務する形で構いません。
WordPressでの実装Tips
権限管理プラグインの活用
WordPress標準のロール機能だけでは細かい権限調整が難しい場合、User Role Editorのようなプラグインを使うことで、ロールごとの権限をより柔軟にカスタマイズできます。会員制サイトなど、独自のロール設計が必要なケースで有効です。
設定系のツールは管理者権限を要求することも多く、「たとえばGTMのscriptタグを入れられる権限が欲しい」ということもあるでしょう。そうした場合でも「管理者とほぼ同等だがプラグインのインストールはできないカスタムロール」などを用意することで堅牢性を増すことができます。
「誰が・いつ・何をしたか」を追跡する監査ログ
権限設計や退職時対応のルールを整えても、それが実際に守られているかを確認する手段が必要です。監査ログを導入しておけば、権限変更やログイン履歴を後から追跡でき、ルール違反や不審な操作の早期発見につながります（詳しくは監査ログとインシデント対応：エンタープライズWordPressに不可欠なセキュリティ基盤で解説しています）。
共有ログインを避けるための運用設計
複数人で1つの管理者アカウントを共有する運用は、誰が何をしたか分からなくなるだけでなく、退職時のアカウント削除も難しくします。人数分のアカウントを発行し、共有ログインを前提としない運用に切り替えることが、これまで述べたすべてのルールの土台になります。
まとめ ―― アカウント管理はセキュリティ対策の基本
WAFや監査ログ、脆弱性診断といった対策は重要ですが、それらは「アカウントが正しく管理されている」という前提の上に成り立っています。権限設計、退職時対応、認証ルール、そしてそれらを社内に浸透させる仕組み――このどれか一つでも欠けると、他の対策の効果は大きく下がってしまいます。
ルールを作ること自体は難しくありません。難しいのは、それを日々の業務フローに組み込み、形骸化させずに運用し続けることです。まずは「管理者を増やさない」「退職者のアカウントは削除する」といった、すぐに始められるところから着手することをおすすめします。
