2020年10月21日水曜日

アメリカ人からみた「日本の住みやすさ」

こんにちは、サイオステクノロジーGluegentサービスラインのジャレド・ウォレスです。今週は前回の記事からリストになかったもうひとつのよく聞かれる質問「日本はどうですか?住みやすいですか?」に対しての思いを説明していきたいと思います。もちろん、本記事はあくまで私の個人的な経験の元に話していますので、ご了承ください。

来日から

まず、外国人として日本に引っ越すための事前準備から話していきましょう。ビザ関連手続きはそれぞれ個人の状況によりますが、流れは大体決まっているのでそこまで個人の手間はかかりません。そのあとの物件探しはそれに比べて大変です。個人で行う場合、すべてリモートベースで契約までの手続きを対応してくれる仲介会社は珍しい存在であり、物件自体も外国人NGが多いので選択肢が結構絞られます。口座振り込みもできないので、クレジットカードで決済できる物件でなければなりません。場合によって、会社や知人の方が手続きを代わりに行ってくれることが多いのですが、そうして頂けない場合、あまりにも難しいため一時的な住まい(シェアハウス等)にする手段も珍しくありません。

ここまでくるだけで十分疲れるんですが、そのあともまだまだやらなければならないことが続きます。引っ越し自体が終わってからすぐにやることは以下のようなものが一般的です。
  • 役所で住所を登録する(在留カードに記録、住民票取得)
  • 携帯電話を契約する
  • 銀行口座開設を行う
実はこの上に書いてある通り、決まった順番で行わないとうまく手続きできません。私が初めて日本に来た時にひとまず携帯電話の契約をしようとしたら、現住所を確認できるものがなかったため1時間半ぐらいが無駄になって契約できませんでした。まず、役所で手続きを行ってから住民票を取得して、携帯電話の契約ができるようになります。口座開設も、現住所の確認できるものと電話番号がないと行えないため、最後に行うべきです。そして、来日する前に一回も考えたことがなった、これのすべての前にやらなければいけないことがもうひとつあります。

ハンコについて

来日する前に教えてくれる方はいませんでしたが、ハンコを作らなければ日本に住むのが困難であり、不可能に近いとも言えるでしょう。ほとんどの銀行で口座開設ができませんし、できる銀行が存在すると言っても、実際作るとなった際従業員側の確認作業(上司に相談、資料調べ等)によりかなり時間がかかり、労力の割に合いません。労働者も会社との契約に印鑑を押さなければ済まないのも普通でしょう。私個人も留学をした時「外国人だからサインで済ませるだろう」と思って様々な手続きにトライしましたが、結局「どうしても必要です」と言われることがほとんどでした。「申し訳ありません、これは本当に日本の良くない文化ですが…」と、説明されることが多かったです。

そこまでハンコに重みと信頼感を置くのはやはり少し格好悪いと思ってしまいますが、量販店でも作れますし、すごく困ったわけではありません。来日する外国人に対して、日本人の知人から色々教えてもらったり、役所からの情報をもらえればおそらく「外国人でも必要であることは知られていない」問題は解決されます。それより何倍もカルチャーショックを受けたのが多くの日本国民のハンコに対しての気持ちです。「良くない文化」とか「どうしようもない」と言う言葉が、「我が国はどうしても変わらない、自分で変えられない」と聞こえてきます。島国根性と言いますか、日常的にこのような文化と考え方に縛られているのが、少し可哀想だと思いました。

ローマ字の名前表記は全く考えられていない

意外と困ることですが、日本では様々なシステムがローマ字の名前表記をそもそも考えずに、作られたものが多いと思われます。外国人の場合「名前はパスポートに書いてある通りに書かなければならない」が基本ですが、なぜそれが大変なのか例で見てみます。まず、仮の名前 John Michael Smith で見てみましょう。

パスポートの名前表記(姓→名→ミドルネーム)
  • Smith John Michael
日本国内手続き(ローマ字で書かなければならない)
  • 姓:Smith(かな:スミス)
  • 名:John Michael(かな:ジョン マイケル)
ここまでだとパスポート表記で困ることはただ「ミドルネームで呼ばれがち」だけです。オンラインバンキングなどを利用する際に名とミドルネームがくっつくので少し違和感がありますが、特別な不便はありません。しかし、クレジットやデビットカードの名前表記はかなの元で出力されるので、以下のような形になります。

カード名義(かな化された名前が再びローマ字化され、名とミドルネームがくっつかれた)
  • JIYONMAIKERU SUMISU
「なんだこれ?」となりますよね。見ての通り、カード名義と本名は一致しません。多くの国内サービスはアカウント名義と支払のカード名義が一致していなければならないと言うルールがあるため、そういったサービスが使えず、かなり不便です。

手続きが終われば楽

一方、日々を過ごすだけの意味では日本(少なくとも関東)は海外と比べて楽で過ごしやすいと思います。留学の頃、料理が苦手だった私には外食が安かったのとコンビニのご飯が美味しいことが特に印象的でした。電車と新幹線が充実しているため旅行もしやすいです。国が全体的に割と小さいため、通販の配達速度もかなり早くてギリギリの注文でも間に合います。ただし、改めて考えてみると「過ごしやすい」と言うより「お金を出す分だけ過ごしやすい」と言えるかもしれません。

日本の文化と価値観になると話がまた少し違います。完全に個人によるとも言えますが、他人に迷惑をかけない・自分の価値観を他人に押さない文化もかなり快適な環境の原因のひとつと感じます。一方、ハンコや紙文化、外国人NG物件など、なかなか時代に追いついていない考え方が社会的に認められている、まだ望ましいと思われている事実に絶望を感じることもあります。

以上、個人的な「日本の住みやすさ」についての考えでした。いかがでしょうか。少ししょっぱい記事になってしまいましたが、少しでも気持ちを理解して頂けたら幸いです。
Jared Wallace

2020年10月14日水曜日

【この機能はこうして生まれた】複数行テキストの高さを設定できるようになりました+イベント開催のお知らせ

弊社が提供しているGluegent FlowはGoogle Workspace(旧G Suite)やMicrosoft 365と連携できるクラウドワークフローです。
各種サービスに追加された新しい機能についてご紹介するシリーズ「この機能はこうして生まれた」です。
過去の記事
今回は、Gluegent Flowにひっそりと追加された複数行テキストの高さ設定をご紹介いたします。
さらに、10月22日に行われるイベントについても併せてお知らせいたします。

◯複数行テキストの高さはドラッグで広げられるけれど・・・

長い間、複数行テキストの高さは固定でした。それは、ブラウザの機能で大きさを自由に変えられるためです。
たとえば、Chromeの場合、入力欄の右下をドラッグすると大きさが変えられます。
この機能があるため、弊社開発チームでは高さの調整は不要と考えていました。

