2018年9月18日火曜日

色々なクラウドサービスとシングルサインオン(SSO)してみよう - G Suite編 -(2018年版)

弊社が提供するGluegent Gateは、シングルサインオン・ID管理・アクセス制御の機能を兼ね備えたクラウドサービスです。現在、多くのサービスが、SAML 2.0という認証連携の標準規格に対応しておりますが、Gluegent GateではこのSAML 2.0という規格を利用して様々なクラウドサービス(G Suite(旧Google Apps)、Office 365、Salesforce、Dropbox、Box、サイボウズ等)とのシングルサインオンを実現しています。認証をGluegent Gateに集約し、そこでアクセス制御を行うことにより、各種クラウドサービスを横断的にセキュリティ強化することが可能となります。

さて、今日はGluegent Gateの利用ユーザ数の中で最も多いG Suiteについてシングルサインオンを行うための設定手順についてご紹介したいと思います。

※この記事は2017年5月に公開した記事の画像を最新版にしたものです。

前提条件

まず、Gluegent GateがG Suiteとシングルサインオンできるようにするためには、以下の作業が完了している必要があります。

    <G Suiteとシングルサインオン連携するための前提条件
  1. Gluegent Gateが利用ドメインにインストール済であること
  2. Gluegent GateでG Suiteとの同期設定が完了済であること
  3. Gluegent Gateにユーザ/グループが登録済であること
  4. 認証/認可ルールが定義済であること

シングルサインオン設定手順の流れ

G Suiteとのシングルサインオンを行うための設定手順は以下の通りです。

    <シングルサインオン設定手順>
  1. Gluegent GateからIdP証明書をダウンロードする
  2. G SuiteにIdP証明書のアップロードおよび各種設定項目を入力する
以下に詳しく説明していきます。

手順1. Gluegent GateからIdP証明書をダウンロードする

Gluegent Gate管理者ユーザでGluegent Gateの管理画面にログインし、以下の作業を行います。
  1. 画面左側メニューの「システム」をクリックします。
  2. 「IdP証明書」をクリックします。
  3. 証明書一覧画面から使用中の証明書のダウンロードアイコンをクリックし、証明書をダウンロードします

手順2. G SuiteにIdP証明書のアップロードおよび各種設定項目を入力する

Gluegent Gate側で証明書をダウンロードしたら、特権管理者権限を持つユーザでG Suiteの管理コンソール画面にログインし、以下の作業を行います。

    2-1. IdP証明書アップロード
  1. 「セキュリティ」を表示し、「シングルサインオン(SSO)の設定」をクリックします
  2. 「ファイルを選択」ボタンをクリックし、先ほどダウンロードしたIdP証明書ファイルを選択後、アップロードボタンを押します
  3. 以下のようにメッセージが表示されたら完了です

    2-2. SSO設定
  1. 上記アップロード作業に引き続き、G Suiteの管理画面にて以下の表を参考に設定します。
    No.
    設定項目
    設定内容
    1
    サードパーティのIDプロパイダでSSOを設定する
    チェック
    2
    ログインページのURL
    https://auth.gluegent.net/saml/saml2/idp/SSOService.php?tenant=<domain>
    ※例えばドメインがexample.comの場合以下のURLとなりますhttps://auth.gluegent.net/saml/saml2/idp/SSOService.php?tenant= example.com
    3
    ログアウトページのURL
    https://auth.gluegent.net/saml/saml2/idp/initSLO.php?RelayState=/saml/logout.php&logout=googleapps
    4
    パスワード変更URL
    https://auth.gluegent.net/user/password.php?tenant=<domain>
    ユーザにパスワードの変更をさせない場合は以下のURLにします
    https://auth.gluegent.net/static/denied_change_password.html
    5
    ドメイン固有の発行元を使用
    チェック


  2. 入力が終わったら、保存ボタンを押します。すると以下のような画面が表示されるので、説明文を確認後、「理解して、同意します。」ボタンを押します。

設定後の確認

設定が一通り完了したら、動作確認を行ってみます。
  1. Webブラウザのプライベートモードによるウィンドウを表示し、ロケーションバーに「https://mail.google.com/a/ドメイン名」を入力し、アクセスします。
  2. 以下のようなGluegent Gateのログイン画面にリダイレクトされますので、Gluegent Gateで登録したユーザID/パスワードを入力後、ログインします。
  3. ログイン後、Gmailが表示できたら成功です。


