t-hom’s diary

主にVBAネタを扱っているブログ…とも言えなくなってきたこの頃。

脆弱なパスワードや使いまわしを避けるために、サービスごとにリスク評価してみた

今回は私が使用・契約しているサービスやIT機器についてパスワードに関するリスクを評価してみた。
実は現在の私のメインの仕事はIT統制なので普段は会社の様々なリスクを評価し、対策を講じている。折角なのでそれを私生活でもやってみようという企画である。

脆弱なパスワードや使いまわしはよくないとされるが、ついついやってしまいがちだ。
かくいう私も全部が全部強力かつサービス固有のパスワードを設定しているかというとそんなはずはなく、パスワードによっては特殊記号を使ってなかったり、ある程度他のサイトでの使いまわしはやってしまっている。

これが絶対にダメと唱える人もいるけど、そういう理想論は「人の性」というものを理解していないと思う。
人間というのは、ダメとわかってても、やってしまう生き物なんだ。

なので私は別の方向性を提案したい。

「せめて、これ流出したらヤベェってやつだけでもちゃんと管理しようぜ!」

ということで、自分にとってヤバいものを分類してポリシーを決めたのが以下の表。
f:id:t-hom:20220306113450p:plain

この表は、以下の方法で作った。

  1. まず5つの観点で資産評価を行う。
  2. そして現在自分がプラットフォームへのアクセスに使用しているコントロールの原理的な強度を評価する。
  3. 上記の情報をもとに、脅威(発生確率)と影響を評価する。(用語ブレ申し訳ない)
  4. 脅威と影響を掛け合わせた数値で各種リスク値を算出し、さらに各種リスク値を掛け合わせて総合リスク値とする。
  5. 総合リスクを判断のベースとして、更に個別のサービスの事情を加味しながらパスワードポリシーを決定する。

補足) 流出可能性はそのサービスが脆弱だという意味ではなく、単にネットに繋がってるかどうかで判定している。GitHubは。。スクショ取る段階でミスってるだけ。後で3に変更した。

私自身は最終的にパスワード強度を「低」に分類するようなものであれば使いまわしても正直問題ないかなぁと思うけど、今回「中」分類したものが多くて結局パスワード管理ツールを使うので、どのみちツール化するなら全部固有にするつもりだ。

私はこうすると決めたけども、真似したくても面倒でやってらんないという方は「リスクによって対策レベルを分ける」という考え方だけでも取り入れてみると良いんじゃないかなと思う。

これが流出・消失すると経済的・社会的に第ダメージを食らうというサービスは誰しも一つや二つ使っているはず。
そういうクリティカルなパスワードと単なる使い捨てのようなアカウントに使うパスワードを一緒にしてしまうということは避けたい。

以上

当ブログは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。