◯やっぱり最初から広い枠がいい!

初期導入のためにお客様先に伺い、機能のご説明をする時に「複数行テキストの高さは変えられないの?」というご質問をいただくことが多くありました。また、クラウドコンシェルジュにも「高さを変えられないの?」といったご質問や「高さを変えられるようにしてほしい」というリクエストが多く寄せられました。
お客様にその理由を聞いてみたところ、自由記述欄にたくさんの文字を書くことが前提のモデルがあるとのことでした。
また、最初から枠が大きければ、「たくさん書かなければ!」という気持ちになるということもあるようです。スタッフ一同納得し、開発に着手しました。

◯設定方法は幅と同じ

では実際に設定画面を見ていきましょう。モデル編集画面の「入力フォーム」をクリックし、複数行テキストの入力フォームをクリックします。「表示設定」をクリックし、「入力欄の高さ」で設定します。
単位は「入力欄の幅」と同じく「px」「%」「em」の3種類から選べます。「%」「em」はフォームレイアウトで「Google Docs」や「HTMLレイアウトエディター」をご利用の際に有用です。

私は普段、サポート業務をしているため、お客様の作成したモデルを拝見する機会は少ないのですが、時々、お客様先に伺うことがあります。そういう時にお客様が作成されたモデルを見せていただく機会があります。皆様とてもこだわりを持ってモデルを作成されています。中には我々の想像を超える使い方をされているお客様もいらっしゃいます。そういった強いこだわりの気持ちに触れると、その想いに応えなければ!と感じます。



さて、この度、第2回目となる User Meeting を開催いたします。1回目はお客様に弊社ビルにお集まりいただいての開催でしたが、コロナウイルス感染症拡大防止の観点から、Zoom による配信にて行います。日頃お使いいただいているお客様も、弊社サービスに興味のある皆様も是非ご参加ください。
 開催日時:2020年10月22日 (木) 10:30〜11:35
 参加費:無料
イベントの詳細やお申し込みはこちらをご覧ください。
皆様のご参加を心よりお待ちしております。
(SUTO) 
 

2020年10月7日水曜日

【こんなこともできるの?】Gluegent Flowでよくいただくご要望と解決方法 第2回

ワークフローの導入をご検討中もしくは、他社製品を導入していて課題や不満を感じていることはございませんでしょうか。弊社では、お客様とやりとりする中で多くのご要望をいただきます。そうしたご要望をどのように実現できるかを今回ご紹介します。今回は第2弾です。もし、このブログをご覧のみなさまも同じようなご要望がございましたら、参考にしてくださいませ。



要望1「稟議書のワークフローで承認者が途中で経路を変更もしくは承認者の追加をしたい」


解決方法:

前の経路、今の経路の担当者情報は変更はできませんが、次以降の経路の担当者は変更可能です(ユーザーによる担当者の変更を許可するが選択されている時に限り)。また、申請者が申請時に経路を変更できることもできます。


設定としては、モデル作成の経路の画面で、「ユーザーによる担当者の変更を許可する」にチェックを入れます。


申請が進んだ際、承認者が経路の画面で各種変更可能です。ここに「自分を追加」「対象者を追加」すると担当者が追加できます。「×」をクリックすると今の担当者を削除することもできます。


要望2「全員が承認しないと先に進まない設定にしたい」


解決方法:

モデルの作成画面の経路設定の「承認待ち」の「実行可能な処理(ボタン)」をクリックします。



「承認」ボタンの右側のアイコンをクリックすると、「実行可能な処理(ボタン)」が表示されます。ボタンの種類を、「次に進む(全)」にしていただくことで、承認者を複数選択している場合、その全員が承認しないと、決裁者に遷移しないように設計することができます。上記を活用すれば並行処理が行うこともできます。

要望3「現在のタスクの内容や状況を画面を遷移せずにみたい。」

解決方法:管理者アカウントのタスクデータ一覧の右端の「 i 」 ボタンで、タスク詳細の画面をクイックビューとしてみることができます。



タスク詳細の画面をクイックビューでみることができます




















要望4「部門や役職を兼任しているメンバーがおり、その設定をしたい。兼任設定の方法や申請時の切り替え方法を知りたい。」


解決方法:下記流れで部門や役職を兼任の設定および申請が行えます。

1. 管理者にて所属する部門のグループアドレスに担当者を追加

2. 管理者にてロール(役職)の設定で指定の役職者の設定を追加

3. ユーザーが設定でデフォルトの部署を選択

4. ユーザーが申請に所属部署を選択し、申請作業を行う

下記にそれぞれの詳細をご説明します。



1. 管理者にて所属する部門のグループアドレスに担当者を追加

通常通り組織図をグループアドレスなどで設定を行います。

 ・G Suite版の場合は、Googleグループ

 ・Microsoft365版の場合は、セキュリティーグループ/配布グループ

 ・Gluegent Flow Plusの場合は、Gluegent Gate


 詳しくは、マニュアルサイトにて

「GluegentFlowマニュアル(管理者向け).pdf」の「Google グループで組織ツリーを構築する」

「GluegentFlowマニュアル(管理者向け)(Office 365版).pdf」の「グループで組織ツリーを構築する」

「Gluegent Flow Plus スタートアップガイド.pdf」の「部署/ユーザーを作成してみましょう」をご参照ください。



2. 管理者にてロール(役職)の設定で指定の役職者の設定を追加
ロールの設定は同じマニュアルの「ロールを作成する」の項目で作成できます。もしくは、こちらのチュートリアルの「TUTORIAL-03-サンプルモデル「休暇申請」の作成.pdf」の「ロールの設定」も参照ください。
3. ユーザーが設定でデフォルトの部署を選択

右上のギアから「設定」を選択。その際に、個人設定の「デフォルトグループの設定」のプルダウンで複数部署に所属する人は、デフォルトのグループを選択できます。



4. ユーザーが申請に所属部署を選択し、申請作業を行う

申請時の画面右上に「所属グループ」のプルダウン項目があるため、そこを選択することで、どの所属部署からの申請かを設定することができます。




いかがでしたでしょうか。こう言った要望が貴社でもございますでしょうか。もしくは、すでに導入ずみの企業様で、もしご利用できそうなやり方や機能がありましたら是非試してみてくださいませ。
(KT)  

2020年9月30日水曜日

【CEOの視点】Beyond クラウド

