こんにちは。コーポレートシステム部の寺園です。 Sansanでは社内の基盤となるIDaaSサービスとして Okta を導入しました。今回はその導入の舞台裏を少しお届けしたいと思います。
部門のミッション
はじめに部門について簡単に紹介させていただきます。 私が所属するのはコーポレートシステム部という部門で、いわゆる情報システム部門にあたります。部のミッションとして掲げているのが「EXをシンプルにする」というものです。EXとは Employee Experience（従業員体験）のことです。
働くうえでストレスとなる要因は様々あると思いますが、その中には IT環境 も含まれると考えます。IT環境はネットワークやシステムなど複数ありますが、これらが適切に組み合わせがされていないと複雑なステップを経ないと完結出来なくなり、利用することそのものにストレスを感じるようになります。これを働くうえで負荷と感じず、意識することがないくらいシンプルにしてしまおうというのが我々のミッションになります。
AD中心の構成による問題点
まずは既存構成をご覧いただきましょう。
基本のIDマスタとなっているのはActive Directory（以下、AD）です。クラウドサービスへのログインには、SSOとしてADFSを利用しています。各サービスのアカウントは一部ID同期を使用していますが基本は手動管理です。アカウント作成における元データは、入退社情報を元にスプレッドシートに書き起こしたアカウントマスタを利用しています。お気づきの通り、この構成のままでは社員数や利用サービスの増加に比例してアカウント管理作業が煩雑になっていきます。事実、アカウント管理作業は作業量や手順の複雑さも増加しつつありました。
もうひとつの問題点が、働き方の多様化に対応出来なくなってきたことです。リモートワークなどが増えてくる一方でPCのアカウントはADに紐付いており、リモート環境ではADに接続出来ずにパスワード変更すら出来ないという状況も発生していました。これに対応するためには働く環境に依存しないインフラ構成が必要であると考えました。
IDaaS中心による構成
ADを中心にしているとADと連携可能であるサービスや同期ツールがないと連携することが出来ません。またリモートワークなどにも対応していくことを考えるとアカウントマスタがADである以上は課題が残り続けると考えました。そこで考えたのがADを中心とするのではなくIDaaSを中心に置いて組み直す構成案です。
基本のIDマスタにIDaaSを据えることで、ADに接続しないと利用出来なかったパスワード変更や、セキュリティ対策としてのMFA（多要素認証）も容易に導入出来るようになりました。また、対応サービスにもよりますがSCIM（System for Cross-Domains Identity Management）によりクラウドサービスとアカウントの同期が可能になります。そして人事システムとのシステム連携により、入退社情報からのシームレスな連携を実現することが出来るようになります。（一部AD依存しているサービスは残るため、しばらくADは残さざるを得ないのですがこれはIDaaSからの同期にて対応します）
こちらを今後の社内インフラの基本的な基盤構成と考え、IDaaSの導入を進めていくことになりました。
選定のキーとなるサービス
IDaaS製品選定の基準は色々とあるのですが、考え方の1つとして「実現したい構成に必要なサービスと連携可能か」という基準で逆算で考えました。そのキーとなるサービスの1つが Jamf Connect です。
問題点でもあったIDaaSとPCアカウントの同期についてどうしてもクリアが難しい点があります。それはMacのアカウントです。
当社では従業員用のPCとしてWindowsの他にMacが選択可能になっています。MacのアカウントをADと連携させるために従来はADバインドを使用していましたが、ADバインドはMacとの相性が悪く特にFileVaultによるトラブルが頻発していました。Jamf ConnectはMacのローカルアカウントとIdP（IDaaS）を直接連携することが出来るサービスですので、この導入により課題解決に繋げることが期待出来ると考えました。よって、これを目標の1つとして考えIDaaS自体が対応しているかという点も選定対象に含めました。（機会があればJamf Connectについては詳しく記事を書きたいと思います）
最終的な選考ポイント
経緯は上記以外にも色々とありますが、更に選考を行いOktaを採用することになりました。そして最終的な選考ポイントは冒頭の部門のミッションに関連しています。それはユーザ目線で考えたことでした。
機能的に実現したいことは他サービスでも達成可能でした。しかし実際に利用するユーザ目線で考えた時に、何をするためにどこのメニューや画面から操作すれば良いのかが直感的に理解しやすいか。つまりユーザビリティを重要視してみました。すると、他サービスではエラー画面1つ見ても、何故エラーが起きているのかが不明瞭だったりと小さいながらもストレスに感じることが分かりました。その点Oktaは画面構成が整理されており、何をすれば良いかが明確になっていると感じました。
ユーザビリティが低いと操作のためにストレスを感じるようになり、シンプルな従業員体験（EX）から遠くなってしまいます。また、この問題点は管理者目線でも問合せの増加を招くことになるため重要なポイントであると考えました。
Oktaのオカネ事情
さて、選定に必要な重要な要素と言えば価格ですがそもそもOktaっていくらかかるの？という点にも軽く触れたいと思います。先に結論を書くと決して安くはないです。
Oktaは機能単位で販売されており、この機能の組み合わせによってライセンス費用が決まります。機能のことだけで1本の記事が書けるくらい複雑なので詳細は割愛させていただきますが、以下に代表的な機能について簡単に紹介しておきます。
| 機能名 | 価格*1 | 機能 |
|---|---|---|
| Single Sign-on | $2 | 外部サービスにSSOする |
| Multi-factor Authentication | $3 | 多様なMFAが利用できるようになる |
| Universal Directory | $2 | ユーザプロフィールでカスタムフィールドが利用可能となる（プロビジョニング利用時は必須） |
| Lifecycle Management | $4 | プロビジョニング機能が利用可能となる |
それぞれの機能を採用することで何が出来て何が出来ないのかが分かりづらいというのが弱点だなと思います。またこの基本機能以外にAdaptive〜やAdvanced〜という高機能版もあり更に分かりづらくなっていきます。。。
必要な機能を必要な数量だけ購入出来るので割安になるという紹介もいくつか見受けましたが、逆にほとんどの機能が必要といった場合にはパッケージ化による割引などが無いため高額化しやすくなると感じました。
Oktaを導入してみて
こうしてOktaを導入して運用開始しました。実際に使っていく中で感じた点、気づいた点をいくつか挙げさせていただきます。
アプリケーションの設定は本当に簡単！
まずアプリケーション（連携させるサービスのこと）が既に用意されているので、追加してちょっと設定入れるだけで完了してしまいます。クラウドサービス側の設定方法も個別に設定マニュアルが用意されているのでほとんど迷うことがありません。プロビジョニングの設定も容易でわずかなステップだけで利用開始出来ました。
細やかなセキュリティ設定
グループや条件に応じてセッション時間、追加承認要求などセキュリティポリシーの細かい調整が可能です。アプリケーションレベルでもポリシーが設定出来るので特定のアプリケーションのみセキュリティレベルを高くするといった設定も可能です。
管理者画面は日本語化されていない
ユーザ画面はローカライズされているのですが、管理者画面は全くされていません。マニュアルもサポートも全て英語です。サポートは問い合わせすると早めに回答いただけるのですが、込み入った話になってくるとミーティングが必要になり、素早く細かい調整をすることは難しいと感じています。
細かい操作は画面だけでは出来ない
管理者画面での操作で基本的な対応は出来るのですが、もう少し細かい操作も行いたいと感じる場面があります。例えばグループ一括割り当てをCSVインポートで一括で出来たり、ユーザ検索でプロフィール項目を条件に検索出来たりするとさらに使い勝手が良くなると思います。
とはいえ、APIが充実しているのでそういった点を補うことが出来ています。このあたりの活用事例などもこのブログでご紹介していけたらと考えています。
これから
導入を開始したばかりで順次移行・展開を進めている最中ですので、理想の構成まではまだまだ遠い道のりです。しかしこれから先の社内インフラ基盤の中でもOktaは中核を担うサービスになりつつあると感じています。EXをシンプルにすることは簡単なようで非常に困難なことなのですが、Sansanの力を底上げしていくためには重要なことだと考えますので、これからもOktaを含めて様々なIT技術を組み合わせてミッションに向き合って行きたいと思います。
*1:2020/10時点。詳細はOkta Pricingを参照
