2019年11月6日水曜日

ワークフローのモデルやカテゴリの並び順が自由に変更できるようになりました!

Gluegent Flowをご利用いただいているお客様から、多くいただいていたご要望にお応えし、このほどモデルやカテゴリの並び順を変更できるようにいたしました。

◯今までのモデルやカテゴリの並び順

これまで「モデルやカテゴリの並び順の変更の仕方を知りたい」というご質問を多くいただいておりました。「モデルやカテゴリは名前順なので変更はできません。名前の頭に数字やアルファベットを付与して並び順を制御してください」とご案内していました。これまで使っていた申請書の名前を変えることに抵抗があるので、仕方なく諦めていたお客様もいらっしゃるかと思います。
モデルやカテゴリを並び替えたいというご要望も多くいただいておりましたので、この度モデルやカテゴリの並び順を変更できるよう仕様変更を行いました。

◯並び順の変更方法
モデルやカテゴリの並び順の変更方法はとても簡単です。
モデルの場合は、「モデル一覧」を表示します。
モデルアイコン・モデル名の左の「≡」をドラッグ(マウスの左ボタンを押しながら上下に移動)します。左ボタンを離すとその位置に移動します。
カテゴリの場合は「カテゴリ管理」を表示します。同様に「≡」をドラッグします。

◯新しくモデルやカテゴリを追加したときの挙動
モデルやカテゴリの並び順が変更できるようになったことでモデル作成時の挙動に変更があります。
仕様変更前はモデルやカテゴリは名前順に並んでいたので作成されたモデルやカテゴリもそこに追加されていました。
仕様変更後は作成されたモデルやカテゴリは一番下に追加されます。
作成したモデルを並び替えてお好みの場所に移動してください。

いかがでしたでしょうか。これからもお客様からいただいたお声にどんどんお答えしていきたいと考えています。皆様も「こんな機能が欲しい!」「もっとこうだったらいいな!」というご意見がございましたらどんどんお寄せください。
(SUTO)

 

2019年10月30日水曜日

ビジネスチャット導入が決定した。でもどうしたらいいの?

昨今、ビジネスチャットの導入事例がどんどん増えています。 ですが、いざ導入が決定された際は、どういったことに気をつける必要があるでしょうか。

ビジネスチャットは、やはり即応性が肝心

まず、そもそもですが、チャットは即応性が肝になります。場所にとらわれず素早くレスポンスする、つまり社内に限らず社外でも積極的にスマホ等のデバイスによってビジネストークに参加することで、ビジネスチャットのメリットが活きてきます。

秘匿性の高い情報を守り、かつ利便性もそのままに

ただし、ビジネス上のやりとりをしているということは、秘匿性の高い情報が流れているということになります。これらの情報は、当然外部に漏洩してしまうような事態は絶対に避けなければなりません。そのためには、予め決められた「許可された人」のみの閲覧に限定されている必要がありますし、また、社外での閲覧に際しては、「許可された端末」のみで行われるように管理されているべきでしょう。このようなセキュリティ運用ポリシーが守られていることによってはじめて、安全かつ迅速なチャットサービスの利用が確保されることになります。

とはいえ、上記のようなセキュリティを実現するために、セッティングや操作面で管理者や一般ユーザに難しさを感じさせてしまうと、心理的負担が上がってしまい、折角のサービス利用が敬遠されてしまうことも考えられます。従って、安全性と利便性を天秤にかけて、バランスのよい運用方法を検討する必要があります。

実際の運用設定はどのように?

では、特にセキュリティ対策が必須となる社外での端末利用について、どのように運用設定を構築していけばよいのでしょうか。

結論としては、サービス利用にあたってID/パスワード入力による認証は必ず行うものとし、社外で利用するスマホ等のデバイスでは、加えてクライアント証明書のチェックによる「多要素認証」とすることが、現在における一般的な現実解になるかと思われます。つまり、クライアント証明書がセットアップされた端末を社外で利用可能な「許可された端末」とすることになります。これを実現するにあたっては、社内(外部が固定IPのネットワーク内)ではID/パスワード認証のみ、それ以外ではID/パスワードとクライアント証明書による多要素認証となるような認証ルールを構築することになります。

さて、以上で認証ルールが出来たとして、次は端末へのクライアント証明書の配布方法について検討が必要です。いざ運用がはじまっても、配布方法が手間では、結局ランニングコストが上がってしまうことになってしまうからです。

では、スマホやタブレットへの証明書の配布方法はどのようなものがあるでしょうか。

(1)予め作成したクライアント証明書を添付したメールをユーザ宛に送信します。ユーザは標準メールアプリで該当メールを開き、添付ファイルをクリックすることで、証明書セットアップ。
(2)証明書発行サービスでは、証明書ダウンロード用のリンクを発行するケースがあります。この場合、証明書ダウンロード用のリンクが記載されたメールがユーザに送付されるので、ユーザは標準メールアプリで該当メールを開き、メール内のURLをでクリックすることで、証明書セットアップ。

(1)のケースでは、管理者が逐次証明書を発行する手間があります。また(2)の場合は、証明書発行サービスと別途ご契約いただく必要があります。

Gluegent Gateはトータルでご支援可能です

弊社サービスGluegent Gateでは、このようなケースを想定しており、Gluegent Gate内でクライアント証明書を発行し、それを各ユーザがポータル画面からダウンロードしてそのままセットアップ出来る機能を備えています。これにより、配布の手間と、セットアップの複雑さを回避することが出来るようになっています。また、上記の多要素認証の構築についても豊富な実績がございます。以上により、社外でのスマホ端末利用についてのトータルなご提案が出来るかと思っております。


以上、ビジネスチャット開始時の、特にセキュリティ面での事項を記述してきましたが、如何だったでしょうか。導入に際してGluegent Gateにご興味があるようでしたら、是非ご連絡ください。

   Gluegent Gate

2019年10月23日水曜日

ビジネスチャット導入しただけで、仕事がうまく回ると思ってませんか? (1)