現在、クラウドサービスの導入はもはや目新しさはなくなり、ごく普通にされるようになってきています。 また、その範囲は幅広く、G SuiteやMicrosoft 365等のコミュニケーションツールはもちろん、ビデオ会議、ストレージ、SFA、電子押印、会計、PBXなど企業が必要なあらゆるサービスが提供、利用されている時代になってきています。 そして、現在も続くコロナ禍に対応するためのテレワークはクラウドサービスの利用促進を急速に早め、オフィスワークで当たり前と思われていたいろいろなコトに変革を迫ってきています。

セキュリティモデルの変革

たとえばセキュリティ側面では、これまではオフィスに社員がいる前提でしたので、ネットワーク等のインフラで内部を守り、インターネット上にあるクラウドサービスをいかにセキュアに使うかのみを考えていれば良かったのが、テレワーク前提での現在ではそうもいかず、インフラとクラウドサービス、さらにはデバイス等を含めて意識したセキュリティモデルが必要となってきています。
いわゆる境界型セキュリティからゼロトラストへの変革です。

beyondクラウド

こうした流れはクラウドサービス間の連携にも求められ、これからは一つの課題解決には広範囲の検討が必要になります。現在ではまだまだオンプレミスのサーバーやインフラも混在しており、クラウドとのハイブリッドな環境も同時に考慮しなくてはなりません。
単純に「クラウドを導入すれば業務改善する」といった時代は終わりを告げつつあり、クラウドをどのように協調させ、またインフラ、デバイスまで含めて、利便性を損なわずに、どのようなセキュリティモデルを作り上げるのかが大事になってきます。
いわばbeyondクラウド時代の到来でしょうか。
Gluegent シリーズに関してもそうした新時代のニーズに対応すべく、開発、機能追加してまいります。

新体制

変革という意味では、10月から株式会社グルージェントはサイオステクノロジー株式会社と統合します。これまでもグループ内の兄弟会社として連携はしてきましたが、業務マターでの連携が主であり、幅広い意見交換や体制協力をすることは少ない状況でしたが、これからはグループ内のリソースを効率よく活用できるようになります。
Gluegent シリーズの今後の発展にご期待いただけますようにお願い申し上げます。

Gluegent Gate

2020年9月23日水曜日

【2020年版】ゼロトラストの現実的アプローチ

【5分で分かる】ゼロトラストとは何か」で、ゼロトラストの概要が理解できたと思います。ただ、「ゼロトラスト」は、「パラダイム」あるいは「考え方」にとどまります。さらに、その考え方に則ってエンタープライズ向けにモデル化したものとして、ゼロトラスト・アーキテクチャが示されていますが、これも結局、抽象的なモデルに過ぎず、実際に動き、利用できる製品が示されているわけではありません。今回は、そのような少し現実世界から離れていて、自分とは遠いところにありそうな「ゼロトラスト」について、実際に自分の組織のシステムに適用を進められるパターンを考えてみます。

注目のサイバーセキュリティモデル

ゼロトラスト(Zero Trust, ZT)は、長らくセキュリティモデルのデファクトスタンダードであった、「境界型セキュリティモデル」のカウンターとして、また、クラウドサービスや、スマートデバイス、BYODなどによってもたらされた「どこでもいつでも」というワークスタイルでも、強固なセキュリティを維持するために、生み出されました。さらに、今年に入ってからの「新型コロナウイルスの流行」が、これに拍車をかける形となり、大きな注目を浴びています。

もとのパラダイムや、その考えに基づくZero Trust Architecture (ZTA)が、企業向けのセキュリティシステム全体をスコープとしているため、ネットワーク機器のようなハードウェアから、クラウドサービスのようなソフトウェアまで、広範囲のレイヤーのベンダーがゼロトラストをうたった製品を出しています。ただ、ゼロトラストに関する理解があやふやだと、その製品がどういう意味で「ゼロトラスト」なのか分からないという感じもあります。

ゼロトラストを今の環境に適用するには

世の中で喧伝されるゼロトラストのモデルは、そのパラダイムに則った理想的な世界を表しています。一方で、我々は、長く常識とされてきた「境界型セキュリティモデル」に根ざした機器やサービスをつかって、セキュリティを維持しています。今この記事を読んでいる端末がつながっているネットワークは、企業LANに属していて、インターネットからは、境界をもって隔絶されていることでしょう。内側からは、特定のプロキシサーバを経由して、特定の領域にしかアクセスできないかもしれません。外側からは、特定のIPアドレスから、特定のポートだけアクセスを許可し、それも、DMZまでだけであったりします。このように「内側」と「外側」を境界で分けて、極少数の「信頼される(Trusted)」アクセスのみを許すセキュリティが、「境界型」です。

そのような環境に、いきなり全面的に「ゼロトラスト」を持ち込むことは、困難です。境界をなくして、全てのリソースについて、都度認証・認可を確認するというのは、現実的ではないでしょう。では、このパラダイムをどのように現場に適用し、そのメリットを享受すれば良いのでしょうか。

部分的・段階的なゼロトラストの適用が現実的

ゼロトラストと境界型セキュリティは、考え方は違いますが、混在させることが可能です。むしろ、多くの組織では、ゼロトラストの部分適用と段階的な移行でメリットがある場合が多いと思います。

例えば、ある組織で、全ての情報資産を境界の中に置いていたとします。しばらくすると、物理サーバの保守切れに伴い、OSを仮想化し、IaaS上に配置することになりました。IaaSと自社データセンターは、専用のネットワークで接続され、インターネットには出ていません。この状態では、境界型のままです。また時が経ち、今度は、オンプレミスのシステムの一部をSaaSに置き換えることになりました。コスト面でのメリットもありますし、より高機能だったためです。SaaSはインターネット上で展開されていますが、重要な情報資産がインターネットを通るのは、「なんとなく不安」だったために、会社の拠点からのアクセスのみに制限することにしました。リモートのユーザは、VPNを経由して拠点からアクセスするという形です。この状態でも、まだ境界型と言えるでしょう。

さらに時間が経過すると、多くのサービスが、SaaSとして安価に提供されるようになっています。データセンター内に配置されたオンプレミスのサービスは、陳腐化し、コストに見合わなくなります。サービスのベンダーもクラウドにシフトし、オンプレミスサービスの機能は更新されないままになり、いつしか、サポート終了します。そして、SaaSが提供するサービスはより高度化するにつれて、要求されるネットワーク帯域も大きくなります。拠点からのアクセスはまだ良いかも知れませんが、VPNの帯域はいつもいっぱいです。働き方改革、コロナ禍を経て、テレワークが急速に増え、VPNを経由したSaaSの利用は限界を迎えました。もう、境界を維持する事が出来なくなっていると言えるでしょう。

