クラウドでは内部も設計対象になる

暗号化は、情報を守るための強力な技術である。しかし、暗号化されていることと、情報が安全に扱われていることは同じではない。通信内容が読みにくくなっていても、その通信がどこで平文になり、どこで複製され、どの権限で参照され、どの境界を越え、誰がその状態を説明できるのかが見えていなければ、安全性は十分に評価できない。暗号化は、情報を守る条件の一部であって、情報の扱い全体を自動的に正しくする仕組みではない。既稿では、暗号化だけでは情報は守れず、情報がどの経路を通り、どの段階で保護を失い、どの運用上の隙間から流出しうるのかを管理する必要があることを整理した[1]。

本稿で扱うのは、クラウド上の仮想ネットワーク内通信である。より具体的には、AWS 上で作られた VPC の内側にある通信を、HTTP のまま扱うのか、それとも TLS を使って暗号化するのかという問いである。ただし、本稿は、ロードバランサーからアプリケーションへ HTTPS で転送する設定手順を説明するものではない。対象にするのは、その選択が何を守り、何を守らず、どのような前提を置き、組織として何を説明可能にするのかという設計判断である。

この問いが分かりにくいのは、「内部通信」と「暗号化」という二つの言葉が、どちらも一見わかりやすいからである。内部通信と聞くと、外部から遮断された安全な場所での通信に見える。暗号化と聞くと、それだけで安全性が大きく高まるように見える。しかし、クラウドにおける内部は、物理的な部屋や配線ではなく、仮想ネットワーク、経路制御、権限、ロードバランサー、セキュリティグループなどの組み合わせによって作られる。暗号化もまた、通信内容を読ませにくくする働き、通信相手を確認する働き、改ざんを検出する働き、監査上の説明を可能にする働きが混ざって語られやすい。したがって、内部通信を暗号化するべきかという問いは、表面上は単純でも、実際には複数の判断を含んでいる。

結論を先に述べる。クラウドにおける暗号化の意味は、通信を読ませないことだけではない。重要なのは、どこまでを信頼し、どこからを検証し、どの例外を許し、その判断をどのように説明できる状態にするのかである。VPC 内通信を TLS で扱うかどうかという実務上の判断は、単に通信方式を選ぶ問題ではない。それは、クラウドにおける信頼境界をどこに引くのか、そしてその境界を技術、運用、監査の各層でどのように維持するのかという問題である。

1. 問いは「内部通信だから安全か」ではない

クラウド環境でしばしば生じる問いに、「VPC の内側で完結する通信まで暗号化する必要があるのか」がある。外部の利用者からロードバランサーまでは HTTPS にする。一方で、ロードバランサーからアプリケーションサーバー、コンテナ、内部サービスへ向かう通信は HTTP のままにする。この構成は珍しくない。外部から見える入口は暗号化されているため、一見すると十分に見える。さらに、通信が VPC の内側に閉じているなら、外部の第三者が簡単に盗聴できるわけではないという直感も働く。

しかし、この問いを「必要か不要か」という二択で扱うと、論理が粗くなる。第一に、クラウドの基盤が一定の保護を提供していることと、利用者が構成するアプリケーション通信の安全性が十分であることは同じではない。AWS は責任共有モデルを示しており、クラウド基盤の物理設備や仮想化層などは AWS が管理する一方、利用者が構成するアプリケーション、データ、アクセス制御、ネットワーク設定には利用者側の責任が残る[2]。第二に、利用者側の責任が残る以上、通信を暗号化しない判断にも、暗号化する判断にも、それぞれ説明すべき前提がある。つまり、クラウドの内側に置いたからといって、すべての安全性が自動的に保証されるわけではなく、逆に、暗号化すればすべての責任が消えるわけでもない。

この点を理解するには、VPC の「内部」という言葉を分解する必要がある。Amazon VPC は、利用者が定義する論理的に隔離された仮想ネットワークであり、従来のデータセンター内ネットワークに似た形で AWS リソースを配置できる[3]。ただし、そこにある内部は、物理的な部屋、単一の配線、同じスイッチにつながった機器の集まりではない。到達可能性は、サブネット、経路、ロードバランサー、セキュリティグループなどの制御によって構成される。セキュリティグループは、送信元、送信先、ポート、プロトコルを指定して通信を許可する境界であり、何が内側にあるかだけでなく、何と何が通信できるかを定義する[4]。

ここに一つ目の因果関係がある。VPC は論理的に隔離された空間であるため、外部インターネット上の任意の利用者が、その内部通信を直接見るわけではない。このため、古典的な意味での盗聴リスクは、むき出しのインターネット通信とは異なる。だが、そのことは、VPC 内通信を無条件に信頼してよいという結論を意味しない。なぜなら、実際の通信経路には、ロードバランサー、ターゲットグループ、コンテナ、仮想マシン、権限設定、ログ、運用者、監査要件が関与するからである。通信が外部から直接見えにくいことと、通信の扱いを組織として説明できることは別の問題である。

さらに二つ目の因果関係がある。内部通信を暗号化しない構成を選ぶと、運用は単純になる。証明書の発行、配布、更新、失効、監視、期限切れ対応を考えなくてよいからである。しかし、その単純さは、監査や組織標準の場面では別の負債になる。あとから「なぜこの区間だけ平文でよいのか」と問われたとき、脅威モデル、AWS 側の保護、通信経路、扱うデータ、例外承認を説明できなければ、技術的には問題が小さくても、統制上は弱い構成になる。したがって、内部通信を HTTP のままにする判断は、単に何もしないという判断ではなく、どの保護を AWS 基盤やネットワーク制御に委ね、どのリスクを受け入れるのかを明示する判断である。

観点	粗い問い	本稿で扱う問い
内部通信	VPC 内だから安全かどうかを問う。	VPC 内のどの経路を、どの制御で、どこまで信頼するのかを問う。
TLS	TLS を使っているかどうかを問う。	TLS が機密性、完全性、相手確認、監査説明のどれを担っているのかを問う。
責任	AWS の内側にあるから AWS が守ると考える。	AWS が守る層と利用者が設計する層を分けて考える。
監査	技術的に危険かどうかだけを見る。	危険の大きさに加えて、説明可能性、例外管理、組織標準との整合を扱う。

この表が示しているのは、判断対象を細かくしすぎることではない。むしろ、分解しなければ判断の根拠が失われるということである。VPC 内通信という一語には、通信経路、到達制御、暗号化の層、アプリケーションの責任、運用手順、監査上の説明が重なっている。TLS という一語にも、通信内容を読ませにくくすること、通信途中の改ざんを検出すること、通信相手を確認すること、転送時暗号化として説明することが重なっている。これらを分けずに「内部だから不要」または「暗号化すれば安全」と判断すると、どちらの結論も過剰に単純化される。

したがって、この章で固定したい前提は単純である。クラウドでは、内部という言葉だけでは安全性を説明できない。内部とは、自然に存在する安全地帯ではなく、複数の制御によって作られる境界である。そして、その境界をどこまで信頼し、どこから検証するかを決めることが、VPC 内通信における暗号化判断の出発点になる。

2. TLS は「安全な通信」という一語では足りない

次に分解すべきなのは、TLS という言葉である。HTTP は、要求と応答の意味、メソッド、状態コード、ヘッダーなどを定義するアプリケーション層の通信仕様である[5]。HTTPS は、HTTP を TLS の上で運ぶ構成であり、通信内容を経路上の第三者に読まれにくくし、途中で書き換えられた場合に検出しやすくし、通信相手を確認するための仕組みを組み合わせる。したがって、HTTPS は単に HTTP の後ろに S が付いた表記ではない。HTTP が「何を送るか」を扱う層だとすれば、TLS は「その通信をどのような前提で守るか」を扱う層である。

TLS 1.3 の仕様は、TLS が盗聴、改ざん、メッセージ偽造を防ぐよう設計された通信方式であることを示している[6]。ただし、この説明だけで「TLS を使っていれば安全」と結論づけることはできない。第一に、TLS には版、暗号方式、証明書、名前確認、鍵管理、設定方針が関係する。第二に、それらのうち一部が弱ければ、TLS という形式を使っていても、期待した保護が十分に得られない。IETF の TLS 利用推奨でも、古い方式を避け、現代的な設定で運用する必要が整理されている[7]。つまり、TLS は導入した瞬間に安全性が確定する部品ではなく、どの前提で構成され、どのように維持されるかによって意味が変わる通信基盤である。

ここで重要なのは、TLS が複数の機能を一つの仕組みとして束ねている点である。通信内容を読ませない機密性。途中で書き換えられたことを検出する完全性。通信相手が想定したサービスであることを確認する相手確認。さらに実務では、監査で「転送時暗号化を行っている」と説明するための統制としての意味も持つ。これらは互いに関係するが、同じものではない。機密性があるからといって、相手確認が十分であるとは限らない。相手確認ができているからといって、端点のアプリケーションが安全であるとは限らない。監査上、転送時暗号化を満たしているからといって、すべての攻撃経路を閉じたことにもならない。

因果関係を二段階で見ると、この違いはさらに明確になる。まず、通信経路で TLS を使うと、経路上で通信内容を読むことや書き換えることは難しくなる。これが第一段階の効果である。しかし、通信相手の証明書を検証しなければ、その通信が本当に想定した相手に届いているのかを十分には確認できない。さらに、通信相手が正しくても、その相手のサーバー、コンテナ、アプリケーション、権限設定が侵害されていれば、TLS はその内部の不正処理を止められない。つまり、TLS の効果は通信経路に強く働くが、端点の安全性や運用権限の安全性まで自動的に保証するわけではない。