ビジネスコミュニケーションツールの中心はどんどん変わってきています。もはや想像することすら難しいですが、会って話す、または手紙の時代があり、その後電話が中心となる時代が長く続きます。今も電話でのコミュニケーションは根強いですが、固定電話から携帯電話の時代になりました。その間、非同期コミュニケーションの補助ツールとして FAXがあり、これまた今も根強く残っています。


ビジネスチャットサービスの興隆

1990年代後半から、インターネットが当たり前、メールが当たり前の時代の到来です。ここで、ビジネスコミュニケーションは大きく変わったと言えるでしょうか。携帯電話の普及も同時期であり、そういった意味でも大きくコミュニケーションが変わり始めた時代だと思います。テレビ会議、インターネット会議なども普及してきています。

そんな中、ここ数年、LINE WORKSや、Slack、Chatwork、Microsoft Teams、Salesforce Chatter のような「ビジネスチャット」が市場を喧伝するようになってきています。各種調査会社がいろいろな数字を出していますが、2020年には国内の市場規模が100億円〜150億円、導入企業は30%程度に達する勢いがあるとされています。今年2019年は、米国で Slack が上場、日本では Chatwork が上場するなど、株式市場も賑わせています。

ビジネスチャットへの期待

当社のお客様からもビジネスチャットと Gluegent Flow の連携や、Gluegent Gate でのシングルサインオン・アクセス制御に関するご相談が多く寄せられています。

ビジネスチャット導入にはいろいろな期待値があります。

・リアルタイムでスピード感のあるコミュニケーション
・情報共有が活性化されることによる会議時間の短縮
・社内のコミュニケーションを活性化
・結果として意思決定の迅速化
・スマートフォンからの利用
・働き方改革!
・シャドーIT撲滅

他にも色々あると思います。

とは言うものの、当社自身も経験していることですが、ビジネスチャットを導入しただけでバラ色の世界・バラ色のコミュニケーションが待っているわけではありません。導入してはみたものの、あまり活性化せず、メール中心のコミュニケーションになっている会社、多くのツールが乱立しちゃっている会社も多くあると思います。

そこにはどのような課題が有り、どのように解決していけるのか。
このあと、2回に分けて、当社なりに分析、課題解決に向けて気をつけていることなどをご紹介していこうと思います。

   Gluegent Gate

2019年10月16日水曜日

多要素認証時代到来!その鍵はクライアント証明書

クライアント証明書を用いて認証を強化するという話を耳にすることが増えてきました。いったいどのような仕組みで認証が強化されるのか、少しだけ踏み込んで、あまり難しくならないよう、技術面の話は抜いてご説明したいと思います。

PKI(Public Key Infrastructure)とは?

インターネットには「なりすまし」「改ざん」「盗聴」「事後否認」といった様々なリスクが潜んでいます。PKIは、「公開鍵暗号」という技術をベースに「公開鍵の正しさを保証するための仕組み」を整備することで、暗号化や電子署名を安心して使える保証されたものとして扱えるようにし、これらのリスクを排除することを可能にしたものです。

アリスとボブとアイヴァンで
それではまず、暗号通信などの書籍でよく登場するアリスとボブという具体的な名前を使って、例え話をしたいと思います。

ここでは、アリスがボブに、自分がアリスであることを証明するシーンを考えてみます。ボブがアリスを知らない場合、アリスがいくら「私はアリスよ」と言ったところで、ボブはそれを信用することができません。ですがこのまま二人だけの状態では埒が明かなくなってしまうので、アリスは自分がアリスであることを証明する何かをボブに示す必要があります。

そこで登場するのが第三者です。

第三者としてこの度、アリスをボブに紹介しようとしているアイヴァンを登場させましょう。アイヴァンはボブの親友で曲がったことが大嫌い、嘘はつかないし、とっても信用できるやつです。アイヴァンの手引でアリスとボブが初めて会います。残念ながらアイヴァンは別の予定があって行けそうにありません。ボブがとっても疑い深いやつだと知っているアイヴァンは、アリスに「この子がアリスだよ アイヴァン」と署名入の手紙を託します。



初めてアリスとあったボブは、アリスからアイヴァンに託された手紙を見せられ、この人は間違いなくアリスに違いないと信用するわけです。

第三者がいることでようやく自身の証明ができる。これは日常生活でもよくあるケースです。日常生活ではこういった場合、免許証やパスポートなどの公的証明書を提示することが多いですね。

改めてPKIとは?

では、上記の例え話をPKIに置き換えてみましょう。

PKIでは、アリスのように自身を証明したいものが主体者、ボブのように証明を求めるものが検証者、そして署名入りの手紙を証明書といい、これを作成して誰かの素性を保証するのが認証局(CA)となります。

もう少し具体的には、PCやスマホのブラウザ(主体者)が、証明を必要とするWebサイト(検証者)を閲覧する際に、認証局が発行した「証明書」を送ることで、自身を証明出来るようになる、という流れです。

このように、主体者も検証者も認証局を信頼していることによって、証明書が正しいものとみなされ、結果として、このような身元保証が成立します。

ただし、これまでのお話は、あくまでも証明書が正しいものであることを保証する枠組みでしかないので、証明書を盗まれたりしてもそのままでは「正しい証明書」として扱われてしまいます。もし証明書をなくした場合には「失効」の手続きをする必要があります。当然ですが、PKIにはこの失効も含めて検証する枠組みが整備されています。

認証局の信頼度はとても重要

これまでにも記述してきたとおり、認証局(CA)は証明書を発行する重要な機関です。 サイバートラストやグローバルサイン、日本RA等の商用CAもあれば、最近では Let’s Encrypt などの無償のCAも出てきました。(※ Let’s Encrypt はサーバ証明書のためのサービスであり、クライアント証明書としては使えません。) また、プライベート認証局を立てるケースもあります。どの認証局を信用するかは、検証者に委ねられている部分があります。

銀行の口座開設や役所等の手続きでは、マイナンバーカードや運転免許証といった公的な身分証が求められるでしょうし、とあるお店の会員登録では健康保険証でもOKなケースもあるでしょう。場合によってはクレジットカードの提示でサービスを受けられるようなこともあります。このように、日常生活でもどういった証明書を求めるかは、検証者に委ねられています。

