ほとんどのゼロトラストアーキテクチャがトラフィック層で失敗する理由

ゼロトラストは、エンタープライズ環境で最も広く採用されているセキュリティモデルの1つになりました。組織は、IDシステム、アクセスポリシー、最新のセキュリティツールに大きく投資しています。紙の上では、これらの環境は十分に保護されているように見えます。

しかし、インシデント中には、異なる現実がしばしば浮き彫りになります。

私はIDとポリシーの観点からゼロトラスト計画が完全に実装されている組織と協力してきました。アクセス制御が定義されました。認証フローは堅牢でした。コンプライアンス要件は満たされました。しかし、何か問題が発生すると、同じ質問が何度も出てくることがありました。

そもそも、どうしてトラフィックが通過したのか？

答えはしばしば不快です。戦略は妥当でしたが、トラフィック層での実行が一貫していませんでした。それがほとんどのゼロトラストアーキテクチャが失敗する場所です。

ゼロトラストが実践で崩壊する場所

ゼロトラストは単純な考え方の上に構築されています。信頼しない、常に検証する。実際には、ほとんどの実装は身元確認に大きく焦点を当てています。ユーザーが認証します。デバイスが検証されます。ポリシーがアクセスを決定します。

しばしば見落とされるのは、これらのコントロールが適用される前に、トラフィックがどのように環境に入り、移動するかです。

トラフィック層には、イングレスパス、ロードバランサー、APIゲートウェイ、TLS強化、リクエスト検証、およびサービス間通信が含まれます。これが信頼が確立されるか、仮定される場所です。

私が働いてきた複数の環境では、これらのギャップはツール不足が原因ではありませんでした。ネットワーク、セキュリティ、およびアプリケーションチーム間の所有権の一貫性がないことが原因でした。

最も一般的なパターンの1つは、強力なID強化と寛容なエントリーポイントの組み合わせです。組織は最新のIDプロバイダーと多要素認証をデプロイしていますが、エッジで古いTLSバージョンまたは弱い暗号化設定を許可しています。米国標準技術研究所のガイダンスはセキュアなプロトコルベースラインを推奨しています。

もう1つの繰り返される問題は、断片化されたイングレスです。アプリケーションはCDN、直接ロードバランサー、レガシーエンドポイント、または新しくデプロイされたAPIなど、異なるパスを通じて公開されています。各パスは若干異なります。

相互TLSも部分的にしか実装されていないことがよくあります。接続は内部で終了され、より弱い仮定で再確立されます。

東西トラフィックはもう1つのギャップをもたらします。内部に入ると、トラフィックはしばしば安全と見なされます。

最後に、可視性の問題があります。インシデント対応中、チームはリクエストがどのパスを取ったかを答えることができないことがよくあります。

これらの問題の多くはOWASPが説明するパターンと一致しています。

トラフィック層が実際の強化ポイントである理由

セキュリティプログラムはしばしばポリシーの定義に成功します。それらを一貫して強化するのに苦労しています。

トラフィック層は、強化が現実になる場所です。

リーダーシップの観点からは、これはツール問題ではありません。これはアーキテクチャの問題です。

クラウドセキュリティアライアンスの原則は、イングレスにコントロールを配置することを強調しています。

実際の環境で機能すること

成功する組織は、トラフィック層を主要な強化ポイントとして扱います。

彼らはイングレスパスを標準化し、厳格なTLSベースラインを強制し、レガシー例外を排除します。

彼らは相互TLSのための明確なルールを定義し、信頼が継続的に検証されることを保証します。

彼らはアプリケーションロジックの前にリクエストを正規化および検証します。

彼らはセキュリティチームがリクエストをエンドツーエンドでトレースできるように、一貫したテレメトリを実装しています。

最終的な考察

ゼロトラストはしばしば考え方の転換として説明されます。それは本当ですが、考え方だけではシステムはセキュアになりません。

セキュリティは強化についてです。そして強化はトラフィックがどのように処理されるかから始まります。

それがほとんどのゼロトラストアーキテクチャがトラフィック層で失敗する理由です。

この記事は、Foundry Expert Contributor Networkの一部として公開されています。
参加しませんか？