製品ごとに開発していたログインを、共通のパスキー認証に統一

この会社は、業務向けの SaaS と、開発者が自らのサービスに組み込んで使う API を、複数の製品として提供しています。対象とする業界や利用者はそれぞれ異なりますが、どの製品にも、利用者が設定や利用状況を確かめるための管理画面があります。製品の数が増えるにつれて、管理画面のログインをどう扱うかが、開発と運用の両面で無視できない論点になっていました。

同社は、製品ごとにばらばらに作られていたログインの仕組みを見直し、すべての管理画面に共通のパスキー認証を導入しました。どのような考えで仕組みをそろえ、どのように展開したのか、その歩みを紹介します。

製品が増えるたびに作り直してきたログイン

同社の製品は、それぞれ独立したチームの判断で立ち上げられてきました。管理画面のログインも、製品を立ち上げる時点でその製品の事情に合わせて作られ、メールアドレスとパスワードによる方法や、メールで届くリンクを使う方法など、製品によって仕組みが異なっていました。

製品が少ないうちは、こうした違いが大きな問題になることはありませんでした。しかし、製品の数が増えるにつれ、ログインに関わる改修や不具合の対応を製品ごとに個別に行う必要が出てきました。ある製品で見直した点を、ほかの製品にも同じように反映するには、それぞれの実装を読み解いて手を入れなければなりません。

管理画面には、API キーの発行や請求の設定、利用者の情報といった重要な操作が集まっています。製品によってログインの強さが異なると、最も弱い製品が全体の安全性を左右することになりかねません。利用者の側から見ても、製品ごとにログインの方法が違うことは、わかりにくさの原因になっていました。

管理画面を使う利用者の層も製品によって異なります。業務向けの SaaS では、事業者の担当者が日々の設定や利用状況の確認のためにログインします。API の製品では、開発者が API キーの発行や利用量の確認のためにログインします。利用の頻度や場面は違っても、どちらも事業や開発の要となる情報を扱う点では変わりません。同社は、利用者の層にかかわらず、同じ水準でログインを守る必要があると考えていました。

同社は、製品が今後も増えていくことを見込んでいました。そのたびにログインの仕組みを作り直し、保守の対象を増やしていく進め方を続けることは難しいと判断し、管理画面のログインを共通の方法にそろえることを決めました。

パスキーを製品ごとに開発する負担

ログインの方法として同社が選んだのは、パスキーでした。パスキーは、端末の生体認証や画面ロックを使ってログインする仕組みで、パスワードのように盗まれたり使い回されたりする心配が小さく、偽のサイトに誘導される被害も防ぎやすくなります。重要な操作が集まる管理画面を守る方法として、パスキーは同社の考えに合っていました。

一方で、パスキーを正しく実装するには、ブラウザと認証器のやりとり、サーバーでの検証、登録済みのパスキーの管理、紛失したときの対応など、多くの要素を整える必要があります。これを製品ごとに開発すれば、実装と保守の負担は製品の数だけ増えます。仕様の更新やブラウザの変化に合わせた見直しも、製品ごとに繰り返すことになります。

また、パスキーを導入するだけでなく、導入後の運用も考える必要がありました。利用者が端末を買い替えたり紛失したりした場合の対応、退職した担当者のログインの停止、不審なログインの確認などは、製品ごとに手順が異なると、運用の担当者の負担が大きくなります。実装と同じく、運用の手順も製品の間でそろえられることが望ましいと同社は考えていました。

社内で共通の認証の仕組みを独自に開発し、各製品から呼び出す案も検討しました。この方法であれば実装は一か所にまとまりますが、認証の仕組みそのものを継続して運用し、安全性を保ち続ける責任を社内で負うことになります。同社にとって、それは本来力を注ぐべき製品の開発から人手を割くことを意味していました。

製品ごとにアプリを分けられる SealGate の採用

こうした検討を経て、同社は既存のログインにパスキーを追加できる認証基盤である SealGate を採用しました。決め手となったのは、製品ごとにアプリを作成し、同じ組み込み方でそれぞれにパスキーを追加できる点です。

SealGate では、アプリごとにドメインを設定でき、パスキーはそのドメインで登録・利用されます。製品ごとに管理画面のドメインが異なる同社の構成でも、製品ごとに一つのアプリを用意すれば、それぞれの管理画面にパスキーを導入できます。組み込みはブラウザ SDK とサーバー側の中継で行うため、各製品の既存のログイン画面や、ログインした後の権限の扱いを大きく作り替える必要はありません。

ログインの記録を SealGate で確認できることも評価の対象になりました。製品ごとにログインの記録を残す仕組みを開発する必要がなくなり、不審なログインの確認や問い合わせへの対応を、共通の方法で行えるようになります。

採用の判断にあたっては、テスト環境で実際に組み込みを試し、既存のログイン画面にどの程度の変更が必要かを確かめました。組み込みに必要な作業が限られた範囲に収まり、製品ごとの違いが設定の差にとどまることを確認できたことで、すべての製品に同じ方法で展開できるという見通しが立ちました。

