コンテナレジストリの心臓部を守る：IAMの深淵と脆弱性スキャンパイプラインの極意
諸君、今日のテーマは、サイバーセキュリティの最前線で戦う我々にとって、もはや呼吸と同じくらい当たり前になりつつあるコンテナ技術、その生命線とも言える「コンテナレジストリ」の防衛についてだ。多くの組織が、アジリティとスケーラビリティを追い求めるあまり、このレジストリという心臓部に盲点を抱えがちだ。しかし、攻撃者はその盲点を決して見逃さない。彼らは、最も油断した瞬間に、最も効果的な一撃を仕掛けてくる。
「イメージは安全だ」「CI/CDパイプラインで自動的にスキャンしてるから大丈夫」――そんな甘い幻想は、今すぐ捨て去るべきだ。我々は、常に最悪のシナリオを想定し、その一歩先を行く防御を構築しなければならない。
1. 攻撃者の視点：なぜコンテナレジストリが狙われるのか
コンテナイメージは、アプリケーションとその実行に必要なすべての依存関係をパッケージ化したものだ。これが一度改ざんされればどうなるか？想像してみてほしい。
- サプライチェーン攻撃の温床: 悪意のあるコードが注入されたイメージがレジストリにプッシュされれば、それをプルしてデプロイするすべての環境が感染源となる。オープンソースの脆弱性だけでなく、意図的に仕込まれたバックドアやマルウェアが、サプライチェーン全体を汚染する。
- 権限昇格の足がかり: レジストリへの不正アクセスは、通常、CI/CDパイプラインのサービスアカウントや開発者の認証情報を通じて行われる。これらの認証情報が盗まれれば、レジストリだけでなく、そのアカウントが持つ他の権限（例えば、Kubenetesクラスターへのデプロイ権限）も悪用され、システム全体が掌握される危険がある。
- 永続的な侵入経路: 一度レジストリに悪意のあるイメージが置かれれば、それが削除されない限り、永続的な侵入経路として機能し続ける。デプロイされるたびに、攻撃者の支配下にあるコンテナが生成されるのだ。
我々が狙うべきは、この攻撃の連鎖を断ち切るための「厳格なアクセス制御」と「継続的な脆弱性スキャン」の融合だ。
2. IAMの深淵：レジストリアクセス制御の極意
一般的なIAMポリシーは、単に「誰が何にアクセスできるか」を定義するだけだ。だが、それでは不十分だ。我々が目指すのは、攻撃者がどんな手を使ってきても、その活動を封じ込めるレベルの「条件付きアクセス制御」だ。
2.1. 最小権限の原則を超えて：条件付きアクセスの実践
AWS ECR (Elastic Container Registry) を例にとろう。レジストリへのアクセスは、プッシュとプルで厳密に分離すべきだ。そして、それぞれの操作に対して、単なるecr:PutImageやecr:GetDownloadUrlForLayerといったアクション許可だけでなく、誰が、どこから、どのような条件でその操作を行うのかを細かく指定する。
プッシュ権限の厳格化
イメージをプッシュする主体は、通常CI/CDパイプラインのサービスアカウントに限られるべきだ。開発者が直接本番環境のレジストリにプッシュするような運用は、即刻見直すべきである。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCiCdPushImages",
"Effect": "Allow",
"Action": [
"ecr:CompleteLayerUpload",
"ecr:UploadLayerPart",
"ecr:InitiateLayerUpload",
"ecr:BatchCheckLayerAvailability",
"ecr:PutImage"
],
"Resource": "arn:aws:ecr:REGION:ACCOUNT_ID:repository/YOUR_REPOSITORY_NAME",
"Condition": {
"StringEquals": {
// CI/CDパイプラインが実行されるAWSのIAMロールARNに限定する
// 例: GitHub ActionsのOIDCプロバイダー経由でAssumeRoleしたロール
"aws:PrincipalArn": "arn:aws:iam::ACCOUNT_ID:role/github-actions-oidc-role"
},
"BoolIfExists": {
// MFAが必須の操作であれば、MFAの有無をチェック（開発者の手動操作の場合など）
// CI/CDパイプラインの場合は通常不要だが、より厳格な運用では検討の余地あり
"aws:MultiFactorAuthPresent": "true"
},
"StringLike": {
// プッシュされるイメージタグの命名規則を強制する
// 例: バージョン番号やコミットハッシュが含まれることを保証
"ecr:ImageTag": [
"v*-*",
"main-*"
]
},
"IpAddress": {
// CI/CDパイプラインが実行されるネットワークのIPアドレス範囲に限定する
// これにより、不正な場所からのプッシュをブロック
"aws:SourceIp": "192.0.2.0/24"
}
}
}
]
}このポリシーでは、以下の条件を課している。
aws:PrincipalArn: プッシュを許可するIAMロールを厳密に指定。GitHub Actionsなどの外部CI/CDと連携する場合は、OpenID Connect (OIDC) を利用して、一時的なAWS認証情報を取得するIAMロールに限定する。aws:MultiFactorAuthPresent: 開発者が直接操作する場合など、MFAが必須の状況を強制。CI/CDパイプラインには通常不要だが、手動の緊急対応などを考慮するなら検討の余地がある。ecr:ImageTag: イメージタグの命名規則を強制。これにより、一貫性のない、あるいは意図しないタグ付けを防ぐ。攻撃者が既存のタグを上書きしようとする試みに対する第一歩の防御にもなる。aws:SourceIp: プッシュ元のIPアドレスを制限。CI/CDパイプラインがデプロイされるVPCや、信頼できるネットワークのIPアドレス範囲に限定することで、ネットワークレイヤでの防御を強化する。
プル権限の厳格化
イメージをプルする主体は、Kubernetesクラスターのノードや、Lambda関数、ECSタスクなど、デプロイされる環境のサービスアカウントに限定すべきだ。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEcsTasksPullImages",
"Effect": "Allow",
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "arn:aws:ecr:REGION:ACCOUNT_ID:repository/YOUR_REPOSITORY_NAME",
"Condition": {
"StringEquals": {
// ECSタスクが使用するIAMロールARNに限定する
"aws:PrincipalArn": "arn:aws:iam::ACCOUNT_ID:role/ecs-task-execution-role"
},
"StringNotLike": {
// プルを許可しないイメージタグを定義する（例: "latest"タグのプルを禁止し、特定バージョンのみを強制）
// これは脆弱なイメージが意図せずデプロイされるのを防ぐ一助となる
"ecr:ImageTag": ["latest"]
},
"StringEqualsIfExists": {
// ECR VPCエンドポイント経由でのアクセスを強制する
// これにより、パブリックインターネットからのアクセスを完全に遮断
"aws:SourceVpce": "vpce-0123456789abcdef0"
}
}
}
]
}ここでは、
aws:PrincipalArn: ECSタスク実行ロールなど、本番環境でイメージをプルする特定のIAMロールに限定。ecr:ImageTag:latestタグのような曖昧なタグの使用を禁止し、特定のバージョンタグのみを許可することで、意図しない古い（あるいは脆弱な）イメージのデプロイを防ぐ。これは非常に重要だ。aws:SourceVpce: VPCエンドポイント経由でのアクセスを強制。これにより、ECRへの通信がAWSのバックボーンネットワーク内にとどまり、パブリックインターネットからの意図しないアクセスや盗聴のリスクを排除する。これは、通信プロトコル仕様の欠陥を狙った中間者攻撃などに対する強力な防御層となる。
2.2. 耐量子暗号への視座
現在のTLSやPKIは、公開鍵暗号の堅牢性に依存している。しかし、将来的な量子コンピュータの登場は、この根幹を揺るがしかねない。認証情報やイメージの整合性を担保するデジタル署名が、量子コンピュータによって破られる可能性は、もはやSFではない。
我々が今できることは、まずは鍵管理の徹底だ。短期的な認証情報の利用（OIDCのような仕組み）、定期的な鍵のローテーション、そしてハードウェアセキュリティモジュール (HSM) の利用など、現在の技術で可能な最高の防御を施すこと。そして、耐量子暗号の動向を注視し、将来的な移行計画を立てておくことこそ、真のホワイトハッカーの責務である。
3. イメージ脆弱性スキャンパイプラインの構築：防御の自動化と深化
アクセス制御が「誰が何をできるか」を定義するなら、脆弱性スキャンは「プッシュされるものが何であるか」を評価する。これはCI/CDパイプラインに深く組み込むべき不可欠なプロセスだ。
3.1. プッシュトリガー型スキャンの原則
イメージがレジストリにプッシュされるたびに、自動的に脆弱性スキャンがトリガーされるパイプラインを構築する。これにより、脆弱なイメージがデプロイされる前に、その存在を検出し、デプロイをブロックすることが可能になる。
脆弱性スキャナーの選定と限界
Trivy, Clair, Aqua Security, Snyk など、多くの脆弱性スキャンツールが存在する。これらは基本的に、イメージ内のOSパッケージやライブラリのバージョンを解析し、既知のCVE (Common Vulnerabilities and Exposures) データベースと照合することで脆弱性を検出する。
しかし、ここに盲点がある。
- 未知のゼロデイ: 既知のCVEデータベースに登録されていないゼロデイ脆弱性には対応できない。
- 低レイヤの脆弱性: OSカーネルの低レイヤのメモリ挙動に起因する脆弱性（バッファオーバーフロー、Use-After-Freeなど）や、特定の通信プロトコル実装の欠陥などは、静的解析だけでは発見が困難な場合が多い。これらはランタイムセキュリティツールやファジング、あるいは詳細なパケット構造解析による異常検知が必要となる。
- 設定ミス: アプリケーションやミドルウェアの設定ミスに起因する脆弱性（デフォルトパスワード、誤ったパーミッションなど）も、静的スキャンでは見落とされがちだ。
- サプライチェーンの深さ: ベースイメージのさらにその奥にある依存関係の依存関係（推移的依存関係）まで完全に追跡し、SBOM (Software Bill of Materials) を生成しきれない場合もある。
これらの限界を理解した上で、可能な限り多角的な防御を構築する必要がある。
3.2. GitHub ActionsとECR、Trivyを連携したパイプライン例
ここでは、GitHub Actionsを使って、イメージビルド後にTrivyで脆弱性スキャンを行い、問題があればプッシュをブロックする基本的なパイプラインを構築する。
name: Build and Scan Docker Image
on:
push:
branches:
- main # mainブランチへのプッシュ時に実行
env:
AWS_REGION: ap-northeast-1 # AWSリージョンを設定
ECR_REPOSITORY: your-app-repository # ECRリポジトリ名を設定
IMAGE_TAG: ${{ github.sha }} # イメージタグをコミットSHAにする
permissions:
id-token: write # OIDC認証のために必要
contents: read # コードをチェックアウトするために必要
jobs:
build-and-scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::ACCOUNT_ID:role/github-actions-oidc-role # OIDCでAssumeRoleするIAMロール
aws-region: ${{ env.AWS_REGION }}
- name: Login to Amazon ECR
id: login-ecr
uses: aws-actions/amazon-ecr-login@v2
- name: Build Docker Image
run: |
docker build -t ${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} . # Dockerイメージをビルド
docker tag ${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} # ECR用のタグを付与
- name: Scan Docker Image with Trivy
uses: aquasecurity/trivy-action@master
with:
image-ref: ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} # スキャン対象のイメージ
format: 'table' # 結果表示形式
exit-code: '1' # 脆弱性が見つかった場合にCIを失敗させる
ignore-unfixed: true # 未修正の脆弱性は無視（運用ポリシーに応じて変更）
severity: 'CRITICAL,HIGH' # CRITICALまたはHIGHの脆弱性でCIを失敗させる
- name: Push Docker Image to ECR
if: success() # Trivyスキャンが成功した場合のみプッシュ
run: |
docker push ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} # ECRにイメージをプッシュ
- name: Generate SBOM (Optional but Recommended)
run: |
# Syftなどを利用してSBOMを生成し、Artifactとして保存する
# syft ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} -o spdx-json > sbom.spdx.json
# echo "SBOM generated for ${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }}"
# uses: actions/upload-artifact@v3 # SBOMファイルをArtifactとしてアップロードする場合
# with:
# name: sbom-${{ env.ECR_REPOSITORY }}-${{ env.IMAGE_TAG }}
# path: sbom.spdx.jsonこのワークフローのポイントは以下の通りだ。
- OIDC認証:
aws-actions/configure-aws-credentialsアクションで、GitHub Actionsが直接AWSの認証情報を持つのではなく、OIDCプロバイダーを経由して一時的なIAMロールの認証情報を取得する。これにより、認証情報の漏洩リスクを最小限に抑える。 - ビルドとタグ付け: イメージをビルドし、ECRへのプッシュに必要なタグを付与する。タグにはコミットSHAを用いることで、どのコミットからビルドされたイメージであるかを明確にする。
- Trivyスキャンと
exit-code:aquasecurity/trivy-actionを使ってイメージをスキャンする。特に重要なのはexit-code: '1'だ。これにより、指定した深刻度（CRITICAL,HIGH）の脆弱性が発見された場合、GitHub Actionsのワークフローが失敗し、次のステップ（ECRへのプッシュ）が実行されなくなる。これが「脆弱なイメージのプッシュ阻止」の肝となる。 - 条件付きプッシュ:
if: success()句により、Trivyスキャンが成功した場合のみイメージがECRにプッシュされる。 - SBOM生成（推奨）:
syftなどのツールを使ってSBOM (Software Bill of Materials) を生成し、Artifactとして保存することで、イメージの構成要素を可視化し、将来的な脆弱性対応や監査に役立てることができる。これはサプライチェーン攻撃に対する透明性を確保する上で極めて重要だ。
3.3. 生成AIとプロンプトインジェクションへの防御層
最近は、DockerfileやCI/CDのスクリプト自体も生成AIによって生成されるケースが増えてきている。ここで注意すべきは、生成AIが必ずしもセキュリティベストプラクティスに従ったコードを生成するとは限らない点、そしてプロンプトインジェクションの脅威だ。
攻撃者が悪意のあるプロンプトをAIに与え、意図的に脆弱な設定やバックドアを含むDockerfileを生成させ、それをパイプラインに取り込ませる、といったシナリオも考慮に入れるべきだ。
これに対する防御層としては、以下の対策が考えられる。
- AI生成コードの厳格なレビュー: AIが生成したDockerfileやCI/CDスクリプトは、人間による徹底的なレビューとセキュリティ専門家による監査を必須とする。
- 静的コード解析 (SAST): AI生成コードに対して、既存のSASTツールを適用し、既知の脆弱なパターンや設定ミスを自動的に検出する。
- テンプレートとガードレール: AIに自由なコード生成を許すのではなく、セキュリティが担保されたテンプレートを提供し、その範囲内でカスタマイズさせる。また、特定の危険な操作やパターンを検出・ブロックするガードレールを設ける。
- セキュリティポリシーの自動適用: CI/CDパイプライン上で、イメージビルドやデプロイ前に、組織のセキュリティポリシーに準拠しているかを自動でチェックするゲートを設ける。
4. 監査と継続的改善：攻撃者の思考を先回りする
セキュリティは一度構築したら終わりではない。常に変化する脅威に対応するためには、継続的な監査と改善が不可欠だ。
4.1. ログとモニタリングの深化
- CloudTrailログ: ECRへのすべてのAPIコールを記録し、不審な操作（例えば、CI/CDパイプライン以外のIAMロールからの
PutImage試行）がないかを監視する。特にerrorCodeやerrorMessageフィールドを注目し、失敗した不正アクセスの試みを早期に検知する。 - VPC Flow Logs: ECR VPCエンドポイントへのトラフィック、あるいはCI/CD環境とECR間のネットワークトラフィックを監視し、異常な通信パターン（大量のデータ転送、未知のIPからのアクセス試行など）を検出する。
- スキャン結果の履歴管理: 脆弱性スキャン結果を履歴として保存し、時間の経過とともに脆弱性がどのように変化しているかを追跡する。新たな脆弱性が発見された場合に、影響を受けるイメージやアプリケーションを迅速に特定できるようにする。
4.2. レッドチーム演習とペネトレーションテスト
最も効果的な監査は、実際に攻撃者の視点に立ってシステムを試すことだ。
- IAMロールの権限昇格: CI/CDパイプラインのIAMロールが侵害されたと仮定し、その権限を使ってどこまで悪事ができるか（例: ECR上のイメージ改ざん、別のAWSリソースへの不正アクセス）を試す。
- イメージ改ざんシナリオ: 脆弱な開発環境からレジストリへ不正なイメージをプッシュする、あるいは既存のイメージにバックドアを仕込むといったシナリオを想定し、防御が機能するかを検証する。
- パイプラインの脆弱性: GitHub Actionsのワークフローファイル自体に脆弱性がないか（例: 機密情報の漏洩、コマンドインジェクション）を確認し、それがレジストリへのアクセス権限悪用につながらないかを検証する。
結び：防御は多層的に、思考は攻撃的に
コンテナレジストリのセキュリティは、単なる技術的な設定作業ではない。それは、攻撃者が何を狙い、どのように侵入しようとするのかを深く理解し、その一歩先を行くための戦略的な思考の結果だ。
我々は、IAMによる厳格なアクセス制御、CI/CDパイプラインに組み込まれた自動脆弱性スキャン、そして継続的な監査と改善を通じて、多層的な防御を構築しなければならない。低レイヤのメモリ挙動に潜むゼロデイから、通信プロトコルの巧妙な欠陥、そして将来の耐量子暗号の課題、さらには生成AIの悪用まで、あらゆる脅威を視野に入れ、常に警戒を怠ってはならない。
「安全」という言葉は、我々の辞書には存在しない。あるのは「より強固な防御」への飽くなき探求心だけだ。今日もまた、世界のどこかで新たな脆弱性が生まれ、新たな攻撃が試みられている。我々は、その最前線に立ち続けるのだ。
コメント