2018年9月25日火曜日

IDaaSとは、何か? (4) 〜どのサービスを使わせるか〜

IDaaSについて紐解く人気シリーズ「IDaaSとは何か」の一回目の記事、[IDaaSとは、何か(1)」で、以下の機能があるとご紹介しました。

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

前回は、IDaaSとは、何か? (3) 〜訪問者は誰?〜として、「認証」について、見てみました。今回は、「認可」です。


認可ってなに?

「認可」とは何でしょうか。「認証」と一字違いですし、混同しやすいことも多いようです。英語でも、認証は、"Authentication"、認可は、"Authorization"で、似ています。ただし、その意味は異なりますので、ここではっきり理解したいところです。
今回もまずは簡単に一文で表現してみましょう。認可とは、「"特定の条件"に対して、"特定の何か"へのアクセスを許すこと」です。
ここで、「特定の条件」というのは、例えば「ユーザAさんが、社内のLANを使ってアクセスする場合」というような条件です。また、「特定の何か」というのは、広義では、「管理対象のリソース」ですが、IDaaSの文脈で言えば、「特定のサービス」と言い換えた方がわかりやすいかも知れません。IDaaSと連携するサービスで、例えば、G SuiteのGmailなどです。
つまり、
  • ユーザAさんは、社内のLANからのアクセスに限り、Gmailを利用できる。
  • ユーザBさんは、特定の端末からのアクセスに限り、インターネット経由で、Google Driveを利用できる。
というような、利用の制限をすることができるという機能です。

「認証」に基づく「認可」

このように、「認可」されるべき主体は、「認証」によって明らかにされた「特定のユーザ」ということになります。認可されるべき条件は、「誰か」以外の要素もありますが、あくまでも、「誰に対する認可なのか」ということを中心に考えるべきでしょう。その点で、「認可」は、「認証」に依存している機能で、認可の前段階で、認証が済んでいることが求められます。

グループに対する認可

また、IDaaSでは、特定のユーザという個人ではなく、特定のグループや組織に対する認可もできるようになっています。IDaaSは、第二回の記事で書いたとおり、Identityに関する情報を保持しています。どのユーザがどのグループや組織に属しているということを知っているので、個人に対してではなく、グループに対して認可することで、管理が容易になります。例えば、
  • 経理部は、社内のLANからのアクセスに限り、Gmailを利用できる。
  • 営業部は、特定の端末からのアクセスに限り、インターネット経由で、Google Driveを利用できる。
というような認可のルールを作ることが出来ます。経理部は社外からは仕事をしないので、会社の中でだけメールが読めれば良く、営業部は社用端末で、社外からも資料にアクセスするというような仕事内容に合わせたルールを柔軟に設定することができます。このような組織やグループに対して認可する機能がない場合は、人の出入りが多いような会社では、管理が煩雑になり、最悪な場合には、意図しない人に適切でないサービスを許可してしまうなどのセキュリティ事故を招くことになります。

アクセス制御

アクセス制御については、前回の記事でも触れました。認証というレベルでも、アクセスの制御をすることが可能ですが、認証を経て、利用者が誰なのかということがわかってから、さらにその他の条件で、対象のサービスに対するアクセスを制御する方がより細かく柔軟な制御が可能になります。前述の例のように、「特定の条件」の組み立ての要素が多いほど、よりきめ細やかなアクセス制御が可能と言えます。
IDaaSは、その名称を聞いただけでは、「セキュリティ」に寄与するような機能とはやや遠いように思われますが、「認証」および「認可」の機能で実現するアクセス制御は、IDaaSで享受できる大きなメリットです。

シングルサインオン

また、IDaaSが実現する機能に、シングルサインオン(SSO)があります。この機能は後の記事でより掘り下げる予定ですが、「認可」の視点から、軽く触れておきます。
SSOは、一度認証を通れば、IDaaSが連携するサービス群に対して、個別にログインせずに、利用できるようになるという利便性のための仕組みです。ここで、利用者はSSOできるサービス群に対して、「認可」されている必要があります。つまり、SSOして良いのかということを定義する基礎的な機能として、「認可」が利用されていることになります。SSOは、実際にはIDaaS側や、サービス側でももっと多くの基礎的な機能を組み合わせることで実現していますが、「認可」も重要な役割を担っています。

他のサービスとの連携

前々回の「保存」、前回の「認証」、そして、今回「認可」は、それ単体では、単純な機能ですが、IDaaSを使うことで、得られるメリットを形作るための「基礎的な機能」と言えます。より高次な機能である「アクセス制御」や「SSO」を実現するための部品という見方もできると思います。
次回は、まだ部品とも言える機能ですが、やや聞き慣れない「プロビジョニング」という機能について掘り下げます。

   Gluegent Gate


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管理画面を通じて行っていくことになります。この設定方法については、また来月以降に本ブログで触れていきたいと思いますのでお楽しみに!

参考:
今日から始めるクラウド型ワークフロー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