コンテナデプロイ前に実施する対策5つ
では実際にどんな対策ができるだろうか。コンテナデプロイ前に実施するマルウェア対策の代表例を5つ紹介しよう。
コンテナイメージに対するスキャン
コンテナセキュリティで代表的かつ欠かせないものとなる。コンテナイメージに脆弱性やマルウェアが潜んでいないかスキャンする。セキュリティベンダー製品の利用、またはレジストリサービスに組み込まれている機能を利用する。
なおコンテナイメージにマルウェアが混入する時とは、先述した通り、公開されているイメージが発端になるケースが多い。こういう場合だと不特定多数を狙うばらまき型が考えられる。逆に特定の企業を標的にするなら外部から脆弱性をついた攻撃が起点となり、成功すれば徐々に攻撃が進行していく。
あるいは何らかの形で開発環境やビルド環境が侵害されてマルウェアごとパッケージングしてしまうケースであれば、コンテナイメージのスキャンだけではなく、脆弱性をつぶしておくことも有効な対策となる。
野村氏は「コンテナイメージのスキャンで大切なことは、マルウェアや脆弱性を検知した時の対応方針やフローを事前に決めておくことが必要です。常套手段としてはコンテナイメージを新しく更新し、修正パッチが適用されたイメージを利用します。しかしもし修正パッチが公開されていなければどうするか。代替製品に切り替える、または脆弱性のリスクを許容するなどの判断が必要となります」と説明する。
脆弱性を作り込まないようにする
脆弱性はあらゆる攻撃の起点となりうるため、脆弱性が生じる余地をできるだけつぶしておくことも有効となる。ミドルウェア（Kubernetes）やコンテナ内アプリケーションや各種コンポーネントは最新バージョンにしておく。
コンテナやオーケストレーターを操作するAPIが起点になる場合もあるので、APIやメンテナンス用のポートの公開範囲は必要最小限に絞っておく。ユーザーアカウントの権限やアプリ実行ユーザーの範囲も最小限に。またWebアプリは外部との接点となるため、アプリ自体のコーディングや設定をセキュアにしておくことも重要だ。
Read Onlyモードの活用
コンテナのファイルシステムをRead Only（読み取り専用）で動作させる。これならマルウェアの配置やファイルの書き換えを制限できる。この対策だと、コンテナ稼働後にコンテナに混入してくるマルウェアにも有効な対策となるため、とても有効だ。
ただしコンテナで稼働させるシステムが読み取り専用に耐えうるものでなくてはならない。リフト＆シフトでは難しいが、システムの設計段階から読み取り専用での運用を想定しておく必要がある。またファイルを使うことのないファイルレスマルウェアには効果的ではないことも忘れてはならない。
開発・ビルド環境をセキュアにする
繰り返しになるが、開発環境やビルド環境が侵害されてマルウェアが混入してしまうケースがある。そこで開発に使う端末やビルド環境サーバーにアクセスするサービスアカウントの管理と運用をセキュアにしておく必要がある。またコードのリポジトリやコンテナイメージのレジストリの認証情報も適切に運用することで、侵入や侵害を防ぐことにつながる。
適切なコンテナイメージタグ運用
コンテナではタグをつけることが可能だが、これを狙う攻撃もあるので注意が必要だ。野村氏は「デフォルトで付与される“Latest”タグを安易に使うことは推奨されていません。最新版を取ってくるので便利ですが、別のコンテナイメージに付け替えられることもあります。悪意ある第三者にマルウェア入りのコンテナイメージに“Latest”タグがつけられ、誤って拾ってしまうケースも想定されます」とくぎを刺す。
そのためタグに頼らないことや、タグの付け替えができないような仕組みにしておく、取得したいコンテナイメージを一意に特定する仕組みにするなどの対策が有効となる。野村氏は「正規のレジストリから正規のイメージを確実に取得、利用できるような仕組みをつくることが重要です」と強調する。
