コンテナ内で実行されている脆弱なものは依然として脆弱なもの
暗号化された悪意のあるコードは依然として悪意のあるコードである、と言っているのは私だけではありません。 暗号化によって、ネットワークを介した転送に対するセキュリティとアプリ インフラストラクチャが不明になる可能性を除いて、状況は何も変わりません。
コンテナ内で実行されるアプリやプラットフォームについても同様です。 アプリが脆弱であれば、OS 上で実行されていても、仮想マシン内で実行されていても、最近ではコンテナ内で実行されていても脆弱です。 アプリがデータセンターで脆弱であれば、クラウドでも脆弱です。 逆もまた同様です。
コンテナはアプリケーションを魔法のように保護するように設計されているわけではありません。 これらはネットワーク層で基本的なセキュリティを提供しますが、ネットワークはアプリケーションではありません。 アプリケーションには攻撃対象領域があり、コードとインターフェース (API) だけでなく、プロトコル (HTTP、TCP) と必要なアプリ スタックもこれに含まれます。 IP テーブルにエントリを追加したり、コンテナ化された環境への入口から来るものだけを受信要求に制限したりしても、これらは変更されません。
私がこのことを取り上げる理由は、 Sonatype の 2017 DevSecOps 調査のおかげです。 この調査では、2,200 人を超える回答者のうち 88% がコンテナ セキュリティの重要性に同意しましたが、コンテナ内の脆弱なアプリケーション/OS/構成を特定するためにセキュリティ製品を活用しているのは 53% のみでした。
この統計の最初の 2 つの要素、つまりアプリケーションと OS が私の目に飛び込んできました。なぜなら、これらは、場所や運用モデル (クラウド、コンテナー、仮想化など) に基づいて必ずしも変化するわけではない、完全に実現されたアプリ スタックの 2 つのコンポーネントだからです。 SQLi または XSS の脆弱性を持つアプリまたは API は、モデル間を移動しても自動的に保護されるわけではありません。 その脆弱性はコードにあります。 同じことは、間違いなくアプリ セキュリティ スタックの一部であるプラットフォームにも当てはまります。 Linux 上で実行されている Apache の HTTP ヘッダーの処理における脆弱性は、そのアプリが従来の OS ベースからコンテナ化されたモデルに移行された場合でも依然として存在します。
アプリがどこに、どのような形式で展開されているかに関係なく、アプリスタック全体の脆弱性を継続的に特定することが重要であり、必須です。
コンテナに移行する際には、従来のアプリですでに採用されているアプリ保護を維持することも同様に重要です。 Web アプリケーション ファイアウォールは、従来の環境にデプロイされたアプリだけでなく、クラウドにデプロイされたアプリにも、コンテナーにデプロイされたアプリにも同様に有益です。
調査で回答者が使用していることが判明したその他のセキュリティ ツール、たとえば静的スキャン ソリューションやリアルタイム スキャン ソリューション ( SAST、DAST、IAST、RASP ) も同様です。 Web アプリケーション ファイアウォール (WAF) の使用は他のツールの使用を上回っていますが、SAST と SCA (ソース コード分析) も一般的です。 SCA は、配信前に問題を根絶する静的な手段です。 古臭い話になりますが、 lintのようなツールは SCA ツールのカテゴリに分類されます。これらのツールは、コード (およびユーザー) のやり取りから生じる脆弱性をリアルタイムで検出することはできませんが、メモリ リーク、クラッシュ、または悪名高いバッファ オーバーフローを引き起こす、開発者が犯す一般的なミスのいくつかを見つけることができます。
あなたが何を考えているかは分かっています。 あなたはこう考えているでしょう。「ロリ、 Stack Overflow の 2017 年開発者調査結果を読んだところ、JavaScript が開発者の間で圧倒的に好まれる言語であることがわかった。 また、JavaScript は解釈されるので、バッファ オーバーフローやメモリ リークの問題は、C/C++ でコーディングしていた昔の悪い思い出にすぎません。」
ただし、JavaScript やその他の最新のインタープリタ型言語は、最終的には C/C++ などの回路基板に近い言語で実装されます。 そして、過去に示されているように、十分に賢い人であれば、その事実を利用してシステムを悪用することができます。
そして、たとえそれが懸念事項ではないとしても、使用されているライブラリや、サーバー側のセキュリティを侵害する誤用されたシステムコールに基づくコードには、他にも多くの脆弱性が存在します。 現在の調査によると、アプリの 80% はオープンソース コンポーネントで構成されています。 Sonatype の調査ではさらに、オープンソース コンポーネントに関連する検証済みまたは疑わしい侵害が 2014 年から 2017 年にかけて 50% 増加していることも指摘されています。 それらの多くは、制御が不十分であることと、それらの言語に精通した開発者がますます少なくなっていることの両方の理由で、より顕著な間違いを起こしやすい言語で書かれています。
重要なのは、どんなコードにも脆弱性が含まれる可能性があるということです。 コードは今日のビジネスの顔であるアプリの構成要素であるため、どこにどのように展開されているかに関係なく、コードをスキャンして保護することが重要です。
コンテナまたはクラウド。 伝統的または仮想的。 すべてのアプリケーションは脆弱性をスキャンし、プラットフォームおよびプロトコルの悪用から保護する必要があります。 期間。
アプリは開発中に徹底的にスキャンおよびテストされ、その後本番環境で再度テストされる必要があります。 分解の誤謬によれば、新しいコンポーネントを導入するとベースラインが変わるため、両方とも必要です。 新たな相互作用により、これまで発見されていなかった脆弱性が表面化する可能性があります。
アプリを保護するには、次の点を考慮してください。
- 開発ではコードとアプリの分析ツールを使用します。 可能であれば、それらを CI/CD パイプラインに組み込みます。
- 他のコンポーネント/アプリとのやり取りで問題が発生する場合は、本番環境で再度テストしてください。
- プロトコルとプラットフォームの脆弱性、および使用する可能性のあるサードパーティのライブラリで発見された脆弱性に注意してください。
- Web アプリケーション ファイアウォールをアーキテクチャに統合します。 ブロッキング モードで使用しない場合でも、プロトコル/プラットフォームのゼロデイまたはライブラリの脆弱性が発見された場合には非常に貴重なリソースとなります。
安全にお過ごしください!