今日は、一般生向けの記事です。
Windowsキー([Wn]キー)を使ったちょいテクをご紹介。
使い方は、複数のアプリを起動しているときに試してみるとわかります。
タスクバー（Windows10なら、画面一番下にある、横長の黒いエリア）に表示されているアプリの、
[Wn] + [1] : いちばん左のものをアクティブにするとき
[Wn] + [2] : 二番目に左のものをアクティブにするとき
[Wn] + [3] : 三番目に左のものをアクティブにするとき
という具合です。
起動しているアプリのうち、左から10個目まではこれでOKです。
「11個目はどうすれば？」という疑問が当然でるかもしれません。
そういうときにも使えるショートカットキーはあります。
が、「アプリを11個起動しているとき」のやり方の話は今回は省略します。
そもそも、「11個もアプリを起動している」という状態が生産的でないです。
そういう状態のまま押し切るための技を学ぶよりもあなたの仕事の成果に直結することがあります。
それは、スマートに仕事を進められる考え方を学ぶことです。
以下の無料講座でどうぞ。
– – – – – – – – – – – – – – – – – – – – – – – – – – –
本題です。今日は、スキル系のお話。
昨日(2018年12月6日)、ソフトバンクで通信障害が起こりました。
かなり大規模で、4G(LTE)回線は全滅だったそうです。
ネット上でも、いろいろな方が嘆いているのを見かけました。
原因は、ソフトバンクによれば、「エリクソン製交換機の
ソフトウェアに異常が発生したため」とのこと。
この障害は、エリクソンの通信設備を使用する海外11カ国の通信事業者でも、
ほぼ同時刻に発生したそうです。
それが、どうも、技術者のポカで生じた、簡単なミスっぽい。
○ITmedia「ソフトバンクの通信障害、原因は「エリクソン製交換機」 ソフトウェア証明書の期限切れ」
サーバ側システム開発をそこそこ経験したことがある方なら
同意いただけるものと思いますが…。
「ソフトウェア証明書の期限切れ」って、
「相当のポカなんじゃないか？」という香りがプンプンします (-_-;
基本中の基本のところでコケてしまったぽい。
– – –
情報セキュリティについてしっかり学ぼうとして教材を開くと、必ず出てくる項目があります。
[1] 情報セキュリティの三要素
[2] リスクアセスメント
[3] リスクへの対応
今日は、今回のソフトバンク通信障害の件を参考にして、上記[1]-[3]について書いてみたいと思います。
「情報セキュリティの三要素」というのがあります。
以下の3つです。
[1-1] 機密性
[1-2] 完全性
[1-3] 可用性
それぞれ、簡単な言葉でもう少し詳しく書くと以下のとおり。:
[1-1] 機密性
権限のある人にしか見られないようにする
[1-2] 完全性
表示される情報に間違いがないようにする
[1-3] 可用性
使いたいときに、使えるようにする
こういう分類を知ってから見直してみると、今回の障害は、要は、「可用性」の問題ですね。
「リスクアセスメント」というのは、上記三要素のそれぞれをリスクにさらしてしまう理由として、どんなことがあるだろう？そして、それは、どの程度ありえそうだろう？それが起こったら、どのくらいの損害になるだろう？と、検討することです。
たとえば、携帯電話の一般ユーザであれば、「可用性」をリスクにさらしてしまう原因として、
「X社で購入した携帯端末が壊れるかも」
「端末じゃなくて、端末に挿入したSIMカードが壊れるかも」
「X社の通信インフラが壊滅するかも」
「ゴジラがX社の通信機器だけを集中的に壊しにくるかも」
とか、いろいろな可能性を考えること。
それぞれの原因ごとに、「いかにありそう」とか、「まあないな」とか、思いますね。
さらに、そのそれぞれについて、自分にとって、どの程度痛いだろう？と考えます。
できれば対策にかかる費用を、金額に換算して。
「まあ、たいしたことない」、「破産するくらいに痛い」等々、原因によりいろいろです。
「リスクへの対応」というのは、「じゃ、ダメだったときのために、どんな準備をしておこう？」と、いうことです。
対応策は、大きく、以下の4つに分類できます。
[3-1] リスクの低減
[3-2] リスクの保有
[3-3] リスクの回避
[3-4] リスクの移転
それぞれ、平たく言うと、こういうこと↓です。
[3-1] リスクの低減
問題が起きてもダメージをあまり追わないような仕組みにしておく。
たとえば、X社だけでなく、Z社の携帯も持ち歩く、とか。
[3-2] リスクの保有
そのときは、「全ダメージを自分で負う」と決める。
たとえば、「X社の通信が壊滅したときは、それはもう仕方ない。」と、肚をくくっておく。
[3-3] リスクの回避
「これはヤバいでしょ！」ということで、違う手段に乗り換えておく。
たとえば、X社の携帯は契約解除し、新たにZ社の携帯を使うようにする。
[3-4] リスクの移転
問題が起きたときには補償を得られるよう、保険をかけておく。
たとえば、X社の携帯の契約時に、「通話できない状態が○時間連続したら、X社から○円もらう」という付帯条項をつける。
あるいは、どこかの損害保険会社と、「通話できない状態が○時間連続したら、保険会社から○円もらう」という契約をする。
今回であれば、おそらく、ソフトバンクは「[3-4]リスクの移転」はしているでしょう。
ソフトバンクは、エリクソン社製通信システムの納入時に、「納品されたシステムに著しい瑕疵があって障害が発生した場合は、それで生じた損害を請求する」という付帯条項をつけた契約を交わしていることでしょう。
さらに、損害保険会社と、「ウチの取引先の失敗で通信の大規模障害が発生して予期せぬ損害が生じたら、取引先に損害賠償するが、それだけでは足りなかったら、残りの出費は保険でまかなう」という契約をしているかもしれません。
エリクソン社はエリクソン社で、損害保険会社と、「納品したシステムが予期せぬトラブルを起こして納品先に大損害を発生させてしまったら、その補償のうちある程度までは保険でまかなう」といった契約をしているかもしれません。
もっとも、ソフトバンクによると、今回の障害の理由は、「エリクソン社が納品したシステムのソフトウェアの、ソフトウェア証明書の期限切れ」ということです。
これは、もし本当にそうなら（かつ、僕がイメージしているようなことが現実に起きていたのだとしたら）、「かなりの大ポカ」です。
保険会社も、ソフトバンクなりエリクソンなりと保険契約を結ぶときには、「リスクアセスメント」をして、とんなリスクがありそうか？そのときは、どんな影響がありそうか？ということを慎重に検討し、費用を算定し、しっかりした契約書を作ったことでしょう。
そのとき、果たして、「プログラマーがうっかりして、ソフトウェア証明書の期限がすぎているせいで、大規模障害が起きる」なんてことをエリクソン社がやっちまうリスクまで検討して、そのリスクの分までを保険料に含んでいるだろうか？
どうでしょうね…。保険については僕は素人ですが、個人的な見解としては、そこは怪しいんじゃないかな～、と思います。
保険会社が「いや、そんなポカまでは補償するとは契約書に書いてないぞ！」と言ってきたら、エリクソン社は大ピンチ。
あと、エリクソン社の、当該通信機器のソフトウェア開発責任者のことも気になります。
開発責任者氏は、責任者ですからいろいろなリスクのことは考えてはいたことと思います。
しかし、果たして、「もしも、『ソフトウェア証明書の期限切れ』なんてポカが起きたときには？」なんてことまで考えていたのか？と。
開発責任者氏にとっての「[3] リスクへの対応」は、こんな感じ↓ですかね。
[3-1] リスクの低減
問題が起きてもダメージをあまり追わないような仕組みにしておく。
ここは、勤め人ならまあ大丈夫でしょう。会社として請け負った仕事だと財産全部投げうって損害補償しなくてはならないかもですが、勤め人なら、せいぜいクビになるくらい。
[3-2] リスクの保有
そのときは、「全ダメージを自分で負う」と決める。
「部下のプログラマーがそんなポカやっちまったときは、まあ仕方ない」と、あらかじめ肚をくくっておく。
↑ありえない。僕ならムリです。ブチ切れる可能性大。
[3-3] リスクの回避
「これはヤバいでしょ！」ということで、違う手段に乗り換えておく。
たとえば、「あの『ポカ』をやりそうなプログラマーはクビにして、もっと優秀な人材を雇う」
↑今になって振り返れば、これはできたかもしれないですね。問題が起きてからでは遅いですが。
あるいは、「最終責任者は上司たる統括プロマネで、私のせいではありません」と、責任回避。
[3-4] リスクの移転
問題が起きたときには補償を得られるよう、保険をかけておく。
エリクソン社でポカをしたときのための転職準備として、日ごろから、同業他社の人と交流しておく。無事に転職に成功すれば、翌月からのお給料は転職先からもらえますね。
↑
これは、別に「リスク移転」のためとは思っていなかったでしょうが、日ごろからしていたことでしょう。
…と。
いろいろな立場から、システムのセキュリティリスクについて検討してみました。
システムというのは、それがどんなものであっても、障害が起きて当然なものです。
それを作る側にいても、運用する側にいても、利用する側にいても、
「情報セキュリティ」については:
[1] どんな要素があって（情報セキュリティの三要素）
[2] どんなリスクがあって（リスクアセスメント）
[3] それぞれのリスクが顕在化したら、そのときはどうしよう（リスクへの対応）
という視点で考え、整理しておきたいところです。
あらかじめリスクについて考え整理しておくと、いざというときにも、だいぶ感じ方も変わりますし、対策もより冷静に取れるようになります。
[参考]
・情報セキュリティの3要素(JINSA 経済産業省)
・リスクアセスメント (IPA 情報処理推進機構)
・リスクへの対応 (IPA 情報処理推進機構)
このメールへのフィードバックもお待ちしています。
こちらよりお願いします。お気軽にどうぞ。
個別にお返事はできませんが、すべて読んで、以降のメルマガに反映させています。
