ソフトウェアレイヤーとしてのエッジセキュリティを考える

CDN エッジで意味のあるロジックを載せられる時代になった一方で、運用上のセキュリティルールはまだ コンソールの寄せ集め のままの組織が多いように見えます。

自分がハマった失敗モード

インシデントのときは WAF の調整や CloudWatch、サーバー調査に時間を使いました。でもその手前に CloudFront がずっと立っていて、いつも通りトラフィックを流していた — IDS/IPS など別レイヤーの話とは別に、CDN をセキュリティの出発点として考えたことがなかった、と気づきました。

そこから cdn-security-framework の原型が生まれ、単一の JavaScript、YAML を読むコンパイラ、そして IaC に載せられる形へと育てています。

セキュリティをソフトウェアとして扱う

エッジのルールを コードに寄せる と、合成・レビュー・テスト・差分管理がアプリケーションと同じ習慣でできます。プロバイダの UI は強力ですが、意図のアーカイブとしては弱いです。

現実のプロバイダ

僕の手元では CloudFront と Cloudflare が中心です。抽象化レイヤーは、実際に触っている縁にふさわしいときだけ意味を持ちます。

トレードオフは残る

翻訳レイヤーは学習コストとメンテ代を払わせます。複数エッジ・複数チーム・複数環境で 単一のソース・オブ・トゥルース が欲しいときにペイします。単一アカウント・単一ベンダーならネイティブのままでよい場合もあります — 選ぶべきは「デフォルト」ではなく設計上の判断です。

「レイヤー」と言い続ける理由

エッジはもう可用性の表面積の一部だからです。設定の忘れ物ではなく ソフトウェアとして扱ったほうが、監査が考古学にならない。