この認証局の信頼ですが、保つことは想像以上に大変です。社内に認証局を立てていたら、悪意のある誰かが勝手に発行しないとも限りません。失効の手続きももれなくやる必要がありますし、データ消失や乗っ取りなどへの対策も必要です。認証局は、アクセスさせるシステムの内容や運用の手間、運用レベル等のバランスを検討し、商用CAを利用するのか、プライベート認証局を建てるのかは、慎重に検討する必要があります。

”クライアント”証明書

証明書の利用シーンはサーバ証明書、電子署名なども含めて幅広いのですが、今回はこのうち「クライアント証明書」としての利用についてのご説明です。クライアント証明書は、クライアント端末にインストールし、そのインストール端末以外からのアクセスを禁止するような際に利用されます。

検証者が信頼する認証局で発行されたクライアント証明書がインストールされた端末からのアクセスのみを許し、それ以外の端末からのアクセスは禁止することができます。

証明書のみを利用して認証を通してしまうことも可能ですが、ID/PWなどの I know 認証(知識認証)と組み合わせて利用するケースが多いです。

証明書認証を用いた多要素認証に対応したGluegent Gate

Gluegent Gate はクライアント証明書を利用した端末認証にも対応しています。また、Gluegent Gate を通じての配布も可能となっており、運用面含めて喜んでいただけています。昨今、多要素認証が求められるケースが着実に増えてきています。Gluegent Gate で、ID/PW認証(I Know 認証)に加えて、証明書認証(I have 認証)を組み込むことで、容易に多要素認証に踏み出すことができます。特にスマートデバイス全盛のこの時代、認証時の手間を増やさずに認証要素を増やし、なおかつ利用するデバイスの制限もできるという面は高くご評価頂いています。

以前の記事でも、セキュリティと運用のバランスとしてクライアント証明書をご紹介しましたが、弊社でも運用実績が豊富にございますので、ご興味があれば是非ご連絡ください。

 Gluegent Gate 

2019年10月10日木曜日

ボタンの表示・非表示を切り替えて、押し間違いを防ごう!

どんなシステムでも言えることですが、ボタンを押し間違えると色々と問題が起きるケースがあります。特に、ワークフローシステムなどでは、決裁者のボタン一つで、関係各所にメールが飛び、いろいろな物事が動き出してしまうケースもあり、ちょっとしたボタンの押し間違えでも、是正するのに色々なコストがかかります。

今日は、当社のGluegent Flowでボタンの押し間違いを減らす方法をご紹介します。それほど難しくないので、ここぞというときには是非ご活用いただけると嬉しいです。

Gluegent Flowには、入力フォームの入力値によって、「承認」や「却下」などのボタンの「表示・非表示」や「有効・無効」を切り替える機能があります。この機能を使えば、特定の入力フォーム項目の値がこうだったら、このボタンを表示するといった制御が可能です。

ここでは、経路が「決裁待ち」のときに、ある項目にチェックを入れないと、ボタンが表示されないようにすることを考えます。

  1. 制御用のラジオボタン項目を用意する
  2. ボタンの有効・無効を切り替える

この2ステップで設定できますので、是非チャレンジしてください。

◯制御用のラジオボタンを用意する

まずは、ラジオボタン項目を用意し、選択肢として「OK」と「NG」を用意します。

※この入力項目は、決裁経路でのみ編集可能とし、他の経路では非表示にしておきましょう。

◯ボタンの有効・無効切り替え設定をする
次に、有効・無効の切り替えを行いたいボタンに制御を入れます。

「決裁」ボタンには以下のようなスクリプトを書いています。
ボタン表示切替の制御では、スクリプトがtrueを返したときに「有効」、falseを返したときには「無効」となります。

if( ${ラジオボタン1} == “OK” ){
  return true;
}
return false;

もし、ラジオボタンで”OK”が選択されていたらtrueを返し、そうでなければfalseを返します。

当該経路の設定で、ボタン表示切替を開き、先程用意したラジオボタンで「OK」が選択されたときのみ「決裁」ボタンが有効になるように、「NG」が選択されたときのみ「却下」ボタンが有効になるように設定します。

以上で、「決裁」経路にある場合に、ラジオボタンで「OK」「NG」を選択しないと、「決裁」や「却下」のボタンが表示されないようにできました。

決裁者はひと手間増えますが、押し間違いのリスクを考えると、こういった制御をした方が安全なケースが多々あります。是非ご活用ください。

 

2019年10月2日水曜日

外国人から見た「日本で働く」ということ

皆さん、はじめまして。グルージェント開発部のジャレド・ウォレスと申します。名前から推測できるかもしれませんが、私は日本人ではなく、生粋のアメリカ人です。簡単に自己紹介すると、私はアメリカのワシントン州出身で、ワシントン大学で日本語を専門として、2017年に卒業しました。大学3年生の頃に、一年間青山学院大学でも勉強をさせていただきました。2018年の夏から半年長野県の観光地のホテルで働き、2019年の1月からグルージェントに勤めています。合計2年間程日本に住む経験を積んでおり、趣味は紅茶・コーヒー、ゲーム、料理です。

これから、日本で働く外国人の経験、リモートワークの海外勤務、多様性のメリット、アメリカの働き方との違い等について話したいと思っています。本記事では、ひとまず外国人の「日本で働いていて感じること」とその考え方について説明していきます。

ほとんど日本人

私が初めて来日して思ったのが、日本がほかの国と比べて極めて外国人が少ないことです。もちろん観光地等では外国人をそれなりに見かけますが、その多くが観光客や留学生で日本の社会環境に外国人が与える影響度はほとんどありません。その結果、日本独自の文化、感覚による暗黙のルールを前提とした社会環境になっていて、そこへの理解や批判の意見を見てみても同じようなものが多いように感じます。

海外では、様々なバックボーンに支えられた文化、感覚で課題を論じますので、社会、会社、個人等、様々な階層、コミュニティで常に問題提起が行われ、とある特定の国のルールが前提にはなりにくく、社会環境への理解や批判も様々な視点があるように感じます。

日本で働く=長時間労働

多くの国の人からすると「日本人は働きすぎ」という共通認識があると思います。理由は様々だとは思いますが、そもそも勤務時間が長いのと、残業に対しての考え方の違いは大きいと思います。

