誰も気づかなかったパスワードの使い回し：香港の会計事務所におけるMFA導入の道のり

要約： 香港の会計事務所で行った定例のIT点検で、気まずい事実が見つかった。あるスタッフが何年も前から、会社のメールシステムと業務管理プラットフォームで同じパスワードを使い回しており、しかもどちらのシステムにも多要素認証（MFA）が有効になっていなかったのだ。事務所の最初の反応は、より厳格なパスワードポリシーを作ることだった。しかし本当に必要な対策は、より強いパスワードではなく、パスワードだけが攻撃者とクライアントデータの間に立つ唯一の防御にならないようにすることだった。

香港の会計事務所は、自分たちが思っている以上に機微なデータを抱えている

これは実在の顧客ではなく複合的なシナリオだが、香港の中堅会計・監査業界——法定監査、税務申告、アドバイザリー業務を手がけ、クライアントが中小企業から家族経営企業、さらには規制業種の企業にまで及ぶ、スタッフ数おおむね30〜60名規模の事務所——では、よくあるパターンだ。表面的には、こうした事務所は明白なサイバーセキュリティの標的には見えない。取引フロアもなければ、顧客向けアプリも、決済ゲートウェイもない。だが静かに存在しているのは、銀行以外では最も機微な財務データが集中している場所のひとつという事実だ。クライアントの銀行明細、給与記録、税務申告書、資本構成表、そして——法定監査業務を手がける事務所であれば——攻撃者が他の経路から再構築しようとすれば数週間はかかるであろう、クライアントの内部財務情報へのアクセス権限がそこにある。

こうしたデータは一箇所にまとまっているわけではない。クライアントとのやり取りや、誰も個別に暗号化しようとは思わない添付ファイルを日常的に運んでいるメールシステム、監査調書やエンゲージメントファイルを保管するクラウドストレージまたはファイル同期プラットフォーム、そしてクライアント記録、請求管理、しばしば文書ワークフロー全体を追跡する業務管理システム——それぞれに分散している。これら3つのシステムはそれぞれが一つの「扉」だ。この規模の事務所では通常、ITに詳しいスタッフ数名と、日常サポートを担う外部委託のIT業者だけで運営されている——専任のセキュリティ機能はなく、多くの場合、これらの扉が実際に同じ強度で施錠されているかを問う責任者すらいない。

これに拍車をかけている商業的な圧力は現実であり、拡大し続けている。クライアントとのエンゲージメントレターには、データ取扱いおよびセキュリティに関する条項が盛り込まれる傾向が強まっている。これはクライアント自身が個人資料（プライバシー）条例（PDPO）の下で負う コンプライアンス義務、そして規制業種に属するクライアントであれば、そのクライアント自身の規制当局が、データに触れるベンダーの連鎖全体に対して抱く期待に起因する。専門職業賠償責任保険会社も、更新時に以前より鋭い質問を投げかけるようになっている。これらはいずれも、会計事務所自体が免許を持つ規制対象機関であることを要求しているわけではない——ただ、他者が責任を負うべきデータを託されているという事実だけを要求しており、それは監査・会計事務所が引き受けるほぼすべての業務に当てはまる。

シナリオ：パスワードだけがすべてを守り、MFAは誰かが思い出した場所にだけ有効になっていた

このシナリオでのIT点検が実際に見つけたものは、この規模の事務所の間で経営陣が想像している以上に繰り返されているパターンだ。ほとんどのシステムはパスワードのみのアクセスで運用されていた——ユーザー名とパスワード、それだけだ。MFAは技術的には存在していたが、有効化は一貫していなかった。おそらくMicrosoft 365の導入または更新のタイミングで、事務所の中核となるメールテナントに対しては一度有効化されていたが、それがすべてのメールボックスで実際に強制されているか、業務管理プラットフォーム、クラウドストレージアカウント、あるいは繁忙期にスタッフが在宅勤務で使うVPNにまで及んでいるかを、誰も後になって確認していなかった。

これらを統一的に管理する条件付きアクセスポリシーは一切存在しなかった——社内ネットワークから会社支給のノートPCでログインする場合と、見知らぬIPアドレスから午前3時にログインを試みる場合とを区別するルールがなかった。どのシステムにとっても、ログインはそれがどこから来たものであれ、どの端末から来たものであれ、すべて同じに見えていた。セルフサービスのパスワードリセットの仕組みも名ばかりだった——パスワードを忘れた場合、通常はIT担当者に電話し、相手が手動でリセットするというやり方で、電話をかけてきた本人であることを確認する確実な手段はほとんどなかった。

