コンテナの利用は拡大を続けています。サーバーレスやクラウドネイティブアプリの普及、モノリシックアプリケーションのモダナイズに対するニーズを背景に、コンテナはアプリのデプロイ先として急速に選ばれるようになっています。
Sysdigは先ごろ、2019年版コンテナ利用状況レポートを公開しました。このレポートは、同社のパブリッククラウドおよびオンプレミスサービスの顧客から収集したデータに基づいています。対象データには、200万を超えるコンテナが含まれています。
これらのコンテナの60%でNGINXが稼働しているという、私にとっては非常に喜ばしい調査結果に加え、Sysdigはセキュリティに関するかなり懸念すべき統計も明らかにしました。
次の数字に注目してください。コンテナの54%は稼働時間が5分未満でした。2018年には、その割合はわずか20%でした。
なぜこれが問題なのでしょうか。もちろん、セキュリティです。アクセスを保護し(当然、保護すべきです)、そのコンテナで稼働するアプリやAPIも保護するには、クラスターの現在の状態に合わせて、セキュリティサービスが常にポリシーを調整するようにしなければなりません。つまり、コンテナの起動時にポリシーを適用し、廃止時には削除する必要があります。これほど多くの変更が発生すれば、運用上のオーバーヘッドも大きくなります。比較的静的なアプリケーションでさえ、セキュリティを適切に確保するのは容易ではありません。変動の激しいアプリケーションで、これを迅速に行うのは非常に困難です。
それでも気にならないという方は、次の統計をご覧ください。コンテナイメージの60%はプライベートレジストリから取得されていますが(これは良いことです)、そのうち52%がイメージスキャンに合格していません。つまり、重大度が「高」以上の既知の脆弱性が存在していたということです。
もう、言葉もありません。
実際、多くのユーザーがコンテナをrootとして実行(ホストあたりの中央値:21)したり、特権モードで実行(ホストあたりの中央値:4)したりしています。また、権限がまったく制限されていないコンテナもあります(ホストあたりの中央値:28)。最も広く利用されているコンテナランタイムであるDockerは、デフォルトでは制限されたケイパビリティセットで起動するため、これは特に残念な状況です。つまり、誰かがデフォルトのセキュリティ設定を意図的に変更したことになります。制限なしで実行すると、権限昇格やコンテナからの脱出(システムへのアクセスが可能になること)につながる可能性があります。
ここで、コンテナセキュリティの基本をおさらいしましょう。
- 扉に鍵をかける。 認証は必須です。強力な認証情報を必須とし、頻繁にローテーションしてください。可能な限り2要素認証を使用してください。特に、オーケストレーションコンソールや重要インフラへの特権アクセスには不可欠です。
- 重要な情報を隠す。 シークレット(キーや認証情報など)をリポジトリや、容易にアクセスできる共有ソースで不用意に公開しないでください。
- リクエストを選別する。 すべてのリクエストが正当とは限らず、悪意のあるコードを含むものもあります。アプリかインフラストラクチャサービスかを問わず、コンテンツを検査し、悪意がないか評価してください。スキャンとSSL/TLS終端を統合して最適化することで、わずかなパフォーマンス低下を相殺できます。
- 脆弱性を修正する。 イメージ、サービス、ワークロード、その他のコンポーネントに脆弱性があることが判明している場合は、パッチを適用してください。特に外部から調達したコンポーネントの脆弱性は、攻撃者に狙われやすいため、対応が重要です。Apache Strutsのように広く導入されているアプリケーションやインフラストラクチャに脆弱性が見つかると、攻撃者はわずかな労力で脆弱な対象を発見して悪用できるため、格好の攻撃機会となります。
アプリ、ひいてはビジネスのセキュリティを確保するには、適切なコンテナセキュリティのプラクティスを実際に実践することが極めて重要です。近日公開予定の2020年版「アプリケーションサービスの現状レポート」によると、企業のアプリポートフォリオに占めるクラウドネイティブ/マイクロサービスの割合は平均15%です。新規アプリケーションの開発案件が長期間にわたって滞留しているという調査結果があるにもかかわらず、この割合に達しています。つまり、コンテナ化されたアプリは今後も増え続けます。わずかな割合のアプリさえ保護できないのであれば、対象を大幅に拡大して保護できると期待できるでしょうか。
安全なコンテナ化を実践しましょう。
コンテナセキュリティの基礎を復習したい方は、F5の同僚であるJordan Zeborの専門知識に基づくこちらのシリーズをご覧ください。
著者について

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ブログをご覧ください。