2018年5月22日火曜日

シングルサインオン(SSO)とは?使うと何がうれしいの?

シングルサインオンとは何でしょうか?端的に表現するとすれば、「関連のない複数のサービスを一回の認証で利用可能にする仕組み」ということになるでしょう。では、そうすることで、なにが嬉しいのでしょうか。今回は、その仕組みを簡単に説明し、導入のメリットをご紹介いたします。


シングルサインオンの仕組み

冒頭で述べたとおり、シングルサインオン(英語: Single Sign-On)は、一回認証すれば、複数のサービスを利用できるようにする仕組みです。サービスAと、サービスBは、異なるプロバイダから提供されていて、なんの関わりもなく、IDやパスワードが異なるというケースでも、SSOに対応していれば、一回の認証で対象サービスでも正しく認証が済んでいて利用することができます。では、その仕組みなどのようになっているのでしょうか。ここでは、昨今のSSOの実装方式としてデファクトスタンダードと言える「SAML2.0」の仕組みを簡単にご紹介します。
SAML2.0は、多くのクラウドサービスで対応されている方式で、特定のベンダーに依存しない標準技術です。SAMLの世界の登場人物は、以下の3つと考えます。

  • サービスを提供する側(Service Provider: SP)
  • 認証を提供する側(Identity Provider: IdP)
  • 利用者

利用者がサービスを利用するまでには、以下のような経過を辿ります。

  1. 利用者がブラウザで、SPが提供するサービスのページにアクセスする。
  2. SPでは、アクセスしてきた人が正しい利用者かどうかわからないので、特定のIdPのURLを生成して、利用者に「ここで認証してきて」と伝える(ユーザのブラウザはリダイレクトされ、利用者自身は意識しません)。
  3. 利用者はリダイレクト先のIdPで、ID・パスワード等で認証を試みます。
  4. IdPは、得られた認証情報をチェックし、IdPに登録済みの特定のユーザであることを確認します。認証情報が正しい場合、利用者に「ここに戻って」と、前の工程でSPにより生成されたURLに予め設定されていたURLと正しく認証が出来たことをしめす情報を伝えます(ユーザのブラウザはリダイレクトされ、ここでも利用者自身は意識しません)。
  5. SPでは、利用者がIdPで正しく認証してきたことを確認し、サービスの利用を許可します。
このように、SPとIdPが直接やり取りするのではなく、利用者のブラウザを経由したやり取りにより、SSOが実現されます。

なぜSAML2.0がデファクトスタンダード

現在、多くのサービスがクラウドサービスとして提供され、ブラウザのみで利用されるサービスがほとんです。Googleを始めとして、Office365や、Salesforce、Dropbox、Box、Slack、Zendeskなど、様々なサービスが展開されています。これらのサービスは、専用アプリを使うものもありますが、ブラウザでも利用可能です。
さらに、サービスがクラウド上にあり、オンプレミスサービスとして社内で管理しなくなると、全部外に持って行きたくなります。SSOの方式として、エージェントを置いたり、リバースプロキシを置いたりする方式もありますが、SAML方式は、それに対応したSPであれば、ブラウザのみで他に追加の条件が不要になります。
クラウド時代にマッチした方式として、多くのクラウドサービスプロバイダが実装しているのも頷けます。

SSO導入のメリット

では、SSOを導入すると、何かいいことがあるのでしょうか。どのメリットにどのくらいの重みがあるかは、組織によって異なりますが、以下のような点が挙げられます。

  1. 利用者が認証処理を繰り替えす事なく、複数のサービスを利用できる。(利便性)
  2. 利用者が複数のサービスのID/パスワードを覚える必要がない。(利便性)
  3. 2.により、パスワードの使い回しを防ぐことができる。(セキュリティの強化)
  4. 利用者の利用停止をする場合、IdPで無効化するだけで、サービスごとに無効にしなくても良い。(利便性・セキュリティの強化)
このように、一般の利用者にとっては、その利便性が向上することで、本来自分がやるべき事に集中してもらうことができます。管理者にとっては、セキュリティの強化と、管理業務の軽減が見込めます。

IdPの立場に立つと、SSOだけだともったいない

今回は、SSOの概要と、そのメリットについて見てみました。ただ、SSOにおけるIdPの立場に立つということは、SSOだけしているのでは、もったいない大きな意味があります。その意味は、また別の機会にご紹介いたします。



   Gluegent Gate


2018年5月15日火曜日

【事例:Gluegent Flow】ワークフロー申請に締切日時を設ける

日常で運用しているワークフローの中には申請する日や時間に制限付きものがあります。例えば、有給申請はその日の10時までに申請してほしい、交通費精算は25日までに申請してほしいといったものです。そこで、このようなご要望にお応えしたGluegent Flowでの「事例」をご紹介します。

10時を過ぎたら申請を拒否したい

このお客様はお弁当の注文をワークフローで申請するよう、Gluegent Flowで申請モデルを作成していました。申請モデルの画面上に「お弁当の申請は当日10時までにお願いします」と書いていても、10時を過ぎて申請するユーザーがいて、申請したのにお弁当が届かないというトラブルになっていました。
そこで、10時を過ぎたら申請できないようなワークフローを作成したいと思い立ちました。
私達はお客様のご要望を受け、入力チェックで現在の時刻が10時を過ぎていたら申請できないような申請モデルを提案しました。以下にその内容をご説明します。

