銀行残高は無事なのに、なぜ止めた？マネーフォワード不正アクセスに学ぶサイバー防衛

「本番環境のセキュリティに数億円を投じても、開発者がテスト用トークンをうっかりコミットした瞬間にリスクが生まれる。SSDLC（セキュリティを組み込んだソフトウェア開発ライフサイクル）を開発プロセスの文化として根づかせることが急務です」（サイバーセキュリティコンサルタントの新實傑氏）

　さらに、AI技術の普及はこの構造的問題を加速させている。攻撃者はAIを使い、業務文脈に溶け込んだ精巧なフィッシングメールを大量生成できる。また、大量のソースコードを取得した後は、AIに脆弱性の検索や埋め込まれた認証情報の抽出を命じることで、人間の何倍もの速度で解析が進む。

「ゼロデイ脆弱性の発見にかかる時間が、AIツールの活用によって従来の数週間から数時間単位に短縮されているケースが報告されています。攻撃と防御の非対称性は今後ますます拡大するでしょう」（同）

「止める」という判断の重さ

　今回の対応で評価すべきは、マネーフォワードが侵害の確定を待たずに予防的措置を即日実行した点だ。

　同社は「各提携金融機関との安全性の確認を万全なものとするため、銀行口座連携機能を一時的に停止する」と表明し、安全確認が完了次第、連携を再開できるよう対応を進めるとした。実際、5月12日から順次再開を始め、5月15日までに三井住友銀行、三菱UFJ銀行、みずほ銀行といったメガバンク各行や、ソニー銀行、住信SBIネット銀行、楽天銀行、ゆうちょ銀行、全国のJAバンクなどとの連携が再開された。5月20日には、停止期間中にプレミアムサービスを利用していたユーザーに対し、継続期間を15日間延長する補償策も発表された。

　この一連の対応は「インシデント前提の設計（レジリエンス）」の実践例として読み解ける。完全な防御は存在しないという前提に立ち、侵害が拡大する前にサービスを遮断できる構造が機能した。また、利便性を一時的に損なってでも安全を優先する経営判断を即日下せたことは、有事の意思決定フローが事前に整備されていた証左でもある。

「被害範囲の確定を待って公表するのではなく、不確実な段階でも迅速に開示し、予防的に動いた姿勢は評価に値します。こうした透明性こそが、長期的な信頼構築の基盤になる」（同）

自社の「設計図」を守るための4つの実践

　今回の事案を踏まえ、企業がすぐに着手できる対策を整理する。

（1）シークレット・スキャンの自動化： ソースコードにパスワードやAPIキーが含まれていないかをAIが自動検知し、コミット前にブロックする機能をGitHubは標準提供している。まず「有効化されているか」を確認することから始めたい。

（2）最小権限の原則（Least Privilege）の徹底： 一人のアカウントが侵害されても、会社全体のリポジトリが閲覧・コピーされないよう権限をエリア分けする。「全員が全リポジトリにアクセスできる」状態は開発効率は高いが、リスクも高い。

（3）MFAとIPアドレス制限の組み合わせ： IDとパスワードだけに頼る時代は完全に終わった。多要素認証（MFA）に加え、接続元ネットワークを制御するIPアドレス制限を組み合わせることで、認証情報が漏洩しても不正アクセスを阻止できる確率を高められる。

（4）開発者教育と机上演習（TTX）の定期実施： フィッシング耐性は知識だけでなく、疑似攻撃を実際に体験することで養われる。インシデント発生時の対応フローをチームで訓練しておくことが、「止める」判断のスピードに直結する。

　今回の事案は、一企業の失態として片づけられない。GitHubを利用して開発を行うあらゆるIT企業が、本質的に同じリスクを抱えている。

　経営層やビジネスパーソンに問いたいのはシンプルなことだ。「自社の開発環境のセキュリティ状況を、あなたはどれだけ把握しているか」。本番環境の守りを固めると同時に、その設計図を管理する開発環境の安全を、エンジニア任せにせず経営レベルの課題として捉え直すこと。それが今、企業価値を守るもっとも確実な盾となる。

（文＝BUSINESS JOURNAL編集部、協力＝新實傑／サイバーセキュリティコンサルタント）