証明書も同じである。X.509 証明書は、公開鍵と主体情報を結びつけるための標準的な枠組みであり、証明書チェーン、発行者、有効期限、用途などの情報を含む[8]。しかし、証明書が存在することと、その証明書を正しく検証していることは同じではない。通信相手の名前をどのように確認するかについても、TLS ではサービス識別子の検証が重要になる[9]。したがって、証明書がある、HTTPS である、暗号化されている、という表面的な状態だけでは、相手確認がどの程度成立しているかは判断できない。

機能	意味	誤解しやすい点
機密性	経路上で通信内容を読まれにくくする。	通信の端点が侵害された場合や、アプリケーションが情報を誤って出力する場合まで守れるわけではない。
完全性	通信途中で内容が改ざんされた場合に検出しやすくする。	アプリケーション内部の不正処理、権限濫用、設定ミスを防ぐものではない。
相手確認	証明書と名前確認を使い、通信相手が想定したサービスであることを確認する。	証明書を検証しない構成や、名前確認を行わない構成では、この意味は弱くなる。
監査説明	転送時暗号化を組織として示せる状態にする。	監査を満たすことと、すべての攻撃を防ぐことは同じではない。

この表が示すのは、TLS を小さく評価すべきだということではない。むしろ、TLS を正しく評価するには、その機能を分けて扱う必要があるということである。通信経路を保護したいのか、通信相手を確認したいのか、内部サービス間の責任境界を明確にしたいのか、監査上の転送時暗号化を示したいのかによって、必要な構成は変わる。単に TLS を使うという表現だけでは、そのどれを満たしているのかが見えない。

したがって、VPC 内通信に TLS を使うかどうかは、単なる設定値の問題ではない。暗号化しているのに相手確認は弱い、相手確認はできているが端点侵害には無力である、監査上は有効だが脅威モデル上の効果は限定的である、という状態は十分に起こりうる。ここで必要なのは、TLS の有無を確認することではなく、TLS が機密性、完全性、相手確認、監査説明のうち何を担い、何を担っていないのかを明示することである。この分解を行って初めて、次に扱うロードバランサーから内部サービスへの通信や、自己署名証明書の意味を正しく評価できる。

3. 証明書は、暗号化と相手確認をつなぐ部品である

TLS を考えるとき、証明書の役割を避けて通ることはできない。X.509 証明書は、公開鍵、主体名、有効期間、発行者の署名などを含み、公開鍵基盤の中で通信相手を確認するために使われる形式である[8]。ここで重要なのは、証明書が単なる暗号化の飾りではないという点である。TLS では、通信内容を暗号化するために鍵が使われる。しかし、その鍵が本当に意図した相手に属しているのかを判断できなければ、暗号化された通信路は作れても、その通信路が正しい相手へ向かっているとは言い切れない。証明書は、この二つをつなぐ部品である。

ただし、証明書が存在することと、その証明書を信頼できることは同じではない。証明書は、誰が発行したのか、どの名前に対して発行されたのか、どの期間だけ有効なのか、検証側がどの認証局を信頼しているのかによって意味を持つ。たとえば、あるサーバーが証明書を提示したとしても、その証明書が未知の発行者によるものなら、検証側はその証明書を信頼できない。逆に、信頼している認証局から発行された証明書であっても、接続先として期待する名前と証明書上の名前が一致しなければ、想定した相手に接続しているとは判断できない。

ここには二段階の因果関係がある。第一段階では、証明書によって公開鍵と主体名が結びつけられる。これにより、通信相手が提示した公開鍵を、単なる鍵ではなく、特定の名前を持つ主体に属する鍵として扱える。第二段階では、その結びつきが信頼できるかどうかを、証明書チェーン、発行者、名前、有効期限、用途などから検証する。つまり、証明書は提示されるだけでは足りない。検証されて初めて、暗号化された通信路と相手確認が結びつく。

通信相手の名前を検証する手順も重要である。TLS におけるサービス識別子の検証は、証明書に書かれた名前と、接続先として期待するサービス名が一致しているかを確認するための手順である[9]。これがなければ、暗号化された経路は作れても、その先が本当に意図した相手かは弱くなる。ここでいう名前は、単なる表示名ではない。通信する側が「このサービスに接続しているはずだ」と期待する識別子であり、証明書はその期待と相手の鍵を対応づける役割を持つ。

観点	確認すること	確認しない場合に起こること
発行者	証明書が信頼している認証局から発行されたものかを確認する。	誰が保証した証明書なのかが不明になり、相手確認の根拠が弱くなる。
主体名	証明書がどのサービス名や主体に対して発行されたものかを確認する。	証明書が別のサービス向けであっても見逃す可能性がある。
有効期間	証明書が現在も有効な期間内にあるかを確認する。	期限切れの証明書を受け入れ、更新管理の失敗を見逃す可能性がある。
名前確認	接続先として期待するサービス名と証明書上の名前が一致するかを確認する。	暗号化された通信路は作れても、想定した相手に接続している保証が弱くなる。
用途	その証明書がサーバー認証など期待する目的に使えるものかを確認する。	本来の用途と異なる証明書を受け入れ、証明書管理の境界が曖昧になる。

この整理から分かるのは、暗号化と相手確認は連動するが、同じものではないということである。暗号化は、経路上で通信内容を読ませにくくする。一方、相手確認は、暗号化された通信の相手が想定した主体であることを確かめる。両方がそろって初めて、一般的に想像される「安全な HTTPS」に近づく。どちらか一方だけでは、守れる範囲が限定される。暗号化だけなら、通信内容は読まれにくくなるが、相手を取り違える危険が残る。相手確認だけを強く意識しても、通信経路が保護されなければ、経路上の盗聴や改ざんに弱くなる。

この区別は、クラウド内部通信を考えるときに特に重要である。VPC 内の通信では、外部インターネットに公開された通信とは異なる前提がある。経路制御、セキュリティグループ、ロードバランサー、AWS 基盤側の保護が関与するため、従来の公開 Web サイトとまったく同じ脅威モデルではない。しかし、そのことは証明書の意味が消えるということではない。むしろ、どの層で相手確認を行うのか、どの層で経路暗号化を担保するのか、どの層で監査上の説明を可能にするのかを分けて考える必要がある。

したがって、証明書をめぐる判断は、「正式な証明書か、自己署名証明書か」という単純な分類だけでは足りない。問うべきなのは、その証明書に何を期待しているのかである。通信内容を平文で流さないことを期待しているのか。通信相手の真正性まで確認したいのか。組織内の証明書基盤でサービス間の責任境界を管理したいのか。監査上、転送時暗号化の証跡を示したいのか。期待する役割が違えば、必要な証明書の種類、検証方法、運用負荷も変わる。

ここで本稿の論点は、次の章へつながる。TLS と証明書を使っていても、ロードバランサーがターゲット証明書をどのように扱うかによって、暗号化と相手確認の意味は変わる。特に、ロードバランサーから内部ターゲットへの HTTPS 通信では、証明書があること、通信が暗号化されていること、ターゲットの真正性が厳密に検証されていることを同一視できない。証明書は、暗号化と相手確認をつなぐ部品である。しかし、そのつながりが実際に成立するかどうかは、証明書を検証する側の設計に依存する。

4. ALB からターゲットへの HTTPS は、外向きの HTTPS と同じではない

この違いは、AWS の Application Load Balancer、以下 ALB を見ると分かりやすい。ALB で HTTPS リスナーを作る場合、ロードバランサーには少なくとも一つのサーバー証明書を配置し、外部のクライアントから来た TLS 接続をロードバランサーで終端する[10]。この構成では、外部の利用者から見た HTTPS の相手は ALB である。利用者のブラウザーやクライアントは、ALB が提示する証明書を検証し、期待するサービス名と証明書上の名前が一致するかを確認する。つまり、外部から ALB までの HTTPS は、通信内容の保護だけでなく、利用者が接続先を確認するための仕組みとして働く。

一方で、ALB からターゲットへ HTTPS で転送する構成は、同じ HTTPS という名前でも意味が異なる。AWS 公式文書では、ロードバランサーはターゲット証明書を検証しないため、自己署名証明書や期限切れ証明書も使えると説明されている。また、ロードバランサーとターゲットが VPC 内にある場合、AWS はパケットレベルで認証されるため、中間者攻撃やなりすましのリスクは低いと説明している。ただし、AWS 外へ出る通信には同じ保護は適用されない[11]。この仕様は、ALB からターゲットへの HTTPS を理解するうえで重要である。HTTPS という表記が同じでも、証明書検証の役割が外部向け通信とは異なるからである。

ここには二段階の因果関係がある。第一段階では、ALB からターゲットへの通信を HTTPS にすることで、ロードバランサーからアプリケーション側までの区間で平文を減らせる。これにより、経路上で通信内容を直接読める状態は減る。第二段階では、しかし、ALB がターゲット証明書を検証しないため、その HTTPS は、信頼された認証局に基づく相手確認としては働かない。つまり、通信内容を暗号化する効果と、ターゲットが本当に想定した主体であることを検証する効果は分かれる。この構成を「HTTPS だから安全」とだけ表現すると、経路暗号化と真正性確認の違いを見落とす。

したがって、ALB からターゲットへの HTTPS が無意味だという結論にはならない。むしろ、目的を正確に言う必要がある。自己署名証明書を使った HTTPS は、経路上の平文を減らすという意味では役割を持ちうる。しかし、信頼された認証局に基づいてターゲットの真正性を厳密に確認しているわけではない。ここで守っているのは、主にロードバランサーからターゲットまでの通信内容である。ここで弱いまま残るのは、証明書検証に基づく相手確認である。この二つを分けておかないと、設計判断の根拠が曖昧になる。

