Identity マスターへの道 第五回 :IDaaS 導入の課題 --IDaaS活用に向けて考えたいコスト

2021-04-21 13:00

[PR]このコラムでは、セキュリティについてこれから学びたいと思う方々、アプリ開発者や、ウェブサービスを開発する方々に向けて、これから要となるアイデンティティのベーシックな情報を提供していきます。

 皆さんこんにちは!Azure Active Directory Program Manager の佐藤沙里那です。
「ID マスターへの道」の連載の5回目は、前回始まった「IDaaS 導入」がトピックです。「ID に興味はあるけれど言葉が理解しづらくてよく分からない」と思っている方や、仕組みが分かりにくくて困っている方、「これからID について学びたい」「ID をシンプルに使いたい」と考えている方は、ぜひ一緒に学んでいきましょう!

前回のおさらい: ID 管理って複雑で大変?

 前回の記事では、IDaaS の仕組みに使われる認証連携や認可連携の違いなどを扱いながら、シンプルなID の一元管理の大切さについて学びました。また、SAMLなどの技術を利用した連携にとどまるだけではなく、現状を把握した上で将来の完全なIDaaS 導入をした際のID 管理のゴール設定を検討することも重要です。この中長期的な視点でのIDaaS 利用のプランニングで必要な視点がコストだということを河野さんから教えてもらいました。今回はコストにまつわる話を考えてみたいと思います。

ID の一元化によるコスト効果って?

 前回の河野さんとの対話の中で、IDaaS を利用し、一つのID で一元管理をすることが大切だということが分かりました。しかし、この一元管理がもたらすコスト効果やメリットというのは、いったいどのように考えれば良いのでしょうか。

沙里那:ID 連携による一元管理はシンプルかつセキュリティ強度も高く、管理がしやすいということが前回の学びでよく分かりました! 中長期的なID の活用という観点でコスト効果についても考えるべきという河野さんの言葉を受け、一元管理がもたらすコスト効果について考えてみたいと思うのですが、どこから着手すればよいのか悩んでいます

河野氏:そうだね。コストを考える土台として、まずはID のライフサイクルをイメージするところから始めてみよう

沙里那:ID のライフサイクル!? ええと、まずはアカウント(ユーザー)の登録ですよね。そして次は、その登録されているユーザーが異動や結婚などで部署名や氏名といった属性情報が変更になった際の情報更新。そして、転職などによる会社を退職した際の、アカウントの停止や削除、が一連の流れになりますか?

河野氏:その通り! そして、アカウントを作ってから削除するまでのログ管理もライフサイクルの中で重要な役割を果たしているね。登録、情報更新、停止や削除、そしてログ管理の4つの視点から、アカウントごとにID を設定し管理している場合と、一つのID でそれぞれのアカウントを管理している場合の違いについて考えてみよう

新しいアカウントの登録時における違い

 ID ライフサイクルの中で最初のポイントが、新しいアカウントの登録です。ここでの違いについて整理してみよう。

河野氏:まずはスタートポイントなので、こんな図を用意してみたよ。左側がそれぞれのサービスでID を管理している場合、右は一元管理の場合だ

沙里那:一つ一つのサービスでID 管理をしている場合には、それぞれのサービスでID やパスワードを設定して登録する必要性があるんですね。これだと、設定するのにも時間がかかりそうですし、パスワードをこんなに覚えきれるのかなと不安になります。一方で、一つのID で管理している場合は、新しいサービスが増えてもID 基盤と連携されている限り、ユーザーがしなければいけない作業はほとんどないのですね!

河野氏:そうそう。沙里那さんが言うように、ユーザー側でいちいちアカウントの登録などを行う必要がないので、これらの登録にかける時間などを削減し、他の作業にあてることができるよ。また、前回のチケットで例えたように、一つのID で管理をしていることにより、サインインの際にも手間がかからずに、それぞれのアプリケーションにアクセスできることもポイントだ

沙里那:アカウント登録の時点でも、両者には、かなり違いがあるように思えます。では、異動などによるユーザー情報の変更についてはどう考えていきましょうか?

ユーザー情報の更新における違い

 ID ライフサイクルの中の最初のポイントとなるアカウント登録の際には、それぞれのアカウントでIDやパスワードを設定する場合と、一つのID でアカウント登録を設定する場合では違いがあることが分かりました。それでは、この登録されているアカウントのユーザーが異動や結婚などにより情報が更新された場合、どのような違いがあるのでしょうか。

沙里那:先ほどのアカウント登録における違いは、バラバラのIDによって管理をしている場合ではそれぞれのサービスごとにアカウント設定を行い、一つのID で管理している場合ではそのID を使ってサービスのアカウント登録を行っていたので、ユーザー情報の更新がされた場合も同様なのかなと思っています

河野氏:ふむ。それをしっかり言葉にすると、どうなるかな?

沙里那:更新されたユーザー情報をそれぞれのアカウントごとに反映するのがバラバラのID で管理している場合ですね。そして、一つのID で管理している場合は、ID 管理基盤上で情報更新したものがそれぞれの連携されているサービスに反映される……という理解です

河野氏:その理解で合っているよ。加えて、アカウントにはパスワードが基本的に存在するよね。これがもしバラバラなID で管理している場合だと、それぞれのサービスごとにパスワードが存在することになる。万一、個人情報が漏えいした場合には、全てのサービスのパスワードを変更する必要があるし、仮に15個サービスを活用していたとしたら全てのパスワードのリセットをヘルプデスクなどに問い合わせてお願いするよね。個人情報が漏えいしなかったとしても、パスワードをうっかり忘れてしまったら、同様にヘルプデスクへの問い合わせをして、パスワードリセットなどのお願いをすると思うだけど、ユーザーや扱うサービスが増えれば増えるほど、これらのヘルプデスクのコストは増すばかりだ

沙里那:確かに。パスワードは、ユーザー情報の中の重要な一つのキーポイントですもんね。バラバラのID で管理している場合には、サービスごとのパスワードリセットなどでヘルプデスクのコストなどかかることが分かりました。もし、一つのID 基盤上でアプリケーションを連携させていれば、パスワードの変更は一回で済んで、迅速に対応することができますね

河野氏:そうそう。それに、例えばAzure Active Directory は、セルフパスワードリセットという機能も持ち合わせているので、パスワードの変更・リセットをヘルプデスクに問い合わせしなくとも、ユーザーが自分で行うことができるんだ。パスワードリセットにも多要素認証などの強固な認証を必要とされているので、セキュアに、かつ、簡単にパスワードを変更できる

沙里那:おお! パスワードって覚えるのも大変ですし、もし盗難事故や漏えい事故などが起きた場合にも迅速に自分のパスワードを変更してファーストアクションをとれるのは良い点ですね

河野氏:ちなみに、いま話しているパスワードの変更については、あくまでユーザー視点なので、今度は管理者視点での違いを考えてみよう

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]