【イベントレポート】認証基盤開発者が知っておくべき構築のおきて

世界中でサイバー攻撃が増加し、セキュリティへの関心が高まるなか、企業はより強固な認証基盤を構築することが求められています。認証基盤を構築する上で考えなくてはいけないのは、IDaaSを導入するか、独自で開発をするのかという問題です。

そこでファインディでは、フリーランスの林さん、株式会社マネーフォワードの細谷さん、株式会社ビズリーチの山本さん、Okta Japan株式会社の池原さんをお招きし、認証基盤の構築について語っていただくイベントを開催しました。

findy.connpass.com

本記事では、認証の概要とトレンド、各企業の取り組み事例など、パネリストの皆さんのトーク内容をまとめています。

パネリスト

林　吟志さん/@ginjih
フリーランス
2011年にNRIセキュアテクノロジーズに入社、日本マイクロソフト、メルカリとITセキュリティに対して、ベンダー・メーカー・ユーザー企業の異なる観点で経験を積んできた。現在はフリーランスとして、セキュリティの支援を行っている。趣味はスノーボード。

細谷直樹さん/@nhosoya
株式会社マネーフォワード　IDサービス開発部部長
2015年にマネーフォワードに入社し、「マネーフォワード ME」の開発、マネジメントに携わる。2018年ごろにID基盤の開発チームを立ち上げ「マネーフォワード ID」を開発。現在も開発チームのリーダーとして活動している。

山本凌平さん/@pikapikaderi
株式会社ビズリーチ　リクルーティングプロダクト本部プラットフォーム開発部会員基盤グループマネージャー
2016年新卒入社。「ビズリーチ」のバックエンド開発からスタートし、フロントエンド、モバイルアプリなど幅広く開発を経験した後、共通認証基盤構築をきっかけにプロダクト全体の基盤を構築するチームで開発を行う。現在は「ビズリーチ」のコアである「マッチング」をAPI化するための足がかりとして検索改善に取り組むチームでマネージャーをしている。

池原大然さん/@Neri78
Okta Japan株式会社　プリンシパルデベロッパーアドボケイト
.NET開発者としてキャリアをスタートし、UIコンポーネントベンダーやクラウドコミュニケーションプラットフォームベンダーにおいて様々なロールを歴任。2023年3月よりOktaに参画し、日本市場におけるAuth0 by Oktaの開発者リレーションを担当。趣味はゲームと長距離の散歩。最長記録は山手線一周。

パネリスト
ID基盤で知っておきたい、抑えておきたいセキュリティの話｜フリーランス　林吟志
マネーフォワードの認証基盤の現在地｜株式会社マネーフォワード　細谷直樹
新認証基盤へ100万ユーザーをゆるやかに移行する｜株式会社ビズリーチ　山本凌平
「にわかにつら」を解消！ Okta Customer Identity Cloud (powered by Auth0) を用いた認証機能の実装｜Okta Japan株式会社　池原大然
- 認証機能だけでなく、クライアントのビジネス成長をサポート

ID基盤で知っておきたい、抑えておきたいセキュリティの話｜フリーランス　林吟志

林：はじめに、認証と認可の違いについてお話させてください。認証は「アクセス者を確認」、認可は「アクセスの可否を確認」するものです。

認証と認可は近しい部分ですが、それぞれに異なる役割を持っています。まれに両者を混同した状態で議論が行われているケースもあるように思いますが、“混ぜるな危険”ということでお話しさせていただきました。

認証方式は思い込みで実装してはいけない

認証がなぜ重要視されるのか。Googleのゼロトラストモデルで援用されるモデル図を参考にすると、アクセス制御の判断にとって、認証は1丁目1番地の重要なトピックであることがわかります。

それを踏まえてお伝えしたいのは、認証方式は思い込みで実装してはいけないということ。拠り所がない状態で実装・リリースしてしまうと、ユーザー体験を著しく毀損してしまったり、ユーザーに不要なリスクを負わせてしまったりする事態になりかねません。

アカウントを作成する際に「複雑なパスワードにする必要がある」「適切な長さが必要だ」といったセキュリティポリシーが公開されているケースがあります。これらはCISのパスワードポリシーガイドやNISTが発行しているドキュメント、各企業や組織のポリシーを参照しているでしょう。このように、拠り所となるポリシーを選択・参照することがとても大切です。

また、このようなポリシーや技術は日々アップデートされています。以前はパスワードの定期更新を促す、秘密の質問を用意する、などの対応が推奨されていましたが、現在はどちらもあまり推奨されない実装となっています。常に最新の情報をキャッチアップするのは難しい部分もあるのですが、ブログやセミナー、Xなどで情報収集するなど、愚直に情報収集するしかないと考えています。

認証器を選択する際は目的を明確にする

認証器についてもお話させてください。認証要素は、知識・所有・生体に大別され、要素を組み合わせると多要素認証となります。なお「パスワード」と「秘密の質問」など同一要素の組み合わせは、多要素認証ではないため、セキュリティレベルは向上しません。

