Oktaから内製IdPへの認証基盤移行（第1回）

はじめに

こんにちは、IT本部IT戦略部テクニカルオペレーショングループの山田です。

認証基盤は、当社のセキュリティと日々の事業活動を支える、最も重要なITインフラの一つです。こうした重要なシステムは、事業の成長や技術トレンドの変化に合わせ、常に最適な状態であり続けるための定期的な見直しが欠かせません。

このような背景から、私達は長年パートナーとして利用してきた認証基盤「Okta」について、現状の評価と今後の方向性を検討するプロジェクトを立ち上げました。

この記事は3部構成を予定しており、今回は第1回目です。それではよろしくお願いします。

私たちの目指す姿

まず前提としてお伝えしたいのは、Oktaが非常に優れたプロダクトであるということです。当社では2012年から10年以上に渡って社内の認証基盤としてOktaを使用しており、迅速なカスタマーサクセスと高度なセキュリティレベルの担保に大きく貢献してくれました。

しかし、当社の事業が成長しプロダクトが多様化するにつれて、Oktaが提供する枠組みと私たちが目指す運用との間にギャップが生じ始めるようになりました。このギャップを埋め、次のステージへ進むために、私たちは主に3つの視点で見直しを行いました。

1. ベンダーロックインの回避

1つ目は特定ベンダーへの依存度が高まること、いわゆる「ベンダーロックイン」の回避です。これはOktaに限りませんが、特定ベンダーに依存しすぎることなく、常に柔軟性と選択肢を確保しておくことは私たちの重要な方針の1つでした。

そのため既存の契約は継続しつつも、他製品との比較検討を通じて、より当社のニーズに合致し、かつ将来的な選択肢を広げられる認証基盤のあり方を検討しました。

2. コスト

2つ目はコストです。OktaのようなIDaaS（Identity as a Service）は、一般的にユーザー数に応じたサブスクリプションモデルであり、企業の成長と共にライセンス費用が増大し続けます。また当社では、国外の製品であってもニーズに合えば積極的に採用しているため、ここ数年の大幅な為替変動も、長期的なコストコントロールを考える上で大きな論点となりました。

社内のITコスト・品質を担うIT戦略部では、日々様々な施策を検討しており、全社的な認証基盤であるOktaがコストコントロールの重点対象となるのは必然でした。

3. セキュリティ技術の社内蓄積と技能伝承

最後の視点は、未来への投資としての技術蓄積です。私たちは、認証というクリティカルな技術をブラックボックス化させず、社内知見として蓄積・伝承していくことを重要な方針としました。

IDaaSのような優れたサービスを利用することは効率的ですが、その仕組みを完全にベンダーに委ねてしまうと、社内から深い知見が失われていきます。将来にわたって高いレベルのセキュリティを維持するためには、その仕組みを自社で深く理解し、かつ長期的に運用可能な認証基盤が必要だと考えました。

要件

これらの視点を持ちつつ、私たちが認証基盤で実現したい要件を「機能要件」と「非機能要件」に分けて定義し、具体的な要件へと落とし込んでいきました。

システム開発において、要件を「機能要件」と「非機能要件」に分けて定義することは、要件の抜け漏れを防ぎ、プロジェクトの全体像を明確にするための基本的なステップとなります。

機能要件 (システムが「何をするか」)

認証機能
- SAML、OIDC、OAuthといった主要な認証プロトコルに対応していることが求められます。特にOIDCは、当社のPCキッティングの仕組みにおける必須要件となります。
- そのため、一部のIDaaS製品のようにOIDCに非対応のものは、その時点で選定の対象外となりました。
サードパーティ連携
- ユーザー情報を一元管理するため、IDの源泉（Source of Truth）となる既存システムとの連携は不可欠でした。社内で利用している主要ディレクトリサービス（Active Directory）とのスムーズな連携は、運用負荷を削減する上で重要な要件でした。
IPアドレス制限
- ゼロトラストセキュリティの考え方に基づき、アクセス元のコンテキストに応じた柔軟な制御ができることは、セキュリティを確保する上で重要な要件でした。
- 例えば、信頼できる社内ネットワークからのアクセスは許可し、社外からのアクセスには多要素認証を強制する、といったポリシーをIPアドレスに応じて分離できる機能を求めていました。
API連携
- 将来的な拡張性と運用の自動化を見据え、豊富なAPIが提供されていることも重要な要件でした。
- 例えば、人事システムとAPI連携した入退社時のアカウント管理を自動化したり、内製の管理ツールを開発する際には、既存システムとの柔軟なAPI連携が不可欠です。

