IDのライフサイクルを考慮したSaaSの導入

どうも、takeru55555(@takeru55555)です。
この記事はGYOMUハック/業務ハック Advent Calendar 2019の12/14の回として書かせていただいております。
みなさん業務をより良くするための素晴らしいノウハウを書いてくださっているため、今回は少し視点を変えてIDのライフサイクルを念頭に、どのようにSaaSを導入すべきかという観点で書きたいと思います。

今回お伝えしたいこと

IDのライフサイクルに合わせてSaaSの導入を行うとセキュリティの向上が望め、また副次的には利便性の向上も望めます。
そもそもIDのライフサイクルとは？何を考慮すべきか？誰が担当すべきか？という点について、私の考えをお伝えしたいと思います。

IDのライフサイクルとは

会社に所属する人には入社、部署変更、昇進、退職といった様々なイベントがあります。
これを人事データベースの観点から考えると、データベースへのユーザー追加、部署異動時に部署属性の変更、昇進時には役職の属性を変更し、退職時にはアカウントを退職扱いや無効にしたりといった対応を実施します。
これを図に書くと下記のようになります。

私は前職でとあるエンタープライズ企業に対して上記のようなIDのライフサイクルの洗い出し、SaaSの設計を実施した経験があります。
その会社では、人事データベースからActive Directoryにデータが流れ、それを起点にSaaSにプロビジョニングをかける構成だったのですが、各イベントに対して属性の設計を行いました。
グローバルカンパニーであり、かつ関係会社も複数あったため、入社、退社、部署異動、出向、転籍、アルバイトから正社員への転換、産休、休職、などそれぞれのイベントを元に、ユーザーの属性約100に対してどのような属性を与えるべきか、また、属性がどうなった時に、SaaS側でどのような動きにするかを設計しました。
IDのライフサイクルはとても奥が深く、様々なシステムが関わると非常に複雑になってきます。
もちろん上記は極端な例ですが、IDのライフサイクルを考えることはSaaSを導入する上でも重要です。その理由は後ほど説明します。

SaaS時代のID管理

今はSaaS全盛の時代。IT部門が全てのシステムを管理できる時代は終わりました。
とある調査ではIT部門のIT投資はマイナス成長、対して業務部門のIT投資は前年を上回ったというデータがあります。
これはすなわち、各部門が自らSaaSを導入する傾向がある、とも言えるのではないでしょうか。
ただし、もともとIT部門ではない業務部門主導のシステム導入ではIDの観点で考慮していないケースの方が多いのではないでしょうか。

なぜIDを守ることが重要なのか？

なぜIDのライフサイクルを考慮すべきなのでしょうか。その中でも特に退職時のことを考えると重要性が見えてきます。
業務部門のSaaSアドミンなら誰しも経験があるであろうアカウントの削除忘れ。あるあるですね。
アカウントを削除を忘れると退職したユーザーがSaaSにログオンでき、社内の情報を閲覧できてしまいます。
これはセキュリティ的に非常によろしくない。退職した人間、つまり社外のユーザーが社内のリソースにアクセスできてしまう。性悪説で考えると、やめた人間は会社に恨みを持っていて、そのアカウントをさらに別の人間に伝え、みたいなこともあるかもしれません。

ユーザーの退職時にSaaSからもアカウントを削除する、もしくはログインを不能にするという対応は非常に重要です。

IDのライフサイクルに合わたSaaS利用

それではどのように上記の対策をすれば良いのでしょうか？それは全社的なSaaSの選定基準にID管理の観点を含めることで対応が可能です。
そのためにも、下記のような対策が有効なのではないでしょうか。
・SaaSの導入基準の明確化
・SAML連携に対応するためにIDaasの導入

SaaSの導入基準の明確化

SaaSの導入基準のポリシーを会社で策定すべきです。この中にID管理の部分を盛り込んでおくべきでしょう。
会社の規模にもよるのですが、スタートアップの企業であればG Suiteを使っている会社が多いと思いますので、Googleログインに対応していることというSaaSの選定基準を設け、GoogleログインでSaaSを導入することで、退職時にGoogleでアカウントを無効にすることで、SaaSへのログインを不可にするといった、対応を行うことができます。
また、もう少し企業のフェーズが進み、セキュリティの観点を重視するとSAMLに対応していることといった選定基準を盛り込むことも有効です。
以前の記事で私のSaaSの導入基準について書きましたが、私もこの辺りを重要だと考えています。
https://note.com/takeru55555/n/nf0b37cba36c1

https://note.com/takeru55555/n/n88471608c5de

また、GoogleログインやSAML連携に対応していないSaaSを利用したい場合もあるかと思いますが、この場合はどのような方法にせよアカウント管理に責任をもつ担当者を明確にしてしっかりと管理しましょう。

SAML連携に対応するためのIDaasを導入

上記のポリシー策定時にSAML連携が必要、といった場合は、対応しているIDaasを導入すべきでしょう。これについてはSAML2.0に対応していることはもちろんですが、SCIMに対応しているとより良いです。SCIMとはサービスプロバイダーに対してアカウントのプロビジョニングをできるといったプロトコルになります。これに対応していると、入社時のアカウントプロビジョニングや部署変更時のアカウント削除などもできるようになります。

誰が担当すべきか

1については全社的にSaaSの導入を推進する部隊が策定すべきでしょう。ここは会社によって異なりますが、企業の情報システムを統括するCIOやデジタルトランスフォーメーションを推進するCDO、セキュリティを重視するのであればCSOなどが策定すべきではないでしょうか。

2については企業のインフラに責任を持つIT部門が実施すべきです。SaaSにおけるIDもまたインフラです。
たまにビジネス部門がシステムを導入しようとしてもIT部門からストップがかかるといった話を聞きます。
もしこのように業務部門とIT部門が敵対する構造を取っているとしたら、これは非常にもったいないです。
本来のIT部門の役割は業務部門をはじめ全社がいかに生産性を高めるかにコミットすることだと私は考えています。決して業務部門がやりたいことに対してNoを言う理由を考えることではありません。
IDのライフサイクルの設計をしっかりと行い、業務部門がSaaSを安全に使うためのインフラを提供することがSaaS時代におけるIT部門の一つの役割なのではないでしょうか。

まとめ

長々と書いてしまいましたがまとめると下記のようなポイントになります。
・SaaSを導入する場合は策定基準を設けるべき
・策定基準にはIDのライフサイクルを考慮したものを含めるべき
・業務部門のSaaS導入は止まらない、それをセキュリティを担保しつつ加速させるITインフラを

SaaSはビジネスを加速させるために非常に強力な手段です。私はもっと日本の企業がSaaSを使いこなす日が来ることを願っています。
そのための一つの参考情報として上記の考えがどなたかの参考になれば非常に嬉しいです。

ではまた次回。