カスタムバリデーションを使う

申請モデルの入力チェック「カスタムバリデーション」はJavaScriptを使うことで柔軟な入力チェックを実現できます。
このお客様には以下のスクリプトを使うよう提案しました。
var now = new Date();    // 今の日時を取得する
var hour = now.getHours();    // 今の日時から「時間」のみを取得する
if (hour >= 10) {    // 「時間」が 10 以上だったら
    return false;     // false を返す=エラー
}    // そうでないなら=9以下だったら
return true;    // true を返す=OK
設定画面は以下の通りです。

このカスタムバリデーションを導入したことで、10時以降は申請できないため、上記のようなトラブルは起きなくなりました。

日付で制限するには?

このように、getHoursメソッドを使うことで、現在日時の「時」のみを取得できます。
同様に、毎月26日以降は交通費申請を受け付けないという申請モデルを作りたい場合は、getDateメソッドを使うといいでしょう。

いかがだったでしょうか。Gluegent Flowのカスタムバリデーションを使うことで申請に対する締切日時の設定ができることがお分かりいただけたのではないかと思います。カスタムバリデーションを利用するにはJavaScriptで記述する必要があり、その点について少し抵抗感がある方もいらっしゃるかもしれませんが、入門者向け書籍やサイト等、参考となる学習先はたくさんございます。ちょっとした工夫でお客様のやりたいことを実現できます。ぜひご利用をご検討ください。





2018年5月8日火曜日

Gluegent Gadgets の G Suite の「新しいサイト」対応について 続々報

当社が提供するGluegent Gadgets に関して、Google Sites の「新しいサイト」への対応状況は以下の記事でもご報告してきました。
今回、Google Sitesの「新しいサイト」対応版が近々リリースできることになりましたので既にご利用中の方々が気になるであろう2点に絞ってご紹介させていただきます。
※ちなみに以下は「新しいサイト」にGluegent Gadgetsを埋め込んだサンプルです。



新しいサイトへガジェットを埋め込む方法は?

前回の記事で新しいサイトへガジェットを埋め込む方法について変わる旨をお伝えしていましたが、以下にその内容をご説明します。
従来のGoogle Sitesではガジェットを挿入する場合、「挿入」>「その他のガジェット」>「URL を指定してガジェットを追加」からガジェット用URLを指定するという操作方法でしたが、「新しいサイト」では少し変わります。

埋め込み手順
1.「新しいサイト」の編集画面の右メニューから「挿入」タブの「埋め込み」を選択する

2. URL欄にガジェットURLを指定する
3. しばらく待つとページ挿入ボタンが活性化されるので押す

4. ページ編集画面にガジェットのプレビュー画面が表示されるので表示位置・サイズを調整する
5. 挿入したいガジェットの数だけ上記No.1〜4を繰り返す

上記手順No.2で指定する「ガジェットURL」は管理画面で取得します。例えば「未読メール」ガジェットを挿入したい場合は、以下の操作でURLを取得します。

URL取得手順
1. 左メニューで「未読メール」を選択する
2. 各設定項目について設定する
3. コピーボタンを押し、URLを取得する

従来のサイトから新しいサイトへガジェットを移行する方法は?

「新しいサイト」へのガジェット挿入方法は上記の説明でお分かりいただけたかと思いますが、既にガジェットをご利用中の方は「既存サイトで利用しているガジェットをどうやって新しいサイトへ移行できるのか?」と疑問を持たれたかもしれません。
単純に考えると、既存のガジェットの設定内容を確認し、管理画面でその設定内容を指定し直した上でURLを発行・コピーする、という作業を1個ずつやるのか?という心配をされた方もいるかもしれませんが、そんな心配は不要です。
今回のリリース以降、新しいサイトへ埋め込むためのURLを表示する機能を追加します。このURLを表示するには以下の操作手順を行ってください。

新サイト移行用URL取得手順
1. 既存ガジェットの右上のギアマークにマウスカーソルを合わせ、クリックするとメニューが表示されるので「新サイト移行用URL表示」を選択する


2. メニュー選択後、ガジェット上に新サイト移行用URLを表示するのでこのURLを選択・コピーする。

上記手順でURLがコピーできたら、前述の新しいサイトへ埋め込む手順に従えば、既存ガジェットと同じ設定内容で表示できるはずです。


いかがだったでしょうか。Google社から新しいサイトへの移行ツールや切替スケジュールの案内はまだ行われておらず、ヤキモキされていた方もいらっしゃるのでは?と思います。しかし、上記の通り、次回リリースからGluegent Gadgets は新しいサイトでもご利用いただけるようになりますのでご安心ください。
今回はご紹介できませんでしたが、次回リリースにはレスポンシブ対応の一部も含める予定で、今後もGluegent Gadgets は進化する計画を立てております。今後のGluegent Gadgets にご期待ください。

※リリース日が確定でき次第、以下の「お知らせ」ページでご報告致します。
Gluegent Gadgets お知らせ
※Google Sitesの「新しいサイト」対応版はGluegent Gadgets Premiumのみでのリリースとなります。



2018年5月1日火曜日

【事例:アカウント連携】社内システムの人事情報から、アカウント同期、アドレス帳まで連携する

