サイバー脅威
コンテナレジストリがプライベートネットワークへの侵入経路に利用されるリスク
コンテナイメージから流出した証明書や秘密鍵が企業システムへの侵入に悪用されるリスクとその攻撃シナリオについて、その要因や影響、対策に焦点を当てて詳しく解説します。
- コンテナレジストリの設定不備に伴うリスクとして、秘密鍵や証明書が攻撃者に盗み出され標的組織への侵入手段に悪用される攻撃シナリオを分析しました。
- 秘密鍵や証明書の流出は、攻撃者に対して正規ユーザへのなりすましや長期潜伏の手段を与えるため、重大な脅威となります。
- 秘密鍵や証明書がビルド済みのコンテナイメージに格納されがちな理由について、開発者側の視点をベースに解説します。
- 企業や組織がこうした攻撃を防ぐ上で有用な対策やセキュリティ推奨事項、警戒すべき誤認識について解説します。
- 「認証なしで公開されているコンテナレジストリが引き起こすサプライチェーン攻撃のリスク」（2024年1月16日日本語記事公開）
- 「公開状態のコンテナレジストリ：膨大な情報の山に潜むリスク」（2024年1月24日日本語記事公開）
これまでの分析に基づくと、下記のようなインシデントのシナリオも十分に発生しうると考えられます。
企業のラボで、突然警報が鳴り響きました。使用中のXDRソリューションからは、「認識されていないデバイスがネットワークに接続した」という報告が出ています。管理者がモニターに駆けつけてアクセスログを調べたところ、ある従業員の秘密鍵と証明書により、VPN経由で自社のプライベートネットワークにアクセスされていることが分かりました。当該従業員に連絡し、未承認デバイスによるネットワークへのアクセスについて問い正しました。
しかし、確認の結果、その従業員は会社のプライベートなコンテナレジストリにコンテナイメージをプッシュしただけであり、未知のデバイスなどは一切使用していないことが判明しました。
その後の継続したコンテナレジストリの設定不備に関する調査の中で、コンテナレジストリから機密情報を含むOpenVPNクライアント設定ファイルが32個発見されるなど、上記シナリオの可能性が明確に裏付けられる事実が見つかりました。コンテナレジストリの設定や管理が不十分であると、それに目をつけた攻撃者がサーバやネットワークに侵入して顧客情報流出やなりすまし行為、サプライチェーン感染などの活動を行い、企業の信頼に傷をつける可能性があります。
調査の中では、2,278個の一意な秘密鍵が発見され、そのうちの169個はSSH秘密鍵であることが判明しました。最も脆弱と見られる88個については、パスワード保護なども一切なく、セキュリティ上のリスクが高いと考えられます。こうした機密情報の扱いに関わる重大なミスは、強力なセキュリティ対策の重要性を示唆するものです。
これらの調査結果から想定するインシデントシナリオはこうです：
- 攻撃者は、はじめに企業や組織のプライベートなコンテナレジストリにアクセスします
- 次に、そこから全てのイメージをダウンロードし、VPN関連のサーバアドレスや接続キー、パスワード保護のかかっていない証明書などを抽出します
- 続いて、抽出した情報を利用し、標的組織の内部ネットワークにまで侵入します
調査対象のコンテナイメージの中には、パスワードなしのSSH鍵やIPアドレスを記載したスクリプトも含まれていました。これが攻撃者の手に渡れば、内部のインフラにまで深く侵入される可能性があります。
上記の攻撃シナリオに関して「よくあるシークレットの公開ミスと、一体何が違うのか」と思われるかも知れません。確かに、証明書や秘密鍵は、技術的にシークレットとして分類されます。しかし、それに伴うリスクは、他とは一線を画するものです。SSHの秘密鍵やOpenVPNの鍵データを外部からアクセス可能なコンテナイメージに置けば、攻撃者はそれを利用して別のシステムにまで手を伸ばし、サーバやユーザへのなりすましや、暗号化された通信に対する介入、より広範な環境での権限昇格に及ぶ可能性があります。
一般的なアクセストークンと異なり、流出した証明書や秘密鍵は、信頼済みのユーザや機関になりすます手段として働く点で、大きな脅威になります。これは、ただ認証情報が失われるということではなく、信頼を置いていたシステムやユーザのアイデンティティ自体が損なわれることを意味します。
本稿では、調査で実際に遭遇した事例をベースとする攻撃シナリオや、企業や組織に及ぼす影響、それに対して防衛体制を強める必要性について解説します。
前回の調査結果：コンテナレジストリの公開に関する問題点
前回の調査では、197件の一意なイメージレジストリから20,503個に及ぶイメージが発見され、そのデータ容量は9.36TBに達していました。
コンテナレジストリは、コンテナイメージを保管する倉庫に相当し、個々のコンテナイメージは、コードや設定情報、依存関係にあたるファイルの格納庫に相当します。コンテナレジストリを不用意に外部公開して放置すれば、そこに攻撃者が侵入し、イメージの内部を探られる可能性があります。
コンテナレジストリの公開に絡む主な問題点を、下記に示します。
問題点1：レジストリの公開、またはレジストリ認証情報の流出
レジストリを外部公開すると、攻撃者によってその中の全イメージ（開発版、テスト版、過去のバックアップ）にアクセスされる可能性があります。こうしたイメージの内部には、設定ファイルやスクリプト類が含まれ、その中に認証情報などの機密データが記載されていることも、珍しくありません。当該データが攻撃者の手に渡れば、さらに内部のシステムに奥深く侵入される恐れがあります。
クラウド上のレジストリは、企業や組織の知識ベースに相当します。それを不用意に外部公開すれば、重大なセキュリティ問題が立て続けに発生する可能性があります。企業や組織では、レジストリを適切な設定のもとで安全に管理することが重要です。
問題点2：シークレットのストレージ
第2の問題点は、企業や組織がコンテナイメージに重要なシークレットを格納していることや、その方法にあります。前回の調査でも、DevOpsに潜む脅威の一環として、この問題を深堀りして解説しました。
当該の問題を解決するためのアプローチが、2つ存在します。第1のアプローチは、イメージ内にシークレットを保管することなく、処理の実行時に参照する方式を用いることです。また、シークレットのスキャンや保護の仕組みを導入することも、攻撃の防止に繋がります。
第2のアプローチは、シークレットをイメージやコードベースから完全に排除することは、難しいという前提に立つことです。実際に開発や運用では、一定の信頼レベルが満たされていると想定し、割り切って対応せねばならないケースもあるでしょう。そのため、やむを得ずシークレットをイメージ内に保管するのであれば、暗号化を徹底することが重要です。また、復号は実行時にのみ行い、鍵データをイメージ内に含めないようにします。これにより、仮にイメージ内のシークレットが流出しても、攻撃者側ではそれを復号できず、利用する術もなくなります。
証明書や秘密鍵に特有の課題
イメージに格納されたシークレットと言えば、多くの場合、APIトークンやパスワード、各種プラットフォームの認証情報などが思い浮かぶでしょう。しかし、認証情報や秘密鍵についても、下記の性質があることを踏まえ、格別の注意を払う必要があります。
- 認証と信頼性：SSL/TLSの証明書やSSH鍵は、ただ機密性が高いと言うだけでなく、ユーザやシステムが自身を証しするために用いる点で、特徴的です。攻撃者がこれらのデータを入手すれば、対象のユーザやシステムになりすますことが可能になります。結果、不正な活動によって組織内のシステムが攻撃者のリソースに接続させられても、正規の証明書や秘密鍵が提示されているため、正常な動作と誤認識してしまうケースが発生します。
- ローテーションなしでの長期利用：APIトークンやパスワードは比較的頻繁に、自動でローテーション（変更）にかけられます。一方、証明書や秘密鍵は、信頼性に重点を置いた厳格な手続きの下で発行されるものであり、取り消しや再発行には相応の手間が必要となります。結果、同じ証明書や秘密鍵が長期に渡って利用され、露出する傾向にあります。
- ステルス性：証明書や秘密鍵が不正なユーザに利用されても、それを特定する痕跡がすぐには現れないことがあります。結果、攻撃者は長期に渡って水面下で活動を続けることが可能になります。また、スキルの高い攻撃者であれば、不正な通信を正常な通信に見せかけたり、一見すると正常なセッションを独自に作成するなど、警戒の緩和に向けた偽装工作を行う場合があります。
- 法律またはコンプライアンス上のリスク：業界によっては、特定の証明書や鍵データの流出が単なるセキュリティ上の懸念事項にとどまらず、コンプライアンス違反と見なされることがあります。厳密なデータ保護の規約を課している業界であれば、セキュリティ面での影響に加え、罰金や法的な問題に発展する場合もあります。
以上の理由から、証明書や秘密鍵を未保護の状態でコンテナイメージ内に放置することは、それを敵対者に差し出すのと同等の危険行為に相当します。残念ながら開発においては、証明書や秘密鍵に関連するファイルが忘れ去られることさえあります。特にローカル稼働のサービスをパッケージ化する際には、その傾向が強まります。VPNやSSHの簡易テストにおいても、似たような状況が発生します。
実例：OpenVPNやSSHの鍵データを含むイメージ
今回調査したコンテナイメージの1つからは、OpenVPNの証明書（または秘密鍵）やSSHの秘密鍵が漏洩していました。双方とも、通信の重要な要素に相当します。
OpenVPNは、VPNトンネルの構築によく使用される技術であり、証明書や秘密鍵を用いて安全かつ暗号化された接続を確立します。攻撃者が当該の証明書や秘密鍵を入手した場合、組織の正規なVPNに承認済みユーザとして接続したり、正規のVPNサーバに見せかけた偽のVPNサーバを設置することが可能になります。これにより、通信データの盗聴、他企業ネットワークへの侵入、機密情報の流出、サプライチェーン攻撃などに及ぶ可能性があります。
一方でSSHは、リモートからサーバを安全に管理するための中核的な技術です。攻撃者がSSHの秘密鍵を窃取した場合、対応する公開鍵が登録されたサーバやシステムにパスワード認証なしで不正ログインするケースが、よく見られます。さらに、多くのシステム管理者が同じSSH鍵を複数環境で流用しているため、ただ1つの鍵が盗まれただけでも、複数のサーバやサービスが侵害されることになります。
コンテナイメージからSSH秘密鍵とOpenVPN証明書の双方が流出すれば、脅威の度合いは格段に高まります。攻撃者はまずVPNに不正アクセスし、SSH認証情報を利用して内部サーバを乗っ取り、最終的にネットワーク全体を掌握する可能性があります。こうしたセキュリティ事象の連鎖的発生により、多大な損害に至ることが懸念されます。
秘密鍵や証明書を再利用した活動も視野に入れると、攻撃の影響や可能性は一層膨れ上がります。
ビルド済みイメージに証明書や秘密鍵が含まれる理由
そもそも、なぜ秘密鍵や証明書などの機密ファイルがイメージ内に含まれてしまうのか、という疑問が上がるかも知れません。以降に、その典型的な事由を示します。
第1に、ビルド環境と本番環境を明確に分離していないケースが挙げられます。開発時にコンテナイメージをビルドする際の環境では、ホストシステム内に環境変数を用意したり、共有ボリュームに秘密鍵を配備して用いることがあります。こうした方式では、Dockerfileの設定に関する考慮漏れにより、ディレクトリの内容を秘密鍵も含めてイメージ側にコピーしてしまうミスが発生しがちです。
本調査では、一意な「Dockerfile」が1,653個、一意な「Docker-Compose.yml」が918個発見されました。これらのファイルは、ビルドの工程でイメージ内にコピーされたものです。
第2の要因として、利便性の過度な優先が挙げられます。例えば、本番環境の再現やトラブルシューティングの対応を円滑化するために、イメージ内にSSH鍵を含める場合があります。こうした習慣は、時間を十分に確保できない場合や、環境が複雑化している場合によく見られます。しかし、その代償として、セキュリティ上のリスクを孕んでいます。
第3の要因として、設定データのコピーペーストが挙げられます。VPNなどの分野では、「ここに設定ファイルを指定してください（Put your config files here.）」などの指示を記載したDockerfileの設定テンプレートがよく見られます。これをそのまま利用すると、ビルド時にDockerエンジンが設定ディレクトリの全内容をイメージ側にコピーします。その中には、証明書や秘密鍵、証明書チェーン（CAチェーン）なども含まれている可能性があります。
最後に、クリーンアップ忘れが挙げられます。デバッグなどの一時的な用途でコンテナ内に鍵データを入れたものの、削除を忘れ、いつまでも残り続けるケースが、これに相当します。また、Dockerfileからの参照を削除しても、中間的なビルドレイヤーがイメージ履歴に残り続ける点に注意が必要です。レジストリに最終イメージと古いレイヤーの双方を保持する方式では、過去のイメージに格納した鍵データが依然として残留することになります。
証明書や鍵データが流出した場合の影響
証明書や鍵データが流出した場合の影響は、軽度な業務障害から甚大な被害に至るまで、さまざまです。攻撃者は、主に下記の活動を行う可能性があります。
- VPNの侵害：OpenVPNの証明書や秘密鍵を窃取した攻撃者は、既存のVPNに入り込むか、または、不正なVPNを立ち上げる可能性があります。結果、標的組織の内部ネットワークが不正な通信経路に乗せられ、情報流出などの被害に至ります。
- 無制限のサーバアクセス：流出したSSH秘密鍵が高い権限を持つユーザに属する場合、攻撃者はシステムを広域的にコントロールできるようになります。結果、標的ネットワーク内で水平移動してバックドア型マルウェアをばら撒くなど、長期的な被害をもたらす可能性があります。
- 中間者攻撃：SSL/TLS証明書や秘密鍵を入手した攻撃者は、ユーザの通信に割り込み、不正なネットワーク側に転送する可能性があります。これは、中間者攻撃（MitM：Man-in-the-Middle）に相当します。
- ユーザなりすまし：上述の中間者攻撃に成功した場合、攻撃者は標的システムとやり取りする顧客ユーザの認証情報を盗み取る可能性があります。
- 情報窃取：上記の認証情報を入手した攻撃者は、それを用いてより機密性の高い顧客情報や企業情報を盗み取る可能性があります。
- サプライチェーンの侵害：ビルド用コンテナが外部に公開されている場合、攻撃者はそこに含まれる実行バイナリに不正な処理を埋め込む形で、サプライチェーンを侵害する可能性がある。この際、盗み出した証明書を用いて当該バイナリに署名を施し、正規なものに見せかけることも考えられます。結果、当該証明書が取り消されるか期限切れになるまで、顧客側では変化に気付けなくなります。経験則として、コンテナ内のシークレットが多ければ多いほど、攻撃の成功率も高まります。
- 信用や評判の失墜：上記の全てが、金銭面と評判面での被害をもたらします。セキュリティ上の取り組みに関してクライアントやパートナーから得ていた信頼に傷が付き、問題がすぐに解決されたとしても、評判上の影響が払拭されるまでには時間がかかります。
誤認識に関する注意事項
導入しているセキュリティソリューションや対策に関わらず、下記のような思い込みには、常に警戒する必要があります。
危険な思い込みその1：「このコンテナはプライベートなのだから、大丈夫」
レジストリの設定不備は、常に発生する可能性があります。特に、自身でコンテナレジストリをホストする際には、デフォルト設定で認証が不要な場合も多いため、格別の注意が必要です。誤って公開設定にしてしまうと、その瞬間から全認証情報が漏洩のリスクに晒され、プライバシーという概念が根底から崩れ落ちます。
危険な思い込みその2：「.dockerignoreのファイルを使っているのだから、大丈夫」
「.dockerignore」の設定は、機密ファイルの誤ったコピーを避ける上で確かに有用ですが、ミスに注意する必要があります。Dockerfileや.dockerignoreの編集時にわずかな誤記や手順誤りがあっただけで、機密ファイルを除外したいという目的は達成されなくなります。
危険な思い込みその3：「あくまでdev/testのイメージだから、大丈夫」
仮に対象環境に「dev（開発）」や「test（テスト）」などのラベルが付与されていても、そのSSH鍵や証明書が本番環境に紐づいている可能性があります。また、これらの鍵や証明書が他のネットワークリソースを開放させるケースもあり得ます。攻撃者は、開発用のイメージからでもくまなく情報を探し出し、本番環境への侵入に繋げようとします。
危険な思い込みその4：「このファイルは後で削除するから、大丈夫」
「後で」と言ったことが、実際には永久に起こらないこともあります。中間的なイメージレイヤーの中に過去のファイルが記録されるケースを踏まえると、多段階ビルドを的確に運用するか、所定のレイヤーを正しく削除しない限り、問題のデータはイメージレイヤーの構造内に残り続ける可能性があります。
リスク軽減策とベストプラクティス
本稿で挙げた攻撃シナリオを回避する上では、厳格な手続きやコードレビュー、適切なソリューションの選定、セキュリティに配慮した開発手法を実施することが重要です。推奨される対策を、下記に示します。
シークレットをイメージから完全に除去する
経験則として、証明書や秘密鍵などのシークレットや認証情報をコンテナイメージに含めることは、推奨されません。代替策として、専用の環境変数や、処理の実行時に認証情報を埋め込む「シークレット管理ソリューション（HashiCorp Vault、AWS Secrets Manager、Docker/Kubernetesのシークレット機能）」などが挙げられます。
具体的な状況の一例として、「server.crt」という名前のSSL証明書と、対応する秘密鍵ファイル「server.key」があり、それを「Dockerfile」や「docker-compose.yml」にハードコーディングすることなくコンテナ側に転送したいケースを考えます。
この目的を達成する手段の1つは、利用中のSwarm内にシークレットを作成することです。
$ docker secret create my_server_crt server.crt
$ docker secret create my_server_key server.key
コマンド「docker secret create」は、主にパスワードの作成を目的としたものですが、鍵データや証明書のファイルにも対応しています。
イメージスキャンツールの導入
シークレットや暗号鍵、不審なファイル名をイメージから検出する専用ツールが存在します。こうしたツールによる検証をCI/CIパイプラインの工程に組み込むことで、機密ファイルがレジストリに乗せられる事態を回避できる可能性が高まります。
プロアクティブなセキュリティソリューション
トレンドマイクロが提供するセキュリティ機能「TMAS（Trend Micro Artifact Scanner）」は、実行前のイメージや脆弱性、マルウェア、シークレットをさまざまなアーティファクト上でスキャンします。これにより、本番環境への反映前に問題を検知し、対処することが可能です。TMASを包含する「Trend Vision One™」は、唯一のAI駆動型エンタープライズ・サイバーセキュリティプラットフォームであり、サイバーリスク管理やセキュリティ運用、堅牢な多層保護を一元化して提供します。この包括的なアプローチにより、全デジタル資産を通してプロアクティブにセキュリティ対策を実行し、先手を打って脅威を予測、阻止することが可能です。
「Trend Vision One」は、長年に渡るサイバーセキュリティ業界での実績や、業界初のプロアクティブなサイバーセキュリティAI「Trend Cybertron」を駆使することで、ランサムウェアのリスクを92%削減、検知所要時間を99%削減するなど、確かな性能を発揮しています。セキュリティリーダーの方は、自社のセキュリティ態勢を評価し、改善に向けた取り組みを継続的にステークホルダーに示すことが可能です。Trend Vision Oneを導入することで、セキュリティ上の弱点を一掃してより重要な課題に注力し、セキュリティを戦略上のパートナーと見据え、さらなるイノベーションを促進できるようになります。
多段階ビルドの利用
Dockerの「多段階ビルド」は、最終イメージをクリーンな状態に保つのに役立ちます。オプション「必要なアーティファクトのみを本番環境にコピー」を指定することで、開発やデバック用の鍵データが最終イメージに移送される事態を防止します。
また、レジストリをデフォルトでプライベートとなるように設定し、厳格なアクセス制御を導入することも重要です。強力な認証やロールベースの権限管理を行うことで、信頼済みのユーザやシステムでしかイメージを更新、入手できないように制限できます。
シークレットの暗号化
どのような対策を講じても、シークレットがイメージやコードベースに入り込む可能性は、常にあります。特に最終段階では、一定の信頼を前提とした操作や運用が必要になってきます。そのため、シークレットは暗号化して保存することが望まれます。また、復号は実行時にのみ行い、鍵データをイメージに置かないように徹底します。こうすることで、仮にシークレットが攻撃者の手に渡ったとしても、復号されるには至らず、影響を抑え込める可能性が高まります。
参考記事：
From Registries to Private Networks: Threat Scenarios Putting Organizations in Jeopardy
By: Alfredo Oliveira and David Fiser
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）