こんにちは！たつみんです。
お客様のID管理のご支援をさせていただく中でこの情報は事前に知っていただいたほうがいいなと思うことがあったので記事にします。
はじめに
組織内で利用するSaaSが増えてくるとID管理が煩雑となり、考え始めるのがOktaやMicrosoft Entra ID(旧称Azure AD)といったIDaaS(Identity as a Service)の導入かと思います。
今回はIDaaS導入を検討しているけどなにから考え始めたらいいか疑問に思っている方や情報収集をするにもイメージがつかめていないという方を対象にあらかじめ知っておくといよいことや考えておくとよいこと、そしてハマりそうなポイントをご紹介します。また、最後には簡易ではありますがIDaaSでよく登場する用語についても紹介しています。
IDaaS導入前と後の世界
ID管理の煩雑さを解消するのがIDaaSですがではどのような世界が広がるのかをまずはイメージしましょう。
IDaaS導入前
ユーザー視点
IDaaS導入前の世界では、それぞれのSaaS毎に発行されたIDとPasswordを利用したり、SaaSによっては2段階認証や2要素認証という名称でPasswordとは別の認証要素としてMFA(Multi Factor Authentication)の利用を促されることがあります。MFAはGoogle Authenticatorのようなスマートフォンアプリの導入によって実現されることが多いです。
MFAもユーザーにとってはSaaS毎に個別に管理しなければならないため煩雑となります。また、スマートフォンの機種変更時にMFAの再設定を個別に行わなければならなくなり大きな負担となることがあります。
IT管理者視点
ユーザーに対して発行しているIDとPasswordが多いため、ユーザーからのパスワードリセットの要望も利用するSaaSの数と比例して増加する傾向にあります。MFAについてもユーザーが機種変更時にうまく対応できずにリセットを要望することもあります。
IDの発行や停止・削除という観点では、IT管理者はユーザーが利用するSaaS毎にアカウントを発行し、IDとPasswordをユーザーに伝える必要があります。同様に退職者のアカウント停止・削除もSaaS毎となるため入退社が重なる時期にはその作業だけでかなりの工数を割くことがあります。
ユーザーとSaaSの関係は常に1対1であるため、例えば営業部門所属のユーザーに必ずSalesforceのアカウントを発行するような場合でも同じ操作を複数回実施する必要があります。
IDaaS導入後
ユーザー視点
ユーザーが利用するSaaSがIDaaSに集約されるので利用するIDaaSのIDとPasswordのみでよくなります。
またMFAについてもIDaaSの1箇所となるため、IDとPasswordの管理と同様に個別管理をしていた時よりもずっとシンプルとなります。
近年OktaやMicrosoft Entra ID(旧称Azure AD)ではパスワードレス認証に力を入れており普段の操作ではパスワードを全く入力しなくてよいという世界が広がっています。これによりユーザー体験も向上し、顔をPCに向けるだけ、指を指紋センサーに触れるだけで、ログインできます。
IT管理者視点
ユーザーからのパスワードやMFAのリセット要望がIDaaSだけが対象となり負担軽減が図れます。また、パスワードレス認証を推進することで限りなくパスワードリセット要望自体を減らすことができます。
IDaaSにはProvisioningという機能があり、対応しているSaaSであればあらかじめアカウントを自動的に作成することができます。これにより新入社員が多い時期でも個別に対応をしなくてよくなり負担が大きく減ります。
IDaaSにあるグループ機能を利用することでユーザーの属性ごとに自動的にグループ化をし、SaaSへの割り当てを行うことができます。例えば営業部門所属のユーザーは必ずSalesforceに、開発部門所属のユーザーは必ずJIRAを利用するような場合はIDaaS内で部署グループを作成しておきSaaSと紐づけておきます。ユーザーの属性によって自動的に部署グループに割り振りを行うことで結果としてグループに紐づいたSaaSの利用を許可したり、Provisioning対応SaaSであればアカウント発行までをまとめて行うことができます。
退職時の対応もProvisioning対応SaaSであれば、IDaaSでアカウントを停止するだけでSaaS側のアカウント停止も自動的に行われます。
Provisioningに対応していないSaaSであってもIDaaSのアカウントを停止することで新規ログインを行えないようになります。
IDaaS導入の前に考えておくこと
IDaaS導入でさまざまな課題が解決できるように感じますが、実は導入までに考えておくことがいくつかあります。この部分を飛ばしてIDaaS導入を急いでも中途半端な状態となることが多々あります。IDaaSの効果を最大化するためにも事前にしっかり考えておきましょう。
SaaSのプランについて
SaaSのIDとパスワードの管理をIDaaSで行うにはSaaS側がSSOに対応している必要があります。特にSAMLもしくはOIDCという方式に対応しているかについて確認しましょう。また、SaaSによってはSAMLやOIDCを利用する場合に上位プランやオプションプランの契約が必要な場合があります。
利用しているSaaSをリストアップして、現在の契約プランから変更が必要かどうかやそもそもSAMLやOIDCに対応しているかどうかを確認しましょう。
Provisoningについても同様でSCIMという方式に対応しているかを確認しましょう。
ID管理においてSSOやProvisioningは非常に重要になります。新しいSaaS導入を検討する場合はこれらが対応しているかを一つの基準としておくとよいでしょう。
MFAの実現のために
システムに安全にログインするにはIDとPasswordだけでは十分でないという考えが広がっており、MFAの利用が推進されています。MFAについて簡単に説明すると認証時に以下の3つの要素の内、2つ以上の要素を組み合わせましょうということです。ここで注意が必要なのは同じ要素を複数回利用してもそれはMFAとは呼べないということです。
認証の3要素
- 知識情報(あなたが知っている何か/例としてPasswordやPINコードなど)
- 所持情報(あなたが持っている何か/例としてICカードやスマートフォンアプリなど)
- 生体情報(あなた自身の何か/例として指紋や顔、静脈など)
知識情報はPasswodが代表的です。MFA実現のためには別の要素として所持情報もしくは生体情報の利用が必要です。この時に所持情報として1番よく利用されるのがスマートフォンアプリです。IDaaSでは付加価値をつけて独自のスマートフォンアプリを提供していることが多いので積極的に利用しましょう。
この時に会社貸与のスマートフォンがないため、私物スマートフォンに対してインストールを行うべきかどうかという議論がよく起こります。
この点については弊社ごのへにて論点整理を行なったブログを公開しましたのでこちらもぜひご参照ください。
IDライフサイクルについて
IDaaSではどのユーザーがどのタイミングでどのSaaSを利用するかのかというユーザーとSaaSの関連性を明らかにしておくことが非常に大事です。具体的には以下のような観点があります。
- SaaSアカウントの発行のタイミングはいつか？(入社時や部署異動、ユーザーからの申請時など)
- どのようなユーザーがどのSaaSを利用するか？(部門や役職といった属性によるかなど)
- 発行後のアカウントの変更について？(雇用形態変更や休職時や退職時、さらには退職者の再入社の場合など)
これらのIDがいつ発行され、変更され、廃止されるのかというIDライフサイクルを検討することでIDaaS上での運用方法や自動化できるポイントを見つける上でとても重要な要素です。IDaaS導入前もしくは導入時に検討しておくと良いでしょう。
SaaSユーザーの属性について
IDaaSではユーザーをグループでまとめることでさまざまな作業を効率的に行うことができます。この時にグループの管理を手動で行うこともできますが、ユーザーの属性によって自動的にグループにまとめることができるので活用しましょう。
そのためにはSaaS毎にどのようなユーザーが利用しているかを確認し、雇用形態や所属部署といった属性によってグループとしてまとめられるものがあるかどうかを検討しましょう。
会社支給端末からのみアクセスを限定したいかどうか？
SaaSはさまざまな場所や端末からのアクセスが想定されます。この時に会社支給の端末からのみアクセスさせたい場合はOktaやMicrosoft Entra ID(旧称Azure AD)ではMDM(Mobile Device Management)と連携をすることでMDM配下の端末、つまり会社支給の端末からのみアクセスをさせることが可能となります。
利用しているMDMがある場合はIDaaSとの連携が可能かどうかの確認を行いましょう。またIDaaS導入とMDMの導入を同時に行うことを検討している場合は連携できるMDMの選定や十分な工数を確保できるか確認しましょう。
よくあるハマりポイント
IDaaS導入にあたり以下がよくハマりやすいポイントです。一部これまでの話と重複する部分もありますがまとめて記載します。
- SaaS側のプランの確認と変更
- MFAとして私物スマートフォン利用する場合のユーザーへの理解
- IDaaSの中のユーザーの名前を日本語表記でなくアルファベット表記とすること
最後の日本語表記でなくアルファベット表記とすることについて以下のブログが参考となりますので是非ご参照ください。
用語
あらかじめ知っておくとよい用語を記載します。IDaaS導入や検討段階以外にも実際の設定を行ったり運用をしていく段階で必要なりそうな用語も記載しています。
- IDaaS(Identity as a Service)
ID管理・認証基盤を提供するクラウドサービス - IdP(Identity Provider)
SPに対してIDを提供するIDaaS内のひとつの要素 - SP(Service Provider)
SaaS等のユーザーに対してサービスを提供するモノ - SSO(Single Sign On)
ユーザーがIdPに一度ログインすればSPへのログインが不要となる機能・状態 - MFA(Multi Factor Authentication)
認証時に複数の要素を用いること/多要素認証と表記されることもある - OTP(One Time Password)
一度きりのパスワードのこと/SMSやEmail宛に送信されることが多い - TOTP(Time-based One-time Password)
30秒や60秒毎に切り替わるパスワード/スマートフォンアプリでの利用が多い - SAML(Security Assertion Markup Language)
IdPからSPに対してSSOを実施する際の方式のひとつ - OIDC(OpenID Connect)
IdPからSPに対してSSOを実施する際の方式のひとつ - IdP-Initiated
IdPのポータル画面を起点としてSSOを行うこと/稀に対応していないSaaSがある - SP-Initiated
SPのログイン画面を起点としてSSOを行うこと - Prvisoning
IdPからSPに対してユーザーの作成、変更や無効化を行う機能・状態/主にSCIMにより実現している状態を指すことが多い - JIT(Just In Time)
SP側にユーザーが存在しない状態でSAML SSOを実施したタイミングでSP側にユーザーを作成する機能・状態/ユーザーの更新や削除には対応していない点に注意が必要 - SCIM(System for Cross-domain Identity Management)
ユーザーをIdP上でSPに割り当てた際にユーザーをSP上で作成したり、ユーザーの変更をSPに反映させたり、IdP上でSPから割り当て解除されたユーザーをSP上で無効化したりするためのプロトコル/そのほかにもIdP上のグループをSPに反映させたりとJITと比べてより高度なユーザー管理が行える
最後に
今回ご紹介したような内容はお客様からID管理についてのご相談いただくなかでよく話題になります。特にIDaaS導入の前に考えておくことが整理されているとその後の製品選定や製品導入のフェーズがスムーズに進みやすいです。
この記事がID管理の世界の入り口に立つ人にとって役に立つことを願っています。
