日本全体の“認証”を弱めた「SSO税」 「アカウント地雷」の撤去コストを下げる極意：「こんなサービス使ってたっけ？」

2026年3月3日、「ITmedia Security Week 2026 冬」で、セキュリティ啓発アニメ「こうしす！」の脚本・監督として活躍する井二かける氏が「認証技術とID統制、その第一歩を踏み出すために」と題して講演した。

[宮田健，＠IT]

　井二（いぶた）氏は、情報処理安全確保支援士という肩書とともに、「物語の力で、IT・セキュリティをもっと面白く」をモットーとしたアニメ作家・クリエイターという多面的な顔を持つ。自主製作でスタートしたセキュリティ啓発アニメ「こうしす！」は地上波放送、劇場公開を実現。さらなる展開として、新SFレーベル「SWIBO Fictions」で2038年問題をテーマとしたSF小説を企画中だ。

　講演では、技術的な堅苦しさを取り払うことで、いかに組織にセキュリティ意識を浸透させるかという戦略的な視点から「認証・認可」を語った。

認証・認可は「大昔からセキュリティの基本」だが……

　井二氏は冒頭で、認証・認可は紀元前14世紀の古代エジプトにおける広義の通行許可証「アマルナ文書」までさかのぼると切り出す。セキュリティの基礎ともいえるテーマで、現在ではパスワードに加えてもう一つの要素を活用する「二要素認証」や、パスワードを廃する「パスワードレス認証」が注目されている。

　ここで井二氏は「認証」と「認可」の区別を行う。認証（Authentication）は「合い言葉を言え」ということ、認可（Authorization）は「通れ、通行を許可する」ということを示す。認証はあくまで本人確認、認可は何を許すかを示すことであり、セットで扱われることが多いものの、別のステップと考える必要がある（参考記事）。

認証は合い言葉、認可は「通れ」という許可を示す（井二氏の講演資料から引用）

　認証・認可を、さらに細分化して考えてみる。

　まず、ユーザーは「アカウント」という名の識別認証情報を「登録」する。これは「エンロールメント」「レジストレーション」とも呼ばれ、銀行口座開設時の免許証などによる本人確認などが含まれる。この情報が認証の基礎となる。

　次に、ユーザーが名乗る「識別」のステップがある。ユーザーIDを入力するログインなどが該当する。そして、「認証」のステップで、名乗ったユーザーが本人かどうかを確認する。パスワード入力や生体認証、パスキーといった方法がある。

　識別と認証の境界は曖昧になっており、ドラマなどで「防犯カメラの顔を認識して個人の行動を追跡する」システムのことを「顔“認証”システム」とすることがあるが、「顔“識別”システム」と呼ぶべきではないかという議論もある。

　認証が完了すると、「認可」のステップに進む。これはユーザーにアクセス許可を与えることを指す。

認証に関連するステップ（井二氏の講演資料から引用）

　井二氏はこのように各ステップを分けた意味について「外注できる部分が増え、柔軟に対応できる」と話す。物理環境の例としては、イベントなどでは受け付け業務や本人確認、入管証の発行をイベント業者に委託し、入管証の確認は警備業者に委託するというイメージだ。

　情報システムでは、どのように委託できるのだろうか。よく言われるのが、「Microsoft Entra ID」「Google Cloud Identity」「IIJ IDサービス」といったIDaaS（ID as a Service）だ。このようなサービスを活用することで、認証情報の処理を委託できる。

　「ベンダーロックインのデメリットは発生するものの、委託することで監視や脆弱（ぜいじゃく）性対応や監査ログの取得、パスキーなど最新技術に対応でき、運用を専門業者に任せられるのがメリットだ」（井二氏）

　特に昨今では、オンプレミスの「Active Directory」がランサムウェア攻撃の標的になりやすく、境界防御だけでは不十分だ。ゼロトラストアーキテクチャへの移行の第一歩としても、IDaaSの活用を考えたい。

「取引先が使っているサービスのアカウント取得」の裏にある悲しい現実

　統制されていない認証情報には、大きな課題がある。「取引先がMicrosoft Teamsを使っているから」「Google Meetを使っているから」とWebサービスに登録したり、「生成AIブーム」で取りあえず登録したりといったシーンは企業・組織でもよく見る光景だろう。

　社内実験でチームプラン（例えば、最低5人から）の契約は難しく、コスト削減のために個人アカウントが選ばれることが多い。その結果、「取りあえず登録した」アカウントが「まあ、いっか」で放置されてしまう。この結果、数年後になって「あれ、このアカウント誰のだ？　退職者？」「情報漏えいのおわびが来たけど、そもそも、こんなサービス使ってたっけ？」といったことにつながるのが実情だ。

「まあいっか」が「こんなアカウント使ってたっけ？」につながる（井二氏の講演資料から引用）

　「統制されていないアカウント」は、アカウント管理の不備による情報漏えいやコスト増、時間増といったリスクを招く。理想的な対策は、やはりSSO（シングルサインオン）だ。これを活用することで、新入社員や退職者のID管理が容易になる。「サービスごとにパスワードを覚えなくていい」「セッションが続いている間は自動で認可されるので、何度もログイン操作しなくていい」といったメリットが得られる。

理想としてのSSO（井二氏の講演資料から引用）