組織には、「ヒト」や「モノ」に関する情報が様々な形で保持されています。これらの情報を効率的に社内に公開し、共有したいというご要望を多くいただきます。今回はこのような要件にお応えした「事例」をご紹介いたします。

G suiteの採用を決定

そのお客様は、グループウェアとしてG Suiteを導入することを決定されました。既存のグループウェアは、長い運用の中で作り込まれ、社内の要望にきめ細やかに対応していましたが、オンプレミスのシステムで、日々のメンテナンスのコストを考えると、クラウド化した方が良いという判断です。
このようなモチベーションは多くのお客様で共通しています。ただ中規模以上のある程度歴史のあるお客様の場合、既存の仕組みがよく出来ていて、利用者がそれに慣れていると、移行時の混乱が予想され、なかなか前に進めないこともあります。許容できる変化と許容出来ない変化をよく調べ対応する必要があります。私達の経験では、利用者の混乱は、半月も続かないことがほとんどです。

アカウントを作るための情報はどこに?

三桁を超える利用者がいる場合、G Suite単体でのアカウント管理は現実的にほぼ無理と考えた方が良いでしょう。そのお客様でも、社内にある人事情報とG Suiteのアカウントを連動させる「アカウント連携」を実現する必要があると判断されました。
この要件も多くのお客様で共通するものです。社内には何かしら「ヒト」に関する情報を保持しているシステムが存在します。それが、Active Directoryや、LDAPのようなディレクトリサービスに保存されている場合もありますし、独自に作り込まれたDBを持つ場合もあります。この持ち方は、組織ごとに千差万別です。
それに合わせて、連携方法も様々な方法が考えられますが、そのお客様は、直接アクセスできるLDAPは持っていました。一方で、そのお客様では、G Suiteだけでなく、他のサービスのアカウントも同時に管理するため、また、アクセス権限をきめ細かく管理したいということで、弊社のGluegent Gateを採用いただいています。では、どのような方法で連携したのでしょうか。

AD/LDAP連携によるアカウント同期

Gluegent Gateでは、AD・LDAPを対象としたアカウント同期の機能を提供しています。既存のADに存在するユーザを特定のグループに所属させることで、そのユーザのGoogleアカウントが作成されます。そのユーザのAD上のデータが変更された場合にも、その変更が同期されます。また、アカウントの同期だけでなく、グループの同期も可能です。AD・LDAP上でグループを使って組織構造がある場合、それをそのままGoogleの世界に持っていくことができます。
今回ご紹介しているお客様でも、アカウント同期とグループ同期で、アカウント連携を実現されました。

Gmailの連絡先は使いにくい

Gmailは優れたサービスですが、高度に作り込まれたグループウェアを利用されているお客様には、使いにくいことが多いようです。特に、メールを出す相手のメールアドレスがわからない場合に、困ります。多くのグループウェアでは、メールの送り先として、組織階層から、選ぶことができます。今回ご紹介しているお客様でも、その点で困っていました。Gmailでは、送信したことがあるユーザは自動的に「連絡先」に登録され、次回からは、候補として表示されるなどの入力支援がされますが、これも「誤送信」を助長するものとして、避けられることがあります。
先に述べた「連絡先」という機能もありますが、一括した管理がしにくい上に、階層を表す部分が狭く、使いにくいようです。
弊社では、このような問題に対応するサービスを提供しています。Gluegent Apps 共有アドレス帳では、Googleグループの構造をそのまま階層構造として表示することが可能です。このサービスは、Gluegent Gateのアカウント連携で、グループ同期が出来ていることでより大きな効果が見込めます。

アドレス帳に付加情報を表示したい

更に、Gluegent Apps 共有アドレス帳では、組織構造の表示で、表示順を変更したり、付加情報を追加して表示することも可能です。例えば、「総務部」を「営業部」より上部に表示させたり、「総務部」内でも「部長」が他の社員より上部に表示されるようにすることが可能です。また、通常Googleアカウントが持っていない情報(内線番号や旧姓など)をプロフィール欄に表示させることができます。
これらの設定は、Googleスプレッドシートで指定することになります。今回ご紹介しているお客様では、社内システムから別途出力されるCSVファイルにこれらの情報も合わせて出すように、若干の変更をしていただきました。
では、このCSVファイルをスプレッドシートに反映させるのはどうするのでしょうか。この仕組みも、弊社でご用意しています。以前の記事 「社内データを超簡単にクラウドから参照できるようにするマル秘ツール」でご紹介したツールで、同期が可能です。このツールが稼働する環境さえご用意いただければ、社内のデータをクラウドから容易に届く領域につなげることができます。

アカウント連携の完成形

以上の仕組みで、社内にあるデータを源泉として、Gluegent Gateにアカウントが同期され、SPの一つとして登録されているG Suiteにアカウント・グループが同期されます。さらに、アカウント、グループのメタ情報を階層構造で探しやすく、見やすい形で表示することができるようになりました。この例では、G Suiteのみですが、Gluegent Gateは、SSOのIdPとして複数のSPを登録でき、こちらでも、アカウント連携が出来ます。既存の社内システムをメンテナンスするだけで、新しく導入するサービスのアカウント管理ができるようになります。
今回ご紹介しているお客様の例は、珍しいものではなく、一般的によくあるパターンです。データの持ち方は千差万別だと書きましたが、必ず何らかの形で連携することが可能で、多くの実績があります。
増え続けるサービスとアカウントの管理に日々の時間を取られている管理者の皆さんは、ぜひご相談ください。




   Gluegent Gate


