コンテナ技術は現代のアプリケーション開発・運用に欠かせないものとなりましたが、コンテナを運用する上で「セキュリティ」と「イメージサイズ」は常に大きな課題として立ちはだかります。

あなたのコンテナイメージは本当に安全で、そして最小限に保たれていますか？

多くの開発者は、手軽さからコンテナをroot（管理者）権限で実行し、また開発やデバッグに不要なOSパッケージをそのまま含めてしまいがちです。

これが、セキュリティリスクの増大と、イメージサイズの肥大化を招く原因となります。

この記事では、この課題を解決するための Unprivileged（非特権ユーザー実行）とDistroless（ディストロレス）イメージについて、その概念から実践的な使い方、そして運用上の注意点までを解説します。

そもそも「Unprivileged」と「Distroless」とは何か？

1. Unprivileged (非特権ユーザー実行) とは？

Unprivileged実行とは、「最小特権の原則」をコンテナで実践することです。

• 定義
  コンテナ内のメインプロセスをrootユーザー（UID 0）ではなく、一般ユーザー（非特権ユーザー）として実行すること。
• メリット
  コンテナが何らかの理由で侵害されたり、エスケープ（コンテナの外側にあるホストOSへの侵入）が試みられたりした場合でも、プロセスが持つ権限が最小限に抑えられます。
  これにより、ホストシステムへの影響範囲を劇的に制限できます。
• 実現方法
  Dockerfile内でUSER命令を使用して、コンテナの実行ユーザーを切り替えます。

2. Distroless (ディストロレス) イメージとは？

Distrolessイメージとは、セキュリティとサイズを極限まで追求したベースイメージです。

• 定義
  OSディストリビューション（Linux）の要素、具体的にはbash、apt、lsといった一般的なシェルやパッケージ管理ツールを意図的に含めない、アプリケーション実行に必要な最小限のランタイムとライブラリのみで構成されたコンテナイメージです。
• 「通常のイメージ」との違い
  通常のイメージ（例: ubuntu:latest）には多くの汎用ツールが含まれていますが、Distrolessイメージにはそれらが一切含まれていません。デバッグツールさえないため、その名（Distro-less = ディストリビューションがない）が示す通り、極めて軽量です。

Unprivileged & Distroless を組み合わせるメリット

この二つのアプローチを組み合わせることで、コンテナの運用は次のレベルに引き上げられます。

1. 圧倒的なセキュリティ向上

• 攻撃対象領域の削減
  Distroless化により、イメージに含まれるバイナリやライブラリの数が最小限になります。
  その結果、既知の脆弱性（CVE）を持つ可能性のあるパッケージが激減し、攻撃対象となる領域を大幅に縮小します。
• 権限昇格リスクの低減
  Unprivileged実行により、仮にコンテナに侵入されても、攻撃者がホストシステムでroot権限を得るのが極めて困難になります。

2. イメージサイズの劇的な削減

• 不要なOSレイヤーやツールがないため、イメージサイズは通常のベースイメージに比べて数百MB単位で削減されることがあるらしい
• これにより、レジストリへのプッシュ/プル時間が短縮され、デプロイ時間の高速化、そしてストレージコストの削減につながります。

3. ビルド時間の短縮と効率化

ベースイメージが小さくなることで、CI/CDパイプラインでのダウンロード時間が短縮され、コンテナのビルドプロセス全体が効率化されます。

Unprivileged & Distroless なコンテナの使い方

Unprivileged & Distrolessを実現する最も一般的な方法は、マルチステージビルドを利用することです。

1. Distroless イメージの基本構造

1. Build Stage
   開発に必要なコンパイラ、パッケージマネージャなどを含む通常のイメージ（例: golang:latest, node:latest）を使い、アプリケーションのビルドや依存関係のインストールを行います。
2. Final Stage
   Distrolessイメージをベースとし、Build Stageで生成された最終的なバイナリや必要なランタイムファイルだけをコピーします。

2. Unprivileged実行の設定

Distrolessイメージの多く（例: gcr.io/distroless/...）は、セキュリティのため、デフォルトで非rootユーザー（例: nonroot）が設定されています。

