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

はじめに

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

今回はDeNAにおける内製IdPへの認証基盤移行プロジェクトの道のりをお届けしてきた連載の第3回・最終回となります。

これまでの記事では、第1回で既存の認証基盤からの移行の経緯と目指すべき姿についてご紹介しました。続く第2回では、内製IdPの開発体制・開発プロセスにおけるAIの活用や、認証基盤の移行で直面した技術的課題と解決策に焦点を当てて説明しています。

最終回になる本記事では、認証基盤の大規模移行が完了した後の運用フェーズで直面した課題や、AIを活用した効率化への取り組み、さらには継続的な改善活動についてご紹介します。IdP移行の完遂をゴールとせず、移行後も立ち止まることなく進化し続ける現場の姿を、本記事を通して実感していただけるのではと考えています。

IDaaSやIdPに興味のある情報システム部門の方々にとって、現実的な運用課題とその解決策、そして継続的な改善へのアプローチとして少しでも参考になれば幸いです。

内製IdPへの移行完了と直面した課題

DeNAが独自開発した内製IdPは、SAML・OIDCといったSP（Service Provider）アプリケーション（以下SPアプリ）へのシングルサインオン（SSO）や多要素認証（MFA）など、企業向けIDaaSに求められる認証・認可の機能を実装しています。

全社で利用していたOktaからの大規模な認証基盤移行は、綿密な計画とSPアプリを管理している部門の協力体制のもと、大きな混乱なく無事に完了することができ、全社的なプロジェクトとして成功を収めたと言えると考えています。しかし、大規模なシステム移行は、完了した瞬間がゴールではありません。移行直後には、想定外の運用上の課題が顕在化することがあります。

Oktaとの並行稼働

第2回でもご紹介した通り、内製IdPへの移行作業はOktaを利用した運用と並行稼働で進めていました。移行がすべて完了するまでの間、ユーザーはSPアプリにログインする際、従来通りOktaにログインして操作する形とし、その裏で内製IdPがSPアプリと認証のやり取りを行う、という方法を取っていました。（詳しい仕組みについては前回の記事をご覧ください。）

350以上あるSPアプリをすべて一斉に切り替えることができないことが理由の１つでしたが、この方法にはユーザー目線でもメリットがありました。移行作業を進める段階で内製IdPは画面も含め基本的な機能の実装は完了していました。しかしこのタイミングで内製IdPの画面をユーザーに公開してしまうと移行が完了していないアプリはOktaを利用、移行が完了しているアプリは内製IdPを利用、という形になってしまいます。すると日々アプリがOktaから内製IdPに移行されていく中で目的のアプリにログインするためにユーザーはどちらのIdPを操作しなければいけないのか混乱してしまいます。同一のIdP（この場合はOkta）内で操作を完結させることで、移行期間中におけるユーザー側の混乱を回避する意図もありました。

また、内製IdPではあらかじめ定められた利用要件（ネットワーク環境や個人情報の取り扱い有無など）に応じて標準的なアクセスポリシーを設けていました。

以下はあくまで例になりますが

社内ネットワークからのみアクセスする場合：内製IdPのログイン情報のみでSSO時に追加の認証は不要
社外ネットワークからのアクセスがある場合：内製IdPのログイン情報に加え、ワンタイムパスワードなどのMFAを要求

といった形です。移行期間中はOktaで運用していたアクセスポリシーと揃えるため、Oktaから内製IdPにSSOすることでアクセスポリシーに必要な条件を満たした、という扱いにしユーザーは従来と同じ操作でSPアプリにログインすることができていました。

IdP公開により顕在化した課題

すべてのSPアプリの移行が完了し、内製IdPの画面を公開するにあたって、公開を年始第2週としたため年末に1回、年始に1回、マニュアルや注意事項などの案内を出しました。

そして、公開後1か月半あまりは、Okta/内製IdPいずれからもSPアプリにアクセスできるようにしていましたが、内製IdPからアクセスしようとした際、先ほど説明した「Oktaから内製IdPにSSOすることでアクセスポリシーに必要な条件を満たした扱いとする」という移行期間中の暫定措置がなくなり、内製IdP上で設定されていた本来のアクセスポリシーが働くようになりました。

その結果、モバイルなど二要素認証が必要なアプリやアクセス経路において「事前にMFAの設定を」「ログイン画面の表示が変わります」など周知していたにも関わらず、今まで通りの感覚で利用しようとし、ログイントラブルに関する問い合わせが一時的に増えました。

移行ならではの光景で、MFAの登録は問い合わせの都度対応していくしかないものの、そのほかの原因としてアクセスポリシーにより安全としていた経路からもMFAを求めるようになっていました。後者の問題に関しては公開前からアクセスポリシーを一定レベルでパターン分けし、標準パターンとして共通化していたことにより影響範囲などは明確でした。

この問題については、セキュリティ部門と迅速なコミュニケーションなどを実施することにより、早期の解決を図ることができました。

ユーザー向け運用におけるAIの活用

DeNAでは常に新しいサービスやツールの導入が継続的に進められています。これにより、内製IdPに連携するSPアプリの追加対応が日々発生しています。

従来の対応プロセスでは、ユーザーからの問い合わせを起点に、要件をヒアリングし、設定に必要な情報を収集していました。このSPアプリの追加対応は、ヒアリングや設定作業1回あたりにそれなりの工数がかかる、といった運用上の課題を抱えていました。多岐にわたるアプリケーションの認証設定を理解し、適切な設定をするためには、時間と専門的な知識が必要でした。