2018年4月24日火曜日

Gluegent Flow活用例:申請データにGoogleマップURLを付与するには?

クラウド型ワークフローであるGluegent FlowはG Suite(旧Google Apps)やOffice 365と連携し、クラウド上で様々なワークフローを実現できるサービスです。 Gluegent Flowで作成可能なワークフローのテンプレート(以降、申請モデル)では、一般的な文字・数値等の入力フォームの他、カスタムスクリプトにより入力値の変換・チェックなども定義することが可能です。そのような申請モデルの定義について、申請時に入力されたデータを元に URL を生成するにはどうすればよいか?というご質問を受けることがあります。
そこで今回は、Gluegent Flowの機能を使って、ユーザが入力した住所を元に Google マップ の住所を生成し、申請画面に出力する方法をご紹介します。

GoogleマップURL生成の実現方法

Google マップ の検索画面で住所を入力したことがある方はご存知かもしれませんが、以下のように固有のURLの後ろに検索文字列が表示されます。
https://www.google.co.jp/maps/place/東京都/...(以下略)

WebブラウザのURLロケーションバーを確認してみると「東京都」のように表示されていますが、実URLではURLエンコードされています。
例えば、下記の URL にアクセスしてみましょう。
https://www.google.co.jp/maps/place/%E6%9D%B1%E4%BA%AC%E9%83%BD
すると、WebブラウザのURLロケーションバーでは以下のように表示されるかと思います。
https://www.google.co.jp/maps/place/東京都
この URLエンコードを Gluegent Flow で実現するには、「カスタムラベル」と「入力フォームの値アップデート自動処理」を使います。

入力フォーム項目の定義

では、実際に申請モデル編集画面で入力フォーム項目を追加していきましょう。
まずは申請モデル名を「Googleマップ」とし、「入力フォーム」タブを選択し、入力フォーム項目を定義していきます。
1つ目は住所を入力するための項目を定義します。この項目のデータ種別は単行テキストに設定します。その他に設定することは特にありません。

続いて、入力された住所を変換するための項目「encode」を定義します。データ種別はカスタムラベルにします。
スクリプト欄にはJavaScript の「 encodeURIComponent 」を使い、以下のように定義します。
return encodeURIComponet( ${住所} );
これにより、前述で定義した入力フォーム項目「住所」の値ををエンコードし、その結果を表示できます。

最後に固定の URL とエンコードされた文字列を結合した値を表示するための項目を定義します。この項目はユーザによる手入力は不要なため、「経路ごとの表示」欄で経路:申請では「非表示」となるように指定します。
<経路ごとの表示設定>

自動処理の設定

続いてGoogle マップ用 URLを組み立てる処理を追加します。
まず「経路」タブを選択します。次に経路:申請の「申請」ボタンの自動処理として「入力フォームの値アップデート自動処理」を追加・定義します。
この自動処理により、GoogleマップのURLを組み立て、特定の入力フォーム値として保存することができます。


「入力フォームの値アップデート自動処理」の更新内容欄には以下を指定します。
https://www.google.co.jp/maps/place/${endode}

以上までの設定が完了した申請モデルを保存し、実際に申請してみましょう。
以下のスクリーンショットでは住所に「東京都港区南麻布」と入力し、申請されたものを経路:承認待ちで表示したものです。GoogleマップURLが表示できていることが確認できます。
このURLをクリックすると以下のようにGoogleマップが表示できます。



以上、Gluegent FlowでGoogleマップのURLを付与する方法をご紹介しました。旅費交通費申請や出張・宿泊申請など住所が関わるワークフローは色々ありますが、その申請の中に上記のようなGoogleマップURLを表示できれば、承認者・決裁者がGoogleマップにより効率的に確認できるようになります。 是非参考にしてみてください。





2018年4月17日火曜日

G Suiteと連携するクラウドワークフローの中でGluegent Flowがおすすめできる理由

クラウドグループウェアへ移行したい場合の理由は様々かと思いますが、「いつでも・どこでも」利用でき、従来出来なかったワークスタイルや効率化を実現できるようにしたいというニーズを良く聞きます。
そんな中、G SuiteやOffice 365をご利用したユーザの場合、それらのクラウドグループウェアではワークフロー機能が備わっていないため、自社で開発するか、サードパーティのサービスを選定することになります。

最近ではオンプレミス中心だったワークフロー製品もクラウド型として提供している企業も増えてきました。ただ、実際に選定・比較してみると分かるのですが、ワークフローを提供しているサードパーティーのホームページやカタログだけでは、ワークフロー自体の機能差がほとんど見つかりません。
例えば、どんな場所からも利用でき、PC・スマホ・タブレットに対応可能、様々なデータ型が扱える入力フォーム、柔軟な承認経路設定(差し戻し、スキップ等)等、一般ユーザからしてみれば、いずれも同じように見えてしまうのではないでしょうか。

今回は、そのようなG Suiteと連携するクラウドワークフローの比較・検討をされている方に対して、弊社のワークフローサービスであるGluegent Flowが他社よりお勧めできる理由を以下にご説明していきたいと思います。