もしご自身でベースイメージから構築する場合、Dockerfileに以下のコマンドを追加してユーザーを切り替えます。

# ユーザーを作成し、パーミッションを設定
RUN adduser --disabled-password --gecos "" appuser

# 実行ユーザーを一般ユーザーに切り替える
USER appuser

運用上の注意点：非特権ユーザーとポート番号の壁

UnprivilegedコンテナをECS（または任意のLinuxホスト）で運用する際、セキュリティの恩恵と引き換えに、ある実用上の課題に直面します。

1. ポート1024未満のバインドはroot権限が必要

Linux OSのセキュリティ原則により、Webサーバーなどで一般的に使われるポート番号1024未満（ウェルノウンポート、例: HTTPの80、HTTPSの443）にバインドするには、root権限（特権）が必要です。

あなたがECSでUnprivilegedかつDistrolessなNginxイメージを使った際、Nginxがデフォルトで80番ポートを使おうとすると、権限がないため「Permission Denied」といったエラーが発生し、コンテナの起動に失敗してしまいます。

2. ECS/Fargate環境での具体的な解決策

この問題を解決しつつ、Unprivilegedのセキュリティメリットを維持するには、以下の方法が最も推奨されます。

1. アプリケーション側のポート変更:Webサーバー（Nginxなど）の設定ファイルを変更し、1024番以上のポート（例: 8080、8081）で待ち受けるように設定を変更します。
2. ロードバランサー (ALB) でのポートマッピング:
   • ECS（Fargate）のタスク定義で、コンテナが使用するポートを8080などに設定します。
   • Application Load Balancer (ALB) を利用し、ALBは外部からのアクセスを80番（標準HTTP）で受けます。
   • ALBは、内部のECSタスクグループに対しては8080番でルーティングします。

これにより、コンテナ内部は非特権ユーザーで安全に運用され、外部ユーザーはポート番号を意識することなくWebサイトにアクセスできるようになります。

次世代コンテナの標準へ

UnprivilegedとDistrolessの組み合わせは、コンテナのセキュリティ基準とデプロイ効率を大きく引き上げる、次世代コンテナの標準パターンです。

• Distroless: 攻撃対象領域とイメージサイズを最小化。
• Unprivileged: 権限昇格リスクを最小化。

特にECSなどの本番環境で運用する際は、ポート1024未満の制限に注意を払い、ロードバランサーを活用して安全かつ効率的な構成を構築しましょう。

あなたのプロジェクトも、今日からこの強力なセキュリティパターンに移行してみませんか？

「ALBでHTTPS化したのに、なぜ後ろにいるECSコンテナはポート80（HTTP）のままで通信できるんだろう？」

この一見不思議な挙動は、ALBが持つ2つの重要な役割を理解することで、スッキリと解決します。今回は、このALBの「魔法」の仕組みを、セキュリティグループの設定から紐解いていきましょう。

最終的な構成：安全な3層アーキテクチャ

まず、私たちが目指すのは、セキュリティと可用性のベストプラクティスに基づいた、以下のような3層アーキテクチャです。

• Web層: ALBがインターネットからのリクエストをすべて受け付けます。
• AP層: ECSコンテナがプライベートな領域でアプリケーションを動かします。
• DB層: RDSがさらに内側のプライベートな領域でデータを安全に保管します。

この構成のセキュリティの肝は「ECSはALBからの通信しか受け付けない」というルールです。これを実現するのが、次に説明するセキュリティグループです。

門番の役割を担う「セキュリティグループ」

セキュリティグループは、リソースのドアを守る「バーチャルな門番」です。今回は3人の門番を配置します。

1. ALBの門番: インターネットからの訪問者（ポート80, 443）を全員受け入れます。
2. ECSの門番: ALBの門番から紹介された人（ALBからのトラフィック）だけを通します。それ以外の人は全員お断りです。
3. RDSの門番: ECSの門番から紹介された人（ECSからのトラフィック）だけを通します。

この連携により、たとえ攻撃者がECSに直接アクセスしようとしても、門前払いされる仕組みが完成します。

ALBがこなす2つの全く異なる仕事

さて、ここからが本題です。ユーザーがhttp://でアクセスしてきた時に、ALBとコンテナの間で何が起きているのでしょうか。実は、これは2段階の独立した処理になっています。

