ゼロトラスト

ゼロトラストとは

ゼロトラスト (Zero Trust) は、ネットワークの内外を問わず全てのアクセスを検証し、暗黙の信頼を排除するセキュリティモデルである。「信頼するな、常に検証せよ」(Never trust, always verify) という標語で語られることが多い。

用語としては、Forrester 在籍時の John Kindervag が名付けたものとして定着している。前身にあたる考え方は 2004 年に Jericho Forum が広めた脱境界化 (de-perimeterization) で、ネットワーク上の位置に基づく暗黙の信頼と、広いセグメントを単一の静的な防御に頼ることの限界を指摘していた。設計原則としての定義は、米国 NIST が 2020 年 8 月に公開した SP 800-207「Zero Trust Architecture」が 7 つの基本原則として整理しており、以下の説明もこれに沿う。

従来のセキュリティ vs ゼロトラスト

両者の差は検査の厳しさの度合いではなく、認可の判断材料が「どのネットワークにいるか」なのか「誰が / どの端末から / どのリソースへ」なのかという違いである。

混同されやすいのは、ゼロトラストが境界防御の撤去を意味するという理解である。NIST SP 800-207 は、ゼロトラストの議論が広域の境界防御 (企業ファイアウォール) を取り除くことを強調しがちだと述べた上で、そうした定義の多くも結局はマイクロセグメンテーションのような小さな境界との関係で自身を説明していると指摘し、除外するものではなく備えるべき原則によって定義する立場を取っている。ファイアウォールや VPN が不要になるのではなく、単一の大きな境界に集約されていた防御が、リソースごとの小さな境界と認可の判断へ配分し直される。

ゼロトラストの原則

SP 800-207 の 7 原則を実装の観点で並べると次のようになる。「AWS での実装」は代表例で、どの原則も単一のサービスだけでは満たせない。

この 7 つは理想の到達点として示されたもので、NIST 自身も、ある戦略において全てを純粋な形で実装できるとは限らないと注記している。ゼロトラストは製品を導入して完了する状態ではなく、どの原則をどこまで満たせているかで語るものになる。

サーバーレスとゼロトラスト

サーバーレスでは、防御の重心がネットワーク境界から認可へ移る。IP アドレスの範囲で許可する制御は、呼び出し元の身元を確かめるトークン検証や IAM の署名付きリクエストへ移り、ネットワークセグメントで隔てていた範囲は、関数ごとの実行ロールと参照先リソース側のポリシーで隔てることになる。細かく区切るという点ではネットワークのマイクロセグメンテーションと同じ発想を認可の層で行っているだけで、境界そのものが消えるわけではない。VPC 内のリソースへ触る関数には、従来どおりサブネットとセキュリティグループの設計が要る。

Lambda が構造的に有利なのは、関数という細かい単位に実行ロールを割り当てられる点である。ただし既定で最小権限になるわけではない。ロールの内容は自分で設計するものであり、複数の関数で 1 つのロールを共有したり、動かすことを優先して広い権限を付けたままにすれば、1 つの関数を乗っ取られた時点で他の関数の権限まで渡すことになる。原則 3 が禁じているのは、まさにこの「1 か所の認可が別のリソースへ自動的に及ぶ」状態である。

ゼロトラストの導入ステップ

まず保護すべきデータとサービスを洗い出す (原則 1 の資産の特定)。次に認証を固め、人の操作には MFA、サービス間には mTLS や一時的な資格情報を使う。JWT のようなトークンは、受け取る側で署名 / 有効期限 / 発行者 / 想定した宛先まで検証しないと認証の強化にならない。続いて IAM ポリシーを見直して最小権限を適用し、CloudTrail で全アクセスを記録して GuardDuty で異常を検知する。最後に定期的なアクセスレビューで、使われていないまま残った権限を落とす。

つまずきやすいのは、全社の通信経路を一斉に作り替える計画から始めてしまうことである。原則は理想形であって一度に満たすものではないので、価値の高いリソースを 1 つ選び、そこへのアクセスだけを身元と端末の状態で判断する形に寄せ、記録が取れていることを確かめてから次へ広げる方が確実である。逆に、認可だけを強めて監視を後回しにすると、原則が破られたことに気づく手段が無いまま運用が続く。