2018年11月27日火曜日

IDaaSとは、何か? (7) 〜その価値とは?〜

今回は、IDaaSについて紐解く人気シリーズ「IDaaSとは何か」の最終回です。各回で、IDaaSが持つ複数の機能を掘り下げてきました。今回は、それらがどのように協調して、IDaaSとしての価値を提供するのか、見てみたいと思います。
それぞれの記事の内容を振り返り、ストーリーがつながることを確認します。


IDの一元的な保存について考える

第二回で、「保存」について説明しました。「Identityに関する情報」が、一箇所に「保存」されていていることの重要性についてです。複数の場所に保存されているのではなく、一元管理されることで、常に新しく、正しい「Identity情報」の保存と、参照が可能であることを説明しました。
一箇所に保存されていない場合には、同期の必要があったり、同期するまでは、一方が古い情報を持つことになります。一箇所に情報があれば、常にそこが正であることを保証することができます。

訪問者は誰?

第三回で、アクセスしてきた人が誰なのかを確認する、「認証」について扱いました。システム側では、アクセスしてきた人が誰なのかを同定し、その人が正しく登録済みの人であるのか確認する必要があります。それが認証です。第二回で説明した「保存」の機能で保持されている「Identity情報」と「アクセスした人」が合致しているか、様々な方法で確認します。

どのサービスを使わせるか

第四回では、認証によって判明したユーザに対して、どのようなサービスを使わせるかを管理する「認可」を扱いました。実際の運用を考えると、
  • 営業担当者には、Salesforceを使わせる
  • サポート担当者には、Zendeskを使わせる
  • 全社員に、G SuiteとSlackを使わせる。
というように、グループに対して、サービスを「認可」することができます。これは、どのユーザがどのグループに属しているかという情報が、IDaaSに「保存」されているためです。

使えるように準備する

第五回では、「プロビジョニング」について扱いました。プロビジョニングが出来ない場合は、対象サービス側の管理画面から、アカウントを作る必要がありますが、プロビジョニングに対応している場合は、連携するサービスに対して、「アカウントの作成・更新・削除」をすることが出来ます。
つまり、IDaaSにアカウントを作成し、対象サービスを認可することで、対象サービス側には、アカウントが作成されますし、認可を取り消せば、削除(あるいは無効化)されることになります。または、認可をグループで管理していれば、特定のグループに所属させることで、対象サービスにアカウントが作成され、グループから外せば、削除(あるいは無効化)されます。ここが自動化されていない場合は、運用において大きな違いがあります。

利便性とセキュリティの両立

第六回では、「シングルサインオン」について扱いました。シングルサインオン(SSO)は、利用者の側からの視点と、管理者からの視点でその意味が大きく異なります。利用者の視点に立つと、
  • 一度ログインすれば、使って良いサービスはすべて使える
  • ID/パスワードをそれぞれ別々に覚えなくても良い
という利点があります。また、管理者にとっては、ユーザが杜撰なパスワード管理をする可能性が低くなる点と、サービス利用の停止が容易である等の利点があります。

運用例にあてはめます

前回までの内容を簡単にまとめてみました。これらの機能は、それぞれ他の機能を利用する立場にあります。ここまでの説明で断片的に出ていますが、全体としてどのように動くのか、簡単な運用例にあてはめてみましょう。登場するのは、「管理者」「利用者」「IDaaS」「サービス」です。
  1. 管理者は、IDaaSに利用者のアカウントを作成する。
  2. 管理者は、IDaaSで、利用者に連携するサービスを認可する。
  3. 利用者は、IDaaSのログイン画面から、ログインする。
  4. 利用者は、サービスを利用する。
この流れを少し詳細に見てみます。1.で利用者の「Identity情報」がIDaaSに保存されます。この段階では、まだIDaaSにあるだけです。2.の認可により、プロビジョニング機能を使って、連携するサービスにアカウントが作成されます。3.では、認証機能により、ログインして、シングルサインオンにより、対象機能にログインしていることになります。これらの機能が協調することで、4.で利用者はサービスを利用することができます。では、もう少し複雑な例として、利用者が他の部署に異動する例を考えましょう。具体的な方が分かりやすいので、以下のような例を想定します。
  • 「山田太郎」が「開発部」から「営業部」に異動する。
  • 開発部では、Slackを利用する。
  • 営業部では、Salesforceを利用する。
  • 全社員が、G Suiteを利用する。
