1. 👋 はじめに
前回はCIA三原則・脅威・脆弱性・リスクという「セキュリティの考え方の土台」を学びました。
今回はより具体的な技術に踏み込みます！
「認証と認可って何が違うの？」
「パスワードってどうやって安全に保存されているの？」
「公開鍵暗号ってどういう仕組み？」
「デジタル署名って何を証明してるの？」
これらを図解でやさしく解説します💪
この記事を読めば：
- ✅ 認証と認可の違いがわかる
- ✅ パスワードの安全な管理方法がわかる
- ✅ 多要素認証・SSOの仕組みがわかる
- ✅ 共通鍵・公開鍵暗号の違いがわかる
- ✅ ハッシュ・デジタル署名・PKIがわかる
2. 🚪 認証と認可：似ているようで全然違う！
認証（Authentication）とは？
「あなたは誰ですか？」を確認すること
認証の例：
🏢 会社の入口でIDカードをかざす
→ 「田中さんですね」と確認
💻 ログイン画面でID・パスワードを入力する
→ 「このアカウントの持ち主ですね」と確認
📱 スマホの顔認証
→ 「あなた本人ですね」と確認
認可（Authorization）とは？
「あなたは何ができますか？」を確認すること
認可の例：
🏢 IDカードで入館できても
「社長室には入れない」← これが認可
💻 ログインできても
「管理者ページは見られない」← これが認可
📁 ファイルにアクセスできても
「削除はできない（読み取りのみ）」← これが認可
認証と認可の流れ
アクセス要求
↓
【認証】「あなたは誰？」
→ IDとパスワードを確認
→ 本人確認OK ✅
↓
【認可】「あなたは何ができる？」
→ 権限・ロールを確認
→ 管理者なら全操作OK
→ 一般ユーザーなら読み取りのみ
↓
アクセス許可 or 拒否
ホテルで例えると🏨
【認証】チェックイン時に身分証を確認
→ 「田中さんですね」（本人確認）
【認可】部屋のカードキーを発行
→ 「305号室に入れます」
→ 「でも501号室には入れません」
→ 「レストランは使えますが、VIPラウンジはNGです」
認証 = チェックイン（本人確認）
認可 = カードキーの権限設定（何ができるか）
3. 🔑 パスワードの仕組みと安全な管理
パスワードはどうやって保存されているの？
❌ 絶対にやってはいけない保存方法：
平文保存：「password123」をそのまま保存
→ DBが漏洩したら全パスワードが即バレ 😱
暗号化して保存（可逆）：
→ 暗号化鍵が漏れたら全パスワードが解読される 😱
✅ 正しい保存方法：ハッシュ化
パスワード → ハッシュ関数 → ハッシュ値（を保存）
「password123」→ SHA-256 → 「ef92b778bafe771...」
ハッシュ値の特徴：
① 元のパスワードに戻せない（一方向性）
② 同じ入力なら必ず同じ出力
③ 少しでも違う入力なら全く違う出力
ログイン時：
入力されたパスワードをハッシュ化
→ 保存済みのハッシュ値と比較
→ 一致すれば認証OK ✅
ハッシュだけでは不十分：レインボーテーブル攻撃
😰 レインボーテーブル攻撃とは？
「よく使われるパスワードのハッシュ値」を
あらかじめ大量に計算して表（テーブル）にしておく
password → ef92b778...
123456 → 8d969eef...
qwerty → 65e84be3...
（数十億件のテーブル）
→ 漏洩したハッシュ値と突き合わせるだけで
パスワードがわかってしまう！😱
ソルトでレインボーテーブル攻撃を防ぐ
✅ ソルト（Salt）= パスワードにランダムな文字列を付け加える
ソルトなし：
「password123」→ ハッシュ → 「ef92b778...」
ソルトあり：
「password123」+「x7kP9m」（ランダムなソルト）
→ ハッシュ → 「3a8f2c1b...」（全く違う値！）
ユーザーごとに異なるソルトを使うので
同じパスワードでも違うハッシュ値になる！
→ レインボーテーブルが使えない 🎯
現在の推奨：
└─ bcrypt・scrypt・Argon2などの
ソルト付きの専用パスワードハッシュ関数を使う
安全なパスワードの条件
| 条件 | 理由 |
|---|---|
| 12文字以上 | 短いと総当たり攻撃で解読される |
| 大文字・小文字・数字・記号を混在 | 文字の種類が多いほど総当たりに時間がかかる |
| 辞書に載っている単語を避ける | 辞書攻撃を防ぐ |
| サービスごとに異なるパスワード | 1つ漏洩しても他に影響しない |
| パスワードマネージャーを使う | 複雑なパスワードを安全に管理 |
4. 📱 多要素認証（MFA）の仕組み
認証の3要素（前回の復習）
🧠 知識情報（Something You Know）
└─ パスワード・PIN・秘密の質問
📱 所持情報（Something You Have）
└─ スマートフォン（認証アプリ）
└─ SMSで届くワンタイムパスワード
└─ セキュリティキー（YubiKeyなど）
👁️ 生体情報（Something You Are）
└─ 指紋・顔認証・虹彩認証
TOTPの仕組み（Google Authenticatorなど）
TOTP（Time-based One-Time Password）：
時刻ベースのワンタイムパスワード
仕組み：
① サービスとスマホが「シークレットキー」を共有
② 現在時刻 + シークレットキー → 6桁の数字を生成
③ 30秒ごとに新しい数字に変わる
サービス側も同じ計算をして照合！
→ 毎回違う数字なので盗まれても無意味 🎯
→ インターネット接続なしで生成できる
SMSとTOTP・セキュリティキーの比較
| 方式 | 安全性 | 利便性 | 備考 |
|---|---|---|---|
| SMS認証 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | SIMスワップ攻撃のリスクあり |
| TOTPアプリ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | Google Authenticator等 |
| プッシュ通知 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | MFA疲労攻撃のリスクあり（後述） |
| セキュリティキー | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | YubiKey等・最も安全 |
| 生体認証 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | デバイス依存 |
📲 プッシュ通知MFAの仕組みと落とし穴
プッシュ通知MFAとは、ログイン時にスマホへ「承認しますか？」という通知が届き、タップするだけで認証できる方式です。MicrosoftやDuoなどで広く使われています。
【プッシュ通知MFAの流れ】
① ユーザーがIDとパスワードを入力
↓
② サーバーがスマホに「承認リクエスト」を送信
↓
③ スマホに通知が届く
┌────────────────────────┐
│ 🔔 ログインリクエスト │
│ example.comへの │
│ ログインを承認しますか？ │
│ │
│ [✅ 承認] [❌ 拒否] │
└────────────────────────┘
↓ ✅をタップ
④ 認証完了・ログイン成功
✅ メリット：
└─ 6桁のコードを入力する手間がない
└─ 直感的でわかりやすい
└─ 多くのビジネス向けサービスで採用
⚠️ MFA疲労攻撃（MFA Fatigue Attack）
プッシュ通知MFAには「MFA疲労攻撃」という弱点があります。
😰 MFA疲労攻撃の手口：
① 攻撃者がパスワードを入手（フィッシング等）
↓
② ログインを何度も試みる
→ スマホに「承認しますか？」通知が大量に届く
↓
③ ユーザーが
「なんの通知だろう？」→ うっかりタップ ✅ 😱
「通知がうるさい！」 → 止めようとタップ ✅ 😱
↓
④ 攻撃者がログイン成功！
実際の事例：
└─ 2022年 Uber社がこの攻撃で被害
→ 攻撃者がWhatsAppで「IT部門です」と連絡して
承認を押すよう説得 → 社内システムに侵入
✅ MFA疲労攻撃への対策：
□ 通知に「ログイン場所・デバイス情報」を表示する
□ 数字照合（ナンバーマッチング）を有効にする
└─ 画面に表示された数字と通知の数字が一致するか確認
└─ うっかりタップを防げる！
□ 身に覚えのない承認リクエストは必ず拒否
□ 大量のリクエストが来たらすぐパスワードを変更
□ セキュリティキー（FIDO2）に移行する（最も安全）
5. 🔓 SSO（シングルサインオン）
SSOとは？
「1回のログインで複数のサービスを使えるようにする仕組み」
SSOなし：
Googleにログイン → IDとパスワードを入力
Slackにログイン → IDとパスワードを入力
GitHubにログイン → IDとパスワードを入力
Salesforceにログイン → IDとパスワードを入力
… サービスごとに毎回ログインが必要😓
SSOあり：
IdP（Identity Provider）に1回ログイン
↓
Google・Slack・GitHub・Salesforceすべて使える！😊
ここで一旦用語を整理します。
🏛️ IdP（Identity Provider：アイデンティティプロバイダー）
└─ 「認証を一手に引き受ける管理者」のこと
└─ ユーザーのID・パスワードを管理し
「この人は本物です」という証明を発行する
└─ 代表例：Okta・Microsoft Entra ID（旧Azure AD）・OneLogin
🔤 SAML（Security Assertion Markup Language：サムル）
└─ IdPとサービス間で「認証情報を安全にやり取りする」規格
└─ 「この人は認証済みです」という情報をXML形式で送受信する
└─ 企業向けSSOで広く使われている標準プロトコル
└─ 他にもOAuth2.0・OpenID Connect（OIDC）という規格もある
🛎️ SP（Service Provider：サービスプロバイダー）
└─ Slack・GitHub・Salesforceなど実際に使うサービス側のこと
└─ IdPを信頼して認証を委ねる
まとめると：
ユーザー → IdP（認証）→ SAML（やり取り）→ SP（利用）
SSOの仕組み（SAMLの場合）
① ユーザーがSlackにアクセス
↓
② SlackがIdP（例：Okta）にリダイレクト
↓
③ ユーザーがIdPでログイン（1回だけ）
↓
④ IdPが「このユーザーは認証済み」という証明書を発行
↓
⑤ Slackが証明書を検証 → アクセス許可
↓
⑥ 次にGitHubにアクセスしても
IdPはすでに認証済みなので再ログイン不要！
SSOのメリット・デメリット
✅ メリット：
└─ ユーザーの利便性向上（パスワードを覚える数が減る）
└─ パスワードの使い回しを防ぐ
└─ 退職者のアクセス管理が一元化できる
└─ セキュリティポリシーを一箇所で管理
⚠️ デメリット：
└─ IdPが攻撃されると全サービスに影響
└─ IdPが落ちると全サービスにログインできない
└─ 導入・運用コストがかかる
6. 🔒 暗号化の仕組み
共通鍵暗号（対称暗号）
「同じ鍵で暗号化・復号する」
【共通鍵暗号の仕組み】
送信者 受信者
│ 🔑共通鍵で暗号化 │
│──────────────────────────────→│
│ 暗号文（解読不可） │
元のデータ │ 🔑同じ共通鍵で復号
↓
元のデータ
代表的なアルゴリズム：
AES-128・AES-256（現在の標準・非常に安全）
3DES（古い・非推奨）
DES（非常に古い・危険）
✅ メリット：処理が高速
❌ デメリット：鍵を安全に共有する方法が問題
公開鍵暗号（非対称暗号）
「暗号化と復号で異なる鍵を使う」
【公開鍵暗号の仕組み】
まず鍵のペアを作る：
🔑 秘密鍵（自分だけが持つ）
🗝️ 公開鍵（誰にでも配る）
暗号化通信：
送信者が「公開鍵」で暗号化
↓
暗号文を送信
↓
受信者が「秘密鍵」で復号
（秘密鍵を持っている人だけが復号できる！）
デジタル署名（後述）：
送信者が「秘密鍵」で署名
↓
受信者が「公開鍵」で検証
代表的なアルゴリズム：
RSA（広く普及・鍵長2048bit以上推奨）
ECDSA（楕円曲線・より短い鍵で同等の安全性）
Ed25519（最新・高速・SSHで普及中）
✅ メリット：鍵の配布が安全
❌ デメリット：処理が重い（共通鍵の10〜1000倍）
実際の通信では両方を組み合わせる
【ハイブリッド暗号（HTTPSの仕組み）】
① 公開鍵暗号で「共通鍵」を安全に交換
↓
② あとは高速な共通鍵暗号で通信
なぜ？
公開鍵暗号 → 安全だが遅い
共通鍵暗号 → 速いが鍵の共有が問題
→ 「安全な鍵配送」だけ公開鍵暗号を使い
「実際のデータ通信」は共通鍵暗号で高速処理！
いいとこどり 🎯
7. #️⃣ ハッシュ関数
ハッシュ関数とは？
【ハッシュ関数の特性】
任意の長さのデータ → 固定長のハッシュ値
「Hello」→ SHA-256 → 「185f8db32...」（64文字）
「Hello!」→ SHA-256 → 「334d016f7...」（64文字・全然違う！）
「War and Peace（全文）」→ SHA-256 → 「a1b2c3d4...」（同じく64文字）
重要な特性：
① 一方向性：ハッシュ値から元データを復元できない
② 衝突耐性：異なるデータが同じハッシュ値にならない
③ 雪崩効果：1ビット変わるだけでハッシュ値が大きく変わる
ハッシュの用途
① パスワードの保存（前述）
「password123」→ ハッシュ → DBに保存
② ファイルの改ざん検知
ダウンロードしたファイルのハッシュ値を計算
→ 公式が公開しているハッシュ値と比較
→ 一致すれば改ざんなし ✅
③ ブロックチェーン
前のブロックのハッシュ値を次のブロックに含める
→ 1つでも改ざんすると全ブロックのハッシュが変わる
代表的なアルゴリズム：
SHA-256（現在の標準・Bitcoin等でも使用）
SHA-3（次世代標準）
MD5・SHA-1（古い・衝突が発見済み・非推奨）
8. ✍️ デジタル署名
デジタル署名とは？
「このデータは確かに私が作り、改ざんされていない」ことを証明する仕組み
【デジタル署名の仕組み】
【署名する（送信者が作成）】
元データ → ハッシュ関数 → ハッシュ値
↓
秘密鍵で暗号化
↓
デジタル署名
【元データを送信する】
→ 元データ + デジタル署名を送信
【検証する（受信者）】
受け取ったデータ → ハッシュ関数 → ハッシュ値A
デジタル署名 → 公開鍵で復号 → ハッシュ値B
ハッシュ値A = ハッシュ値B ✅ → 正当・改ざんなし
ハッシュ値A ≠ ハッシュ値B ❌ → 改ざんあり or 偽物
デジタル署名が証明すること
① 真正性（Authenticity）
└─ 確かにその人が作成した
└─ 秘密鍵を持っている人しか署名できないから
② 完全性（Integrity）
└─ 署名後に改ざんされていない
└─ 1ビットでも変わるとハッシュ値が変わるから
③ 否認防止（Non-repudiation）
└─ 「自分は署名していない」と言い張れない
└─ 秘密鍵を持っている本人しか署名できないから
9. 🏛️ PKI（公開鍵基盤）と証明書
デジタル証明書の必要性
😰 公開鍵だけでは解決できない問題：
「この公開鍵は本当にgoogle.comのものか？」
攻撃者が偽のgoogle.comを作り
偽の公開鍵を配ることができる！（中間者攻撃）
→ 「この公開鍵は確かに本物」と証明する仕組みが必要
PKI（Public Key Infrastructure）
【PKIの仕組み】
認証局（CA：Certificate Authority）
└─ 公開鍵の正当性を証明する信頼できる機関
└─ DigiCert・Let's Encrypt・VeriSignなど
デジタル証明書の中身：
├─ 誰の証明書か（example.com）
├─ 公開鍵
├─ 有効期限
├─ 発行したCA
└─ CAのデジタル署名
信頼の連鎖（Chain of Trust）：
ルートCA（最上位・ブラウザに組み込み済み）
↓ 署名
中間CA
↓ 署名
サーバー証明書（example.com）
↓
ユーザーが接続
→ ルートCAを信頼 → 中間CA → サーバー証明書
まで信頼の連鎖がつながる！
HTTPSの証明書確認
ブラウザで 🔒 マークをクリックすると見られる情報：
発行先：example.com
発行者：Let's Encrypt
有効期限：2026/09/01まで
公開鍵：RSA 2048bit
ブラウザが自動でやっていること：
① 証明書の有効期限を確認
② CAの署名を検証（信頼できるCAか？）
③ ドメイン名が一致するか確認
④ 証明書が失効していないか確認（OCSP/CRL）
10. 🎭 ソーシャルエンジニアリング：「人間の隙」を突く攻撃
ここまで技術的な認証・暗号化を学びましたが、どんなに強固な技術も人間の心理的な弱点を突かれると一瞬で突破されてしまいます。
💡 有名なハッカーの言葉：
「システムを攻撃するより
人間を騙す方がずっと簡単だ」
→ 技術的なセキュリティを完璧にしても
人を騙せば鍵を開けてもらえる！
ソーシャルエンジニアリングとは？
人間の心理・行動・信頼を悪用して情報を盗み出したり、不正操作をさせたりする攻撃手法のことです。
代表的な手口
🎣 フィッシング（Phishing）
偽のメール・サイトで認証情報を騙し取る
典型的な手口：
「【緊急】Amazonアカウントが
不正アクセスされました。
こちらから確認してください」
→ 偽のAmazonサイトへ誘導
→ ID・パスワードを入力させる
見分け方：
□ 送信元メールアドレスが微妙に違う
（amazon.co.jp → amaz0n.co.jp など）
□ URLが本物と少し違う
□ 「今すぐ」「緊急」など焦らせる言葉
□ 日本語が不自然
種類：
スピアフィッシング → 特定の人・組織を狙い撃ち
ホエーリング → 経営幹部を標的にした高度な攻撃
スミッシング → SMSを使ったフィッシング
ビッシング → 電話を使ったフィッシング
🎭 プリテキスティング（Pretexting）
架空のシナリオ（口実）を作って信頼させ
情報を引き出す手口
例：
「IT部門のXXですが、システムのメンテナンスで
パスワードを確認させていただけますか？」
「人事部です。給与振込の口座変更の確認で
社員番号を教えてください」
「警察です。サイバー犯罪の捜査で
アカウント情報が必要です」
本物の組織はパスワードや秘密情報を
電話やメールで聞くことは絶対にない！
🚪 テールゲーティング（Tailgating）
物理的なセキュリティを突破する手口
例：
「荷物を持っているので、ドアを押さえてください」
→ 認証なしでセキュリティゾーンに侵入
「今日から来た新入社員なんですが、
カードをまだもらっていなくて…」
→ 同情を誘って内部に侵入
対策：
□ どんな理由があっても第三者を連れ込まない
□ 不審な人物は必ず確認・受付に連絡
💰 ベイティング（Baiting）
好奇心・欲求を利用した手口
例：
「当選おめでとうございます！
USBドライブをお送りします」
→ 受け取ったUSBを刺すとマルウェアが起動
駐車場にUSBを落としておく
→ 拾った人が「なんだろう？」と会社のPCに刺す
→ マルウェアが起動・社内ネットワークに感染
対策：
□ 出所不明のUSBは絶対に刺さない
□ 拾ったUSBはIT部門に届ける
人間を守る3つの対策
🧠 ① セキュリティ教育・訓練
└─ 定期的なフィッシングメール訓練
└─ 「怪しいと思ったら確認する」文化を作る
└─ 事例を共有して組織全体の意識を高める
📋 ② プロセス・ルールの整備
└─ 「電話でパスワードを教えない」ルールを明文化
└─ 本人確認の手順を決めておく
└─ 不審なアクセスの報告フローを整備
🛡️ ③ 技術的な補完
└─ フィッシングサイトをブロックするDNSフィルタリング
└─ 怪しいメールを自動検知するメールフィルタ
└─ MFAで「パスワードが盗まれても突破されない」設計
💡 最終的には：
「おかしいと思ったら確認する」
この一言を習慣にすることが最大の防御！
ソーシャルエンジニアリングまとめ
| 手口 | 狙うもの | 対策 |
|---|---|---|
| 🎣 フィッシング | 認証情報・クレジットカード | URLを確認・公式サイトから直接アクセス |
| 🎭 プリテキスティング | 機密情報・アカウント | 電話・メールで機密情報を教えない |
| 🚪 テールゲーティング | 物理的な侵入 | 不審者を連れ込まない |
| 💰 ベイティング | マルウェア感染 | 不審なUSBを刺さない |
| 📱 MFA疲労攻撃 | MFAの突破 | 身に覚えのない承認を拒否 |
11. 📋 まとめ
| 概念 | 一言で言うと |
|---|---|
| 🚪 認証 | 「あなたは誰？」本人確認 |
| 🔓 認可 | 「あなたは何ができる？」権限確認 |
| 🔑 ハッシュ | 元に戻せない一方向の変換・改ざん検知に使う |
| 🧂 ソルト | ハッシュにランダム文字列を追加してレインボーテーブルを防ぐ |
| 📱 MFA | 複数の認証要素を組み合わせて安全性を高める |
| 📲 プッシュ通知MFA | 便利だがMFA疲労攻撃に注意・ナンバーマッチングで対策 |
| 🔗 SSO | 1回のログインで複数サービスを使える仕組み |
| 🔒 共通鍵暗号 | 同じ鍵で暗号化・復号。高速だが鍵配送が課題 |
| 🔐 公開鍵暗号 | 公開鍵で暗号化・秘密鍵で復号。安全だが遅い |
| ✍️ デジタル署名 | 秘密鍵で署名・公開鍵で検証。真正性・完全性を証明 |
| 🏛️ PKI | 公開鍵の正当性を証明する仕組み（CAと証明書） |
| 🎭 ソーシャルエンジニアリング | 技術ではなく「人間の隙」を突く攻撃 |
認証・認可・暗号化はセキュリティの核心技術です。「なんとなく使っていた」HTTPS・パスワード・MFAの仕組みが理解できたでしょうか？🌟
次回はWebアプリケーションの攻撃と防御を解説します！SQLインジェクション・XSS・CSRF・OWASP Top 10など、現場でよく遭遇する攻撃パターンを詳しく解説します！
💬 質問や感想があれば、コメント欄でお気軽にどうぞ!
👍 役に立ったら、いいね&ストックをお願いします!
🎓 ここまで読んでくださって、本当にありがとうございました!
🔗 シリーズ記事
- 【第一回】CIA三原則・脅威・脆弱性・リスクをやさしく解説
- 【第二回】認証・認可・暗号化（この記事）
- 【第三回】Webアプリケーションの攻撃と防御（近日公開）
- 【第四回】ネットワークセキュリティ（近日公開）
- 【第五回】セキュリティ設計と運用（近日公開）
- 【第六回】最新のセキュリティトレンド（近日公開）