2017年12月12日火曜日

セキュリティ対策としてGluegent Gateをお薦めする3つの理由

昨今、クラウドサービスを利用することが当たり前になってきたと行っても過言ではないでしょう。 さらに、メール・カレンダーはG Suite、社内SNSはSlack、ファイル共有はBoxというように、複数のクラウドサービスを目的・用途によって使い分けている企業も増えています。
クラウドサービスのメリットの1つに「いつでも」「どこでも」「どこからでも」利用できることがありますが、そのことばかり重視し、足元のセキュリティ対策が疎かになっていないでしょうか。また、複数のサービス毎にログインし直す手間や、ID・パスワードを個々のサービス毎に管理する結果、システム管理者では次第に運用面で回らなくなるケースも出てきていたりしないでしょうか。
今回は、クラウドサービスのセキュリティ対策として弊社が提供しているGluegent Gateを導入することにより上記のような課題がクリアできる3つの理由についてご紹介していきます。



多彩な認証方式でセキュリティを確保できる

セキュリティレベルを上げるには複数の認証方法を組み合わせることが効果的です。Gluegent Gateでは以下の通り、多用なアクセス制御方式をご用意しています。
    <Gluegent Gateで利用可能なアクセス制御方式例>
  • IPアドレス制御
  • 端末個体識別ID制御
  • 時間帯指定制御
  • アプリケーション認証
  • クライアント証明書
  • 統合Windows認証

通常のID・パスワードに加え、その他の方式を複数組み合わせることで安全性が飛躍的に高まります。また、セキュリティポリシーはグループまたはプロファイル単位に指定したルールに沿って制御できますので、効率かつ効果的です。

シングルサインオンで様々なクラウドサービスやシステムの利用が快適になる

複数のクラウドサービスに逐一ログインし直すのは大変面倒です。
また、個別ログインにあってしまうとパスワードも使い回しにしがちであり、セキュリティ低下の要因になりがちです。
Gluegent Gateでは一度の認証手続きで複数のサービスに安全にログインすることができる「シングルサインオン」を採用しています。 現在、Gluegent Gateでは以下のクラウドサービスに対してシングルサインオン機能がご利用できます。
    <Gluegent Gateでシングルサインオンできる主なクラウドサービス>
  • G Suite(旧Google Apps)
  • Office 365
  • Salesforce
  • Dropbox
  • cybozu.com
  • Box
  • LINE WORKS
上記以外でもSAML2.0に対応した各種クラウドサービスはもちろん、SAML2.0に未対応のシステムに対してはユーザに成り代わって認証(代理認証)することでシングルサインオンがご利用できます。

アカウントの一元管理でスムーズかつ正確な運用ができるようになる

社員の移動・退職時に複数のクラウドサービス毎にアカウントのメンテナンスを行うのは大変な労力が必要です。特に退職者のクラウドサービスアカウントの削除漏れがあると、退職後も社内の重要なデータにアクセスできてしまい、セキュリティリスクが発生します。
Gluegent Gateでは前述のクラウドサービスに対するアカウントの一元管理(統合ID管理)が可能です。つまり、Gluegent Gateでアカウントのメンテナンスを行うことで、各クラウドサービス上のアカウントの追加・削除といったアカウント同期が実現できます。これにより、システム管理者の手間が大幅に減らせるだけでなく、削除漏れも防げるため、退職者による不正アクセスの心配もありません。 また、Active Directory(AD)やLDAPにて社内のアカウントを管理している場合、それらとGluegent Gateを連携することにより、例えば従来通りADにてアカウントの管理を行いつつ、Gluegent Gateにて各クラウドサービスにアカウント同期が行えます。

いかがだったでしょうか。Gluegent Gateをご利用いただくことで直接クラウドサービスを利用する際に発生しがちなセキュリティ上の課題に対策できることがお分かりいただけたと思います。Gluegent Gateでは今後も様々なクラウドサービスとつながり、お客様がより安全にご利用いただくためのサポートを行っていきます。

   Gluegent Gate


2017年12月5日火曜日

うちの会社でもワークフローシステムは必要ですか?

そもそも「ワークフローシステム」は、必要なものなのでしょうか。「ワークフローシステム」というものは、どのようなニーズに応えるもので、どのようなメリットをもたらすのでしょうか。今回の記事では、「ワークフローシステムって要るの?」という疑問に答えてみたいと思います。



「ワークフローシステム」は、「仕事をする」のを支援する

ワークフローは、生産業に端を発し、限られたリソースを効率的に配分して、成果物を生産するための反復可能な活動のパターンを指す概念です。広い意味では、何かを作るための材料の調達や、運搬なども考慮に入れて、最適な方法で成果を出すことを目的としています。ただ、「ワークフローシステム」として考えた場合には、もう少し規模が小さい、「稟議」や「経費精算」などが実質的な用途とされることが多いようです。
ただ、どのような規模であれ、「ワークフローシステム」は、「仕事をする」ということを支援するシステムです。仕事は、場当たり的にその場で処理されていくものではなく、適切に計画され、進捗が管理され、期待される結果を出さなければいけません。これらの処理を「ワークフローシステム」が道標となり、適切に進めることを支援してくれます。 どのような組織であっても「仕事をする」というミッションのためにあります。そのため、ワークフローシステムはどのような組織にとっても「有用である」ことは確かです。

「定型業務」と「非定型業務」

仕事は、その内容によって、「定型業務」と「非定型業務」に分けることができます。「定型業務」はよく言われるようにマニュアル化が可能で、手順が変わらない業務です。一方で、「非定型業務」は、その都度内容が変わったり、判断によって、手順が変わるよう業務です。
業務の効率化を進める時に、大きなテーマになるのは、「非定型業務の定型化」です。定型業務は、手順が変わらないため、ワークフローシステムに載せるのは、容易です。多くはマニュアルに記載された手順をそのままワークフローにまとめることができます。ただ、「非定型業務」も、実は多くの部分で定型化することができます。手順が変わらないレベルまで汎化して、モデル化にする方法もありますし、全体の行程を分割して、定型可能な部分を「定型業務」として切り出すという方法もあります。どのような方法を取るにしても、曖昧で属人化した「非定型業務」を可能な限り、定型化し、ワークフローシステムにのせることで、仕事はより効率的になります。

どこまで定型化すれば良いのか

業務は定型化し、業務フローとしてまとめることが出来れば、ワークフローシステムで管理可能になり、より効率よく、より確実に仕事を進めることが出来ます。では、どこまで定型化すれば良いのでしょうか。それは、ワークフローシステムの表現力にかかってきます。
Gluegent Flowは、条件分岐や、ロールの設定による柔軟な経路設計が可能です。オンプレミスで提供されているワークフローシステムでは、かなり複雑な表現が出来るものがあります。お客様の中には、クラウド型のワークフローシステムは、そこまでの表現力がないと考えている方もいらっしゃいますが、Gluegent Flowでは、オンプレミス型に劣らない複雑な表現が可能です。(参考:G Suite 連携ワークフロー クラウド型でも複雑な経路を設定できる)
ただ、あまりに複雑なモデルは、それを運用する事自体が、新たな仕事を生むことになってしまい、本末転倒です。じっくりと現行の業務を分析し、適切な規模の業務フローを確立することが大事です。

うちの会社でも要りますか?

