SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2023 セッションレポート(AD)

オンプレミスの当たり前が通用しない! 設計時から気をつけたい、コンテナ環境のセキュリティ対策

【9-E-5】クラウドネイティブのセキュリティ所在や対応を考える ~コンテナ環境のマルウェア対策を例に~

  • X ポスト
  • このエントリーをはてなブックマークに追加

 クラウドネイティブといってもマイクロサービスやサービスメッシュなど幅広いが、今回は主にコンテナ環境を中心としてセキュリティ対策を考える。そもそもクラウド環境では責任共有モデルがあり、オンプレミス環境とは考え方が異なる。さらにコンテナになると従来のマルウェア対策ソフトウェアを導入できないケースもある。インフラ運用担当者だけではなく開発者にも有益なコンテナ環境におけるセキュリティ対策について、トレンドマイクロ フィールドセールスエンジニア 野村達広氏が解説する。

  • X ポスト
  • このエントリーをはてなブックマークに追加

クラウドネイティブにおけるセキュリティ対策のポイント

 コンテナを中心としたクラウドネイティブでは、セキュリティ対策が従来と異なる場合がある。もちろんクラウドネイティブであろうともサイバー脅威は実在するため、まずは管理対象の資産を洗い出しして、リスクの識別、分析、評価、対応、受容していくという基本的な流れは大きく変わらない。

 クラウドネイティブでは管理資産の範囲が変わる。クラウドでは責任共有モデルがあり、資産や責任はユーザーとクラウドベンダーで分け合う形となる。特にコンテナやサーバーレスアーキテクチャ、レジストリサービスを採用すると、ユーザーから見て管理対象外の資産が増えていく。

 そうなるとクラウドベンダーとユーザー企業、ユーザー企業内での責任分担をあらためて考える必要が出てくる。またシステムを構成するコンポーネントやサプライチェーンの観点で違いが生じてくる。

 なおクラウドネイティブにおけるリスクを把握するために参考となるのがNIST SP800-190に代表されるNIST(アメリカ国立標準技術研究所)が発行しているドキュメント、あるいはマイター社が攻撃者視点で手法をまとめたMITRE&ATTACKフレームワークがある。

フレームワーク
フレームワーク

 野村氏はクラウドネイティブにおけるセキュリティ対策のポイントとして「1つ目に多層防御の重要性。多岐にわたるコンポーネントやサプライチェーンで対策のレイヤを重ねて抜け漏れなく。2つ目にシフトレフトやセキュリティ バイ デザインで手戻りコストを最小に。3つ目はユーザー組織内のセキュリティナレッジ強化」と挙げる。

 それではコンテナ環境におけるマルウェア対策を考えてみよう。当初コンテナ環境では仮想通貨のマイニングツールが流行したこともあった。コンテナ環境では従来のセキュリティ対策ソフトウェアを導入できない場合もある。従来のものはサーバーまたはクライアントに導入するもので、コンテナを想定していないためだ。しかし対策はいろいろとある。詳しくは後述するが、コンテナ実行前と実行後(デプロイ環境)に分けて対策を施していくことができる。

 コンテナ環境におけるマルウェア混入のタイミングはデプロイ前、デプロイ時、デプロイ後と分けることができる。デプロイ前だと、公開ベースイメージやOSS、あるいは開発環境やビルド環境にマルウェアが混入し、ユーザーは気づかずにマルウェアごとパッケージングしてしまう。デプロイ時だと、コンテナ実行時のスクリプトにマルウェアをダウンロード、実行するという命令が含まれるケースが考えられる。デプロイ後だと、稼働中のコンテナにマルウェアが配置、実行されることになり、混入経路は多岐にわたる。脆弱性を突かれるケース、アプリのファイルアップロードで不正ファイルが混入するケース、環境に直接乗り込まれるケースも考えられる。

 対策としては、直接的にはマルウェアの検知と駆除があり、間接的にはマルウェアの配置や実行の検出や防止、目的達成の阻止などがある。ユーザーで作り込めるものもあれば、クラウドベンダーのサービス利用や設定で可能なものもあり、サードパーティー製品を採用することも可能だ。混入のタイミングや経路により、対策が分かれてくる。

 野村氏は「対策や混入タイミングがまちまちである一方、脅威が顕在化するのはデプロイ後の稼働環境です。そのため顕在化する前後で複数の対策を重ねれば、早期発見、被害の拡大防止につなげられます」と話す。

