NetOps 様: セキュリティルールゼロはあなたにも適用されます

はい、NetOps です。 自動化を進め、スクリプトを一生懸命作成しているときに、セキュリティについて少し思い出してみましょう。 ここで言っているのは、ファイアウォールや WAF、あるいは導入と管理を担当するその他のセキュリティ サービスについてではありません。 私が話しているのは、デジタル変革の旅に乗り出す際に行うスクリプトとコードについてです。

今日は、セキュリティ ルール ゼロについてお知らせしたいと思います。 思い出をリフレッシュするには:

セキュリティルールゼロ: ユーザー入力を信頼してはならない。 これまで。 

とても簡単なルールですよね？

そうあるべきですが、そうではありません。 違反 そしてその後 違反 ビジネスの世界におけるセキュリティ侵害は、セキュリティルールゼロの違反に起因しています。 開発者が新しい言語やフレームワークを研究し、学習する際に目にするサンプル コードには、このルールの違反が蔓延しており、残念なことに、NetOps という刺激的な新しい領域にも浸透しつつあります。

証拠書類Aを提示させてください。

さて、公平に言えば、少なくともこのスクリプトには、データが検証されていないことを警告する良識があります。 これは良いことです。なぜなら、このスクリプトは入力に基づいて、ルーターの構成のあらゆる種類のリモート操作を実行するからです。

これに関して私が不満に思っているのは、このコードは、スクリプトを作成して実稼働ネットワーク デバイスを自動化する方法を NetOps に指示する目的で設計されており、その方法に関する役立つ情報は一切提供されず、単にデータ検証にうなずくだけであるということです。

Python で IP アドレスを検証するための良いアドバイスについては、この Stack Overflow のディスカッションを参照してください。

でもロリ、これはスクリプトで、CLI を使ってやっているのに、それがどれだけ危険なのか、私にはわかりません。

悪い習慣はなかなかやめられません。

セキュリティ ルール ゼロを無視すると、2 つの問題が発生します。

まず、CLI の時代は終わりに近づいています、友人よ。 API は新しい CLI であり、ほとんどの自動化フレームワークは、ネットワーク デバイスとサービスのプロビジョニングと管理に RESTful API の使用を採用しています。 つまり、アプリ スタックとパーサーのことです。 これは、脆弱性を含む可能性のある API を介して構成が変更される可能性があるため、潜在的に悪用される可能性があるデバイスを意味します。

広く議論されている Apache Struts の脆弱性に関するこのCisco の勧告は、私が誇張していない証拠として提示します。 コンセンサスは、サニタイズされていない入力を Struts フレームワークに渡すことで、あらゆる種類の悪影響を引き起こします。  

しかし、悪用される可能性を心配してセキュリティ ルール ゼロの適用を心配するほどではないとしても、入力をサニタイズしないと、単一のデバイスの場合よりも影響範囲がはるかに大きくなる可能性があることを指摘しておきます。 2017 年初頭の Amazon S3 の停止についてわかっていることを考慮してください。  

午前 9 時 37 分 (太平洋標準時)、確立されたプレイブックを使用する承認済みの S3 チーム メンバーが、S3 請求プロセスで使用される S3 サブシステムの 1 つから少数のサーバーを削除することを目的としたコマンドを実行しました。 残念ながら、コマンドへの入力の 1 つが誤って入力されたため、意図したよりも多くのサーバーのセットが削除されました。

-- 北バージニア (US-EAST-1) リージョンにおける Amazon S3 サービス障害の概要

彼がスクリプトに入力した数字は、彼が意図していたよりもはるかに大きかった。 しかし、オペレータが提供するものを盲目的に受け入れるスクリプト（セキュリティ ルール ゼロを無視）は、最終的にはこのような間違いにつながることになります。 スクリプトによる簡単な（確かに面倒ではあるが）検証を行っていれば、この問題が1週間以上もTwitterで話題になることは防げたかもしれない。

ネットワークや本番環境では、セキュリティを認証の観点から見ることがよくあります。 ボブにはこのアクションを実行する権限がありますか? アリスはこのスクリプトを実行できますか? そしてそれは必要であり、依然として重要です。

しかし、私たちが（社内の）デジタル変革の取り組みを加速させ、より多くのフレームワークを採用し、API とスクリプトを使用してプロビジョニングと管理を徹底的に自動化するにつれて、開発の観点からもセキュリティを考慮する必要が出てきます。

これらのルールの中で最初に挙げられるのは、セキュリティ ルール ゼロです。 ユーザー入力を信頼してはならない。 これまで。 

入力を常に検証します。 追加のセキュリティを提供するだけでなく、優れた自動化が悪くなるのを防ぐこともできます。