いかがだったでしょうか。上記のような設定でG SuiteとのシングルサインオンがGluegent Gateで簡単に実現できることがお分かりいただけたかと思います。今後、他サービスであるOffice 365やSalesforceに関する設定方法についてもご紹介していきますのでお楽しみに。

 Gluegent Gate


2018年9月13日木曜日

【グループキャッシュの更新時刻が設定可能に】8月のまとめ

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



グループキャッシュ更新スケジュールの設定が可能になりました

「グループキャッシュ」の更新スケジュールをお客様の管理画面から設定することができるようになりました。
Gluegent Apps 共有アドレス帳 リリースのお知らせ(2018/08/23)
Gluegent Apps グループスケジューラ リリースのお知らせ(2018/08/28)

iOS版共有アドレス帳でプロフィール情報から電話をかけられるようになりました

プロフィール情報に電話番号が記載されている場合に、そのまま電話をかけられます。
iOS 版共有アドレス帳 リリースのお知らせ(2018/08/08)

   Gluegent Gate

2018年9月11日火曜日

今日から始めるクラウド型ワークフローGluegent Flow(インストール・初期設定)

Gluegent FlowはG Suite (旧Google Apps)やOffice 365と連携することができるクラウド型ワークフローです。本ブログをご覧頂いている方の中にもクラウド型ワークフローを使ってみたいけど導入方法や準備作業が大変なのでは?と考えている方もいらっしゃるかもしれません。
G Suiteをご利用している中小規模の情報システム担当者の方を対象に、
Gluegent Flowを利用するにあたって必要となる導入・準備作業を本ブログで数回に分けてご説明していきます。

Gluegent Flowを導入するために必要な作業とは?

Gluegent Flowをご利用いただく際に必要となる導入時の作業内容は以下となります。
  1. Gluegent FlowをG Suiteにインストールする
    • ご利用中のG SuiteドメインにGoogle Marketplaceからインストールします。
      • Gluegent Flowインストール時にお使いのクラウドサービスに応じてグループが必要となります。Googleグループが既に作成済の場合、この手順は不要です。
  2. 組織階層をGoogleグループで定義する
    • 承認者選択および承認経路の自動判定で必要となる組織階層についてGoogleグループで定義します。
  3. 初期設定を行う
    • お客様情報、システム管理者、グループ選択パネルに表示するルートグループを設定します。
  4. ワークフローをグルーピングするための「カテゴリ」を定義する
    • 「申請」「稟議」「報告」等、ワークフローをグルーピングし、アクセス権を設定するための「カテゴリ」を定義します。
  5. 承認時の上長を自動判別するための「ロール」を定義する
    • 課長、部長といった役職に対して部署毎に自動判別するための「ロール」を定義します
  6. 番号の採番ルール「シーケンス」を定義する
    • 申請毎に一意に採番される番号の採番ルールを「シーケンス」として定義します
  7. マスタデータをスプレッドシートに定義する
    • 「部門情報」、「製品情報」等、ワークフローの選択肢で取り扱いたいデータをスプレッドシートに定義します。
※本記事では、上記No.1〜3までのインストール〜初期設定について触れています。


Gluegent FlowをG Suiteドメインへインストールする

Gluegent Flowをご利用するためには、まずG Suiteへのインストールが必要です。この作業を行うには特権管理者権限ユーザが必要です。そのユーザで当社からご連絡したGluegent Flowインストール用URLにアクセスします。すると、以下のような画面が表示されますので、「INSTALL APP」ボタンを押します。

以下のような画面が表示されるので、利用規約をご確認後、同意欄にチェックをつけ、「同意」ボタンを押します。

「次へ」ボタンを押します。


「次へ」ボタンを押します。

「アプリケーションを起動」ボタンを押します。


すると、以下のようなGluegent Flow初期設定画面が表示されます。

なお、この初期設定を進めるにあたり、G SuiteドメインにGoogleグループが1件以上存在している必要があります。次節ではこのGoogleグループによる組織階層の定義方法について説明します。
(既にGoogleグループが定義済であれば、次節をスキップしていただいて構いません。)

組織階層をGoogleグループで定義する

Gluegent Flowでは、ワークフロー時の承認経路等で利用する組織階層にGoogleグループを利用します。Googleグループを利用することで、兼務を表現したり、人事異動時の組織切り替えを柔軟に行うことができます。Googleグループによる組織構成例は以下の通りです。