アメリカは州によって法律の詳細が少し変わりますが、基本的な勤務時間が休憩時間を含めた8時間となっています。残業時間に関しては個人として可能な限りやってはいけないことで、会社としてはやらせてはいけないことだと認識されています。一方、日本では残業は当たり前でしょうがないと考えられているように感じます。個人レベルでは「残業しなければ仕事が終わらない」とか「残業代がないと収入が減る」と認識され、会社視点では「ある程度の残業はやってもらわなければ仕事が回らない」という認識がされているのではないでしょうか。もちろん、最近の「働き方改革」の一環で残業に関しての考え方は変わってきてはいますが、まだまだ多くの会社では前述の感覚が残っているように思います。
※ちなみにグルージェントでは残業はほとんど発生していません。念のためフォロー(笑)

仕事に対する考え方

日本で散見される「仕事が人生の中心となる」風潮は不思議でなりません。
正直、「働き方改革」を実現するためにはまず「仕事に対する考え方改革」をする必要があるように感じてしまいます。海外(少なくともアメリカ)では人がそれぞれ自分の生きがいや時間の使い方を決め、仕事の優先順位は2番目か3番目ということが普通であり、会社もそういうことが前提として経営されています。
ちなみに、「過労死」という言葉は英語では存在しませんし、なんでそんなことが起こるのか理解するのが困難です。

次回予告

以上、少しネガティブになってしまったかもしれませんが、日本で働いていて感じることについて話させていただきました。
次回は多様性・ダイバーシティのメリットを話したいと思っていますので、皆さんもお楽しみにしてくださいませ。

ジャレド・ウォレス
Jared Wallace

   Gluegent Gate

2019年9月25日水曜日

4人のうち3人が承認すれば次に進む経路なんてどうやって作るの!?実は簡単にできちゃうんです!

Gluegent Flowをご利用いただいているお客様、これから導入を検討されているお客様からよくいただくご質問で、複数人が担当者だった場合、どうなるか?というものがあります。
例えば、申請→承認→決裁という経路で承認者が2人いた場合、設定により、1人が承認すれば次の経路に進む場合と、2人が承認すれば次の経路に進む場合の2パターンがあります。
ほとんどのお客様は、「それならばOK!」となるのですが、中には「10人の担当者のうち、3人が承認したら次に進むようにしたい」という声も少なからずいただきます。
今回は複数の担当者のうち限られた人数が処理すれば進められる方法をご紹介しましょう。

◯設定方法

設定方法をここでご紹介すると長くなりますので、割愛します。詳しくはGluegent Flowのマニュアルサイトの「小技g-承認する人数を制限する.pdf」をご参照ください。

◯どういう仕組み?
上記マニュアルでは「最大承認者数」「承認者数」「承認者」「差し戻し用テキスト」という入力フォームを作成しています。次に進める上で必要なのは「最大承認者数」「承認者」「承認者数」です。それでは1つずつご説明していきましょう。

「最大承認者数」は文字通り、複数人設定されているうち何人が承認すれば次の経路に進めるかを表しています。マニュアルの例では担当者を4人設定し、3人が承認すれば次に進めるので「3」が初期設定されています。この数を変更すると承認者を増やすことができます。
「承認者」は承認した人のメールアドレスが表示されます。これは「入力フォームアップデート」自動処理で承認者のメールアドレスを追加する仕組みで実現しています。
「承認者数」は承認した人数を表します。申請した時点では0が表示されています。1人目の承認者が承認すると1に変わります。これに「承認者」に追加されたメールアドレスの値をスクリプトで計算して戻す仕組みで実現しています。
承認経路では2つのボタンを作成しています。「承認」は最大承認者数に到達する前(1番目、2番目の承認者)有効となり、「承認2」は最大承認者数に到達する場合(3番目の承認者)にのみ有効化されるようにスクリプトが記載されています。
また、「承認」の処理についてはタスクを進めずにとどめるためのテクニックが用いられます。意図としては「次に進む(全)」として全員が処理しないと進まないようにするというテクニックです。しかし、Gluegent Flowの仕様上、1つの経路に「次に進む」と「次に進む(全)」の両方を作成することができないので、「終了(全)」を用いています。


おわかりいただけましたでしょうか。少しややこしいですが、ちょっとした工夫で実現可能になります。既にこの方法をお使いのお客様もいらっしゃいます。皆様もぜひご検討いただけましたら幸いです。
(SUTO)

 

2019年9月18日水曜日

<実録> テレワークやってます(4) テレワークだとこうなります〜時間の使い方〜

前回は、「隣にいないと伝わらない?」と題して、オンラインとオフラインのコミュニケーションの違いについて考察し、オフライン特有のコミュニケーション(対面の会議や、雑談、近い席から聞こえてくる程度の話等)の優位性と、そのような本来リモートでは取りにくい種類のコミュニケーションをオンラインでどのように実現するかについて、考えてみました。
リモートだからと諦めずに、問題点とそれを解決するための工夫をすることで、必要十分なコミュニケーションが取れるはずという結びとしました。離れた場所で仕事をする人にも、そうでない人にも努力を強いるところもありますが、テレワークをするためには避けられないポイントだと感じます。

今回は、テレワークがもたらす大きなメリットになる「時間の使い方」について見てみようと思います。筆者は、数年テレワークで仕事をしていますが、以前は、多くの方と同様に毎日通勤してオフィスで仕事をしていました。それぞれで一日の時間の使い方がどう違うのか、まとめてみます。

時間配分を数字で比較する

初回の記事に、リモートワークでのある一日について書きました。詳細を省いて、まとめると以下のようになります。

06:30 起床。仕事はじめまで家事等。
08:30 仕事はじめ。昼に1時間休憩、家事等。
17:30 仕事終わり。就寝まで家事等。
23:00 就寝

家事等は、食事・休憩を含みます。それぞれの配分は、以下のようになります。

  • 仕事:8時間
  • 家事等: 8.5時間
  • 睡眠: 7.5時間

一方でオフィスに通勤していた時には、以下のような一日でした。