ここで、ゼロトラストの出番です。すでにいくつも使われているSaaSを、VPNを経由せずにインターネットでそのまま利用できるようにします。インターネットのような誰も信用できないネットワークにおいても、アクセスする人に対して、「その人が誰で(認証)」、「その情報にアクセスが許可されているか(認可)」を確認し、利用を許可するようにします。そのためのサービスとして、IDaaSを利用します。多くのSaaSは、認証を他のサービスに任せることができるようになっています。任された認証は、IDaaSが一手に引き受けます。IDaaSには、どの人がどのリソースにアクセス可能であるかを定義しておきます。IDaaSが提供する認証認可は、物理的な位置や、ネットワーク、サービスが複雑で、曖昧になってしまった境界に影響されることなく、管理対象のリソースに対してアクセス権があるかどうかを常に確認することにより、セキュリティを維持します。

ただ、この組織がもつすべての情報資産が、ゼロトラストで守られているわけではありません。データセンター内にあるSaaSや、IaaSに出していないサービス、ファイルサーバなどは、境界型セキュリティで守られたままかも知れません。しかし、すべてをゼロトラストで管理しなければいけないものでもありませんし、そうするべきでもありません。BYODやテレワークで利用したいというニーズがない情報資産であれば、境界型のまま維持するのも一つの選択肢です。「明確な境界」を定義することが出来、境界の守りが鉄壁であれば、まだ有効なセキュリティモデルです。ただし、ラテラルムーブメントのような境界型につきもののリスクについては、考慮する必要があります。多要素認証を使うなどで、境界を突破されにくくすることと、リソースに対するアクセス権を必要最小限にしておくことで、突破された場合でも被害を最小にすることができます。

ゼロトラストを実現するIDaaS : Gluegent Gate

Gluegent Gateは、弊社が提供するIDaaSです。豊富なID源泉に対応するID管理や、多くのサービスに対応するプロビジョニング、柔軟で強固なセキュリティを提供する認証認可、高度な利便性を提供するシングルサインオンなど、ゼロトラストの中心的な役割を担う、IDaaSとして、必要十分な機能を備えています。2011年に提供を開始したGluegent Gateは、多くのお客様に高いセキュリティと利便性を提供し続けています。ゼロトラストの文脈においても、二段階認証や、端末証明書等により、信頼されないネットワークにおいても十分安全なセキュリティを提供します。正しく許可された人だけに確実にアクセスを提供することが可能です。

また、Gluegent Gateは、IDの源泉として、外部のADやLDAPサーバを利用することもできます。これにより、ID源泉を境界の中に置いておいたとしても、境界の中でも外でも統合されたIDの管理が可能となります。上で述べたようなハイブリッドな構成であったとしても、柔軟に対応できます。

システムの構成は、それぞれの組織で千差万別といえますが、ほとんどのシステムは「境界型」で守られていることでしょう。しかし、我々利用者を含め、システムを取り巻く環境は大きく変わってきています。伝統的な「境界型セキュリティ」だけで組織の情報資産を守るよりも、ゼロトラストの概念を持ち込み、多くのニーズやより高い価値のために構成を変えていくことが、組織のチカラにつながります。コロナ禍の世界的に厳しい状況で、競争力を維持し、さらにビジネスを加速させるために、変化することを選択する時です。

(ま)
  Gluegent Gate

2020年9月16日水曜日

これが欲しかった!Office 365版にも対応した「Gluegent Flow マスター管理機能」リリース

弊社製品Gluegent Flowに以前からご要望のあった「マスター管理機能」が遂にリリースされました。G Suite/Office 365(Microsoft 365)連携版の他、Gluegent Flow Plusでも同様にご利用いただけます。


マスター管理機能とは?

そもそも「マスター」をひとことで説明しますと、「日々更新されることのない、ある程度決められたデータのまとまり」となります。例えば都道府県や社員情報などですね。Gluegent Flowでは、既にこのようなマスターをモデルで利用可能でした。リスト系入力フォームの選択肢設定(「テキストで直接定義」/「スプレッドシートで定義※G Suite版のみ」)で選択肢に設定されたものがそれにあたります。ただし「テキストで直接定義」では、複数のモデルに同じマスターを設定していた場合、後でマスター自体に更新が発生した際に、全ての対象モデルの修正が必要になります。「スプレッドシートで定義」ですとその問題は解消できますが、Office 365版では利用不可能となっていました。そこで、今回新たにリリースされたマスター管理機能によって、そういった問題を克服できます。

実際の設定

では、実際の設定はどのようになるのか、以下に概要を記述することにします。まず、予めマスター管理画面からマスターを登録します。※画像は、マスターデータ登録画面からモデル内でマスターを選択したところまでを表示しています。



そして申請時にリスト選択した画像がこちらです。つまり選択肢の元ネタに「マスターデータ」が追加されたということなので、一般ユーザは従来どおりご利用いただけます。



なお、画像ではマスターを直接入力で登録していますが、CSVによるアップロードとスプレッドシートによる参照(※G Suite版のみ)をサポートしています。特にOffice 365版をご利用中の場合には、CSVによるマスター登録はご活用いただける場面が多いのではないかと思っております。

最適な利用ケース

様々なモデル内でよく使われる「決まった選択肢」をマスター管理機能で一括管理するとよいでしょう。冒頭に例に挙げた都道府県や社員データ以外にも、入力選択用の部署や各種手当、製品データ(メンテナンスが必要となるかもしれませんが)など、様々に考えられるものがありますが、それらを事前に登録しておき、モデルでご利用いただくことをオススメします。なお、マスターに変更があった場合、マスター管理画面で対象のマスターを更新して保存すれば、モデル側は再度編集せずに、申請時に新しいマスターの選択肢が反映されます。この点からも、マスター管理機能を積極的にご活用していただければと思っております。

注意点

・登録できるマスタデータには制限があります。CSVの場合は8MBまで、スプレッドシートの場合は100万セル以内、直接入力の場合は800KBとなっています。なお、スプレッドシートをデータとしている場合、スプレッドシート更新後は一度マスタデータ画面から再度保存してマスターデータの更新を行う必要があります。
・自動機能の「スプレッドシート行追加」によって更新されたスプレッドシートを、自動的にマスターに反映する機能はございません。


以上、マスター管理機能の概要を述べてきましたが、「表示列制限」「フィルタ」という、ご紹介しきれていない機能がございます。そのあたりにつきましては、後日アップしたいと思います。
(Fuji)

 

2020年9月9日水曜日

日本語が喋れる外国人あるあるベスト5

はじめに

外国人が長く日本にいると絶対に言われたことのある・飽きた台詞ベスト5をまとめてみました。こちらはあくまで私の個人的な経験と友達と話した内容で書いたものになりますが、少しでも笑って、最後まで読んでいただければと思います。

5. 英語メニューもありますよ!