また全てのサービスで強度の高い認証プロセスを選べばいいというわけではないのもポイントです。UXの毀損を防ぐためには、アクセスに応じて認証強度を変えるのが効果的だと言えます。例えば、最近はGoogle Authenticator やワンタイムパスワードを採用しているサービスをよく見かけるようになりました。しかし、これらを導入したからといって、フィッシング耐性を向上することはできません。認証器を選択する際は、目的を明確にしておきましょう。

安全なサービスを提供するための原則

最後に、セキュリティのトレンド、原則についてお話しします。

一つ目は「セキュリティ・バイ・デザイン」です。従来の開発プロセスでは、完成した後のセキュリティ診断や運用におけるセキュリティを重視していました。しかし、後続のフェーズになればなるほど、追加の対策・施策を導入する際のコストが高くなってしまいます。そこで提唱されたのが「セキュリティ・バイ・デザイン」です。機能仕様検討が終了した段階で脅威分析を開始するなど、設計の早い段階からセキュリティを組み込む原則であり、コストの高騰を抑えるだけでなく手戻りの削減などにも効果があります。

二つ目が「セキュア・バイ・デフォルト」です。これは、ユーザーがセキュリティを高めようとせずとも、セキュリティが高い状態にするという原則です。ここで一点だけお話させていただきたいのは、セキュリティレベルを落とすことを許容しない、というわけでない点です。セキュリティが低い状態に変更しても、あとから追跡できるようにするのが重要だということ。認証ログや監査ログがちゃんと取れる状態にしておくことが大切です。

マネーフォワードの認証基盤の現在地｜株式会社マネーフォワード　細谷直樹

マネーフォワードは、認証基盤を独自で開発しました。本日は、開発するに至った経緯や認証基盤が完成したあとの変化についてお話しします。

認証基盤の話に入る前に、サービスについて簡単に紹介させてください。マネーフォワードには、現在50を超えるサービスがあり、一番有名なのがお金の見える化サービスの「マネーフォワードME」です。それ以外にもBtoBのバックオフィス向けSaaS、マネーフォワードクラウドシリーズがあり、それらも含めて、基本的には一つの認証基盤を使って認証しています。

サービスの成長に伴い、認証基盤の開発をスタート

経緯を簡単に説明すると、まず「マネーフォワードME」のサービスを開始したのが2012年です。翌年からサービスの多様化が進み、2017年に共有DBアーキテクチャが限界を迎えたため、2018年1月より認証基盤の開発を開始。同年12月に認証基盤をリリースして、2020年に全サービスが認証基盤への移行を完了させました。

そもそもマネーフォワードのシステムは、一つのアカウントで複数のサービスを利用できる点が売りです。しかし、ユーザー数が600万／サービスの数が7～8個ほどの規模になったときに、共有DBアーキテクチャが限界を迎えてしまいました。

それにより「DBがスローダウンして全プロダクトがシステム障害になってしまう事態が頻発」「認証に責任を持つチームがなく時代遅れな認証になっている」「言語やインフラの制約があり開発者体験が悪い」といった課題が発生してしまったのです。その課題を解決するために、認証基盤を開発することとなりました。

自作の認証基盤にはOpenID Connectを採用

認証基盤には、OpenID Connectを採用しました。OpenID Connectは標準化されている仕様であり、RP側・サービス側が使うライブラリも言語にとらわれることがなく、APIの制約もなくなるという理由からです。

また、既存サービスの認証基盤への移行方針としては、各サービスが任意のタイミングで移行できるようなアプローチを取りました。具体的には、全サービスが認証基盤への移行を完了するまでは、これまで使っていた共有DBと新たに作るDBの両方にデータを書き込み、互換性を保つようにしていました。

ちなみに、IDaaS を使用しなかった理由としては「コスト」「ベンダーロックインの回避」「複雑な要件への対応の柔軟性」などいくつかあるものの、一番はIDエキスパートとの相談やコンサルティングの影響があったように思っています。

時代遅れだった認証のモダン化に成功

認証基盤を自作する上で、個人的に重要だったなと思うのは、サポート体制を整えることです。というのも、私たちのチーム内には認証に詳しい人がいなかったため、認証に詳しい方にコンサルティングしていただいていました。何かあれば相談できるような体制にしていたことが、メンバーのモチベーションを維持することにつながったように思います。

最後に、かつてのマネーフォワードはレガシーな認証しか提供できていませんでしたが、2023年にパスキーに対応するなど、今では最新の認証をいち早く提供できるようになりました。自作するのがおすすめだと主張したいわけではなく、一つの事例として参考にしていただければ幸いです。

新認証基盤へ100万ユーザーをゆるやかに移行する｜株式会社ビズリーチ　山本凌平

「ビズリーチ」ではIDaaSを導入しています。本日は、IDaaSを導入した理由や既存ユーザーの移行方法についてお話しします。

