IDaaSで解決！検討から導入のリアル～ID環境の現状-展望から紐解く着目ポイント～
はじめに
IDaaSとは、様々なサービスのログインや点在するユーザーアカウントを集約するクラウド型認証/ID管理サービスです。
複数のクラウドサービスを有する企業では各サービスのID管理の負荷が増大し、パスワードの使いまわしによる漏洩、管理者側のIDメンテナンス漏れによるゾンビアカウント等のセキュリティホールを突かれ、いつインシデントが起きても不思議ではありません。
こうした背景からIDを一元的に管理するIDaaSは注目のソリューションです。
本記事では、IDaaSの検討にあたっての課題と、理想の連携方法を解説します。
目次
- なぜIDaaSなのか
- 企業が抱えるAs-IsとTo-Be
「多拠点運用におけるケース」
「IT戦略検討におけるケース」 - 失敗しない、IDaaS検討プロセス
- 将来のIDaaSのかたち
1. なぜIDaaSなのか
IDaaSを家屋に例えるならば、ID管理が1階、認証が2階に相当します。1階の部分が不安定だと、その上の認証設計にも影響がでてきます。
土台の部分となる1階は、現状整理に加えてこれからどのような設計をするのか、最終的な全体像をTo-Beとして描きたいのかといった設計の理想を、早い段階で具現化することが重要です。
特に、国内に多拠点を持つ企業やグローバル展開をしている企業は、各拠点のシステムや運用ルールを維持しつつ、ガバナンスを強化してくことを視野に入れ、現状を確認することをおすすめします。
「ID管理運用」は 1階に相当。 1階部分が不安定だと認証設計にも影響あり。立派な家屋も「土台」が大切
IDaaSにおいては「As-Is / To-Be の具現化」が最重要
2. 企業が抱えるAs-IsとTo-Be
IDaaS導入に際してしばしば直面する６つの課題を、「多拠点運用におけるケース」と「IT戦略検討におけるケース」の2つのグループに分けて見ていきましょう。
「多拠点運用におけるケース」
課題① IDソースの乱立・管理すべきADの把握
課題② IdP/IDaaSの乱立
課題③ 認証ポリシーの乱立
課題④ 中央拠点側にIDaaS運用が一極集中
「IT戦略検討におけるケース」
課題⑤ 既存IT環境とどう連携していくべきか？
課題⑥ 特定部門でのSaaS利用が増加しているが...
課題① IDソースの乱立・管理すべきADの把握
まずは多拠点運用、とりわけグローバルで複数の拠点で事業を展開している企業や、グループ会社を複数有している企業が抱える課題です。
IDやパスワードの管理において主にADが利用されており、本社グループにあるADは本社側で管理者が運用しています。
一方、海外拠点は拠点ごとの管理者になっていたり、国内で展開する企業でもグループ会社では別の管理者が運用管理しているケースが多数あります。
国内と海外でSaaSを別々に運用管理しているというケースも多く見受けられます。
下図のように、各拠点が持つユーザー名、アカウント情報の管理に加えて、拠点ごとに持っている属性情報やSaaS連携情報はバラバラです。
各拠点のユーザー情報がバラバラの状態では、DX推進を図るためにグループ全体で新たなITツールやサービスを展開する際に、多大な時間を要し展開スピードの阻害要因になりえます。
こういった状況を踏まえて、IDaaS上で各拠点のID情報の統合管理するアプローチをおすすめします。
統合管理とは、IDソースの運用管理を各拠点が維持した状態で、グループ全体としてIDのプロファイル情報を一つに統合することです。
IDaaSを導入し、各拠点の持つIDソースをIDaaSに連携し、各ユーザー情報をIDaaS上のマッピング機能を用いてマージすることでIDプロファイル情報を１つに統合します。
事前にIDソースの事前統合をすることなく、簡単に連携できることがポイントです。
さらに、IDaaSに連携するユーザー情報は必要な情報のみを集約することが可能な製品もあるため、各IDソース側から不要なユーザー情報を集めてしまうこともありません。
課題② IdP/IDaaSの乱立
拠点ごとにIdPやIDaaSを既に展開されているケースも最近では珍しくありません。
例えば、IdP、IDaaSで運用していても一部拠点ではAzureADを使用していたり、未導入の拠点もあるというケースも考えられます。
M&Aを推進する企業においては、新たな合併先のIdPといかに連携させるかがグループ共通のサービスを展開するにあたっての課題になるでしょう。
グループ共通SaaSが各拠点で導入済みのIdPと連携ができれば問題ありません。
しかし、一般的にSaaS製品は1SaaSに対して、1IdPと連携する仕様のものが多いです。そういった場合、どのような構成を組むかが一つの課題となるでしょう。
IDaaSをハブに位置づけ、各拠点が持つIdP、IDaaSの運用環境はそのままというケースがあります。
さらに、グループ共通サービスを使うユーザー属性に応じて、どのIdPに認証を委任するか、中継先をIDaaS側に機能として追加することでうまく運用をしているという事例です。
ポイントとしては、現状のIdP環境を維持しつつ、簡単な追加設定で連携を加速できること、その結果グループ共通SaaSを早期に展開できるという強みがあります。
また、これらは既存のグループ企業だけではなく、新たにチームに加わった企業に自社のサービスを使用してもらいたいというケースでも同様に行うことができるため、
M＆Aやグループの再編成などに対しても早期対応が可能です。
課題③ 認証ポリシーの乱立
国内において、グループ共通のSaaSを使用する場合はIDaaSでコントロールし、強固なグループ共通アクセスポリシーを適用させることができます。
一方で、海外拠点においては、海外拠点だけが使うSaaSに対してどのようなアクセスポリシーで認証させているのか、ブラックボックスになっている場合があります。
ガバナンスを効かせるという観点では、グループ共通のポリシーをしっかりと割り当て、定期的に監視し、各拠点の運用者とコミュニケーションをとる必要があります。
しかし、こういった一連の運用が、現実としてうまく機能していないことがあります。
IDaaSの製品によっては、連携先のテナントで割り当てているアクセスポリシーを確認し、どういった独自ポリシーを設定しているのかを定期的にチェックすることができます。
海外のテナントで割り当てた独自の認証ポリシーがグループ共通ポリシーに準拠していなかった場合、テナントの管理者に是正通知を行うことも可能です。
各拠点間でのマニュアル対応は不要となり、システム間で自動連携により定期的なチェックができます。
加えて、グループ共通で使うサービスだけではなく、各拠点が独自で使うサービスについてもポリシー監視ができることが最大の強みです。
課題④ 中央拠点側にIDaaS運用が一極集中
＼IDaaSで解決！検討から導入のリアル～ID環境の現状-展望から紐解く着目ポイント～の続きを読みたい方／
＼関連資料：IDaaS選定ガイド #IDaaSに必要な４つのポイントを読みたい方はこちら／