パスワードの使い回しそのものは、クライアントのデューデリジェンス質問票に対応するための定例アクセスレビューの最中に、ほぼ偶然発見された。あるスタッフが何年もの間、会社のメールアカウントと業務管理プラットフォームのログインで同じパスワードを使い続けていた——厳密には不注意というより、誰もそうしないようにと言わなかったからであり、事務所自体もそれを防ぐようなポリシーを一度も強制していなかったからだ。パートナーたちが本当に理解した後に懸念したのは、まさにこの点だった。長年にわたるクライアントの財務データを保持する2つのシステムにまたがって、たった一つのパスワードが使い回され、そのパスワード以外に防御が何もなかったという事実だ。

これが実際に意味するリスク——そして、より厳格なパスワードポリシーではなぜ解決しないのか

事務所が詳しく調べた結果、3つの実質的な問題が浮かび上がった。それぞれ解決方法が異なるため、分けて考える価値がある。

第一に、一つの漏洩したパスワードだけでクライアントデータに到達できてしまう。これは事務所が不注意だったからではなく、パスワードのみのアクセスがそもそも、認証情報が他人の手に渡った場合を想定して設計されていないからだ。パスワードはフィッシングで盗まれ、第三者サイトの漏洩で使い回しが露呈し、推測され、あるいは事務所自身が気づかないうちに漏洩事件で流出し、攻撃者が実際に使用するまで発覚しないこともある。データ漏洩の80%以上には、どこかの段階で盗まれたか強度の弱い認証情報が関わっている——この数字は抽象的な業界統計ではなく、まさにこの事務所が抱えるリスクそのものを表している。パスワードのみのアクセスを運用する事務所で一つのパスワードが漏洩すれば、攻撃者は通常、正規ユーザーがアクセスできる範囲すべてに、そのユーザーと同じ権限でアクセスできてしまう。

第二に、社内ネットワーク上の信頼できる端末と、世界中のどこからでも来る見知らぬ端末とを区別するポリシーが存在しない。パートナーが会社支給のノートPCでオフィスのWi-Fiからログインする場合と、見知らぬ端末で他国の自宅ネットワークからログインする場合とは、ユーザー名とパスワードしか確認しないシステムにとってはまったく同じに見える。クライアント先への出張、監査繁忙期の夜間在宅勤務、そして個人端末でのメール確認が増えている事務所にとって、これは現実のギャップだ——これらの行動自体は珍しいものではないが、いずれもパスワードのみのアクセスには存在しないポリシー層を必要とする。

第三に——そして事務所が見落としがちな点だが——設計の甘いセルフサービスパスワードリセットは、それ自体がソーシャルエンジニアリングのリスクを生む。電話確認と、簡単に推測できるいくつかの確認質問（「社員番号は？」「生年月日は？」）に依存するリセットプロセスは、それ自体が一つの攻撃対象領域だ。対象となる従業員について少しでも下調べをした攻撃者——LinkedInのプロフィールや、事務所自身のウェブサイトの「チーム紹介」ページからでも容易に得られる情報だ——は、本当にパスワードを忘れた従業員と同じくらい簡単に、脆弱なリセットプロセスを突破できてしまう。パスワードの使い回しだけを解決し、リセットプロセスをこのまま緩いままにしておく事務所は、一つの扉を閉めて、もう一つの扉を開けたままにしているに等しい。

より厳格なパスワードポリシー、より長いパスワードの義務化、より頻繁な強制リセットといった直感的な対応は、実際には上記のどの問題も解決しない。長いパスワードでも単一障害点であることに変わりはない。より頻繁な強制リセットは、実際にはスタッフをより予測しやすいパスワードパターンへ、より多くのパスワード使い回しへと向かわせる傾向がある——十分に文書化された現象であり、厳格なローテーションポリシーがむしろ逆効果になることを示している。問題は一度もパスワードの強度が足りないことではなかった。パスワードがその唯一の防御だったことが問題だったのだ。

Brocentの視点：MFA導入はポリシー設計の作業であり、一度きりのスイッチではない

