こんにちは！セキュリティの世界へようこそ。
新人のIT担当者や、これからアプリやWebサービスの開発に挑む一般開発者の皆さん、日々の業務お疲れ様です。
「暗号化通信」や「SSL/TLS」「証明書」といった言葉を聞くと、なんだか難しそう、数学の教科書みたい……と身構えてしまいますよね。でも、安心してください。これらは私たちの日常生活にある「身近な防犯の仕組み」に置き換えると、すんなりと理解できるようになります。
今回は、サイバー攻撃者がひそかに狙っている「中間者攻撃（MITM）」の仕組みと、それを防ぐための「証明書検証」や「HSTS（HTTP Strict Transport Security）」という大切な盾について、一緒に一歩ずつ学んでいきましょう！
—
1. 泥棒はネット上にもいる？「中間者攻撃（MITM）」ってなに？
まずは、私たちが普段スマートフォンやパソコンでWebサイトを見るときに、裏側で何が起きているのかをイメージしてみましょう。
家の鍵と宅配便の例え
あなたがネットショップで買い物をして、クレジットカードの番号を入力するとします。このとき、あなたのパソコン（購入者）からショップのサーバー（お店）へ、大事な情報が送られますよね。
もし、この通信に「鍵（暗号）」がかかっていないとどうなるでしょうか？
途中の道（インターネット回線）には、悪意を持った泥棒（攻撃者）がウロウロしています。この泥棒が通信をこっそり覗き見たり、中身を書き換えたりする攻撃を、中間者攻撃（Man-in-the-Middle Attack：MITM）と呼びます。
通信に鍵をかける仕組みが HTTPS（SSL/TLS暗号化通信）ですが、実はこの「鍵のやり取り」の瞬間を狙う巧妙な手口があるんです。
—
2. 「見せかけの身分証」に騙されるな！証明書検証の不備
通信を暗号化するために、Webサイト側は「私は本物のお店ですよ」と証明するためのデジタル証明書（身分証のようなもの）を私たちに渡してきます。
ブラウザやアプリは、本来次のようなチェックをしています。
1. この身分証は、信頼できる公的な機関（認証局）が発行したものか？
2. 有効期限は切れていないか？
3. アクセスしている宛先の名前と、身分証の名前は一致しているか？
攻撃者はどうやって騙すの？
ここで、もしアプリやプログラムを作る際、テスト用のコードや手抜き（設定のミス）によって、「この身分証、偽物っぽいけど……まあいっか！通しちゃえ！」というガバガバな検証コードを書いているとどうなるでしょう？
攻撃者は、あなたの通信の間に割り込み、偽物の身分証を突きつけて「私がお目当てのサーバーですよ」と嘘をつきます。プログラムがその嘘を信じてしまうと、暗号化されているつもりでも、実は攻撃者との間でガッツリ情報をやり取りしてしまう……これが「証明書検証の不備」を突いた恐ろしい攻撃のメカニズムです。
—
3. アプリの鉄壁の守り「証明書ピンニング」を実装しよう
特にスマートフォンアプリなどの開発で、この中間者攻撃をガッチリ防ぐために使われるのが「証明書ピンニング（Certificate Pinning）」という技術です。
合言葉による身元確認の例え
通常の検証が「身分証を見せる（誰でも知っている公的機関のハンコがあればOK）」という仕組みなのに対し、ピンニングは「あらかじめお店と私たちだけで決めておいた『秘密の合言葉（フィンガープリント）』が一致するか」を確認する仕組みです。
たとえ攻撃者が偽物の身分証を持ってきたとしても、「合言葉が違うからお前はニセモノだ！」と一発で見破ることができます。
実装のヒント（イメージ）
例えば、アプリ側で特定の証明書のハッシュ値（指紋のようなもの）を固定（ピン留め）しておきます。実際のAndroidやiOS、あるいは各種言語のHTTPクライアントライブラリでは、以下のように信頼する証明書の情報をコード内に組み込みます。
// Java（Androidなど）における証明書ピンニング設定のイメージ
// ※実務ではライブラリの仕様に合わせた正確な記述を行ってください。
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAウェブサイトの証明書ハッシュ値=")
.build();
OkHttpClient client = new OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build();このように、アプリ側であらかじめ「このサーバーの証明書以外は絶対に信用しない！」と硬く決めておくことで、中間者攻撃を強力にブロックできます。
—
4. Webサイトの総仕上げ！「HSTS」を設定しよう
次は、Webサイト（サーバー側）を構築・管理する開発者向けの必須対策です。
ユーザーがブラウザでサイトにアクセスするとき、最初から https://... と打ち込むとは限りません。ついつい http://example.com と、暗号化されていない古い入口から入ろうとしてしまうことがあります。
この最初の「ちょっと待った！」を自動で行ってくれるのが、HSTS（HTTP Strict Transport Security）というレスポンスヘッダーです。
HSTSヘッダーの仕組み
Webサーバーの設定ファイル（NginxやApacheなど）やWebアプリケーションの応答に、以下のようなヘッダーを付与します。
# HTTPレスポンスヘッダーの例
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadmax-age=31536000: 「これから1年間（31536000秒）、このサイトには必ず安全なHTTPSでアクセスしなさい」とブラウザに覚え込ませます。includeSubDomains: メインサイトだけでなく、すべてのサブドメイン（例:*.example.com）にも同様の強制力を適用します。
これにより、ユーザーがうっかり http:// でアクセスしようとしても、ブラウザが自動的に https:// に変換して通信してくれるため、最初の隙を突いたダウングレード攻撃や中間者攻撃を防ぐことができるのです。
—
5. まとめ：一歩ずつ、確実なセキュリティ対策を
今回は、暗号化通信の裏側に潜む中間者攻撃の脅威と、それを防ぐための「証明書検証」「証明書ピンニング」「HSTS」について紐解いてきました。
セキュリティの対策と聞くと、なんだか壁が高く感じるかもしれませんが、要するにこういうことです。
1. 通信の途中で怪しい奴が割り込んでも、身分証（証明書）をサボらずに厳しくチェックする！
2. アプリなら「秘密の合言葉（ピンニング）」でさらにガチガチに固める！
3. Webサイトなら「HSTS」を使って、ユーザーが危ない道を通らないように看板を立てておく！
これらを一つひとつ丁寧に実装・設定していくことで、あなたがつくるシステムは劇的に安全になります。
「難しそう」を「なるほど、こういうことか！」に変えながら、一緒に一歩ずつ、セキュアな開発スキルを磨いていきましょう！
コメント