この点は、内部通信の脅威モデルとも関係する。VPC 内で ALB とターゲットが通信している場合、攻撃者が経路上に割り込んで自由に通信を横取りするという想定は、公開インターネット上の通信より成立しにくい。AWS がパケットレベルで認証されると説明しているのは、この前提に関わる。しかし、成立しにくいことと、設計上考慮しなくてよいことは同じではない。扱うデータが機微である場合、監査で転送時暗号化を求められる場合、あるいは組織標準として内部通信も暗号化する方針を採る場合には、ALB からターゲットへの HTTPS は意味を持つ。ただし、その意味は「ターゲットを厳密に認証している」ではなく、「内部区間の平文を減らし、転送時暗号化の説明をしやすくする」に近い。

相手確認をより強くしたい場合には、別の設計が必要になる。ALB には、クライアント証明書を使って接続元を検証する相互 TLS の仕組みがある[12]。相互 TLS では、サーバー側だけでなく、接続してくる側も証明書を提示し、検証の対象になる。これにより、通信相手を確認する力は強くなる。しかし、その分だけ証明書の発行、配布、失効、更新、監視、障害時の切り分けが必要になる。強い確認は、常に強い運用負荷を伴う。したがって、相互 TLS は、単に安全性を高める選択肢ではなく、その運用を継続できる組織能力を要求する選択肢でもある。

構成	主な意味	注意点
ALB での HTTPS 終端	外部クライアントと ALB の間で TLS を使い、外部利用者から見た接続先として ALB が証明書を提示する。	ALB から先の通信は、同じ HTTPS 接続の延長ではなく、別の区間として設計しなければならない。
ALB からターゲットへの HTTPS	ロードバランサーからアプリケーション側までの平文区間を減らし、内部区間の転送時暗号化を説明しやすくする。	ターゲット証明書を検証しない構成では、信頼された認証局に基づく真正性保証は限定される。
自己署名証明書	信頼された外部認証局を使わずに、内部区間の TLS 通信を成立させる。	経路暗号化には使えても、それだけでターゲットの正当性を強く証明するものではない。
相互 TLS	通信の一方だけでなく、接続元の証明書も確認し、サービス間の相手確認を強める。	証明書のライフサイクル管理が重くなり、更新失敗や失効管理の不備が障害要因になりうる。

この章で確認したいのは、ALB からターゲットへの HTTPS を過小評価することでも、過大評価することでもない。外部クライアントから ALB までの HTTPS と、ALB から内部ターゲットまでの HTTPS は、同じ言葉で語られていても、証明書検証、相手確認、信頼境界の置き方が異なる。前者では、外部利用者がサービスを確認するための証明書検証が中心になる。後者では、内部区間の平文を減らし、転送時暗号化を満たすことが主な意味になりやすい。この違いを理解して初めて、内部通信を TLS 化する判断を、単なる形式ではなく、何を守り、何を守らない設計なのかとして説明できる。

5. 基盤側の暗号化は、アプリケーション側 TLS と同じではない

AWS には、アプリケーションが明示的に TLS を扱わなくても、基盤側で転送時暗号化を行う仕組みがある。EC2 のデータ保護に関する文書では、アベイラビリティーゾーン間通信の暗号化や、一部の Nitro System 対応インスタンス間における転送時暗号化が説明されている[13]。Nitro System は、仮想化、入出力処理、管理機能を分離する AWS の基盤構成であり、EC2 の安全性と性能を支える重要な仕組みである[14]。このような仕組みは、利用者がすべての通信経路に個別に TLS を設定しなくても、一定の条件を満たす通信について基盤側で保護を提供する。

ただし、ここで注意すべきなのは、基盤側で暗号化されることと、アプリケーション側で TLS を使うことは同じではないという点である。第一段階として、基盤側の暗号化は、仮想マシン間やアベイラビリティーゾーン間など、AWS の管理する下位層で通信内容を保護する。これにより、アプリケーションを変更せずに、通信経路の一部で平文が露出する可能性を下げられる。第二段階として、しかし、その暗号化は、アプリケーション同士が互いに誰であるかを確認する仕組みではない。サービス A がサービス B に接続しているのか、証明書はどのサービスに割り当てられているのか、どの内部サービスだけに接続を許すのかといった論理は、基盤側の暗号化だけでは表現しにくい。

この違いは、暗号化の層を分けて考えると明確になる。基盤側の暗号化は、主に AWS が管理する通信路の保護である。アプリケーション側 TLS は、アプリケーションやサービスの単位で、通信相手、証明書、名前確認、認証単位を設計するための仕組みである。前者は、利用者の設定負荷を増やさずに転送時の保護を強めやすい。後者は、サービス間の責任境界を明示しやすい。どちらが上位で、どちらが下位というだけの話ではない。守る層が違うため、表現できる責任も違う。

さらに、基盤側暗号化には適用条件がある。すべての通信が、あらゆる構成で同じように保護されるわけではない。インスタンスの種類、通信相手、リージョン、VPC、経路上にロードバランサーや他のネットワーク機能が入るかどうかによって、どの保護が効くかは変わる。したがって、「AWS 側で暗号化されるからアプリケーション側 TLS は不要」と一般化することはできない。正しく言うなら、基盤側の保護がどの経路に適用されるのかを確認したうえで、アプリケーション側でさらに何を保証する必要があるのかを判断する、という順序になる。

ここでも因果関係は二段階で整理できる。まず、基盤側暗号化があることで、利用者が明示的に TLS を構成していない区間でも、一定の経路保護が得られる。これにより、内部通信のすべてをアプリケーション側で暗号化しなければならない、という単純な結論は弱くなる。次に、それでもアプリケーション側 TLS が不要になるとは限らない。なぜなら、アプリケーション側 TLS は、通信相手の名前確認、サービス単位の証明書管理、監査上の説明、内部サービス間の責任境界を表す役割を持つからである。基盤側暗号化は通信路の保護に強く、アプリケーション側 TLS はサービス間の意味づけに強い。この違いを見落とすと、どこで何を守っているのかが分からなくなる。

観測や監視のための仕組みも、この議論に関係する。Amazon VPC の Traffic Mirroring は、ネットワークインターフェイスを通る通信のコピーを、セキュリティ監視や障害調査のための装置へ送れる機能である[15]。これは正当な運用機能である。侵入検知、通信分析、障害調査、通信経路の確認には、実際に流れるパケットを観測できる仕組みが役立つ。一方で、正当な観測機能は、強い権限を持つ主体が通信を見られる経路にもなりうる。平文通信であれば、観測された通信の内容も読み取れる可能性がある。

TLS は、このような観測経路に対して、通信内容を読ませにくくするという意味を持つ。ここでも二段階で考える必要がある。第一段階では、通信が平文であれば、監視のために複製された通信から内容を読める可能性がある。第二段階では、通信が TLS で暗号化されていれば、複製された通信から直接内容を読むことは難しくなる。ただし、これは監視機能そのものを否定する話ではない。監視は必要であり、観測も必要である。問題は、観測できることと、内容まで読めることを区別して設計しているかである。

ただし、TLS で観測経路に対する内容保護を強めても、問題がすべて閉じるわけではない。アカウント権限が侵害されれば、攻撃者は設定変更、ログ参照、証明書取得、アプリケーション操作など、通信経路以外の手段を使える可能性がある。端点のサーバーやコンテナが侵害されれば、TLS で守られる前または復号された後の情報に触れられる可能性がある。したがって、Traffic Mirroring のような観測経路に対して TLS が有効な場面はあるが、それは経路上の内容秘匿に対する効果であって、権限管理や端点防御の代替ではない。

層	代表例	得意なこと	不得意なこと
基盤側	Nitro System による転送時暗号化。	アプリケーション改修なしに、条件を満たす通信経路の保護を強めやすい。	サービス間の論理的な相手確認や、アプリケーション単位の責任境界を直接表現しにくい。
アプリケーション側	サービス間 TLS、相互 TLS。	通信相手、証明書、名前確認、認証単位をサービスの論理で扱える。	証明書の発行、配布、更新、失効、監視を継続的に運用する必要がある。
監視側	Traffic Mirroring。	通信の観測、分析、侵入検知、障害調査に使える。	平文通信であれば、観測経路に通信内容が見える可能性がある。
権限側	IAM、管理者権限、設定変更権限。	誰が通信経路や監視設定を変更できるかを制御できる。	通信暗号化だけでは、過大な権限や認証情報の漏洩を補えない。
端点側	仮想マシン、コンテナ、アプリケーション。	復号後のデータ処理、認可、入力検証、ログ出力を制御できる。	端点が侵害された場合、経路上の TLS だけでは情報利用を止められない。

この章の要点は、暗号化されているかどうかだけでは不十分だという点である。どの層で暗号化され、誰がその層を管理し、どの責任境界を表しているのかを見なければならない。基盤側暗号化は、通信路の保護を強める。アプリケーション側 TLS は、サービス間の意味づけと相手確認を扱う。監視機能は、通信を観測可能にする。権限管理は、その観測や設定変更を誰が行えるかを制限する。端点防御は、復号された後のデータ処理を守る。これらは相互に補完するが、互いの代替ではない。

したがって、VPC 内通信の暗号化を考えるときには、「AWS 基盤側で保護されているから十分」または「アプリケーション側で TLS を使えば十分」という二つの単純化を避ける必要がある。基盤側の保護は重要である。しかし、それはサービス間の相手確認や監査上の説明をすべて担うわけではない。アプリケーション側 TLS も重要である。しかし、それは権限侵害や端点侵害を止める万能の防壁ではない。必要なのは、層ごとの役割を分け、それぞれがどの信頼境界を表しているのかを明確にすることである。

6. コンテナ環境では、選択肢がさらに増える

