こんにちは！インフラや開発の現場に飛び込んだばかりの新人IT担当者の皆さん、そして「セキュリティって何だか難しそう……」と少し不安を感じている開発者の皆さん。日々の開発やサーバー管理、本当にお疲れ様です！
皆さんは今、Dockerなどの「コンテナ」を使ってアプリケーションを動かす機会がぐっと増えているのではないでしょうか。「環境構築が一発で終わって魔法みたいに便利だな〜」と感じているその裏側で、実は今、サイバー攻撃者たちがこっそり狙っている「とっても怖い落とし穴」があるんです。
今回は、最近のサイバー攻撃のトレンドである「コンテナイメージのレジストリ汚染とサプライチェーン攻撃」について、身近な防犯の仕組みに例えながら、一緒に優しく紐解いていきたいと思います。難しい専門用語が出てきても、一歩ずつ分かりやすく解説していくので、どうぞリラックスして読んでくださいね！
—
1. コンテナの「ベースイメージ」ってなぁに？（身近な例え話）
皆さんは、何かお部屋のDIYや家具の組み立てをするとき、一から木を切ってペンキを塗ったりしませんよね？ 普通は、ホームセンターで売っている「すでに途中まで組み立てられたカラーボックス」や「便利な既製品のパーツ」をベースにして、自分の好きな棚を作ったりするはずです。
コンテナの世界でもこれと全く同じことをしています。
ゼロからOSの機能をすべて自分で作るわけにはいかないので、世の中の親切な誰かが作ってくれた「OSの土台（UbuntuやAlpine Linuxなど）」や「プログラミング言語の実行環境（Node.jsやPythonなど）」をダウンロードしてきて、その上に自分たちのアプリを載せます。
この「一番最初にとってくる土台のパーツ」のことを、コンテナの世界ではベースイメージと呼びます。そして、このベースイメージをみんなで共有して保管しておく倉庫のことを「コンテナレジストリ（Docker Hubなど）」と呼ぶんです。
—
2. 攻撃者はどこを狙う？ サプライチェーン攻撃のメカニズム
ここで、ちょっと恐ろしい泥棒の話をさせてください。
あなたが家を建てるとき、柱や壁の材料をあちこちの工場からトラックで運んできますよね。泥棒たちは、「完成したあなたの家（頑丈な玄関の鍵がかかっている）」を直接こじ開けるよりも、「その家を建てるための木材をこっそり作っている、少しセキュリティが甘い下請けの工場（サプライチェーン）」に忍び込んで、柱の中にこっそりボルトを仕掛けたり、腐った木材を混ぜたりする方が簡単だと知っています。
コンテナのサプライチェーン攻撃も、まさにこれと同じです。
攻撃者は、みんながよく使う人気のベースイメージ（例えば node:latest のようなタグ）をこっそり乗っ取るか、あるいは似たような名前の「ウリ二つの偽物イメージ（タイポスクワッティング）」をレジストリにアップロードします。
もし、開発者がその危険性に気づかず、汚染された（悪意あるコードが混入した）イメージを自分のプロジェクトの土台として使ってしまったらどうなるでしょうか？
アプリケーションが動いた瞬間に、サーバーの裏側で秘密裏にハッカーへ接続し、パスワードや機密データを盗み出すスパイプログラム（マルウェア）が勝手に動き始めてしまうのです。玄関の鍵（パスワード管理やファイアウォール）をいくら頑丈にしても、「家を建てるときの材料そのものに毒が盛られていた」としたら、防ぎようがありませんよね。
—
3. 「見た目が同じなら大丈夫」の罠と、タグの危険性
よくある現場のミスとして、イメージを指定するときに latest というタグをそのまま使ってしまうケースがあります。
# 【危険な例】最新版をそのまま使おうとして、latestタグを指定している状態
FROM python:latest
# アプリケーションのファイルをコピーする
COPY ./app /app
# これでは、今日ダウンロードするものと、来週ダウンロードするものが、
# まったく同じ安全なものかどうかが保証できません！latest という名前がついていると、「常に一番新しくて安全なものなんだろう」と思いがちですが、実はこれ、「スーパーの棚に置いてある、誰が中身をすり替えたか分からないジュース」をそのまま買うようなものです。攻撃者がその latest の中身を悪意あるものに書き換えてしまったら、明日ビルドしたときに、知らず知らずのうちに毒入りのイメージを取り込んでしまいます。
—
4. 救世主「Cosign」による署名検証で、本物を見極める！
「じゃあ、レジストリにあるイメージが本当に安全なものか、どうやって見分ければいいの？」という疑問がわきますよね。
ここで登場するのが、今回のテーマのもう一つの主役「Cosign（コサイン）」です。
Cosignは、いわば「本物のお墨付き（デジタル署名）スタンプ」のようなものです。
身近な例え：実印と印鑑証明書
重要な書類にハンコを押すとき、私たちは「実印」を押し、本当に本人のものか証明するために「印鑑証明書」を添えますよね。
コンテナの世界でも同じように、信頼できる開発元（例えば会社のセキュリティチームなど）が、イメージに対して「私たちが作った本物ですよ」というデジタル署名（電子的な実印）をペタッと押しておきます。
サーバー側（デプロイ時）は、そのイメージを使う直前に「このスタンプ、本当に本物のもので間違いなくだれも改ざんしていないかな？」と署名検証を行います。もし、途中で悪意ある攻撃者がイメージを書き換えていたら、スタンプのインク（デジタル署名）の形が崩れてしまうため、「おや？これ偽物だぞ！」と一発で弾き出すことができるんです。
—
5. 実践！ Cosignを使ったイメージ署名と検証の流れ
それでは、実際に現場でどのようにこの安全対策を行うのか、具体的な手順を見ていきましょう。
一歩ずつ、丁寧に解説しますね！
ステップ1：鍵のペア（秘密鍵と公開鍵）を作る
まずは、デジタルスタンプを作るための「秘密鍵（自分だけが持つハンコ）」と、それを検証するための「公開鍵（みんなに見せる確認用データ）」を作ります。
# Cosignを使って鍵のペアを生成するコマンド
# 実行するとパスワードを求められるので、安全なものを設定してください。
cosign generate-key-pair
# 実行後、以下の2つのファイルが生成されます：
# - cosign.key （秘密鍵：絶対に外部に漏らしてはいけないもの！）
# - cosign.pub （公開鍵：サーバー側に配置して検証に使うもの）ステップ2：コンテナイメージに署名（スタンプを押す）をする
開発したイメージをレジストリ（ここでは例として Docker Hub や GitHub Packages）にプッシュしたあと、そのイメージに対して秘密鍵で署名をします。
# 自分のコンテナイメージに対して、秘密鍵でデジタル署名を付与する
cosign sign --key cosign.key ghcr.io/your-username/your-app:v1.0.0
# ※これで、レジストリ上のイメージに「安全なお墨付き」がくっつきました！ステップ3：本番環境やKubernetesで「検証」を行う
本番サーバーにコンテナをデプロイする際、あるいはCI/CDパイプライン（自動ビルドの仕組み）の中で、そのイメージが本当に改ざんされていないかチェックします。
# 公開鍵を使って、イメージの署名が正しいか（改ざんされていないか）を検証する
cosign verify \
--key cosign.pub \
ghcr.io/your-username/your-app:v1.0.0
# 【解説】
# もしイメージが途中で書き換えられていたり、署名がなければ、
# このコマンドはエラーを返して処理をストップ（デプロイを阻止）します！
# 逆に、問題なければ検証成功のメッセージが表示されます。このように、「ただダウンロードするだけでなく、使う前に必ずスタンプ（署名）を確認する」というひと手間を挟むだけで、サプライチェーン攻撃の大半を綺麗にブロックすることができるんです。
—
おわりに：安全なサプライチェーンの第一歩を踏み出そう！
いかがでしたでしょうか？
コンテナのレジストリ汚染やサプライチェーン攻撃というと、なんだかすごく難しくて自分には手に負えないように感じるかもしれません。でも、「家の鍵をかける」「届いた荷物の差出人を確認する」という私たちの日常生活の防犯意識と同じように、仕組みを少しずつ紐解いていけば、しっかりと対策を立てることができます。
今日から実践できるポイントをまとめておきますね！
1. latest タグを安易に使わず、バージョン（ハッシュ値や特定のタグ）をしっかり固定する！
2. 信頼できるベースイメージを選び、定期的にスキャンする！
3. Cosignなどのツールを使って、イメージの署名と検証をパイプラインに組み込んでみる！
セキュリティの向上は、一気にすべてを完璧にやろうとすると息切れしてしまいます。「まずは身近なベースイメージの管理から見直してみようかな」「今度Cosignを検証環境で試してみよう！」そんな小さな一歩の積み重ねが、あなたと組織のシステムを守る最高最強の盾になります。
一歩ずつ、着実にセキュアな開発ライフを楽しんでいきましょう！それではまた次回の記事でお会いしましょう〜！
コメント