コンテナデプロイ前に実施する対策5つ

 では実際にどんな対策ができるだろうか。コンテナデプロイ前に実施するマルウェア対策の代表例を5つ紹介しよう。

コンテナイメージに対するスキャン

 コンテナセキュリティで代表的かつ欠かせないものとなる。コンテナイメージに脆弱性やマルウェアが潜んでいないかスキャンする。セキュリティベンダー製品の利用、またはレジストリサービスに組み込まれている機能を利用する。

 なおコンテナイメージにマルウェアが混入する時とは、先述した通り、公開されているイメージが発端になるケースが多い。こういう場合だと不特定多数を狙うばらまき型が考えられる。逆に特定の企業を標的にするなら外部から脆弱性をついた攻撃が起点となり、成功すれば徐々に攻撃が進行していく。

 あるいは何らかの形で開発環境やビルド環境が侵害されてマルウェアごとパッケージングしてしまうケースであれば、コンテナイメージのスキャンだけではなく、脆弱性をつぶしておくことも有効な対策となる。

 野村氏は「コンテナイメージのスキャンで大切なことは、マルウェアや脆弱性を検知した時の対応方針やフローを事前に決めておくことが必要です。常套手段としてはコンテナイメージを新しく更新し、修正パッチが適用されたイメージを利用します。しかしもし修正パッチが公開されていなければどうするか。代替製品に切り替える、または脆弱性のリスクを許容するなどの判断が必要となります」と説明する。

脆弱性を作り込まないようにする

 脆弱性はあらゆる攻撃の起点となりうるため、脆弱性が生じる余地をできるだけつぶしておくことも有効となる。ミドルウェア(Kubernetes)やコンテナ内アプリケーションや各種コンポーネントは最新バージョンにしておく。

 コンテナやオーケストレーターを操作するAPIが起点になる場合もあるので、APIやメンテナンス用のポートの公開範囲は必要最小限に絞っておく。ユーザーアカウントの権限やアプリ実行ユーザーの範囲も最小限に。またWebアプリは外部との接点となるため、アプリ自体のコーディングや設定をセキュアにしておくことも重要だ。

Read Onlyモードの活用

 コンテナのファイルシステムをRead Only(読み取り専用)で動作させる。これならマルウェアの配置やファイルの書き換えを制限できる。この対策だと、コンテナ稼働後にコンテナに混入してくるマルウェアにも有効な対策となるため、とても有効だ。

 ただしコンテナで稼働させるシステムが読み取り専用に耐えうるものでなくてはならない。リフト&シフトでは難しいが、システムの設計段階から読み取り専用での運用を想定しておく必要がある。またファイルを使うことのないファイルレスマルウェアには効果的ではないことも忘れてはならない。

開発・ビルド環境をセキュアにする

 繰り返しになるが、開発環境やビルド環境が侵害されてマルウェアが混入してしまうケースがある。そこで開発に使う端末やビルド環境サーバーにアクセスするサービスアカウントの管理と運用をセキュアにしておく必要がある。またコードのリポジトリやコンテナイメージのレジストリの認証情報も適切に運用することで、侵入や侵害を防ぐことにつながる。