コンテナを使うと、通信の単位はさらに細かくなる。単一の仮想サーバーにアプリケーションを置く場合、通信経路は比較的追いやすい。ロードバランサー、仮想サーバー、アプリケーションという関係で考えられるからである。しかし、コンテナ環境では、複数のタスク、複数のサービス、補助コンテナ、名前解決、サービス間通信、ヘルスチェック、ログ収集、監視用通信が重なる。通信の数が増えるだけではない。どの通信が利用者向けで、どの通信が内部サービス間で、どの通信が運用のためのものなのかが分かれ、保護すべき境界も細かくなる。

Amazon ECS のネットワークセキュリティ文書では、必要に応じてネットワーク暗号化を使うこと、PCI DSS のような準拠要求では転送時暗号化が求められる場合があることが説明されている[16]。ここで重要なのは、コンテナ環境では、通信暗号化が単なる一箇所の設定では済みにくいという点である。第一段階として、サービスが分割されると、通信経路が増える。第二段階として、通信経路が増えると、それぞれについて、どの区間を暗号化するのか、どの相手を確認するのか、どの例外を許すのかを判断しなければならなくなる。したがって、コンテナ化は、アプリケーションの配置を柔軟にする一方で、信頼境界の数を増やす。

このとき、HTTP のままにする、自己署名証明書で HTTPS にする、内部認証局を使う、サービス間通信の暗号化を基盤機能に任せる、といった選択肢が並ぶ。重要なのは、これらを強弱の直線上に置かないことである。HTTP は常に悪であり、相互 TLS は常に最善である、という整理では実務判断にならない。扱うデータ、通信経路、監査要求、運用体制、障害時の復旧能力によって、妥当な選択肢は変わる。つまり、コンテナ環境における暗号化判断は、単に安全性を最大化する作業ではなく、保護したい対象と維持できる運用の釣り合いを取る作業である。

内部証明書をきちんと扱うためには、認証局の設計も問題になる。AWS Private Certificate Authority は、組織内のプライベートな公開鍵基盤に証明書を発行・失効するための管理型サービスである[17]。これは、自己署名証明書を個別に置くよりも、組織として信頼の根を管理しやすくする。個々のサービスがばらばらに証明書を作るのではなく、どの認証局を信頼するのか、どの範囲へ証明書を発行するのか、どの証明書を失効させるのかを一つの仕組みとして扱えるからである。

ただし、内部認証局を使うことは、責任が軽くなることを意味しない。第一段階では、認証局を置くことで、証明書の発行元を統一でき、内部サービスの相手確認を設計しやすくなる。第二段階では、その認証局自体が重要な信頼の根になるため、認証局の階層、権限、証明書の期限、失効手順、監査記録、誤発行時の対応を管理しなければならなくなる。信頼の根を集中させることは、管理しやすさを生む一方で、その根を誤って扱った場合の影響も大きくする。

ECS Service Connect には、AWS Private CA と連携してサービス間通信の TLS 証明書を自動的に発行、配布、更新する仕組みがある[18]。これは、暗号化をアプリケーション開発者の手作業から、基盤的な運用へ移す例である。各サービスが証明書の作成や更新を個別に抱えるのではなく、サービス間通信の仕組みの中で証明書を扱う。この方向性は、コンテナ環境のように通信経路が増えやすい構成では特に重要である。人手で管理する対象が増えすぎると、期限切れ、配布漏れ、設定不一致、障害時の切り分け困難が起こりやすくなるからである。

しかし、自動化されたからといって、設計判断が消えるわけではない。第一段階では、自動化によって証明書の発行、配布、更新の手作業は減る。第二段階では、その自動化がどのサービスに適用され、どの範囲の通信を暗号化し、どの認証局を信頼し、障害時にどのように復旧するのかを決める必要が残る。自動化は、判断を不要にするものではなく、判断した方針を継続的に実行しやすくするものである。したがって、Service Connect の TLS も、単なる便利機能ではなく、サービス間通信の信頼境界をどの単位で管理するかという設計の一部として扱うべきである。

選択肢	向いている目的	注意点
HTTP のまま	脅威モデル上の追加効果が小さく、閉域、到達制御、基盤側保護で十分と判断する場合に使う。	なぜ平文を許容するのかを文書化しなければ、監査、引き継ぎ、障害調査で説明できない。
自己署名証明書による HTTPS	経路上の平文区間を減らすことを主目的にし、厳密な相手確認までは求めない場合に使う。	通信は暗号化できても、証明書検証に基づく相手確認を強く保証するものではない。
AWS Private CA	内部サービスの証明書を組織的に発行し、信頼の根を管理したい場合に使う。	認証局そのものの権限、階層、期限、失効、監査記録を管理する責任が生じる。
Service Connect の TLS	サービス間通信の暗号化と証明書更新を、コンテナ基盤側の運用として自動化したい場合に使う。	対象サービス、証明書発行範囲、障害時の切り分け、基盤機能への依存を設計する必要がある。

この表が示しているのは、コンテナ環境では、暗号化の選択肢が増えるほど判断も細かくなるということである。選択肢が増えることは、自由度が増えることでもある。しかし、自由度が増えると、暗黙の前提も増える。HTTP のままにするなら、なぜそれでよいのかを説明する必要がある。自己署名証明書を使うなら、それが経路暗号化を主目的とすることを明確にする必要がある。AWS Private CA を使うなら、信頼の根をどう守るかを設計しなければならない。Service Connect の TLS を使うなら、自動化された証明書運用がどの範囲を覆うのかを把握しなければならない。

したがって、コンテナ環境における内部通信の暗号化は、「通信が細かいから全部暗号化する」または「VPC 内だから何もしない」という二択ではない。サービス分割によって通信経路が増え、通信経路が増えることで信頼境界が増え、その信頼境界を管理するために、証明書、認証局、自動更新、監査説明が必要になる。ここで見えてくる背後構造は、暗号化が単なる通信保護ではなく、分散したサービス群の関係を管理するための設計要素になるということである。

7. 転送時暗号化は、監査できる統制へ変わる

ここまでの議論では、主に脅威と技術機能を見てきた。TLS は何を守るのか。証明書は何を確認するのか。ALB からターゲットへの HTTPS は、外向きの HTTPS と何が違うのか。基盤側の暗号化とアプリケーション側 TLS は、どの層で責任を持つのか。これらはすべて、攻撃者や障害経路を想定した技術的な問いである。しかし実務では、暗号化は攻撃を防ぐためだけに導入されるわけではない。組織が標準として何を要求し、どの構成を許し、どの例外を記録し、監査時に何を説明できるのかという統制上の問いにもなる。

AWS Well-Architected Framework のセキュリティ柱では、転送時暗号化の要件を最新の標準や実務上の推奨に基づいて定義し、安全なプロトコルだけを許可することが推奨されている[19]。ここで暗号化は、個別サービスの設定項目ではなく、システム全体の設計原則として扱われている。第一段階では、通信ごとに TLS を有効にするかどうかという判断がある。第二段階では、その判断を個々の担当者の裁量に任せるのではなく、組織として標準化し、継続的に確認し、逸脱を検出できるようにする必要が生じる。つまり、転送時暗号化は、単なる通信保護から、設計品質を維持するための管理対象へ移る。

この変化は、暗号化の意味を広げる。通信内容を読ませないことは、暗号化の重要な役割である。しかし、組織の中で運用されるシステムでは、それだけでは足りない。どの通信が暗号化されているのか。どの通信が平文のまま残っているのか。平文を許す場合、その理由は何か。例外は誰が承認し、いつ見直すのか。これらを答えられなければ、技術的には問題が小さい構成でも、統制上は弱い構成になる。暗号化は、通信を守る技術であると同時に、組織が通信経路を把握していることを示す証拠にもなる。

VPC Encryption Controls は、この流れをさらに明確にする。AWS の文書では、この機能は VPC 内および VPC 間の転送時暗号化を監視し、非準拠のリソースを特定し、最終的には平文通信を許す機能やサービスの利用を制限するものとして説明されている[20]。AWS の発表でも、この機能は VPC 内外の転送時暗号化を監査・強制し、暗号化標準への準拠を示しやすくするためのものとされている[21]。ここでは、暗号化はアプリケーション担当者が個別に設定するものから、クラウド基盤上で状態を確認し、逸脱を検出し、必要に応じて制限するものへ変わっている。

この変化にも、二段階の因果関係がある。第一段階では、暗号化状態を可視化できるようになる。これにより、どの通信が標準に合っていて、どの通信が標準から外れているのかを確認できる。第二段階では、可視化された状態をもとに、組織は標準を強制できるようになる。つまり、暗号化は「設定されているはず」という期待から、「確認できる状態」へ移り、さらに「逸脱を許さない制約」へ移る。この移行によって、転送時暗号化は個別の安全対策ではなく、組織として維持される統制になる。

ここでいう統制とは、抽象的な管理用語ではない。統制とは、組織が望ましい状態を定義し、その状態から外れたものを見つけ、必要であれば修正または制限できる仕組みである。転送時暗号化でいえば、望ましい状態は「一定の通信経路では安全なプロトコルを使うこと」である。逸脱は「平文通信を許す構成が残っていること」である。修正は「TLS 化する、基盤側の暗号化を使う、例外として記録する、またはその通信経路を廃止する」ことである。この一連の流れがなければ、暗号化方針は文書上の標語にとどまる。