　一方で、デメリットも理解しなくてはならない。SSOは単一障害点となるので、IDプロバイダーのサービスが落ちたら全てのサービスにログインできなくなり、業務が止まってしまう。これを防ぐためには、別手段でのログイン方法の確立やBCP（事業継続計画：Business Continuity Plan）によるカバーなどを検討しなくてはならない。

　SSOは、設定のためにさまざまな知識を持たねばならない点もデメリットの一つとして挙げられる。井二氏もアニメ制作のためにSSO環境を作ろうと努力したが、難易度が非常に高く諦めた過去があると明かす。

　“コスト”の問題も大きい。大抵のSaaSでは、IDaaSと連携したSSO対応には上位プランの料金が必要なことが多い。海外では「SSO税」と表現されるもので、中小企業では上位プランの契約がそもそも難しく、ハードルを上げる原因となっている。井二氏は私見として、「SSOはセキュリティ向上に役立つ必須機能だが、大企業向けの高額な価格設定が問題だ。基本機能はあらゆる組織で利用可能にすべきだ」とした。

「エンタープライズ価格」限定はよくない！（井二氏の講演資料から引用）

　井二氏は「メリットもあればデメリットもある。全てをSSOに寄せるのは難しい」とまとめ、小さな一歩から始めることを勧める。まずは手動でできることからを提案する。

どこから始める？　認証・認可の強化

　SSO導入への第一歩は「アカウントの棚卸しと台帳管理」だ。手作業で始められるステップで、どこに誰のアカウントがあるかを把握するのが最優先。その上で、台帳などで管理するのが全ての基本となる。

　次に、「登録・削除のマニュアル化」だ。新入社員採用時のアカウント作成手順や、退職したときのアカウント削除手順、部内で共有しているアカウントのパスワード変更など、抜け漏れがないように管理する。部内での共有アカウントは、例えば取引先から提示されているサービスのアカウントなど、完全に排除できないものも多い。現実解としては、そのようなサービスを前提に、棚卸しを行い、存在を把握しておくことが重要だ。

　続いて、「組織アカウントの利用」を考える。例えば、各個人で使っているGoogleアカウントを組織で使うと統制が取れず、問題となる。こうした場合は「Googleワークスペース」を、組織アカウントとして活用するのが解決策の一つとなる。こうすることでワークスペースのユーザー一覧を台帳の一部と見なせば、台帳管理をアップデートしていくコストも下がるというメリットも生まれるだろう。

　この上で、可能なものからSSOに置き換える。ここでのポイントは、「全社利用のサービスからSSOを考える」ということだ。

　多くの場合、新サービスは一部の部署からテストで運用していくのが普通だが、無差別に連携を許可することで、本来そのサービスを利用する必要のないユーザーがアクセス可能となり、ユーザー数課金による高額課金が発生する可能性がある。グループ単位での利用制限は、実装が複雑であり、高額プランでのみ利用可能な制限が存在することもあり、初期段階での対応は困難だ。

　従って、部内利用や小規模な利用から開始するよりも、全社的に利用されているサービスからSSOを導入するのが望ましい。これは、一般的なアプローチとは異なる戦略となる。

　例えば、PCログインを「Microsoft 365」の組織アカウントのEntra IDで行うように設定することで、PCとMicrosoft 365の認証を統一できる。この設定により、PCのパスワードを変更すると、自動的にMicrosoft Officeログインのパスワードも変更されるという利便性が得られる。Microsoft 365のIdP（IDプロバイダー）機能を使う場合、Microsoft 365の組織アカウントでGoogle Workspaceにログインできるように設定したり、その逆の設定を行ったりすることで、Google WorkspaceとMicrosoft 365の両方で認証基盤を統一できる。

　とはいえ、これで全てのIDを統一できるわけでもない。どうしても発生する例外に関しては、個人アカウントを取得するにしても、会社のメールアドレスで登録し、定期的に監査する、設定を確認するチェックリストを適用するといった運用が考えられる。

　「エンタープライズ価格しか用意されておらず、中小企業レベルでは割高なサービス場合、独立して使うしかない。どうしても手作業は残るが、その棚卸しと管理は全ての基本であり、無駄なことではない」（井二氏）

手作業は残るが、それは無駄ではない（井二氏の講演資料から引用）

　認証と認可を細かくステップ分けすることで、その一部分をIDaaSとして外注できるようになる。統制で活用できるようにするには、事前に台帳管理しておき、個人ではなく組織アカウントが必要となる。ここからも分かるように、基本的な台帳管理からは逃れられない。井二氏は「逆に言えば、SSOを導入する前から、手作業で管理できる体制を整えることが重要であり、それが最初の一歩だと言える」とまとめた。

---

　いま、攻撃者が狙うのは、クラウドにつながってシステムに正面から侵入できる認証・認可情報だ。多くのインシデントレポートでも、「脆弱性を突かれて侵入された」という表現から「認証情報を悪用された模様」といった、やや玉虫色の表現が増えてきている。攻撃されるはるか前から奪われた認証情報が、時を経て悪用されてしまえば、原因の追究が難しいことも理解できるはずだ。いますぐ、認証・認可を強化しなければ、残された“地雷”がいずれ起爆してしまう。

　多要素認証に加え、認証・認可に関連する「監査」「ログ蓄積」も求められる。その対策になるのがIDaaSの導入と活用。その第一歩をいますぐ踏み出さねばならない――。井二氏は、コミカルに表現しつつも、本質的なポイントを語っていた。ぜひ、もう一度自社の状況をチェックしてほしい。