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でさえ起動できれば簡単に認証を設定できるようになります。

ジャレド・ウォレス

2020年7月22日水曜日

よく使う申請書は「お気に入り」化でスマートに申請しちゃいましょう

弊社でご提供しているクラウド型ワークフローサービス「Gluegent Flow」は、業務で使用する各種申請書を電子化したい、クラウド化したいというお客様のお声から誕生し、これまで様々なお客様にご利用いただいています。
さて、業務で使用する各種申請書はどれくらいあるでしょうか?
改めて数えてみると結構あるもので、あるお客様ではGluegent Flow導入を機に全社で洗い出してみると100〜200もの大小様々な申請書があったそうです。
最初は、全部の申請書をGluegent Flowに置き換えることは無理だろうとおっしゃられていましたが、最終的には全てがGluegent Flowに置き換えられたそうで、大変喜ばれておりました。このようにGluegent Flowはいろいろな種類の申請書のクラウド化を実現できます。

◯たくさんモデルがあると探すのが大変!

お客様が業務で使われている申請書をGluegent Flowでは「モデル」として作成いただいています。

たくさんのモデルがあると、申請する側は大変ですので、利用シーンに合わせて「カテゴリ」を作成いただきます。

「カテゴリがたくさんあって大変」という場合や「どのカテゴリだったっけ?忘れちゃったな・・・」ということがあるかもしれません。そんな時は、作成画面で検索欄をご利用ください。モデル名のキーワードを入力すると、対象のモデルが表示されます。

◯よく使うモデルはお気に入り登録

氏名や家族の変更といった申請は、そう滅多に使いませんが、例えば「休暇申請」「週報」のように、日常的によく使うモデルは、毎回カテゴリを選んだり検索するのは大変です。そういったよく使うモデルは「お気に入り」に登録しておきましょう。
作成画面の各モデルの右側に☆印が表示されています。これが「お気に入り」のアイコンです。
よく使うモデルの「☆」をクリックするだけで、お気に入りに追加されます。

お気に入りに追加するとカテゴリの一番トップに「★お気に入り」が表示され、「☆」をクリックされたモデルだけが表示されます。

◯使わなくなったらお気に入り解除

お気に入りのモデルの管理は簡単です。一覧で☆をクリックすれば、「★お気に入り」に追加され、「★」をクリックすると「★お気に入り」から削除されます。この設定は各ユーザー単位ですので、「最近良く使うなぁ」と思ったらお気に入りに追加し、「もう使わないなぁ」と思ったらお気に入りから削除するという風にお気軽にご利用ください。

もし、たくさんのモデルを作成されていて、「モデルが見つけられなくて困っている」「申請するまでの手順が多い」とお困りのお客様はぜひ「★お気に入り」をご活用ください。
(SUTO)