In Transit暗号化

トランジット暗号化で

1）制御の定義と限界

In-transit暗号化は、ネットワーク伝送経路全体（ブラウザ↔サーバー、サービス↔サービス、エージェント↔ブローカー、データベース↔アプリケーション、データセンター↔データセンター）に沿ったデータの保護です。

対象：公共およびプライベートAPI （HTTP/HTTPS、 gRPC）、ストリーミングおよびブローカー（Kafka、 NATS、 RabbitMQ）、 WebSocket、ネットワーク上のデータベースとキャッシュ、クラスタ内のサービストラフィック、VPN間データセンタークラウド、DNSリクエスト、モバイル/IoTクライアント。

完全にカバーしていないもの：エンドポイントへの攻撃（ホスト/ブラウザの妥協）、アプリケーションの脆弱性、ログ/ダンプからの漏洩。これは、個別のコントロール（A&A、権利最小化、安静時の暗号化、安全なログ記録）によって解決されます。

2）脅威モデルとターゲット

リスク：トラフィック傍受/スプーフィング（MITM）、プロトコルのダウングレード/暗号スイート、偽の証明書/CA、キー漏洩、SNI/メタデータ攻撃、混合コンテンツ、バランサーのTLS誤植、安全でないサービス相互接続。

目的：

1.暗号認証による機密性+完全性。

2.ダウングレードへの反対（厳格なポリシーと設定）。

3.当事者の識別（サーバー、必要に応じて-相互）。

4.管理された証明書/キーライフサイクルと監査。

5.セキュリティトレードオフなしのパフォーマンスプロファイル。

3）基本原則

TLSはデフォルトでどこでもあります。外部および内部トラフィック-暗号化。

現代のバージョン。TLS 1。標準として3；TLS 1。2-厳格なポリシーの下でのみ。1を無効にします。0/1.1.

PFSを備えたAEAD暗号スイート。AES-GCMまたはChaCha20-Poly1305；PFS経由（EC） DHE。
曲線/キー検査X25519（できれば）またはsecp256r1 （P-256）。RSAキー≥ 2048で、ECDSA （P-256）よりも優れています。
信頼が乏しいmTLS。相互認証によるサービス間チャネル、管理API、ブローカー、データベース。
Web用のHSTS。パブリックドメインのHTTPS+preloadを強制しました。
「encrypt-and-encrypt-again」を意識的に。周囲のTLS終了+バックエンドまたはエンドツーエンドのパススルーへの再暗号化-脅威モデルに従って選択します。
暗号アジリティ。ダウンタイムがゼロのカーブ/スイート/バージョンを変更する機能。

4）プロトコルスタックとスクリプト

4.1 HTTP/2、 HTTP/3 （QUIC）、 gRPC、 WebSocket

ALPN： HTTP/2のためのh2、 HTTP/3のためのh3；h2c阻害（TLSなし）。
HTTP/3/QUIC：レイテンシ、埋め込み0-RTT、および複合移行を低減します。0-RTTは選択的に許可します（リプレイリスク）。
gRPC： h2/h3に；必須のTLS、オプションのmTLS+RPCごとの承認。
WebSocket： wss：//のみ；プロキシ/バランサー-ドメインの正しいアップグレードとTLSピン留め。

4.2インターサービストラフィックとサービスメッシュ

サイドカーモデル（Istio/Linkerdなど）自動mTLS、パーミッションポリシー、証明書のローテーション。
SPIFFE/SPIRE。分散サービスアイデンティティ（SPIFFE ID）、 SVID証明書、短いTTL。
TLSパラメータは集中化されます。サービスコードの設定の不一致を最小限に抑えます。

4.3ブローカー/ストリーミング/キュー

カフカ/NATS/RabbitMQ： kliyent↔brokerとbroker↔brokerのためのTLS；可能であればmTLS。
SASL over TLS： mTLSが不可能な場合、トークン/ログインによる認証が、チャンネルを暗号化します。
ACLとトピックの承認。暗号化≠アクセス制御。

4.4データベースとキャッシュ

PostgreSQL/MySQL/SQL Server： TLS、 CN/SAN検証、CA pin/rootを有効にします。
Redis/Memcached： stunnel/TLS大根を使用します。プロダクトの明白な交通の禁止。

4.5ネットワーク/トンネル

データセンター/クラウド間：IPsec （IKEv2）またはWireGuard（現代のプリミティブのセット）。
管理者アクセス：近代的なKEH/暗号でSSH；パスワードなし、キー/SSOのみ。

4.6つのDNSおよび補助プロトコル

DNS over HTTPS （DoH ）/DNS over TLS （DoT）クライアントおよびクラスタ内で可能な場合。
混合コンテンツを無効にします。http：//ページのhttps：//には何もありません。

5）証明書、PKIおよびキー管理

PKIモデル：外部ドメイン-公開CA；内部トラフィック-独自のCAまたはSPIRE-CA。
自動化：Kubernetes用ACME/Cert-Manager、短いTTL、自動回転。
OCSPホチキスのCRL。前面にステープリングをオンにします。定期的にチェーンを更新します。
ピン留め-慎重に。モバイル/デスクトップクライアント-緊急ローリングメカニズムを備えたピンCA/SPKI。
キーの貯蔵：HSM/KMS/秘密の貯蔵の秘密鍵；最低の露出；ロギング禁止。

6）構成： 練習のプロフィール

推奨TLSプロファイル（外周）：

バージョン：TLS 1。3（必須）、TLS 1。2（フォールバック）。

