おれさまラボ

インターネット技術を中心に、実際に手を動かして理解を深めるブログ。

Zero Trust Networks (2/10)

Chapter 2 Managing Trust

忙しい人のための3行サマリ

  • さまざまな情報を組み合わせることで、信頼度が高くなる。
  • ゼロトラストモデルでは、ありとあらゆる攻撃を防御対象としていない。
  • デジタル証明書を用いて、デバイス、ユーザー、アプリケーションを常に検証し、信頼度を測ることが肝心

信頼を管理するということ

この章では、「信頼とは何なのか」を掘り下げています。

大抵の人が、家族のことは信頼していると思います。どうして、家族のことを信頼できるのでしょうか。

答えは、家族のことをよく知っているからです。

  • 容姿を知っている
  • どこに住んでいるのか知っている
  • どういう生涯を送ってきたのか知っている

これが、赤の他人だったらどうでしょうか。果たして信頼できるでしょうか。

答えはNOです。

  • 容姿は知っているかもしれない(会ったり、見かけたりしたことがあれば)
  • どこに住んでいるのか知らない
  • どういう生涯を送ってきたのか知らない

比べてみるとよくわかるように、信頼できるもの(ここでいう家族)は、さまざまな情報(状況、人、その他可能な限り得られる情報)から個人を完全に特定できているから信頼できるのだということがわかります。何かしらに「固有の信頼」を持つ場合は、その信頼がどこからきたのか見極め、慎重に管理することが重要となります。

しかしながら、システム管理者がいつでも正しい判断ができるとは限りません。その代わりに、信頼を委任することでこの問題を解決できます。大規模なシステム環境においては、人間の関与を最小限に留めながらも、安全に動作するシステムを構築することが重要です。

これを実現するには、システム管理者は、自分に代わってシステム(たとえばプロビジョニングシステム)がアクションを実行できるようにする必要があります。つまり、システム管理者はシステムに実行の責任を委任し、システムはその責務を果たすことで、信頼のおける存在になります。

これを、「信頼の連鎖」といい、信頼の最上位にいるシステム管理者を「トランスアンカー」と言います。

ゼロトラストモデルと脅威モデル

今日、世の中にはさまざまな脅威モデルが存在します。たとえば、STRIDE、DREAD、PASTA、Trike、VASTなどです。これらは、あるモデルでは攻撃者が標的とする資産に主眼を置いていたり、あるモデルではソフトウェアコンポーネントに主眼を置いていたり、あるモデルでは攻撃者の観点に主眼を置いていたりとさまざまな観点からセキュリティの問題に取り組んでいます。

どのモデルも一長一短であり、セキュリティ問題を解決するにあたっては、これらのアプローチをブレンドすることが理想的といえます。

RFC3552では、インターネット脅威モデルを定義しています。ここでは、「インターネット上のホストから流れてくるトラフィックは、たとえ相手のIPアドレスが意図するものだったとしても、悪意のある中間者によって偽装されたパケットかもしれない」ということを理解すべきとされています。

ゼロトラストモデルは、このRFC3552を拡張したモデルと言えます。

RFC3552では、一度ホストが侵害されてしまうとそれを保護することは難しいけれども、被害を抑えるための設計をすることは可能であると述べられています。

ゼロトラストモデルでも同様の考え方が適用されます。しかし、より強力な考えです。

ゼロトラストモデルでは、ホストが侵害されたことを検知する仕組みを強力に用意し、動的にポリシーを割り当てることで侵害の拡大を軽減することを目指します。

また、ゼロトラストモデルでは、すべての攻撃を防ぐことを端から目標に掲げていません。

  1. スクリプトキディ
  2. 企業スパイ
  3. 組織内部の潜在的な脅威
  4. 信頼の置けるシステム管理者
  5. 国家レベルの攻撃者

ゼロトラストモデルでは、1から3までを防御対象としており、それ以外の攻撃者から身を守ることは本質的に不可能であるとしています。そのため、防御対象外の脅威から身を守る手段として、従来のセキュリティのベストプラクティスは引き続き推奨されます。

強力な認証

先に述べた通り、さまざまな情報を組み合わせて判断することで、我々はだまされにくくなります。コンピューターにとっても同じことで、IPアドレスやパスワードの情報だけでは、相手を100%信頼することはできません。

一般に、コンピューターが通信相手を信頼するための仕組みとして、X.509という標準規格があります。これは、TLSなどでも利用される規格であり、信頼の連鎖に基づいてIDを検証することで信頼できる相手かどうかを判断する仕組みです。

証明書ベースの認証では、公開鍵と秘密鍵の2つの鍵が用いられます。公開鍵で暗号化したデータを秘密鍵で復号化できますし、逆も同じようにできます。この仕組みから、「正しくデータを複合できる」ということは「秘密鍵が存在する」ということを暗に示すことになります。秘密鍵をもつのは唯一無二の存在である想定のため、相手を特定できますし、中間者によって通信を傍受されていないことも証明できます。

ただし、万が一秘密鍵が悪意のある他者の手に渡ってしまった場合は、この限りではありません。対策として、攻撃者が複数の鍵を同時に入手することは難しいため、異なる場所に保管された複数の秘密鍵を使うことが理想的です。

しかしながら、これでもまだ不十分です。万が一、すべての鍵を攻撃者が手に入れてしまったらどうでしょう。これには、資格情報のローテーションが有効です。たとえ、鍵がすべて盗まれてしまったとしても、短時間で失効してしまえば、被害を最小化できる可能性があります。

この考え方は、ゼロトラストモデルの肝となる部分であり、なるべく早い段階でこれを考慮した設計をすることが望ましいとしています。なぜなら、資格情報のローテーションはなるべく短時間で行われることが望まれますが、頻度が多くなればなるほど、コストも高くなるためです。

信頼の証明

PKIは、信頼されていないネットワークで公開鍵を安全に配布・検証するための仕組みです。PKIの詳細な説明はここでは省きますが、ゼロトラストモデルを理解する上で、PKIの理解は非常に重要なファクターとなります。

ゼロトラストネットワークでは、PKIを利用してネットワーク全体でアイデンティティを証明します。デジタル証明書で認証される可能性のあるエンティティは以下の3つです。

  • バイス
  • ユーザー
  • アプリケーション

ゼロトラストにおいては、無数の証明書が発行されるため、自動化が不可欠となります。ただし、機密性の高い情報については、人の手を介した方が安全であるケースもあるので、この限りではありません。

PKIには、組織で管理するプライベートPKIと、第三者的な企業の運営するパブリックPKIがあります。ゼロトラストモデルでは、以下3つの観点からプライベートPKIを利用することを推奨しています。

  1. パブリックPKIを利用するとコストがかかる
  2. パブリックPKIを完全に信頼することが難しい
  3. 柔軟性とプログラマビリティが失われる

とくに、資格情報のローテーションを行う場合は、APIを提供しない組織が多く、自動化ができないことでコストが急騰しやすくなります。そのためパブリックPKIを利用することは推奨されません。

特権の最小化

最小特権の原則とは、必要なときに必要となる最小の特権だけを与えることを言います。アプリケーションに対してであれば、サービスアカウントやコンテナー、Jailのようなものを指します。人間に対してであればソースコードへのアクセスはエンジニアに限定するなどの行為を指します。ゼロトラスト化を進めるにあたっては、どのアクションにどの特権が必要か理解することが非常に重要となります。

しかしながら、特権の管理というのは非常に曖昧なものです。たとえば、システム管理者に与えられる特権は、時間の経過とともに拡大する傾向にあります。こういったところを、攻撃者は虎視眈々と狙っているのです。