異動のタイミングでの管理者の処理から始まります。ただし、前提条件として、
  • 開発部グループには、Slackが認可されている。
  • 営業部グループには、Salesforceが認可されている。
  • 全社員グループには、G Suiteが認可されている。
という設定がされているものとします。
  1. 管理者は、IDaaS上で、開発部グループのメンバーから、山田太郎を削除する。
  2. 管理者は、IDaaS上で、営業部グループのメンバーとして、山田太郎を追加する。
  3. 山田太郎は、IDaaSのログイン画面から、ログインする。
  4. 山田太郎は、G Suite、Salesforceが利用でき、Slackが利用できない。
この流れも詳細に見てみます。1.でSlackの山田太郎アカウントは、プロビジョニング機能により、削除か無効化されます。削除か無効化としているのは、対象サービスや、IDaaSの仕様によるからです。どちらにしても、山田太郎は、Slackを使えなくなります。2.で、Salesforceに山田太郎アカウントが作成されます。これ以降は、前述の例と同様で、3.で認証機能により、ログインし、4.では、シングルサインオン機能によりG SuiteとSalesforceにはログインしている状態となっているので、そのまま利用可能です。一方で、以前は使えていたSlackは使えないということになります。

まとめ

「IDaaSとは何か」というテーマで、7回にわたってその機能について掘り下げみました。IDaaSという耳なれない言葉について、身近なものとして理解するための一助となればと思います。多くのクラウドサービスが、提供されていますが、それを有効に使うためには、クラウドサービスを管理、運用するためのサービスも必要になります。それがなければ、結局運用は破綻し、せっかく有用なサービスも使われないか、なりすましや、不正利用されることもあり得ます。
IDaaSは、ユーザにも、管理者にも非常に有用なサービスです。導入をご検討ください。弊社では、豊富な実績のあるIDaaSサービス「Gluegent Gate」を提供しています。IDaaSの必要性に納得いただけましたら、ぜひ、ご相談ください。


   Gluegent Gate

2018年11月20日火曜日

新しいGoogleサイトでなくなった機能をなんとかしたい

新しい Google サイトが公開されてからずいぶん経過しましたが、使用感はいかがでしょうか。正直、以前の Google サイトではできていたのに、新しい Google サイトでは実現できないというものが多くあると思います。
例えば、お知らせやファイルキャビネットが使えなくなったり、各種ガジェットが使えなくなったり・・・
そこで、今回は新しい Google サイトになってなくなってしまった機能を弊社でご用意している Gluegent Gadgets で実現する方法をご紹介します。

新しいGoogleサイトでは何が使えなくなったのか

以前の Google サイトと新しいGoogleサイトの比較表が Google から公開されています。
以前の Google サイトと新しい Google サイトの比較

「デザインと編成」の「テンプレート:サイト用に事前にデザインされたテンプレートを使用する」とはページ作成時に選択する「テンプレート」のことです。
テンプレートには「ウェブページ」「お知らせ」「ファイルキャビネット」「リスト」「スタートページ」が用意されていました。
弊社でご案内したことがあるお客様でもよく使われるのが「お知らせ」と「ファイルキャビネット」です。
全社ポータルのトップページには「お知らせ」の最新の投稿記事が一覧できるガジェットを置き、社員へのアナウンスを掲載するといった使い方をよくされています。
また、就業規則やドキュメント類をファイルキャビネットに置いておき、社員に共有するということをされています。
新しい Google サイトに変えたいけど、これらの機能がなくなるのは困るので、新しい Google サイトに移行できないとお悩みではないでしょうか。
ではこれから、Gluegent Gadgets で代用してみましょう。

「お知らせ」には「掲示板ガジェット」

お知らせを新しい Google ガジェットに移行するとなんとただのウェブページに変換されてしまいます。各記事は下の階層に配置されます。もちろん、投稿はできなくなります。
代わりに、掲示板ガジェットをお使いください。
上記の比較表の「ページレベルの権限」も使えなくなってしまっていますが、掲示板ガジェットは各掲示板の管理権限・投稿権限・閲覧権限がユーザー・グループ単位で設定できます。
掲示板ガジェットでは見せるべき投稿を見せるべき人に公開するということができます。

「ファイルキャビネット」には「ドライブガジェット」

新しい Google サイトではファイルキャビネットの代わりとして挿入>ドライブを使うよう案内されています。しかし、指定のフォルダのファイルをリスト状に表示しているだけです。
これだけでも十分ですが、せっかくなら検索やツリー表示ができたら嬉しいですよね。