非機能要件 (システムが「どのように動作するか」)

可用性（SLA）
- IDaaSの主要となるIdP（Identity Provider）は高いサービス稼働率が保証されていることが求められます。そのため99.99%（フォーナイン）以上の高いサービス稼働率が保証されていることを絶対条件としました。
- 背景として、既存のOktaはIdPの基幹となるSSO（シングルサインオン）部分でのサービスダウンが一切なく、10年以上に渡り安定稼働を維持していました。これは私たちが求める最低限の品質基準となりました。
セキュリティ
- セキュリティは、ユーザーの信頼と事業継続性を守るための最重要要件です。まず、日本国内で個人情報を取り扱う全ての事業者は、個人情報保護法が定める「安全管理措置」を講じる義務があります。
- また、当社はグローバルに事業を展開しているため、欧州や米国といった現地のデータ保護や個人情報保護に関する法律や規制への準拠が求められます。
- そして万一のインシデント発生時に備え、原因究明や監査証跡として十分なログが、長期（例えば5年以上）に渡り、改ざん不可能な形で保管できることも、これらのコンプライアンス要件を満たす上で不可欠でした。
コスト
- 総所有コスト（TCO）が合理的であり、長期的な運用を見据えた価格体系であることが求められます。IDaaSは継続的に利用するものであるため、単に費用が安いだけでなく、将来のユーザー数増加や機能拡張を見越した上で、トータルコストを評価する必要がありました。
- 具体的には、導入コスト（イニシャル）と運用コスト（ランニング）の合計が、Oktaを継続利用した場合の想定費用を上回る選択肢は除外しました。また、移行に伴うイニシャルコストは2年以内にコスト削減効果で回収できることも条件としました。
サポート体制
- 自社だけで解決できない問題が発生した際に、迅速に支援を受けられるサポート体制は安定運用の生命線です。
- 日常的な疑問点は、自己解決を促すヘルプサイトやナレッジベースでカバーされていること。そして、より複雑な問題に対しては、専門のエンジニアに直接相談できる問い合わせ窓口（チャット、電話、メールなど）が提供されていることを求めました。
- 特に、事業全体に影響を及ぼすような緊急性の高い障害においては、24時間365日のサポート体制が必須となります。

他製品の評価

定義した要件を基に、Okta以外のIDaaS製品について、市場調査と技術的な評価を行いました。

今回のプロジェクトでは、最初から「内製化ありき」で進めることはせず、あくまでも中立的な視点での評価を徹底しました。具体的には、以下のプロセスで選定を進めました。

Okta以外のIDaaS製品（既製品）で要件を完全に満たすものが存在するかを評価する。
もし存在すれば、その製品を最有力候補とし、PoC（概念実証）を実施する。
要件を満たす既製品が存在しない場合に限り、「内製化」が選択肢として浮上する。

このように、既製品への乗り換えと内製化を公平な選択肢として捉え、あくまで「要件を満たせるか」という点を判断基準としました。

既製品A
- コスト面でOktaに対する価格優位性があり、PoCの有力な候補でした。
- しかし、可用性の調査を進める中で、過去の障害発生数が多く、サービスの安定稼働に懸念があることが分かりました。
- このことから当社の可用性要件（SLA 99.99%以上）を満たせないリスクがあると判断し、最終的にPoC・移行対象から外しました。
既製品B
- こちらもコスト優位性があり、候補となりました。
- しかし、評価時点（2024年夏頃）では、私たちの必須要件であるOIDC機能がまだリリースされておらず、技術的な要件を満たしていませんでした。加えて、予告期間の短いメンテナンス停止が頻繁に行われるという運用上の懸念も確認されたため、移行対象から外すこととなりました。
既製品C
- コスト面では最も優位性の高い選択肢でした。
- ただし当社がOktaで使用している認証方式（2要素認証）から別の方式へ、全面的に変更する必要があることが分かりました。これは全従業員に再設定を強いることになり、ユーザー負荷と問い合わせ対応のコストが非常に高くなることが懸念されました。
- また月数回の計画メンテナンス停止も、常時稼働を求める当社の要件とは合致せず、移行対象から外しました。
その他既製品
- その他主要なIDaaS製品についても調査しましたが、いずれも現行のOktaのコストを上回ることが見積もり段階で判明したため、PoCを行う前に移行対象外と評価しました。