上図の「営業部」という組織は、Google管理コンソール>グループから以下の手順で作成します。
  1. 「営業部(sales@sample.com)」をGoogleグループで作成する
  2. 「営業部(sales@sample.com)」のグループメンバーとして「営業一課(sales_01@sample.com)」、「営業二課(sales_02@sample.com)」、「Eさん(user_e@sample.com)」を追加する
良く質問を受けますが、グループのメンバーにはGoogleアカウントの他、別のGoogleグループも追加できます。これにより、上図のような階層構造が表現できるようになります。

Gluegent Flowの初期設定を行う

Googleグループで組織定義まで完了したら、引き続きGluegent Flow初期設定画面で登録していきましょう。この画面で設定する内容は以下の通りです。

  • ご担当者情報
    • お客様情報を登録します。
  • システムユーザー
    • Gluegent FlowからG SuiteドメインへAPIアクセスする際に利用するシステムユーザーを選択します。
  • ルートグループ
    • 承認者を選択するときに表示する「グループ選択パネル(下図参照)」の1番左端に表示させる組織階層のトップを選択します。

ご担当者情報
まず、会社名、部署名、担当者名、メールアドレス、電話番号、会社規模を入力後、「個人情報保護方針」の同意欄にチェックを付けて、「ご担当者様情報を登録する」ボタンを押します。


システムユーザー/ルートグループ
続いて、システムユーザーとして特権管理者権限を持つユーザーをリスト表示しますので、その中からGluegent Flowで利用してよいユーザーを選択します。
ルートグループ設定欄では定義済Googleグループをリスト表示しますので、その中からルートグループに設定したいグループを指定します。
選択できたら登録ボタンを押します。


 初期設定登録内容でチェックが通れば、G Suiteドメイン内のアカウント/グループ情報を取得します。取得処理中、以下の画面が表示されます。

取得が完了したら、以下の画面が表示されるので「アプリケーションを開始する」ボタンを押します。

Gluegent Flowのタスク一覧画面が表示されます。ここまで表示できれば初期設定まで完了しています。


以上、Gluegent Flowのインストールおよび初期設定についてご紹介しました。初期設定まで完了したら、後はカテゴリ/ロール/シーケンス等の設定をGluegent Flow管理画面を通じて行っていくことになります。この設定方法については、また来月以降に本ブログで触れていきたいと思いますのでお楽しみに!



2018年9月4日火曜日

IDaaSとは、何か? (3) 〜訪問者は誰?〜