話が通じている時点では多分不要です。「漢字が読めないかも!」という気持ちも分かりますが、最初から日本語メニューと一緒に出すか、頼まれた時に出した方がいいと思います。日本語メニューを配っている最中に外国人だけに「英語メニューありますが要りますか?」が最も居心地が悪いパターンです。

4. どうして日本語を勉強しようと思ったんですか?

YOUはなにしに日本へ?の影響かもしれませんが、私の経験では日本人がよく「外国人がなぜか日本に興味を持って日本語を勉強することにした」と思いがちです。残念ながら、面白いキャラを除いて、特にきっかけがあって日本語を勉強しようと思った方は意外と少ないと思います。出身地によって外国語が義務教育だったりして、なんとなく他の言語より日本語を選んだというケースは珍しくありません。
きっかけがあったとしても、そのきっかけ=勉強を続けた理由ではないケースも多いと思います。私でも、高校生の時にドラゴンボールZとナルトが好きでスペイン語やフランス語より日本語を勉強することにしたのですが、アニメが好きだったから大学に進学してからでも勉強を続けようと思ったわけではありません。日本人の留学生と交流して友達が出来たり、言語学自体に興味を持ったりして続けたわけで、「きっかけ」より「勉強を続けた理由」の方が充実した会話になると思います。

3. 英語教えてくれる?!

正直、無理です。本気で外国語を話せるようになりたければ人にお願いする時点でもう間違っています。教えたくても教えようがない、という状況です。ネイティブスピーカー一人で充実した外国語の教育ができるのは現実的ではありません。プログラミングや数学と同じように、まずは自習か教育プログラムから始めて、何かがわからない時に知識のあるネイティブスピーカーをリソースにするのが正しいです。外国語で会話相手を付き合ってもらったり、使っている言葉を辞書で見つかった言葉より「一般的に使われる単語」に直してもらったりするなど、自習ではなかなか不可能なことをお願いするのが効果的だと思います。
私の日本語勉強にあたってよく友達にお願いしていたのが、「この文章、自分だったらどんな言い方をする?」と聞いて、自分の不自然な日本語をなるべく自然な言い方に直してもらうことでした。ただし、英語会話だけで上手になるわけでもなく、自習・プログラムとのバランスを持たなければならないと思います。

2. どうして日本語がそんなに上手いんですか?

ハーフであるとか、子供の頃から学んでいるとか、様々な事情で個人差はありますが、誰だって何かの秘密があって簡単に日本語が上手になったという訳ではありません。殆どの場合、何年間授業と自習の勉強の上、完全に日本語に囲まれる環境(留学)に時間を過ごすことが理由になります。よくあることですが、聞く側として本当に知りたいのがなぜ日本語が上手いではなく、「発音」や「文法」とか、とある細かい箇所についてです。それでもちゃんと上手になった理由があって、それに認識できて、言語学が詳しくない人に説明するのが難しいことなので、聞かれても答えにくい質問です。

1. 日本語お上手ですね。

絶対に言われるナンバーワンです。褒めるつもりで言っている日本人の皆さんの気持ちがよく分かりますが、日本語の勉強が始まったばかり、ものすごく下手の時からでも言われてきたセリフであるのが事実です。中高学生に「偉いね」を言うと同じように「外国人扱いされている」感が溢れます。それに数え切れない程度で言われます。コンビニで弁当を購入したら店員さんに言われます。銀行で手続きしたら言われます。スタバの店員がコーヒーコップにも書かれたことがあります。申し訳ありませんが、セットフレーズとしては完全に意味がなくなり、「はいはい」となって飽きれてしまいます。私は失礼だと知りながら謙遜さえしなくなったぐらい言われたことがあります。感動してどうしても褒めたければ、「熟語」や「相槌」など、なるべく具体的なところを選んで褒めた方が外国人としては受けやすいと思います。
個人的な意見になってしまうのですが、「日本語お上手ですね」と言われる事に関して一番嫌いなところが「外国人であること以外に私に興味がない」という点です。当然かもしれませんが、自分のアイデンティティが「外国人である」と思っていませんし、人と交流していて他に話したいことが沢山あるのに、また毎回同じ言語の話ばかり聞かれると少し寂しいです。

まとめ

以上、私が選んだ「日本語が喋れる外国人あるあるベスト5」をご紹介させて頂きました。いかがでしょうか。心当たりの台詞はありましたでしょうか?もしあれば恥ずかしがらず、これからの外国人との交流の参考になれば幸いです。

2020年9月2日水曜日

【新機能紹介】年度末でタスク番号の連番をリセットできるようになりました。

弊社でご提供しているクラウド型ワークフローサービス「Gluegent Flow」は、タスク番号という番号が自動で採番されます。この番号は日や月や年単位で数字をリセットできます。この度、年度単位で数字をリセットできるようになりましたので設定や利用方法についてご紹介いたします。



◯タスク番号のリセットはシーケンス管理で

冒頭でも触れたように、Gluegent Flowでは1つの申請(タスク)毎に「タスク番号」が振られます。管理画面の「シーケンス管理」でシーケンスを作り、モデル編集画面で選択します。
サンプルのように、日付や固定文字列と連番が振られます。この連番の「クリアするタイミング」が「毎日」「毎月」「毎年」「クリアしない」から選択できます。
このクリアするタイミングで「年度」が使えないか?というご要望をたくさんのお客様から熱望されていました。

◯長いβ期間を経て新機能登場!

これまではβ機能として、一部のお客様に限りご提供していました。クリアするタイミングが1年に1回ですので、万が一不具合があったらお客様にご迷惑がかかってしまいます。幸い不具合もなくβ期間を終了し、満を持してご提供を開始できました。

◯利用開始はクラウドコンシェルジュへの依頼から

この機能をご利用いただきたいお客様はお手数をおかけいたしますが弊社サポート「クラウドコンシェルジュ」へご依頼ください。HPからでもメールからでもご依頼いただけます。

◯設定は2ステップ

クラウドコンシェルジュへご依頼いただき、設定が完了した旨の連絡がきましたら、まずは年度末の設定を行っていただきます。
※この操作は管理者権限を持つユーザーで行ってください。
Gluegent Flowの画面右上のギアアイコンをクリックし「ドメインの設定」をクリックします。
ドメインの設定画面で「ドメイン設定」>「フロー設定」の項目までスクロールしてください。年度設定で年度の最終月を選択してください。例えば4月1日から年度が始まる場合は「3」を選択します。「設定を保存する」をクリックすると設定完了です。


続いてシーケンス管理でクリアするタイミングを設定します。
選択肢に「年度」「半期」「四半期」が増えていますので、ご希望に合わせて選択してください。

これまでタスク番号のリセットのタイミングに不満があったというお客様はぜひご依頼ください。追加費用は一切かかりませんので、ご連絡をお待ちしております。
(SUTO) 
 