合計8つ程のIDaaS製品を評価しましたが、当社の要件を全て満たすものはありませんでした。コスト面でOktaを下回る製品は、機能や可用性といったクリティカルな要件で懸念があり、一方で、機能や可用性で同等レベルの製品は、コスト面でのメリットが見込めない、という結果となりました。

この評価結果をもって、私たちは「Okta以外の既製品への移行は行わない」という判断を下しました。

Oktaの契約内容の見直し

他製品の調査と並行して、現行のOkta契約を見直すことによるコスト削減も検討しました。

具体的には、業務への影響が少ない機能や項目を洗い出し、機能の縮小やプラン変更・廃止が可能かを多角的に評価しました。

この見直しによって一定のコスト削減は見込め、他社製品への乗り換えメリットを抑える水準になりました。ただし、私たちの目的は単なるコスト削減だけではありません。冒頭で触れた目指す姿を実現するためにはこのアプローチだけでは不十分だと考えました。

内製化の決定

ここまでの検討結果を踏まえ、私たちはコスト以上に目指す姿を実現することを重視し、最終的にIDaaSの主要となるIdP機能を内製化することを決定しました。

もちろん、内製化はメリットばかりではありません。私たちが評価した内製化のメリットとデメリットを以下に紹介します。

内製化のメリット

高い柔軟性とベンダーロックインの回避
- 自社で開発・運用を行うため、ビジネス要件や業務プロセスの変化に合わせて、認証基盤の仕様や運用手順を迅速かつ柔軟に最適化できます。
- また、今回のIdPの範囲に留まらず、プロビジョニングやグループプッシュといったID管理機能についても内製化し、特定のベンダーに依存しない、自律的で拡張性の高いID管理エコシステムを構築することを目指しています。
コスト削減
- 増大し続けるITコストに対して、自社でコストコントロールができるようになります。
- ユーザー数の増減や機能の追加・変更に伴うコストインパクトを自社で完全に予測し、管理下に置けることは、財務的な観点から大きなメリットとなります。
セキュリティにおける主導権の確保
- グローバルサービスを標的とする攻撃や、自社のビジネスに不要な機能、そして複雑なサプライチェーンがもたらすリスクからシステムを切り離し、攻撃対象領域を限定させることができます。
- またシステムの内部がブラックボックスでは無くなるため、インシデント発生時もベンダーに依存することがなくなり、迅速な原因究明と対応が可能となります。
- これにより、認証という最もクリティカルな領域のセキュリティ・ガバナンスを、完全に自社のコントロール下に置くことが可能になります。
技術的知見の蓄積
- 今回の開発を通じて、IDaaSに関する高度な技術的知見と、実践的な開発・運用・ノウハウが無形の資産として社内に蓄積されます。これは、将来のセキュリティ脅威への対応力や、新たな技術を迅速に採り入れるための土台となり、持続的な組織力の向上に繋がります。

内製化のデメリット

