さて、NetOpsの皆さん。自動化を進め、思う存分スクリプトを作成している今こそ、セキュリティについて改めて確認しておきましょう。ここで取り上げるのは、導入や管理を担当している可能性のあるファイアウォールやWAFなどのセキュリティサービスではありません。デジタルトランスフォーメーションへの取り組みを始めるにあたり、これから作成するスクリプトやコードについてです。
本日は、セキュリティのルールゼロについて改めてお伝えします。おさらいすると、次のとおりです。
セキュリティルール・ゼロ：ユーザー入力を決して信頼してはならない。
とてもシンプルなルールですよね？
そうあるべきですが、現実は違います。侵害に次ぐ侵害がビジネスの世界で発生していますが、その原因をたどると、セキュリティルールゼロへの違反に行き着きます。このルールへの違反は、開発者向けに提供されているサンプルコードに蔓延しています。開発者はこうしたコードを参考に、新しい言語やフレームワークを調査・学習しています。残念ながら、この問題はNetOpsという新たな注目分野にも広がりつつあります。
証拠Aをご覧ください：
公平を期すなら、少なくともこのスクリプトは、データが検証されていないことを警告してくれます。これは重要です。このスクリプトは、その入力に基づいてルーター設定に対するさまざまなリモート操作を実行するからです。
これについて気になるのは、このコードが、NetOps担当者にスクリプトを使って本番環境のネットワークデバイスを自動化する方法を手ほどきするためのものでありながら、データ検証には軽く触れるだけで、その具体的な方法について役立つ情報を何も提供していない点です。
PythonでIPアドレスを検証する際に役立つアドバイスについては、Stack Overflowのこちらのディスカッションをご覧ください。
でもLori、これはスクリプトで、CLIを使った作業ですよ。そんなにリスクがあるものなんですか？
悪い習慣は、なかなか断ち切れません。
セキュリティルールゼロを無視することには、2つの問題があります。
まず、CLIの時代は終わりに近づいています。APIが新たなCLIとなり、ほとんどの自動化フレームワークでは、ネットワーク関連のデバイスやサービスのプロビジョニングと管理にRESTful APIを採用しつつあります。そこには、アプリケーションスタックやパーサーが関わります。つまり、脆弱性が存在する可能性のあるAPIを介して構成を変更できるため、デバイスが悪用される可能性があるということです。
誇張ではないことの証拠として、広く議論されているApache Strutsの脆弱性に関する、このCiscoアドバイザリを挙げます。サニタイズされていない入力をStrutsフレームワークに渡すと、さまざまな問題が引き起こされるというのが共通認識です。
しかし、悪用される可能性だけではセキュリティルールゼロの適用を重視するに至らない場合に備えて、入力のサニタイズを怠ると、影響範囲が単一のデバイスをはるかに超える可能性があることを指摘しておきます。2017年初頭に発生したAmazon S3の障害について、判明していることを見てみましょう。
太平洋標準時の午前9時37分、権限を付与されたS3チームのメンバーが、確立された手順書に従い、S3の請求処理で使用されるサブシステムの1つから少数のサーバーを削除するためのコマンドを実行しました。しかし、コマンドへの入力の1つを誤ったため、意図していたよりも多くのサーバーが削除されました。
-- 北バージニア（US-EAST-1）リージョンにおけるAmazon S3サービス障害の概要
彼がスクリプトに入力した数値は、意図していたものよりはるかに大きいものでした。しかし、オペレーターが入力した内容を何でも無条件に受け入れるスクリプトは（セキュリティルールゼロを無視しているため）、いずれこのようなミスを引き起こすことになります。多少煩わしいとはいえ、スクリプトで簡単な確認を行っていれば、この問題が1週間以上にわたってTwitterで話題になる事態は防げたかもしれません。
ネットワークや本番環境では、セキュリティを認可の観点から捉えることがよくあります。Bobにはこの操作を実行する権限があるか。Aliceはこのスクリプトを実行できるか。認可は必要であり、今なお極めて重要です。
しかし、（社内の）デジタルトランスフォーメーションを加速し、より多くのフレームワークを採用するとともに、APIやスクリプトを活用してプロビジョニングと管理を徹底的に自動化する中で、開発の観点からもセキュリティを考慮することが不可欠です。
そして、そうしたルールの筆頭がセキュリティルール・ゼロです。「ユーザー入力を決して信頼してはならない。絶対に。」
入力は必ず検証してください。セキュリティをさらに強化できるだけでなく、適切に設計された自動化が思わぬ問題を引き起こすのを防ぐことにもつながります。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。