Flowステータスガジェットで自分の処理対象タスクを「見える化」できる 

通常のワークフロー製品では、承認等の処理依頼・結果の通知をメールで行います。
担当者レベルではあまり問題になりませんが、大人数が所属する部署の上長の場合、ワークフローから大量のメールが届くことになり、その結果、重要な処理依頼も埋もれてしまい、後手後手になりがちです。
Gluegent FlowにはFlowステータスガジェットというものがあります。
これは自分が処理しなければならないタスクについて期限に応じて色分け表示するガジェットで、Googleサイトのガジェットで埋め込んだり、ブラウザ拡張プラグイン(Chrome/Firefox)としてGmail上で表示することで利用できます。 このガジェットがあれば、現在自分が処理しなければならないタスクが「見える化」できるようになり、緊急性の高いものや期限が迫ったものが一目で分かるようになるため、処理漏れを防ぐことができます。

スプレッドシートによるマスタデータ管理でメンテナンス業務を外出し化できる

店舗・製品マスタなど、企業では様々なマスタ情報を扱っているのが普通でしょう。
当然、ワークフローでもそのようなマスタ情報を利用したいケースも多くあると思いますが、そのデータをワークフロー内の設定値として定義すると何かとメンテナンスが大変になりがちです。
その点、Gluegent Flowではスプレッドシートに登録したデータを入力フォームのマスタデータとして参照利用する機能が備わっており、そのデータメンテナンスをワークフローと独立した形で、運用することができるので大変便利です。
これにより、マスタデータの追加・変更が発生したとしても、わざわざワークフロー編集により、修正を個別に行う必要がありません。複数のワークフローから参照するようなデータのメンテナンス時には特に効果を発揮します。
この機能をご利用中のお客様の中には、スプレッドシート同期ツール(有償)をご利用いただき、基幹システムから出力したデータをスプレッドシートに同期するようにすることで、メンテナンスフリーを実現されている方もいらっしゃいます。

参考:社内データを超簡単にクラウドから参照できるようにするマル秘ツール

Googleドキュメントによる入力フォームデザインで誰でもレイアウト編集できる

高機能なフォームエディターで複雑な帳票イメージを再現できることを強みとしているワークフロー製品もあるでしょう。しかし、そのような製品は専用アプリをPCにインストールする必要があったり、機能が多く、操作が複雑になりがちで学習コストが高くなることで一部の管理者しかレイアウト編集ができない企業様もいらっしゃるのではないでしょうか。
その点、Gluegent Flowでは複雑なレイアウトが実現できるHTMLエディタの他にGoogleドキュメントで入力フォームのレイアウトがデザインできる機能が備わっていますので、導入時の敷居も下がっています。
例えば、Googleドキュメントを用いたレイアウト編集は以下の溶操作手順は以下の通りです。
  1. Googleドキュメントで作りたい帳票イメージを作成する
  2. 入力フォームの項目名をプレースホルダ形式で埋め込む
  3. Gluegent Flowの申請モデル編集画面で上記Googleドキュメントを読み込む
  4. プレビューで確認しながら、微調整していく
上記の通り、レイアウト編集は非常にシンプルに行えるため、総務部や人事部のようなシステム部門ではない担当者の方でも可能になります。特に帳票デザインのこだわりは現場担当者のほうが強いことが多く、その意味では導入および運用面において現場担当者が扱いやすい機能と言えるのではないでしょうか。

自動処理機能でワークフローデータを使った業務を効率化できる

Gluegent Flowには承認・決裁のタイミングで実行するための様々な「自動処理」機能が備わっています。 例えば、ワークフローの経路変更、データ更新、外部WebAPI操作の他、G Suiteリソースに対して操作するものものあります。 これらを組み合わせてステップ実行形式で定義を行うことで以下のような処理が実現できます。
  • 見積承認完了時にメール送信自動処理を設定し、承認完了のタイミングで、開発部に自動でメール送信する
  • 経費精算申請に添付された領収書の画像ファイルを添付ファイルアップロード自動処理を用いて、Google Drive上の所定のフォルダ内にアップロードする
  • 経費申請データを決裁時にスプレッドシートへ出力するように「スプレッドシート行挿入/更新自動処理」を設定しておく。月末締め後、経理担当者は対象のスプレッドシートからCSVファイルでダウンロードし、経理システムへインポートする。

いかがだったでしょうか? Gluegent Flow を G Suite と連携するワークフローとしてご利用いただければ、クラウドワークフローのメリットだけでなく、普段お使いの G Suite をもっと有効活用できる印象をお持ちいただけたのではないかと思います。
なお、G Suiteとの連携面についてもまだまだ追加・改善したい機能は数多くあります。また、Office 365等の他クラウドサービスとの連携につきましても、機能追加・拡張をどんどん行っていきたいと考えています。
上記の内容につきまして、知りたいこと、気になることがございましたら、お気軽にお問い合わせください。よろしくお願いします。


お問合せはこちらからどうぞ




2018年4月10日火曜日

パスワードの定期的な変更が不要とされたことの意味とは?

先月末、セキュリティに関する興味深いニュースが広まりました。総務省が「パスワードの定期的な変更は不要」としたものです。企業の情報システムを管理されている皆さんは、これまで「パスワードは定期的な変更が推奨されている」と認識されていたと思います。今回は、この方針変更について考えてみます。

