こんにちは！ネットワークやセキュリティの世界に足を踏み入れたばかりの皆さん、日々のインフラ学習お疲れ様です。「ゼロトラスト」や「SASE（サセ）」といった言葉、最近よく耳にしますよね。社内も社外も関係なく「すべてを信用しない」というこのセキュリティ思想において、クラウド上の安全を守る「CASB（キャスブ）」という仕組みは欠かせない主役の一つです。
でも、このCASBの実装現場で、インフラエンジニアたちが頭を悩ませる「ある強敵」がいるのをご存知でしょうか？それが、今回取り上げる「証明書ピンニング（Certificate Pinning）」という技術、そしてそれに伴う「例外処理」です。
なんだか聞き慣れない難しそうな名前ですが、大丈夫です！一歩ずつ、身近な例えから紐解いていきましょう。
—
1. 郵便配達と「偽物チェック」の仕組み
まずは、私たちが普段使っているスマホアプリやWebブラウザが、どのように安全を保っているのかをイメージしてみましょう。
インターネットの世界は、いわば「見知らぬ宛先への手紙のやり取り」です。悪意を持った第三者が途中で手紙を覗き見したり、中身を書き換えたり（これを盗聴や改ざんと言います）するのを防ぐため、通信はすべて暗号化（HTTPS）されています。
この暗号化の安全性を保証するために使われるのが「デジタル証明書」です。これは、いわば「政府公認の身分証明書」のようなもの。ブラウザやアプリは、通信相手が提示する証明書を見て、「おっ、本物の銀行から届いた手紙だな」と信用します。
そして、企業のネットワークを守るCASBは、社内のメンバーが怪しいクラウドサービスに機密データを持ち込んでいないか監視するため、通信の途中に割り込んで「一度中身を確認する（SSLインスペクション）」という大役を担っています。郵便局の窓口で、怪しい荷物の中身を一度開けてチェックするようなイメージですね。
—
2. 困ったちゃんな「証明書ピンニング」とは？
ここで問題が発生します。
最近のセキュリティ意識の高いスマホアプリ（特に銀行アプリや、一部のモダンなチャットツールなど）は、こんな風に考えています。
> 「いくら会社（CASB）の郵便局だからって、俺たちの手紙の封を勝手に開けて中身を見るなんて信用できない！ もしかしたら偽物の郵便局員かもしれないし！」
そこで彼らは、アプリの中に「特定の身分証明書（サーバーの証明書）の指紋や実物」をガッチリと直接縫い付けて（ピン留めして）おいたのです。これが証明書ピンニングです。
アプリ「俺はこの証明書しか信用しないからな！」
CASB「えっ、安全のために中身を見ようとしただけなのに……」
結果どうなるかというと、CASBが善意で（あるいは会社のポリシーとして）通信を覗き見しようと身分証明書を差し替えた瞬間、アプリ側が「あれっ？ 俺が知ってる証明書と違う！ 偽物だ！ 通信ストップ！」と怒り出し、アプリが一切使えなくなってしまうのです。
「社内の安全を守るためにCASBを導入したのに、肝心の業務アプリが動かなくなった……」これは現場のインフラ担当者にとって冷や汗もののトラブルですよね。
—
3. どう解決する？「例外処理」というスマートな逃げ道
では、証明書ピンニングを使っているアプリが社内で使えなくなったとき、私たちはどうすればよいのでしょうか？
答えはシンプルです。「この特定のアプリに関しては、CASBの覗き見（復号化）の対象外（例外）にして、そのまま直接通信させよう」という設定を入れます。これを実務の世界では「SSL復号化除外（バイパス）」や「ピンニングアプリの例外処理」と呼びます。
「えっ、例外を作ったらセキュリティが甘くなるのでは？」と心配になるかもしれませんが、ゼロトラストの考え方では「すべてを一律に縛る」のではなく、「リスクを見極めて賢くコントロールする」ことが求められます。ピンニングアプリは独自の強固なセキュリティを持っているため、CASBの復号化から外しても一定の安全性が保たれることが多いのです。
—
4. 実務での設定イメージを見てみよう
ここからは、実際に大手SASE製品やCASB製品で、こうした例外処理を行う際の設定イメージを覗いてみましょう。
実務では、ドメイン名やアプリケーションのプロセス名、あるいは特定の宛先IPアドレスを指定して、「この通信のときは、中身の覗き見（SSLインスペクション）をやめてね」と指示を出します。
設定ファイルのイメージ（YAML形式のサンプル）
以下の設定は、証明書ピンニングを実装している特定の社内業務アプリ（ここでは secure-app.example.com と仮定します）の通信を、CASBの復号化対象から外すための設定例です。
# SASE / CASB ポリシー設定サンプル
policy_name: "bypass-pinned-applications"
description: "証明書ピンニングを使用するアプリのSSL復号化除外ポリシー"
# 適用する条件の定義
match_conditions:
destination_domains:
- "*.secure-app.example.com" # ピンニング実装済みの独自アプリのドメイン
transport_protocols:
- "TCP"
ports:
- 443
# 一致した通信に対するアクション
action:
ssl_inspection: false # ここを false にすることで、復号化（中身の検査）をバイパスする
log_traffic: true # ただし、誰がアクセスしたかのログ（メタデータ）はしっかりと残す
note: "アプリの誤作動を防ぐため、TLSハンドシェイクの割り込みを行わないこと"このように、ssl_inspection: false というパラメータを与えてあげることで、CASBは「あ、このアプリは手を出しちゃいけないやつだな」と判断し、そのまま素通りさせるようになるわけです。
—
5. トラブルシューティングの現場から：生きた知見
現場でインフラ構築や運用をしていると、次のような相談を本当によく受けます。
> 「新しいスマホアプリを入れた途端に、『ネットワークエラーです』と言われてログインできません！」
そんなときの私たちの泥臭い調査ステップはこうです。
1. ログの確認: SASE/CASBの管理コンソールで、その端末の通信ログを開きます。ステータスコードが変なところで止まっていないか、あるいは Handshake Failure（ハンドシェイク失敗）というエラーが出ていないかを確認します。
2. 証明書エラーの特定: パケットキャプチャやクライアント側のエラー画面を見ると、見慣れない証明書エラー（例: CERTIFICATE_VERIFY_FAILED）が出ています。ここで「あ、こいつはピンニングだな」と見当をつけます。
3. 例外ルールの適用とテスト: 先ほど紹介したような除外ルールを一時的に適用し、アプリが正常に動くかテストします。
ここで大切なのは、「何でもかんでも例外扱いにしないこと」です。例外を広げすぎると、そこがセキュリティの「抜け穴」になってしまいます。本当にピンニングが必要なアプリなのか、開発元に仕様を確認したり、アプリ自体のベンダー推奨設定に従ったりすることが、プロとしての腕の見せ所になります。
—
まとめ
今回は、CASBのインプレッション（復号化）における「証明書ピンニングの例外処理」について、郵便配達の例えを交えながら優しく解説しました。
- CASBの復号化は安全確認のために重要だが、証明書ピンニングを実装したアプリとは相性が悪い。
- アプリが壊れてしまうのを防ぐため、例外処理（SSLバイパス）の設定が必要になる。
- セキュリティと利便性のバランスを取りながら、適切なターゲットだけを除外する設計がインフラエンジニアには求められる。
最初は複雑に見えるネットワークの仕組みも、身近な世界に置き換えてみると、エンジニアたちがなぜその設定を入れているのか、その「理由」が見えてきてワクワクしませんか？
これからも一歩ずつ、確実にお仕事や学習のスキルを積み上げていきましょう！次回の記事もお楽しみに！
コメント