IDチームの前田です。先日 NuPhy Halo65 をいうキーボードを入手しました。打ち心地が最高で永遠にコードが書けます。
突然ですが、みなさん認証システム開発、運用してますか? 私は長年開発、運用をやっておりました。
今回は筆者がWEB系企業でインフラエンジニア、SREとして過去に開発、運用してきたWEBサービス(主にB2C)の認証機能、認証基盤の話から2023年における認証システムの話を思います。それぞれのアーキテクチャはあえてぼんやりとした形で記載しています。
サマリー
- 時代に合わせて認証システムの構成は変わる
- 自分たちで認証システムを開発し運用するのは大変
- 2023年には自分たちで作らずにIDaaSを利用するという選択肢もある (次回予告)
用語の整理
本投稿における用語の整理
- 認証機能
- 認証機能とはシステムなどをユーザーが使用する際に正当性を検証する機能
- 認証基盤
- 認証基盤とはWebサービスやアプリケーションのそれぞれが持つ認証機能を一カ所に集約しているシステム
- 認証システム
- 認証機能、認証基盤などを含めたシステム全体として利用
- IDaaS
- Identity as a Serviceの略。ID(アイデンティティ)に関するサービスをSaaSで提供するサービスであり、ID認証、IDパスワード管理、シングルサインオン、アクセス制御などが提供されている
ここから本題
パターン1(モノリス時代): サービスごとで認証機能を持っている
サービスごとで認証機能を持っていて、同じ会社のサービスなのにそれぞれでアカウント登録が必要というパターン。古くからあるサービスやモノリシック・アーキテクチャ(モノリス)だと多くがこのパターンかと思います。
メリット
- 他サービスに依存せず、開発がしやすい
- カスタマイズ性が高い
デメリット
- 会社全体で見たときに非常に管理コストが高い
- 一から認証機能の開発なのでコストと時間がかかる
- それぞれのチームで同じような開発が走ってしまうのも大変問題
- セキュリティのリスクが増える
- 入口が多数あるということは、それぞれに対策が必要
サービスごとで認証機能を持っている場合、主にセキュリティリスクから認証機能の集約へ向かいますが、それぞれのアーキテクチャを吸収するあらたらしい認証基盤の開発は大変険しい道のりです。
筆者も涙無しには話ができませんのでその話は今回割愛 ?
パターン2 (モノリスからマイクロサービス移行期): 他のサービスの認証機能に相乗り
サービス内では認証機能を持たず、他のサービスのに相乗りしているパターン。
筆者の観測範囲ではスタートアップなどが新規サービスを作る際はいきなり単独で認証基盤を作ることは少ないので、将来の認証基盤を見据えてこのパターンを採用してたりします。
筆者の経験では、モノリスからマイクロサービス移行中に新規サービスを開発している時期はこの形になっていました。
メリット
- サービスごとに認証機能を開発しなくて良い
- 認証機能が濫立していないので、管理コストやセキュリティリスクを最小限に抑えられる
- (パターン1と比べて)後述のパターン3の認証基盤への導入、移行がしやすい
デメリット
- 認証機能を持っているサービスに依存
- ユーザ登録の導線が複雑になりがち
- サービスB or サービスCを利用するために、なぜかサービスAにアカウント登録が必要
この形は認証機能を持っているサービスAの機能改修が、他のサービスの思わぬ場所に影響が出てしまうことがあり、不具合を起こさないよう慎重になり開発速度の停滞を招いていたのと、当時マイクロサービス化が進んでおり、後述のパターン3 認証基盤への移行に進みました。
パターン3(マイクロサービス時代): 認証基盤が存在する
サービス横断の認証基盤があり、それぞれのサービスと連携しているパターン。マイクロサービスを採用している場合はこのパターンになっているかと思います。
メリット
- 認証機能を一元管理できる
- 認証基盤を使うことでアカウント情報などの情報を共有できるため、ユーザーにとっても利便性が向上する
- セキュリティ対策がしやすい
デメリット
- 多くの場合は導入や移行には時間やコストがかかる
- 全サービスの認証に関わるので重要度が一番高いシステムになる
認証基盤の運用が非常に重要になってくるので、可用性やセキュリティ対策が高いレベルで求められます。
認証基盤が最重要インフラであるため、ここで障害が発生すると全サービスの障害に発展します。大きな機能改修や、言語やフレームワークのバージョンアップの際にはパターン2の構成の時よりも神経をすり減らしながら作業をしていました。
幸いにも優秀な開発者とQAチームがいたため大きな事故は起こさずに済みましたが、非常に手が出しにくいシステムになっていました。
2023年に認証システムはどうあるべきか
これまで3つのパターンの認証システムを自分たちで開発、運用してきて2023年において認証システムはどうあるべきかを考えます。
- 管理コスト、セキュリティの観点からそれぞれサービスの認証機能を集約した認証基盤は必要
- 攻撃は多様化しており、自前認証システムの運用には高度なセキュリティの知識を持った人材が必要
- 2023年には認証システムは自分たちで作らずに、IDaaS(Identity as a Service)を利用というパターンがある
自分たちで認証システムを作らずに、IDaaSの利用のメリット、デメリットについては次回に続く!!
