SOFRIA
SOFRIA — TURNING VISIONS INTO VISUALS
SOFRIA JOURNAL ESSAY 03 / 05

誰がどこまで操作できるか。アカウントと権限を見直す

WordPressの不正ログインと侵入経路を、人と権限から整理。パスワード、二要素認証、パスキー、WAFの役割と限界を確認し、サーバーやDNSを含むアカウント管理を考えます。

鍵束と管理台帳を見つめる黒猫。アカウントと権限の管理を表す挿絵
AIで制作した説明用のイラストです。実在の顧客・被害事例・制作実績を示すものではありません。

この回で判断できること

不要なアクセス、認証の改善点、防御機能の確認先と運用担当を整理できます。 「対策を入れたか」に加え、「誰に、どこまで操作を許しているか」「対策が実際にどこへ適用されているか」を確認していきます。

A社は、担当者ごとのアカウントを使っている

従業員20名のA社には、お知らせと問い合わせフォームを備えた企業サイトがあります。兼任の社内担当者がおり、制作会社と保守契約を結んでいます。 A社ができているのは、日常の記事編集に、担当者ごとのアカウントを使っていることです。 一方、サーバーや計測サービスまで含めた権限一覧、外注終了時のアクセス停止については、確認範囲が十分に共有されていませんでした。制作会社に悪意や怠慢があるという設定ではありません。 ※A社は説明用の想定事例であり、実在の顧客・被害事例ではありません。

1.WordPressの不正ログイン対策と、権限管理の違い

認証は本人確認、権限は操作できる範囲の管理です。 ログイン時に本人であることを確かめても、その人に必要以上の操作を許していれば、誤操作やアカウント悪用時の影響が広がるおそれがあります。 WordPressには、操作範囲をまとめた「ロール」があります。公式資料の標準的な説明では、管理者は単一サイト内のすべての管理機能にアクセスでき、編集者は他の利用者の記事を含めて記事の公開・管理ができます。投稿者や寄稿者など、操作範囲がより限られるロールもあります。WordPress「Roles and Capabilities」 ここからは運用上の提案です。担当者の役職名ではなく、実際の仕事に合わせて、必要な最小の権限を選びましょう。記事を書く仕事と、追加機能や利用者を管理する仕事を、常に同じ権限で行う必要があるかを考えます。 実際の権限は構成や追加機能でも変わり得るため、ロール名だけで判断せず、保守先に設定を確認してもらいます。

2.パスワードの使い回し・フィッシング・共有アカウントを見直す

別のサービスと同じパスワードを使うと、一方で漏れた情報が、もう一方でも悪用されるおそれがあります。IPAは、不正ログイン対策としてパスワードを使い回さないよう案内しています。IPA「不正ログイン被害の原因となるパスワードの使い回しはNG」 フィッシングには、本物を装った偽画面で、ログイン情報などを入力させる手口があります。 IPAは、偽サイトへ誘導するURLリンクに注意するよう案内しています。突然届いたリンクはクリックせず、普段使うブックマークや正規のアプリから利用することが対策として挙げられています。IPA「URLリンクへのアクセスに注意」 社内の運用としては、急なログイン要求を受けたときに入力を急がず、普段使う正規の入口で状況を確認する手順を共有しておくことを提案します。

共有アカウントは、操作した人を追いにくくする

複数人が同じIDを使っていると、そのIDの操作記録だけでは、実際に誰が操作したかを特定しにくくなります。これは、記録と引き継ぎの観点からの整理です。 A社が日常編集で行っているように、個人ごとのアカウントを基本にすると、利用目的や終了時の停止対象を整理しやすくなります。共有が必要な場合も、利用者・用途・管理責任者を明確にします。

ログインに使う端末も確認する

WordPressの公式資料は、利用者のPCに入力内容を盗むマルウェアなどがある場合、WordPressやサーバー側の対策だけでは守れないことを指摘しています。Hardening「Vulnerabilities on Your Computer」 社内だけでなく、制作会社などが管理に使う端末も、確認対象になります。委託先に端末管理の方針や、紛失・感染時の連絡先を確認しておくことを提案します。

3.二要素認証・パスキー・復旧手段をどう選ぶか

二要素認証は、知っている情報、持っている機器など、異なる種類の要素を組み合わせる本人確認です。二段階で入力する仕組みが、すべて二要素になるわけではありません。 WordPressのHardeningでは、強いパスワードに加えて二段階認証を有効にすることが勧められています。Hardening「Passwords」 パスキーは、対応するサービスで使える、暗号技術を用いた認証情報です。FIDO Allianceは、パスキーをフィッシングに強い認証方式として説明しています。FIDO Alliance「Passkeys」 ただし、WordPressで何を利用できるかは、ホスティングや追加機能などの環境によって異なります。標準でどこでも使えると考えず、保守先に対応状況を確認してください。 以下は、選択時の役割と確認事項を整理した表です。各手段は組み合わせられる場合があり、互いに排他的な分類ではありません。「導入条件・限界」は、運用上の確認事項として編集したものです。