これらの課題を解決し、定型業務の効率化を図るため、私たちはアプリの担当者（依頼者）が内製IdPにSPアプリの追加依頼をする際、依頼内容の作成支援にAIを活用することを検討しました。そしてGoogleが提供するLLMであるGeminiのGem（プロンプトによる指示やファイル等の知識を事前に設定することで特定の目的や役割に特化させたAIアシスタント）を活用することで実現しました。

具体的には、SPアプリの追加依頼をする前段階として、依頼者にはGemから問いかけられる質問に回答してもらいます。この質問の回答結果をもとにGemが必要な情報を整理し、申請フォーマットを自動生成する仕組みを構築しました。作成された申請フォーマットをそのまま依頼に貼り付けてもらうことにより、人間がゼロから申請書を作成する手間を大幅に削減し、ヒアリング漏れのリスクの低減にも繋がりました。

このAIを活用した施策によりアプリ追加の依頼をもらった時点でヒアリングする情報の大部分が確認できる状況となり、一部の細かい調整のみを人手で行う形となったことでヒアリングにかかる工数の削減も実現できました。その結果、SPアプリの導入を迅速に進めることが可能になり、新しいツールをスムーズに利用開始できるよう支援しています。

申請作成のためにGemが問いかけてくる質問例

質問から作成された申請フォーマット例

チーム内の運用におけるAIの活用

内製IdPを運用するチーム内でもAIの活用を進めています。日々のログ監視にはAWSのCloudWatchを利用しており、特定の条件に合致するログを効率的に検索するためにCloudWatch Logs Insightsを活用しています。このLogs Insightsで実行するクエリの作成プロセスにおいても、Gemを導入し効率化を図りました。

施策としてはGemから問いかけられる質問に回答するだけで、目的のログ検索クエリを生成できるツールを作成しました。

CloudWatch Logs Insights自体にも指示した内容に沿ったクエリを生成してくれる生成AIによるクエリ作成機能（Query Generator）が準備されています。当初はQuery Generatorの活用を検討していたのですが、実際の運用で利用してみたところ

指示内容を英語で記述する必要がある（英語が苦手な場合、日本語から翻訳する手間がかかる）
ツールがログの仕様を把握していないため、細かい指示を記述する必要がある

といった面で課題がありました。これらの課題に対してGemを用いることで日本語で記述が可能になり、Gemに指示をするプロンプトを通じてログの構造や詳細な仕様をAIに事前に把握させることができます。これにより、

なんのログを調べたいか（Webサーバのログ、アプリログ、など）
ログから取得したい情報は何か（IPアドレス、ユーザー名、ログの出力時間、など）
どういう条件で調べたいか（特定のユーザー名、特定のアプリケーション名、など）

という3つの質問に答えるだけで精度の高いクエリを迅速に作成できるようになり、チーム内の運用作業の効率化が実現しました。

クエリ作成のためのGemの質問例

質問から生成されたログ検索クエリ例

移行後の運用における継続的な改善活動

内製IdPへの認証基盤移行は、DeNAにとって非常に大きなプロジェクトであり、成功裏に完了しました。しかし、私たちはこの移行を終着点とは捉えていません。認証基盤は、企業のセキュリティと利便性を支え、「常に進化し続けるシステム」であるという認識のもと、移行後も継続的な改善活動に取り組んでいます。

内製IdPの公開以降、私たちは利便性向上とセキュリティ強化を両立させるために、以下のような取り組みを積極的に進めています。

セキュリティ強化:
- 資産管理システムと連携したアカウントの有効化/無効化: DeNAでは業務端末にインストールされているセキュリティツールが正しく稼働しているかのステータスを資産管理システムで管理しています。このステータスが正常な状態でない場合、内製IdPのアカウントを無効化し、是正されるまで社内システムへのアクセスを限定する仕組みを構築しました。これにより利用端末のセキュリティツールの稼働状態を正常な状態にし、セキュリティの担保につなげています。
- 内部不正対策：私物PCからのアクセス制限: 企業情報への不正アクセスリスクを軽減するため、内製IdPへのアクセス元を会社支給のPCに限定する機能を導入しました。
利便性の向上:
- ワンタイムパスワード設定時にQRコード読み取りだけでなくセットアップキーへの対応: ユーザーがMFAを設定する際の利便性を高めるため、QRコードが読み取れない環境でも手動でキーを入力できるよう、セットアップキーの表示機能を追加しました。

これらの取り組みは、内製IdPがユーザーにとって使いやすく、かつセキュアな認証基盤であり続けるための恒常的な努力の一環です。私たちは、変化するビジネス要件や新たな脅威に対応するため、常に内製IdPの機能と運用をアップデートし続けています。

おわりに

本記事では、Oktaから内製IdPへの認証基盤移行後の運用フェーズに焦点を当て、直面した課題、AIを活用した効率化、そして継続的な改善活動についてご紹介しました。大規模な認証基盤移行を成功させ、今なおAIの活用も含めたさまざまなアプローチで移行後の運用課題解決と継続的な改善への注力を続けています。

内製IdPは、今後もDeNAのビジネスを支える重要なインフラとして、さらなる発展を遂げていきます。私たちは、技術的挑戦を恐れず、常に最高のユーザー体験とセキュリティを提供することを目指し、社内外への貢献を続けてまいります。DeNAが継続的に技術的挑戦を続ける組織であり、その最前線で働くエンジニアたちの情熱と学びが、皆さまにとって少しでも有益な情報となれば幸いです。