06:00 起床。移動開始まで家事等。
07:30 移動開始。
09:00 会社着。昼に1時間休憩、食事。
18:30 仕事終わり。移動開始。食事
20:00 自宅着。就寝まで家事等。
23:00 就寝

時間配分は、以下の通りです。

  • 仕事:8.5時間
  • 移動: 3時間
  • 家事等: 5.5時間
  • 睡眠: 7時間

もちろん、毎日このままの時間配分で過ごすことはありませんが、仕事が忙しい時期以外はこのようなスケジュールになることが多く、これを平均として比較してみます。大きく異なるのはやはり移動に使っていた時間を、そのまま家事等に充てることができている点です。
これはいわゆるワーク・ライフ・バランスにおける分かり易いテレワークの利点をしめしているように見えますが、テレワークとオフィスワークの本質的な差異を見落としがちな比較になります。

単純な時間配分に現れない差

時間単位でまとめても見えてこない「本質的な差異」とは何でしょうか。オフィスワークの場合、仕事をするにしても、家の事をやるにしても、その間に必ず、一定時間の移動が伴います。やはり、「通勤の有無」に起因する様々な違いがあります。実際に経験してみると、具体的には以下のような違いとして現れます。

  • オフィスワークの場合、周囲が一斉に帰るわけでもないので、どうしても「定時帰りは気も引けるし、来週の資料のドラフトまで作っておくか」とか、「明日でも十分に間に合うけど、もう少しだけやっていくか。」というような思考に陥りがちで結果として残業が増えがちです。
  • テレワークでは、コーヒーブレイクのタイミングで、短時間の家事をすることも出来ます。例えば、洗濯物を干すとか、米を研いで炊飯器のスイッチを入れる等です。
  • テレワークの場合、家族の緊急の用事(子供が学校で怪我をした等)に対して、素早く対応できます。さらに学校や地域の行事等にも、参加しやすくなります。それらのイベントに参加後でも、仕事に復帰可能です。

このような違いは、「仕事」と「家の時間」の間に「移動」が伴わないことによる差異です。テレワークの方が、その時の優先度や重要度によって、柔軟に時間を使うことが出来ると言えるでしょう。

時間を柔軟に使えるからこそ注意が必要

一方で、柔軟であるがために、以下の点に注意が必要です。

  • 仕事時間と家の時間の境界があいまいになりやすい。
  • 早朝や深夜に作業をすることも出来るため、生活のリズムが乱れやすい。

さらに、移動時間がないことで、以下のデメリットを感じます。

  • 読書の時間が減る。
  • 運動不足になる。

オフィスワークでは、定まった時間に通勤することで、生活のリズムが出来るようです。そして、運動というほど多くはありませんが歩く時間もあります。しかし、テレワークでは、時間の使い方の裁量の幅が広いため、油断すると運動不足にもなりますし、リズムも乱れやすいと感じます。
テレワークでは、自分の裁量に任されている部分が大きくなるため、仕事についても、生活についても、サボらず、丁寧にやる必要があります。仕事をしっかりやっていても、生活が乱れてしまえば、結局仕事にも影響が出てきます。逆も同様です。テレワークでの仕事をすれば、簡単に「ワーク・ライフ・バランス」が保たれるというわけではありません。自分が置かれた状況や、やりたいこと、未来像などを冷静に分析し、状況を把握した上で、積極的に最適な働き方を求めていくことが大事です。
(ま)

   Gluegent Gate

2019年9月12日木曜日

モバイルアプリのアクセス制御は、ログインの時だけって、知ってた?

昨今セキュリティに関する話題には、良くも悪くも事欠かない状況です。 当然、クラウドサービスの利用に当たっても二段階認証を導入する等の対策を取るケースが一般的になってきています。 弊社サービスのGluegent Gateを導入頂いているお客様でも、オフィスのIPアドレスからのアクセスであればID/パスワードだけ、それ以外からのアクセスの場合はID/パスワードに加えてワンタイムパスワードや、証明書を用いた多要素認証(MFA)を組み合わせて運用されているケースが多いです。

さて、モバイルアプリのアクセス制御については、特に意識しておかなければならない点があります。現在のモバイルアプリは、「最初に一度認証すると、意図的にログアウトするまではずっと使い続けることができる」という仕様が一般的です。このため、モバイルアプリについては「いずれ認証セッションが切れるのが一般的」なブラウザベースでの利用シーンとは異なる考え方をする必要があります。モバイルアプリへのアクセス制御を考える際には、この点をしっかりと意識しておく必要があります。

モバイルアプリでパスワード入力が一度だけなのはなぜ?

モバイルアプリでパスワードを何度も入力すること/入力させることを避けることは、利便性を上げたいアプリの提供サイド、そして便利に使いたい利用サイド双方にメリットがあり納得できます。ただ、セキュリティ面からすると安全とは言い難いのが現状かと思います。コンシューマ系のアプリでは、最初の認証以降は端末の生体認証で利用できるタイプのアプリが増えてきています。ビジネスアプリでもこの方向性での安全性の確保は進んでいくものと思われます。加えて、FIDO等のパスワードをなくしていく流れも強まってくるでしょう。

モバイルアプリへのアクセス制御をどうするか?

アクセス制御は、本人及び端末を識別した上で、適切に利用させることが目的です。では、本人及び端末の識別はどのように行えば良いでしょうか。本人の確認についてはID/PWを利用するケースが一般的です。これに加えて、G SuiteやOffice365等、証明書を利用できるモバイルアプリに関しては証明書認証を利用した多要素認証(MFA)がお勧めできます。これにより、「証明書がインストールされた端末で、許可されたユーザ」が利用していることを保証できます。

証明書が使えないモバイルアプリの場合はデバイスの制御が難しいため、会社にVPNで接続したり、社内のWi-Fiから認証させる等の運用について検討しなければなりません。つまり「VPNに接続できる端末」や「社内のWi-Fiに接続できる端末」からID/PWで認証し、本人及び端末を識別する方法となります。

これらに加えて、近年のモバイルデバイスであれば、端末利用に際して指紋認証や顔認証などの生体認証がありますので、よりセキュアな運用が可能となります。