2020年8月26日水曜日

【こんなこともできるの?】Gluegent Flowでよくいただく疑問と解決方法 第1回

ワークフローの導入をご検討中、もしくは、他社製品を導入していて、課題や不満を感じていることはございませんでしょうか。弊社では、お客様とやりとりする中で、多くのご要望をいただきます。そうしたご要望をどのように実現できるかを今回ご紹介します。もし、貴社でも同じようなご要望があるようでしたら、参考にしてくださいませ。  



要望1「決裁には関わらないが承認前に特定の人や部署に申請を閲覧させたい」

解決方法:メール送信自動処理で実現することができます。宛先に指定の人を追加することで、指定のタイミングで自動でメールが通知されます。




参照権限がない人向けには、「参照許可設定の追加」の自動処理を使用します。


もしくは、フォローを入れておくことで各申請の状況が閲覧できます。
フォローの箇所でユーザーを選択しておくことで、申請状況の共有することもできます。



要望2「決裁後の事後処理として総務が別途入力する処理もワークフローに組み込みたい」

解決方法:まず経路を作成します。その際に、「終了」ボタンは、5.総務処理にします。

1.申請
2.部長確認
3.取締役確認
4.社長決裁
5.総務処理
 
その後、実行可能な処理(ボタン)の名称を下記通り変更
4.社長決裁 「承認」→「決裁」
5.総務処理 「決裁」→「総務処理」



そうすることで、ワークフロー自体は、決裁が完了しても終了せず、総務処理が完了したら終わる形になっています。その後、「経路ごとの表示・編集設定」で実際に入力させたい項目を別途指定して設定完了になります。

要望3「去年の承認された稟議書の一覧や、購入申請書の一覧を一括でダウンロードしたい」

では、解決方法:下記の流れでダウンロードすることができます。
 1、Gluegent Flowの管理者にダウンロードする人を追加
 2、右上の「設定」を開く
 3、左下の「タスクデータ一覧」から指定の条件で検索
 4、右下の「検索」の右の▼を押し「ファイル出力」を押下
 5、指定の申請書のCSVがZIP形式でダウンロードできるポップアップが表示されます




いかがでしたでしょうか。こう言った要望が貴社でもございますでしょうか。もしくは、すでに導入ずみの企業様で、もしご利用できそうなやり方や機能がありましたら是非試してみてくださいませ。

 
Gluegent Flow

2020年8月19日水曜日

【5分で分かる】ゼロトラストとは何か

ゼロトラスト(Zero Trust, ZT)という用語が、セキュリティを説明する際に頻繁に使われるようになりました。この記事では、5分で(ある程度まで)わかるように解説します。  


注目のサイバーセキュリティモデル

「ゼロトラスト」を、出来るだけ端的に表すと、  

「静的なネットワーク境界」で防御する方法から、「保護対象へのフォーカス」により防御する方法に移行するサイバーセキュリティの一連の考え方

ということになります。理解するためのキーワードは、脱境界型、非境界化、性悪説です。この考え方自体は、2003年あたりから議論されていましたが、近年急速に形をなしてきたと言えます。その成果の一つとして、NIST(アメリカ国立標準技術研究所)が、ゼロトラストの考え方とそれを実装するためのプランとなるZero Trust Architecture (ZTA)に関する文書をまとめています。2019/9/23に、Draft1が公開され、2020/8/11にfinalが出たばかりです。


Abstractだけでも見ておくと、より理解が進むと思いますが、ここでは、5分である程度まで分かるために、旧来のモデルと、ゼロトラストで提唱するモデルを対比してみましょう。

境界型のセキュリティモデル

これまでのセキュリティでは、ファイアウォールの内側は安全な領域というように、静的なネットワークの区切りをそのまま「セキュリティ的に安全かそうでないか」の境界とするモデルが一般的でした。このモデルで境界の外か中かで、信頼できるかどうかを判断しています。境界を通過する経路だけを強固にしておけば、一定以上の安全が確保できるものでした。ただ、このモデルでは、境界内の信頼された空間内からの攻撃には、対応できません。この攻撃は、ラテラルムーブメント(Lateral Movement: 横方向の移動)と呼ばれます。何食わぬ顔をして、隣の席に座っている隣人が、悪意ある攻撃者である可能性を想定していないというモデルです。分かりやすく、人の行動に例えると以下のような状況です。

厳重な入退室ゲートがあるオフィスで、隣の席で作業をしている隣人は、ゲートを通ってきているし、通行証のようなものを持っているように見える。さらに、このところ毎日見かける人で、日常的に、施錠もされていないキャビネットの資料も閲覧している。

性悪説のセキュリティモデル

ゼロトラストのモデルでは、境界の内外で信頼出来るか否かを評価する形をとらず、アクセス権限があるかどうかを、継続的に評価して、リソースを保護します。前述の「隣の席に座っている隣人」の例でいえば、以下のような運用になります。

普段見慣れた隣の席の人が、キャビネットの資料を見たいというので、まず、その人が本人かどうかを確認し、その資料を閲覧する権限が記載されたリストに存在するか確認した。アクセス権限の確認は、閲覧の機会の度に実施される。

このモデルであれば、常にアイデンティティの確認とアクセス権限の評価が実施されるため、ラテラルムーブメントによる攻撃には強いと言えます。

なぜ、今ゼロトラストが注目されているのか?

では、なぜ、ゼロトラストが注目されているのでしょうか。これまで、強固な境界を設け、一点でアイデンティティとアクセス権限を確認するモデルで、一定の安全を確保出来ていたはずです。既存のインフラストラクチャは、それを実現するように作られていますし、一点集中で確認した方がコストも削減できるはずです。 
 ゼロトラストが議論され、注目されるのは、世の中のワークスタイルやサービス形態の変化によるものが大きいようです。以前であれば、物理的、あるいは静的なネットワークの境界を設けることが出来ましたが、現代では、境界を定義する対象が高度に複雑になってしまいました。テレワークや、BYOD、クラウドベースのサービスなど、多様で今後も変化し続けることが見込まれる環境に対して、境界を維持し続けることが困難になってきました。 境界型のセキュリティモデルでは、境界が守られていることが前提です。境界が崩壊した段階で、信頼されている前提の資産が危険に晒されることになります。また境界が侵されていたとしても、それが明確になるのは、被害が明るみになってからです。長期間に渡って、人知れず、被害が拡大することもあるでしょう。 ゼロトラストモデルであれば、そもそも全てを信頼せず、常に検証するため、事故があった場合でも、早期に発見でき、規模も小さくなることが期待できます。

IDが境界になったんじゃなかったの?