MFAを「オンにすればいい」というチェックボックス的な発想で捉えたくなる気持ちは理解できるが、それはほぼ常に不十分だ。一つのシステム、一部のユーザーだけにMFAを有効化しても、この事務所に実際に存在していたギャップは埋まらない。ただ移動するだけだ。この事務所の当初の状態——「MFAは誰かが思い出した場所にだけ一貫性なく有効になっていた」——それ自体が、MFA導入を一度きりの設定作業として扱い、すべてのシステム、すべてのユーザー、すべてのアクセス経路を継続的にカバーするポリシーとして扱わなかった場合に何が起きるかを示す証拠だ。

BrocentのMFAソリューションは、この前提から出発する。MFA導入はスイッチではなく、設計の作業だということだ。それは、メール、業務管理プラットフォーム、クラウドストレージ、VPN、そして最新の認証方式をネイティブにサポートしない古いレガシーアプリケーション（古い業務管理ソフトや会計ソフトでは実際によくある問題で、面倒だからと放置するのではなく、RADIUS、SAML、あるいはアプリケーションプロキシを通じて対応する）まで、システムごとに何をどう確認するかを決めることを意味する。また、信頼できるオフィス端末と見慣れない端末とを実際に区別できる条件付きアクセスポリシーを設計することも意味する——端末のコンプライアンス状況、所在地、IPレピュテーションに基づいて認証を段階的に強化するかどうかを判断し、事務所が本当に信頼している端末や場所はホワイトリストに登録して日常的な摩擦を減らす一方、すべてのログインを一律に疑わしいものとして扱うことはしない。同時に、セルフサービスリセットの仕組み自体を修正し、それが気づかないうちに導入全体の中で最も弱い部分になってしまわないようにすることも意味する。

同様に重要なのは、導入初日にスタッフをシステムからロックアウトしないよう、展開のペースを設計することだ——MFAの強制適用がうまく処理されなければ、事務所が最も繁忙な時期にこれは現実のリスクとなり、同規模の事務所がやるべきだとわかっていてもMFA導入を毎年先送りしてしまう最大の理由でもある。適切に管理された展開では、事前にスタッフへの案内を計画し、猶予期間と明確な登録ガイドを用意し、移行期間中は専任のヘルプデスクを配置する——既存のサポート窓口に混乱したユーザーが殺到するのに任せることはしない。これは一度やって終わりの「1週間プロジェクト」では決してなく、継続的な姿勢が必要だ。毎月、実際に誰が登録を完了したか、どこに例外が存在するか、そして上下するMFAカバレッジ率が事務所自身のリスクについて何を語っているのかを把握し続ける必要がある。

この規模の事務所にとって、実際には何が変わるのか

適切に導入された後は、MFAはメールと、クライアントデータに触れるすべての中核システムで一貫して強制される——「メールだけ有効で、他は忘れられている」状態ではなく、単一のポリシーが業務管理プラットフォーム、クラウドストレージ、リモートアクセスに同じように適用され、事務所が既に使っている環境に合った認証プラットフォームが選ばれる（すでにMicrosoft 365を利用している事務所であれば、Entra IDを通じたMicrosoft Authenticatorが最も自然な選択であり、アプリケーション構成によってはDuo SecurityやOktaも選択肢となる）。

このMFA層の上に条件付きアクセスルールが重なり、所在地、端末のコンプライアンス状況、IPレピュテーションに基づいて各ログインをリアルタイムで評価する——すべてのログインを一律に扱うのではなく、信頼できるオフィス端末や場所はホワイトリストに登録して日常的な摩擦を低く保ち、見慣れない場所や非準拠の端末からのログイン試行には、人が気づいて対応するのを待つことなく自動的により厳しい審査が課される。特に機微なクライアント基盤を持つ、あるいは最もセンシティブなアカウントを扱うパートナーがいる事務所には、パスワードレス認証とFIDO2ハードウェアキーがさらなる選択肢として用意されている——初日から全社に強制する必要はなく、最も重要なアカウントについてはパスワードという攻撃対象領域そのものを完全に排除できる。

