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

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