以上、今回は一部の機能だけですが、新しい Google サイトでなくなってしまった機能を代用する Gluegent Gadgets をご紹介しました。弊社では Gluegent Gadgets をもっと利用していただくため、無償提供キャンペーンを行っております。この機会に是非ご利用をご検討ください。



2018年11月13日火曜日

今日から始めるクラウド型ワークフローGluegent Flow(マスタデータ定義)

Gluegent FlowはG Suite (旧Google Apps)やOffice 365と連携することができるクラウド型ワークフローです。
本記事では前回の記事に続いて、G Suiteをご利用している中小規模の情報システム担当者の方を対象に、
Gluegent Flowを利用するにあたって必要となる導入・準備作業について、ワークフローで利用するマスタデータ参照機能の設定をGoogle スプレッドシートを利用し、どのように行っていくか、ご説明していきます。

Gluegent Flow導入時の準備作業

Gluegent Flowをご利用いただく際に必要となる導入時の作業内容は以下の通りです。
  1. Gluegent FlowをG Suiteにインストールする
  2. 組織階層をGoogleグループで定義する
  3. 初期設定を行う
  4. ワークフローをグルーピングするための「カテゴリ」を定義する
  5. 番号の採番ルール「シーケンス」を定義する
  6. 承認時の上長を自動判別するための「ロール」を定義する
  7. マスタデータをGoogleスプレッドシートに定義する
本記事では、上記No.7の設定内容についてご説明します。

No.1〜6の内容に関しては前回までの記事をご覧ください

<前回までの記事>


マスタデータをワークフロー毎に設定した場合の課題と対処策

ワークフローが参照するマスタデータとは、申請時のフォームに配置する単一チェックやリストの参照元データのことを指します。マスタデータの例としては、業務に関する区分・種類や、自社が取り扱う商品、そして取引先情報などが挙げられます。
このようなマスタデータをワークフローで扱いたい場合、そのワークフローの申請モデルに必要なデータを設定する必要があります。
ここで、複数の申請モデルにマスタデータを設定した場合のメンテナンスとして、商品マスタに新商品が追加になったケースを考えてみましょう。通常、追加された新商品のレコードは設定済の申請モデル数だけ追加作業が発生します。また、人手で変更することになるため、確認作業も当然必要となります。修正対象の申請モデルが2~3個ならまだしも、10個以上になってくると修正作業の労力もかなり大変です。
もし、この商品マスタデータ定義が申請モデルの外部で定義でき、一括編集できるとメンテナンス作業も1回で済み、作業労力も大幅に低下させることが可能となるでしょう。これを実現するのが、Googleスプレッドシートを利用したマスタデータ定義なのです。
スプレッドシートにマスタ定義することで、データ変更対象はそのスプレッドシートに限定させることができます。また、そのシートを申請モデル側から参照させるようにすることで、データ変更が発生しても申請モデルの修正は必要ありません。
更に、通常であればマスタデータ等は基幹システムで管理しており、そのシステムで追加・変更等の作業を行った後、ワークフロー側でも利用したいこともあるかと思います。この場合、変更があった商品マスタデータを自動でスプレッドシートに反映できるような仕組みを用意しておけば、人手を介することなく、ワークフローにて自動参照ができるようになります。
※弊社では他システム上のデータをGluegent Flowで利用可能とするため、CSV・スプレッドシート同期ツールを有償オプションとしてご提供しております。ご興味のある方はお問い合わせください。

マスタデータをGoogleスプレッドシートに定義し、申請モデルから参照する方法

それでは、Gluegent Flowでマスタデータをスプレッドシートに定義していく方法について説明していきましょう。
マスタデータとしてスプレッドシート参照が可能なフォーム項目は以下の通りです。
  • リスト
  • テキストとリスト
  • 単一チェック
  • 複数チェック
  • 親子リスト(★)
  • 親子テキスト(★)
  • 親子リスト(他項目連携)(★)
    (★):ヘッダー行が必要となるフォーム項目
親子リスト系の項目は選択肢の依存関係が定義できるものです。例えば、都道府県を定義した場合、関東地方を選ぶと、東京都、神奈川県、千葉県、埼玉県、群馬県、栃木県、茨城県が絞り込まれて表示できるようなものです。