セルフサービスのパスワードリセットも、独立した問題として放置するのではなく、MFA導入と同時に修正される——修正後のリセットプロセス自体にも第二要素の確認が必要になり、推測しやすい確認質問と電話だけに頼ることはなくなる。これにより、設計の甘いリセットプロセスがそのまま放置していたソーシャルエンジニアリングの隙間を塞ぐことができる。導入自体も慎重にスケジューリングされる——強制適用の前にスタッフへの案内と登録ガイドを配布し、移行期間には猶予期間を設け、展開期間中は専任のヘルプデスクを配置して登録に関する問い合わせに対応する——繁忙期がそのままロックアウト事件にならないようにするためだ。稼働開始後は、ポリシーの更新、新規スタッフや新規アプリケーションの追加に伴う例外処理、そしてMFAカバレッジ率、認証イベント、ブロックされたアクセス試行を示す月次レポートによる継続的な管理が行われる——次にパートナーがアクセス制御は機能しているのかと問われたとき、データに裏付けられた実際の答えを返せるようにするためだ。

パスワードのみのアクセス vs. MFAの不統一な有効化 vs. 管理されたMFA・条件付きアクセスの全面導入（Brocentモデル）

この状況にある事務所には、実際には3つの状態が存在し、それぞれが実際にどこまで守っているのかを正確に見極める価値がある。

• パスワードのみのアクセス（単一要素、単一障害点）——同規模の多くの事務所の出発点であり、漏洩したパスワード一つでクライアントのメール、業務管理記録、クラウド上の監査調書に到達できてしまう状態。運用コストは最も低いが、アクセスレビューやクライアントのデューデリジェンス質問票がその問いを突きつけるまで、多くの事務所は自分たちがまだこの状態にあることに気づいていない。
• MFAの不統一な有効化（「一部のシステムだけ有効」）——何もないよりはましだが、しばしば「完了した」と誤解される。MFAは最も有効化しやすいシステム——通常はメール——にだけ存在し、業務管理プラットフォーム、クラウドストレージ、VPNは静かにパスワードのみの状態にとどまっているか、正式に導入・強制されたことのないMFAを使っている。これは本シナリオで実際に存在していた状態であり、事務所に「アクセス制御は十分だ」という誤った安心感を最も与えやすい状態でもある。
• 管理されたMFA・条件付きアクセスの全面導入（Brocentモデル）——メール、業務管理プラットフォーム、クラウドストレージ、リモートアクセス全体でMFAが一貫して強制され、信頼できる端末・場所と見慣れないものを区別する条件付きアクセスポリシーがあり、セルフサービスリセットがそれ自体の弱点にならず、カバレッジと例外に関する月次レポートによって、事務所はいつこの問いを投げかけられても、実際の最新の答えを返せる。

よくある質問

MFAは日常業務のスピードを落としてしまいますか？

適切に設計されていれば、実質的な影響はほとんどありません。条件付きアクセスポリシーは信頼できる端末と場所をホワイトリストに登録します——パートナーがオフィスで会社支給のノートPCからログインする場合、見慣れない端末や場所からのログインとは異なり、通常は追加認証を求められません。実際に事務所が感じる摩擦は、ほぼ常に展開のスケジューリングの不備に起因します——登録期間もヘルプデスク体制もないまま全員に一斉にMFAを有効化する、といったケースです——MFA自体の問題ではありません。

MFAと条件付きアクセスの違いは何ですか？

MFAは、パスワードに加えて確認コード、プッシュ承認、ハードウェアキーなど、追加の要素を要求してからアクセスを許可する仕組みです。条件付きアクセスは、その上に重なるポリシー層で、端末のコンプライアンス状況、所在地、IPレピュテーションなどのシグナルに基づいて、*いつ*その追加要素を要求するかを決定します。条件付きアクセスのないMFAは、リスクの高低にかかわらずすべてのログインを同じように扱ってしまいますが、条件付きアクセスがあれば、実際にリスクが高い場面にのみより強い確認を課すことができます。

これはMicrosoft 365と組み合わせて使えますか？

使えます。すでにMicrosoftのクラウド生産性スイートを利用している香港の会計事務所の多くにとって、Microsoft 365とEntra ID（旧Azure Active Directory）は最も自然なプラットフォームであり、Entra条件付きアクセスとMicrosoft Authenticatorの組み合わせは、Brocentがこの規模の事務所に導入する最も一般的な構成です。同じ導入プロセスで、Microsoft 365以外のシステム——業務管理プラットフォーム、クラウドストレージ、レガシーアプリケーション——にもカバー範囲を広げます。最新の認証方式をネイティブにサポートしないシステムには、RADIUS、SAML、アプリケーションプロキシを通じて統合します。

ロックアウトを起こさずに、どのように導入をスケジューリングしますか？