まずは即戦力人材と企業をつなぐ転職サイト「ビズリーチ」ついて、簡単に紹介させてください。「ビズリーチ」は、求職者（ビズリーチ会員様）と、必要な人材を探している企業の人事や、ヘッドハンターに向けて転職プラットフォームを提供しています。

「『キャリアインフラ』になる」というビジョンに向けて、今後もさまざまなサービスを展開していきたいと考えており、そのためには認証基盤が重要なポイントでした。

コストやビジネス的観点からOkta CICを採用

実現したかったポイントは下記の三つです。

・一つのアカウントで横断的にサービスを利用できるようにする・新たにサービスを構築する際の認証機能の実装・運用コストを削減する・パスワードなどの秘匿情報を一元管理し漏洩や不正利用のリスクを下げる

それらを踏まえて、私たちはOkta Customer Identity Cloud（以下、Okta CIC）へ認証基盤を移行しました。マネーフォワードさんのように独自で開発する案もあったのですが、中長期的に考えてコストが高くなること、移行に伴う既存ユーザーの強制ログアウトを回避したいというビジネス的な観点から、IDaaSを導入することになりました。

Okta CICを選んだ理由は、セキュリティ、可用性、サポート体制などを見て総合的に優れていると判断したからです。ユーザーを移行する際にパスワードの再設定が不要だったことも大きなポイントですね。

移行については「1.アクティブユーザーの個別移行」「2.その他ユーザーの一括移行」という二つのフェーズに分けて実施しました。

フェーズ別、移行の具体的な手順

ここからは、移行の手順について具体的にお話します。

まず、アクティブユーザーの個別移行については、Okta CICのAutomatic Migrationを利用しました。簡単に説明すると、カスタマイズしたスクリプトを書くことで、自サービスのAPIやDBと連携し、Okta CIC上で認証を完了したユーザーを、自サービスのユーザーIDと紐付けられる機能です。流れとしては下図の通りです。

ただ、ソーシャル連携でログインしてるユーザーについてはAutomatic Migrationが利用できないため、ActionsとManagementAPIを組み合わせて移行を行いました。前者はカスタマイズの処理を挟みこめる機能で、後者はOkta CICのデータを変更できる管理用のAPIですね。処理の流れは少し複雑なのですが、下図をみていただければと思います。

最後は、その他ユーザーの一括移行です。

先ほども出てきたManagementAPIがユーザーデータのImportAPIを提供してくれているため、APIを利用したバッチを組んで、ソーシャル連携でログインしていないユーザーの一括移行を行うことができました。

認証基盤を構築する際の3つのポイント

認証基盤構築後の運用から得た心得は下記3つです。

・問い合わせが増えることを見越した体制構築と回答のナレッジ化が鍵
・各種Best Practicesは必ずチェックを
・仕様変更をユーザーに受け入れられなかった場合の対応もあらかじめ検討すべき

問い合わせ体制を構築することの大切さや、Best Practicesをチェックしてパフォーマンスを気にかけること、仕様変更を受け入れられなかった場合のリカバリープランを考えておくこと。認証基盤の構築を通して、これらはとても大切なポイントだと感じました。

「にわかにつら」を解消！ Okta Customer Identity Cloud (powered by Auth0) を用いた認証機能の実装｜Okta Japan株式会社　池原大然

本日はOkta Customer Identity Cloud（以下、Okta CIC）についてお話しさせていただきます。

そもそも、我々の製品を含めてIDaaSとは、下記のような「にわかにつら」というものを解消できるというふうに思っています。

・認証の実装方法が「わか」らない・正しく実装しているか「わか」らない・自前の実装を保守するのが「つら」い・最新の認証方式に対応するのが「つら」い

数あるIDaaSのなかでも、Okta CICは開発者フレンドリーなプラットフォームで、利便性・安定性・セキュリティを追求するとともに認証トレンドに追随しているのも特徴です。機能の一つであるユニバーサルログインでは、Webのサインアップ、ログインUIをOktaの認証サーバで提供しています。

ユニバーサルログインについてはデモ画面を使って解説していただきました。
詳細はアーカイブ動画にてご確認ください！

認証機能だけでなく、クライアントのビジネス成長をサポート

ここからは「認証のその先」についてお話させてください。

個人ユーザーからスタートしたあと、グループユーザーや企業ユーザーへの対応が必要になるなど、サービスの利用が拡大すると顧客層が変化し、ビジネスは成長していきます。そのなかで、シングルサインオンや多要素認証、アクセス制御など、さまざまな要件が出てくるでしょう。私たちは、認証機能の実現だけでなく、その先のログインフローやユーザー管理の拡張においてもサポートしたいと考えています。

例えば、サービスが成長して個人ではなく企業ユーザーに対応するとなった場合、各社のIdPに連携してほしいという要望が出てくるかもしれません。そのような場合、メールアドレスが登録済みのドメインと一致した場合には各社のIdPを使い、一致しなかった場合はパスワードやパスキーなどで認証するということも可能です。