午前I問題

公開鍵基盤（PKI）における電子証明書に関する記述のうち、最も適切なものはどれか。

ア）電子証明書は公開鍵とその所有者を紐付けるものであり、認証局（CA）がデジタル署名を行うことで信頼性を担保する。

イ）電子証明書に含まれる公開鍵は、通信の暗号化と復号の両方に同一の鍵として使用される。

ウ）自己署名証明書（オレオレ証明書）は、認証局の署名がなくても信頼できる第三者による検証と同等の信頼性を持つ。

エ）証明書失効リスト（CRL）は一度発行されると更新されることはなく、失効した証明書の情報は永続的に同一の内容である。

午前I の解答・解説を見る

正解： ア）

解説：

  • ア）正解。電子証明書は「この公開鍵はこの主体（サーバやユーザ）のものである」という対応関係を、信頼された認証局（CA）が秘密鍵でデジタル署名することで保証する仕組みである。
  • イ）不正解。公開鍵暗号方式では公開鍵と秘密鍵は別物であり、暗号化に公開鍵、復号に対応する秘密鍵を使うなど非対称な用途で使われる。同一鍵で暗号化・復号を行うのは共通鍵（対称鍵）暗号方式の特徴である。
  • ウ）不正解。自己署名証明書は発行者自身が署名したものであり、第三者による身元確認・信頼の連鎖（チェーン）がないため、公的な認証局が発行した証明書と同等の信頼性は得られない。組織内など限定的な用途で使われることはあるが、経路上の第三者によるなりすまし検知には別途の仕組みが必要になる。
  • エ）不正解。CRL（Certificate Revocation List）は失効した証明書の情報を随時更新して発行するものであり、定期的に最新のリストが公開される。更新されない場合、新たに失効した証明書の検知ができなくなってしまう。

午前II問題

マイクロサービスアーキテクチャにおけるサービス間通信のセキュリティ対策として、mTLS（mutual TLS）をサービスメッシュ（例：Istio, Linkerd）で実現する仕組みの説明のうち、最も適切なものはどれか。

ア）mTLSはサーバ証明書のみを用いてサーバの真正性をクライアントが検証する方式であり、クライアント側の認証は別途アプリケーションレベルのAPIキーで行う必要がある。

イ）サービスメッシュでは各Podに付随するサイドカープロキシがmTLSのハンドシェイクと証明書の管理を透過的に行うため、アプリケーションコード自体を変更せずにサービス間通信を暗号化・相互認証できる。

ウ）mTLSを導入すれば通信内容が暗号化されるため、各サービスが呼び出し元の認可（どのサービスがどのAPIを呼び出せるか）を個別に検証する必要はなくなる。

エ）サービスメッシュにおけるmTLS用の証明書は、一度発行すれば有効期限を設けず永続的に使用することが推奨されている。

午前II の解答・解説を見る

正解： イ）

解説：

  • ア）不正解。mTLS（mutual TLS）は「相互」TLSという名のとおり、クライアント側も証明書を提示し、サーバ側がそれを検証する。サーバ・クライアント双方が互いの真正性を証明書で確認し合う方式であり、片方向認証ではない。
  • イ）正解。IstioなどのサービスメッシュではEnvoyなどのサイドカープロキシが各Podに配置され、サービス間通信のmTLSハンドシェイク・証明書の発行/ローテーション/検証をアプリケーション層から切り離して透過的に処理する。これにより開発者はアプリケーションコードにTLS処理を実装することなく、通信の暗号化と相互認証を実現できる。
  • ウ）不正解。mTLSは通信経路の暗号化と通信主体（サービス）の認証を提供するが、「認証されたサービスがどのリソース・APIにアクセスしてよいか」という認可（Authorization）は別レイヤーの話である。ゼロトラストの考え方では認証後も個々のリクエストに対する認可ポリシー（例：IstioのAuthorizationPolicy）を適用すべきである。
  • エ）不正解。証明書には有効期限を設け短命化（short-lived certificate）することがセキュリティのベストプラクティスである。サービスメッシュでは証明書を短い周期（例：数時間〜1日程度）で自動ローテーションすることで、秘密鍵が漏洩した際の悪用可能期間を最小化する設計が一般的である。

午後問題

物流管理システムを提供するE社は、モノリシックなシステムをマイクロサービスアーキテクチャへ移行し、Kubernetes上で20以上のサービスを稼働させている。各サービスはクラスタ内部のネットワークで自由に通信できる設定になっており、サービス間通信は平文のHTTPで行われていた。