パスワードの定期的な変更が推奨されていた時代の根拠

認証が必要なサービスを利用する時に、パスワードの定期的な変更を求められることがあります。現在でも、個人で利用されるネットバンキング等では、わざわざ「パスワードが3ヶ月変更されていません」のような注意が出ることがあります。また、変更が強制された上に、過去に使ったパスワードを利用できないようにするなど、多くのシステムは、パスワードが定期的に変更されることを前提とした仕組みが備わっているようです。
そもそも、なぜ「パスワードを定期的に変える」必要があったのでしょうか。パスワードを自分以外に知られると、自分になりすまされる可能性があり、パスワードが漏洩したとしても、それが認識されていないかもしれないからです。1年前から使っているパスワードは、すでに漏れているかも知れず、自分が認識していないだけで、誰かが自分になりすましているかも知れません。
このルールの根拠について少し調べると、以下のような記事がありました。
あのパスワード規則、実は失敗作だった 2003年にパスワードの設定規則を考案した人が、後悔しているというものです。この規則は、世界中で採用され、パスワードは定期的に変えることがセキュリティに寄与するとされてきました。少し考えると、確かに安全そうなので、広く採用されているのだと思います。ルールを設定する側にとっては、責任を利用者に転嫁できることも、それを後押ししたように感じられます。
ただ、利用者の立場で考えると、この記事に書かれている通り、変更する必要がある場合は、自分が覚えていられるくらいの、最低限の長さで、特定の規則に従った小幅な変更にとどめることが多いようです。そうなると、攻撃者にとっては、以前のパスワードでは認証できなくなったが、末尾の数字に+1すると認証できたというような状況になります。

「定期的な変更」から「流出した時に変更」へ

今回ニュースになった総務省のサイトでは、定期的な変更ではなく、流出した場合に変更することを推奨しています。2017年に米国のNISTから出されたガイドラインに従った形になります。定期的な変更をしなくてもよくなった利用者は十分に安全なパスワードを使い続けられるようになります。
また、Googleを始めとした近年のサービスでは、日常で使用されている環境と比較して、異なる環境や地域からのログインが試みられた場合に、ユーザに通知する機能があります。自分がログインしようとしたのでなければ、誰かがパスワードを持っているか、持っていなくても、想定されるパスワードでログインしようとしているということになります。このような場合に、変更しようということになります。
また、パスワードだけに頼らない認証方法も、近年では当たり前になってきました。ワンタイムパスワードや、多要素認証です。パスワードという原始的で、人の記憶や努力に頼った仕組みと比較すると、仕組みとしてより洗練されてきたと言えます。

複数のサービスでのパスワード流用は避ける

パスワードの定期的な変更が不要になったからといって、流出した場合には変更する必要があります。また、あるサービスで流出したパスワードが、他のサービスでも使い回されていた場合には、そちらも危険ということになります。そのため、使っているサービス毎にそれぞれ固有のパスワードを使うことが推奨されています。また、それぞれ、十分に強力なものを設定する必要があります。

認証を一つにまとめると、安全かつ利便性が高い

近年多くのクラウドサービスが提供され、みなさんの組織でも、複数のサービスが使われているものと思います。定期的な変更をしなくても良さそうだとは言え、それぞれ固有で十分に安全なパスワードを設定するというのも、なかなか大変です。覚えきれないパスワードは、一部だけ変更したり、大胆にも「サービス名を付加するだけ」などの使われ方をされそうです。このような安易な規則に則ったパスワードは、攻撃者の標的になります。
では、利用者の利便性を損なうことなく、セキュリティを保つ方法はないのでしょうか。今考えられる方法は主に2つあると考えられます。
  1. パスワードマネージャの利用
  2. シングルサインオンによる認証の統合
前者は、「パスワードマネージャ」というサービスにサービス毎のパスワードを覚えさせるという方法です。パスワードマネージャにログインするために、一つだけパスワードを覚える必要がありますが、それ以外は、パスワードマネージャが覚えていてくれるので、十分に強力なパスワードを個別に設定することが可能です。ただ、この方法は、一部のサービスは組織向けに出来ているものの、多くは個人利用を想定しているようです。
後者は、個別のサービスでは認証せず、認証を別の仕組みに移譲してしまうシングルサインオン(SSO)という方法です。個別のサービス(SP:Service Provider)にログインしようとすると、認証サービス(IdP:Identity Provider)に飛ばされるという仕組みです。IdPでログインすると、もともとログインしようとしていたSPに戻ります。つまり、SPのパスワードは設定せず、IdPのパスワードだけ覚えれば良いということになります。
どちらも、利用するパスワードは一つで済みますので、利便性を損なうことなく、十分に安全なパスワードを設定することができるでしょう。

Gluegent Gateは、SSO + IDM の機能を提供します

弊社のサービス、Gluegent Gateは、SSOの機能を提供します。認証を一手に引き受けることで、対応するサービスを高いセキュリティと利便性を保ったまま利用することが可能です。また、各サービスへのプロビジョニングが出来たり、AD/LDAPをID源泉として設定することが出来るなど、組織向けの機能を多く持っています。
今回のニュースは、単純に「定期的な変更をしなくてよくなった」とだけ捉えずに、よりセキュアな運用に進むためのチャンスと捉えるべきだと思います。利用者の利便性を下げ、無駄とも言える努力を強いる運用から、利便性を確保した上で安全も提供する運用にレベルアップしましょう。


   Gluegent Gate