お客様にGluegent Flowをご説明した時に「そこまでやる規模じゃないんだけど、うちでも要りますか?」、あるいは「業務がすごく複雑なんだけど、入れられますか?」と聞かれることがあります。上で見たように、どのような組織であっても、「ワークフローシステムに載せるべき業務」はありますし、複雑な業務フローでも対応できます。また、Gluegent Flowは利用したい人の数だけ購入することができますので、導入したことによるメリットを考えると高い費用対効果を期待できます。 また、部門単位などの小規模な導入から始めて、全社に広げていくというような展開も可能です。さらに、利用開始時の手間をはぶく、テンプレートを多く提供しています(参考:Office 365 / G Suite 連携のクラウド型ワークフロー テンプレートを拡充します)。弊社サービスのご利用者向けのサポートサービス(クラウドコンシェルジュ)では、細かな部分まで迅速なサポートを提供しています。 Gluegent Flowは、ただのワークフローシステムではなく、クラウド型のサービスならではの利点も多く備えています。ワークフローの添付ファイルをG Suiteで共有したり、ワークフローの処理状況をSlackに通知したりできます。また、申請者が入力時にこまらないような対応も細かくできます。

私達は、どのような組織でも「必要です」と言えるワークフローシステムをご提供しています。より効率の良い働き方を考えている方には、有力な選択肢をご提案できると思います。是非ご相談ください。





2017年11月28日火曜日

当然ですが、クラウド時代にもIDライフサイクル管理は必要です

SOX法やコンプライアンスの観点からも、情報システム部門の負荷の観点からも、IDライフサイクル管理は情報システムに関する大きなテーマとなってきました。時代がオンプレミスからクラウドに移りゆく今こそ、この先IDライフサイクルをどのように管理し続けるのかを考えておく必要があるでしょう。

 Gluegent Gate

当社の Gluegent Gate は、2009年頃からクラウドのアクセス制御・シングルサインオン・統合ID管理サービスとして提供を続けています。2009年頃は「初めてクラウドを活用するにあたって、アクセス制御をしておきたい」というのが基本的な要件でした。特に、当社(当時はクラウド事業はサイオステクノロジーにありました)が、G Suite(当時は Google Apps for Business)を販売していたこともあり、「G Suite を使いたいが本当に安全だろうか」という不安がベースにあってのご相談がほとんどでした。

Gluegent Gate の IPアドレス制限や証明書認証等により、これらの要件をクリアして初めてのクラウドをより安全に活用いただけたと考えています。

この流れに除々に変化が起きてきています。まずひとつは「モバイル」が指すものが大きく変わりました。サービス開始当初は、フィーチャーフォンの「携帯個体識別番号」を使っての「制限する」ことが主流でしたが、徐々に対象がスマートフォンに移っていき、2017年現在は完全にスマートフォンから「いかに便利に利用してもらうか」というスタンスになってきています。そして、もうひとつの大きな変化として「クラウドはシングルサインオン(SSO)で飛躍的に便利になる」でも取り上げていますが、2016年頃からシングルサインオン視点で導入をご検討いただくことが増えてきたことです。また、これに伴い「複数のクラウドサービスのアカウントやグループをどのように管理していくか」というテーマでお話させていただくシーンが増えてきています。

もはや、複数のクラウドサービスを利用するのが当たり前、これらのアカウント管理をどのように行っていくかというのが、大きなテーマとなりつつあります。また、パブリックなクラウドサービスだけでなく、自社開発のクラウドシステムなども対象になってきています。

Gluegent Gateの運用パターン - ID管理編 -」でも紹介している通り、当社が提供するGluegent Gateは、IDの運用についても、優れた機能を提供しております。特に、Active Directoryや基幹の人事システムとの連携により、これまでの運用に近い形で運用設計が可能な点はご評価頂くケースが多いです。

一方で、まだまだIDライフサイクルを完全に管理できるものになっているかというと、まだまだ足りないものが多いのも事実であり、現在機能強化を推進しております。

例えば、最近「プロファイル」の機能をリリースいたしました。これにより「社員、営業部所属、課長」「社員、開発部所属」などの職責等によって利用できるサービスの管理や、各クラウドサービスに対するアカウントのプロビジョニングが管理できるようになるなど、簡素な設定で柔軟な管理が可能になっております。

今後も、各社が利用するクラウドサービスは確実に増え、そして多様化していきます。グルージェントは、そのような将来を見据え、安心して快適に利用できるサービスの提供を続けて参ります。


 Gluegent Gate


2017年11月21日火曜日

G Suite(旧Google Apps)の社内ポータルで様々な共有情報を1箇所に集約する

Gluegent GadgetsはGoogle サイトで社内ポータルを構築する際に役立つ情報共有ツールです。 Googleサイトだけで構築する際に発生する課題も、Gluegent Gadgetsを利用すれば解決できるようになります。
Googleサイトで社内ポータルを構築するときに発生する課題の一つに、様々な社内のお知らせ情報を同一ページに集約することが難しい、というものがあります。これは、部署毎にアクセス権が異なる情報をGoogleサイト上のページに掲載できないことによるものですが、このためにはお知らせ情報をユーザの権限に応じて動的に切替えた上で表示する必要があります。
今回は、Gluegent Gadgetsの「お知らせ通知」および「掲示板」ガジェットを利用することで、社内のお知らせ情報を集約する方法を説明します。

Googleサイトだけで社内のお知らせ情報を扱う場合の課題

社内でお知らせする情報は大きく以下の2種類に分かれることが一般的です。

  1. 全社員に共通で伝えたいこと
  2. 特定の部署・人毎に伝えたいこと
この2種類に対してGoogleサイトのお知らせページ機能で管理することを考えてみます。まず上記1は全社共通の情報であるため、記事の掲載場所やアクセス権について特に気にする必要はないでしょう。 一方で上記2はどうでしょうか。内容に応じてユーザのアクセス権を制限する必要がありますが、Googleサイトのお知らせページでは記事毎にアクセス権を設定することができません。Googleサイトではアクセス権設定における最小単位が「ページ」であり、そのページ毎にアクセス可能なグループ・ユーザにのみ権限を付与することになります。その結果、社内ポータルにおける「お知らせ情報」は、全社共通で公開してよい情報はトップページに、部署・ユーザ毎に制限されている情報は別のページに分けて管理するしかありません。

上図の通り、お知らせ情報のアクセス権に応じて、お知らせページも3種類(全社共通、開発部、営業部専用)分けて管理することになります。この場合、以下のような運用面での課題が発生します。

  1. お知らせの掲載場所がバラバラとなってしまうことで、その情報に対する視認性が落ちてしまう(パッとひと目で確認しづらくなる)。しかも別ページに分かれたお知らせはユーザ自らアクセスしないと見れないため、見落としがちとなりやすい。
  2. 管理者が部署毎のお知らせ専用ページを設けることになるため、ページが部署の数だけ必要となり、管理も煩雑になる
  3. 特定のメンバーのみ共有したい場合でも、既存のお知らせページとアクセス権が異なってしまうと、そのアクセス権に応じた専用のお知らせページを管理者に用意してもらう手間が発生してしまう(そして、ほとんどの場合、専用ページの追加要望は管理者から却下される)
Gluegent Gadgetsのお知らせガジェットと掲示板ガジェットで社内の情報を集約化
前述の課題に対して、Gluegent Gadgetsのうち、以下の2つのガジェットを利用すると分散されてしまっている社内の様々な共有情報をポータルトップページ1箇所に集約させることができるようになります。
  • お知らせ通知ガジェット
    • 参照先としたGoogleサイトのお知らせページを収集し、1箇所で表示するためのガジェット

  • 掲示板ガジェット
    • 社内で共有したい情報の種類毎に掲示板を用意し、それ毎に記事を投稿・閲覧するためのガジェット

これらのガジェットを導入・活用することで視認性も改善し、管理も1箇所に集約できることで簡潔になります。


お知らせ通知/掲示板ガジェット導入時のチェックポイント
Googleサイトに上記ガジェットを導入したい場合、まずは以下のチェックポイントに従って、現在の状況・要望がどちらにマッチするご確認いただき、その上で導入の検討を進めるのが良いでしょう。

