リスク対応
前回はリスクマネジメントについてかるーく触れたので今回はリスクマネジメントの中で実施するリスクアセスメント、その後に行うリスク対応について調べてみました。
- リスク対応の概要
リスクアセスメントでリスクを分析、評価しました。けどその後の対応が間違ってたら意味がない。
そのリスク対応については大きく分けて二つ、リスクコントロールとリスクファイナンスがあります。
- リスクコントロール
これは潜在的なリスクに対して、物理的対策、技術的対策、運用管理的対策によって、発生を防止したり、損失を低減させてりすることですね。 例としては機密データのあるデータセンターを免震構造にしたり、入退室の履歴をしっかり取ったりすることが挙げられるかも。
こっちはリスクを抑えるのではなく、リスクが顕在化して損失を負うこと前提でその時に備えて損失の補填や対応費用などの確保をしておくことらしい。損失を負うこと前提って考え方はなんとなくフェールセーフやフェールソフトを思い出しますね。
リスクはどれだけしっかりリスクコントロールしても顕在化の可能性を０にすることはできない。そのために資金面での対策を講じておくことも非常に重要らしいです。
具体例としては 保険を利用して不測事態発生時の対応費用を組織外に転嫁 不測事態発生時に備え、準備金・積立金などの名目で組織に対応費用を確保
難しいですね… ここら辺は実務を経験してる人でないと理解しずらいかもしれません。
さて、二つの対応を行いましたがそれでもリスクは残ります。こういったリスクの事を「残留リスク、残余リスク」なんて呼ぶそうです
じゃあ残りはどうするのか。難しいところですがその場合はリスクの強度や予算などとの兼ね合いによりあえて対処を行わないことがあります。それがリスクの受容です。リスクの受容については組織としての判断基準を予め明確に決めておかないといけません。
ちなみにこのリスク対応等諸々含むリスクマネジメントに関する規格は ISO 31000:2009/JIS Q 31000:2010 で定義されています。 気になる人は調べてみるといいかもしれません。
では今回はここら辺で失礼します
ドラクエのせいで暫く記事書くテンションにならなかったなんて言えない…
リスクマネジメント
ソフトウェアやサービスの開発、運用をしていく中でリスクというものは切っても切り離せないものだと浅学ながら自分では考えています。
そんなリスクを大きなフローの中で分析し、対応することが昨今では必須となっていますが今回はその中でリスクマネジメントについてまとめてみました。
- リスクマネジメント
リスクマネジメントには
2.リスク対応方法の洗い出し
3.リスク対応の実施
4.リスク及びリスク対応の洗い出し
の4つのプロセスがある。これらのプロセスは一過性のものではなく継続的に繰り返していく必要がある。
一つ一つ見ていくと、
①リスクアセスメント（リスクの分析、評価）
これは実際にその計画（運用や開発）の中にあるリスクが顕在化した場合もたらすものを対象としている。リスクマネジメントの対象となる組織や情報システムのどこに、どのように潜在しているのかを発見・確認し、その大きさを測定・評価する。
②リスク対応方法の洗い出し
リスクアセスメントの結果を受け、損失を最小限に抑える適切なリスク対応方法を洗い出す。
③リスク対応の実施 洗い出されたリスク対応と、 予算や組織などの兼ね合いによって、実際に実施するリスク対応策（大体セキュリティ対策？）を決定、実施する。ちなみに、この時決定されたリスク対応方法は情報セキュリティポリシにも確実に反映させる必要がある。
④リスク及びリスク対応方法の見直し
リスクそのもの及び、実施済みのリスク対応方法を定期的に見直し、必要に応じて改善することで、リスク対応の効果を維持する。
今日は眠いのでここまで。明日リスク対応についてまとめます
公開鍵暗号と共通鍵暗号
簡単に言うと暗号化と復号化を同じ鍵で行う方式。つまり送信者と受信者で一つのカギを使うので、別の通信相手の場合には別のカギを用意しなくてはいけません。代表的な共通鍵暗号方式としてAESがあります。
鍵の数は n(n-1)/2 です。
- 公開鍵暗号
公開鍵暗号は多対多のインターネットにおいて優れた暗号化方式ですが暗号化と復号化に共通鍵暗号のおよそ数千倍の時間がかかり、CPUにも負荷がかかります。
公開鍵暗号のカギは二つ存在し、秘密鍵と公開鍵にわかれます。サーバーなどが多数のクライアントと通信をしたい時、データを秘密鍵で暗号化して公開鍵を各クライアントに配ることで復号化してもらいます。この時データの暗号化は秘密鍵でしかできません。なので秘密鍵は絶対に秘匿しておく必要があります。
- RSAの安全性
暗号技術分野の知識ですがRSAの安全性の根拠は桁数の大きな整数を素因数分解するのが困難だということを根拠にしています。
例として、 1. 二つの素数を挙げる a=523,b=613
数字の桁数が大きくなればなるほど素因数分解は困難になります。つまり数字の桁数がそのまま鍵の安全強度に繋がります。実際のRSAではもとの素数に150~300以上もの桁の数字を使用しているそうです。
暗号技術についての雑記
そもそも暗号ってなんぞや？という時が自分にあったのでまとめておこうかなと思います
一番原始的とも言える暗号を例に紹介します。それはシーザー暗号です。
シーザー暗号は簡単に言うとアルファベットをずらすことによって文字列を暗号化します
・例 Hello ⇒ ifmmp 例は1文字ずらしただけです。それでも平文の原型を残さず別の文字列にすることができました。
では例の場合のカギは？ それは １ です。
この暗号は確かポケモンBW２の海底遺跡か何かでも使われていたと思います。
この他にもデータの場合は全て2進数になおして鍵とXORを演算することで暗号化するというような方式もあります
暗号技術の書籍は結構あって面白いので是非興味があったら読んでみることをお勧めします
そもそもどうして暗号化のアルゴリズムと鍵を分ける必要があるのか。それは毎回データを暗号化するのに新しいアルゴリズムを生み出すのはめんどくさい。何回も同じの繰り返して使いたい。だけど同じアルゴリズムを使っていると解読されるリスクが高くなってしまう。だから、暗号化アルゴリズムに「変更可能な部分」を残しておいて通信ごとにそこを変えればなんとかなるだろう。その変更可能な部分というのが鍵のことですね。 先人たちの偉大な努力の結晶ですね。
もし今度時間があったら色々な暗号化アルゴリズムについてもまとめてみようかなと思います
なんというか暗号化アルゴリズムについての方がつい熱が入ってしまいました。次回は何についてまとめておきましょうか…
夏休みにも入ったのでじっくり勉強しながら考えようと思います。
では今日はここら辺で筆をおかせていただきます
ディジタル署名とディジタル証明書の違いって？
今回は情報セキュリティスペシャリストの試験勉強中にディジタル証明書の問題で「ん？」っとなったので書いてみました
ディジタル署名って何？
ディジタル署名っていうのはいわゆる現実世界で言う印鑑。送られてきたデータが本当にその人（サーバとか）から送られてきたと証明するための技術。
いわゆるデータの 正当性 （完全性とごっちゃになることがある）を保証するためのものなんですね。
またディジタル署名は署名を作成できる鍵（公開鍵暗号のうちの秘密鍵）は送信者のみが保持しています。これが漏えいすると色々なところで鍵が勝手につくられちゃって大変！
その他にも「このデータは私が送ったよ！」ということを証明するので後で「私そんなデータ送ってないよ！あなたの思い違いでしょ！」といったことにならないような 否認防止 の役割もあります。
仕組みに関してはハッシュ関数と公開鍵暗号方式を組み合わせて電子的な署名を作成してます。ここでは面倒なので省きます。 色々としっかり者のディジタル署名ですがこの署名自体が偽造されたものだったら？データを正しいと証明はできますがディジタル署名自体が自信の正当性を証明することはありません。なのでここで登場するのがディジタル証明書です。
ディジタル証明書とは？ 第三者機関である「認証局」によって発行される電子式の身分証明書です。SSLサーバー証明書などとも呼ばれます。
通信相手が送ってきた証明書を認証局の公開鍵で復号化することで通信相手の身元を確認することができます。
証明する内容としては認証局の情報、通信相手が発行した公開鍵、暗号化されたデジタル署名等があります。
ディジタル証明書はITU-T勧告の X.509 で定義されています。
しかし、悪意ある攻撃者は認証局になりすまして証明書を発行することがあります。それを防ぐために証明書の利用者情報を登録するRA（登録局）や 証明書の有効性を検証するVA(証明書有効性検証局)といったものがあります。
簡単にディジタル証明書の発行の手続きをまとめてみました。登場人物はwebサーバーとクライアントと認証局です。
- webサーバ「webサーバ側で公開鍵と秘密鍵を作成するよ！」
- webサーバ「公開鍵が正しいことを証明するための証明書が欲しい！じゃあ公開鍵とその他諸々の証明書送るから認証局にディジタル証明書発行してもらおう！」
- 認証局「ふむ。確かにwebサーバが発行したものだな（公開鍵と所有者情報を参照）。よし、秘密鍵で暗号化した署名付きでディジタル証明書にしてやるぞい」
- webサーバは証明書を受け取りインストールする
- クライアント「webサーバさん！接続要求です！」
- webサーバ「じゃあこれうちの証明書ね。保存しといてね」
- クライアント「証明書が届いたよ。じゃあこの認証局さんの公開鍵でデジタル署名部分をちょちょいと復号化して... よしハッシュ結果が同じだね！これは正しい署名だ！」
と多分大体こんな感じです。暗号化のところやCRLうんたらのところは複雑になるのですっ飛ばしました。
少し長くなってしまいましたが今回はここらへんで終わっておこうと思います。次は公開鍵暗号とかのまとめかな？
勉強中なので間違ったことを書いてあることが当然あると思うのでその際はご指摘お願いします