2018年4月3日火曜日

Gluegent Gate と SSO設定したG Suite のパスワードはどうなる?

Gluegent Gateは、G Suite(旧 Google Apps )やOffice 365等、様々なクラウドサービスとシングルサインオン(SSO)を実現することができるサービスです。
様々なクラウドサービスでSSOの設定ができますが、SSO 設定時の挙動はサービスごとに異なることが多いです。例えば、サービスへ直接アクセスできたり、できなかったり、管理者だけアクセスできたり、G Suite などではIMAPでアクセスする場合はSSO経由とならなかったりと多岐にわたります。
Gluegent Gateでは、SSO設定時に指定するパスワード同期ルールとして3種類選べますが、それぞれの特徴と G Suite 利用時を例に取って、同期ルール選択時の考え方についてご紹介します。

Gluegent Gateのパスワード同期ルール

Gluegent Gate とG Suite との間にシングルサインオン(SSO)設定を行っているとき、G Suite のパスワードはどうなっているのでしょうか。 SSO設定を行うと、G Suite へのログイン時には Gluegent Gate のログイン画面が表示されます。ここで入力するパスワードは G Suite への同期有無について、Gluegent Gate のパスワード同期ルールの設定で変更することができます。

Gluegent Gate のパスワード同期ルールは「なし」「シングルサインオンのパスワード」「ランダムパスワード」の三種類から選択します。

以下にそれぞれの設定の内容について説明していきます。

(1)パスワード同期=「なし」
Gluegent Gate のパスワードは G Suite には同期されません。
Gluegent Gate にユーザーを作成した時、G Suite に同期され、G Suite 側にユーザーが作成されます。この時、G Suite 側のユーザーのパスワードはランダム値が設定されます。
その後、ユーザーや管理者が Gluegent Gate 側のパスワードを変更しても G Suite には同期されません。
つまり、G Suite 側のパスワードは最初に作成された時のまま変化しません。


(2)パスワード同期=「シングルサインオンのパスワード」
Gluegent Gate のパスワードは G Suite に同期されます。
Gluegent Gate にユーザーを作成した時、G Suite に同期され、G Suite 側にユーザーが作成されます。この時、Gluegent Gate のパスワードと同じ値が G Suite 側のパスワードに設定されます。
その後、ユーザーや管理者が Gluegent Gate 側のパスワードを変更すると G Suite に同期されます。
つまり、Gluegent Gate と G Suite のパスワードは常に同じ値となります。

(3)パスワード同期=「ランダムパスワード」
Gluegent Gate のパスワードは同期されず、G Suite のパスワードにはランダムな値が設定されます。
Gluegent Gate にユーザーを作成した時、G Suite に同期され、G Suite 側にユーザーが作成されます。この時「なし」と同じように G Suite 側のユーザーのパスワードはランダム値が設定されます。
その後、ユーザーや管理者が Gluegent Gate 側のパスワードを変更するとランダムな値が G Suite のパスワードに設定されます。
つまり、G Suite 側のパスワードは常にランダム値が設定されます。

どのパスワード同期ルールを選択するべきか?

それぞれのパスワード同期ルールの特徴はお分かりいただけましたでしょうか。
では、それぞれのパスワード同期ルールはどのように選択すればいいでしょう。それは G Suite の利用シーンにより異なります。
「なし」の特徴は G Suite のパスワードは変更されないことです。もし G Suite の管理コンソールで G Suite 側のパスワードを変更しても大丈夫です。
例えば、特定のユーザーにのみ POP / IMAP を使ってメールを受信させる、あるいは SMTP を使って自動的にメールを送信するといったことを行いたい場合は「なし」を選択しましょう。
ユーザーが Gluegent Gate 側のパスワードを変更しても G Suite 側は変更されませんので、その都度設定を変更する必要がありません。
管理者がエンドユーザーのパスワードを伝えることなく上記のようなことを実現する場合、有効となるでしょう。
「シングルサインオンのパスワード」の特徴は Gluegent Gate と G Suite のパスワードが一致していることです。万が一 Gluegent Gate が障害により使えなくなったら(そんなことはありませんが!)シングルサインオンの設定を解除して、G Suite のログイン画面からログインすることになります。G Suite のパスワードがランダム値だった場合、G Suite のパスワードを全ユーザーに一括で変更する必要があります。ですが、それを告知する術は・・・?そういったときに、Gluegent Gate と G Suite のパスワードが一致していれば、ログイン画面は変わりますが、エンドユーザーはいつもと同じパスワードでログインができるようになります。
「ランダムパスワード」の特徴は G Suite のパスワードが常にランダム値であることです。G Suite 側にどんなパスワードが設定されているかは誰も知り得ないので、安全でおすすめです。

いかがだったでしょうか。本記事ではG Suiteを中心に説明しましたが、パスワード同期ルールは cybozu.com、Mail Luck!、PrimeDrive、Salesforce でも利用できます。お客様の運用に合わせてお選びください。

   Gluegent Gate

2018年3月27日火曜日

Gluegentシリーズユーザに役立つサイトをご紹介します