手段 期待する役割 導入条件・限界
パスワード管理ツール サービスごとに異なる強いパスワードの生成・保管を助ける 保管庫・端末・復旧方法・共有権限の管理が必要。フィッシングや端末侵害をすべて防ぐものではない
パスキー 対応サービスで、フィッシングに強い認証を利用する サービス・端末の対応、同期を使う場合の基盤、紛失時の復旧、代替ログインを確認。ログイン状態の悪用や過剰権限への対策は別途必要
二要素認証 パスワードだけに依存する状態を減らす 方式ごとに耐性が異なる。復旧コードや代替手段も保護する

入れなくなったときの手段も守る

FIDO Allianceのホワイトペーパー紹介ページでは、新しい認証方式の導入だけでなく、ログインと復旧の両方を強化する取り組みが必要だと説明しています。FIDO Alliance「Passkeys: The Journey to Prevent Phishing Attacks」紹介ページ 運用上は、端末紛失や本人不在でも、安全に復旧できる担当と手順を決めておきましょう。 復旧コードは、通常の認証手段が使えないときに利用する秘密情報です。提供される場合は、アクセスを制限した保管庫などで管理します。台帳にはコード自体を書かず、保管先の管理責任者と取り出し手順を記録します。 唯一の管理者が不在になる場合も考え、必要な範囲で代替管理者を決めておくことが大切です。

4.サーバー・DNS・メールなど、外側の侵入経路を確認する

WordPressのログイン画面だけが、管理に関わる入口ではありません。確認対象として、次のサービスや接続手段も挙げられます。

  • サーバーの契約・設定を扱う管理画面
  • ファイル転送に使うFTP/SFTP、サーバー操作に使うSSH
  • ドメインを契約する事業者と、接続先を設定するDNS
  • 管理連絡やアカウント復旧に使うメール
  • 社内や制作会社などの操作端末

これは確認対象を整理した一覧であり、どの入口でも同じ被害が起きるという意味ではありません。操作できる範囲と、他のサービスへの影響を確認します。 ファイル転送について、公式資料はホストが対応していればSFTPを利用するよう案内しています。SFTPでは通信が暗号化されます。Hardening「FTP」 管理画面にサーバー側のパスワード保護を追加する方法もあります。ただし、管理機能の一部が動かなくなる場合があると公式資料に記載されています。保守先に相談する対策の一つとして考えてください。Hardening「Securing wp-admin」 追加機能の脆弱性と更新は、第2回で扱っています。

5.WAF・セキュリティプラグイン・アクセス制限は、何を守り、何が残るか

WAFは、Webサイトへの要求を検査する防御機能です。例えばCloudflareの公式資料は、自社WAFが要求をルールに基づいて検査すること、検知による評価と、遮断などの処理を区別して説明しています。同製品では、検知による点数付けだけで遮断されるわけではありません。Cloudflare「Concepts」 これは一つのベンダーの説明です。すべてのWAFが同じ仕組みや設定を持つという意味ではありません。 以下は、一般的な役割と、別途対応が必要なことを編集上整理した表です。機能の有無・範囲は、製品・契約・設定により異なります。 特に「残るリスク」は、上記資料の引用ではありません。

対策 守るもの・役割 守らないもの・残るリスク 運用が必要なこと
WAF 検査対象のWeb通信に対し、ルール等に基づいて不正な要求を検知・遮断する ソフトウェアの弱点自体の修正、保護経路外のアクセス、すべての認証悪用や侵入済み環境の正常化 適用範囲、遮断設定、ルール更新、例外、誤検知、確認担当
セキュリティプラグイン 製品に応じてログイン制限、二要素認証、検査、変更検知等を補助する 未搭載・無効の機能、ホストやDNS等の別アカウント、完全な検知・復旧の保証 プラグイン自体の更新、機能の有効化、通知先、互換性、結果確認
アクセス制限 管理画面等への接続元や利用者を限定し、接触できる範囲を狭める 許可された端末・アカウントの侵害、対象外経路、過剰な操作権限 許可先の見直し、例外管理、終了時の削除、緊急時の安全な利用手順