段階	暗号化の扱い	組織上の意味
個別設定	サービスごとに TLS を有効にする。	担当者の判断と設定品質に依存しやすく、全体としてどの通信が保護されているのかを把握しにくい。
標準化	組織の標準構成として、安全なプロトコルや転送時暗号化の要件を定める。	新規構築時のばらつきを抑え、設計レビューや引き継ぎで判断基準を共有しやすくなる。
監視	平文通信を許すリソースや、標準から外れた構成を発見する。	例外や逸脱を後から検出でき、暗黙のまま残る危険な構成を減らせる。
強制	暗号化されない通信を許す構成やサービス利用を制限する。	方針を文書だけでなく基盤側の制約として実装でき、担当者の注意力だけに依存しない運用に近づく。
例外管理	暗号化しない通信を例外として明示し、理由、範囲、期限、見直し条件を記録する。	平文通信を完全に消せない場合でも、組織としてリスクを認識し、説明できる状態を保てる。

この表が示しているのは、暗号化が強いか弱いかだけではない。暗号化が、組織の中でどの成熟度で扱われているかである。個別設定の段階では、担当者が正しく設定していれば通信は守られる。しかし、構成が増え、チームが分かれ、サービスが増え、監査要求が加わると、個別の善意や注意力だけでは維持できない。標準化によって基準をそろえ、監視によって逸脱を見つけ、強制によって標準を実装し、例外管理によって残るリスクを説明する。この段階を踏むことで、暗号化は単発の設定から、継続的な管理へ変わる。

この論点は、技術的な脅威分析と矛盾しない。脅威モデル上、VPC 内通信の一部では、TLS によって新たに防げる攻撃が限定的な場合がある。だが、監査や準拠の観点では、問いは少し変わる。攻撃がどの程度起こりやすいかだけでなく、組織が転送時暗号化を標準として定義しているか、その標準から外れた通信を把握しているか、例外を承認しているか、後から説明できるかが問われる。つまり、技術的な有効性と監査上の説明可能性は、重なる部分を持ちながらも別の評価軸である。

ここで注意すべきなのは、監査を満たすことが安全そのものではないという点である。監査項目を満たしていても、過大な権限、脆弱なアプリケーション、露出した秘密情報、誤ったログ出力があれば、情報は漏れうる。反対に、特定の内部通信を平文にしていても、脅威モデル、到達制御、基盤側保護、データ種別、例外承認が整理されていれば、合理的な設計判断として説明できる場合もある。したがって、監査は技術判断の代替ではない。監査は、技術判断を説明可能にするための別の層である。

本章の要点は、転送時暗号化が、通信を読ませないための技術から、監査できる統制へ変わるということである。暗号化は保護機能である。同時に、どの通信を標準に含め、どの通信を例外とし、どの状態を非準拠とみなすのかを示す管理対象でもある。クラウドでは、内部通信が増え、サービスが分散し、責任境界が細かくなる。その結果、暗号化は、個々の通信を守るだけでなく、組織が信頼境界を把握し、維持し、説明するための仕組みになる。

8. 監査と規制は、技術判断を別の方向から拘束する

技術者は、実際の脅威にどれだけ効くかを重視する。それは正しい。通信経路の盗聴、中間者攻撃、権限侵害、端点侵害といった脅威を置かずに、暗号化の有効性を評価することはできない。しかし、組織のセキュリティ判断は、技術的な攻撃可能性だけで決まらない。顧客、監査人、規制当局、社内の統制部門は、「攻撃がどれだけ起こりやすいか」だけでなく、「どの標準に従い、どの設定を許し、どの例外を承認し、どの証拠で説明できるのか」を問う。ここで、暗号化は技術対策であると同時に、説明可能な管理状態を作るための統制になる。

この違いを見落とすと、設計判断が二つの方向にずれる。一方では、技術的な脅威だけを見て「VPC 内通信では実害が小さいから不要」と結論づけてしまう。もう一方では、監査項目だけを見て「暗号化していれば安全」と考えてしまう。どちらも不十分である。第一段階では、脅威分析によって、その暗号化が実際にどの攻撃経路に効くのかを確認する必要がある。第二段階では、監査や規制によって、その判断を組織として説明できる形にする必要がある。つまり、脅威分析は技術的な妥当性を支え、監査・規制は説明可能性と標準化を支える。

AWS Config の FedRAMP Moderate 向け運用ベストプラクティスでは、ロードバランサーの SSL または HTTPS リスナー、暗号化、監視などが統制項目として扱われている[22]。ここで重要なのは、ロードバランサーが実際にどの攻撃をどの程度防ぐかだけではない。組織が、ロードバランサーの入口で安全な通信方式を使い、構成状態を確認し、標準から外れた設定を検出できるかが問われる。監査の文脈では、通信がどのように保護されているかを示すこと自体が要求になる。したがって、暗号化は「攻撃者に読ませない」ための技術であると同時に、「組織が設計方針を守っていることを示す」ための証拠にもなる。

NIST SP 800-53 は、情報システムと組織のためのセキュリティおよびプライバシー統制のカタログであり、攻撃だけでなく、人為的な誤り、自然災害、構造的障害、プライバシーリスクを含めた多様なリスクに対処するための統制を整理している[23]。ここでの統制とは、単なる技術設定ではない。組織として、何を守るか、どう実装するか、どう確認するか、どの逸脱を許すかを結び付ける枠組みである。通信暗号化でいえば、暗号化を有効にする設定だけでなく、暗号化要件の定義、設定確認、ログ、例外承認、定期的な見直しまでが統制の一部になる。

ここにも二段階の因果関係がある。第一段階では、規制や標準が、組織に対して望ましい状態を定義させる。たとえば、特定の通信では転送時暗号化を求める、古い通信方式を許可しない、ロードバランサーの入口では HTTPS を使う、といった基準である。第二段階では、その基準が、実際のクラウド構成を拘束する。担当者が便利だから HTTP を使う、移行が面倒だから古い設定を残す、という判断は、標準や監査の観点から制限される。つまり、監査と規制は、技術判断の外側から来る余計な手続きではなく、技術構成を組織の責任体系に接続する力を持つ。

ゼロトラストの議論も、内部を無条件に信頼しないという点で本稿と接続する。NIST SP 800-207 は、ゼロトラストを、ネットワーク上の位置だけで信頼を与えず、資源ごとにアクセスを継続的に評価する考え方として整理している[24]。ただし、本稿はゼロトラスト総論ではない。ここで必要なのは、ゼロトラストという大きな標語を導入することではなく、VPC 内通信の TLS を考えるだけでも、「内部だから信頼する」という前提が揺らぐことを確認することである。内部にあるから通信を平文でよいとするのではなく、内部であっても、どの通信を信頼し、どの通信を検証し、どの通信を例外として扱うのかを決める必要がある。

業界規制も同じ構造を持つ。PCI DSS は支払いカード情報を守るための技術的・運用的な要件を定める標準であり、現行文書として 4.0.1 が公開されている[25]。HIPAA Security Rule は、電子的に保持または送信される保護対象保健情報を守るために、管理的、物理的、技術的保護策を求めている[26]。これらの制度が直接適用されるかどうかは、業務、扱うデータ、契約、地域、顧客要求によって異なる。しかし構造は共通している。特定のデータを扱う組織には、単に「安全だと思う」だけでなく、「要求された保護策を実装し、維持し、説明できる」ことが求められる。

このため、規制対象のデータを扱う場合、暗号化の意味はさらに変わる。第一段階では、通信内容を読ませないために暗号化を使う。これは技術的な保護である。第二段階では、暗号化されていることを、標準、監査、契約、顧客説明の中で示す必要が生じる。これは制度的な保護である。制度的な保護は、攻撃を直接止めるわけではない。しかし、組織が保護策を設計し、実装し、見直していることを示すことで、責任の所在と管理状態を明確にする。暗号化は、攻撃対策であると同時に、組織が責任を説明するための形式になる。

文脈	問われること	暗号化の意味
脅威分析	想定する攻撃に対して有効かを問う。	通信経路の盗聴、改ざん、中間者攻撃を抑える技術的制御になる。
設計標準	組織としてどの通信方式を許可し、どの構成を標準とするかを問う。	担当者ごとの判断のばらつきを抑え、構成の前提をそろえる基準になる。
監査	組織標準に沿っているか、例外を説明できるか、証拠を示せるかを問う。	設定状態、運用状態、例外管理を示す統制になる。
規制	特定のデータや業界要件に適合しているかを問う。	法令、標準、契約上の要求に対する説明材料になる。
運用	継続して管理できるか、期限切れや設定逸脱を検出できるか、障害時に復旧できるかを問う。	証明書、設定、監視、例外、更新手順を含むライフサイクル管理の対象になる。

この表が示しているのは、暗号化の評価軸が一つではないということである。脅威分析では、暗号化がどの攻撃に効くかを問う。設計標準では、どの構成を組織として許すかを問う。監査では、その状態を証拠として示せるかを問う。規制では、特定のデータや業界要件に適合しているかを問う。運用では、その状態を継続して維持できるかを問う。これらは互いに重なるが、同じではない。したがって、VPC 内通信の TLS 化を評価するときも、「技術的に効くか」だけではなく、「組織として標準化できるか」「監査で説明できるか」「運用し続けられるか」を同時に見る必要がある。

ただし、監査と規制を理由にして、すべての通信を無条件に重装備にすればよいわけではない。過剰な暗号化構成、複雑すぎる証明書管理、過度に細かい相互 TLS、把握できない例外設定は、それ自体が障害や運用ミスの原因になる。規制や監査は、設計を強くするための枠組みであるが、設計判断を不要にするものではない。むしろ、どの通信にどの水準の保護が必要か、どの例外を許すか、どの運用負荷まで組織が負えるかを明確にするために使うべきである。

本章の結論は、監査と規制が技術判断を別の方向から拘束するということである。脅威分析は、暗号化の技術的な効果を評価する。監査と規制は、その判断を組織の責任、標準、証拠、例外管理に接続する。両者は対立するものではない。むしろ、片方だけでは不十分である。脅威分析だけでは、説明責任が抜け落ちる。監査だけでは、実際の攻撃経路への理解が弱くなる。VPC 内通信の暗号化を設計するには、この二つの評価軸を分けたうえで、同じ構成の中に接続する必要がある。

