TLSから見るSREの未来

2025/07/11, SRE NEXT 2025 IN TOKYO, TOC 有明

WebにおけるTLS証明書は、安全な通信を実現するための基盤技術として、現在も進化を続けています。Let's Encryptをはじめとする自動発行可能な認証局の登場は、Web全体のセキュリティレベル向上に大きく貢献しており、クラウドプロバイダなども認証局を提供することで、開発者はより容易にサービスを安全に保てるようになっています。

本発表では、進化し続けるTLSを取り巻く状況が、SREの役割にどのような影響を与えていくのかを改めて考察します。 具体的には、セキュリティ強化の流れとしての証明書有効期限の短縮化、より効率的で安全な暗号化方式であるECDSA証明書へのの移行について俯瞰することで、SRE活動の一助となるヒントを提供します。

Transcript

1. @atpons 浅野 大我 / Taiga ASANO TLSから見るSREの未来
2. 自己紹介 浅野 大我 (@atpons) 2020~ スマートフォンゲームのバックエンドエンジニア / SRE 2024~ STORES 株式会社 技術推進本部 利用しているパブリッククラウドのコスト・アカウントの管理 プロダクト間の連携基盤や認証認可基盤・セキュリティの課題などの解決 2
3. 今日話すこと TLSの進化を知り セキュリティと運用効率を両立するSREingに生かす 3
4. アジェンダ 1. TLSの重要性 2. TLS証明書の最新動向 3. SREの役割と未来について 4
5. TLSとは 5 Transport Layer Security ＝ 通信を安全にするための仕組み → どのように？
6. TLSの構成要素 6 認証 正当な通信相手かを 判定 要素技術 ECDSA / RSA 機密性 第三者による盗聴を 防ぐ 要素技術 AES-GCM / ChaCha20-Poly1305 完全性 データの改ざん検知 要素技術 AES-GCM / ChaCha20-Poly1305 TLS 1.3+ AEAD (認証付き暗号) によって同じに
7. サーバー TLS の仕組み (ざっくり) 7 PKI (CA) クライアント 鍵ペア 鍵ペア サーバとクライアントで 公開鍵をやりとり 証明書 証明書鍵ペア 署名 共通鍵 共通鍵 鍵ペアを使って 通信用の共通鍵を導出 サーバーの署名を検証 認証 機密性/完全性 証明書による認証と、通信の暗号化がセット
8. TLSの活用範囲の拡大 8 • サーバー・クライアント間の通信 ◦ HTTPS, HTTP/2 • クライアント証明書を活用した通信 (mTLS) ◦ 先ほどの仕組みに加えてクライアント側も証明書を提示する ▪ SSL/TLS-VPN/EAP ▪ サービスメッシュ, gRPC などのサービス間通信 ▪ Kubernetesクラスタ間の通信
9. アジェンダ 1. TLSの重要性 2. TLS証明書の最新動向 3. SREの役割と未来について 9
10. TLSで近年注目されている変化 10 • 自動化の加速 • 証明書有効期限の短縮化 • 暗号方式の進化
11. TLSで近年注目されている変化 11 • 自動化の加速 • 証明書有効期限の短縮化 • 暗号方式の進化
12. 証明書は手動・有償から自動・無料へ 12 - かつてのTLS証明書の常識 - 取得や更新は手作業かつ有償 - 年1回・もしくは長期間なら数年に1回期限到達で更新 CSRの作成 認証局(CA)に申請 ドメイン所有権確認 審査・発行 証明書受け取り 👤 ユーザー 🏢 商用認証局
13. 証明書は手動・有償から自動・無料へ 13 - 現在のTLS証明書の常識 - クラウドプロバイダ・Let’s Encryptなどの認証局を利用 - ツールで自動化して有効期限は短く、自動でローテーション CSRの作成（自動） API/Webで申請 ドメイン所有権確認 発行 証明書適用 👤 ユーザー 🏢 認証局 DNS-01・ HTTP-01 で自動化 自動化
14. TLSで近年注目されている変化 14 • 自動化の加速 • 証明書有効期限の短縮化 • 暗号方式の進化
15. 自動化による証明書有効期限の短縮化 15 - 自動化が加速したことにより、90日 (Let’s Encrypt)の証明書が当然 の世界になった - 証明書の期間を短くすることで、データとしての信頼性を向上させる - 業界団体 CA/B Forum による有効期限短縮の変遷 - 2020年に825日 → 398日に短縮された - 今後段階的に短縮され2029年から47日になることが決定 オンプレミス・クラウド関わらず より証明書更新の自動化が求められる時代に
16. TLSで近年注目されている変化 16 • 自動化の加速 • 証明書有効期限の短縮化 • 暗号方式の進化
17. TLS1.2からTLS1.3へ 17 • 前方秘匿性が必ず保証 ◦ 基本 ECDHE が利用されることで、セッション鍵が使い捨てに • 暗号化通信確立までの時間短縮 ◦ 1-RTT で接続確立が可能になった ▪ TLS 1.2までは2-RTT必要だったが、TLS 1.3では最初にクラ イアントから鍵交換に必要な情報が渡るため、すぐに鍵交換が 完了する ◦ 再接続時の 0-RTT Resumption の活用による高速化 ▪ セキュリティリスクもあるが、CDNなどのコンテンツ配信に おいては十分有用
18. RSAから EC（楕円曲線暗号）へ 18 • TLSにおけるECへの移行 ◦ 鍵交換の変化 ▪ RSA鍵交換はTLS 1.3で廃止、基本はECDHE ◦ 署名方式の進化 ▪ TLS証明書の署名も RSA → ECDSA / Ed25519 への移行が進 行中 • ECのメリット ◦ より短い鍵長で同等以上の安全性を得ることができる ◦ 計算コストが低く、証明書のサイズが小さいため通信が高速に
19. 証明書のEC対応 19 • TLS証明書で利用される公開鍵と署名にもRSAではなくECが利用可能 ◦ ECDSA・Ed25519が利用可能 • 対応状況 ◦ Let’s EncryptではECDSA証明書の発行が可能 ◦ Amazon Web Services, Google Cloudなどのパブリッククラウ ドでも発行が可能になりつつある • 一部クラウドサービスや古いデバイスの対応が課題 証明書・署名検証のEC化により 通信の高速化のメリットがある
20. RSA証明書・EC証明書の違い 20 等価安全性 2048 bit RSA = 112 bit 安全性 256 bit ECDSA = 128 bit 安全性
21. アジェンダ 1. TLSの重要性 2. TLS証明書の最新動向 3. SREの役割と未来について 21
22. 証明書管理におけるSREアプローチ 22 • 手動での証明書更新 → 自動化: 自動取得・更新 • 証明書有効期限の監視 → 可観測性: 証明書の状態を監視する • 新たな暗号スイート・仕様への対応 → 継続的な改善: TLS 1.3、今後の PQC (ポスト量子暗号) 対応
23. 証明書更新の自動化 23 • パブリッククラウドの認証局の活用、ACME に対応した認証局の利用 ◦ 例) Google Trust Services, Amazon Certificate Manager, Let’s Encrypt + Certbot, Lego ◦ ドメインの所有権の確認を自動で行い、発行からインストールま で自動で行う仕組みを構築する時代に
24. 証明書の手動更新と監視 24 • 自動化に対応した認証局が利用できない場合でも、証明書の適切な管 理ができるようにする ◦ 基本的には自動で更新できるようにするのが望ましい ◦ 証明書を始めとした機密情報を一元管理できるツールの利用 ◦ 例) HashiCorp Vault, 各種クラウドのシークレットマネージャ • 証明書の有効期限もアップタイムと同様に定期的に確認する ◦ 更新作業をできる限り自動で行うようにした上で、定期的に監視 することで期限切れを防止する
25. 新たな暗号スイート・仕様への対応 25 • TLSで利用される暗号スイート（鍵交換・認証・暗号化）は変化して いる ◦ 鍵交換: RSAからECDHEへ ◦ 認証: RSAからECヘ ◦ 暗号化・認証: AES-GCM・ChaChaPoly-1305へ 常に最新の暗号や、TLSの仕様のアップデートに 追従し、高速かつ安全な通信ができるようにする
26. まとめ 26 • 暗号技術は進化し続ける ◦ 証明書も監視や自動化の対象になる • SREとして、TLSの変化をキャッチアップを行い、安全で持続可能な運 用を支える必要がある ◦ 証明書更新の自動化や監視 ◦ 暗号やTLSの仕様の定期的なキャッチアップ ◦ 組織やサービスに合わせたTLSの使い方を模索しましょう