家田　私は6年以上前から総務省テレワークマネージャーとして、企業のテレワークの相談に乗ってきました。当初の目的は生産性向上が中心でしたが、働き方改革関連法案の成立からはそちらにシフト。さらに昨年のコロナ禍で、その対応のために多くの企業が付け焼き刃的にテレワーク対応を余儀なくされた、というのが現在までの流れです。日本テレワーク学会では、この20年の取り組みで普及が進まなかったものが、この1～2年で一気に進んだという話をしています。

総務省テレワークマネージャー

家田佳代子氏

――業界による違いはありますか。

家田　企業別の傾向では、まず大手が取り組みをスタートして、中小企業に降りてきました。業界別では、IT系の企業から始まり、大手ゼネコン、設計・デザイン会社、また、AI、ARなどの技術の普及で工場系の企業にも浸透してきました。コロナ以降は、医療・介護系が目立ちます。これはクラスターの発生が施設全体の閉鎖につながるためです。

――テレワークの相談内容は変化していますか。

家田　当初は、何をしてよいのか分からず、仕組み自体から教えてほしいという相談が多かったです。今は、導入したシステムが適切なのか見てほしい、あるいは、急きょ対策することになったが、どんなシステムが推奨されているのかなど、システム寄りの相談が中心です。これは大手も中小も同様で、相談を受ける先も情シスではなく、人事や経営企画からの相談がほとんどです。これも働き方改革を目的としているためだと思います。

――お客様のニーズに対応されてきたニュータニックスさんは、昨年の緊急事態宣言時と、現在とで変化を感じますか。

江副　コロナ禍以前のリモートワーク環境は、ノート PCの置き忘れ、データ漏えいといったセキュリティ対策の観点から、シンクライアントなどデータを端末に残さないVDI環境を検討されるケースがほとんどでした。コロナ禍では、ほぼ自宅で作業するので、従来のFAT-PCでも大丈夫という認識から、VDIから戻すケースもあります。その理由は単純にコストで、他に管理性などの理由もありますが、コスト比較ではPCの単価がかなり下がっているため、十分ではないかと考えられるようです。

ニュータニックス・ジャパン

エンタープライズ営業統括本部長

江副桂太氏

――家田さんは、テレワークマネージャーとして120件以上もの企業のテレワーク導入をサポートされてきたわけですが、FAT-PCとVDIの導入傾向はいかがですか。

家田　かなり以前から大手企業の多くはVDI環境を導入されています。その見直しの時期に差し掛かったところで、FAT-PCとVDIの選択を検討されるわけですが、VDIを選択する第一の理由はセキュリティですね。VDIに対して中小企業はハードルの高さも感じています。まず、専用サーバーが必要であることが大きいと思います。

コロナ禍で構築した環境を見直す動きが出ている

――急きょテレワーク環境を導入して一段落した今、浮き彫りになってきた問題点は。

家田　システムのほか、マニュアル化、チェックシートなど企業自体の運用体制を含めて環境が整備されていないため、情報システム部門の方に、さまざまな相談やクレームが寄せられて、残業を余儀なくされているというケースが目立ちます。また、人事評価と労務管理にも問題が出ています。

江副　コロナ禍対応で、事業継続を第一に考え、他のことにはある程度は目をつぶっても、いち早くテレワーク環境を実現することを最優先にシステムを導入したケースが多かった。そのため、拡張性や管理性などは考慮されていませんでした。そこで、今になってVDIのサーバー追加などをしようとすると、苦労するケースが見られます。旧来のやり方で作業すると数カ月掛かることもありますが、その間に人の流動があると状況も変わってしまいますから。Nutanixを基盤とするVDIソリューションが選ばれるのも、そうした拡張性などの高さが評価されたためと考えています。

――Nutanix製品のメリットが活きたケースというのは。

江副　緊急事態宣言下では、保守作業に人が出せないことも課題です。その点でも、Nutanix製品は、もし故障しても自動的に修復する機能を備え、データは保護されています。最悪、すぐに駆け付けられない場合でも時間的な猶予があります。以前であれば、当日4時間以内に駆け付けなければならない、ということもありましたので、お客様にとってもわれわれにとっても、安心感を提供できるものと自負しています。

――コロナ禍で利用状況の変化も影響していますか。

江副　アプリケーションの観点では以前、VDIは業務使用がメインでしたが、コロナ禍以降はWeb 会議などのコミュニケーションが加わりました。これらはシステム負荷が大きくリソース追加が必要になった場合、それが容易なNutanixのメリットが生きます。また、昨年はみんながPC 調達に一斉に動いたことで、供給不足が起こりました。その際も、リソースプールから優先順位に応じて割り当てできたことが、お客様に評価されています。

　さらに、FAT-PCではWindows アップデートやパッチの適応など運用の問題もテレワーク環境では難しい作業です。VDIならセンターから一括して実施、統合管理ができるというメリットがあります。Nutanixは1台でも、10台でも、100台でも、同じ画面で同じオペレーションで管理できることが大きな特徴で、1人でも運用することが可能です。