9. 運用できない安全は、安全ではない

暗号化を増やせば、それだけ安全になるように見える。通信経路を HTTP から HTTPS に変える。自己署名証明書ではなく内部認証局を使う。さらに相互 TLS を導入し、サービス間で互いに証明書を確認する。こう並べると、対策を積み上げるほど安全性が増すように見える。しかし、現実には保護機能が増えるほど、管理対象も増える。証明書には期限があり、発行元があり、利用範囲があり、更新手順がある。認証局を持てば、証明書を発行する権限、失効の手順、監査記録、障害時の復旧経路を管理しなければならない。相互 TLS やサービスメッシュを導入すれば、通信経路の制御は強くなるが、障害時の切り分けも難しくなる。

ここには二段階の因果関係がある。第一段階では、暗号化を強めることで、通信経路上の盗聴、改ざん、意図しない接続を抑えやすくなる。これは明確な利点である。第二段階では、その保護を維持するために、証明書、鍵、認証局、更新、失効、監視、例外、復旧手順を継続的に管理しなければならなくなる。つまり、暗号化は導入時点では安全性を高めるが、運用設計が弱ければ、時間の経過とともに障害要因や説明不能な構成へ変わりうる。安全対策は、導入した瞬間ではなく、維持される期間全体で評価しなければならない。

この点は、保存データの暗号化と同じ構造を持つ。既稿では、暗号化ディスクの長期運用を、古い構成を単純に消すことではなく、役割を確定し、必要な期間だけ管理し、役割が終わった時点で退役させる能力として整理した[27]。通信暗号化でも同じである。ある構成が導入時点で妥当でも、数年後には古い方式、用途不明の証明書、更新されない例外、誰も説明できない経路になる可能性がある。したがって、暗号化構成は作った時点の正しさだけでなく、更新され、点検され、不要になれば退役できるかまで含めて評価する必要がある。

保存データの暗号化では、鍵を失うと正当な利用者もデータを読めなくなる。通信暗号化でも、同じ性質が別の形で現れる。証明書が期限切れになれば、正当なサービス同士の通信が止まる。認証局の鍵や設定を誤れば、発行済み証明書の信頼性が揺らぐ。失効手順が曖昧であれば、漏洩した証明書を無効化できない。ここで起きているのは、攻撃者を防ぐための仕組みが、管理を誤ると正当な利用者や正当なサービスを拒む仕組みにもなる、という反転である。暗号化は保護であると同時に、解除条件や信頼条件を厳格にする技術でもある。

暗号化デバイスの運用手順を扱った既稿では、暗号化領域は作った瞬間に終わるものではなく、初期生成、通常運用、情報確認、鍵管理、ヘッダー保全、点検、復旧、退役までを一つの作業体系として扱う必要があると整理した[28]。この考え方は、通信経路にも移せる。TLS を有効にすることは始点であり、終点ではない。証明書の発行、配布、更新、失効、監視、例外処理、障害時対応、構成変更時の再確認までが運用である。設定画面で暗号化を有効にしただけでは、暗号化を運用しているとは言えない。

さらに、LUKS の手順と運用を扱った既稿でも、暗号化は紛失や盗難への耐性を高める一方で、解除条件を失えば正当な利用者もデータに到達できなくなると述べた[29]。通信暗号化でも同じ両義性がある。証明書や認証局の管理を誤れば、攻撃者を防ぐだけでなく、正当なサービス間通信まで止めてしまう。たとえば、期限切れ証明書によって決済処理が止まる、内部認証局の障害でマイクロサービス間通信が失敗する、失効設定の誤りで本来許可すべき通信まで拒否される、といった事態が起こりうる。したがって、強い対策を入れることではなく、維持できる制御を選ぶことが重要になる。

ここで重要なのは、運用負荷を理由に暗号化を避けることではない。むしろ逆である。暗号化を本当に安全対策として扱うなら、その運用負荷を設計対象に含めなければならない。証明書の期限を誰が見るのか。更新は自動か手動か。自動更新が失敗した場合、誰に通知されるのか。認証局の権限は誰が持つのか。証明書の発行履歴は残るのか。退役したサービスの証明書は失効されるのか。例外として平文通信を許した場合、その期限と解消条件は定義されているのか。これらに答えられない構成は、表面上は暗号化されていても、長期運用では脆い。

失敗しやすい点	通信暗号化での現れ方	必要な設計
期限切れ	証明書が更新されず、正常な通信が止まる。	期限監視、自動更新、手動更新時の手順、更新失敗時の通知を持つ。
用途不明	どの証明書がどのサービスに使われているか分からなくなる。	発行目的、対象サービス、所有者、更新責任、退役条件を台帳化する。
例外の放置	一時的に許した平文通信や弱い設定が残る。	例外期限、承認者、解消条件、再確認日を明示する。
復旧不能	認証局や証明書配布基盤の障害でサービス間通信が止まる。	障害時の迂回、再発行手順、ロールバック条件、代替経路を設計する。
過剰な複雑化	相互 TLS やサービスメッシュの設定が複雑になり、障害箇所を特定しにくくなる。	通信経路、証明書、認可設定、ログ、監視項目を対応づけて管理する。
責任の曖昧化	証明書や認証局を誰が管理しているのか分からず、更新や障害対応が遅れる。	所有者、運用担当、承認者、緊急連絡先、変更手順を明確にする。

この表が示しているのは、通信暗号化の失敗は、暗号方式そのものの弱さだけから起こるのではないということである。むしろ実務では、期限切れ、用途不明、例外放置、復旧不能、過剰な複雑化、責任の曖昧化といった運用上の失敗が問題になる。暗号化は、数学的に強い方式を選べば終わるものではない。どの証明書が、どのサービスに、どの期間、どの目的で使われ、誰が更新し、障害時にどう戻すのかを管理して初めて、実際の安全対策になる。

この観点から見ると、VPC 内通信の TLS 化には、三つの評価軸が必要になる。第一に、脅威に対して有効かである。通信経路の盗聴や改ざんに対して、TLS がどの程度効くのかを確認する。第二に、監査や規制に対して説明できるかである。転送時暗号化の状態、例外、証拠を示せるかを確認する。第三に、運用し続けられるかである。証明書、認証局、更新、失効、障害対応を継続できるかを確認する。この三つのうち一つだけを見ても、設計判断としては不十分である。

したがって、本章の結論は単純である。運用できない安全は、安全ではない。強い暗号化構成を導入しても、期限切れを検出できず、証明書の用途を説明できず、例外を見直せず、障害時に復旧できないなら、それは安全対策ではなく不安定な依存関係になる。安全な設計とは、最も強い仕組みを選ぶことではない。守るべき対象に対して十分な制御を選び、その制御を維持し、監査し、退役できる形にすることである。クラウドにおける内部通信の暗号化も、この運用可能性から切り離して評価することはできない。

10. 技術と制度の速度差が、暗号化を統制へ変える

ここで、技術と制度の関係を少し広く見る必要がある。既稿では、生命科学の進歩と規制の関係を扱い、技術が先に可能性を広げ、制度が後から境界、責任、例外を定義する構造を整理した[30]。分野は異なるが、クラウドセキュリティにも同じ構造がある。クラウド基盤は、新しいサービス、抽象化、自動化を次々に追加する。一方で、監査、規制、組織ルールは、その後から「どこまでを許すか」「何を記録するか」「どの状態を準拠と呼ぶか」を定める。技術が先に選択肢を増やし、制度が後からその選択肢を管理可能な形へ整理する。この時間差が、暗号化を単なる通信保護ではなく、統制の対象へ変えていく。

この速度差は、VPC 内通信の暗号化を考えると分かりやすい。技術的には、選択肢はすでに複数ある。基盤側の転送時暗号化を使うこともできる。アプリケーション側で TLS を使うこともできる。内部認証局を使って証明書を発行することもできる。Service Connect のような仕組みで、サービス間通信の証明書管理を自動化することもできる。VPC Encryption Controls を使えば、暗号化状態を監視し、標準から外れた構成を見つけ、場合によっては平文通信を制限する方向へ進めることもできる。つまり、技術側は「どう守るか」の選択肢を細かく増やしている。

しかし、選択肢が増えることは、そのまま安全性が増えることではない。第一段階では、技術の進歩によって、より多くの通信経路を暗号化できるようになる。これは保護の可能性を広げる。第二段階では、その可能性が増えた結果、組織はどの通信にどの保護を適用するのかを決めなければならなくなる。すべてを同じ水準で守るのか。扱うデータに応じて変えるのか。VPC 内通信でも暗号化を標準にするのか。自己署名証明書を例外的に認めるのか。内部認証局を必須にするのか。これらを決めなければ、技術的な選択肢は増えても、組織としての判断は曖昧なまま残る。

ここで制度が現れる。制度とは、法律や規制だけを指すのではない。監査基準、業界標準、顧客要求、社内ポリシー、設計レビュー基準、例外承認手続きも制度である。制度は、技術が作った選択肢の中から、組織として許すもの、許さないもの、条件付きで許すものを定義する。たとえば、外部公開通信は必ず HTTPS にする。特定のデータを扱うサービス間通信は転送時暗号化を必須にする。自己署名証明書を使う場合は、用途と範囲を文書化する。一定期間を過ぎた例外は再承認を必要とする。このように、制度は技術構成を責任ある判断へ変換する。

