mirolabo

ID／パスワードだけのログインは終わりにする ― 経営者のMFA最低ライン

今でもID／パスワードだけで使っているSaaSはありませんか。流出済みパスワードは数十億件以上、自動攻撃は24時間動いています。完璧を目指すより、最低限のMFAを全アカウントに入れることの方が現実的です。

経営者のSaaS（クラウド型サービス）アカウントが、いまだにID／パスワードだけで運用されているケースがあります。会計ソフト、Microsoft 365、Google、銀行、ドメイン管理。どれかひとつでもMFA（多要素認証：パスワードに加えて、SMSコード・アプリ通知・パスキー等の別の確認手段を組み合わせる仕組み）が入っていなければ、それは「鍵が一つしかかかっていない金庫」です。

最初に、この記事の立場を書いておきます。MFAに完璧はありません。リアルタイムフィッシングのように、MFAを入れていても通る攻撃は存在します。それでも、ID／パスワードだけで運用するよりは圧倒的に強い。だから、完璧を目指して動けないより、SMSでもアプリでも何かしらのMFAを今日入れる方が現実的です。

ID／パスワードだけが危険な理由

数字で実態を見てみます。

公開されている流出パスワードのデータベース（Have I Been Pwned 等）には、過去の侵害から漏れたパスワードが累計で数十億件以上登録されています。これは過去のサービス侵害の積み重ねで、自分のパスワードがそこに含まれている可能性は決して低くありません。

そして攻撃者は、これらの流出パスワードを使ってさまざまなサービスへのログインを自動的に試行し続けています。「リスト型攻撃」「クレデンシャルスタッフィング」と呼ばれる手口で、世界中のサーバーから24時間動いています。

つまりID／パスワードだけのアカウントは、「攻撃される可能性がある」のではなく「常に攻撃されている」前提で考える必要があります。

MFAは何でもいい、入れることが最優先

MFA方式の比較を以下にまとめます。完璧度の差はありますが、最も大事なのは「入っているかどうか」だということです。

MFA 方式と攻撃耐性の早見表
方式 自動攻撃
（リスト型・パスワードスプレー等）		 標的型攻撃
（SIMスワップ・リアルタイムフィッシング）		 導入しやすさ
ID／パスワードのみ ✕ 通る ✕ 通る ―
SMS 認証 ○ 概ね止まる △ 弱点あり ○ 高い
TOTP／アプリMFA
（Authenticator系）		 ○ 概ね止まる △ 弱点あり ○ 高い
パスキー ▮ 止まる ▮ 構造的耐性 △ サービス依存
物理キー
（YubiKey 等）		 ▮ 止まる ▮ 構造的耐性 △ コスト・運用負担
最大の差はID／パスワードのみとそれ以外の間。何かしらMFAが入れば自動攻撃の大半は止まる。

ポイントは：

  • どのMFAを入れても、自動攻撃の大半は止まる。リスト型攻撃で流出パスワードが正しく当たっても、二段階目で止まります
  • 標的型攻撃（特定の人を狙うリアルタイムフィッシング等）への耐性は方式で差が出る。ただし、中小企業の経営者を本気で狙う標的型攻撃は確率が低い
  • 完璧を目指してパスキーや物理キーまで揃えるより、まずすべてのアカウントに何かしらのMFAを入れる方が、トータルで安全

私自身、SMSしか使えないサービスにはSMSで、アプリが使えるところはMicrosoft Authenticatorで、対応しているところはパスキーで、と段階的に運用しています。「全アカウントに、入れられる範囲で最強のMFA」が現実解です。

なお、表の最下段にあるYubiKeyのような物理セキュリティキーはMFAの最強形ですが、中小企業の経営者にとっては運用負担とコストが釣り合わない過剰な選択肢です。本記事の対象読者にはあまり関係しないので、ここでは触り程度にとどめます。

MFAで防げないこと（正直に）

完璧を装わないため、MFAでも防げない攻撃を書いておきます。

リアルタイムフィッシング（AiTM：Adversary-in-the-Middle、攻撃者が偽サイトと本物のサイトの間に入って中継する手口）

偽のログイン画面で入力した情報を、攻撃者が裏で本物のサイトに即座に転送し、MFAコードまで連続して聞き出す手口です。SMSでもアプリのTOTP（Time-based One-Time Password：時刻ベースで毎回変わる6桁ほどの認証コード）でも通ります。パスキーは構造的にこれを防ぎます（ドメインが違うと認証情報が出ない仕組み）。

SIMスワッピング

攻撃者がキャリアの窓口で本人になりすましてSIMを再発行させ、SMSコードを奪う手口です。米国では深刻な被害事例が複数出ています。SMS MFAだけはこれに弱いので、可能なところは順次アプリMFAに切り替えるのが望ましいです。

認証アプリのクラウドバックアップ漏洩

Google AuthenticatorやAuthyの一部はクラウドバックアップを提供しています。便利ですが、そのクラウドアカウント自体が乗っ取られると、MFAの元情報がまるごと持っていかれます。バックアップを有効にする場合は、そのクラウドアカウント自体を最高水準で守る必要があります。

経営者が今日できる3つのこと

  1. 使っているSaaS・サービスを棚卸しする。会計ソフト、Microsoft 365、Google、銀行、クラウドストレージ、ドメイン管理、決済代行——これらすべてを書き出してください。

  2. 棚卸ししたサービス全部のMFA設定を確認する。MFAが入っていないアカウントがあれば、SMSでも構わないので今日中に有効化してください。「アプリにすべきだから」と保留すると、その間ずっと自動攻撃の対象です。

  3. アプリMFAに切り替えられるサービスから、順次切り替える。Microsoft Authenticator、Google Authenticator、1Passwordなど、好みのアプリで構いません。ナンバーマッチング機能があるアプリなら、なお良いです。

締め

セキュリティに完璧はありません。リアルタイムフィッシングのように、MFAを入れていても通る攻撃は存在します。

ただ、完璧を求めて動けないことが最大のリスクです。ID／パスワードだけのアカウントは、攻撃者にとって最もコスパの良い標的です。SMSでもアプリでもパスキーでも、何かしらのMFAが入っていれば、攻撃者は次の標的を探しに行きます。

「うちの全アカウントに、何かしらのMFAは入っている」と言える状態を、まず作ってください。