――一度導入した他のテレワーク環境から乗り換えるユーザーはいますか。

江副　テレワーク環境に限らず、今は、全面的なシステムの切り替えを決断するのは、難しい時代だと思います。そこでスモールスタートして、パフォーマンスや業務要件が合うのかをチェックした上で、拡大していくというケースが多い。Nutanixはスモールスタートが容易で拡張性が高く、IT 投資を最適化できるというメリットを提供できます。

金谷　Nutanixが優れているのは増設が容易なことで、実際、昨年から今年にかけて既存のNutanix環境に増設したいという問い合わせが増えました。特に、人が出せないという状況下で、簡単に増設できるというNutanixのメリットが活きています。同時に運用担当者に負荷を掛けない容易な管理、サポート品質も高く評価されています。

ネットワールド

マーケティング本部インフラマーケティング部

データセンタソリューション課

金谷宗也氏

家田　ユーザーにとって、しっかりしたサポートが受けられるという安心感はとても大きく、特に、コロナ禍ではシステム担当者が自分でサポートに出向くよりも、サポート料を払ってもベンダーに頼みたいというニーズが強いようです。

全体最適の観点からテレワーク環境を構築すべき

――ポストコロナを考えた時、どのような観点でテレワーク環境を整備すべきですか。

家田　まず、性善説／性悪説（徹底した管理）のどちらを選択するかという観点からはじめ、ゴールを決めて、それに向かって最適なシステムを選択することが、後戻りしないための方法です。セキュリティの確保は第一ですが、がんじがらめであることは使い勝手を損なうのでバランスが大切です。スモールスタートは投資を無駄にしないためにもとても有効な手段で、各部署から選抜した人でスタート、問題がなければ全社展開します。システム以外では、上司と部下でコミュニケーションをしっかりとることをお勧めしています。

――FAT-PCとVDIの選択で悩まれるお客様には、どのようなアドバイスを。

江副　セキュリティ確保を目的にVDIを導入したお客様が、セキュリティに目をつぶって FAT-PCに戻すような選択はするべきではないでしょう。仮に使い勝手に問題があれば、用途に応じてクラウドの選択もある。われわれも、クラウドサービスとしてNutanixを利用できる製品をリリースしているので、オンプレ、クラウドを含むハイブリッド環境で、お客様が適材適所に使い分けるというニーズにもしっかり対応します。

　PCかVDIかの比較論は多いのですが、最終的にはシステム全体で見た時のアプリケーションをどうするか、基幹系を含めたDXなど、全体の中の一つの要素にすぎません。そこだけを見て判断すべきでなく、全体最適解という観点で選択されるようお勧めしています。

金谷　当社でも、何が目的なのか、セキュリティの強化なのか、働き方改革なのか、それともBCP/DR対策なのか、お客様の本来の目的を判断した上でディストリビューターの立場ならではの最適なシステム提案ができると考えています。

――お勧めするソリューションはありますか。

江副　ニュータニックスは、これまで主にHCI分野でビジネスを展開してきましたが、VDIに絡む部分でも、プロファイルを置くような領域でFiles（ファイルサーバー機能）を提供していますし、追加コストなしで利用できるハイパーバイザー「Nuatnix AHV」も活用いただければと思います。

金谷　最近、VDI導入の相談を受けた時は、Nutanix Filesも一緒にご検討されているお客様が多いです。お客様としても、ベンダーが異なるとサポートが別になって面倒と感じるようで、インフラ部分はニュータニックス製品で統一したいというケースが目立ちます。

Permalink | 記事への反応(2) | 19:09

2020-10-11

■エンドツーエンド暗号化(通称: E2E)について解説する

[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ　（写真=AP）日本経済新聞

エンドツーエンド暗号化という技術がある。

暗号とは

平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。

ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。

共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。

公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。

ノーマルモードとコモンモードみたいで意味不明だが耐えろ。

共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、

共通鍵では「平文→　　　鍵→暗号文→鍵　　　→平文」と同じ鍵を使い、

公開鍵では「平文→　公開鍵→暗号文→秘密鍵　→平文」と二種類の鍵を順に使う。

なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。

共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。

この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-Masuda Ultra Global Root CAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。

ここまでが暗号技術のおさらいである。

暗号化 通信とは

暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? HTTPS化しているウェブサービスでも、TLSをロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。

Diffie-Hellman-Merkle鍵交換方式

Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。

送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。

上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。

Aさんの手元には乱数A、適当、暗号Bがある。

Bさんの手元には乱数B、適当、暗号Aがある。

AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである。

では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか? 可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。

或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者が乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。

これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密の暗号鍵用乱数を得ることができる。

原始的なDiffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、

暗号A = XをA乗してYで割った余り、

暗号B = XをB乗してYで割った余り、

鍵AB = 暗号BをA乗してYで割った余り、

鍵BA = 暗号AをB乗してYで割った余り

である。

なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。

End-to-End(E2E) 暗号化

ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。

この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End 暗号化」である。

E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS 運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。

ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。

これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若い IT キッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。

実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。