この関係にも二段階の因果がある。まず、クラウド技術は抽象化と自動化によって、通信経路を増やし、サービスを細かく分割し、暗号化を複数の層で実装できるようにする。これにより、従来よりも柔軟な構成が可能になる。次に、その柔軟性は、判断のばらつき、例外の増加、責任境界の曖昧化を生む。だから制度が必要になる。制度は柔軟性を否定するためではなく、柔軟性が組織の中で説明不能な状態へ崩れないようにするためにある。つまり、技術が可能性を広げ、制度がその可能性に境界を与える。

領域	増えるもの	制度が定義するもの
クラウド基盤	基盤側暗号化、監視、強制、サービス間通信の自動化といった選択肢が増える。	どの基盤機能を標準として使い、どの構成を非準拠とみなすかを定義する。
アプリケーション	サービス分割、内部 API、コンテナ間通信、相互 TLS などの通信経路が増える。	どの通信に暗号化や相手確認を要求し、どの単位で証明書を管理するかを定義する。
運用	証明書、認証局、期限、失効、例外、監視項目などの管理対象が増える。	誰が管理し、いつ更新し、どの状態を異常とし、どの手順で復旧するかを定義する。
監査	確認すべき構成、証跡、例外、準拠状態が増える。	どの証拠を残し、どの周期で確認し、どの例外を承認済みとみなすかを定義する。

この表が示しているのは、制度が技術の外側にある飾りではないということである。クラウド基盤が複雑になり、アプリケーションが分散し、運用対象が増え、監査項目が増えるほど、制度は技術構成の一部として働く。たとえば、VPC 内通信を TLS 化するかどうかは、単に開発者が選ぶ実装方針ではない。扱うデータ、利用する AWS サービス、組織標準、監査要求、運用能力の交点で決まる。したがって、暗号化の設計は、技術仕様だけを読んでも決まらない。どの制度的要求の中でその技術を使うのかを見なければならない。

逆に、制度だけを見ても十分ではない。監査項目に「転送時暗号化」と書かれているからといって、どの層で暗号化するべきか、どの証明書を使うべきか、ALB からターゲットへの HTTPS がどの程度の相手確認を提供するのかまでは自動的に決まらない。第一段階では、制度が要求を与える。第二段階では、その要求を満たすために、技術側で脅威モデル、通信経路、証明書検証、運用負荷を整理する必要がある。制度は目的と制約を与えるが、具体的な構成の妥当性は技術的に評価しなければならない。

このため、技術だけで見れば過剰に見える対策が、監査では必要になることがある。たとえば、VPC 内通信で実際の盗聴可能性が低いと判断できる場合でも、転送時暗号化を標準として要求されるなら、TLS 化や基盤側の暗号化統制を導入する理由が生じる。反対に、監査項目を満たしていても、実際の脅威モデルには不十分な場合がある。たとえば、HTTPS を使っていても証明書検証が弱ければ、相手確認の保証は限定される。通信経路が暗号化されていても、端点が侵害されれば復号後の情報は守れない。したがって、技術的妥当性と制度的準拠は、どちらか一方に吸収できない。

ここで暗号化は、技術と制度の接点になる。強い暗号方式を選ぶことだけではなく、どの範囲で要求し、どの例外を認め、誰が確認し、どの状態を準拠とみなすかを決める必要がある。さらに、その判断は一度決めれば終わりではない。AWS の機能が増え、組織の標準が変わり、規制文書が更新され、扱うデータが変わり、システム構成が変われば、暗号化の妥当な範囲も変わる。技術の変化と制度の変化は同じ速度では進まないため、定期的に接続し直す必要がある。

本章の結論は、技術と制度の速度差が、暗号化を統制へ変えるということである。クラウドでは、暗号化は通信経路の性質であると同時に、組織の判断を外から検証可能にする仕組みになる。技術は、暗号化できる範囲を広げる。制度は、その範囲のうち、どこを標準とし、どこを例外とし、何を準拠と呼ぶのかを決める。両者を接続して初めて、VPC 内通信の暗号化は、単なる設定値ではなく、信頼境界を維持するための統制として機能する。

11. 信頼境界は、前提ではなく設計される

ここまで見てきた論点をまとめると、VPC 内通信を TLS で扱うかどうかは、単なる暗号化設定の問題ではない。第一に、クラウドの内部は、物理的な安全地帯ではなく、VPC、セキュリティグループ、ロードバランサー、IAM、証明書、監査機能によって構成される。第二に、TLS は、機密性、完全性、相手確認、監査説明という複数の意味を持つ。第三に、自己署名証明書、Private CA、相互 TLS、基盤側暗号化、VPC Encryption Controls のように、同じ暗号化でも担っている役割は構成によって異なる。したがって、VPC 内通信を暗号化するかどうかを判断するには、まず何を信頼し、何を検証し、何を説明するのかを分けなければならない。

ここで中心になるのが、信頼境界という考え方である。信頼境界とは、ある範囲までは前提として受け入れ、それを越える部分では検証や制御を必要とする境目である。従来の感覚では、社内ネットワークやデータセンター内ネットワークが、そのまま信頼境界として扱われることがあった。しかしクラウドでは、境界は物理的な壁や配線ではなく、設定、権限、通信方式、証明書、監査機能の組み合わせによって作られる。つまり、信頼境界は最初から自然に存在するものではない。設計によって置かれ、運用によって維持され、監査によって確認されるものである。

この違いには、二段階の因果関係がある。第一段階では、クラウドが物理的な構成を抽象化することで、内部と外部の境界が見えにくくなる。利用者は VPC、サブネット、セキュリティグループ、ロードバランサー、マネージドサービスを組み合わせてシステムを作るが、その背後の物理経路を直接管理するわけではない。第二段階では、物理境界が見えにくくなるため、代わりに論理境界を明示しなければならなくなる。どの通信を閉域内として扱うのか。どの通信に TLS を求めるのか。どの証明書を信頼するのか。どの権限で監視や設定変更を許すのか。これらを決めることが、クラウドにおける信頼境界の設計になる。

このとき重要なのは、「内部だから信頼する」でも「すべて TLS にすればよい」でもない。内部だから信頼するという考え方は、内部という言葉に過剰な意味を持たせる。すべて TLS にすればよいという考え方は、TLS が何を保証し、何を保証しないのかを曖昧にする。必要なのは、信頼してよい範囲と検証すべき範囲を明示することである。ALB からターゲットへの通信を自己署名証明書で暗号化するなら、それは主に経路暗号化であり、厳密な相手確認ではない。Private CA や相互 TLS を使うなら、相手確認を強められるが、証明書管理という新しい運用責任が生じる。VPC Encryption Controls を使うなら、暗号化状態を基盤側で監視・強制できるが、既存構成の非準拠箇所や例外管理と向き合う必要がある。

ここで起こるのは、信頼の移動である。HTTP のままにする場合、通信経路の保護を VPC の到達制御、AWS 基盤側の保護、運用上の閉域性に大きく委ねる。自己署名証明書で HTTPS にする場合、経路上の平文を減らす一方で、相手確認はネットワーク制御や構成管理に依存する。Private CA や相互 TLS を使う場合、相手確認を証明書基盤に移す。VPC Encryption Controls を使う場合、暗号化状態の確認を基盤側の統制へ移す。どの選択肢でも、信頼が消えるわけではない。どこを信頼し、どこを検証し、どこに責任を置くかが変わるだけである。

目的	主な選択肢	判断の要点
閉域内で十分と判断する	HTTP を維持し、脅威モデルと前提を文書化する。	なぜ平文通信を許すのか、どの境界を信頼しているのか、どのデータなら許容できるのかを残す必要がある。
平文区間を減らす	ALB からターゲットへ HTTPS で転送する。	自己署名証明書の場合、真正性保証ではなく経路暗号化として位置づけ、相手確認をどの層に委ねるのかを明確にする。
内部サービスの相手確認を強める	Private CA、相互 TLS、サービス間証明書を使う。	証明書の発行、失効、更新、監視、所有者管理まで運用する必要がある。
組織標準として強制する	VPC Encryption Controls や構成監査を使う。	非準拠リソース、例外、移行計画、標準変更時の影響を管理する必要がある。
監査で説明できる状態にする	暗号化方針、例外管理、証跡、構成確認を組み合わせる。	暗号化されていることだけでなく、なぜその構成を採用したのかを説明できる必要がある。

この表は、選択肢の優劣を単純に並べたものではない。HTTP のままにする判断にも、自己署名証明書を使う判断にも、Private CA を使う判断にも、基盤側の統制を使う判断にも、それぞれ成立する条件がある。重要なのは、どの構成が最も強いかではなく、どの目的に対してどの制御を割り当てているかである。閉域性を信頼するなら、その根拠を文書化しなければならない。経路暗号化を目的にするなら、相手確認とは切り分けなければならない。相手確認を強めるなら、証明書基盤を運用しなければならない。組織標準として強制するなら、非準拠と例外を管理しなければならない。

この整理から分かるのは、安全な設計とは、信頼をなくすことではないという点である。どのようなシステムでも、何かを信頼しなければ動かない。AWS の基盤を信頼する。VPC の到達制御を信頼する。証明書を発行する認証局を信頼する。IAM の権限管理を信頼する。監査機能の検出結果を信頼する。問題は、信頼そのものではなく、信頼している範囲が暗黙のまま残ることである。暗黙の信頼は、設計レビューでは見落とされ、障害時には原因を特定しにくくし、監査時には説明できない例外として現れる。

したがって、信頼境界を設計するとは、信頼する対象を減らすことだけではない。信頼する対象を明示し、その信頼が破れたときに何が起こるかを考え、必要な場所に検証や監視を置くことである。たとえば、VPC の閉域性を信頼するなら、セキュリティグループ、経路、公開設定、接続元を確認する必要がある。証明書基盤を信頼するなら、認証局の権限、証明書の発行履歴、失効手順を管理する必要がある。VPC Encryption Controls を信頼するなら、非準拠の検出結果、例外設定、強制範囲を運用に組み込む必要がある。信頼は前提ではなく、確認可能な構成として実装されなければならない。