それでは、以下からスプレッドシートへのデータ定義方法について説明していきます。
まずリストや単一チェックといった親子リスト系以外のフォーム項目が参照するデータの場合、以下のようにスプレッドシートへデータのみ定義します。ヘッダー行は必要ありません。


一方、親子リスト系のフォーム項目は、ヘッダー行とデータの両方を定義します。

スプレッドシートの準備ができたら、申請モデルから参照できるように設定してみましょう。
管理者権限を持つユーザでGluegent Flowアクセス後、右上のギアマークメニュー>設定を選択します。管理画面が表示されたら、モデル一覧>新規作成ボタンを押します。
申請モデル編集画面が表示されたら、「入力フォーム」を選択後、新規フォーム項目を追加し、以下の設定を行います。
  1. タイプを選択し(①)、フォーム名を入力します(②)
  2. 選択肢設定で「スプレッドシートを定義」を選択(③)、未設定リンクをクリックし、参照先となるスプレッドシートを指定します(④)。


編集途中、プレビューボタンを押すことでどのように表示されるか確認できます。
以下にスプレッドシートが参照可能なフォーム項目の初期表示および選択時のイメージを掲載しています。まず、初期表示時は以下のようになります。
各リスト選択後、以下のような表示となります。親子リスト系の場合、種類>商品名の依存関係に従って絞り込み表示されていることが確認できると思います。
※上記例では親子リスト系のヘッダー行タイトルが表示されていますが、テンプレートのプレースホルダー表記を${親子リスト.1}のようにすれば表示させないことも可能です。詳しくはマニュアルをご確認ください。

上記のような申請モデルの設定をしておけば、分類や商品が追加となった場合、スプレッドシート編集のみで申請モデルを再編集することなく、対応可能です。
なお、追加・変更されたマスタデータは新規申請分から反映されます。承認途中のものは、申請時点のマスタデータが表示するため、変更分は反映されません。


以上、Gluegent Flowのスプレッドシートによるマスタデータ定義を中心にご紹介しました。マスタデータをスプレッドシートに定義することでデータ管理の一元化およびメンテナンス作業の効率化が実現できることがお分かりいただけたと思います。
さて、全4回を通じてGluegent Flowの初期導入時に必要となる設定作業をご説明させていただきましたがいかがでしたでしょうか。本記事に関してご不明な点がございましたら、お問い合わせフォームからお問い合わせください。



2018年11月12日月曜日

【長期ご利用事例を紹介しています】10月のまとめ

10月のGluegentシリーズのリリースや、各種情報のまとめです。



『新しい Google サイト活用キャンペーン』の募集準備中です

新しい Google サイトに対応した、Gluegent Gadgetsの一部機能を無償提供するキャンペーンの募集準備をしています。11月中に募集開始予定です。もう少々お待ち下さい。
『新しい Google サイト活用キャンペーン』予告 〜 新しい Google サイトに対応した Gluegent Gadgets を無償提供 〜

Gluegent Gateの仕様を一部変更しました

パスワード期限警告に関する仕様を一部変更しました。
AD/LDAP認証の「パスワード同期」の仕様を一部変更しました。
Gluegent Gate リリースのお知らせ(2018/10/11)

株式会社 熊谷組様 の事例をご紹介しています

弊社製品を広く長期間ご利用頂いています。
https://www.gluegent.com/customer/2018_kumagaigumi/

 Gluegent Gate

2018年11月6日火曜日

IDaaSとは、何か? (6) 〜利便性とセキュリティの両立〜