共通の手順を一つの製品で固めてから展開

導入にあたって、同社はまず組み込みの手順を一つにまとめることから始めました。SealGate のアプリの作成、ドメインの設定、ブラウザ SDK の組み込み、サーバー側の中継の実装という流れを手順として整理し、どの製品でも同じ順序で進められるようにしています。

最初の製品では、テスト環境で登録からログインまでの流れを確かめ、手順の抜けや製品ごとに異なる部分を洗い出しました。製品ごとに違うのは、主に管理画面のドメインと、ログインした後に開くセッションの扱いです。こうした違いを手順の中で明示しておくことで、次の製品に展開する際に迷う点を減らしました。

手順が固まった後は、ほかの製品にも同じ手順を当てはめていきました。製品ごとに SealGate のアプリを作成し、共通の手順でパスキーを組み込んでいます。各製品の開発の担当者は、手順に沿って作業を進めればよく、パスキーの仕組みを一から理解し直す必要はありませんでした。

切り替えの期間には、既存のログインを残したままパスキーを追加しました。管理画面の利用者は、これまでどおりの方法でログインしながら、都合のよい時にパスキーを登録できます。急な切り替えによって利用者が管理画面に入れなくなる事態を避けるため、パスワードとパスキーを併用する期間を設けています。

ログインの記録を一か所で確かめる運用

製品ごとにアプリが分かれているため、ログインの記録も製品ごとに整理されて SealGate に残ります。いつ、どの利用者が、どの製品の管理画面にログインしたか、ログインに失敗した記録があるかを、製品の単位で確かめられます。

同社では、こうした記録を確認する方法も製品の間でそろえました。不審なログインが疑われる場合や、利用者からログインに関する問い合わせを受けた場合には、該当する製品のアプリの記録を確かめて状況を把握します。製品ごとに異なる仕組みの記録を読み解く必要がなくなり、確認の手順が標準化されました。

利用者と登録済みのパスキーの管理も、SealGate の管理画面から行えます。端末を紛失した利用者のパスキーを無効にするといった対応も、どの製品でも同じ方法で進められます。運用の担当者にとって、製品ごとに対応の方法を覚え直す必要がないことは、日々の負担を軽くする要因になっています。

社内では、ログインの記録を確かめる担当と、利用者からの問い合わせに対応する担当の間で、確認の手順を共有しています。どの製品の問い合わせであっても、同じ画面で同じ項目を確かめればよいため、担当者が替わっても対応の品質を保ちやすくなりました。

そろったセキュリティの水準と開発の進め方

導入後、同社のどの管理画面も、同じパスキーの仕組みでログインできるようになりました。製品によってログインの強さが異なる状態が解消され、管理画面全体のセキュリティの水準がそろっています。利用者にとっても、複数の製品を使う場合に同じ方法でログインできるため、わかりやすさが増しました。

開発の面では、ログインに関わる実装の多くを SealGate に任せられるようになりました。パスキーの仕組みを製品ごとに保守する必要はなく、製品の開発の担当者は、それぞれの製品の機能の改善に力を注げます。ログインの記録の仕組みを製品ごとに持つ必要もなくなりました。

ログインの方法を見直す必要が生じた場合も、共通の手順を一つ見直せば、すべての製品に同じ考え方で反映できます。製品ごとに異なる実装を一つずつ確かめていた頃と比べ、変更の影響を把握しやすくなりました。

社内の開発の進め方にも変化がありました。新しい製品の設計を始める段階で、管理画面のログインは共通の手順に任せることが前提となったため、設計の議論を製品そのものの機能に集中できるようになりました。ログインの仕組みが製品の立ち上げを遅らせる要因になることも少なくなっています。

新しい製品にも同じ手順で

同社は、今後立ち上げる製品にも、同じ手順でパスキーを導入する方針です。新しい製品の管理画面を用意する際には、SealGate のアプリを一つ作成し、共通の手順に沿って組み込むことを標準としています。製品を立ち上げるたびにログインの仕組みを考え直す必要はなくなりました。手順そのものも、製品に展開するたびに気づいた点を反映して更新しており、社内の共通の資料として整備を続けています。

当面は、既存のログインとパスキーを併用しながら、各製品の利用者にパスキーの登録を広げていきます。製品ごとのログインの記録を見ながら移行の進み具合を確かめ、案内の方法を調整していく考えです。パスキーの登録が十分に広がった製品から順に、パスワードによるログインの扱いを見直すことも検討しています。

あわせて、ログインの記録の活用も進めていく予定です。製品ごとの記録を定期的に確かめ、ふだんと異なるログインの傾向に早く気づける運用を整えることで、管理画面の安全性をさらに高めていきます。製品の数が増えても、管理画面のログインを同じ水準で守り続けられる体制を整えていきます。