この視点に立つと、VPC 内通信の TLS 化をめぐる議論は、単なる暗号化の有無から離れる。問うべきことは、通信が暗号化されているかだけではない。誰が通信できるのか。通信相手をどの層で確認しているのか。通信内容はどの区間で平文になるのか。証明書は誰が発行し、誰が更新し、誰が失効できるのか。平文通信を残す場合、その理由と期限は何か。監査時に、どの証拠で説明するのか。これらの問いに答えられる状態が、クラウドにおける信頼境界の設計である。

つまり、クラウド設計とは、何を信頼するかを暗黙に決める作業ではない。信頼する範囲を部品の組み合わせで記述し、必要に応じて検証し、組織として説明できる状態にする作業である。VPC 内通信を TLS で扱うかどうかは、その一部にすぎない。しかし、その一部を丁寧に見るだけでも、クラウドでは内部が自然な安全地帯ではなく、設計される境界であることが分かる。暗号化は、その境界を見える形にするための重要な手段である。

12. 結論――暗号化とは、信頼境界を設計することである

VPC 内通信の TLS は、必要か不要かを一律に決められるものではない。扱うデータ、通信経路、AWS の構成、監査要求、運用能力、障害時の復旧手順によって答えは変わる。技術的な脅威だけを見れば、TLS によって新たに防げる攻撃が限定的な場合もある。たとえば、VPC 内の到達制御、AWS 基盤側の保護、ロードバランサーとターゲットの関係が整理されており、扱うデータの機微性も高くない場合には、内部区間の HTTP を合理的な例外として説明できることがある。逆に、規制対象データ、複数アカウント、外部接続、サービス間認証、監査要求、顧客契約が関係する場合には、強い暗号化と相手確認が必要になる。

したがって、本稿の結論は「VPC 内通信は常に TLS 化すべきである」ではない。また、「VPC 内通信なら TLS は不要である」でもない。どちらの断定も、クラウドにおける通信の性質を単純化しすぎている。前者は、TLS が端点侵害、権限濫用、設定ミス、証明書運用の失敗まで防ぐかのように見せてしまう。後者は、内部という言葉に過剰な信頼を置き、監査、準拠、説明責任、例外管理の問題を見落とす。必要なのは、暗号化の有無を結論として先に置くことではなく、どの信頼境界をどの制御で支えるのかを順に確認することである。

本稿で確認してきた因果関係は、次のように整理できる。第一に、クラウドでは内部が物理的な安全地帯ではなく、VPC、サブネット、セキュリティグループ、ロードバランサー、IAM、証明書、監査機能によって構成される。第二に、内部が構成された境界である以上、その境界をどこまで信頼するかを明示しなければならない。第三に、その信頼を支える手段として、TLS、証明書、Private CA、相互 TLS、基盤側暗号化、VPC Encryption Controls などが選択肢になる。第四に、それらの制御は導入すれば終わりではなく、証明書更新、失効、例外管理、監査証跡、障害時復旧を含めて運用しなければならない。

この連鎖を逆にたどると、暗号化の位置づけも明確になる。TLS は、単に通信内容を読ませにくくするための技術ではない。証明書を検証すれば、通信相手を確認する仕組みにもなる。組織標準として定義すれば、構成のばらつきを抑える基準になる。監査機能と結びつければ、平文通信や非準拠リソースを検出する統制になる。例外管理と結びつければ、あえて暗号化しない通信についても、理由、範囲、期限、承認者を説明できるようになる。暗号化は、通信経路上の保護であると同時に、組織が何を信頼しているのかを外から確認できる形にするための設計要素である。

問い	不十分な答え	本稿での答え
VPC 内通信は安全か	内部だから安全である、または内部でも危険であると一律に判断する。	どの通信経路を、どの到達制御、基盤保護、権限管理、監査機能で支えているかを確認する。
TLS を使えば安全か	TLS の有無だけで安全性を判断する。	TLS が機密性、完全性、相手確認、監査説明のどれを担い、どれを担っていないかを分ける。
自己署名証明書でよいか	自己署名証明書は無意味、または自己署名証明書でも安全と単純化する。	経路暗号化として使うのか、相手確認まで求めるのかを分けて判断する。
基盤側暗号化で十分か	AWS 側で暗号化されるならアプリケーション側 TLS は不要と考える。	基盤側暗号化が守る層と、アプリケーション側 TLS が表すサービス間の責任境界を分ける。
監査で求められるなら導入すればよいか	監査項目を満たすことを安全性そのものとみなす。	監査は説明可能性を支える層であり、実際の脅威モデルと運用可能性を別に評価する。

この表から分かるように、VPC 内通信の暗号化判断は、単独の設定値ではなく、複数の評価軸の交点にある。脅威分析は、暗号化がどの攻撃に効くのかを示す。クラウド構成の理解は、どの層を AWS 基盤に委ね、どの層を利用者が設計するのかを示す。証明書と認証局の設計は、通信相手をどの単位で確認するのかを示す。監査と規制は、その状態を組織として説明できるかを問う。運用設計は、その制御を継続して維持できるかを問う。これらのどれか一つだけを見ても、結論は安定しない。

ここで、本稿の中心命題に戻る。クラウドにおける暗号化の意味は、通信を読ませないことだけではない。暗号化は、どこまでを信頼し、どこからを検証し、どの例外を許し、どの状態を組織として説明できるのかを表す設計である。VPC 内通信を TLS 化するかどうかは、その設計の一部である。HTTP を維持するなら、信頼する境界と受け入れるリスクを文書化する必要がある。自己署名証明書を使うなら、経路暗号化を主目的とすることを明示する必要がある。Private CA や相互 TLS を使うなら、相手確認と証明書運用の責任を引き受ける必要がある。VPC Encryption Controls を使うなら、標準、非準拠、例外、移行計画を管理する必要がある。

したがって、VPC 内通信を考えるときに問うべきなのは、「内部だから安全か」でも「TLS だから安全か」でもない。問うべきなのは、内部とは何か、何を信頼しているのか、その信頼はどの制御で支えられているのか、その制御はどの層で効いているのか、失敗したときに何が見えるのか、監査されたときに何を説明できるのかである。クラウドでは、内部も設計対象になる。暗号化とは、その内部に引かれる信頼境界を、通信、証明書、権限、監査、運用の組み合わせとして明示する行為なのである。

この結論は、暗号化を過小評価するものではない。むしろ、暗号化を単なる安全そうな印象から引き離し、実際の設計判断の中に置き直すものである。暗号化は重要である。しかし、どの層で行われ、何を保証し、何を保証せず、誰が維持し、どの証拠で説明するのかが分からなければ、その重要性は実務上の安全へつながらない。クラウドにおける安全は、内部を信じることでも、暗号化を増やすことでも完結しない。安全とは、信頼する範囲を明示し、検証する場所を決め、例外を管理し、運用し続けられる形にすることである。

参考文献

id774, 暗号化だけでは情報は守れない（2026-06-29）. https://blog.id774.net/entry/2026/06/29/4916/
Amazon Web Services, Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/
Amazon Web Services, What is Amazon VPC? https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
Amazon Web Services, Control traffic to your AWS resources using security groups. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
IETF, RFC 9110: HTTP Semantics. https://datatracker.ietf.org/doc/html/rfc9110
IETF, RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. https://datatracker.ietf.org/doc/html/rfc8446
IETF, RFC 9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). https://datatracker.ietf.org/doc/rfc9325/
IETF, RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://datatracker.ietf.org/doc/html/rfc5280
IETF, RFC 9525: Service Identity in TLS. https://datatracker.ietf.org/doc/html/rfc9525
Amazon Web Services, Create an HTTPS listener for your Application Load Balancer. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html
Amazon Web Services, Target groups for your Application Load Balancers. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html
Amazon Web Services, Mutual authentication with TLS in Application Load Balancer. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html
Amazon Web Services, Data protection in Amazon EC2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html
Amazon Web Services, The components of the Nitro System. https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html
Amazon Web Services, What is Traffic Mirroring? https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html
Amazon Web Services, Network security best practices for Amazon ECS. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-network.html
Amazon Web Services, AWS Private Certificate Authority Documentation. https://docs.aws.amazon.com/privateca/
Amazon Web Services, Encrypt Amazon ECS Service Connect traffic. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect-tls.html
Amazon Web Services, SEC09-BP02 Enforce encryption in transit. https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html
Amazon Web Services, Enforce VPC encryption in transit. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html
Amazon Web Services, AWS introduces new VPC Encryption Controls and further raises the bar on data encryption. https://aws.amazon.com/about-aws/whats-new/2025/11/aws-vpc-encryption-controls/
Amazon Web Services, Operational Best Practices for FedRAMP(Moderate). https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-fedramp-moderate.html
NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
NIST, Zero Trust Architecture, SP 800-207. https://csrc.nist.gov/pubs/sp/800/207/final
PCI Security Standards Council, PCI DSS Document Library. https://www.pcisecuritystandards.org/document_library/
U.S. Department of Health & Human Services, Summary of the HIPAA Security Rule. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
id774, 暗号化ディスクを長期運用するための設計（2026-05-30）. https://blog.id774.net/entry/2026/05/30/4818/
id774, 暗号化ディスク運用手順を整理する（2026-05-31）. https://blog.id774.net/entry/2026/05/31/4829/
id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
id774, 生命科学は規制より速く進んでよいのか（2026-06-13）. https://blog.id774.net/entry/2026/06/13/4886/