コストや環境、セキュリティポリシーの制限で、こうした運用が難しい場合に関しては、モバイルアプリを諦め、Webブラウザやセキュリティブラウザによるサービス利用をご検討いただくのが良いかと思われます。

モバイル端末の盗難や紛失等の際にはどうする?

盗難や紛失、何らかの事情により急きょモバイルアプリからの利用を止めたいというケースにはどのように対処すべきでしょう。これは、モバイルアプリを提供している各クラウドサービスの管理機能によって、強制的にモバイルアプリからログアウトさせる等の運用ルールを明確にしておく必要があるでしょう。クラウドサービスごとに強制的なログアウトの可否、方法などは異なりますので、クラウドサービス選定の際に確認しておくのが良いでしょう。

また、場合によってはMDMやMAMといったモバイルデバイスやアプリのマネジメントができるツールの導入も検討する必要があるかもしれません。


いかがだったでしょうか。 世の中のサービスやそれを利用するモバイルアプリについて、セキュリティとその利便性をうまくバランスさせることで、より効率的な働き方を実現出来るかと思います。


   Gluegent Gate

2019年9月4日水曜日

【CEOの視点】パスワードがなくなる未来

クラウドサービスが便利なのはいつでも、どこからでも自身の管理するデータにアクセスできることにあります。
ユーザーはアクセスのためにIDとパスワードを入力し、クラウドサービスにログインします。
逆に言えば、IDとパスワードが知られてしまえば乗っ取りも簡単に行えるリスクもあります。
昨今ではGmailやTwitter、LINE等のアカウント乗っ取り被害が増えており、IDとパスワードによる運用のリスクは日に日に増しているように感じます。

新たな認証方法FIDO/FIDO2

こうしたリスクに対して、パスワードに代わる新たな認証方法としてFIDO/FIDO2が標準化されており、いろいろなサービスで対応されていますが、実態として普及しているとは言い難い状況です。
FIDOには、デバイスのみで生体認証等で認証を行うUAFと、いわゆるドングルを挿して認証を行うU2Fという規格がありますが、生体認証と相性が良いUAFはスマホでの対応がメインで、PCに関してはなぜかU2Fに各社の思惑が集中しているように感じます。
Google社がTitanセキュリティーキーというドングルを日本でも販売というニュースもありましたが、基本的にドングルでのU2Fを前提とした場合、購入コスト、管理コストがかかり、運用が面倒になりがちです。
FIDOの普及という意味では、Appleというデバイスの巨人がFIDOアライアンスに参加していないというのも業界の足並みの悪さを感じます。
Windowsでは、生体認証でログインをするWindows Hello がFIDO2認定されたことでブラウザベースでの普及の可能性はありますが、やはりドングルベースのU2Fの課題がFIDO普及の壁になるのではないかと思っています。

スマホアプリでのパスワードレス認証

一方で、FIDOとは異なるサービス側の取り組みとしてはワンタイムパスワードの仕組みを進化させたパスワードレスログインの手法も出てきています。
こちらの方法は簡単に言えば、「スマホが利用できる人は本人である」という考え方で、サービスにログインしようと試みた時に、スマホアプリに通知がくるのでそれを承諾すればパスワード入力せずにログインできるというものです。
FIDO U2Fにおけるドングルの課題をスマホアプリとして解決したと言うと言い過ぎでしょうか。
指紋認証やFace IDが存在するスマホでは生体認証がされますので、パスワードレスでの運用も心配ありません。
弱点はスマホアプリをインストールしなくてはならないことでしょうか。
こちらに関してはサービス側独自での対応となっており、標準化されていないというのが普及のネックになりそうです。

パスワードの今後

いずれにしても数々のインターネットサービスが次々に生まれている現在では、パスワードでの運用は限界に到達しつつあります。
最終的には生体認証をベースにしたものになるとは思いますが、それがFIDO/FIDO2で決着するのか、はたまた別の規格が生まれてくるのか、今後も注目していきたいところです。

   Gluegent Gate

2019年8月28日水曜日

二段階認証をGluegent Gateで実現する方法をご紹介します

先日の記事で、二段階認証(二要素認証、多要素認証)についてご紹介しました。
【5分で分かる】二段階認証とは
では実際に、Gluegent Gateではどのようにして二段階認証を実現するかをご紹介いたします。

◯ワンタイムパスワードによるGluegent Gateでの二段階認証

Gluegent Gateでは二段階認証の方式の一つとして「ワンタイムパスワード認証」をご用意しております。Gluegent Gateに標準で実装されている機能ですので、すべてのお客様に追加料金なしでご利用いただけます。
「ワンタイムパスワード認証」はiOSアプリの「Google Authenticator」、Androidアプリの「Google 認証システム」をインストールしていただき、そこに表示されたワンタイムパスワードを入力する方法(トークン)と、ユーザ情報に登録されたメールアドレス宛にメールを送信し、そこに記載されたワンタイムパスワードを入力する方法(メール認証)の2種類があります。
それぞれの利用には認証・アクセス権限ルールの設定が必要になります。

◯Gluegent Gate管理画面での設定
認証・アクセス権限でそれぞれルールを設定しているかと思います。そのルールに「ワンタイムパスワード認証(トークン)」または「ワンタイムパスワード認証(メール認証)」を選択します。
他の認証・アクセス権限ルールと併用してもいいでしょう。
ルールの設定はお客様の運用によりそれぞれ異なります。状況に合わせて設定してください。設定方法が不明な場合は、弊社サポートへご相談ください。
◯認証ルールの例
この例ではワンタイムパスワード(トークン)を選択しています。

◯アクセス権限の例
この例ではワンタイムパスワード(メール認証)を選択しています。

トークンを利用する場合、ユーザーにワンタイムパスワードの設定をさせる必要があります。この方法には、ログイン時に実施させるものと、ポータルに入って実施させる二種類があります。
前者の場合は「パスワードポリシー設定」で「ワンタイムパスワード設定初期化」のチェックをオンにします。

後者の場合は「画面設定」の「ポータルに表示する機能」の「ワンタイムパスワードの設定」のチェックをオンにします。また「ワンタイムパスワードの設定に表示するトークン」の「Google」のチェックをオンにします。