IDaaSについて紐解く人気シリーズ「IDaaSとは何か」の第6回目です。前回までで、IDaaSが持つ機能を個別の機能として捉えて、それぞれについて掘り下げてきました。一回目の記事、[IDaaSとは、何か(1)」で示した以下の機能群です。

  • 保存:Identityに関する情報を保存・管理する。
  • 認証:利用者が誰なのかを管理する。
  • 認可:利用者が許可されているサービスやリソースを管理する。
  • プロビジョニング: 利用者が許可されているサービスに対して、アカウントを管理する。

前回は、IDaaSとは、何か? (5) 〜使えるように準備する〜として、「プロビジョニング」について、見てみました。今回は、「シングルサインオン」です。


シングルサインオンってなに?

シングルサインオン(SSO)とは、「一度ログインするだけで、本来それぞれログインしなければならない複数のサービスに対し、ログインした状態になる」ということです。IDaaSの文脈で言えば、IDaaSが提供するログイン画面からログインすると、IDaaSと連携するすべてのサービスで、個別のログイン画面でログインすることなしに、サービスを利用できるということになります。
単純に考えると、「ログインIDとパスワードを入れる回数が減って楽になる」というだけのように思えますが、他にも様々なメリットがあります。ログインが一箇所だけで良いというのは、どういう意味なのでしょうか。

認証情報が一つでよい

ログインするためには、IDaaSとは、何か? (3) 〜訪問者は誰?〜で見たように、ID/パスワードに代表される、「認証情報」が必要です。その人が誰であるかを示すものと、その人しか知り得ない情報をもって、システムに対して、ログインしようとしている人が誰かを示す必要があります。
シングルサインオンを使っていない場合、複数のシステムがあると、それぞれで固有の「認証情報」が必要です。あるサービスでは、IDにメールアドレスを使うことになっているのに、別なサービスでは、システムから配布される数値をIDとしているというように、ルールが異なることがあります。また、サービス毎にパスワードポリシーが異なったり、定期的な変更が求められたり、パスワードの管理も大変です。
シングルサインオンが導入されると、これらの煩雑な認証情報の管理が一つだけで良くなります。では、この認証情報の管理が一つで良いということは、どういう意味があるのか、さらに掘り下げてみましょう。ユーザと管理者の視点から見てみます。

ユーザにとっては、利便性の向上

ユーザにとっては、覚えることも少なくて済みますし、認証情報というクリティカルな情報の管理が一つだけで良いということは、それだけ本業に専念できるということになります。ログインするという動作についても、一回で済みます。利用するサービスが増えたとしても、同様です。
つまり、一つの認証情報の管理という最小の労力をもって、有用な複数のサービスを利用できるという「利便性」が提供されるということになります。これまでは、情シスから、「新しいサービスを使うことになったので、このIDを使ってください。パスワードはしっかり管理してくださいね。」と言われていたのに、シングルサインオンを導入されると、「新しいサービスを入れましたが、いつもの認証情報でログインしてもらえれば、使えます。」というように変わります。
シングルサインの導入は、ユーザにとって大きなメリットと言えそうです。

管理者にとっては、セキュリティの強化

管理者にとっては、どうでしょうか。シングルサインオンが導入されていない場合、ユーザに、サービス毎にIDを配ったり、登録してもらったりしていたと思います。あるいは、IDaaSとは、何か? (5) 〜使えるように準備する〜でみたような「プロビジョニング」の機能がなんらかのシステムで提供されている場合は、アカウントの登録は自動的に行われるかもしれません。ただ、「認証情報」に含まれる、パスワードに代表される「その人しか知り得ない情報」は、ユーザ本人のものです。管理者も知ることはできませんし、「管理者によるなりすまし」を防ぐためには、管理者は知るべきではありません。
そのため、シングルサインオンが導入されていない場合、多くの有用なサービスを導入したとしても、「認証情報はユーザの責任で管理すること」として、サービスの数だけクリティカルな情報をユーザに管理させることになります。本業が忙しいユーザは、クリティカルな情報だとしても、管理が杜撰になり勝ちです。複数サービスでパスワードを使いまわしたり、予想可能なものにしたり、総当りを許しそうな短いものにしたり、セキュリティリスクになり得る管理方法がとられます。そのため、管理者としては、長さを指定したり、定期的な変更を強制したりしますが、効果は薄いと言えるでしょう。(参考:パスワードの定期的な変更が不要とされたことの意味とは?)
有用なサービスを多く提供したとしても、ユーザに対して、高いセキュリティを維持する責任の一旦を担わせているということになります。高いセキュリティを維持することは、ユーザの責任というようりも、情報システム管理者の責任と言えるでしょう。ユーザには本業を頑張ってもらうべきです。
シングルサインオンは、このような状況を解決することができます。シングルサインオンを提供する基盤を採用し、シングルサインオンに対応するサービスを導入することで、ユーザに過大な責任を追わせずに、高いセキュリティを維持したまま、有用なサービスを提供することができます。

次回はまとめです

今回までで、6回にわたって、IDaaSの機能について見てきました。それぞれの機能は、これまでも単機能として提供されてきたものですが、IDaaSとして、一つのサービスにまとまり、有機的に組み合わされることで、クラウドサービス当たり前時代に、必須なサービスとなっています。次回は、全体のまとめとして、これらの機能が組み合わされることでどのような意味があるのか、掘り下げてみます。

   Gluegent Gate