ハードニング済みイメージとは何ですか？
ハードニング済みイメージとは、特定のセキュリティ標準に準拠するように専用に構築または事前設定された、VMまたはOCIコンテナイメージです。イメージのハードニングのプロセスには、不要なユーティリティやライブラリの削除、設定基準の実装、脆弱性のスキャン、パッチの適用などが含まれます。
ハードニング済みイメージを使用することで、ワークロードが最初からセキュリティのベストプラクティスに従っているという安心感が得られます。ハードニング済みイメージにより、リリース時点での攻撃対象領域と既知の脆弱性が最小限に抑えられているという確信を持てます。ハードニング済みイメージは、配布前にCVEデータベースに対する徹底的なスキャンを受けますが、時間の経過とともに新たな脆弱性が出現する可能性があるため、継続的なスキャンとパッチ適用が重要になります。Wizを含む一部のベンダーは、ハードニング済みイメージ製品における脆弱性修復に関するSLAを維持しており、お客様がセキュリティ体制を維持できるようにパッチ適用の負担を引き受けています。
覚えておいてください：コンテナやVMが本番環境で稼働した後に脆弱性を修正するよりも、最初から問題を予防する方が簡単です。そのため、ハードニング済みイメージには確実なメリットがあります。事前に脆弱性を排除することで、脆弱性のノイズ、露出、および侵害のリスクが軽減されます。
セキュアイメージ 101
コンテナイメージのセキュリティに関する必要な知識を分かりやすく解説した、読みやすいデジタルポスターで、コンテナエコシステムを保護しましょう。
ハードニング済みイメージの種類と入手先
ハードニング済みイメージには、そのアーキテクチャやホスト環境との対話方法によって分類される、2つの異なるタイプがあります。
ハードニング済みVMイメージ
ハードニング済みVMイメージは、オペレーティングシステム全体、専用カーネル、および必要なすべてのドライバーを含む自己完結型の成果物です。これらのイメージのハードニングには、OSを必須サービスのみに絞り込み、 CISベンチマーク や STIG などの厳格な設定ベンチマークを適用することが含まれます。これらは、強力なハードウェアレベルの分離を提供するために、ハイパーバイザー（Hyper-VやKVMなど）上で実行されるように設計されています。
ハードニング済みコンテナイメージ
ハードニング済みコンテナイメージ は、アプリケーションとそのユーザー空間の依存関係のみを含む軽量な成果物であり、実行時にホストのカーネルを共有します。ここでのハードニングは、イメージサイズを縮小し、最小限のベースイメージを使用して不要なバイナリを排除することに焦点を当てています。イメージを最小限の機能要件まで削ることで、攻撃対象領域を縮小できます。コンテナイメージのハードニングは、脆弱性の排除にも焦点を当てています。「セキュア」イメージは、CVE修復に関する保証を提供することで、イメージのハードニングをさらに一歩進めたものです。これらのセキュアイメージは、ベンダーに裏付けられたSLAの下、CVEがほぼゼロの状態に継続的に維持されます。
アーキテクチャを決定したら、いくつかのチャネルからイメージを調達できます。
クラウドサービスプロバイダーのマーケットプレイス： すべての主要なクラウドプラットフォームには、継続的にメンテナンスされている、事前にハードニングされたイメージを入手できるマーケットプレイスがホストされています。これらを使用すると、VMの使用時間ごと、またはインスタンスごとの月額料金として追加コストが発生する場合があることに注意してください。
プライベートなハードニング済みイメージのメンテナー： Center for Internet Security（CISベンチマーク準拠のイメージ）などのベンダーは、パブリックまたはプライベートレジストリから事前にハードニングされたイメージを提供しています。
セキュアイメージ／マネージドハードニング済みイメージプロバイダー： Wizなどのベンダーは、CVE修復に関してベンダーが裏付ける厳格なSLAを備えたハードニング済みイメージを構築および維持しています。これは、お客様からパッチ適用とメンテナンスの負担を取り除き、時間の経過とともにハードニングされたセキュリティ体制を維持するのを支援することで、従来のハードニング済みイメージよりもさらに一歩進んだものです。
自作する： ハードニングプロセス全体を完全に制御したい場合は、自分でハードニング済みイメージを作成することもできます。これは最も手がかかる選択肢です。ビルドプロセス以外にも、進化し続ける脅威の状況に対応するために、ハードニング済みイメージのメンテナンスにも労力を費やす必要があります。
ソースからデプロイメントまでのセキュアなイメージパイプラインの構築
次に、セキュアなイメージパイプラインを構築するための一般的なフローを見ていきましょう。実際のステップは作成するイメージの種類や目的によって異なりますが、以下の段階ごとのヒントを参考にすれば成功に近づくことができます。
開発
要件と目標 を作成します。
信頼できる信頼性の高いソースから、優れたベースイメージを選択します（（VMとコンテナの両方に対応する）最小限のイメージ、または Distroless （コンテナのみ）——Distrolessイメージには、シェル、パッケージマネージャー、一般的なユーティリティが含まれていませんが、自動的にハードニングされているわけではないため、引き続きセキュリティ設定とスキャンが必要です。
選択したフレームワーク（CISベンチマークやDISA STIGなど）に準拠した 内部セキュリティメカニズムとツールを設定します。
アーキテクチャ固有のコントロールで攻撃対象領域をさらに縮小します。
VMの場合： ホストファイアウォール（
iptables、nftables）を設定してデフォルト拒否ポリシーを実装し、厳密に必要なポートのみが開いているようにします。コンテナの場合： コンテナ内ファイアウォールでイメージが「肥大化」するのを避けます。代わりに、 コンテナが読み取り専用のルートファイルシステムで実行されるように設定します。 これは、攻撃者が初期アクセスを取得した際に、マルウェアのダウンロードや永続化を防ぐ最も効果的な方法の1つです。
両方の場合： デフォルトユーザーを非rootに切り替え、不要なLinuxケーパビリティ（例：
CAP_NET_RAW または CAP_SYS_ADMIN）を削除し、AppArmorやSeccompなどのセキュリティプロファイルを使用してカーネルの攻撃対象領域を制限します。
このステージの間は機密情報を安全に保ちましょう！イメージにハードコードすると、これまでに強化プロセスに注力したすべての努力が台無しになってしまいます。
ビルド
イメージのビルドにCI/CDを使用する：自動化されたセキュリティ強化により、必要な労力が大幅に削減され、多くの時間を節約でき、十分にテストされた新鮮なイメージのソースを提供できます。
コンテナの場合は、最新のセキュリティを意識したビルドツール（例：BuildKitやBuildpacks）を使用します。
VMの場合は、Packerやクラウドネイティブツール（Azure Image Builderなど）を使用してビルドプロセスをコード化します。
スキャン
イメージとその中のすべてのコンテンツの脆弱性をスキャンし、欠陥のあるパッケージやライブラリを信頼できる安全なバージョン（または代替品）に置き換えます。
この段階では、Trivy、Grype、Wizなどのツールが役立ちます。
新しい脆弱性は毎日発見されます。すでにビルドしたイメージも定期的に再スキャンして、レジリエンスが維持されていることを確認してください。
出所証明（プロベナンス）の追加
イメージの起源、変更履歴、適用された基準を明らかにすることで、後からのセキュリティおよびコンプライアンスチェックが容易になり、改ざんも防止できます。
ベースイメージの正確な内容を追跡するためにSBOMを生成します。SBOMにはさまざまな形式があり、Linux FoundationのSPDXとOWASPのCycloneDXが業界の2大標準です。セキュリティ、コンプライアンス、サプライチェーン保護の他のエコシステムと互換性のある形式を選択してください。
イメージに署名する 後で整合性チェックを行えるようにするためです。イメージの署名には、 Sigstore Cosign 、Notary、Docker Content Trustなどのソリューションを使用できます。AWS Signerなどのクラウドネイティブサービスも役立ちます。例：Cosignを使用すると、1つのコマンドで コンテナイメージ に署名できます：
cosign sign --key <private key> <image>。この署名は、後で次のように検証できます。cosign verify --key <public key> <image>。ビルドの起源、SBOM（ソフトウェア部品表）の内容、セキュリティスキャン結果に関する暗号署名付きのステートメント（SLSA出所情報やin-totoの証明書を使用）を作成し、イメージを証明します。これらの署名付き証明書により、ダウンストリームの利用者は、イメージが改ざんされておらず、セキュリティポリシーを満たしていることを検証できます。
検証
このステップでは、これまでのすべての作業を振り返ります。
選択したベンチマークに対してイメージを検証します。スキャン結果を調査し、除外事項を正当化し、最終結果をレポートします。
イメージが期待通りに動作するかテストします。一部のセキュリティ対策、特に最も厳格なものは、不具合を引き起こす可能性があります。たとえば、非常に徹底的なミニマフィケーション（最小化）により、実際に必要なライブラリが削除されてしまうことがあります。検証ステップは、イメージがデプロイに向かう前に、すべてが正常に動作していることを確認する最後のチャンスです。
昇格とデプロイ
イメージの作成が完了しました。もちろん最後のチェックを通過した後ですが、これで環境の一部になることができます。
ポリシーの閾値を満たすイメージのみを許可する昇格ゲートを設定します（例：修正のある重大な、または重要度の高いCVEがないこと、必須のイメージ署名および証明書があること、CISベンチマークに準拠していること）。パッチのない脆弱性に対するリスク受容ワークフローを定義します。
OPA Gatekeeper、Kyverno、またはKubernetes Pod Security Admission（PSA）を使用してアドミッションコントロールを設定し、署名され、証明され、テストされ、準拠しているコンテナイメージのみをデプロイ候補として受け入れます。たとえば、KyvernoポリシーでCosignの署名を検証し、デプロイ時に署名のないイメージをブロックできます。
セキュリティチームは、CI用のスキャナー、レジストリ用の2番目のスキャナー、ランタイム用の3番目のスキャナーなど、それぞれ異なるポリシーや閾値を持つ断片化されたツールに苦労することがよくあります。代わりに、単一のポリシーエンジンの導入を検討してください。開発から、CI、環境の昇格、アドミッションに至るワークフロー全体で、ポリシーを1つだけにすることを目指します。これにより、不要なツールの断片化とそのオーバーヘッドなしに、均一で一貫性のある堅牢なセキュリティ体制を維持できます。
12分間のデモを見る
Wiz は、露出したコンテナを特定し、攻撃パス全体を視覚化し、コード内で直接問題を修正します。
クラウド運用を阻害する一般的なハードニングの落とし穴
安全ではない設定
ハードニングにおいて最も重要な部分の一つは何でしょうか？ それは安全な設定です。イメージの問題は、単純なミスから頻繁に発生します。残されたままの緩いファイアウォール設定、無効化された組み込みセキュリティツール、VM/コンテナホスト上のSELinux/AppArmor/seccompの設定ミスなどがその例です。不幸なことに、これらのミスは最終的なイメージの信頼性に深刻な悪影響を及ぼします。
依存関係と追加
ハードニング済みイメージは、そのままの状態で安全であるように設計されていますが、常に 安全な 状態を維持できるとは限りません。ハードニング済みイメージをアプリケーションのベースイメージとして使用している場合、その依存関係やビルドプロセスによって脆弱性が持ち込まれる（または再導入される）可能性があります。どのような方法や形式であれ、ハードニング済みイメージに何らかの追加を行う場合は、必ず再度スキャンする必要があります。
ランタイムの設定ミス
過剰な権限を持つアクセスや、重要なソフトウェアの更新およびパッチのスキップなどのランタイムの設定ミスは、適切にハードニングされたイメージであっても問題を引き起こしやすくします。これはコンテナにおいて特に当てはまります。特権モードでのコンテナの実行、コンテナ内でのrootユーザーの使用、過剰なカーネルケーパビリティ、ルートファイルシステムに対する書き込み権限などは、悪意のあるアクターが コンテナエスケープ を実行するために必要な足がかりになり得ます。
インターネット露出、特権コンテナ、機密データといった深く具体的な文脈なしに、これらすべての落とし穴を取り除こうとすると、チームはノイズを追いかけることになってしまいます。代わりにリスクグラフアプローチに焦点を当てて本当に重要なものを優先し、ターゲットを絞った正確な修正をデプロイしてください。
ハードニング済みイメージを実装するためのステップバイステップのロードマップ
もしあなたが シフトレフト を行いたいのであれば（そして、そうすべきです）、プロジェクトの非常に早い段階でハードニング済みイメージを実装してください。その方法は以下の通りです：
組織に最も適した標準とポリシーを選択します。確信が持てない場合は、 CISベンチマーク が優れた出発点となります。
ハードニングが必要なワークロードを特定し、優先順位を割り当てます。一部のワークロードは他のものよりも重要であるため、どのワークロードに最も注意を払う必要があるかを慎重に選択してください。残りの部分については後で検討すれば十分です。
適切な修復アプローチを決定します。自分でイメージを構築するか、ベースイメージを使用してその上にアプリケーションを追加するか、あるいは完全に事前構築されたソリューションを採用するか？
選択したイメージをワークフローに統合します。CI/CDパイプラインがプロセスにおいて重要な役割を果たすように調整します。例えば、定期的なスキャンを設定したり、パッチが公開されたときに自動ビルドが行われるように設定したりします。
環境を監視し、ゴールデンスタンダードを維持します。セキュリティ体制を定期的に見直し、新しい脆弱性を継続的に監視し、イメージの品質を再評価して、常にクリーンで安全な状態を保ちます。
双方向の追跡可能性を目指します。クラウドで問題が見つかった場合、それを生成したベースイメージやパイプラインまで簡単にさかのぼることができるようにします。また、コードやビルドの欠陥を修正する際には、影響を受けるクラウド環境でのドリフトを検証します。手動での調査やチケットの引き渡しをなくすことで、追加のコンテキストを自動的に収集し、修復平均時間（MTTR）を数日から数時間に短縮できます。収集したいコンテキストは以下の通りです：
クラウド リソース: ECSタスク、Kubernetesポッド、VMインスタンス
コンテナ イメージ: レジストリ、タグ、ダイジェスト、ビルドのタイムスタンプ
CI/CD パイプライン: Jenkinsジョブ、GitHub Actionsワークフロー、GitLabパイプライン
ソース コード: リポジトリ、Dockerfile、コミットSHA、作成者
所有者: チームのSlackチャンネル、オンコールローテーション、JIRAプロジェクト
Wizがハードニング済みイメージの機会を特定し、優先順位付けする方法
ハードニング済みイメージを入手することは、組織を保護するための長い道のりの始まりにすぎません。幸いにも、すべてのステップ、障害、そして終わりのないセキュリティの戦いをたった一人で乗り越える必要はありません。より優れた、よりシンプルな方法があります： Wiz 。
WizOS イメージ は、コンテナ化されたアプリケーション向けに安全で本番環境ですぐに利用可能な基盤を提供し、脆弱性（CVE）プロファイルをほぼゼロに抑えた、セキュリティを強化した最小限のイメージを実現します。すべてのリリースには署名が付与され、来歴を証明するための SBOM が含まれています。イメージは Wiz によって SLA のもとで継続的に管理されるため、開発者の修正負担が軽減されます。
Wiz セキュリティグラフ は、イメージの CVE をネットワーク露出、アイデンティティ、およびデータの機密性と関連付けることで、安全ではないイメージを一目で特定し、最も緊急性の高い修正を優先的に行えるようにします。双方向のコードからクラウドへのトレーサビリティにより、どのサービスがイメージをビルドしたか、誰が所有しているか、そしてデプロイ前にポリシーがどのように適用されているかをチームが把握するために必要なすべての情報が提供されます。
Wiz のコンテナイメージインベントリ により、すべてのコード、クラウド、レジストリにわたるすべてのイメージが確実に把握されます。チームは最も脆弱性の高いイメージを素早く特定し、WizOS などのセキュリティ強化された代替イメージへの移行を優先的に進めることができます。
詳細についてご確認ですか？ デモに登録 して、Wiz がクラウドで構築および実行するすべてのものをどのように保護できるかをご自身の目でお確かめください！
コンテナセキュリティのデモをリクエスト
Wiz がどのようにコンテナの脆弱性をスキャンするか、また WizOS ベースイメージによって CVE の数をほぼゼロまで削減できる方法を実際にご覧ください。