「メール認証」を使う場合は、ユーザーに設定をさせる必要はありませんが、ワンタイムパスワードのメールが通知用メールアドレスに送付されますので、ユーザ詳細画面の「通知用メールアドレス」に任意のメールアドレスを設定します。
通知用メールアドレスにはログイン対象サービスとは異なるメールアドレスを必ず設定してください。ログイン対象サービスと同じ場合、ログイン時にログイン対象のサービスにワンタイムパスワードが送られるのでログインできなくなってしまいます。

◯ユーザ側の設定(トークン)
iOS/Android端末に予めGoogle Authenticator/Google 認証システムをインストールしておきます。
サービスへのログインを行い、Gluegent Gateのログイン画面に遷移します。

2次元コードが表示されますので、Google Authenticator/Google 認証システムで読み取ります。

以降、ログイン時にはGoogle Authenticator/Google 認証システムに表示されたワンタイムパスワードを入力してログインします。

◯ユーザ側の設定(メール認証)
メール認証の場合は、ログイン時にワンタイムパスワードの入力を求められたタイミングで通知用メールアドレス(未設定時はメールアドレス)宛にワンタイムパスワードが記載されたメールが送信されます。

表示されたワンタイムパスワードを入力してログインします。

いかがでしたでしょうか。今の設定にプラスするだけでワンタイムパスワードがご利用いただけます。認証・アクセス権限ルールの設定次第で、「特定IPアドレスからアクセスした場合は、ワンタイムパスワードは不要、それ以外はワンタイムパスワードが必要」や「ユーザポータルへログインするときはワンタイムパスワードは不要」といったログイン方法の設定も可能です。
この方法を使ったセキュリティの強化をご検討ください。
(SUTO)

 

2019年8月21日水曜日

2019年こそフィッシングを気を付けましょう

「フィッシング」という言葉を聞くと、皆様何を想像するのでしょうか。20年前のポップアップ広告による、かなりシンプルなものになりますでしょうか。2019年ではもはや被害に会わない、という意識が強い人が多いのではないかと思います。しかし、事実はその真逆です。今年のサイバーセキュリティ会社retruster様が行った調査によると、約9割の情報漏れ事件の原因がフィッシングだと発表されています。ITのプロフェッショナルすらフィッシングに引っかかってしまうことも、珍しくありません。本記事では最新のフィッシングとその対策について少し説明していきたいと思います。 まず、フィッシングの種類について説明します。

意識されないフィッシング

フィッシングと言ってまず想像するのは、不特定多数向けにメール配信し、ユーザー名、パスワード、クレジットカード情報、電話番号、住所等の個人情報を入力させる「バルクフィッシング」(英:bulk phishing)と呼ばれるものでしょうか。ネットの広告等で大人数向けに行われ、一般に広く認知されているかと思います。こちらはある日突然身に覚えのない内容で届いたりするため、比較的、怪しさを感じやすいですが、特定の個人や法人向けに行う「スピアフィッシング」、さらには>会社の幹部を標的とした「ホエーリング」、正規のメールに似せた内容を送る「クローンフィッシング」などは、フィッシングだと意識されないような内容となり、より危険なものになります。

さて、フィッシングの特徴として、いかに被害者をだまして、リンクや添付ファイルを開かせるかがポイントになります。開かせた先は攻撃者が用意した一般サービスに似せた画面になり、たとえばGoogleに似せたサイトの場合、以下のような画面が表示されます。ここまで巧妙だと、ついユーザー名・パスワードを入力してしまわないでしょうか。

「技術」より「人間」を狙った攻撃

しかし、この画面を開かせるためにもメールを本物だと思わせなくてはなりません。送信者アドレスの偽装で良く使われるパターンをみてみましょう。たとえば、以下のものです。

tarou.yamada@sarnple1234.com 

よく見れば分かると思いますが、ドメインがsample1234.comのように見せかけていますが、「m」ではなく、「r」と「n」になっています。こうして攻撃者がユーザー名やドメインを真似、信用できるリンクや添付だと思わせることも多いです。気を付けていれば気付けるでしょうが、多数のメールを処理していたり、疲れていたりすると、細かく確認できずに、リンクや添付ファイルを開いてしまいかねません。結果として、ITに不慣れな人だけではなく、ITプロフェッショナルでもフィッシングが成功してしまうことも珍しくないのです。もちろん、こうしたものもフィッシング手法の一つということであり、他にも沢山存在します。
 「中間者攻撃」と呼ばれる巧妙なフィッシングも存在します。これは偽サイトで入力された内容を本物サイトに送付し、本物から戻される情報をそのまま改ざんして本物サイトになりすますというものです。こちらは本物サイトから見れば正しいアクセスと見えてしまいますので、たとえばパスワードの変更を行ったとしても攻撃者に追従されてしまう可能性もあり、危険度はかなり高くなります。

対策するには?

ワンタイムパスワードによる二段階認証はある程度有効な対策ではありますが、中間者攻撃においては現在アクセスしているサイトが偽のものか本物かを判断できず、結果としてすり抜けてしまう可能性もあります。
このため、証明書認証を認証方式として追加したり、認証プロセスにIP制限を設定したりする方がよりセキュアであると言えます。弊社が提供するGluegent Gate等のIDaaS製品もシングルサインオン連携で様々な認証方式や制限の実装が可能になるため、フィッシングの対策をしつつ、快適かつ安心にクラウドサービスをご利用頂けます。

2019年8月7日水曜日

<実録> テレワークやってます(3) 隣にいないと伝わらない?

前回は、「テレワークで『対面の打ち合わせ』に挑む」と題して、オンラインとオフラインのコミュニケーションについて、特に、テレワークで「対面の打ち合わせ」に近いコミュニケーションを取ることについて、考察しました。リモートの環境にあっても、いくつかのポイントをおさえることで、オフラインに劣らないコミュニケーションをとることができます。
今回は、テレワークというワークスタイルには苦手なコミュニケーションについて、考えてみます。


積極的な発信・共有に至らないコミュニケーション