前々回の記事、[IDaaSとは、何か(1)」で、IDaaSには、以下の機能があるとご紹介しました。

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

前回は、「IDaaSとは、何か? (2) 〜IDの一元的な保存について考える〜」として、「保存」についてみてみました。今回は、「認証」です。



あなたは誰ですか?

「認証」とは何でしょうか。端的に言えば、「アクセスしている人が誰なのかを明らかにすること」です。通常、クラウドサービスは、広くインターネット全体に入り口を公開しています。この入り口(ログイン画面)に来た人が、誰なのかがわからなければ、サービスを利用させることは出来ませんし、その利用者向けの情報を保持していたとしても、提供することができません。
また、次回見る予定の「認可」でも、相手が誰なのかわからなければ、誰に何を認可して良いのかわかりません。すべての人に同一のサービスを提供するというものでもない限り、情報システムでは、利用者が誰であるかを明らかにする、「認証」という機能は必須ということになります。

何をもって、「誰」なのかを証明するか

では、サービス側に登録済みの利用者であることを、どのように確認するのでしょうか。最も一般的なのは、「id」と「パスワード」です。「id」は、重複のないそのシステムでユニークな「名前」と言えます。「パスワード」はその利用者しか知らない前提の文字列です。この2つの組み合わせをログイン画面で入力させることにより、「利用者が正しく、登録済みの誰であるか」を確認します。
ただ、「パスワード」は、前述の通り、「利用者しか知らない」ということを前提としています。そのため、これが流出してしまった場合や、容易に類推できるものである場合には、意図しない人が利用者になりすますことが可能です。パスワードが短すぎる場合や、文字種が少ない場合は、総当りで突破することも可能でしょう。ただ、人が覚えていて入力するものなので、あまり長くては覚えられなかったり、入力時にミスをしたりするため、簡単なものにしてしまうことが多いようです。

パスワード認証の高度化

パスワードは、「認証」機能の基本ですが、前項で述べたとおり、様々な観点で鉄壁のセキュリティとは言い難い仕組みです。IDaaSが備える「認証」機能は、いくつかの仕組みで、パスワードの弱いところを保管していることが多いようです。
利用者が脆弱なパスワードを使うことを防ぐために、パスワードに設定可能な文字種や文字数をポリシーとして設定できれば、パスワード自体を一定以上の強度に保てます。
また、流出に気づいていないようなケースでもなりすましを防ぐために、定期的な変更を促すこともできるようになっています。ただし、昨今では、定期的な変更を促すことで、いくつかの単純なパスワードを使いまわすようになるなど、返って脆弱になるという意見もあります。これについては、パスワードの定期的な変更が不要とされたことの意味とは?で詳しく書いてみましたので、ご覧ください。
また、パスワードの総当りをできないようにするため、同一IDに対する一定回数以上の不正なパスワード入力で、そのID自体をロックするという機能もあります。
このように、人間には便利な認証方法である、「パスワード」を使うために、その認証方法は高度になってきましたが、やはり、パスワードそのものが漏れてしまった場合や、共有アカウントを使っていて、組織のみんながパスワードを知っていて、誰かが組織から離れたような場合には、どうしても不正なアクセスを許してしまいます。

パスワード以外の認証

そこで、パスワード以外の認証方法も発達してきました。方法は様々です。基本的には、IDとそれ以外の情報での組み合わせです。それ以外の情報は、「本人しか持ち得ないもの」です。パスワードは、「本人しか知らないもの」ですので、構造は一緒と言えます。ただ、知っているかどうかということは、漏れたら終わりです。そこで、「物理的に本人しか持っていないもの」として、指紋や虹彩などの生体情報を使う認証方法もあります。ただ、専用のデバイスが必要なので、あまり広くは使われていないようです。
一方で、スマートフォンなどのスマートデバイスは、今や殆どの人が肌見放さず持ち歩くようになっています。ここに目をつけて、スマートデバイス自体を「本人しか持ち得ないもの」として扱う認証方法が広く使われるようになっています。弊社が提供しているGluegent Gateでも、アプリケーションで端末独自のキーを生成することで、そのキーをもってアクセスしなければ、認証しないようにすることができます。紛失した場合には、登録されているキーを取り消すことで、第三者がアクセスすることを防ぐことができます。
このような認証方法を複数組み合わせることで、セキュリティのレベルを格段に上げることができます。IDaaSに限らず、昨今のサービスでは、それぞれで、このような認証(他要素認証)を備えていることも多くなりました。サービス側から、端す。末の電話番号に対して、六桁ほどの数値をSMSで送るというのが一般的なパターンのようです。
他にも、一定期間しか有効にならない、パスワードを一時的に生成する仕組みを提供することで、その仕組みを保有する人が、正しい人であると認証する方法(ワンタイムパスワード)など、認証方法は高度に多様化していると言えるでしょう。

アクセス制御への応用

アクセス制御という考え方は、本来、認証とは直接関係しませんが、認証を通すか通さないかという仕組みを使って、アクセス制御の機能をもたせることができます。よく使われるのが、特定のネットワークからのアクセスに限るという制御です。
前述した、パスワードやその他の認証と同様に、予め定義されたネットワークからのアクセスを認証要素として加えることができると、柔軟なアクセス制御が可能になります。例えば、
  • 社内LANからのアクセスの場合、パスワード認証のみで利用可能とする。
  • 社内LAN以外からのアクセスの場合、パスワード認証と端末認証を組み合わせた認証で利用可能とする。
というように、レベルの差をつけることが出来ます。社内のネットワークにアクセスできる時点で、その人は、社内の人間であることが担保できます。そこで、利便性を上げるために、端末認証は、はずしても良いという考え方です。
このように、認証とは、本来「あなたは誰ですか」というだけのものですが、複数の認証要素を組み合わせることで、利便性とセキュリティの高さを両立させることができます。

誰に何を使わせるか

認証機能により、使っている人が誰であることがわかるようになりました。では、その人にどのようなサービスを使わせれば良いのでしょうか。これを制御するのが、「認可」です。次回をこれを掘り下げてみましょう。

   Gluegent Gate


2018年8月28日火曜日

スプレッドシートを使ってスマートなワークフローを作ろう(2)

先日の記事でスプレッドシートと親子リストを使って、申請者情報を自動表示する方法をご紹介しました。
今回は、同じくスプレッドシートを使って、社員番号から所属部署やユーザー名・メールアドレスを自動的に表示させる方法をご紹介いたします。

◯スプレッドシートを準備する

今回は「親子テキスト」を使います。親子テキストとは親項目がテキストになっており、入力された内容に該当するものがあった場合は、子項目以下を表示するというものです。前回ご紹介したオーダーシートは1列目にメールアドレスが入力されていましたが、今回は親項目が社員番号になります。そこで、オーダーシートのデータを参照して、列を入れ替えたスプレッドシートを別に用意します。

◯IMPORTRANGE関数を使う

オーダーシートのデータはグループキャッシュに使用するため、列の入れ替えはできません。そこで、IMPORTRANGE関数を使います。IMPORTRANGE関数は別のシートの情報を参照し、対象データを表示するものです。
IMPORTRANGE
新規のスプレッドシートを作成します。
シート1のA1にIMPORTRANGE関数を入力します。第一引数にスプレッドシートのURL、第二引数にシート名・列を入力します。
初回のみ、「#REF!」になりますが、メッセージの「アクセスを許可」をクリックするとデータが表示されます。

◯QUERY関数を使う

親子テキストの親項目は社員番号ですので、マスターとして使うにはA列に社員番号が無いといけません。そこで、列の入れ替えのためにQUERY関数を使います。QUERY関数は参照元のデータを条件に見合った形で表示します。
QUERY
上記のシートに新しいシートを追加します。
シート2のA1にQUERY関数を入力します。第一引数に参照元のデータ(シート名・列)、第二引数にクエリ文を入力します。クエリ分は特に条件は無いので、Selectに続いて、表示したい列名を順に入力します。D列=社員番号が先頭に、他は元の並びで表示してほしいので、「D,A,B,C,E,F」となります。

◯マスターデータは1シート目を参照する

1シート目がIMPORTRANGEでデータ出力されたシート、2シート目がQUERYでデータ出力されたシートになっています。親子テキストのマスターデータは1シート目を参照しますので、QUERYでデータ出力された2シート目を1シート目に移動します。

◯親子テキストのマスターデータにスプレッドシートを使う

タイプが「親子テキスト」の入力フォームを作成します。選択し設定で「スプレッドシートで定義」を選択し、スプレッドシートを選択します。今回は「ログインユーザーでフィルター」のチェックはオフのままです。
これにより社員番号を入力し、一致するものがあれば、社員情報を表示します。参照元のデータはオーダーシートなので、社員番号用のスプレッドシートはメンテナンスが不要です。
※最初の画像は入力フォーム用のドキュメントを作成しています。

いかがでしたでしょうか。このように社員番号等からデータを参照する場合はこの方法を使ってみてください。


2018年8月21日火曜日

紙やExcel帳票をワークフローシステムへスムーズに移行するためのポイント


最近、稟議書、経費精算書、休暇申請等の様々な帳票を紙やExcelで作成し、社内ワークフローを回しているものの、内部統制、作業効率、テレワーク等を考慮し、ワークフローシステムへの移行を検討され始めている企業が増えてきています。



今回、そのような紙・Excel帳票からワークフローシステムへの移行を検討されている企業様が予め注意しておくべき点についてご説明したいと思います。

ワークフローシステムへ移行する際に陥りがちなケース

紙・Excel帳票をワークフローシステムへ移行する際に焦ってしまうことで陥りがちなケースをご紹介します。
  • ワークフローシステムの評価・検証で簡単な帳票レイアウトを利用する
    • 良くありがちなのが、簡単そうでシンプルな帳票から取り組もうとするケースです。例えば、項目も少なく承認ルートもシンプルな「休日申請」をベースにワークフローシステムの導入評価を行ったとします。その時点では何も問題なくスムーズに検証も終わり、本導入後に項目が多く複雑な承認ルートがある「稟議申請」を作ろうとしたところ、ワークフローシステムの制限が分かり、実現が困難であることが判明してしまいますが、運用開始後のため戻れません。
  • 既存の帳票をそのままシステム上に載せようとする
    • 紙やExcel帳票を使ったワークフローでは入力欄の他、申請・承認ルートも自由に変更可能です。特に非常に複雑な申請・承認ルートとなっている場合が多く見受けられます。そのような承認ルートをそのままワークフローシステム上で再現しようとすると、設定が複雑となり、メンテナンス負荷も上がってしまいがちです。
  • いきなり全社展開する
    • 焦って全社展開に踏み切ってしまうと、社内からの問い合わせや部署間の調整に時間がかかってしまい、その結果、スムーズな社内展開ができなくなります。
上記のような評価・移行の進め方のままでは、何かと障害も多く、すんなり移行できないのではないかと思います。

スムーズに移行作業を進めるためのポイント

数多くのお客様の移行を支援してきた弊社の観点から、以下に移行作業を進めるためのポイントをご説明します。

1. 最もよく使う、または複雑な帳票を検証対象として選定し、評価検証に取り掛かる
できるだけ利用頻度が高いものか、複雑なものをベースに、ワークフローシステムの評価・検証を行うようにします。これにより、ワークフローシステムの制限も早い段階で明確になり、ベンダーからの改善策や回避方法などの情報も得やすく、かつ、対策のための準備時間も確保しやすくなります。

2. 利用中の帳票をそのまま移行しようとせず、項目および承認ルートを整理してからシステムへ導入する
紙・Excel帳票は何かと複雑なレイアウトになりがちですが、その帳票をそのままワークフローシステム上で実現しようとすると大変な労力が掛かってしまうだけでなく、ユーザに不親切な分かりづらい入力画面になってしまう恐れがあります。
そのため、以下の観点で既存の帳票について見直してみましょう。

  • 帳票レイアウトを変更して良いか?
    • 紙・Excel帳票と全く同じレイアウトでなくても問題ない場合、ワークフローシステムに適したレイアウトに変更することを検討します。
  • 1帳票内で異なる入力内容・承認ルートが混じっていないか?
    • 別帳票に分割することができないか検討します。
  • 記入頻度が低い項目はあるか?
    • 廃止するか、入力フォーム項目をフリーテキスト欄に書かせるようにします。
  • 申請・承認ルートを整理できないか?
    • 複雑な分岐ルート等を見直し、代替可能なルートに置き換えます。
3. 運用フローの検証は少人数のメンバーから開始し、PDCAで改善する
上記1,2で作成したワークフローがきちんと運用に乗るかどうかについては、社内での検証・評価が必要です。そのための少数精鋭チームを編成し、しっかりPDCAサイクルを回して改善していきましょう。

いかがだったでしょうか。ある意味、当たり前のことかもしれませんが、まずは現状の整理から開始するほうが遠回りのようで実は近道だったりします。
なお、弊社が提供しているクラウド型ワークフローGluegent Flowでは帳票デザインをHTMLエディタやGoogleドキュメント(G Suite版)を利用することで紙帳票と同等のレイアウトが再現できます。
また、利用者も1名からご契約できますので、最初は評価検証用ユーザ分で少人数から契約し、評価検証が終わり全社展開の前に全社員分を契約するように柔軟にご利用することができます。
紙やExcel帳票のワークフローから1歩前へ進みたい情報システム部の方はぜひお問い合わせください。
お問合せはこちらからどうぞ




2018年8月14日火曜日

IDaaSとは、何か? (2) 〜IDの一元的な保存について考える〜

前回の記事では、[IDaaSとは、何か(1)」として、文字通り、どういうものを表すものなのかを探りました。今回からは、IDaaSが備える機能について、より掘り下げて見てみます。前回、IDaaSには、以下の機能があるとご紹介しました。

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

今回は「保存」です。



「何を」保存するのか

機能そのものを見る前に、まず、その対象となる「Identityに関する情報」とは、何かをはっきりさせておきます。実例を挙げてみましょう。一般的な情報としては、

  • 氏名
  • メールアドレス
  • 所属部署
  • 所属グループ
  • 役職

のような情報です。更にIDaaSでは、後に考察する「認証」や「認可」の機能で参照される以下のような情報も持っています。
  • あるサービスのアカウントID
  • あるサービスでの組織

例えば、G Suiteであれば、アカウントIDは、メールアドレスです。ただし、G Suiteで利用しているドメインのメールアドレスということになります。必ずしもIDaaSが保持するメインのメールアドレスと同一とは限りません。組織は、G Suite側で用意されている組織のどれに所属しているかを示すことになります。
サービスによっては、より付加的な情報を利用できる場合があります。G Suiteであれば、電話番号や予備のメールアドレスなどがあります。
これらが、「Identityに関する情報」と言えるでしょう。ここで挙げた例以外にも多くの情報がありますが、全部を網羅することが目的ではないので割愛します。

「保存」とは何か。一元管理の重要性

では、これらの情報を「保存」するというのはどういうことでしょうか。より分かりやすく表現するならば、保存してあるだけでなく、

Identityに関する情報を一元的に保存、管理し、問い合わせに対して、回答する

ということになります。Identityに関する情報が、一元的に保持されていない場合、情報の参照や更新が非常に煩雑になります。例えば、氏名、所属部署は人事部のDBに保持されていて、氏名、メールアドレスは、情シスが管理してるというようなケースです。結婚により氏名が変わったり、転籍により別ドメインのメールアドレスを追加するということはよくあります。
こういうイベントが発生した時、それぞれの保存場所の更新が必要になります。Identityに関する情報は、すべての情報システムに必須な情報であるため、それぞれで持っていることが往々にしてあります。ただ、情報の更新漏れがあった場合には、思わぬセキュリティリスクとなります。退職した社員のメールアドレスが無効になっていなくて、退職後もMLのメールが送信されていたというような事は起こり得ます。
しかし、一元的に管理されていて、その情報を必要としているサービスの側からの問い合わせに応える仕組みがあれば、一箇所を変えれば良いだけです。更新漏れの心配はありません。情報の更新タイミングも同一ですので、まだこっちのシステムには反映されてないというような不整合も起こりません。Identity情報は、みんなが必要とする情報ですが、分散して保存されているべきではなく、一箇所で管理されているべきです。

今、情報が分散している場合

情報が一元管理されていることの重要性が理解できました。では、今運用中の仕組みで、Identityに関する情報が分散していて、これを取りやめることが出来ない場合は、どうしたら良いのでしょうか。
理想としては、既存の情報も含めて、全ての情報を一箇所に集めて、既存システムはこれを参照するようにするのが良いでしょう。ただ、既存システムの回収が困難な場合も多いです。そのような場合でも、様々な手法で、「一元的に参照できる」ようにすることは可能です。
例えば、弊社が提供するGluegent Gateでは、既存のADを源泉として、情報を同期するオプションを提供しています。あるいは、CSVで毎日出力される情報を同期するような方法もとれます。本当に必要なのは、IDaaSに情報を問い合わせれば、常に正しいIdentity情報が得られるということです。統合できない情報が外部にあったとしても、それと連携が自動化されていれば、IDaaSとしての役割は、十分です。

一元的に保存管理されている情報は何に使われるのか

今回は、どのような情報が、どのように保存されるのかを見てみました。では、保存されている情報は何のために使われるのでしょうか。次回は、その利用のされ方を見てみたいと思います。


   Gluegent Gate


2018年8月10日金曜日

【GluegentFlow管理者UI更新】7月のまとめ

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

Gluegent Flow の管理者画面を更新しました

今年初頭から、お知らせしていたGluegent Flowの管理者画面の刷新を行いました。
一般ユーザ向け画面への大きな変更はありません。


詳細は、以下をご覧ください。マニュアルへのリンクもこちらに。

Gluegent Flowの画面が新しくなります

アイペット損害保険株式会社 様の事例をご紹介しました

Gluegent Flowをご利用いただいている、アイペット損害保険株式会社 様の導入と今後の展望について、ご紹介いただきました。

今後も、導入事例を増やしていきますので、ご期待ください。
 Gluegent Gate


2018年8月7日火曜日

スプレッドシートを使ってスマートなワークフローを作ろう

紙で回すワークフローでは、全ての入力項目は手で入力していると思います。ExcelやWordで作ったものも基本的には同様ではないでしょうか。これって、結構面倒ですよね。例えば、自分の所属部署を入力する欄があった場合、入力や選択することになると思います。これを自動化できれば嬉しいですね。
今回は、Gluegent Flowとスプレッドシートを使って、所属部署や申請者にまつわる情報を自動的に表示させ、入力を省略させる方法をご紹介いたします。

スプレッドシートを準備する

自動的に表示させるためには各ユーザーの情報が登録されているものを準備する必要があります。1列目にメールアドレス、2列目に氏名、3列目に所属部署・・・というように入力していきましょう。
実はこのスプレッドシートは「オーダーシート」として既に用意されているのです。

オーダーシート

Gluegent Flowを利用する際に「オーダーシート」というスプレッドシートを使うことができます。このオーダーシートには
・ユーザーやグループの並び順を指定する
・ユーザーやグループの名前を指定する
・プロフィール情報を追加する
という用途があります。
1列目にはメールアドレスを入力します。グループ選択パネルでの並び順はオーダーシートに入力されたメールアドレス順になります。
2列目には名前を入力します。G Suiteでは「山田太郎」と設定されていますが、Gluegent Flowを使うときには「山田部長」と表示したい場合に入力します。G Suiteで設定されたままに表示したい場合は、特に入力は不要です。
3列目以降は好きな情報を入力できます。所属部署や社員番号、内線番号、電話番号などを入力しましょう。

親子リストのマスターデータにオーダーシートを使う

並び順やプロフィール情報の表示のために作成したオーダーシートをモデルでも使いましょう。
タイプが「親子リスト」の入力フォームを作成します。選択設定で「スプレッドシートで定義」を選択し、オーダーシートを選択します。ポイントは「ログインユーザーでフィルター」のチェックをオンにすることです。

このチェックをオンにすることで、親子リストの親項目をログインユーザーのメールアドレスだけにします。オーダーシートにはメールアドレスは1人1件登録されていますので、ドロップダウンにはなりますが、他のユーザーを選択することができません。
これで各種情報を自動的に表示します。

※最初の画像は入力フォーム用のドキュメントを作成しています。

いかがでしたでしょうか。毎回同じ情報を入力させるのはユーザーにとっても負担になります。このように各ユーザーに付帯する情報を申請書に表示したい場合はこの方法を使ってみてください。



2018年7月31日火曜日

ワークフローの監査対策はどうすればいい?

社内のワークフローをペーパーレスにしてクラウド化に成功したものの、いざ内部監査や外部監査が入ったとき、どうすればいいでしょう?
クラウド型ワークフローであるGluegent Flowにはこれまでに作成された全てのタスクを一覧で出力する機能があります。この機能を使用するには「管理者」である必要があります。
「管理者」はG Suite/Office 365の管理者であるか、g-workflow-adminというグループに所属するユーザーである必要があります。
しかし、監査の担当者に管理者権限を与えるのは避けたいという声を多数いただきます。
そこで、監査対策のために、予め実施しておきたい対策をご紹介します。

ユーザー・グループの準備

監査の担当者がGluegent Flowを参照するために、G Suite/Office 365のユーザーを作成しましょう。監査の担当者はこのユーザーでログインしてワークフローを参照します。
また、監査の担当者が所属するグループを作成し、このグループのメンバーに上記で作成したユーザーを追加しましょう。


モデルの準備

作成されたモデルに「参照許可設定の追加自動処理」を設定します。この自動処理により作成されたタスクデータは全てタスク一覧の「参照可能」に表示されます。
作成方法は以下の通りです。

  1. モデル編集画面の「経路」をクリックします。
  2. 一番最初の経路をクリックし、「自動処理設定」をクリックします。
  3. 次に進む処理の「+」をクリックします。
  4. 「参照許可設定の追加」の「+」をクリックします。
  5. 「メンバー」の「+」をクリックし、「…」をクリックします。
  6. グループ選択パネルで上記で作成した監査用グループをチェックし、「OK」をクリックします。
  7. 「OK」をクリックします。
  8. 「保存」をクリックします。
作成された全てのモデルに同様の設定を行います。
この方法を使うと、監査の担当者には一般ユーザーの権限でも全てのタスクの内容が参照できます。

既存タスクの参照権限付与

残念ながら既に運用を開始し、多数のタスクが作成されている場合は、「タスクデータ一覧」で参照権限を付与します。
設定方法は以下の通りです。
  1. 「タスクデータ一覧」をクリックします。
  2. 表示件数を「100」に変更します。
  3. 「一括参照権限変更」をクリックします。
  4. 表の一番上のチェックボックスをオンにすると全ての行のチェックボックスがオンになります。
  5. 「選択したタスクの参照権限を変更」をクリックします。
  6. 「対象者を追加」をクリックします。
  7. グループ選択パネルで上記で作成した監査用グループをチェックし、「OK」をクリックします。
  8. 「参照権限を変更」をクリックします。

いかがでしたでしょうか。年に何度も発生する問題ではないにせよ、お問い合わせでも多数のお客様よりご相談いただく問題ですので、これを機に検討してみてはいかがでしょうか。