少し前に、従来の境界型セキュリティモデルの次の形として、「アイデンティティが新しい境界になる」と言われました。ゼロトラストは、これを更に推し進めた形と捉えることもできます。「ID=新しい境界論」は、理解しやすい「境界」を静的なものから開放し、より論理的で変化に対応しやすい形で表現したものです。ゼロトラストは、「境界」という概念を廃することで、「境界を超えてさえいれば、無条件に信頼される」という脆弱性に対抗したと言えます。ゼロトラストモデルにおいても、アイデンティティは中心となる概念であり、ある意味それが境界であるという状況に変化はありません。ただ、それが継続的に評価されるという点が、異なります。

現実にそんな構成できるの?

既存のネットワークセキュリティは、暗黙のうちに、境界型を前提としています。これからは、ゼロトラストで行きましょうと、すぐに変えられるものでもありません。また、ゼロトラストは、セキュリティについてのモデルや、考え方、捉え方であって、それだけでは、実際に動くものではありません。ゼロトラストを前提として、より実装を見据えたZero Trust Architecture(ZTA)も、まだ高度に抽象化されたレベルでの構成案です。ただ、これまで絶対の前提だった境界型のモデルを否定し、より柔軟で強固なセキュリティを目指したゼロトラストモデルに根ざしたサービスや製品が利用可能になるでしょう。
弊社が提供するIDaaS「Gluegent Gate」も境界を設けない、ゼロトラストを実現するサービスと言えます。急速にニーズが高まる複雑なワークスタイルにも、柔軟で安全なサービスを提供できます。旧来の境界型のセキュリティに不安を感じる方は、ぜひご相談ください。
(ま)

  Gluegent Gate

2020年8月5日水曜日

セキュリティサービスご導入…の、その前に

現在の情勢から、テレワークへの移行が加速している模様です。そのような中、組織でその移行をご担当される方は、導入にあたってどのような点を考慮されるとよいのでしょうか。今回は、弊社製品Gluegent Gateを例にとって、そのあたりを簡潔に述べたいと思います。ただ、どのような製品/サービスであっても、進め方は同様になるかと思います。


なによりもご要件を確定する

まず弊社製品Gluegent Gateですが、クラウドサービスへのSSO(シングルサインオン)やアクセスコントロールを特徴としたサービスとなっております。私はその職掌上、左記製品のご契約前のご相談への対応や、ご契約後の導入支援を行うことが多いのですが、その際「とにかく早急に端末制限を行いたいのですが…」といった、ざっくりとしたご依頼も度々見受けられます。組織のセキュリティ担当者に指名されたけれども、いざ実施するにあたり、具体的にどのようにすればよいのか?と戸惑われているケースでしょうか。このような場合、Gluegent Gateであればまずは以下の点をヒアリングすることでご要望を整理し、その上でご要件を確定することにしています。

・(特にご契約前の段階で)Gluegent Gateとの連携を想定されているクラウドサービスやアプリケーション(特にスマホアプリ)はどのようなものですか?
・(特にご契約前の段階で)ID源泉となるADやLDAPはご利用されていますか?また、ユーザ/グループ情報はADやLDAPから取得することを想定されていますか?
・対象のご利用端末は、PC/スマホ/タブレットのうちどれ(または複数)になりますか?
・社内ネットワーク内でのご利用、またはキャリア回線/公衆回線などからのご利用はありますか? ・クライアント証明書による端末制御は必要ですか?また、クライアント証明書の配布方法に対するご要望はありますか?

以上によって、おおよそのご要望は把握できますので、それに沿ったご提案が行えることになります。どのような製品/サービスでも、「実現出来ること」の範囲があります。従いまして、ご要望にそえる点、そうでない点を明確にして、まずはご要件を確定させることが重要になるでしょう。

利用者への負担を可能な限り軽減

セキュリティ製品を導入しても、利用者側にとって操作が難解であったり、また従来との変化が大きかったりすると、作業効率が落ちるといったデメリットが強調されてしまうことにもなりかねません。そこで、例えばGluegent GateのSSOにより、複数クラウドサービスへのログインが都度発生ではなく1度になるように集約することで、結果的にID/パスワードは1つだけ覚えておけば良くなること、認証もID/パスワード(従来と同じもの)+証明書といったバランスの取れた構成とするなど、ユーザへの負担を極力軽減することがポイントとなるでしょう。

移行作業発生の可能性

既にクラウドサービスをご利用されている状態でGluegent GateとのSSO連携を行う場合等、移行作業が発生するケースがあります。そのため、できるだけ管理者とエンドユーザへの負担が大きくならないよう検討する必要がありますし、また事前の周知もふまえたスケジュール調整も重要になります。

費用面への考慮

どのような製品でもそうですが、高機能になればそれだけ費用が嵩みます。例えばよくご質問されるケースとして、「その端末にしかインストールできないようなクライアント証明書はありますか?」というものがあります。結論としましては、そういった製品は存在しますし、更には端末自体を制御する製品(EMM等)や仮想化端末といった製品もあります。ただこういった製品は一般的に高額になる傾向にあるため、ご予算を考慮してご検討されると良いかと思います。

継続的なご運用を

セキュリティの強度が確保できて、かつ利用者側も不便なく利用できていたとしても、管理者への負担が大きくなってしまっては、継続的なご運用が難しくなってしまうことでしょう。管理者の担当業務には、社員の入退社や異動、新規サービスの追加導入、利用端末の管理など、多岐にわたります。そういったことへの対処として、例えばGluegent Gateであれば、プロビジョニング機能を利用することで(プロビジョニング対応している)複数のクラウドサービスへのユーザ管理を一元化できたり、クライアント証明書の一括申請機能など、様々な便利な機能がございます。こういった機能を事前に把握してご活用いただくことで、ご無理のないご運用を目指していただきたいと思っております。

以上、セキュリティサービスご導入に際しての概要やポイントを、特にGluegent Gateを例にとってご説明してきました。導入にあたっては、製品それ自体の特徴だけではなく、継続的なご運用までをご検討いただくことが肝要となるかと思いますので、製品の担当者とそれらを踏まえて事前にご相談されると良いのではないでしょうか。それでは、これからご導入をご検討されている場合のご参考になれば幸いです。
(Fuji)


Gluegent Gate

2020年7月29日水曜日

AWSのロードバランサーでGluegent Gate認証をしましょう

皆さん、こんにちは。グルージェント開発部のジャレド・ウォレスです。クラウドサービスの普及にともない、物理的なサーバーなどの社内インフラをクラウドに移行している会社は少なくないでしょう。今回の記事では皆さんにAWSクラウド上にあるインフラにGluegent Gateの認証を連携し、楽でよりセキュアなアクセス方法をご紹介していきたいと思います。具体的には、Gluegent Gateの汎用SAMLをAmazon Cognitoと連携させ、ロードバランサーで認証を行ってみます。