ポイントは役割が2つ存在するということです。

ブラウザへの「リダイレクト指示」

最初のやり取りは、ユーザーのブラウザとALBの間だけで完結します。

1. ユーザー: ブラウザで http://example.com (ポート80) にアクセス。
2. ALB (ポート80の受付係): リクエストを受け取ると、中身は見ずにこう応答します。「すみません、こちらの窓口は安全ではありません。向かいにある安全な443番の窓口へ行き直してください」。これがHTTP 301リダイレクトです。

この時点では、リクエストはまだECSコンテナには一切届いていません。

ステップ2：コンテナへの「リクエスト転送」

ブラウザはALBからの指示に従い、今度は最初から安全な窓口へ向かいます。

1. ユーザー: ブラウザが自動的に https://example.com (ポート443) に新しいリクエストを送信します。
2. ALB (ポート443の受付係):
   • 暗号化されたリクエストを受け取り、持っているSSL証明書を使って通信を復号します（SSL/TLS終端）。
   • 安全な平文になったリクエストを、宛先であるECSコンテナのポート80へ転送（フォワード）します。
3. ECSコンテナ (ポート80): ALBから来た通常のHTTPリクエストを受け取り、処理を実行します。

このように、ALBはユーザーを正しい入口へ案内する「案内係」の仕事と、リクエストを内部の担当者へ届ける「取次係」の仕事という、2つの全く異なる役割をこなしているのです。

コンテナからすれば、常にALBという信頼できる取次係から、暗号化が解かれた分かりやすいリクエストが届くだけなので、ポート80で待ち受けていれば良い、というわけです。

非常に便利ですね。。

CDKの実装

SecurityGroup の実装

// ALB用セキュリティグループ
const albSecurityGroup = new ec2.SecurityGroup(this, 'AlbSg', { vpc });
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(80), 'Allow HTTP');
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(443), 'Allow HTTPS');

// ECS用セキュリティグループ
const ecsSecurityGroup = new ec2.SecurityGroup(this, 'EcsSg', { vpc });
// ALBからの通信のみを、コンテナのポート80で許可
ecsSecurityGroup.addIngressRule(
    albSecurityGroup,
    ec2.Port.tcp(80),
    'Allow traffic only from ALB'
);

ALBリスナー

// ALB本体を作成
const alb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
    vpc,
    internetFacing: true,
    securityGroup: albSecurityGroup,
});

// HTTPリスナー (ポート80): HTTPSへリダイレクトするだけ
alb.addListener('HttpListener', {
    port: 80,
    defaultAction: elbv2.ListenerAction.redirect({
        protocol: 'HTTPS',
        port: '443',
        permanent: true,
    }),
});

// HTTPSリスナー (ポート443): ECSへリクエストを転送する
alb.addListener('HttpsListener', {
    port: 443,
    certificates: [certificate], // ACMで発行した証明書
    defaultAction: elbv2.ListenerAction.forward([ecsTargetGroup]), // ECSのターゲットグループ
});

まとめ

• ALBのHTTP→HTTPSリダイレクトは、「リダイレクト指示」と「リクエスト転送」の2段階で行われる。
• SSL/TLSによる暗号化・復号の処理はALBがすべて肩代わりしてくれる（SSL/TLS終端）。
• コンテナは、ALBから転送されてくる暗号化されていないHTTPリクエストを受け取るだけで良い。
• セキュリティグループを正しく設定することで、この安全な通信経路が完成する。

役割が2つあることが分からなければ理解できなかったなぁ。

参考記事

今日は、僕がAWS環境で構築したWEBアプリケーションがDoS攻撃を受け、サーバーダウンに至った際の障害対応について、その全貌を語りたいと思います。

特に、ALB（Application Load Balancer）の思わぬ落とし穴が原因だったという、衝撃の事実を皆さんに共有します。
同じような問題で悩んでいる方、これからAWS環境を構築する方は、ぜひ参考にしてください。

障害内容

ある日突然、ALB配下のアプリケーションサーバーがDoS攻撃によりダウンしてしまいました。

緊急事態発生です！確認すると、アクセスのあったIPはまさかのオレゴンリージョンから。