機能によっては、セキュリティプラグインがWAFやアクセス制限の役割を兼ねます。表の区分は重なり得ます。 IPAのWAF読本の案内も、導入判断・導入・運用の各段階で検討する考え方を示しています。古い資料を含むため、ここではその枠組みのみを参照します。IPA「Web Application Firewall 読本」案内ページ(アーカイブ) セキュリティプラグインを入れていることだけでは、安全性は判断できません。何が有効で、どこまで適用され、誰が確認しているかを確かめる必要があります。 例えば、正常な問い合わせまで遮断される「誤検知」があれば、業務への影響も確認します。例外設定を追加する場合は、理由と見直し担当を残す運用を提案します。

6.計測・タグ・SNS連携も含めて、権限と終了時の引き継ぎを管理する

台帳の対象は、WordPress、ホスト管理画面、FTP/SFTP・SSH、ドメイン、DNS、メールに加え、Google Analytics、Search Console、タグマネージャー、SNS・外部連携も含めます。 計測や発信のためのサービスでも、利用者・目的・権限・管理責任者を確認しておくと、担当交代時に見落としを減らせます。 台帳にパスワードや秘密鍵そのものは書きません。 秘密鍵は、接続時の本人確認などに使う秘密情報です。台帳には管理責任者、秘密情報の保管先を確認する手順、利用終了時の停止担当を記録します。 独自機能のソースや保守の引き継ぎは第2回、外注終了時のアカウント停止はこの回の対象です。また、ステージングという確認用環境も、利用者と認証を管理し、利用が終わったアクセスを残さないようにします。

人と認証の確認表

「分からない」は「未確認」と記録して構いません。役割は次の目安です。

  • 経:経営者が決める
  • 担:社内担当者が行う
  • 専:専門家に依頼する

契約や体制に合わせて調整してください。「専」には、必要な知識を持つ社内技術者も含みます。

確認すること 役割 確認できる人・聞く先 注意が必要な目安
Web関連サービスを一覧にできるか 担 制作会社・計測担当・契約担当 タグやSNS連携の所有者が不明
利用者と利用目的が分かるか 担 各部署・委託先 共通IDで利用者を追えない
業務に必要な権限を決めているか 経 業務責任者・技術者 全員が管理者になっている
権限設定が判断どおりか確認できるか 専 サービス管理者・技術者 画面の設定と台帳が一致しない
使い回しを避け、認証情報を安全に管理できるか 担 社内管理者・技術者 共通パスワードをメール等で配布している
認証方式と復旧方法が利用環境に合っているか 専 サービス管理者・技術者 本人不在や端末紛失で復旧できない
退職・外注終了時の停止担当がいるか 担 人事・契約担当・委託先 終了した委託先のアクセスが残る
緊急時に使える代替管理者がいるか 経 社内責任者 唯一の管理者が不在だと操作できない

防御機能の確認表

確認すること 役割 確認できる人・聞く先 注意が必要な目安
WAF等で何が有効か説明してもらえるか 専 ホスト・保守先 「導入済み」という回答しかない
設定変更・例外・結果確認の担当がいるか 担 保守先・社内責任者 通知先や例外を追加した理由が不明

A社なら、個人別アカウントで管理できている日常編集から、確認範囲を外側へ広げられます。

WordPress以外も含めて、現在アクセスできる人と権限を確認したいです。契約終了時の停止担当と、導入済みの防御機能の適用範囲も教えてください。

次回は、異常に気づき、復旧するための備えを考える

認証を強くすること、操作範囲を絞ること、防御機能を運用することは、それぞれ役割が異なります。どれか一つの導入で、確認が終わるわけではありません。 まずは一つのサービスについて、利用者・権限・停止担当を確認してみてください。 第4回では、「気づく→止める→戻す→再公開」を扱います。この回で整理した防御機能の通知を、誰が受け取り、どう対応につなげるかも考えます。

関連記事

出典と情報確認日

情報確認日:2026年10月10日。

本記事は一般的な解説であり、特定のサイトを診断した結果ではありません。機能の対応状況は利用環境・契約・設定を確認してください。

READ NEXT

こちらの記事もおすすめ

この記事のテーマを、別の視点から。あわせて読みたい記事を選びました。

連載を読む

  1. 01
    公開

    WordPressは危険なのか? 仕組みと責任分担から考える企業サイトの安全

  2. 02
    公開

    プラグインとテーマ、追加した後まで管理できていますか

  3. 03
    公開 この記事

    誰がどこまで操作できるか。アカウントと権限を見直す

  4. 04
    公開予定

    異常に気づく・安全に戻す・再公開する。事故対応の備え

  5. 05
    公開予定

    WordPressを続けるか、構成を変えるか。運用と総費用で選ぶ