構成の背景

AWS環境に社内で良く使うアプリがEC2インスタンスに稼働している前提とします。実は特定のインスタンスではなくても、ECSなど、EC2上のターゲットグループの対象になるものであれば様々なサービスが利用可能になります。本記事ではシンプルに説明するためにEC2インスタンスに静的コンテンツを提供するnginxサーバーを用意しました。

インスタンスのDNS名をブラウザーでアクセスしてみれば、アプリのページが表示されます。
http://ec2-xx-xxx-xxx-xx.ap-northeast-1.compute.amazonaws.com/
(※セキュリティーグループのルールによって直接アクセスできない、または特定のソースIPでないとアクセスできない場合があります)

ロードバランサーを作成します。すでに利用されている方はセキュリティーグループとロードバランサーのルールを確認しましょう。

ロードバランサーの作成

EC2コンソールからロードバランサーの画面を表示し、「作成」ボタンを押します。

Application Load Balancerを選ぶ
基本設定、リスナー、アベイラビリティーゾーンを定義する
リスナー以外の設定は任意です。リスナーはできるだけHTTPSを使いましょう。証明書を用意するのが厳しい場合、HTTPリスナーのみでの作成になり、Gluegent Gateによる認証は正常に動作しない可能性があります。後ほどリスナールールを定義する時にHTTPからHTTPSのリダイレクトルールを含めて説明します。

デフォルト証明書を選択する
アクセスされるドメインの証明書を選択します。

セキュリティグループを定義する
HTTPとHTTPSの接続を受けますので、80と443を開けます。ソースは任意で、社内IP指定でも構いませんが、Gateで認証を行うため特別な事情がなければ任意の場所でも安全と思われます。

ルーティング設定を定義する

こちらのターゲットグループの設定は自分のアプリによります。私が使っているnginxは80になっているので、そのままで問題ありません。

ターゲットを登録する
EC2インスタンスを下の方から選択して、「登録済みに追加」のボタンで登録済みターゲットのリストに追加します。

次の画面から内容を確認し、「作成」を押します。
ロードバランサーが作成されます。アプリインスタンスのセキュリティグループにロードバランサーの通信を許可するルールを追加しましょう。

HTTPリスナーのリダイレクトを設定する
転送ルールを削除し、リダイレクト先のルールを追加します。「更新」ボタンを押します。

念のため、ロードバランサー経由のアクセスを試します
https://example-app-lb-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com/
または(ドメインのDNS設定を完了した場合)
https://my-app.my-domain.com/
無事にアクセスできましたね。では、Cognitoの処理に進みましょう。

Amazon Cognitoのユーザープール作成

Amazon Cognitoのコンソールからユーザープールの管理を選択し、「ユーザープールを作成で」始めます。

プール名を入力し、「ステップに従って設定する」を選ぶ
必要な標準属性を指定する
こちらのテキストをじっくり読んでいただけると「プールの作成後に、これらの要件を変更することはできません」という点が目立つと思います。アプリによりますが、プール作成時に何が必要なのかはまだ未定の場合、または変わってくる可能性がある場合この項目を未入力(メールさえも外す)ことをおすすめします。

ここから確認画面までデフォルト設定で問題ので、確認画面まで「次のステップ」で進みます。最後の画面で内容を確認したら「プールを作成」を押します。
CognitoでSAML IDPの設定を行う前にGluegent GateのSAMLメタデータを取得する必要があります。

Gluegent Gateの管理画面にログインし、「システム」メニューから「テナント情報」の画面をアクセス
メタデータのダウンロードが終わりましたら、Amazon Cognitoの画面に戻り、左側のメニューの「フェデレーション」に「IDプロバイダー」をクリックし、SAMLを選択します。

SAML設定を行う
Gluegent Gateの管理画面から取得したSAMLメタデータファイルをアップロードし、Gluegent Gateをプロバイダー欄に入力してから作成ボタンを押します。そうすると、以下のように「アクティブなSAMLプロバイダー」下に表示されます。
左側のメニューの「全般設定」に「アプリクライアント」にアクセスし、「アプリクライアントの追加」をクリックします。

アプリクライアント名を入力し、アプリクライアントを作成する
デフォルト設定で問題はないので、アプリ名を入力しアプリクライアントを作成します。ここに「詳細」を押すとアプリクライアントのシークレットが表示されます。このシークレットは後ほど重要になりますので、この画面で確認できることを覚えてください。

左側のメニューの「アプリの統合」から「アプリクライアントの設定」をクリックする
有効なIDプロバイダで先程作成したGluegent Gateにチェックを入れ、コールバックURLを入力します。尚、ロードバランサーで認証を行う場合、コールバックURLは https://<アクセスのドメイン>/oauth2/idpresponse という決まった方式でなければなりません。カスタムドメインをご利用の場合はそちらの入力してください。

左側のメニューの「アプリの統合」から「ドメイン名」をクリックする
Amazon Cognitoドメインを取得します。アプリのアクセスドメインではないので、任意になります。また、自分が所有するドメインでも構いません。

Gluegent GateのSAMLサービス設定

Gluegent Gateの管理画面に戻り、「シングルサインオン」から「SAMLサービスプロバイダー」をクリックします。
入力する項目は以下になります:
  • 割り当てるライセンス:利用可能なライセンス
  • サービスID:任意アプリの名前
  • サービス名:任意サービスの名前
  • エンティティID:「urn:amazon:cognito:sp:<プールID>」
  • Assertion Consumer Service:https://<設定したドメイン名>/saml2/idpresponse
    • https://example-app.auth.ap-northeast-1.amazoncognito.com/saml2/idpresponse
  • アクセス先URL:設定したコールバックURL

設定ができたら「正常に保存されました」と表示されます。

最後にロードバランサーのHTTPSリスナールールに認証アクションを追加します。
アクションの追加ボタンに「認証」を選択し、作成したCognito ユーザープールとアプリクライアントを選択します。

動作確認

これで設定完了します。ブラウザでアプリをアクセスしてみると、Gluegent Gateのログイン画面が表示されます。
https://example-app-lb-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com/
または(ドメインのDNS設定を完了した場合)
https://my-app.my-domain.com/
ログインを完了したら、問題なくアプリのページが表示されます。

まとめ

いかがでしょうか。このように、CognitoのユーザープールとGluegent GateのSAMLサービスプロバイダー機能を上手く活かしてAWS EC2上のアプリに認証を連携することができます。また、ロードバランサーのターゲットになるものであればなんでも連携できるものなので、Dockerでさえ起動できれば簡単に認証を設定できるようになります。

ジャレド・ウォレス