「車輪の再発明」のリスク
- 世の中に既に存在する機能をわざわざ内製で開発することになります。
- これは「車輪の再発明」となり、業界標準の機能レベルに追いつくだけでも、多大な開発工数と時間を要する可能性があります。
開発コストと時間
- 当然ながら、自社で開発・運用を行うため、初期の開発費用（イニシャル）と、継続的な運用保守費用（ランニング）が発生します。
- 単に機能を実装するだけでなく、将来の技術変化に追随していくための継続的な投資が必要となります。
品質と安定性の確保
- 認証基盤は、全従業員の業務の根幹を支える極めて重要なシステムです。Oktaが提供する99.99%のSLAと同レベルの可用性維持が求められますが、内製でこれを実現するのは容易ではありません。
- システムの正常性監視や、予期せぬエラー発生時の原因究明・修正対応など、安定稼働を支えるための工数も常に考慮する必要があります。
運用体制とサポートの構築
- 「ログインできない」といったユーザーからの問い合わせから、システム障害発生時のエスカレーションフローまで、あらゆる事態を想定したサポート体制を自社で構築し、維持しなければなりません。
- これには、ドキュメントの整備、担当者のアサイン、インシデント対応訓練などが含まれます。
組織体制と教育コスト
- 認証基盤を内製で開発・運用し続けるには、特定の個人に依存しない、持続可能な組織体制が不可欠です。
- 担当者の退職や異動に備えるだけでなく、内製化のための技術習得や、常に進化するセキュリティ技術をキャッチアップし続けるための、継続的な学習・教育コストも発生します。

このようにデメリットやリスクも多く出てきますが、それでも私たちは、長期的なITコストのコントロールと、ベンダーロックインの回避という、それを上回るメリットを実現するために、デメリットやリスクを許容し、内製化に踏み切りました。

この決断を支えたのは、

長年のサービス開発で培われた、高いレベルの技術力と運用力
システムを安定稼働させ続ける、徹底した品質管理能力

という当社の強みがあるからこそでした。

移行計画の3つのマイルストーン

システムのリプレイス、特に今回のようなIdPというクリティカルなシステムの移行は、慎重かつ段階的に進めることが求められます。

当社では400を超えるアプリケーションがSSO連携しており、その影響は全従業員の業務に及びます。10年以上に渡り安定稼働してきたこの認証基盤を、ユーザーへの影響を最小限に、かつ安全に移行させることが本プロジェクトを成功させる必須条件です。

この大規模な移行を成功させるために、私たちは以下3つの主要なマイルストーンを設定しました。

1. 移行が必要なアプリケーションの洗い出しと基盤開発

まず、Oktaと連携している400以上の既存のアプリケーションを洗い出し、整理することから始めました。移行の要否、難易度、利用者への影響範囲などを評価し、移行の優先順位を決定しました。

その中から、移行できなければ業務継続に支障をきたすクリティカルなアプリケーションを特定し、新しいIdPで求められる機能の洗い出し（機能マッピング）を行いました。

この分析と並行して、定義した要件を満たすIdPのコア機能の開発を進めました。

2. 新しいIdPとOktaの並行稼働

ユーザーへの影響を最小限に抑えつつ、新しいIdPの安定性を検証するため、一定期間、新旧のIdPを並行稼働させました。万一のトラブル発生時にも迅速にOktaへの切り戻しができる体制を構築し、業務に与える影響を低減できるようにしました。

同時に移行作業の中で見つかるバグや機能追加については、開発側でスプリントを設け、定期的に実装をしていくことで、新しいIdP機能の成熟を進めていきました。

3. 新しいIdPへの完全移行

本記事の執筆時点ではまだこのフェーズには至っていませんが、最終的なマイルストーンは、Oktaの契約終了までに全てのSSO連携アプリケーションを新しいIdPへ移行し、Oktaを完全に撤廃することです。

既存ユーザーに認証プロセスの変更を意識させることなく、認証情報を透過的に移行する「無停止移行」を目指しています。

さいごに

今回は、長年に渡り当社の認証基盤を支えてきたOktaから内製IdPへの移行を決断した背景について、私たちが設定した3つの指針と、それに伴う要件定義や製品評価のプロセスを紹介しました。

Oktaは優れたIDaaSですが、当社を取り巻く環境の変化に対応しうる認証基盤の開発は、単なるコスト削減だけでなく、私たちが目指す姿の認証基盤を自らの手で構築し、将来の事業展開に繋げることを目的としています。

次回は、技術的な側面に焦点を当て、この内製IdPを「どうやって実現したのか」を具体的な開発プロセスなどを交えて紹介する予定です。最後までお読みいただき、ありがとうございました。