チェックポイント
推奨ガジェット
  • 既にGoogleサイトで複数のお知らせページを運用しているが、特に問題ない
  • Gluegent Flowでお知らせ記事投稿承認フローを運用している
    お知らせ通知ガジェット
    • Googleサイトお知らせページが複数あり、管理・運用が煩雑になっている
    • Googleサイトのお知らせ機能では利用できない以下の機能を利用したい
      • 記事の公開/終了日程の予約設定
      • 記事単位でのアクセス権設定
      • 記事投稿/変更時に閲覧可能なユーザへメール通知する
      • 記事の未読・既読管理
    • 一般ユーザが記事単位に共有先を設定できるようにしたい
    掲示板ガジェット
    なお、各ガジェットの機能に関する詳細については以下の記事をご確認ください。




    Googleサイトで社内のお知らせ情報を構築したものの、散財化してしまい、困っているケースも多いのではないでしょうか。Gluegent Gadgetsお知らせ通知や掲示板ガジェットを利用すれば、各記事のアクセス権に基づき動的に表示しますので、社内のお知らせ情報を1箇所に集約できるようになります。これにより、一般ユーザによる認識率の向上や管理者による運用管理効率も実現できるようになり、より円滑に社内情報を共有化できるようになるでしょう。
    まだ、Googleサイトだけで情報共有しようとしている方はぜひGluegent Gadgetsをお試しください。


    2017年11月14日火曜日

    Gluegent Gateの運用パターン - ID管理編 -

    Gluegent Gateは、各種クラウドサービスをはじめとして、オンプレミスな社内システムへのシングルサインを可能とし、「適切な人」が「適切なサービス」を「適切な場所や端末」からアクセスできるようにする、アクセス制御の機能を備えています。これらの機能にフォーカスした運用パターンについては、以下の記事でご紹介しました。
    今回は、もうひとつの重要な機能、「ID管理」の運用パターンについて、ご紹介します。


     Gluegent Gate

    IDはどこに管理・格納されているのか

    組織内のID情報は、様々な場所に置かれているようです。
    • Active DirectoryやLDAP Server
    • 独自の社内システムの人事データベース
    • 社員名簿
    • まとまった場所がない
    一番筋が良いのは、Active DirectoryやLDAP Serverなどのディレクトリサービスで管理する方法です。まさにそのために作られた仕組みですので、管理や検索も容易にできます。ただ、小規模な組織には若干敷居が高いかも知れません。
    また、給与や、人事など様々な社内の仕組みの管理のために社内システムを作りこみ、その中のデータベースに格納されているという場合も多くあります。 数人から十数人の組織では、そもそもシステムというものとしては、社員の一覧を格納した場所はないようなことも多いでしょう。IDの数が多くなく、検索するほどの量でもないため、必要がないからです。

    サービスにアカウントを登録する

    クラウドサービスやオンプレミスのサービスを利用するには、そのサービスにアカウントを作る必要があります。前述したIDの格納場所が、AD等のディレクトリサービスであれば、気の利いたサービスならアカウントの連携ができることもあります。独自システムの場合も、CSVファイルなどに出力できれば、それを読み込む仕組みがあったりします。 システムが参照できる仕組みがなかったり、そもそも一覧がない場合は、使う人ベースでアカウントを手動で作るような運用が多いでしょう。人の数や使うサービスの数が少ない場合は、実はこれで十分です。

    「クラウド当たり前」な近年のID管理は複雑になりやすい

    近年、特定の領域で高度な機能を備えたクラウドサービスが安価で利用できるようになっています。多くの組織では、G SuiteやOffice 365のようなクラウド型のグループウェアと合わせて、必要に応じて別サービスを組み合わせることが多いようです。ストレージ機能の強化のために、BoxやDropboxを足したり、営業部のみSalesforceを追加したりなどの利用形態です。
    このような使い方をする時に、IDの適切な格納場所がなく、アカウントがそれぞれのサービスでバラバラに手動で作成されているような運用となってしまっているお客さまも多くいらっしゃいます。ただ、小規模な組織でも、急成長したり、買収などにより、複数の組織が統合されるような場合には、そもそもIDの管理や利用しているサービスも全く異なるため、一気に複雑さが増します。
    このような状況では、利用者も管理者も運用するだけで非常に大きなコストを払うことになります。新入社員のアカウント発行や、退職者のアカウント削除、異動等によるアカウントの更新など、アカウントがあるサービスの数だけ手動で実施するのは、困難な上、セキュリティリスクを抱えることになります。

    IDの管理は一箇所だけで

    IDに対する管理は、一箇所だけで行い、この情報が伝搬していくのが理想です。IDを管理している主体(ここでは便宜的にADとします)に、新入社員の情報を作成し、利用させたいサービス(G Suite、Dropbox、社内システムなど)を有効にすると、自動的に対象サービスでアカウントが作成されるという仕組みです。姓が変わったとしたら、ADだけ変更すると、利用している全てのサービスに伝搬します。このような仕組みは、「ID連携」や、「アカウント連携」、「プロビジョニング」など様々な用語で説明されますが、要は、人間が手を入れるところは一箇所にして、他はそれが伝搬して反映されるという仕組みです。

    Gluegent Gateでの運用

    Gluegent Gateを使った運用では、どのような形態が取られるのでしょうか。

    小規模な組織で少数のサービス利用のケース 
    例えば、ID数15で、利用するサービスは、G SuiteとBox、5人の営業メンバーのみSalesforceも利用するというようなケースです。Gluegent Gateを利用しなくても、この程度の数であれば、それぞれ個別に登録・利用しても良いかもしれません。ただ、Gluegent Gateは、それ自体がIDの管理・格納場所として機能します。そこで、Gluegent Gateに15人登録し、それぞれおの利用するサービスを有効にします。これだけで、それぞれのサービスにアカウントが作成され、利用可能な状態となります。その上、以前の記事で書いた通り、シングルサインオンの機能により、一回のログインで全てのサービスが利用できますし、特定の端末からのみ使わせたいといったアクセス制御もGluegent Gateの画面のみで完結します。更に、サービスの追加や、アカウント増、退職者アカウントの適切なクローズなどもGluegent Gateの画面から処理できます。
    つまり、Gluegent Gateが無くても、頑張ればそれなりに使えるものですが、Gluegent Gateを入れることで、運用コストが大幅に下がり、高いセキュリティレベルを実現することができます。その余剰のマンパワーは、より組織の目的に直結するような仕事に使うことができます。

    IDはADに格納されていて、利用するサービスもそれなりにあるケース
    数百から数千のIDを管理する場合、前述のようなGluegent Gateのみでの管理は難しくなってきますし、そのようなボリュームであれば、ADのようなディレクトリサービスに情報を置いているケースがほとんどです。部署の多岐にわたり、様々な仕事があるため、利用するサービスも多くなります。
    このような場合、ADのデータをそのまま利用し、Gluegent Gateを経由して、必要なサービスにアカウントを作成するといった機能を利用することができます。当然、シングルサインオン、アクセス制御もそのまま利用できます。「AD/LDAP連携オプション」として、提供しています。このオプションを使えば、既存のADをそのまま利用し、プロビジョニングやシングルサインオンの利便性とアクセス制御による高いセキュリティを両立することができます。

    IDは社内システムのDBにもあるし、一部はADにもあり、利用するサービスもそれなりにあるケース
    このケースは、一部事業を買収するなど、異なる形態でIDが管理されています。この場合は、Gluegent Gateを素のままで使って、連携させることは困難かもしません。ただ、Gluegent Gateでは、「スプレッドシート連携オプション」を提供しています。この機能は、GoogleスプレッドシートにあるIDを、Gluegent Gateに取り込み、プロビジョニング等を行うということができます。つまり、散らばったIDの源泉とスプレッドシートをつなぐ処理を開発してあげることで、プロビジョニングまで連携できます。また、弊社では、「社内データを超簡単にクラウドから参照できるようにするマル秘ツール」でご紹介したCSVまたは、DBからスプレッドシートにデータを同期するツールも提供しています。これを使えば更に開発の手間を抑えることができます。
    大規模なお客様でも、AD等に綺麗にデータが入っているケースは多くありません。大きな組織を適切に運用していくために最適化された情報の持ち方をされています。ただ、どのような形にしても、丁寧に情報の流れを整理し、スプレッドシートに書いてあげれば、前述したような利便性と高いセキュリティを低い作業コストで実現することができます。

    様々なID源泉に対応できる柔軟なID管理

    ここまで見たきたようにID管理はその格納場所や既存の管理形態に、大きく依存します。Gluegent Gateでは、多くのお客様のご要望に対応してきたことで、現在のような柔軟なID管理が可能になっています。ID管理は管理者の苦労やコストが高い割に利用者には見えにくい裏方の仕事ですが、失敗すると即セキュリティ事故に繋がる重要なものです。さらに、手作業での処理が増えるほど、ミスも多くなり、作業コストもかかります。この領域の仕事は可能な限りシンプルな構造にして、人的作業は最小限に、自動処理を最大限にすることが正解です。

    人の出入りや、人事異動のたびに多くの手作業をしなければいけないシステム管理、人事を担当されている方は是非一度ご相談ください。

     Gluegent Gate


    2017年11月7日火曜日

    クラウド型ワークフローサービスへのご期待が変わりつつある

     今年は、クラウドグループウェアが「当たり前」になった印象が強いです。昨年までは、クラウドグループウェアは先進的な企業でのみ導入が進んでおり、保守的な企業での導入はそれほど進んでいない印象でした。それが今年に入り、一気に「クラウドありき」と捉えられている印象が強くなりました。いよいよキャズムを超えたというところでしょうか。グループウェアだけでなく、IaaS や PaaS、その他パブリッククラウドなどでも、全体的に「前向きに」「前のめりに」クラウドを活用しようという企業さまが増えてきているのを感じます。


    このような環境の中、クラウドのワークフローに対する期待も少しずつ変化してきています。以前は、「ずばりクラウドならではの利便性」という観点でのご期待をいただくケースが多かったのですが、最近は、より本質的で高度なご期待に変わってきている印象です。

    例えば、以前は「クラウドのワークフローであれば、オンプレミスのようにサーバのお守りをする必要がなくなる」「最新の機能がいつでも利用できる」「社外からの、またスマートフォンからの利用ができる」「利用人数に対する従量課金がうれしい」というような声を多く頂いていました。これらは、ずばりクラウドそのものの利便性であり、クラウド黎明期に「クラウドのメリット」として語られていた内容です。もちろん、クラウドそのもののメリットに対するご期待は今もなお継続していますし、その期待のレベルはどんどん高まっています。我々は、このご期待を裏切ることのないよう、一歩一歩着実にそのレベルを上げつつあります。

    一方で最近は、「クラウドそのもののメリット」より少し高度なご期待が増えてきています。例えば、「他のクラウドサービスとは連携」に関するお問合せです。

    当社の Gluegent Flow では、当初よりご評価頂いていた機能ですが、例えばワークフローで承認を受けた内容が Google スプレッドシートに自動的に連携されるなどの機能です。Gluegent Flow と G Suite の Google スプレッドシートが連携し、業務が効率化されます。最近は、例えば Slack や、Yammer、LINE Works など、G Suite 以外との連携についてもお問合せ頂くケースが増えてきております。

    弊社のクラウド型ワークフローサービスは、サービス開始当初より G Suite 等とのクラウド連携を強みとして成長を続けております。今年から来年にかけてのテーマは「つながる」に置いています。クラウド間の連携ももちろんですが、それ以外の「つながる」を強化してまいりますので、ご期待ください。

    「つながる」と色々ワクワクしてきます。


    2017年10月31日火曜日

    Gluegent Flow活用例:決裁金額に応じて承認/決裁を切り替えるには?

    Gluegent FlowはG Suite(旧Google Apps)やOffice 365と連携し、クラウド上で様々なワークフローを実現できるサービスです。 ご導入頂いているお客様では既に様々な「お金」に関するワークフローをご利用いただいていることでしょう。
    一般的には上長の承認・決裁が必要な稟議書、精算書などに関するものがほとんどかと思いますが、そのようなワークフローにおいて決裁金額に応じて処理を切替えたいという御要望をお受けすることがあります。
    今回は、Gluegent Flowを使って決裁額に応じた承認ルートの分岐方法をご説明します。

    決裁金額に基づく承認ルートの分岐方法

    本記事では以下の稟議フローの一部を使って説明していきます。
    例えば、申請者からの稟議申請に対して直属の上司である課長が承認・決裁する場合、その決裁額によって以下のように処理が分かれるものとします。
    1. 20万未満:課長による決裁ができる。
    2. 20万以上:承認のみ。決裁の判断は次の承認者・決裁者に委ねる。

    課長は決裁金額に応じて承認者となる場合もあれば、決裁者になる場合もあります。
    これは、決裁金額によってどちらか一方の処理を排他的に実行するものと考えることができます。
    Gluegent Flowでは上記のようなケースを実現する場合、必要な処理を実行するボタンを追加し、そのボタン毎に有効/無効または表示/非表示の条件設定を行うことで、表現することができます。
    以下、このボタン表示切替に必要な設定方法を説明します。
    • 経路毎に必要な処理を追加する
    • その経路で承認/決裁者が行うべき処理を「経路」→「(経路名)」→「実行可能な処理」に定義します。以下のスクリーンショットでは「承認」、「決裁」を処理するためのボタンを追加しています。
      
    • ボタン表示制御のためのスクリプトを指定する
    • 上記で追加したボタンの名称をクリックし、「ボタン表示切替」の編集リンクをクリックします。すると、スクリプト編集画面が開きますので、そこで判定処理のためのスクリプトを記述します。
      例えば、「決裁」ボタンは入力フォームの項目「決裁金額」が20万未満の場合のみ表示するようにしたい場合、以下のようなスクリプトを記述します。
    // 決裁ボタンの表示制御用スクリプト
    // 20万未満の場合、表示(true)
    if ( ${決裁金額} < 200000 ) {
        return true;
    } else {
        return false;
    }
    
      同様に「承認」ボタンにも表示制御用スクリプトを指定します。承認ボタンの場合は上記のスクリプトとは逆の条件判定になります。なお、スクリプトを記述したら、「スクリプトを確認する」リンクをクリックし、動作検証を行いましょう。
    // 承認ボタンの表示制御用スクリプト
    // 20万以上の場合、表示(true)
    if ( ${決裁金額} >= 200000 ) {
        return true;
    } else {
        return false;
    }
    
      指定すると、各ボタン名に以下のようなアイコンが表示されます。

      以上の設定内容を踏まえた申請モデル「稟議書」を作ってみました。以下のスクリーンショットでは「費用または金額」が決裁金額に該当するものとします。
      例えば、申請者がタブレット購入額として160,000円を稟議申請した場合、20万未満となりますので、課長承認時には以下のように決裁ボタンのみ表示します。
    パターンA:決裁金額が20万未満の場合(→決裁)


      一方、申請者がノートPC購入額として360,000円を稟議申請した場合は、決裁金額が20万以上となりますので承認ボタンのみ表示します。
    パターンB:決裁金額が20万以上の場合(→承認)

      以上の通り、決裁金額による条件判定でボタンが切り替わることがお分かりいただけたと思います。

    ボタン表示制御を利用するメリット

    Gluegent Flowのボタン表示制御を利用することで以下のメリットを享受できます。
    • ユーザの誤認識による間違ったボタンの押下リスクが防止できる
      • 画面上に説明や注意書をどれだけ記載したとしても、人はミスする生き物であり、ミスは防ぎきれないでしょう。適切にボタン表示切替を利用することで、余計なボタンを押さず、ミスを防止することができます。
    • ワークフローを一元管理できる
      • 適切にボタン表示切替機能を指定することで、申請モデルを複数分ける必要はありません。
    • ユーザの学習コストおよび情報システム部のサポートコストが下がる
      • 画面のボタン表示もシンプルとなり、ユーザの教育コストおよび情報システム部門のサポートコストも下がることにつながるでしょう。

    以上、Gluegent Flowのボタン表示制御機能を利用することで承認経路を変更する方法をご紹介しました。お客様へご説明するとき、「え?スクリプト?難しいんじゃない?」と不安がられることもありますが、書き方を少し覚えていただければ、すぐご活用いただけると思います。またスクリプト形式で記述できるからこそ、様々な条件判定が記載でき、拡張性も高いです。なお、注意点としましては、稟議書の申請モデルを1本にするために複雑な判定処理を記述してしまうと、ボタン毎に同様の記述が必要となり、修正発生時のメンテナンスが大変になる場合もあります。そのため、運用とメンテナンスを考慮しつつ、申請モデルを1本にまとめるべきか、分けるべきかご検討いただければと思います。



    2017年10月24日火曜日

    Gluegent Gateの運用パターン - シングルサインオン編 -

    以前の記事「Gluegent Gateの運用パターン - アクセス制御編 -」において、Gluegent Gate でアクセスを制御する運用のパターンをいくつかご紹介しました。今回は、もう一方の主要機能「シングルサインオン」についての運用パターンを見ていきます。

     Gluegent Gate

    シングルサインオン

    シングルサインオン(SSO)とは、簡単に表現すると、「一回のログインをもって、複数のサービスを利用可能にする」という仕組みです。Gluegent Gate では、高度な連携が出来る既定のサービスをはじめとして、SAML2.0に対応するサービスや、SAML2.0に対応していない一般的なWebサービスも、SSOの対象サービスとして登録することができます。Gluegent Gate にログインすることでこれらのサービスに個別にログインすることなく、利用することができます。SSOの世界では、認証する役割をID Provider (IdP)、利用したいサービスをService Provider(SP)と言います。ここでは、Gluegent Gate が、IdPで、登録されるサービスがSPということになります。以下にGluegent Gate が扱えるSPを簡単にご紹介します。

    1. 既定のSP
    Gluegent Gate では、多くのサービスが既定のSPとして利用可能です。SSOの文脈では認証の連携をするのみですが、既定のサービスでは、認証以外にも、プロビジョニングの機能を提供するなど、より高度な連携が可能です。現時点では、G Suite、Office 365、cybozu.com、Box、Dropbox、Salesforce、Mail Luck!、PrimeDriveなどに対応しています。

    2. SAML2.0対応のSP
    SAML2.0は、SSOの仕様として事実上の標準となっており、多くのサービスがSPとして動作します。ただ、仕様として定められているものの、実際の実装にはサービス毎に若干のばらつきがあります。Gluegent Gate では、個別の設定をすることでSPとして登録することが出来ます。

    3. SAML2.0に対応していないSP
    SAML2.0に対応していなくても、SPとして登録することができます。そのサービスのログインURLとユーザIDのパラメータなどを設定することで、Gluegent Gate が代理で認証します。昨今の多くのサービスはSAMLに対応していますが、古くから社内で使われているサービスや、SSOを意図していない内製のサービスなどは、この方式でSPとして登録することができます。

    実際の運用パターン

    Gluegent Gateでは前述したSPを利用することができますが、お客様は実際にどのように運用されているのでしょうか。以下、お客様環境での運用ケースをご説明していきます。

    代理認証でレガシー対応

    まず、G Suiteや、Office 365といったメジャーなクラウドサービスの利用のために、アクセス制御を目的として導入するケースが多くあります。これまで、社内にサーバを置いてグループウェアを利用していたお客様が、G SuiteやOffice 365に移行する場合、多くのニーズは、移行先で満たせます。ただ、業務の内容によっては、どうしても既存のサービスを利用しなければいけない場合があります。その場合には、「既定のSPでクラウド型グループウェア 、代理認証で 既存サービス」というような運用となります。既存サービスを置き去りにせず、SSOの世界に入れることで、利便性が損なわれることがありません。

    汎用SAMLで各種クラウドサービスをトッピング

    クラウドサービスが当たり前の状況となってから、G SuiteやOffice 365のような多機能なサービスとは別に、特定の単機能に特化したサービスも多く提供されています。多くのお客様は、一般的なオフィススイートとして、G Suiteか、Office 365を使い、足りない部分を単機能のクラウドサービスで補うような運用をされています。全社員向けに、G Suiteを入れて、営業部門にはSalesforceを、サポート部門にはZendeskを、経理部門にはさらに別なクラウドサービスをというように、各部門向けに特化したサービスを選んで追加する形です。
    ニーズは各部門にあるので、部門独自で導入してしまうケースも見受けられます。ただ、その場合は、ID管理が別になりますし、全社で使っているサービスと部門で使っているサービスは別にログインしなければいけません。その場合は、SPとして登録して、SSOの仲間にしてしまいます。メジャーなサービスは既定のSPとして提供しています(今後も対応を増やしていきます)し、現時点で対応できていなくても、汎用SAMLを利用すれば、SPとして登録可能です。
    高度な機能が月単位で少人数でも利用可能になっている時代です。トッピング感覚でSSOに取り込むことでシームレスにサービスを利用できます。

    シングルサインオンでユーザの利便性を追求し、さらに...

    ビジネスで使うサービスは、今後も増加していきますし、捨てきれないレガシーサービスもあります。これらをまるっとSSOに取り込むことで、利用者は本来の仕事のために頭と時間を使うことができます。さらに、認証を一箇所で管理することで、前回の記事で触れた「アクセス制御」も一元管理できます。もうひとつのポイントの「ID管理」も一箇所で完結します。ユーザの利便性を追求することと、セキュリティの強化および、管理工数の削減を同時に実現可能です。


    いかがだったでしょうか。Gluegent Gate は、レガシーシステムも、最新のクラウドサービスも同時に利用するお手伝いができます。是非一度ご相談ください。

     Gluegent Gate


    2017年10月17日火曜日

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

    2016年に、G Suite の「新しいサイト」が利用できるようになりました。「新しいサイト」は、これまでのサイトの延長線上には無く、コンセプトから何から大幅に変更されています。色々便利になっている反面、いくつかの不安な点もありました。特に、弊社として気を揉んでいたのは、Gluegent Gadgets はじめ埋め込み型の「ガジェット」の挿入の可否についてでした。



    「新しいサイト」と「以前のサイト」についての Google社 からの公式アナウンスは、およそ以下の通りでした。

    • 2017 年に、以前の Google サイトから新しい Google サイトへ移行するためのおすすめの方法を提供予定
    • 2018 年より、以前の Google サイトの段階的なサービス終了について、日程や詳細な情報のお知らせを開始予定
    • 現段階では具体的なサービス終了日は確定しておりませんが、終了日の少なくとも 1 年前にはお知らせを実施
    一方で、ガジェットについては、以下のような情報がありました。

    Google Cloud Connect (G Suite 管理者向けの公式オンライン コミュニティ) の情報

    - What kind of security is in place in the new Sites? -
    For customers with classic Sites that have code from outside their domain (including third-party gadgets), we provide additional protections for those embeds. Upon launch, the new Sites will not have gadgets and instead, will have embeds with content from other sources in an iframe, or using the OpenGraph protocol, neither of which pose a security risk.

    弊社からの Google Support への問合せ結果

    貴社を含め多くのパートナー様がガジェットを提供いただいている状態であるため、そう簡単に廃止できる機能でないとは思っておりますが、現時点でははっきりとしたことは申し上げられません。


    この度、上記の状況に動きがありましたので、ここで紹介させていただきます。

    2017年9月13日に、Google社 より新しいサイトでのガジェットへの対応ということで、以下の記事が掲載されました。


    この情報により、弊社Gluegent Gadgets についても、新しいサイトで利用していただくことができるだろうとの判断の下、現在対応可否の詳細について調査を進めております。

    同時に「新しいサイト」の売りでもある、「レスポンシブ Web デザイン」(PC、スマートフォン、タブレット等でも柔軟にデザインが調整されるウェブサイト) に対応させることも検討しております。

    みなさまに、新しいサイトに対応した Gluegent Gadgets をお届けできるよう、邁進いたします。



    2017年10月10日火曜日

    Gluegent Gateはなぜ細かいアクセス制御が実現できるのか?

    Gluegent Gateは G SuiteやOffice 365等の様々なクラウドサービスに対して、SSOやアクセス制御を実現することができるセキュリティサービスです。Gluegent Gateでは、接続サービス、認証方式、時間帯、ネットワーク、端末種類など対するアクセスルールを、ユーザやグループ毎に設定することができます。これにより細かいアクセス制御が可能となっています。今回は、そのアクセス制御を実現している仕組みについてご説明したいと思います。

    Gluegent Gateで細かいアクセス制御が実現できる理由

    認証・アクセス制御をご検討されている会社の場合、社内のユーザに対して、部署、業務、利用しているクライアント端末などに応じて、利用するサービスや認証方法を変えたい場合もあるかと思います。
    例えば、以下のようなアクセスポリシーを社内で設定したいとします。
    • G Suiteは社員全員が利用できるものとしする。
      • アクセス時のクライアント端末は社内のPCブラウザからのアクセスを基本とするが、社外からの利用は会社が許可した端末からのみアクセス可能とする。
    • その他、営業部に所属する社員はSalesforceへアクセスできる
    このようなポリシーを踏まえて適切なアクセス制御を行いたい場合、「誰が」「どの端末で」認証しようとしているかに加えて、「誰が」「どの端末で」「どこに」アクセスしようとしているかもチェックする必要があります。
    Gluegent Gateではこのようなチェックを適切に行えるようにするために、認証を行ったユーザを識別し、ある特定のユーザ・グループに対してアクセス先サービスを限定したり、端末毎に認証方式を変更する必要があります。 これを実現するために、Gluegent Gateでは認証フェーズと認可(アクセス権限)フェーズの2フェーズに分けて処理するようになっており、これにより細かいアクセス制御が可能となっています。

    下図は、認証/認可処理フェーズの流れをまとめたものです。
    以下に各フェーズ毎の処理概要を説明します。

    1. 認証フェーズ

    認証フェーズでは管理者が定義した認証ルールに基づき、ログインを試みるユーザーが誰であるかを特定するものになります。
    • 認証ルールは、どの端末種類からの認証時にどの認証方式を要求するか定義します。
    • 認証方式は、ID・パスワード認証、証明書認証、端末認証、AD/LDAP認証等を指定します。
    • 認証ルールに複数該当していたとしても、最初に認証が失敗した時点で即認証エラーとなります。
    • なお、Gluegent Gateではログインに成功した情報を保持し、別の対象サービスへのアクセスに際して再認証の必要なくログインが可能です(SSOの実現)

    2. 認可(アクセス権限)フェーズ

    認可(アクセス権限)フェーズでは、上記1の認証フェーズで特定されたユーザに対して、管理者が定義したアクセス権限ルールに基づき対象サービスへのアクセス権があるかチェックします。
    • アクセス権限ルールは、ユーザ、グループ、場所(ネットワーク)、日時、端末種類等といった条件を組み合わせて定義します。
    • 認証が成功したユーザは設定されたいずれかのルールにマッチするアクセス手段であれば、アクセス成功とみなします。
    • いずれのルールにもマッチしなかった場合は、アクセス失敗となり、対象サービスを利用することができません。
    アクセス権限の詳細については以下の記事をご確認ください。
    Gluegent Gateの運用パターン - アクセス制御編 -


    いかがだったでしょうか。Gluegent Gateでは認証・認可の2フェーズに分けていることで細かいアクセス制御が可能となることがお分かりいただけたと思います。もし、別のセキュリティサービスを使っており、アクセスポリシーを細かく設定したいができない点でお困りの方がいらっしゃいましたら、ぜひお問い合わせください。

     Gluegent Gate


    2017年10月3日火曜日

    細かい配慮で利用者にやさしいワークフローを実現するには?

    Gluegent Flow は、G SuiteやOffice 365と連携して、多様な「ワークフロー」をクラウドで実現することができます。これまでに、多くのお客様のご要望を実現しするために、きめ細やかな機能を実装してきました。ただ、お客様がやりたいことは千差万別で、全てを実装済みの機能としてご提供するのは困難です。そこで、Gluegent Flowでは、一部の機能でお客様自身が拡張できる仕組みをご用意しています。今回はそのような拡張の実例をご紹介します。

    細かな入力チェック

    申請者は、フォームに入力する時に様々な値を入れます。ワークフローとしては、数値を期待しているのに、文字列が入れられたりすると、後続の処理で困るため、手で直さなければならない場合もあるでしょう。そのため、入力フォームでは、入力された値をチェックする「入力チェック(バリデーション)」という機能が必要です。
    以下の例で、フォームにメールアドレスが入力されることを期待する入力チェックをご紹介します。

    カスタムバリデーション

    入力チェックのルールをJavaScriptで実現します。申請モデルの入力チェックのカスタムバリデーションの「スクリプト」で、入力された値が、期待されたものなら、trueを返し、そうでない場合には、falseを返すようにします。
    custom_validation.png


    メールアドレスが期待される場合には、以下のようなスクリプトになります。入力された値が、メールアドレスを示す文字列にマッチしない場合に、falseを返しています。


    // 未入力チェック
    if (${メールアドレス} == undefined) {
     // 未入力の場合は、以下のチェックは行わず、正常とする
     return true;
    }
    // 形式チェック
    if (!${メールアドレス}.match(/^[A-Za-z0-9]+[\w-]+@[\w\.-]+\.\w{2,}$/)){
     // !は否定(〜でない)。この場合、match(xxx)で xxx に該当するものでないとなる。
     return false;
    }
    return true;
    

    「スクリプトを確認する」の機能を使って、その場で動作の確認をすることもできます。
    任意のスクリプトを設定することで、入力値が、定められた形式(社員番号や商品コードなど)であることをチェックできます。また、スクリプト内では、他の入力フォームで入力された値や、日付、申請者の情報などを参照することもできますので、より柔軟なチェックが可能です。

    入力された値に対応したメッセージを表示する

    上の例は、入力される値を期待するものに限定する機能でした。次の例は、入力された値に対応して、特定のメッセージを表示する機能です。ここでも、JavaScriptが使えます。

    カスタムラベル

    入力フォームの形式として「カスタムラベル」を使います。特定の値を参照して、定義した条件に合致した場合に、特定の文字列を返します。返された文字列が、申請フォームに表示されます。
    custom_label.png


    以下の例では、処理した日付を参照して、曜日を表示することができます。


    var today = new Date( ${処理年月日});
    var label = ["日","月","火","水","木","金","土"];
    return label[today.getDay()] + "曜日";
    

    スクリプトを確認してみましょう。確認するために任意の日付を入れられますが、実際の申請時には、プレースホルダの機能によって、申請された日付が自動で入ることになります。
    custom_label_test.png

    細かい配慮で使いやすいワークフローを提供できます

    Gluegent Flowでは、様々な機能でJavaScriptを使って、機能を拡張することができます。申請フォームの作りの柔軟さは、利用者の利便性を大きく左右します。申請者が迷わずに必要な値を入力し、迅速に処理をすすめられるワークフローを提供するために、ぜひ、Gluegent Flowをご利用ください。





    2017年9月26日火曜日

    G Suite 中心での SSO か Gluegent Gate 中心での SSO か

    G Suite は、OpenID Connect の Identity Provider や SAML の IdP としての機能を持っています。このため、G Suite にさえログインしていれば、他のサービスにもログインできるという形での SSO(シングルサインオン)は、G Suite だけでも実現することが可能という事になります。

    ある意味で、弊社が提供するGluegent Gateとは競合関係にあるのですが、我々としては、今のところうまく共存できているものと考えています。

     Gluegent Gate

    SSO以外の重要な付加機能

    SSOについては、Gluegent Gate の重要な機能の一部ではあるのですが、あくまでも一部の機能という位置づけになります。アクセス制御の観点から見ると、G Suite のみでは実現できないことが多々あり、Gluegent Gate のような IPアドレスや証明書、端末制御などの機能が必要になるケースが多いです。

    また、クラウドの統合的なID管理を考えていくと、各種クラウドへのアカウントやグループ同期のためのプロビジョニング機能が必須と考えられるケースは多くあります。

    こういったケースでは、どうしても Gluegent Gateで提供している機能が必要となってきます。

    SSO 自体の捉え方の違い

    G Suite のような業務に密接に影響を与えるサービスは、業務効率改善のために別サービスへの移行を検討する必要があるケースが度々訪れます。例えば、G Suite を利用していて、Office 365 への乗り換えを検討する必要がある等、最近はよく耳にします。このようなケースでは、G Suite を SSO の中心に据えてしまっていると移行に際して、問題になるケースが多くなります。

    例えば、G Suite を SAML IdP として、Dropbox を SAML SP として利用している場合に、Office 365に移行するには、Office 365 のアカウントを社員に払い出し、Dropbox と G Suite の SAML 連携を解除して、Office 365に振り向ける必要が出てきます。アカウント同士の紐付けなどにも注意を払う必要が有るでしょう。

    Dropbox だけであればまだしも、Salesforce や Box、Zendesk など、複数のクラウドサービスを連携している場合、かなり煩雑な業務になることが目に見えています。全社的なアナウンスなども大変でしょう。

    Gluegent Gateなどの、薄い認証レイヤーを入れておくことで、上記のような対応は比較的簡単なものになります。Gluegent Gate と Office 365 を連携させ、然るべきタイミングで G Suite との連携を解除するのみです。

    実際には、もう少し手間は必要ですが、G Suite を中心に SSO を組んでいる場合と比べ、かなり見通しは良いものとなります。



    一方で、弊社の Gluegent Flow や Gluegent Apps 等は、現時点では G Suite や Office 365 に OpenID Connect でぶら下げるような仕様にしています。これは、これらのサービスが G Suite や Office 365 に密接に連携するものであるためです。

    このように、SSO 連携させたいサービスの特徴によって、G Suite にぶら下げるのか、Gluegent Gate にぶら下げるのかを判断していく必要もあるでしょう。

    そうは言っても、是非 Gluegent Gate を中心にすることをご検討下さい!


     Gluegent Gate


    2017年9月19日火曜日

    Gluegent Flow 活用例:ワークフローの承認依頼や処理状況をSlackへ通知するには?

    Gluegent FlowはG Suite (旧Google Apps)やOffice 365と連携することができるクラウド型ワークフローです。G Suiteとの連携では、承認/決裁時に申請内容をスプレッドシートへ出力したり、ドキュメントとして保存できる自動処理機能を活用することで、より効率的に社内業務の円滑化が実現できるようになります。 一方で、Gluegent FlowをG SuiteやOffice 365以外のクラウドサービスと連携したいケースもあるでしょう。最近では利用シーンに合わせて様々なクラウドサービスを活用している企業も増えてきており、そのようなサービスとGluegent Flowが連携できないかご相談を受けるケースも増えてきました。
    今回は、その連携の一例として、ワークフローの承認依頼や処理状況を外部サービスであるSlackに通知するための方法をご紹介します。

    Gluegent FlowからSlackへ通知できるようにする方法

    Slackへ通知できるようにするためには、Gluegent Flowから「Slack API」を操作できる必要があり、そのためにはお使いのSlackにてアプリケーション登録およびアクセストークンの発行が必要となります。
    一方、Gluegent FlowからSlack APIを操作するには、Web APIに対するGET/POST操作を行うための自動処理「外部システム実行」を利用します。この設定においてアクセストークンをパラメータに指定することでSlackにメッセージが投稿できるようになります。
    以上を踏まえると、Slackとの連携イメージは以下のようになります。

    まず処理担当者がGluegent Flowで処理を行った後、申請モデルに定義した外部システム実行自動処理によりSlack APIを通じてメッセージを投稿します。そのメッセージを閲覧した次の処理担当者がGluegent Flowにアクセスし、処理を行います。

    それでは以下から設定内容を順に説明していきましょう。


    • Slack APIを操作するためのアクセストークンを用意する
    • Slack API操作にはOAuth アクセストークンが必要となりますので、最初にこの発行から行います(詳細はhttps://api.slack.com/docs/oauth を参照)。

      1) Slackにログインした状態で以下のURLにアクセスする
      URL: https://api.slack.com/apps

      2) 「Create New App」ボタンを押し、アプリケーション名(App Name)、Workplace(Slack Workspace)を入力し、「Create App」ボタンを押す

      3) Scopesとして「chat:write:bot」を指定し、「Save Changes」ボタンを押す

      4) 追加したアプリケーションをSlack Apps一覧から選び、左メニューから「OAuth & Permissions」を選択する。 「Install App to Workspace」ボタンを押し、該当Workplaceに新規アプリケーションを追加する

      6) OAuth Access Tokenの「Copy」ボタンを押し、アクセストークンをコピーしておく
            
      ここでコピーしたアクセストークンは次で説明するGluegent Flowの自動処理設定で指定します。

    • Gluegent Flowの自動処理「外部システム実行」を設定する
    • Slack APIを通じてメッセージをSlackに通知するための設定を行います。
      ※この設定は各経路の実行ボタン毎に行ってください
      以下のように各項目について設定を行ってください。
      No.
      設定項目
      設定内容
      1
      自動処理の名前
      設定内容が分かる名称を記入する
      2
      URL 
      https://slack.com/api/chat.postMessage
      3
      HTTPメソッド
      POST
      4
      パラメータ
      No
      パラメータ名
      設定内容
      1
      token
      上記手順6)でコピーしたSlack APIアクセストークン
      2
      channel
      通知先
      3
      text
      メッセージ

      以上の設定内容を踏まえた申請モデル「営業日報」を作ってみました。
      これは営業担当者がその日の活動内容を報告するイメージです。通常、Gluegent Flow単体の場合では次の経路に指定した処理担当者にメールで通知しますが、各経路のボタン毎に外部システム実行自動処理によるSlack通知が設定されていれば、画面で指定されたSlackアカウント宛にも通知することができます。
      以下がSlackに通知されたメッセージです。
      このメッセージ上のリンクをクリックすれば、Gluegent Flowにて該当の報告内容を直接確認することができます。

    以上、Gluegent Flowの自動処理を利用することで外部サービスであるSlackに通知するための方法をご紹介しました。上記の例では個人アカウント宛に直接メッセージ通知する例でしたが、パラメータ値を変更すればスレッド宛に通知することも可能です。 もし、Slack以外に連携したいサービスがございましたら、弊社ホームページから是非お問い合わせください。



    2017年9月12日火曜日

    Gluegent Gateの運用パターン - アクセス制御編 -

    Gluegent Gateは多くの機能があり、運用を始める前に、自分の組織にどのような機能を適用するのがよいか決定するのは、なかなか大変です。この記事では、実際にご利用いただいているお客様はどのような使い方をされているのか、いくかのパターンに類型化して、ご紹介いたします。

     Gluegent Gate

    ポイントは、SSO、アクセス制御、ID管理

    パターンを理解するためのポイントは、以下の三点です。
    • どのようなサービスをSSOの対象にするか
    • 利用者の利用をどのように制限するか
    • IDの管理をどのようにするか
    なぜ、「SSO」と「アクセス制御」、「ID管理」を組み合わせるのか?の記事でも触れましたが、Gluegent Gateは、これらの機能を組み合わせることで高度な利便性とセキュリティを実現しています。今回は、アクセス制御に着目して利用の多いパターンをご紹介します。

    利用者のIPアドレスを制限

    もっともシンプルな利用方法がこのスタイルです。対象のサービスについて、特定の固定されたIPアドレスからのみのアクセスを許すという要件を満たします。G Suiteを導入したいが、社外からのアクセスをさせたくないような場合に有効です。比較的小規模な組織でクラウドサービスを入れたいが、扱う情報の質や、利用者のリテラシーを考えると、素のままのサービスでは、不安があるようなケースでご利用いただく場合は、この構成を提案いたします。 この環境では、社内のネットワークであれば、許可されるので、個人で持ち込んだ機器も社内ネットワークにつながりさえすれば、利用することができます。また、社外からもVPNで社内ネットワークにアクセスできれば、そのまま利用することができます。つまり、社内ネットワークでもある程度の制御が出来るとより高度なセキュリティを実現できます。

    利用者のIPアドレスを制限、端末を制限

    IPアドレスの制限に加えて、管理者がアクセスを許可した端末のみから利用させたいというパターンです。特定のIPアドレスからは、全てのユーザが利用可能としておき、特定のユーザについては、特定の端末を渡し、任意のIPアドレスからアクセスすることができるようにします。
    社外からも頻繁に利用したいような場合に、VPNで繋がずに通常の通信業者のネットワークを利用して、高いセキュリティを実現できます。組織がゆるした特定の端末のみですので、社員の自宅のPCや、公衆利用のPCからはアクセスできません。セキュアな領域を区切ることで、過失による情報の流出を防ぐ事ができます。
    端末制御は、以下の方式のいずれかで実現します。
    • アプリケーション認証(有償オプション)
    • 証明書認証(有償オプション)
    • アクセスキー認証(無償)
    アプリケーション認証は、予め専用のアプリケーション「SeciossPass」で、利用申請を行い、管理者に承認された端末からのみのアクセスを許すという方式です。
    SeciossPassは、PC版、iOS版、Android版を提供しております。
    証明書認証は、お客様が所有されているクライアント証明書がインストールされた端末のみ許可するという方式です。クライアント証明書を配布・管理する手間がかかりますが、アプリケーションを入れる必要はありません。
    アクセスキー認証は、予めユーザが申請し、管理者が承認したアクセスキーを保持するブラウザからのアクセスのみ許可するという方式です。アクセスキーは、ブラウザのCookieとして保持されます。
    これらの方式は、運用の容易さやセキュリティの強さに特徴がありますので、環境に合わせてその特徴を検討の上、ご利用ください。

    アクセス制御の運用

    適用するグループや組織などを考えると実際にはもっと複雑ですが、アクセス制御のパターンは、大きく以上の二点となります。対象とするサービスや、組織で扱う情報の質、一般ユーザの利用形態、運用の継続性など、多くの要素を検討した上で、どのようなアクセス制御をするとよいのか、考える必要があります。


    以上の通り、Gluegent Gateでは様々なアクセス制御が行え、クラウドをセキュアに利用することが可能となるサービスです。自分の組織では、どのような制御をしたら良いかわからないという方は、是非一度ご相談ください。

     Gluegent Gate


    2017年9月5日火曜日

    G Suite 連携ワークフロー クラウド型でも複雑な経路を設定できる

    G Suite や Office 365 と連携するクラウド型ワークフロー「Gluegent Flow」について、経路の設定に関するご相談やお問合せが多いので、簡単にまとめてみたいと思います。

    簡易なワークフローは、事前に担当者を指定しておくか申請時にユーザに選択させる等の設定ができるものが多いと思います。経路設定としてそれで十分というケースも多いと思いますが、やはり組織階層に従って自動的に申請者の上長が設定されたり、条件に応じて決裁者を変えたいなどのケースも出てくると思います。

    Gluegent Flowでは、このような経路設定も可能になっており、想像より柔軟な経路設定ができるというお言葉を頂くことが多いです。

    ここでは、お問合せが多い幾つかのケースについて、簡単に紹介したいと思います。 

    承認者としてグループを指定したい

    例えば、人事部の誰かが承認すれば良いものなど、担当者としてグループを指定したいケースがあります。Gluegent Flowでは、グループを担当者として指定することができるようになっています。また、グループの誰かひとりが承認すれば良いのか、全員が承認して初めて次の経路に行くのか等の設定も可能になっています。

    申請者を複数回登場させたい

    例えば、経費精算などでは、事前申請を求められるようなケースがあります。事前申請に通った後、経費を使い、その後、経費精算申請をするような運用です。この場合、「申請者→承認者→決裁者→申請者→承認者→決裁者→経理部門の確認」などのような経路設計が必要になります。Gluegent Flow では、経路担当者として申請者を指定することが可能なので、こういった経路設定も簡単にできます。

    申請者の上長を承認者にしたい

    ある程度の規模になってくると、申請時に承認者をユーザに選ばせるのは厳しくなってきます。こういった場合、組織階層情報から申請者にとっての上長が自動的に承認者として設定されると、利用時のユーザ負荷が格段に下がります。Gluegent Flow は組織階層を持ち、各組織に対する責任者を名前付きで設定できるようになっています。例えば、開発部の部長はAさん、副部長はBさん、開発部第一グループのグループマネージャはCさん等。Gluegent Flow では、経路の担当者設定にこの「部長」や「副部長」「グループマネージャ」等のロール(役職)を指定することができるようになっており、ロールの指定さえしておけば、自動的に経路の担当者が設定されるようになります。
    組織階層自体は、G Suite のグループ等と同期させることが可能となっており、ワークフローのためだけに組織階層をメンテナンスする必要はありません。

    条件によって決裁者を変えたい

    例えば、100万円未満のものは課長決裁、それ以上は部長決裁など、金額によって決裁者を変えたいケースがあります。Gluegent Flow は、条件に応じて次の経路を変更することが可能になっており、簡易的に上記のようなケースに対応することができます。


    Gluegent Flow では、ある程度の経路設計に耐えられるような仕組みを用意しております。今後もより柔軟に、そして簡単に経路を設計できるように改善を続けていきます。各種経路設定の詳細についても、今後当ブログにてご紹介できればと思います。

    ご質問等ございましたら、是非こちらからお問合せください。