ゼロトラストをより細かく分解する

(Last Updated On: 2017/10/03)

セキュリティを維持する為にはゼロトラスト、何も信頼しない所から始めて信頼できることを検証する、作業が必要です。ゼロトラストは信頼できるモノと信頼できないモノに分ける作業ですが、より細かく考える必要があります。

信頼できるモノ、信頼できないモノ

信頼できるモノと信頼できないモノ、と単純に分類できれば良いのですが現実にはそうなりません。「モノ」の粒度が大きいと単純に「モノ」全体を信頼することができないからです。

セキュリティ設計を行う場合

  • 物理的
  • ネットワーク的
  • ソフトウェア
  • システム

の各レベルで信頼境界を引き、可能な限り信頼できるように設計します。しかし、普通は信頼境界の中の「モノ」全体を完全には信頼できません。

例えば、”ソフトウェア全体を信頼できるモノ”1とする場合でも必ずリスクが残ります。

  • ライブラリを安全に利用するには条件がある(無条件に信頼できない。例:バッファオーバーフロー)
  • ライブラリが更新/追加された場合に脆弱性が追加される。最悪の場合、悪意があるコードが含まれたモノに更新される
  • ソフトウェアのコードが更新された場合に脆弱性が追加される

ネットーワークの場合なら

  • 信頼できないデバイスを追加/接続される
  • 信頼できない接続経路を追加される
  • 信頼できるデバイスのみで構成したつもりでも、デバイスに脆弱性がある
  • そもそも解った上で脆弱なデバイスやプロトコルを使用している
  • デバイスのファームウェア更新などで脆弱性が追加される

といったリスクが残ります。

 

ゼロトラストとセキュリティ設計

セキュリティ設計を行う場合、全ての「モノ」を信頼できない「モノ」としゼロトラストで1つ1つの「モノ」を”信頼可能な状態”になるよう管理できるようにします。しかし、”信頼可能な状態”とは”無条件で信頼可能な状態”にすることではありません。”無条件に信頼可能な状態”とは”完璧なセキュリティが維持されている状態”と言えます。セキュリティに完璧はありません。

”信頼可能であるとしたモノは無条件で信頼できる”、つまり”信頼できるモノにはリスクが無い”と誤った仮定をしてしまう間違いはよくあります。風力発電システムが簡単に攻撃できてしまう状態になった原因は「簡易な鍵のみで、物理的なセキュリティが維持でき信頼できる」と誤った仮定をしてしまった事にあります。

ゼロトラストで安全、検証済みである、信頼できる、としたモノにも必ずと言って良いほど残存リスクがあります。つまり検証済み/信頼できるモノであっても、前提条件付きで信頼できるモノに過ぎません。

前提条件付きの信頼である、という点がポイントです。前提条件が維持されない場合、安全性は維持できません。風力発電システムの場合、「鍵によって物理的セキュリティは維持される」とする前提条件が簡単に突破されるため、それに頼ったセキュリティはあまり役立たないものになっていました。

個々のリスク廃除/削減策を強固な対策にすることも重要です。しかし、同時に全てのリスク廃除/削減策は突破されるリスクがあることを前提にセキュリティを考える必要があります。ITシステムの最外周信頼境界(最も外側の信頼境界)で出来る限りのリスク廃除/削減策を行うべきですが、それだけに頼ると要求される安全性を維持できません。そこで、セキュリティ設計には必ず多層防御が必要になります。

セキュリティ対策に幾らでもリソース(人、モノ、お金)を使えるのであれば良いのですが、普通は最小限のコストで必要なレベルの安全性を維持することが求められます。どこに、どれだけのリソースをつぎ込んで

  • 物理的
  • ネットワーク的
  • ソフトウェア

のセキュリティを維持するのか?これがセキュリティ設計を行う設計者の腕の見せ所になります。

 

セキュリティ設計と管理(マネジメント)

どんなに注意深くゼロトラストで全てのモノを検証し安全性を確保したとしても、システムがアップグレードや交換などにより変化したり、利用しているモノに新たな脆弱性が見つかったり、危殆化により安全でなくなったりします。そもそもリソースの関係で、最初から考えうる万全な対策になっていない場合がほとんどです。

万全ではない(できない)ので、利用可能なリソースに応じた設計とマネジメントが重要になります。脆弱性を場当たり的、総当たり的に対応していたのでは、不要な対策にリソースを割いたり、必要な対策にリソースを割当ない、といった問題が発生します。

 

ゼロトラストとデータ

ITシステム、特にソフトウェア、で問題になるとなるのはデータです。信頼境界内にも”信頼できないデータ”は多く存在します。ネットワークの脆弱性を利用して”信頼できないデータ”を送信できるようになっているシステムも多数あります。(例:HSTSは多くのHTTPSサイトで利用されていない)

信頼できるデータであっても、出力用には安全でない場合も少くありません。現在のシステムではほとんどのデータがテキストでやり取りされます。e.g. HTTP/HTML/XML/JSON/etc 検証済みの入力であっても、出力先のコンテクストに応じたセキュリティ処理(検証/エスケープなど)が欠かせません。

「全てのデータを信頼できる」はかなり危険な考え方です。大多数のセキュリティ問題は「全てのデータを信頼できる」という脆弱な前提条件の元で発生しています。データを信頼できるかどうか?は多層防御で何重にもチェック/対応する必要があります。

 

まとめ

セキュリティ対策はゼロトラスト(全て信頼しない)から始めて、ホワイトリスト型で信頼可能なモノを増やしていきます。しかし、”完璧に信頼可能なモノ”はほとんどありません。常に何らかのリスクが残存したり、増加したりします。

セキュリティ対策というとリスク廃除/削減にばかり目が行きがちですが、残存/増加したリスクに対応/管理する、視点が欠かせません。ゼロトラストからセキュリティを構築したから大丈夫!ではなく、更に細かく細分化したリスク管理が必要です。

  • ゼロトラストで、信頼できるモノ、信頼できないモノ、を区別する
  • 信頼できるモノ、としたモノにもリスクが残存する
  • 残存リスクがある為、信頼できるモノ、には信頼できる状態の前提条件がある
  • 残存リスクは定期的にレビューし、必要であれば廃除/軽減策を講じる

現在のセキュリティは工学的に構築されているのではなく、職人的に(経験則で)構築されているように感じています。これが原因で、風力発電機のどれかに侵入できるとシステム全体を容易に破壊できる、といった問題があらゆる所で再現されているのではないでしょうか?

参考:

 

 


  1. ソフトウェアの信頼境界は基本的に同一プロセス/スレッドを超えることはできません。 

Comments

comments