スイート（例）：

TLS 1。3： 'TLS_AES_128_GCM_SHA256'、 'TLS_AES_256_GCM_SHA384'、 'TLS_CHACHA20_POLY1305_SHA256'。
TLS 1。2： 'ECDHE-ECDSA-AES128-GCM-SHA256'、 'ECDHE-RSA-AES128-GCM-SHA256'（必要に応じて+オプションAES256/CHACHA20）。
曲線：X25519、 secp256r1。
証明書：ECDSA優先、RSAフォールバック。
安全なヘッダー：'Strict-Transport-Security'、 'X-Content-Type-Options'、' X-Frame-Options'（ケース別）、'Referrer-Policy'。
クッキー：'セキュア'、'HttpOnly'、 'SameSite' （Lax/Strict by design）。

内部の周囲（mTLS）：

クライアント証明書が必要です。
短いTTLクライアントSVID（時間/日）、自動回転。
ポリシー：誰が誰に接続することができます（意図ベース/メッシュ認証を介して動作）。

7）性能および信頼性

ハードウェアアクセラレーション：AES-NI/ARMv8 Crypto、 AES-NIなしのCPUでの優先ChaCha20-Poly1305。
セッション再開：TLS 1。3チケット；寿命（香水と安全性のバランス）を考えてください。
0-RTT： idempotentクエリのみ；リプレイ（サーバーのアンチリプレイ機構）から保護します。
バランサー/プロキシ：明確に終了とパススルーを選択します。終了時-バックエンドに再暗号化します。
観測可能性：ALPNハンドシェイク/エラー/ネゴシエーションメトリック、TLSパーセンテージ1。3の証明書の有効期限、OCSPの状態。

8）テストおよび検証

TLSプロファイルのスキャン。サポートされているバージョン/スイート/カーブおよびHSTS/OCSPの定期的なチェック。
否定的なテスト：ダウングレードの禁止、弱いスーツの拒否、SNIなしの接続の失敗/有効なチェーン証明書なし。
Channel pentest： MITMシミュレーション、モバイルクライアントのピンチェック、リプレイ試行0-RTT。
カオステスト：証明書の有効期限/失効、OCSP/CAの利用不可。

9）頻繁な間違いとそれらを回避する方法

TLSは有効ですが、ホストの検証はありません。私たちは常にCN/SANをチェックし、'InsecureSkipVerify'を禁止します。
混合コンテンツ。httpsページのhttpリソースをブロックし、CSPを使用します。
弱い/古いバージョンとスーツ。TLS 1を無効にします。0/1.1、 CBC/RC4/3DES。
内向きの再暗号化の欠如。バランサーからアプリケーションへの明白なトラフィックはリスクです。
長寿命証明書。短いTTLと自動更新を行います。
プロキシの後ろの悪いSNI/ALPN。TLSのパス/終了との正しいSNI/ALPN伝達。

10）ミニレシピ（構成断片）

Nginx（フロント、TLS 1。3/1.2のHSTS、 OCSPのステープリング）：


ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Envoy（サービス間のmTLS、スキーム）：


transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

WireGuard（データセンタートンネル、回路図）：


[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11）方針とコンプライアンス

最低要件：TLS 1。可能な限り3。TLS 1。2-スイートセットが限られています。
規制：PCI DSS/金融セクター-弱いバージョン/スイートの禁止。必須の回転および監査。
Zero Trustアプローチ：ワークロードごとのアイデンティティ、継続的な検証、サービスレベルのポリシー。

12）操作およびSLO

SLO：ハンドシェイク≥ 99％成功し、TLS 1で95％のトラフィックを≥しました。3の0％混合された内容。
アラート：証明書の有効期限（<14日）、ハンドシェイクの失敗の増加、TLS 1シェアの低下。3のOCSPのステープルエラー。
手順：CA/ルートの緊急交換、侵害されたキーの失効、0-RTTの無効化。

13）チェックリスト

レイアウトする前に：

TLS 1が無効になっています。0/1.1と弱いスイート、AEADとPFSが含まれています。
ALPN設定（h2/h3）；h2cの禁止。
HSTSが有効になっている（パブリックドメイン用）、混在コンテンツはありません。
証明書は自動更新され、OCSPステープリングが実行されています。
内部チャネルはmTLS（またはWireGuard/IPsec相当）で保護されています。
クライアント/SDKのホスト/チェーン検証を検証しました。

操作：

TLS/ALPN/エラーと有効期限のバージョンを監視します。
暗号アジリティプラン（新しいスイート/曲線への翻訳）。
周期的なチャンネルペンテストと設定レビュー。

14） FAQ

Q： TLSは周囲で十分ですか？
ああ、いやいや。内部トラフィックも暗号化されなければなりません（mTLS/tunnels/mesh）、特にクラウドやマルチリース中に。

Q： 0-RTTが必要ですか？
A： idempotentリクエストに対してpointwiseを有効にします。そうでなければ、リプレイのリスクのために無効にします。

Q：データセンター間のために選ぶべき何か？IPsecまたはWireGuard？
A： WireGuardはシンプルで高速です。IPsecは成熟しており、広くサポートされています。両方とも正しく設定されている場合に有効です。

Q：外出先でどのようにWebhookを保護していますか？
A：最新のプロファイル+送信者証明書確認（mTLSの場合）+ペイロード署名およびタイムスタンプ検証（Webhook配信保証、要求署名および検証を参照）を持つHTTPS。

In Transit暗号化

トランジット暗号化で

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です