🟢 はじめに

本記事ではゼロトラストの基本、AWSにおけるゼロトラスト思想を中心に記載します。

よく耳にする用語ではあるものの、一人歩きしがちな用語でもあります。

具体的な定義とは？
どのようにシステムに適用するの？
AWSではどのように捉えているか？

などの疑問がある方の助けとなれば幸いです。

🙅‍♂️ゼロトラストとは？

まず初めにゼロトラストの一般的な意味について確認します。

ひとことで言うと

簡潔にまとめると
"何も信頼しない"を前提として安全性を検証・脅威を回避するセキュリティの考え方
と説明できます。

もう少し詳しく

ゼロトラストの考えが生まれた背景も踏まえて、もう少し詳しく説明します。

従来は、"信頼できる内側" と "信頼できない外側" にネットワークを分けて、主にその境界でセキュリティ対策を講じると言う考え方が主流でした。
内側の例としては社内LANやVPNで接続されたデータセンター、外側の例としてはインターネット等が挙げられます。

しかし、昨今はクラウドやリモートワークの普及により保護対象が様々な場所に点在するようになりました。
信頼できるか、保護対象の場所などが"内側/外側"で分けることができなくなりました。

従来の考え方では十分な対策を講じることができなくなったため、内側/外側に関係なく全ての領域を"信頼できない"として監視や対策を行うことで安全なシステム運用を実現しようというものがゼロトラストの考え方です。

『NIST SP800-207』では以下のゼロトラストの7原則が示されています。

1 すべてのデータソースとコンピューティングサービスをリソースとみなす
2 ネットワークの場所に関係なく、すべての通信を保護する
3 企業リソースへのアクセスをセッション単位で付与する
4 リソースへのアクセスは、クライアントアイデンティティ、アプリケーショ
ン/サービス、リクエストする資産の状態、その他の⾏動属性や環境属性を含
めた動的ポリシーにより決定する
5 すべての資産の整合性とセキュリティ動作を監視し、測定する
6 すべてのリソースの認証と認可を⾏い、アクセスが許可される前に厳格に実
施する
7 資産、ネットワークのインフラストラクチャ、通信の現状について可能な限
り多くの情報を収集し、セキュリティ体制の改善に利⽤する

※7原則については以下で簡潔にわかりやすく説明されているため興味のある方は一読ください。

🟠AWSではどのように捉えているか？

次にAWSではAWSをどのように捉えているか確認します。

主にAmazon Web Services ブログの『ゼロトラストアーキテクチャ: AWS の視点』、『AWS上でどのようにゼロトラストアーキテクチャを考えていくか』の内容から抜粋して説明します。

基本思想

基本となる定義は主に以下のよう説明されています。

従来は"信頼"をネットワーク内のアクターのいる場所によって確立されていた。
ゼロトラストの考え方では、従来のネットワーク制御やネットワーク境界のみに依存しない。
どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼せず、あらゆるソースからの入力を潜在的に悪意のあるものとみなす
従来のネットワークを中心とした信頼モデルは、アイデンティティを中心としたコントロールによって拡張または置き換えられる。

また、ゼロトラストに基づいて求められる設計の代表例として以下のような記載もあります。

個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計
意図しないアクセスのリスクを低減するために、リアルタイムですべてのアクションとリソースを評価

３つの指針

AWSにおけるゼロトラストの指針も紹介します。

①ネットワークとアイデンティティの組み合わせ

従来のネットワーク中心のセキュリティ対策では不十分となったため、
アイデンティティによるセキュリティ対策も重要である。

ネットワークorアイデンティティの二者択一ではなく、
互いに共存、さらには互いに認識して強化する必要がある。

②特定問題へのフォーカス

"ゼロトラスト"という単語は様々な文脈で異なる意味を持つ可能性があり、
何を組織のために達成しようとしているかは、ユースケースにより大きく異なる。

一律な定義にこだわらず、特定の問題に焦点を当てて新しい視点と新しいツールで問題に取り組むことが需要である。

③保護対象に合わせたセキュリティレベルの決定

ゼロトラストの原則は、適切に適用すればセキュリティ基準を大幅に高めることができる。
一方、原則通り厳格に適用されてしまうと、過度に負担をかけてしまいイノベーションを失速させる。

保護対象に応じたセキュリティレベルで適用するべきである。

(参考)STRIDE

ゼロトラストをよりよく理解するために脅威モデリングのSTRIDEが紹介されています。
脅威モデリングとは、すべての潜在的な攻撃の可能性を評価してリスクを定義し、管理策を決定するための試みです。
脅威モデルの一つであるSTRIDEでは、以下のようなカテゴリの脅威を特定しています。
こちらの視点も取り入れてアーキテクチャを検討することを推奨しています。

ユーザーIDのなりすまし（Spoofing）
データの改ざん（Tempering）
ソースの否認（Repudiation）
情報漏洩（Information Disclosure）
サービスの拒否（Denial of Service）
特権の昇格（Elevation of Privilege）

🔸AWSにおけるゼロトラスト実装例

ゼロトラスト原則に対応したAWSでの実装例をいくつか紹介します。

例１：最小特権アクセス

各リソースの役割と責任を明白にしたうえで、きめ細かなアクセス制御を実施することで、リソースの独立性とセキュリティを向上する。

[実装例]
・IAMポリシーやIAMロールによる詳細な権限設定
　⇒必要な人が必要なリソースにのみアクセスできるように[最小権限の原則]

例２：マイクロセグメンテーション

社内外問わず不要な経路は全て排除する必要がある。
ネットワークを細分化して、複数種類のシステムやデータが混在することを避ける。

[実装例]
・VPCやサブネットによるネットワーク分離
・セキュリティグループやACLによるアクセス制御
・AWS PrivateLinkにより必要な通信のみをプライベートに実現

例３：監視と追跡

信用しないものは監視する必要がある。
攻撃はもちろん、ネットワークトラフィックやユーザ操作などを監視、追跡、可視化することが重要である。

[実装例]
・Cloud WatchLogsによりアプリケーションやサービスのログデータを収集
・Cloud TrailによりAPIコールやユーザー操作を記録
・AWS Security HubによりAWS全体のセキュリティイベントを統合・継続化

例４：自動化

インシデントに対しては迅速かつ正確な対応が求められる。
そのため、インシデント予防やインシデント対応はできるだけ自動化した対応を実現することが重要である。

[実装例]
・AWS Configによるリソース設定の監視&自動修復
・SSMによるサーバ操作自動化
・各種リソース+（EventBridge+）Lambdaによる自動対応
　（例：GuardDuty、WAFなど）

💎まとめ

ゼロトラストは、従来の境界型セキュリティから解放し、「何も信頼しない」を前提としたセキュリティアプローチ
証拠ベースの認証とネットワーク制御の組み合わせ、最小特権アクセス、監視、そして自動化による対応が求められる
システム全体の維持コスト、複雑さ、運用オーバーヘッドが増加していることも考慮すべきであり、Well-Architectedフレームワークの5つの柱すべてを評価して、各ニーズ間のバランスを意識するべき

🟢おわりに

様々場面で耳にするゼロトラストをAWSの概念も通して理解が深めることができたなら幸いです。
是非、自分の関わっているシステムのセキュリティについて、俯瞰的な視点で再検討することをお勧めします。

本記事がどなたかのお役に立てれば幸いです。ご覧いただきありがとうございました。

📚参考文献