コインチェックのインシデント対応報告を読み解く
久々に（技術的にも実務的にも）良い意味で考えさせられる対応報告書を読んだ。
コインチェックの対応報告書がそれ。
読み解いてみたけど、存外に大変なことに（主にオレが書いた文の分量が）…。
コインチェックからリリースされたたインシデント対応報告
読んでいて、真面目な意味で面白く、かつ自分で考えようと思えばいろいろと考えられる報告書は、久しぶりに出会った。オレもこういう報告書を書けるようになりたい…。
真面目な意味で「どこが」面白いのか？（あくまで私見）
あくまで私見ではあるが、「監視業務にてレスポンスの遅延を検知し関連システムの調査を開始」という1行が、ものすごく興味をそそられた。
その次に「第三者によりドメイン登録情報が変更されていたことを確認」という結果につながるのが面白い。
この間の経過時間は、おおよそ7時間ちょっと。
その7時間にどんな調査／確認が行われたのか？は、いろいろと考える価値があるのだが、「レスポンス遅延」から「ドメイン登録情報が変更されていた」という経緯が、「風が吹けば桶屋が儲かる」を連想するレベルで「？」となり、その後に「レスポンスの内容を考える」ことにつながった。
その結果、自分の知見の総動員とまではいかないまでも、結構な勢いで自身の知見から仮説の再構成をするに至った。正直相当疲れたけど、ものすごく面白かった。
調査開始から事案確認までに実施したことを想定する
以降は、調査開始から事案確認までに、コインチェックで実施したのではないか？という調査の内容を考えていたりする。
レスポンスの遅延を検知
こういう話が出てくると、レスポンスの遅延が何に起因して発生するのか？が気になってくる。
オレとかは、Webサーバ／Webアプリケーションサーバへのアクセス時に発生する処理を並べて、遅延が発生するとしたらどこ？というのを考える。例えば以下のような処理がざっと並びますが、それぞれでどうなったら遅延が発生するのか？を考えてみることに。例えば、遅延という話だと、以下のような話が考えられる。
- Webサーバ／アプリケーションサーバの性能不足
- Webアプリケーションの処理遅延
- 名前解決の処理遅延
次に、遅くなる傾向（一斉に遅くなる／偏って遅くなる／遅くなることもある）などから、例えば以下のような話が考えられる。実際の対応現場では、もしかしたらもっと多岐にわたった検討を実施したかもしれないが、オレが考えられるのはさしあたり以下のような感じ。
- 一斉にまんべんなく遅くなる場合
単純にリソース不足。
ロードバランサ等に異常はなく、均等に処理を割り振って、サーバ側の負荷が均等に上昇・処理量が増えている
回線の帯域が逼迫している
DNSの処理が遅延している - 特定のサーバに偏って遅くなる場合
リソースが少ない特定のサーバが遅くなっていたり、ロードバランサのバランシングポリシーが誤っている（Webサーバ／アプリケーションサーバのリソース搭載状態によって、バランシングポリシーを均等ではなく30%:70%に振り分けるなどはありえる、もしくは同じリソースを持っているWebサーバ／アプリケーションサーバに、アクセスを均等に割り振らなければいけないはずが、なぜかバランシングポリシーがそうなっていないか）
特定のサーバに至る回線が逼迫している
特定のDNSレコードのみ名前解決が遅くなることがある - 特定の処理に偏って遅くなる場合
特定処理（例えばDBMSトランザクションが入る処理）で処理遅延が発生する
排他処理でリソース解放を待って遅くなる
その他、希少リソースを取り合うなどの理由で遅くなることも - ばらついて遅くなる場合
サーバ側に上記のような問題がある
ユーザからサーバまでの通信経路に（局所的に）問題が出ている
DNSの応答が時々遅くなる
上記の項目を全部一人で～となるとさすがに死ぬし、解決までの時間がかかりかねないので、それぞれに詳しいメンバが調査にあたったはず。とはいえ、Webサーバ／アプリケーションサーバ、DBサーバ、DNS、ネットワークの負荷がどんだけかかってるか？というレベルのチェックであれば、きちんとした運用をやっているところであれば、（時間はともかく）確実に状況を把握できるはず。
この時点で、DNSはあくまで疑義があるパーツの1つであり、ましてやレジストラの登録情報が改ざんされているなんて普通は考えない*1。
Webサーバ／アプリケーションサーバのリソースも処理負荷も回線帯域も問題ない場合に見るところ～例えばNWの遅延
次に見るべきところは、NW上の（TCP/UDPレベルの）レスポンス遅延がどれだけあるか？という（わりかし）ミクロなところかなと思う。TCPはOSのプロトコルスタックが、UDPはアプリケーションが返すものだが、負荷に問題がない以上、おおよそのレスポンスを見積もるのはそんなに難しい話ではない。特に、国内のデータセンタ等に情報を置いているサービスであれば、海をまたぐレベルでの遅延はほぼ起こり得ない（除く沖縄）。
おそらくだが、ここで遅延をミクロに見ていたエンジニアが「おかしい」と気付いたのが、DNSのレスポンス遅延なのではないか。
原因はともかく、DNSのレスポンス遅延（フルリゾルバがキャッシュする前の、権威DNSからのレスポンスが遅い）は、遅くともこの段階で見つかる可能性が高い。ただ、DNSの負荷や経路に異常がない（DNS側から見たら、インターネット上の通信経路に異常がない）可能性は非常に高いので、システム側からではこういう話は気づきづらい。
権威DNSからのレスポンスが何故遅れる？～ここでDNSの配置が問題に？
権威DNSからのレスポンスが遅れる、でも権威DNSの負荷は問題なく、経路も問題ない、となると、レスポンスの内容を確認する動きになる。知らないDNSがいる、という話は、この段階でわかる可能性が高い。
権威サーバは、リクエストに応じてレスポンスを返すが、このレスポンスは通常は、途中に存在するフルリゾルバ（DNSキャッシュサーバ）に一定時間留め置かれる。フルリゾルバがDNSからのレスポンスをキャッシュしている場合には、遅延が発生せず、そうでない場合には遅延が発生するのではないか？と考えるに至る。
DNSの配置がなぜ問題に？
ここで、DNSの配置がなぜ問題になるのか？を述べておく。
DNS自体は、クエリをさばいてレスポンスを返す単純なしくみであり、不明な内容があると、（権威DNSであっても）それを知っていると思われるDNSにリクエストを送る。例えばだが、あるドメインにおいて、サブドメインまるごと委任した場合なぞは、委任された先にもDNSが設置され、あるドメインの権威DNSが情報を持っていないサブドメインに対するリクエストと判断された場合には、サブドメインの情報を持つDNSに問い合わせを送り、応答をクエリ元に返す。
当然この場合、単独のDNSのみで処理を完結するよりも時間を要する。さらに、国外にあるDNSが、国内にあるDNSにリクエストを転送するような処理を考えると、
国内→国外→国内という感じで、一度国内にある（委任先の）DNSにリクエストを送る。
なお面白いことに、ここで何気に「距離」が効いてくる*2。
物理的な距離が1000kmほど離れているところだとどの程度の時間がかかるか？だが、単純に委任先のDNSにリクエストが到達するだけでも、「国内→1000km→国外→1000km→国内」というように、2000km程度の時間がかかる。そして、光速度は30万km/秒と言われているが、光ファイバ内だとおおよそ6～70%程度まで低下するため、20万km/秒となる。この光速度で2000kmを移動するためには、0.01秒（＝10m秒）を要する。光速度不変の法則とかいわずにもっと根性出せや、と思うかもしれないが、これが物理法則から導き出される限界の1つである。
そういう目でDNSのレスポンスを見て、レジストラへの登録情報に目が行く
システムを運用してる側からしたら、システムが順風満帆に動作していることのほうが稀で、実際には小さいトラブルや不具合が発生しながらも問題ないレベルに局所化していることのほうが（多分）圧倒的に多い。
となると、まず「自分とこの不具合」を疑って、徹底的に調査を行い、不具合がないところでやっと外に目が行き始める。
そこで「外部要因の1つ」であるレジストラの登録情報に注目し、そこで改ざんに気がついた、というオチになったのではないか。
レジストラの登録情報が改ざんされていると発生する懸念
レジストラの登録情報～今回の場合はDNSの情報～が改ざんされていたわけだが、これはかなり重大で、ドメインを乗っ取られるのに等しい。
Webサーバが乗っ取られるのは、それはそれで困るが、ドメインが乗っ取られることは、リクエストそのものの最初の行き先を操られるというさらに困った事態に陥る。
レジストラの登録情報が改ざんされる＝DNSの情報が改ざんされる、と考えると、メールの行き先も改ざん者が自由に変えられる。改ざんされて登録されたDNS上のMXレコードを攻撃者が持つホストにすれば、coincheck.com宛のメールを受け取り放題になる。ここで報告書の「問い合わせメール～」につながる。
別にコインチェックを擁護するわけではないが、この件は事象から原因にたどり着くまでが難しい…
後からはどうとも言えるかもしれないが、オレはこの机上検証を行うことで、「レスポンス遅延」から「レジストラの登録情報改ざん」を突き止めた方々の努力に敬意を表したい・そして、多岐にわたるレスポンス遅延の要因を1つ1つ潰し、レジストラの登録情報改ざんに至るまでの（想定）プロセスが、相当大変だという結論に至ったのは、1つの知見を得たとか考えている。
それこそここまでのことを10秒でトレースできる人がいれば～という話なのかもしれないが、そんな人はそうそういるわけではないし、オレもスタートとゴール（そしてその後）を見るまでは、そんなこと思いもしなかった。
結び～適切な仮説設定と、仮説に基づいた地道な調査が一番重要
ここまでにいろんなことを書いたが、最も重要なのは「適切な仮説設定」と「地道な調査」ということ。仮説設定が間違っていると、調査はあさっての方向に行きがちだし、地道な調査を行わないと、積み重ねる事実が瓦解しかねない。
自分も気をつけないとなぁ…と感じた瞬間である。
みんなVPN死ね症候群にかかってないか？
極端なテレワーク推奨期間に入ってはや数ヶ月（？）、VPNについて「クラウドベースに移行するのを視野に入れて」とかなんとかいろいろと出てるけど、別にVPNが悪いわけじゃないぞ。使うVPNの種類と使い所を間違っているだけだ。
ということで、本日はざっくりとしたVPNの種類と使い所を、自分の記憶と理解の範囲だけで説明してみよう*1。
VPN is 何？～種類の前にまずはここから
VPNとは、「専用線とみなして使うことができる回線であり、「専用線のようなもの」である。」という以上の意味しかない。ちなみに対義語はPN（Private Network）。技術的には、「接続される2点もしくはそれ以上をつなぐ」専用に使われる回線である。しかしVPNは、技術的に専用線のようなものと言えるかもしれないけど、厳密には専用線ではない。それっくらいの意味しかない。
IP-VPN is 何？
IP専用のVPN。網は通信事業者が準備しているものを使う。機密性、完全製、可用性（この場合は利用可能な帯域）は、通信事業者がサービス内容に応じて設定する。結構お高い。
インターネットVPN is 何？
IPsecやSSLなどを用いて、機密性と完全製を担保するタイプのVPN。可用性（帯域）は、通る経路によってだいぶ異なるため、まず保証はされない。ただ、トポロジにもよるが、IP-VPNよりは安価にすむことが多い*2。
テレワークで使われるのは？～当然インターネットVPNだが…
インターネットVPNの場合は、接続されるのはエンドユーザと（例えば）会社であり、そこからさらに「別のサービスを使う」ための接続が走る。
ユーザ - 職場 - サービスサイト、というような構成になる。
サービスサイトは、なんでも適当なものを想定すればよい。例えばどこかのWebサイトでもよいし、Zoomなどのオンライン会議サービスなどでもよい。
インターネットVPNの問題は？～インターネット技術のよさをある意味全く無効化してしまっていること
テレワークで使われるのは、インターネットVPNだが、別にインターネットVPNが悪いわけではない。ユースケースが悪いのだ。
多くの場合、ユーザは手元の端末（コンピュータなど）から職場などに置いてあるコンピュータににVPN経由で接続し、そこからさらに外部のサービスに接続することになると思うのだが、このときに「通信が必ず職場を通る」ことになる。インターネットは、経路制御プロトコルなどの働きにより、できるだけ高速に通信ができる／通信ができやすい経路をユーザが意識しなくても使用することが可能である。
しかし、テレワークの場合、必ず「職場」を通り、そこからサービスに接続することから、「職場」がボトルネックになる。ボトルネックになっても、仕組み上しょうがない状態であり、もはやどうしようもない。
解決法の案～サービスはサービスに、会社の中は会社に、という形でTPOに応じた通信を実現する必要があるが、問題も。
解決法はいたってシンプルで、会社であろうと外部サービスであろうと、最適な経路を使えるようにすることだ。しかし、会社を通らないとガバナンス上（情報管理上）のリスクを抱えることになる。例えば「社員の私物PCに、業務上の機密資料が複製される」などがそのひとつである。
なので、テレワークを行う社員に配布するコンピュータは、そういうことを行えないような仕掛けを施す必要がある。
むすび～テレワーク時の情報管理に留意する必要はあるが、なるべく必要なサービスにはユーザの手元コンピュータから直接利用できるようにしよう
例で情報持ち出しのリスクの話を挙げたが、このあたりは別にテレワーク云々関係なく考えなければ行けない話である。
通信のボトルネックになるのが職場、というケースが多いことを勘案すると、そこは通らないが、情報管理をきっちりとやる、ということを考えるのがよい。
CVE-2020-10136～IP-in-IPに脆弱性…
久しぶりに個人的なツボにはまる脆弱性が…
CVE-2020-10136の脆弱性概要
詳しくは以下のJVNの記事を見てください。
要は「IP over IPを実現する規格の1つで、悪用される脆弱性があるからね」というもの。
この脆弱性を悪用すると、何ができるのか？
脆弱なIP-in-IPを使えるところを経由して、好きなところにIPパケットを送りつけることができます。いわば「IPパケットプロキシ」のような感じです。
IP-in-IPは、以下のRFCに記述されています。
TCPコネクションが必要など、戻りパケットが必須な攻撃を仕掛けるためには、少しアタマを使う必要がありますし、DDoSのように「大量にあちこちからパケットを送りつける用途」には若干効率が落ちる可能性はありますが*1、単にパケット送りつけられればいいという話であれば、これは非常に有用な脆弱性になります。
対策のサマリ
該当するJVN（http://jvn.jp/ta/JVNTA90492923/index.html）にも記述はありますので、そちらをご覧いただきたいですが、個人的にはそれも含めて以下の3つのいずれかになる、と考えています。
以下、上記のような結論に至った経緯を説明します。
IP-in-IPの通常利用と悪用のイメージ
以下に、通常の利用イメージ（あくまでイメージｗ）を示します。
普通ならば、Normal Userが、IP-in-IPサービスを経由して、任意の（Normal Userが通信したい）ホストにIPパケットを送りつけます。
詳細は省略しますが、通常はNormal Userとの間で、IP-in-IPを利用したトンネルを開設していると考えられるので、戻ってきたIPパケットは、宛先IPアドレスがNormal Userのものであれば、またIP-in-IPを使ってNormal Userに送り届けられます。
ところが、通常のIP-in-IPの規格を見ると、以下のようなことも可能そうです…。
そして、今回の脆弱性は、どうもこういうことが出来てしまう、というように読めます。
ポイントは、Normal UserもAttacker（攻撃者）も、フォーマットが正しいパケットさえ送っていれば、カプセル化を解除の上IP-in-IP serviceを提供するコンピュータ上での処理が走る、ということです。
攻撃者が送りつけたいIP packet2とIP packet3は、送信元IPアドレスに何が入ってるかわからないですが、IPパケットを送りつけるだけで成立する攻撃を仕掛けたいのであれば、これだけで事足ります。
JVNで挙げられている対策～送信元を限定した遮断は「役に立たない」
今回、該当するJVN（http://jvn.jp/ta/JVNTA90492923/index.html）には、以下の4つの対策が記述されています。
- アップデートする
- IP-in-IP を無効化する
- PoC を確認する
- 侵入検知システムでフィルタリングする
この中で、1のアップデートについてはよくわからない*2ですが、2についてはすべてのIP-in-IPを遮断・無効にする対策であり、使わずにすむのであれば、それが一番いいと思っています。
なお、よく言われる「送信元を限定する」対策は、今回の場合は役に立ちません。理由は後述します。
3は確認のための手段なので、有用といえば有用ですが、それで何かの対策になるか？は怪しいです。3を実施して、影響あるとなったら1,2,4のいずれかを実施する、というのが正しいでしょう。
4は「検知する」だけであり、これだけで遮断はできません。
送信元限定が対策にならない理由～IPはステートレス＆IP-in-IPは認証レス
送信元限定が対策にならない理由は2つ。
- IPプロトコルはステートレスである
- IP-in-IPに認証の仕組みがない
IPプロトコルがステートレスであり、かつIP-in-IPそのものには認証のしくみがないため、別の認証手段が必要となります。実際、RFC2003（RFC 2003 - IP Encapsulation within IP）でも、Authentication Header（RFC 1826 - IP Authentication Header）について言及されています。
じゃあ対策は？～IPsecを使うこと。でもこの時点で、IP-in-IPいらなくね？
ここまで読んでくれた人はもう理解したと思いますが、安全にIP-in-IPを使うためには、IP-in-IPパケットの送信元が正当であることを確認出来る必要があります。今、IPパケット単位でこのようなことを実現できるポピュラーな技術はIPsecです。実際、前述のAuthentication Header（RFC 1826 - IP Authentication Header）も、IPsecを実現する1つの形態です（パケット認証のみを行うモード）。今はだいたいESPだけで暗号化＋認証いけてしまうのですが、AHのような認証だけ行うというのも今回の場合は有効である、ということです。
もっとも、ここまでやっておいて、IP-in-IP + AHとするくらいならば、IPsecトンネルモード使えばいいんじゃないか？と思うのはオレだけではないはずです。
むすび～IP-in-IPを使うならばベンダの修正を適用 or AHを併用する or 他の選択肢を採用できないか？を考えよう
今回の脆弱性は、いろいろとステートレスの意味を考えさせられるものでした。
とりあえず「不正なIP-in-IP通信を検知できる」というところでしのいで（問題は、しのいだところで不正なパケット送付を防止できるわけではないこと）、ベンダ製装置を使用しているのであれば、修正を適用する、もしくはIPsec AHを使う、もしくは別の手段に乗り換えるかというくらいしかないです。
テレワーク関係で「即座に」留意しなきゃいけないこと
さんざん書くだけ書いて、すっかり忘れてたｗ
テレワーク関係で「即座に」留意しなきゃいけないことその1～リモート操作ツールのファイル共有機能
例えばWindowsのリモートデスクトップを使う場合、ローカルのドライブをRDP経由でアクセスさせることが可能です。
また、クライアントとサーバの間でファイルをコピペすることも可能です。
ポリシーで禁止することは可能だけど、忘れないでね。
当然、TeamViewerやVNCなどでもファイル転送は可能になるケースはありますし、いわゆるリモート操作系ツールではファイル転送の機能は結構な高確率で実装されているので、ファイルの持ち出しとか點せたくない場合には注意。
テレワーク関係で「即座に」留意しなきゃいけないことその2～オンライン会議サービスのファイル共有機能
これも上記と似ている課題。
契約した側でオフにしたり、会議開催側が無効にしたりとできるみたいだけど、このあたりも留意して使う必要があります。
ファイル持ち出しは、DRM等のツールを使うことで、ある程度はリスク緩和可能
DRM（デジタル著作権管理）のためのシステムを活用することで、ある程度はファイル持ち出しに対抗することが可能。
でも、対応可能なファイル形式に限界があったり、本当に必要があって持ち出す時に（DRM解除しないで）使えないなどという話もあるので、運用が少し難しいかも。
あと、導入にあたり、例えばActive Directoryが必要だったりというケースもあるので、このあたりのものの導入は計画的に。
PPAPは役に立たない
PPAPは、「Passwordつきzip暗号化ファイルを送ります. Passwordを送ります. Aん号化（暗号化
ということで、PPAPは即座に捨てることをお勧めします*1。
おまけ：PPAPがなぜもてはやされている()のか＆その害悪っぷり
諸説ありますが、ISMSの審査観点にこのような手法を取ってデータを保護しているか？という説が個人的には最有力だと考えています。
あと、たまたま「ISMS」「メール」「暗号化」の3つのキーワードで検索をかけたところ、見つかったページの1つに以下のような文章がありました。
様々な企業が「メール添付ファイルのZIPパスワード化」を行っており、そして様々な人が、その方法について議論しています。確かに、技術的な側面から見れば、ZIPパスワード化は無意味かもしれません。
しかし「ヒューマンエラーをなくす」という観点から見れば、1つの立派な情報セキュリティ対策といえます。
ここについては、大いに異を唱えたく。
- 「無意味かもしれません」ではなく「無意味」です
- 「ヒューマンエラーをなくす」という観点から見れば、1つの立派な情報セキュリティ対策といえます→控えめにいっても「いえません」
この論を唱えている会社の製品を見たところ、以下の処理を行うシステムを販売しているように見えました。
- メールに添付されたファイルを抽出し、パスワード付きZIPで保護する
- 元の添付ファイルは削除し、かわりにパスワード付きZIPを添付する
- 元メール内で指定された送信先に、パスワード付きZIPで保護されたファイルを添付したメールを送信する
- 元メール内で指定された送信先に、パスワードを記述したメールを送信する
おそらく、ヒューマンエラーと言ってるのは、「暗号化し忘れを防ぐ」ということだと思うのですが、機能的には送信先の指定誤りには対応できません*2。
そもそもPPAPが無意味である＆その根拠を示している人がいるにもかかわらず（リンク先の記事は比較的最近ですが、主張自体は前から存在します）、無意味とされた手法を金科玉条のごとく遵守する、ということ自体が滑稽である、と考えます。
本質的に暗号化には、機密性を担保する役割があります。暗号化を施すことで、以下の2つの効果を期待できます。
- 途中経路での覗き見に対抗する
- 誤った送信先（閲覧権限のない相手）に機密情報を添付したメールを送ってしまった場合であっても、内容の閲覧はできないようにする
PPAP自動化を行った場合、1も2も達成できないどころか、「システム入れたから大丈夫」という謎の安心感から、いわゆる機密情報誤送信系のインシデントの発覚が遅れる懸念があります。なにせ、暗号化、暗号ファイル添付したメール送信、パスワード送信の一連の操作を自動化してくれてるので、送信先を誤った時には、そのまま暗号化ZIPとパスワードが誤った送信先に送られます。
これならば、アクセスリストをきちんと設定したオンラインストレージの上にファイルを置いておくほうが、はるかにマシです。
また、筆者は、上記以外にも「害になるであろうケース」を発見しています。
- 添付ファイルの暗号化が「広義でのメール改ざん」になるため、PGP等の署名検証が失敗する
- 署名データそのものが暗号化される懸念がある
PGPで再署名したくても、秘密鍵は送信者の手元にあるのが普通であり、変なシステムに預けるとか危険極まりなくてやりたくありませんし、できません。
その他、筆者はまだ経験したことはありませんが、最悪「PGP等で暗号化されたデータがさらに暗号化ZIPに含められる」という、冗談のようなことが発生することも想定されます。
冗談のようですが本当に起こった（もしくは起こりうる）害悪を前にして、これをして「セキュアである」という方は、ぜひその根拠を教えて下さい。もしくはもっとシンプルに「PGPよりもPPAPのほうが安全である、という根拠を示せる人がいたら、ぜひ私に教えて下さい」。
書いていて、PPAPが想像以上にダメなことを再確認してしまって、頭が痛い…
テレワークはいいかもしれないが、導入を決めるまでが結構大変かも…（制度、技術、セキュリティをどう考える？）
書いたら長くなった…けど、何らかの議論のネタなりになればということで、とりあえず放流する。
「テレワーク」というと、なかなか魅惑なパワーワードだが、ちょっとアタマを巡らせると、かなり大変であることがわかる。
大変といっても、実は文章の読み替えをやったり考え方を柔軟にしたりということをできれば、あんまりハードルにならないのかもしれないが、考えないといけないことをとりあえずざっと書いてみた。
とりあえず、一つの思考実験的に書いたものなので、考え違いや抜け漏れあるかもしれないが、そこはご容赦を。
1. 制度面の課題
テレワークというと、オフィスにいなくても仕事が出来る、とポジティブに考える人が多いが、会社の就業規則などの面を考慮すると、結構な難事が出てくる懸念がある。
とはいえ、（最初に結論を書いてしまうが）何のための業務で、どんな成果を期待するのか？が明らかになれば、下記の話は（本質的には）問題にならないことが多い。むしろ問題にする人がいるとしたら、「既存ルールの整合性をどのように取るのか」ということを考えなければいけない人であろうと考える。
1.1. 就業場所に関する規則
こんなこと書くと、「また昭和かよ」と言われそうだが、別に平成の早いうちでもこういう話はいくらでも出てきていたので、昭和だの平成だの令和だのというようにくくらないでほしい。
基本、テレワークのような就業場所にとらわれない働き方を前提に出来るのは、最低限3つの前提を満たす必要がある、と考えてほしい。
- 特定の就業場所に行かなくても遂行可能な業務であること
- 就業規則等で、特定の場所以外での業務遂行を認めていること
- 顧客との契約上、特定の場所以外での業務遂行を認められていること
個々の業務特性を考慮すると、さらに条件は細分化されるが、とりあえずざっくり上記3つについては、「最低限」押さえておかないといけない、と私とかは考える。
1.2. テレワークに係る費用負担
テレワークは、インターネットのような安価かつリーズナブルな通信帯域を「誰もが」利用しうる状況になって、はじめて可能になった就労形態とも言えるが、そこにかかる費用を（たとえ少額とはいえ）労働者の持ち出しにしてよいのか？という議論が出てくる懸念はある。そこは、光熱費なども同じことが言える。
1.3. 労働時間の算定に関する課題
「8:30～17:00勤務」とか、固定的な労働時間帯を設定し、そこは業務専念すべし、という話になってくると、結構ややこしい。そもそも「その労働時間帯は適正であるか？」とか、「何を根拠にそう決まっているか」という話も出てくる。
1.4. 勤怠管理および評価に関する規則
これは、労働者当人というよりは、管理者が「どう評価すればいいのか」という話に帰着する。
労働時間については、「一定時間、適切に手を動かしていれば必ず成果が出る」という思想に基づいたものであると考えられるため、そういう考え方がフィットしないような業務であれば、そもそも勤怠管理という考え方をあらためる必要があると考える。
「プロセスもきっちり評価する」という話であっても、「そのプロセスをどう遂行しているのか」がわかればよい話であり、それを時間だけで評価すると、どうしても評価結果が歪む可能性がある。
1.5. まとめ～制度ありきでテレワークを難しくするのではなく、何のためにどういう制度を敷くか？を考えよう
会社における制度は、会社がその社会的使命を果たすために、構成員に求める行動を明文化したものである。
管理のため云々という話はあるだろうが、じゃあその管理は何のためか？というのを考えていくと、最終的にはその会社が何のために業務を行っているのか？に行き着くはず。
個人事業主や構成員の数が少ない会社の場合は、こういう制度をがらっと変えて周知、というのももしかしたら難しくないのかもしれないし、場合によっては明文化も（法令が求めるもの以外は）なされなくてもうまくいくのかもしれない。しかし、構成員（社員）が多くなればなるほど、こういう制度をきちんと決定の上で周知・遵守を促さないと、だいたいの場合はうまく動かない。
しかし、そのために（業務によってはできるはずの）テレワークをしない／させないというのは、非常に残念な結果を招く。
技術的課題はあるものの、可能であれば制度面をきっちり整備して、可能な業務ではテレワークを（ある程度）認める、というように舵を切るのもアリなはずだ。
2. 技術的課題
制度的な課題をクリアしても、次は技術的な課題がある。
オンプレミスを主体とした社内システムや業務システムを持っている会社の場合、テレワークを実施することで、インターネットの出入り口に設置・稼働している機器の負荷が逼迫する可能性がある。
2.1 何がテレワークを阻害するのか？
特に昨今、DaaS（Desktop as a Service）をパブリッククラウドではなくオンプレで（社内ネットワークに）構成している場合には、そのような社内ネットワークを構成している機器の負荷は、設計時のものを超える懸念がある。
- (1) RDPによる画面転送に起因したトラフィック
ここは、当然だが会社からのアウトバウンドが増える。 - 音声系トラフィック
ここは、何を使うかによって、トラフィックの増え方が変わる。 - 動画系トラフィック
ここも、何を使うかによって、トラフィックの増え方が変わる。
1はしょうがないとしても、2,3は問題になりうる。
個人的には、以下の2つの条件が同時に満たされてしまった時に、問題は顕在化しうる、と考える。
- オンライン会議系の外部サービス（例：WebEx、Zoom、Microsoft Teams）をオンプレDaaSもしくは社内に設置したPCで使う
- 社内で構成したオンプレDaaSもしくはPCをRDP経由で「社外から」使う
この2つが場合は、音声系や動画系の情報が、HTTPS経由でDaaSなど社内に入ってきたあとに、RDPトラフィックに乗って社外（利用者のところ）に出ていく。
発生する通信は、社内から普通に利用する時の倍程度（インバウンドとアウトバウンド）の想定。音声だけならばまだしも、資料の画像や動画などが乗ってくると、かなりクる。
あと、オンライン会議を多くの人が使うようになると、今度はアウトバウンドのTCPセッションの数が問題になりうる。普通にStatelessなWebアクセスが大半だったりする分には全然OKで、通常のようにF2Fで打ち合わせを行うなどであればいいのだが、オンライン会議がマジョリティになると、今度はTCPセッションが膨大になる。
このあたり、何の考慮もしていなかったりすると、利用者数が万単位になった瞬間に詰む。まぁ、普通は万単位の利用者がいる場合には、Proxyなどはロードバランサ使って適度に振り分けるはずだが、オンライン会議は基本数十分とか1時間とかセッション張りっぱなしというのもザラである。
トラフィック量（帯域）の話以外だと、テレワークの場合は、プロトコルの限界や、トラフィックをさばく機器の性能問題は、多分トラフィック量よりも先に限界が見えてくる、と思う。
2.2 本質的な技術的課題：会社の環境がすべてのボトルネックになる
他の要因もあるのかもしれないが、何をするにも一旦会社の中に収容され、会社の外に出ていく。管理はしやすいかもしれないが、管理のしやすさと引き換えに、多くのユーザにとって利用しづらい環境（業務アプリケーションを満足に利用できないなど）を実現してしまう。
2.3. とりあえずの解決策の案：せめてオンライン会議くらいは会社を経由させるな
オンライン会議のサービスは、（当然だが）外部のサービスであることが大半だ。
だったら、家から直接使ってもいいのではないか？と考える。
それが出来ない場合は、会社の設備を増強するしかないわけだが、それにも限界がある上に、直接外部のサービスを使ったほうが効率はよい。
もちろん、持ち出し出来ない資料（でも投影は可）を、会議で使うこともあるだろう。この場合は、会議運営を行うホストのみが社内システムに入る形にし、参加者は直接オンライン会議サービスに接続させる、というのでよいのではないか。あとはホストの権限で、ファイルを見せることはできても共有出来ないようなしくみを使う（例えば、ファイル共有機能を無効にする）ことで、ある程度の対処は可能だ。投影内容を写真に取られたらどうする？的な話はあるだろうけど、テレワークを実施させる以上、常につきまとうリスクだ。
完全には難しい場合には、オンライン会議系のトラフィックは、別のNWから外に出す、というのもあるかもしれないが、NW構成が面倒になるだけな気もするので、オススメは最初から会社を経由させない、というもの。
3. テレワークに係るセキュリティ
あまりセキュリティの話はしたくないのだがｗ、オレ自身にそういう属性がついてしまっているので、とりあえずざっと書いておく。
3.1 ソリューションありきで考えない
昨今、「これ使えばテレワークバッチリ！」と煽っているソリューションやツールが多いが（個人的には、Tea○Vie○er使えばバッチリ！と言ってるところがあって、こけそうになったｗ）、ソリューションやツールはあくまで「業務を補助する道具」である。
もちろん、ないよりはあったほうがいいが、そのソリューションを導入したら何が出来て何ができないか、何は制御できるか？という話を、後述する3.2のところでリスクを考える時に、細かく見ていく必要がある。
自分とこに必要なものが何か？をきちんと押さえておくことが重要である。それこそ「監査できること」なども、要件に含めておく必要があるが、これは別にテレワークに限った話でもないか。
3.2 自分のところにとっての「テレワークを認めることによるリスク」を考えよう
テレワークを認めることによって、どのようなリスクが発生するのか？を認識しよう。
1,2で「いけるね」となっても、ここがダメだとそもそもテレワーク難しいね、になってしまう。
3.3 リスクに応じた情報の機密性、完全性、可用性の確保を考える
ある程度リスクを考えることができれば、あとはそのリスクに応じて対処を行うことを考えよう。
- 仕事場以外で仕事をするからといって、情報をお気軽に持ち出されては非常に困る。
- 仕事場以外で会議（オンライン会議）をする時に、大丈夫なしくみがあるか
3.4 リスクが現実になってしまった時の対応プランを考えよう
これは別に、あらためて考えるというよりは、既存のプランがきちんと発動するかどうか？を確認する話と考えてもらえればよい。
何か起こってしまった時に、事象を追跡できるようにする、という話もこの中に含まれる。
裏を返すと、テレワークに必要なツールは、ユーザの行動を（後追いであっても）追跡できるものが望ましい、ということになる。
4. まとめ～テレワークを実施したいのであれば、制度と技術とセキュリティの3面から！
少し長くなったが、最終的に述べたいのは以下の5つ。
- テレワークを出来る土壌があるならば、テレワークを認めてもよいのではないか
- テレワークを認めてもよいのであれば、認める根拠を制度化すべき
- テレワークを実施するにあたっての技術的な課題を考慮のこと
- セキュリティ関連の話は、リスクもあわせて考慮のこと
- 最終的にテレワークを認めるかどうか？は、上記1～4を勘案の上、総合的に判断すること
とはいえ、テレワークやらなくても考えないといけないことも「かなりあるはず」なので、備えをきっちり出来ているところであれば、見た目ほどの作業は発生しない…と思いたい。
…結構長くなったな…。
「Zoom」のその後
IPAから続報が出ていたので、ちょっと見てみました。
www.ipa.go.jpそこには、「どうやったら警告が出てくるのか？」の解説がありました。
なんだ、インストールした後に「買う」とすると、あの警告が出てくるのね。ということで、またまた検証してみました。いろいろと釈然としないのもあるので、とりあえずスッキリするために。
なお、同じことやってマシン壊れたとか調子悪くなったとか言われても、こちらで責任取れないので、試すときは自己責任で。
まずは「Zoom」を起動して「Purchase」を選ぶ
これは、上記のIPAのページでも紹介しているものですが、とりあえず「Zoom」を起動して出てくる画面から「Purchase」を選びます。
一番上を選ぶと、「警告画面」が出てくるはず…なので、確かに警告画面は出てきたのですが、ウチでは違うものが出てきました。
これ、使用しているセキュリティソフトウエアの警告画面です。
この検証自体は、VMware上にインストールしたWindowsで実施しているのですが、VMware - ホストOS - インターネット と出て行く前に、セキュリティソフトウエアが通信を見て、ヤバいURLにアクセスしようとしたら「ここ危険だからとりあえず止めてます」という画面を見せるようになっている、というわけです。
「Zoom」でPurchase押した後は、どんな通信が走っているのか？
簡単に言うと、Webブラウザを起動して、特定のURLにアクセスしようとしています。
見たところ、「Zoom」を開発・販売している会社のWebサイトの"/buy.html"というページにアクセスしようとしているのですが、見たところ、その会社のWebサイトはすでに存在せず、そのかわりに別のサイトにリダイレクトされます。
/buy.htmlにアクセスした際のレスポンスが、「302 Found」なのですが、Webブラウザは、レスポンスに含まれるLocationヘッダで示されたURLにさらにアクセスに行きます。
これ以降、ずっとHTTPSアクセスなので、その中で何が起こっているのか？までは推し量れないのですが、アクセスする中でセキュリティソフトウエアが「危険」とみなしているサイトにアクセスしようとしたため、セキュリティソフトウエアからの「警告メッセージ」が表示された、というのが私のところで起こったことです。
今回「Purchaseボタンを押しちゃった時の対処」＝「ウィンドウを消す」は正しい
今回、不幸にしてさまざまな脅しメッセージを表示されちゃった人もいらっしゃると思いますが、落ち着いてみれば「ブラウザの画面に警告入れたり派手な表示にしたりして、恐怖を煽っている」だけです。
なので、その時になんかのソフトウエアをインストールしたとかなければ、新しく表示されたおどろおどろしいWebブラウザのウィンドウを「ウィンドウの右上にあるバツ印のボタン」をクリックして消せば、さっぱり消えます。
仮に何かプログラムの実行を促されても、決してやっちゃいけません。それは最初に「Zoom」をインストールした時と同じかそれ以上に危険な行為です。
これはZoomだけどZoomじゃない！（意味不明）
みんな大好き＆私も大好きなZoomですが、最近偽物が増えてるという噂を聞きます。
で、我らがにゃん☆たく先生も検証されている。
ただ、にゃん☆たく先生の検証範囲は、「これは僕が使いたいリモート会議のZoomじゃない！」という結論で終わっているように見えるので、じゃあそのZoomはどのZoomじゃい？というのを確認してみました。
なお、本稿では以降、、いわゆるリモート会議サービス「じゃない」Zoomを「Zoom」と称します。
まずはかの「Zoom」をインストール
「Zoom」をどうやってインストールしたか？はおいときます。同じことやって「PCが壊れたどうしてくれる」と因縁つけられても嫌なんで。
普通にインストーラをダウンロードして実行することで、普通にインストールされたわけですが、なるほど。インストール直後に以下のような画面が。
なお、最初にスクリーンキャプチャを取りそこねたんで、「（イメージ）」と書かれてます。上の図は、インストールされた「Zoom」を（わざわざ指定して）起動した図です。Run 3 out of 20 と書かれてるんで、「20回のうち3回起動した」ということで、あと17回起動できます。
「Zoom」の開発元Webサイトにアクセスする（失敗）
次にやったのは、Dachshund Softwareという会社のWebサイトを探してアクセスすることですが、これは見事に失敗しました。理由はよくわからね。
「Zoom」のヘルプを見る
実行ファイルがあるんだから、ヘルプくらいねえのか？と探したら、ありました。
一緒にインストールされていたので、見たところ、以下のような画面が。まっとうです。
ちっこくてわからないかもしれませんが、上記は「What is Zoom?」の部分です。
書かれていることは、「Zoomはソフトウエアの起動、再起動、スタンバイ、復帰を高速化する」ということで、「リモート会議には全く役に立たない機能」ということがわかりました。
さっきのうっとおしい画面は「試用中画面」ということで、金払うかどうするか？を問い合わせるだけのものだった、ということで。
「Zoom」の消し方
普通にアンインストールすれば消えるようにみえます。
上記で「Zoom 1.3.1」を選択し、上の「アンインストールと変更」を押して、アンインストールすれば消えます。
名前がかぶった「Zoom」とZoom（あーまぎらわし）
不幸にして名前がかぶった、機能違いの「Zoom」ですが、インストール時のサポートプラットフォームに以下のような一文が（赤字・協調は筆者による）。
Zoom is fully compatible with Windows 95/98/98SE/Me/NT/2000/XP.
ということで、「Zoom」は、リモート会議のZoomよりも、だいぶ古いであろうことが推し量れます（騙りでなければですが）。
むすび～ソフトウエアを使う時は正規サイトから＆名前だけでなく機能も吟味しましょう
今回検証した結果、「Zoom」は同じ名前でも、機能が異なるソフトウエアというオチでした。しかしこれは、Zoomのサービスをきちんと指定して（今回の場合はリモート会議）検索なりすれば、だいぶリスクは下げられるのではないか？と感じています。
リモート会議のZoomは、自分とこのサービスを紹介するページとかも作っていますし、そもそもZoomを使って開催される会議に参加するだけならば、ソフトウエアをインストールしなくてもいけます。
会議に参加する側は、多分「検索→ダウンロード→インストール」とか複雑な手順を踏まなくても、「https://zoom.us」ではじまるURLをクリックすれば参加はできます*1。
どうしてもZoomクライアントをインストールしなきゃ、という人は、会議の主催をする人か、Zoomの機能をフルに使いたい人じゃないかと思いますが、そういう人は慌てずに、ちゃんとZoomのサービスサイトにログインして、そこからいろいろと探すのが良いかと思います。
もっとも、Zoom会議の招待メールを模したものが来てる気もするので（私のところには来てませんが）、見に覚えのない会議招待は、招待元に確認するなりスルーするなりしてもいいかなと思います。もしあなたがその会議に必須のメンバなのであれば、別の手段で確認が来ます。
Happy Remote Conference!
*1: これはこれで危ういのですが