グルージェントでは、G Suite や Office 365 といったクラウドサービスをより便利に、より快適にお使いいただけるような便利機能をGluegentシリーズとしてご提供しております。
主なGluegentシリーズは以下の通りです。

上記サービスをご契約いただいたお客様がご利用方法や設定内容などを確認する場合、どのような情報リソースが存在しているか興味ある方もいらっしゃると思います。今回はユーザが困った時に役立つ情報をどこで確認することができるか簡単にご紹介します。

オンラインマニュアルでサービスの使い方を学ぶ

弊社サービスのオンラインマニュアルは以下からご確認いただけます。

上記サイトにアクセスすると、左のナビゲーションメニューにサービス共通またはサービス毎のユーザ・管理者マニュアルリンクが表示されていますので、確認したいリンクをクリックしてください。すると、右ペインに掲載しているオンラインマニュアルが一覧表示されます。

マニュアルは全てPDF形式のため、Chrome等のブラウザ上ですぐに表示することができます。


このオンラインマニュアルサイトは、ご契約が無い一般のお客様からもアクセスできるようになっています。そのため、事前に細かくご確認いただくことも可能です。


サポートサイトで問い合わせの他、FAQやリリース情報を確認する

前述のオンラインマニュアルにて基本的な設定方法や操作をご確認いただき、色々と触り始めると、思った通りに動かなかったりすることもあるかもしれません。また、「こんなことを実現したいのだけどできるんだろうか?」と疑問に思うことももあるでしょう。
そんな時は、弊社のサポートサイト「クラウドコンシェルジュ」をお使いください。
弊社サービスをご契約を頂いたお客様は、クラウドコンシェルジュを利用できるように弊社にてアカウント登録を行います。その後、こちらからお問い合わせすることができるようになります。

特に問い合わせがないでも契約サービスのリリース情報やFAQの確認にご利用いただけます。
以下のスクリーンショットではGluegent Apps共有アドレス帳に関するサポートページです。
クラウドコンシェルジュでは、サービス毎に以下の内容を掲載しています。
  • お知らせ
    • エンドユーザに多大な影響がある大規模リリースや、お客様操作が必要な変更、その他外部要因によりアプリケーションの動作が変わってしまうような注意事項を案内しています。
  • リリース情報
    • リリースの予告および実施報告を案内します。新バージョンで追加する機能や改修する機能を簡単に紹介しています。
  • FAQ
    • アプリケーションに対してよくある問い合わせをFAQ形式でまとめています。
  • 既知の問題
    • アプリケーションにおける既知の問題をまとめています。
購読ユーザ登録をしておけば、掲載追加・更新時にメール配信により、お手元でご確認いただくことが可能です。まだの方はぜひお願いします。


いかがだったでしょうか。Gluegentシリーズのオンラインマニュアルは大変充実しており、読み応えも十分かと思います。また、何かご不明な点があればクラウドコンシェルジュによるサポートサイトですぐお問い合わせできますし、購読メールにより適宜アプリケーションの変更内容を受信することもできるため、サポート面で不安な方も安心してお使いいただけるかと思います。
ご興味ある方はぜひ弊社お問い合わせフォームからお問い合わせください。よろしくお願い致します。


 Gluegent Gate



2018年3月20日火曜日

Gluegent Flowテンプレートを使って「社内アンケート」を作ってみよう

Gluegent Flowで用意してあるテンプレートをカスタマイズしてみましょう。今回は、簡単な例として、社内向けアンケートを作ってみます。入力フォームの調整だけで良いので、数分で作成可能です。

設問・選択肢をカスタマイズ

G Suite版のGluegent Flowではサンプル申請モデルとしてテンプレートを用意しています。その中に「社員満足度アンケート」テンプレートを用意しておりますが、このテンプレートをもとに申請モデルを作成後、少しカスタマイズしてみることでいろんなアンケートが実現できます。以下、その手順を説明していきましょう。

新人の歓迎会をするのに、希望の会場を聞くということにしましょう。まず、申請モデルの名称を変えます。

「中間ガイダンス」で質問内容を書きます。今回は既存のものを書き換えました。


次に、テンプレートにある既定の選択肢も書き換えましょう。テンプレートでは単一チェックになっていますが、複数チェックにして、会場候補を書いてみました。

また、必須のチェックも入れてあります。その他の場合の受け皿も用意します。

他の不要な入力フォームを削除して、以下のようになりました。

プレビューボタンを押して、実際に利用者に見てもらう画面を確認しましょう。

これで、希望の会場を決められそうです。

回答の記録・集計

アンケートの回答をGoogleスプレッドシートにまとめて、集計します。「送信」の経路で、送信時にスプレッドシートに回答内容が出力されるようにします。

「自動処理を追加する」をクリックして、

「Google Spreadsheetへの行挿入自動処理の追加/編集」を選び、必要な設定をします。ここで任意のスプレッドシートに回答を書き出すことができます。


申請モデルを素の状態から作るのは、少し敷居が高いと感じるかも知れませんが、既存の申請モデルをコピーしたり、テンプレートを使うことで、一部を変更して、簡単に希望のワークフローを作成することができます。テンプレートは今後も拡充する予定です。今回は、ワークフローとしては、少し変わったものを作ってみましたが、Gluegent Flowの仕組みを使えば、いろいろなものを作ることができます。柔軟な入力フォームと豊富な自動処理を是非ご活用いただければと思います。