僕が管理しているアプリケーションサーバーは東京リージョンにあるため、なぜ遠く離れたオレゴンから大量のアクセスが来ているのか、この時点では全く見当がつきませんでした。

調査内容

まずは手がかりを求めて、nginxやアプリケーションのアクセスログ、エラーログを徹底的に漁りました。
しかし、一向に決定的な手がかりが見つかりません。

そんな中、アクセスログを注意深く見ていたところ、ある異変に気づきました。
通常、僕たちが意図的に公開している EIP で抑えているグローバルIPとは全く関係ないIPアドレスから、アプリケーションサーバーにアクセスが到達しているのです。

そこで、すかさずdigコマンドを実行してみると、やはり先ほどのEIPとは無関係のIPアドレスが確認できました。
しかし、「なぜ、僕たちに関わりのないIPがアプリケーションへアクセスを流しているんだ？」

この疑問が頭から離れません。ルーティングテーブルや他のAWSリソースを調べても問題は見当たらず、「うーん、わからない…」という状況が3時間ほど続きました。

精神的に疲弊し始めたその時、ふとALB（Application Load Balancer）のルールに問題があるのではないかという考えがよぎりました。そして、確認してみると…ビンゴです！

ALBのデフォルトルールが、アプリケーションサーバーが所属するターゲットグループにトラフィックを転送する設定になっていたのです。

そして、Route 53のAレコードにALBのエイリアスを指定していることで、ALBに紐づくサブネットのグローバルIPでもアクセスが可能になっている仕様もここで理解しました。

つまり、ALBのグローバルIPに直接アクセスが入ると、意図せずアプリケーションサーバーへ流れてしまう状態になっていたのです。

この瞬間、「これで勝ち確定！」と心の中で叫びましたね。

対策

今回の障害を受けて、最も効果的な対策はALBのデフォルトルールを適切に設定することです。意図しないアクセスをアプリケーションサーバーに流さないために、以下のように設定することをおすすめします。

• デフォルトルールで固定レスポンスを返す:レスポンスコード: 503 Service Unavailable
• 本文: 許可されていないリクエストです

これにより、正規のドメインを通さないALBへの直接アクセスはアプリケーションサーバーに到達せず、DoS攻撃のリスクを大幅に低減できます。

もし、プロジェクトの制約上、固定レスポンスを返すのが難しい場合は、少なくともアプリケーションサーバーへリクエストを流さない設定にすることが重要です。例えば、別のダミーのターゲットグループを指定するか、アクセスを拒否するアクションを設定することも検討してください。

調査に使ったもの

nginx のアクセスログ

該当のリクエストがあった時間帯のアクセスを dig ることで出どころのIP等がわかります。

IPでどの辺りの地域かが判別できたり、content-type を元に BOT からのリクエストなのかがわかったりします。一旦、アクセスログを覗いてみましょう。

2025年に入って、生成AIからのリクエストが頻繁に来ている事を確認できているのでアクセスログを覗いてみると面白いですよ。

VPC フローログ

AWS のサービスです。VPC内の監視ができるのでかなり有用です。。使っていないプロジェクトは導入オススメします。

VPC、サブネット、またはネットワークインターフェイスのフローログを作成できます。サブネットまたは VPC のフローログを作成する場合、そのサブネットまたは VPC 内の各ネットワークインターフェイスが監視されます。

監視されるネットワークインターフェイスのフローログデータは、フローログレコードとして記録されます。これは、トラフィックフローについて説明するフィールドで構成されるログイベントです。詳細については、「フローログレコード」を参照してください

フローログの基礎

コマンド類

nslookup

DNS が正しく設定されているか、IPがEIPと同値かに使用した、

dig

ドメイン名に関する詳細な情報を取得するためのツールです。今回はDNSの設定が正しいか検証するために使用しました。

tail

アクセスログを掘り起こすのに使用しました。リアルタイム監視を後輩に見せたら尊敬されたのでドヤりたい人使ってください。（後輩が可愛いだけ

まとめ

誰でも簡単に作れるようになっているのがAWSの特徴ですが、結果として穴ができてしまうことが多々あるので皆さんの環境も見てみましょう。