セキュリティ監査で次の指摘を受けた。

  • クラスタ内部のPod間通信が暗号化されておらず、万一クラスタ内に侵入された場合、通信内容の盗聴や改ざんが可能な状態である
  • あるサービスが侵害された場合、そのサービスから他の全サービスのAPIへ制限なくアクセスできてしまう構成になっている（例：在庫管理サービスから決済サービスへ直接アクセス可能）
  • サービスの認証・認可ロジックが各サービスのアプリケーションコードに個別実装されており、実装漏れのあるサービスが一部存在した

設問1

この状況を改善するため、サービスメッシュを導入してmTLSによるサービス間通信の暗号化・認証を実現する方針とした。サービスメッシュのサイドカーパターンを採用することで、アプリケーションコードの改修に関してどのようなメリットが得られるか、具体的に述べよ。

設問1の解答・解説を見る

正解例： サイドカープロキシが各サービスのPodに自動的に配置され、TLSハンドシェイク・証明書の発行・ローテーション・検証をプロキシ層で透過的に処理するため、各サービスのアプリケーションコードにTLS通信やmTLS認証のロジックを個別に実装する必要がない。これにより実装漏れによるセキュリティホールのリスクを排除でき、開発チームはビジネスロジックに専念できる。既存の20以上のサービスに対しても、コード改修を最小限にしてメッシュへ組み込むことが可能になる。

解説・採点基準（計15点）：

採点項目キーワード配点
サイドカープロキシがTLS処理を透過的に肩代わりする点に言及サイドカー・透過的処理5点
アプリケーションコードの改修が最小限で済む点に言及コード改修不要・非侵襲的5点
実装漏れリスクの排除・統一的なセキュリティ担保に言及実装漏れ防止・一貫性5点

設問2

在庫管理サービスから決済サービスへ制限なくアクセスできてしまう問題に対して、mTLSによる認証に加えて実施すべき対策を、ゼロトラストの考え方に基づいて述べよ。

設問2の解答・解説を見る

正解例： mTLSによる相互認証はあくまで「通信相手のサービスが何者であるか」を検証するものであり、「そのサービスが何を許可されているか」の認可は別途制御する必要がある。ゼロトラストの「決して信頼せず、常に検証する」の考え方に基づき、サービスメッシュの認可ポリシー（例：IstioのAuthorizationPolicy）を用いて、サービスごとに通信を許可する送信元サービス・呼び出し可能なAPIパス・HTTPメソッドをホワイトリスト形式で明示的に定義する。例えば決済サービスへのアクセスは注文処理サービスからのみ許可し、在庫管理サービスからの直接アクセスは拒否する設定とすることで、最小権限の原則に基づいたマイクロサービス間の通信制御を実現する。

解説・採点基準（計15点）：

採点項目キーワード配点
mTLS（認証）と認可が別レイヤーである点への理解に言及認証と認可の分離4点
サービス単位での認可ポリシー（ホワイトリスト等）の設定に言及AuthorizationPolicy・許可リスト6点
ゼロトラスト・最小権限の原則に言及ゼロトラスト・最小権限5点

「ネットワークポリシー（NetworkPolicy）でPod間通信を制限する」という回答も、L3/L4レベルでの補完的な制御として部分点（最大10点）を与える。ただしL7（アプリケーション層）でのAPI単位の認可制御に言及がない場合は満点としない。

重要キーワード

用語説明
mTLSmutual TLS。通信の両当事者（クライアント・サーバ）が互いに証明書を提示し合い相互に真正性を検証するTLSの拡張方式
サービスメッシュマイクロサービス間の通信を管理するインフラ層。サイドカープロキシによりmTLS・トラフィック制御・可観測性を提供する
サイドカーパターン各サービスのPodに補助的なプロキシコンテナを併設し、通信処理を本体アプリケーションから分離するアーキテクチャパターン
認可ポリシー認証済みの主体に対し、どのリソース・操作へのアクセスを許可するかを定義する規則。認証とは異なるレイヤーの制御
ゼロトラスト内部・外部を問わずすべての通信を信頼せず、都度検証を行うセキュリティモデル（ゼロトラストも参照）
短命証明書有効期限を数時間〜数日程度に短縮した証明書。漏洩時の悪用可能期間を最小化するため自動ローテーションと組み合わせて用いる

まとめ

  • 午前I視点： PKIにおける電子証明書はCAの署名により公開鍵と主体を紐付ける仕組みであり、自己署名証明書との信頼性の違いを理解することが基礎となる。
  • 午前II視点： サービスメッシュのサイドカーパターンはmTLSをアプリケーションコードから切り離して透過的に実現する点が特徴。証明書は短命化・自動ローテーションが前提である点も頻出。
  • 午後視点： マイクロサービス間通信の実務対策は「mTLSによる相互認証（通信の暗号化と身元確認）」と「認可ポリシーによるアクセス制御（ゼロトラスト・最小権限）」を分けて設計することが核心。認証だけでは不十分という理解が問われる。