強制適用が始まる前に、登録に関する案内と明確な手順が配布され、移行期間には猶予期間が設けられ、スタッフが業務中にロックアウトされることなく登録を完了できるようにします。展開期間中は専任のヘルプデスクを配置し、登録に関する質問や端末変更に対応します。強制適用は通常、段階的に行われます——パイロットグループ、あるいは影響が最小限のシステムから始め——すべてのシステム、すべてのユーザーに同時に適用することはありません。

これはサイバー保険のMFA要件を満たしますか？

現在、ほとんどのサイバー保険契約と、ますます多くのコンプライアンスフレームワークがMFAを要求していますが、保険会社は「MFAはありますか」よりも具体的な質問をしてきます——どのシステムをカバーしているか、どれだけ一貫して強制されているか、例外は追跡されているか、といった点です。管理された、一貫して強制される導入で、毎月のカバレッジレポートがあれば、事務所はこうした質問に対して、最も有効化しやすいシステムだけをカバーする部分的な答えではなく、実際の最新の答えを提供できます。

MFA端末を紛失した場合はどうなりますか？

適切に設計された導入には、このための安全で管理されたプロセスが含まれます——単純なパスワードリセットではなく、検証を伴う再登録です。これにより、紛失した携帯電話やハードウェアキーが、本来強制すべきその管理策自体を回避するバックドアになることを防ぎます。これはまさに、設計の甘いセルフサービスリセットプロセスが放置していたギャップであり、管理された導入が塞ぐべきギャップです。

これはマネージドITプランに含まれますか？

基本的なパスワードおよび認証情報の管理は、BrocentのマネージドIT支援プランのすべての階層にすでに含まれています——これはプラン自体がすでに管理している内容であり、別途購入するものではありません。すべてのシステムをカバーし、レガシーアプリケーションの統合と月次の継続的なレポートを含む、フルスケールのMFA・条件付きアクセス導入は、プランのセキュリティガバナンス業務の一部として、単独プロジェクトとしてではなく事務所の規模に合わせて範囲設定されます。各プラン階層でこれがどのようにカバーされるかは、最新の料金をご覧ください。

マネージドITプランの中での位置づけ

この事務所にとって本当の解決策は、より厳格なパスワードポリシーではまったくなかった——MFAと条件付きアクセスの導入は、一度やって終わりのプロジェクトではなく、継続的に保持すべきガバナンス業務だと認識することだった。だからこそ、これは単独の購入としてではなく、ユーザー単位で課金されるマネージドITプランの中に組み込まれるべきものだ。パスワードと認証情報の管理は、すでにBrocentのマネージドIT支援プラン——Startup、Established、Growth、Enterpriseの各階層——の一部であり、24時間365日の監視、ヘルプデスク、管理されたファイアウォール、パッチ管理と並ぶ位置づけにある。Microsoft 365やEntra IDなどのマネージドクラウドサービス全体にまで及ぶフルスケールのMFA・条件付きアクセス導入も、独自の契約と独自のギャップを抱える別のベンダーとの取引としてではなく、この同じガバナンス関係の中に位置づけられる。

長年にわたるクライアントの財務データを保持するシステム間でパスワードが使い回されていたことを発見したばかりの香港の会計事務所にとって、次に取るべき有用な一歩は、単独でMFAベンダーを探すことではない。事務所の規模に合ったユーザー単位のマネージドITプランがどのようなものかを話し合い、MFAと条件付きアクセスの導入を、プラン自体がすでに担っているセキュリティガバナンス業務の一部として位置づけることだ。事務所の日常的なIT運用を担うチームから切り離された形で、MFAを単発のプロジェクトとして専門ベンダーから個別に購入することこそ、事務所が最初と同じ状態に戻ってしまう原因となる——一つのシステムに対して一度だけ有効化され、その後誰も見直すことのない管理策として。

詳しい料金はこちらをご覧ください。4つのプラン階層すべてと、MFA・条件付きアクセス導入のようなセキュリティガバナンス業務がどのように組み込まれるかを確認できます。貴事務所と同じ規模の事務所にとって、管理された導入が実際にどのようなものになるか——本シナリオのようなパスワードの使い回しやMFAカバレッジの不統一が、どれだけ早く解消できるかを含めて——最も早く知る方法は、料金ページだけで判断しようとするのではなく、Brocentに直接相談することです。