オフィスワークで、周囲に同僚が座っているような環境で仕事をしていると、様々な形で情報が入ってきます。例えば、お客様と電話で話している同僚の声が聞こえてきたり、ちょっとした雑談の中で、業界動向や新しい技術について触れられたりもするでしょう。さらには、同僚の表情や顔色、声の調子から、疲れが溜まっていそうだとか、プロジェクトがうまくいってそうだというような、言葉に現れない情報を感じられたりもします。
テレワークの場合は このような情報の取得が基本的に出来ません。テレワークで得られるのは、「その人に対して、積極的に伝えられる意図がある情報」です。メールの宛先やCCに入れられた情報や、メンバーとして参加依頼されたリモート会議の内容などです。これらは必要があって伝えられますが、前述したような「聞こえてくる」程度の情報は、伝えようと意図されていないため、リモート環境までは届きません。
このように情報源が限定されているため、オフィスワークでは、当たり前のように共有されている情報が伝わっていないということは良くあります。デメリットのようにも聞こえてしまうかもしれませんが、こちらに関してはデメリットだけでなく、メリットと感じる部分もあります。

情報共有が不完全なことがある?

オフィスワークでは、様々な方法で情報が得られます。これらのコミュニケーションによって、総合的に情報が共有され、効率的な仕事につながります。テレワークでは「発信・共有が意図された情報」に限定されるため、全てを意識して伝えなければいけません。手間もかかりますし、抜けてしまうこともあります。この観点でみると、テレワークのデメリットとも言えるでしょう。
ただ、テレワークの場合、必要な情報を伝えるために、対象領域の問題や懸念事項が整理され、理解が深まるという面は見逃せません。意図せず伝わっているというような「確実性が低い」伝達に頼らず、情報を適切に整理して、必要な情報を必要な人に伝えることによって、結果的に仕事がより効率化されることもあります。
このようにテレワークでは、伝わってくる情報の分析とより積極的なコミュニケーションが求められる側面はあるものの、その「必要性を認識して」取り組めば、オフィスワークとは違った効率化の追求が可能となります。

チームの一体感

コミュニケーションが限定されてしまうと、仕事に必要な情報共有だけでなく、組織やチームの一体感や共感といった感覚的なものについても、違ってきます。チームで仕事をするなら、やはり机を並べていた方が、一体感を感じやすいでしょう。リモートに居る場合には、やはりその辺の感情的な共感や一体感が薄れるようにも思います。仕事に無関係な雑談をしたり、一緒に食事をしたりなど、チームの一体感は、同じ空間で同じ時間を過ごす事で深まるものです。
ただ、これについても、工夫次第で改善することは可能です。オフィースワーク側も意識して、チャットルームでいろいろな会話をしたりすることで、いろいろな情報に触れることができますし、ビデオチャットを利用したリモートでの会議では、カメラを有効にして顔を見えるようにしておくことで、お互いの表情を見ることができます。これらの工夫を意識的にしていくことで、物理的な距離があっても、感覚的に近い関係を持つことができるでしょう。

限定的状況の認識と工夫

前回と今回で見たように、オフィスワークとテレワークという働き方には、特にコミュニケーション・情報共有の点について、やはり差異があり、テレワークには苦手な部分があることがわかりました。ただ、そのような差異についても、その構造的な問題点を適切に把握して、工夫することで、十分に対応可能です。
今回まで、テレワークに関するネガティブな側面をどう解決するかに着目してきましたが、次回はテレワークを選択する大きな理由の1つとなる「時間の使い方」に焦点を当ててみます。ご期待ください。
(ま)

   Gluegent Gate

2019年7月31日水曜日

二段階認証の代わりになるものは?

様々な報道により、二段階認証が認知されてきています。 二段階認証はその仕組み上、セキュリティ強度は高くなりますが、その分認証に手間がかかります。認証を2度行うのですから、それは当然ですね。

二段階認証の代わりになるものは?

ですが、利用者への負荷を出来る限り軽減し、かつ一定のセキュリティ強度も担保したいというご要望も多いかと思います。 このような要件を満たすものの一例に、証明書を用いた二要素認証があります。

実際には、認証の際に、例えばID/パスワードと証明書確認が必要となるように構築します。すると、サービス利用時の認証画面でID/パスワード入力後、すぐに表示される証明書選択画面から証明書を選択することで、認証を通過したことになります。
これにより、ID/パスワードによるいわゆる「知識認証」と、証明書による「所有物認証」の二要素認証が実現できます。この証明書は、予めデバイスに登録する必要はありますが、それが出来てしまえば、後は利用者側の負担は大きくありません。

ご要望に添った認証をGluegent Gateで

いかがだったでしょうか。上記の証明書を始め、弊社製品Gluegent Gateでは様々な認証方式をご用意しています。その為、ご利用シーンや運用ごとの適切なご提案が出来ると考えております。ご興味がありましたら、是非ご連絡ください。
(Fuji)


 Gluegent Gate

2019年7月24日水曜日

自分が申請したワークフローを一覧でわかりやすくするためのポイント

Gluegent Flowをご利用いただいているお客様からよくいただくご質問に、「タスク一覧の件名がわかりにくい。なにかわかりやすくする方法はないですか」というものがあります。そこで今回は、ちょっとしたテクニックでタスク一覧の視認性を向上させる方法をご紹介します。

◯件名に表示されるものとは?

そもそもタスク一覧の「件名」には何が表示されるか。初期状態では「モデル名」+「タスク番号」が表示されます。また、申請時にユーザーが件名を変更できます。

◯自動処理で件名をカスタマイズ
それでは、自動処理を使って件名のカスタマイズを行ってみましょう。
件名は申請されて、次の経路に移ったところから他者の目に触れますので、最初の経路で自動処理を設定します。

「タイトルのアップデート自動処理」を追加しましょう。
更新後のタイトルに任意の値を設定しましょう。
ここではプレースホルダーが使えます。
例えば、件名にモデル名と申請者名と申請区分という入力フォームの入力値を設定する場合は、${モデル名}-${申請者名}-${申請区分}と入力します。

実際に申請するとこのように表示されます。

いかがでしたでしょうか。ちょっとした工夫で、視認性が向上し業務効率をアップさせることにつながるのではないでしょうか。
(SUTO)