Data in TransitのEncryption Strategy

1. HTTPS エンドポイントが1つあっても全経路暗号化とは限らない

転送中の暗号化では、データが通る経路をホップ単位で確認します。

クライアント
  │ HTTPS
  ▼
エッジ / ロードバランサー
  │ HTTP ?
  ▼
アプリケーション
  │ TLS ?
  ▼
バックエンドサービス

フロントエンドがHTTPSでも、バックエンド区間がHTTPなら「全ネットワークホップを暗号化」という要件は満たしません。

2. データフローをホップへ分解する

アーキテクチャ図上の矢印をそのまま「暗号化済み」とみなさず、各接続を独立して評価します。

3. 全ホップ暗号化と中間復号禁止は別要件

次の2つは同じではありません。

終端 + 再暗号化クライアント ─TLS─> ロードバランサー ─TLS─> アプリケーションパススルー
クライアント ─────────TLS────────> アプリケーション中継点で復号しない

4. プライベート接続は転送中の暗号化を代替しない

プライベートサブネット、AWS PrivateLink、VPC リンク、Transit Gateway、AWS Direct Connectなどでパブリックインターネットを避けても、アプリケーションプロトコルがHTTPならTLSによるペイロード暗号化とは別です。

プライベート経路
≠
TLS 暗号化

要件が「プライベートネットワーク内を含むすべてのホップを暗号化」であれば、プライベート接続とは別にTLSを適用します。

5. ACM証明書は配置したホップだけを成立させる

AWS Certificate Managerで証明書を管理してフロントエンドTLSを成立させても、それだけでバックエンドTLSまで完成したとは判断しません。

クライアント
  │ HTTPS
  ▼
ALB
  ↑ ACM証明書
  │
  │ バックエンド区間は別確認
  ▼
アプリケーション

証明書管理の知識は、各TLS終端ポイントへ適用します。1枚の証明書が複数ホップを自動的に保護するわけではありません。

6. CloudFrontはビューワーとオリジンを別ホップとして確認する

CloudFrontではビューワー側とオリジン側は別接続です。

ビューワー ─HTTPS─> CloudFront
                     │
                     │ HTTPS ?
                     ▼
                   オリジン

ビューワープロトコルポリシーがHTTPSのみでも、オリジンプロトコルポリシーがHTTPならオリジン側は平文です。全ホップ暗号化要件ならオリジン側もHTTPSにします。

カスタムオリジンへHTTPS接続する場合は、CloudFrontがオリジン証明書の信頼性やドメイン名などを検証するため、TLS化だけでなくそのホップの信頼成立も確認します。

7. ALBではバックエンド暗号化とバックエンドの証明書検証を分ける

Application Load BalancerはHTTPS 対象を利用してバックエンド区間を暗号化できます。

クライアント ─HTTPS─> Aロードバランサー ─HTTPS─> 対象

ただしALBは対象証明書を検証しません。そのため、

バックエンドTLS 暗号化
≠
バックエンド証明書によるアイデンティティ検証

要件が「暗号化」だけなのか、「CA / ホスト名等によるバックエンドの証明書検証」まで求めるのかを分離します。

8. ALB バックエンドTLSポリシーはフロントエンドと同一とは限らない

フロントエンドリスナーがコンプライアンス要件を満たしていても、バックエンド接続が同じセキュリティポリシーを使うとは限りません。

ALBではバックエンドのセキュリティポリシーを独立して選択するのではなく、リスナーセキュリティポリシーのカテゴリに応じてAWS側がバックエンドポリシーを決定します。

フロントエンドのリスナーポリシー
        ↓
現在ALB 動作を確認
        ↓
バックエンドのセキュリティポリシー
        ↓
対象のプロトコル / 暗号スイートの互換性
        ↓
バックエンドTLS 要件成立？

具体的なポリシー名を固定暗記せず、現在サービス動作を確認します。

9. Amazon API Gateway フロントエンドHTTPSとプライベート統合は別

Amazon API GatewayのフロントエンドエンドポイントがHTTPSでも、プライベートバックエンドとの統合プロトコルは別に確認します。

クライアント ─HTTPS─> API ゲートウェイ
                     │
                     │ HTTP / HTTPS ?
                     ▼
                プライベートバックエンド

要件がバックエンドまでTLS必須なら、プライベート統合側でもHTTPS / TLSを明示的に成立させます。

10. リダイレクトとHTTPSのみを要件で分ける

要件が「アプリケーションデータはHTTPSへ誘導」でよいのか、「平文 HTTP 接続そのものを禁止」なのかで選択が変わります。

11. 証明書とTLS セキュリティポリシーを分ける

有効な証明書を配置しただけでは、TLS 1.2以上などのプロトコル要件は完成しません。

証明書
→ エンドポイントのアイデンティティ/ TLS成立要素

TLS セキュリティポリシー
→ TLS バージョン / 暗号スイートの許容範囲

コンプライアンス要件が明確なら、デフォルトに任せず対象サービスの現在のセキュリティポリシーとクライアント / バックエンド互換性を確認します。

12. 障害経路にも平文区間の抜けを残さない

通常時だけHTTPSでも、障害時にHTTPへフォールバックするなら「平文禁止」という要件は満たしません。

通常経路ロードバランサー ─HTTPS─> アプリケーション障害時経路ロードバランサー ─HTTP──> アプリケーション   ← 要件違反

ヘルスチェック、フォールバックリスナー、代替オリジン、復旧経路など、実際にトラフィックが通る可能性がある経路も確認します。

13. 候補比較

14. 判断フロー

転送中の暗号化要件
        ↓
必要なデータフローを列挙
        ↓
ホップへ分解
        ↓
各ホップでTLS必須？
        ↓
平文ホップあり？
        ↓
中継点での復号を許容？
        ↓
各ホップの証明書/ 信頼確認
        ↓
サービス固有TLS 動作確認
        ↓
TLS バージョン / 暗号スイート要件確認
        ↓
障害 / 代替経路確認
        ↓
平文区間の抜けなし
        ↓
要件成立

15. 混同ポイント

まとめ

転送中の暗号化
=
必要なデータフロー
+
ホップバイホップ TLS
+
終端要件
+
証明書/ 信頼
+
TLS セキュリティポリシー
+
障害時経路の検証

重要なのは「HTTPSを使っているか」ではなく、要件対象のすべての経路で平文区間の抜けがなく、必要な信頼 / TLSポリシーまで成立しているかです。