GitHub の 2FA 導入戦記

　もし 5 年以上使っているメールアドレスがあったら、ダークウェブに流出していないものはない。そう言っていいくらい、アカウント情報の漏洩は普通の出来事である。だが、SMS やメール通知、Authenticator アプリによる 2FA / MFA を設定していれば、漏洩したアカウントの悪用をある程度防ぐことができる。本稿は、2025年の現在にも通ずる ID管理 の課題に関して、Black Hat USA 2023 で行われた講演の要旨をレポートする。

有効でも普及するとは限らないセキュリティ対策

　あまたのセキュリティ対策と同様に、2FA および追加認証とて、ただ「効果がある」「安全性が向上する」という理由だけで経営層や、コンシュマーサービスのエンドユーザーを納得させるのは難しい。メジャーなサービス、Google や Meta などビッグテックは、自社サービスのアカウントに 2FA（以下、とくに明記しない限り本稿では二要素認証、多要素認証を示す用語として 2FA を使う）の設定を強く推奨している。パスワードだけに頼った認証では、フィッシングやリスト攻撃などによるなりすまし、不正アクセスによる被害がなくならないからだ。

　SMS プロトコルには本質的な脆弱性があり SMS 通知による 2FA は推奨されるべきではないという指摘もあるが、接続したデバイスまたは通信路に応じた追加認証（ワンタイムパスワードやパスコード）、ログインアラート、アクセス通知には一定の効果は期待できる。自分を守るためには設定したほうがいいのだが、設定そのものが面倒、確認手順が面倒と考える層は少なくない。経営層やマネージャ、マーケティングなどセキュリティ部門以外からすると、2FA プロセスの導入に伴うコストや UI / UX、顧客満足度への影響に対する懸念がある。

　2020年前後の GitHub アカウントの 2FA 設定率は 20 ％以下だったという。ユーザーの多くがプログラマーや開発者であるはずの GitHub でさえ 8 割は追加認証なしでログインしていたわけだ。彼らは、ソフトウェア開発のプロ、専門家でありサイバーセキュリティに対してもリテラシーが高いはず。なのにこの数字。しかも、ソフトウェアサプライチェーン攻撃が問題になっている今日この頃、アカウント保護や 2FA についてもっと感度を高めるべきだろう。

GitHub ユーザーが 2FA を設定しないことのインパクト

　攻撃者は、正規のアプリやサービスにエクスプロイト、悪意のあるコード、マルウェアを忍ばせるため正規のライブラリモジュールやアプリケーションを標的とする。良性アプリを偽装または良性アプリに感染するのではなく、正規コードに悪意のあるコードを混入させ、正規の呼び出しを攻撃に利用する。正規のダウンロードサイトやプラグインサービスを偽装することもあるが、GitHub のようなオープンな開発プラットフォームの正規プロジェクトに潜入して悪意のあるコードをコミットする方法もある。

　ライブラリレベルで混入したマルウェアの発見は簡単ではない。しかも、多くの製品や商用サービスがオープンソースモデルで開発されている現在、汚染ライブラリ（関数）がどこまで拡散・浸透しているかのトラッキングはほぼ不可能だ。SBOM やソフトウェアアセット管理の重要性が叫ばれているが、アプリケーション名やバージョンだけでなく、市販を含むシステムが依存しているライブラリまで把握する必要があるのはこのためだ。なお、攻撃者はライブラリやモジュールを汚染するため、開発ベンダーや下請け業者に侵入してバックドアを仕込んだ製品コンポーネントを野に放つこともある。

　人気のライブラリツールキットや、プルリクエストしてくるエンジニアが信頼できないとなると、ソフトウェア市場の信頼モデルが崩壊する。かくして、GitHub は 2023 年までにすべての（コードを投稿する）ユーザーに 2FA を有効化するという決定を下し、全ユーザーに通達を送った。GitHub は、オープンソースプロジェクトだけでなく、私企業の開発プラットフォームとしても機能している。彼らにとって、アカウント保護は最優先事項だ。

戦略と戦術を対で考える

　GitHub もまた、他の企業や組織と同じで、2FA の導入には苦労したようだ。セキュリティ対策は、往々にして経営戦略と整合しにくい。ユーザー体験や利便性を損なう傾向もある。どのように 2FA 導入プロジェクトを実施したのか。実際のプロジェクトに参加した GitHub のセキュリティ戦略ダイレクター ジョン・スワンソン氏（写真右）は、2023年の BlackHat USA で、その容易ではなかった取り組みについて情報共有を行った。