サイバー脅威
認証なしで公開されているコンテナレジストリが引き起こすサプライチェーン攻撃のリスク
本稿では、認証を必要とせずに公開されているレジストリまたはデータベースのセキュリティリスクについて解説します。これらのレジストリには機密情報も格納されている可能性がある中、公開されているため誰でもアクセス可能となっています。
本稿では、認証を必要とせずに公開されているレジストリまたはデータベースのセキュリティリスクについて説明します。これらのレジストリには情報が格納されており、公開されているため誰でもアクセスできます。今回の調査では、クラウドサービス上でホストされているこの種のレジストリを大量に発見し、中に格納されていた9TB以上のイメージや20,000以上のダンプされたイメージなどのコンテンツを正常にダウンロードすることができました。
こうした状況に伴う潜在的なセキュリティへの影響を浮き彫りにし、公開されたレジストリを使用する際のセキュリティ面の考慮事項の重要性を解説します。なお、本稿では、専用のクラウドホストコンテナレジストリのセキュリティは扱わず、クラウドワークロード内における手動でのコンテナレジストリ展開に伴うリスクを詳説します。これらの状況は、設定ミスを招きやすく、有効な攻撃経路となる可能性があるからです。
まず、今回の調査で扱った主な数値を以下に示します。
コンテナは、アプリケーションの開発、デプロイ、管理の方法に変革をもたらしました。隔離、移植性、一貫性を提供することで、クラウド環境での迅速なスケーリングと効率的な統合を可能にするからです。コンテナは、クラウドネイティブテクノロジーの成長を促進し、多くの最新アプリケーションの設計、デプロイ、管理の仕方を根本的に変えました。
こういったコンテナと連携するうえで重要な側面は、アプリケーションをカプセル化するために使用されるコンテナイメージの保存と管理です。これらのイメージをどこかに保存する必要があるため、クラウドサービスプロバイダー（CSP）はイメージリポジトリとして機能し、開発者がさまざまな環境間でアプリケーションを共有およびデプロイできるようにマネージドレジストリサービスを提供し始めました。さらに、企業や組織は、オンプレミスまたはクラウドコンピューティングインスタンスワークロード（Amazon EC2など）の内部で、独自のコンテナイメージレジストリをデプロイおよび運用することも選択できます。
コンテナイメージレジストリについて
コンテナイメージレジストリは単なるリポジトリ以上のものであり、コンテナ化されたシステムの生命線とも言えます。これらのレジストリは、プリインストールされたアプリケーションとその依存関係や環境設定などのレイヤーを含む静的ファイルであるコンテナイメージを保存します。セットアップに際しては、アプリケーションコード、ライブラリ、システムツール、その他の設定事項が含まれています。
コンテナイメージの各レイヤーは、ファイルの追加や構成の変更など、イメージへの変更を担当しています。これらのレイヤーが積み重ねられて最終的なイメージが形成されます。イメージが更新されると、変更されたレイヤーのみが更新されることから、コンテナイメージの使用が効率的になります。
コンテナの作成は通常、アプリケーションのイメージ構築から始まります。このプロセスには、アプリケーションコードのコンパイル、必要な依存関係とのバンドル、ランタイム環境の構成が含まれます。結果として得られるイメージは、アプリケーションの実行に必要なすべてをカプセル化した単体で実行可能なパッケージとなります。
イメージが構築されると、レジストリ（プライベートまたはパブリックリポジトリ）にプッシュされます。CSPは、ニーズと構成に応じて、マネージドサービスとしていずれかまたは両方を提供できます。この際、ユーザはレジストリへのアクセスの構成方法を選択でき（パブリックリポジトリでも変更のプッシュやイメージのアップロードを制限できます）、リポジトリにプッシュされる前に機密コンテンツをフィルタリングする責任があります。
レジストリは、配信ポイントとして機能し、イメージを保存し、必要に応じてプルできるようにします。これは、異なるバージョンのアプリケーションを異なる環境間において一貫性と信頼性を持ってデプロイできることを保証する上で、コンテナライフサイクルにとって重要な側面となります。
レジストリに保存されているイメージは、アプリケーションとそのすべてのソフトウェア依存関係をカプセル化しています。これは、配置される環境に関係なく、アプリケーションが同じ方法で実行されることを意味し、コンテナイメージレジストリを使用することによって実現されます。
コンテナイメージレジストリは、コンテナ化された環境でのアプリケーションのデプロイにおいて重要な役割を果たし、コンテナイメージの集中保存および配信地点として機能します。
コンテナが起動すると、必要なコンテナイメージをプルするために、システムはレジストリにアクセスします。その後、このイメージを使用してホストシステム上に実行中のコンテナをインスタンス化します。このことから、レジストリのセキュリティと信頼性が極めて重要であることがわかります。レジストリが侵害されると、侵害されたイメージがデプロイされてしまう危険性があります。この点については後半で言及しますが、これによりさらなる深刻なセキュリティリスクが生じる可能性があります。
ただし、レジストリの役割はこうした保存以上のものと言えます。レジストリを使用すると、複数のイメージバージョンを保存しつつ、タグを使用してこれらすべての変種を追跡できます。例えば、開発者は、開発、テスト、本番の各環境に対して、構成のわずかに異なるイメージを保持する場合がありますが、レジストリを使用することで、これらすべての変種を追跡できるため、必要に応じて適切なイメージをプルできます。
ただし、クラウドベースのサービスを使用する場合もセキュリティリスクは存在します。例えば、コンテナイメージレジストリでは、攻撃者が書き込みや、イメージをプッシュする権限を得たりすると、イメージに不正なコードが注入され、レジストリ内の元のイメージが置き換えられる可能性があります。一方、非公開であるべきレジストリへの読み取りアクセス権を取得した場合、イメージをプルして機密情報を悪用することも可能となります。このため、レジストリ自体だけでなく、保存されている個々のイメージを保護することが不可欠です。
コンテナイメージレジストリは、コンテナ化されたインフラストラクチャの重要なコンポーネントであるため、その仕組みと保護方法を理解することは、コンテナ化されたアプリケーションと基盤インフラストラクチャの整合性とセキュリティを維持する上で不可欠と言えるでしょう。
コンテナイメージレジストリの状況
トレンドマイクロでは、公開されているレジストリの調査を実施し、Amazon Web Services（AWS）に多数ホストされていることを確認しました。この際、認証情報や、ブルートフォース攻撃の手法を使用することなく、これらに接続し、コンテンツをダウンロードできました。
以下がその規模を示すデータポイントとなります。
- 9.31TB：ダウンロードされたイメージの容量
- 197：ダンプされたレジストリのユニーク数
- 20,503：ダンプされたイメージ数
これらの数字は、非常に大きな規模の容量およびダンプされたイメージやレジストリの件数を示しており、攻撃者がこれだけの規模で潜在的にアクセスできる可能性があり、この問題がいかに広範に及ぶかという状況を浮き彫りにしています。
また、これらの公開されたレジストリの所有権が、個人ユーザや小規模企業に限定されているわけではないことも確認しました。むしろ、その一部は、これら以外には公開コンテナやコード共有プロジェクトがない民間企業によって所有されていました。
公開されたレジストリのリスク
公開されたレジストリは、適切な認証メカニズムがない状態で誰でもイメージをプルできるため、重要なセキュリティリスクが存在します。これにより、イメージに埋め込まれた独自ソフトウェアや機密データへの不正アクセスにつながる可能性があります。また、公開されたレジストリに攻撃者がアクセスした場合、侵害されたイメージを誤設定されたレジストリにプッシュバックさせ、マルウェアの拡散につながる可能性もあります。
公開されたレジストリに関連するリスクは、こうした実証実験的なものだけではありません。実際、公開されたレジストリがセキュリティ侵害につながった事例が数多く報告されています。
今回の調査に伴うセキュリティリスクの影響を完全に理解するには、コンテナイメージレジストリの仕組みおよびコンテナ化された環境における重要性について、以下のとおり詳しく見ていく必要があります。
公開されたレジストリがもたらす影響
今回の調査で明らかになった公開されたレジストリは、重大なセキュリティリスクを示しています。適切な認証情報で保護されていない場合、これらのレジストリは、発見した誰に対しても公開されてしまいます。こうしたセキュリティの欠如は、レジストリに格納されているイメージが露出されるだけではなく、書き込みアクセス許可が付与されている場合は、誰でもイメージをプッシュできるようになります。
こうした無制限のアクセスは、潜在的に2つの影響をもたらし、いずれのシナリオでもセキュリティ侵害の原因となり得ます。1つ目は、イメージ内に格納されている独自情報や機密情報が露出するシナリオです。この場合、ソースコードの他、ソースコードやコンテナイメージに属さない機密情報まで（APIキーやデータベース資格情報など）、幅広い範囲に及ぶ可能性があります。これらの情報が攻撃者の手に渡れば、システムへの不正アクセスを得たり、知的財産を窃取したり、対象に攻撃を展開したりすることが可能となります。
2つ目は、公開されたレジストリへの書き込み権を持つ攻撃者が、侵害されたイメージをプッシュできるシナリオです。この場合、この侵害されたイメージには、バックドア、暗号通貨マイナー、ランサムウェアといった不正コードが含まれている可能性があります。これらの侵害されたイメージをプルするシステムは、不正コードを実行する可能性があり、インフラ全体に被害が広がる危険性もあります。こうして、情報窃取や、システムの混乱、大規模なランサムウェア攻撃に至るまで、様々な危険なシナリオにつながる可能性があります。
さらに、公開された上に誤設定されたレジストリの影響は、所有する企業や組織への直接的な脅威だけでなく、より大きな範囲に及ぶ可能性さえあります。今日のようなソフトウェアサプライチェーンにより相互接続された状況を考えると、特定箇所で侵害されたイメージは、すぐに他のシステムや組織に拡大する可能性があります。こうした波及効果により、公開された単一のレジストリの影響が増幅され、地域的な侵害が広範なセキュリティ事例に変わってしまう可能性があります。
コンテナイメージレジストリの保護
公開されたレジストリが企業や組織に与える影響は甚大であり、コンテナ化されたアプリケーションのセキュリティに対して重大な脅威となる可能性があります。このことは、堅牢な認証メカニズム、定期的な脆弱性スキャン、アクセスレベルの厳格な管理など、適切なレジストリセキュリティ対策の重要性を浮き彫りにしていると言えます。
以下、コンテナイメージレジストリを保護するために必要なベストプラクティスを見ていきます。
高度な認証機能の導入とIDライフサイクル管理
高度な認証機能によるセキュリティ対策の利用により、権限のあるユーザのみがレジストリにアクセスできるようになります。これは、従来のユーザ名とパスワード、APIキー、デジタル証明書など、さまざまな方法で実行できます。多要素認証など高度な認証機能の実装は、組織のレジストリへの不正アクセスからの最初の防御線です。さらにその上で企業や組織は、オンボーディング（新しいデジタルIDの作成とリソースへのアクセスの提供）からオフボーディング（ユーザが企業や組織を去ったときのリソースへのアクセスの終了）まで、ユーザの適切なIDライフサイクル管理が策定されていることも確認する必要があります。
企業や組織およびユーザは、基本的なセキュリティ慣行として「最小特権の原則」に従う必要があります。この原則は、ユーザには業務を遂行するために必要なアクセスレベルまたはアクセス許可のみを付与する必要があることを述べています。レジストリのコンテキストでは、これはイメージのプッシュやプル、削除や変更を行うことができる人を制限することを意味します。
イメージへの脆弱性スキャン
イメージ中に含まれるソフトウェア関連の既知の脆弱性を検出するため、イメージへの定期的な脆弱性スキャンが有効です。また、このプロセスを自動化するさまざまなツールも利用可能となっています。例えば、イメージがレジストリにプッシュされるたびにスキャンを実行し、潜在的な脆弱性をユーザに警告してくれます。この場合、脆弱性の検出だけでなく、イメージから漏えいする可能性のあるハードコード化された機密情報の保護にも有効となります。
データの保存時および転送時における暗号化
データの保存時および転送時での暗号化を実施することで、誰かがデータへの不正アクセス権を得た場合でも、そのデータの読み取りを阻止できます。データの暗号化には、さまざまな方法とツールが利用可能であり、最適な選択はユーザの具体的なニーズや全体的な環境によって異なります。
レジストリの定期的な更新とパッチの適用
他のタイプのソフトウェアと同様に、コンテナイメージレジストリおよび基盤ソフトウェアにも、定期的な更新とパッチ適用が不可欠です。一定の間隔でアップデートとパッチを適用することは、新機能の実装が迅速化するだけでなく、悪用可能な脆弱性とその他のセキュリティ不具合の修正も迅速化され、これらのレジストリが最新かつ安全な状態であることを保証します。
マネージドコンテナレジストリは、企業や組織にとってもう1つのオプションとなるでしょう。この種のサービスでは、CSPがパッチや基盤構成の管理を担当するため、顧客はアクセス制御の構成のみに専念できます。
ファイアウォールルールの実装
企業や組織において、ワークロードかネイティブサービスのいずれかでコンテナレジストリを使用しているかに関わらず、適切なセキュリティ対策の適用、監視、実装は必要となります。コンテナイメージレジストリの場合、サービスへの望ましくない接続をブロックするためにもファイアウォールルールを確立し、認証、暗号化を有効にしたうえで、システムを継続的に監視することが不可欠です。
社内チーム向けのコンテナプル用レポジトリの提供
社内チームのためには、信頼できるコンテナをプルできる一元管理されたレポジトリを提供することで、頻繁に必要とされる機能の利用を簡単にすることができます。このコンポーネントとその依存関係のソースを一元的に管理することで、セキュリティチームが統合前にコンポーネントの特性を評価できるようになります。さらに、この設定によって既存パッケージの変更から生じる予期しない問題の可能性が低減されます。
シークレットレスコンテナの使用
機密情報が外部管理されたシークレットレスコンテナを使用することで、コンテナ化された環境内での機密情報の処理において、より安全で効率的な方法が可能となります。この場合、アプリケーションから独立した形での機密情報が管理されるため、シークレットレスコンテナは、重要なデータへの不正アクセスのリスクを軽減し、全体的なセキュリティを強化するため、レジストリの侵害が成功した場合でも認証情報の漏えいリスクが回避されます。
結論
コンテナイメージレジストリの保護は、コンテナへのセキュリティ対策において重要な側面であり、DevOps環境全体とその関連インフラストラクチャにとって不可欠と言えます。本稿で確認したとおり、多くの開発者やその他のユーザがレジストリを公開された状態のままにしているため、潜在的な脅威に対して脆弱になっています。これらの脅威を理解し、本稿で示されたベストプラクティスに従うことで、個々のユーザおよび企業・組織の両方がセキュリティ侵害のリスクを最小限に抑え、コンテナイメージの安全を確保できます。
なぜこれほど多くのレジストリが、セキュリティ対策なしに公開されたままになっているのでしょうか。その理由を1つに絞ることは難しいでしょう。しかし、これまでに確認してきたことから、設定ミスがこの問題の要因と言えます。他のタイプのセキュリティ侵害と比較して設定ミスはマイナーなセキュリティ上の問題に見えるかもしれません。しかし、クラウドテクノロジーが広く使われている今日、設定ミスは、他のセキュリティリスクと同じレベルの懸案として扱うべきです。
クラウドへのセキュリティ対策は、通常、AWSの責任共有モデルの対象となります。このモデルは、クラウドプロバイダの強みを（インフラストラクチャとテクノロジーを通じて）活用する一方で、（適切なクラウドアセットの設定など）ユーザが堅牢で安全なクラウド環境を構築することにも依存しています。つまり、このモデルは、安全で信頼できるクラウドインフラを維持するために両当事者が効果的に協力することに依存しているのです。
これらを念頭にプライベートレジストリを実装する際、ユーザは、次のようなセキュリティ関連の質問について自問すべきでしょう。
- 本当にプライベートレジストリサービスをデプロイする必要があるか。
- このサービスはオンプレミスで提供するべきか、クラウド上で提供するべきか。
- クラウド上で提供する場合、マネージドサービスを利用するか、自身でレジストリを運用するかのトレードオフを組織として理解しているか。
- 誰がそれらのレジストリにアクセスでき、どのようにアクセスしているか（社内ネットワークからアクセスできるか、ファイアウォールルールでアクセスを許可したリモートネットワークからアクセスできるか、VPN接続したリモートネットワークからアクセスできるかなど）。
- コンテナは機密情報や独自情報を保持する予定であるか。もしそうなら、そうした情報を暗号化することで、どういった悪影響が出る可能性はあるか。
- コンテナイメージには不要な認証情報が含まれていないか。
今後、これらの公開レジストリからアクセスできた情報の詳細についても調査する予定です。また、ユーザやCSPがコンテナイメージレジストリをさらに保護するために実装可能でより高度なセキュリティ対策についても議論していく必要があります。
参考記事：
Exposed Container Registries: A Potential Vector for Supply-Chain Attacks
By: Alfredo de Oliveira and David Fiser
翻訳：与那城 務（Core Technology Marketing, Trend Micro™ Research）