適切なコンテナイメージタグ運用

 コンテナではタグをつけることが可能だが、これを狙う攻撃もあるので注意が必要だ。野村氏は「デフォルトで付与される“Latest”タグを安易に使うことは推奨されていません。最新版を取ってくるので便利ですが、別のコンテナイメージに付け替えられることもあります。悪意ある第三者にマルウェア入りのコンテナイメージに“Latest”タグがつけられ、誤って拾ってしまうケースも想定されます」とくぎを刺す。

 そのためタグに頼らないことや、タグの付け替えができないような仕組みにしておく、取得したいコンテナイメージを一意に特定する仕組みにするなどの対策が有効となる。野村氏は「正規のレジストリから正規のイメージを確実に取得、利用できるような仕組みをつくることが重要です」と強調する。

コンテナデプロイ後の対策4つ

 今度はコンテナデプロイ後の対策を簡単に見ていこう。

稼働中コンテナに対するスキャン

 コンテナのファイルシステムでマルウェアが実行されたら、リアルタイムで検知して駆除する。従来のサーバーOSに導入するタイプのマルウェア対策ソフトでは、コンテナに対応していないケースもあるので注意が必要だ。

稼働中コンテナの脆弱性対策

 脆弱性のなかにはイメージスキャンでは検出できなかったもの、検出したが許容したもの、新たに発見されるものもある。外部からの脆弱性をついた攻撃にそなえ、ネットワーク手前にWAFを設置する、ネットワーク上で攻撃パケットをとらえて対処するなどの対策が考えられる。

稼働中コンテナの不審な挙動を検出

 周辺ネットワークの探索、外部との不正な通信、ツールのダウンロード、ログの改ざんや消去などはマルウェア特有の不審な挙動と言える。こうした挙動を検出して、早期に封じ込めれば被害を最小限にできる。事前に正規の挙動をルールまたは学習でホワイトリスト化、あるいは不審な挙動をブラックリストで検出する。

 野村氏は「実際に不審な挙動が攻撃者の攻撃なのか、正規の挙動の範囲なのか、評価できるのはシステムを最も把握している開発者になりえます」と話す。

コンテナと外部、およびコンテナ間の通信制御

 マルウェアは感染後に何らかの形で不正な通信を行うため、正規の通信先以外の通信を制御しておけば被害を最小限に抑えることにつながる。通信の制御は、ネットワークの設定やサードパーティー製品で実装可能だ。ただし正規の通信やアクセスコントロールの作成はユーザー側で行う必要がある。

 野村氏は「クラウドネイティブやコンテナのセキュリティ対策を見ると、従来よりも開発者が関わるところが多くあるため、組織全体でセキュリティナレッジの強化が求められています」と強調する。

コンテナ環境のセキュリティ対策 Trend Micro Cloud One

 クラウド環境を保護するソリューションとして、トレンドマイクロでは複合的なアプローチをとれる「Trend Micro Cloud One」シリーズを提供している。コンテナ環境では、ネットワークの境界部分で「Network Security」、仮想マシンなどサーバー環境を保護する「Workload Security」、ストレージを保護する「File Storage Security」、デプロイ前のセキュリティチェックとデプロイ制御からランタイム保護まで、コンテナ環境のセキュリティを一気通貫で実現する「Container Security」がある。さらに全体の設定不備を可視化する「Conformity」もある。

コンテナ環境への対策
コンテナ環境への対策

 その他にも「Cloud Sentry」によるクラウド環境への定期スキャン、「Container Security」のランタイム脆弱性検索、「Open Source Security by Snyk」によるOSS脆弱性検索など、機能が拡充している。最新情報はCloud Oneのオンラインヘルプでチェックするといいだろう。

 野村氏は「Cloud OneシリーズはAWSやAzure Marketplaceでも提供しており、30日間の無料トライアルも提供しているので、ぜひ使用感を確認してみてください」と呼びかけ、最後に「クラウドネイティブは設計時からセキュリティを作り込むことが求められています。組織でナレッジの強化、抜け漏れがないように多層防御でカバーいただければと思います。対策製品としてぜひCloud Oneシリーズもご検討ください」と述べて講演を締めた。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

提供:トレンドマイクロ株式会社

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/17566 2023/04/26 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング