アイデンティティは「新たな境界」である

クラウド化が進む現代において、従来のネットワーク境界（ファイアウォール）はもはや絶対的な防御線ではありません。VPNで繋がった先のシステムも、クラウド上のSaaSも、従業員の手元のデバイスも——これらはすべて「境界の外」にあると考える必要があります。

現在のサイバー防御の最前線は、ユーザーやデバイスの**「アイデンティティ（ID）」**そのものに移っています。「誰が、何のリソースに、どの状況下でアクセスしようとしているか」を正確に把握し制御することが、現代のセキュリティの核心です。

認証（AuthN）と認可（AuthZ）の決定的な違い

この2つの概念は「Auth」と略されて混同されがちですが、システム設計において明確に分離（Decoupling）して実装する必要があります。混同すると設計上の重大な穴が生まれます。

概念略称問いかけプロの実務における適用例
認証AuthN (Authentication)「あなたは本当にその人か？」ログイン画面でパスワードとFIDO2セキュリティキーを要求し、本人性を暗号学的に確認するフェーズ。
認可AuthZ (Authorization)「あなたは何を読み書きできるか？」認証済みのユーザーに対し、IAMポリシーに基づき「S3バケットへのReadOnly権限」のみを付与するフェーズ。

「本人だと確認できた（認証）」ことと「何でもできる（認可）」は全く別の話です。この分離を徹底することが、最小権限の原則の基礎となります。

認証：パスワードの限界とMFAの進化

パスワードハッシュの厳格な要件

認証情報（パスワード）をデータベースに保存する際、平文はもちろん、単純なハッシュ化（MD5、SHA-256）も絶対的な禁忌です。現代のGPUクラスタを用いた総当たり攻撃では、MD5ハッシュは1秒間に数百億回を超える速度で解析できます。

パスワードハッシュアルゴリズムの選定基準（2026年標準）
アルゴリズム評価プロフェッショナルの見解
Argon2id最推奨メモリ・並列性・反復回数を細かく調整可能。パスワードハッシュコンペティション（PHC）の勝者であり、現在最もGPUクラックに強い。新規システムではこれ一択。
bcrypt / scrypt推奨実績があり多くのフレームワークのデフォルト。Argon2が利用できない環境での安定した選択肢。
PBKDF2条件付き推奨FIPS準拠が厳格に求められる政府系・金融系システム向け（NIST SP 800-63B準拠）。
SHA-256 / SHA-512直ちに使用停止ソルト（Salt）を付与しても計算が高速すぎるため、専用クラッキングリグの攻撃に対して脆弱。パスワード保存への使用は禁止。

多要素認証（MFA）の落とし穴とFIDO2

「MFAを導入すれば安全」という認識は、AiTM（Adversary-in-The-Middle）を用いるフィッシングキットの台頭によって崩れています。

SMSによるOTP（ワンタイムパスワード）はSIMスワッピングに弱く、認証アプリ（TOTP）の6桁コードも、偽サイトを経由してリアルタイムに奪取されます。精巧なフィッシングサイトがユーザーから盗んだTOTPコードを瞬時に本物のサイトへ転送することで、MFAをバイパスするのです。

これに対抗できる唯一の認証手段が、Phishing-Resistant MFA（耐フィッシングMFA） と呼ばれる規格です。

WebAuthn / FIDO2（パスキー）の優位性

YubiKeyなどのハードウェアキーや生体認証デバイスを用いるFIDO2規格（パスキー）は、ブラウザが「現在アクセスしているドメイン名」を暗号的チャレンジに組み込んで検証します。そのため、ユーザーが精巧な偽サイト（例: g00gle.com）に騙されても、認証プロトコル自体が「ドメインの不一致」を検知してログインを物理的にブロックします。URLを見間違えても防御できる——これがパスキーの本質的な強みです。

認可・委譲：OAuth 2.0 と OpenID Connect (OIDC)

OAuth 2.0（権限委譲フレームワーク）

OAuth 2.0は「アプリAに、ユーザーのパスワードを教えることなく、アプリB（例：Googleドライブ）上のデータへのアクセス権を部分的に渡す（委譲する）」ための仕組みです。

たとえば「Notionを使い始める際にGoogleアカウントで連携する」という操作がOAuth 2.0です。あなたはGoogleのパスワードをNotionに教えていません。Googleが「NotionにGドライブの読み取り権限だけを渡すことを許可しますか？」と確認し、承認した分だけのトークンを発行します。

※OAuthは「認証」プロトコルではなく、「権限委譲」のプロトコルです。

最新のセキュリティベストプラクティス（BCP）

かつて多用された「インプリシットグラント（Implicit Grant）」は、トークンがURLフラグメントに露出し漏洩リスクが高いため非推奨となりました。フロントエンドSPAであっても**「PKCE（Proof Key for Code Exchange）を伴う認可コードグラント」**を使用することが現在の世界標準です。

OpenID Connect（OIDC）による認証の標準化

OAuth 2.0の仕組みの上に「ユーザーの身元確認（認証）」の機能を追加したのがOIDCです。JWTフォーマットの「IDトークン」を発行することで、SSO（シングルサインオン）のデファクトスタンダードとなっています。「Google/GitHubでログイン」はすべてOIDCで実現されています。

アクセス制御モデル（AuthZ）の設計戦略

誰がどのリソースにアクセスできるかを決める認可モデルの設計は、情報漏洩を防ぐ最後の砦です。

RBAC（ロールベースアクセス制御）

ユーザーに「ロール（役割）」を付与し、そのロールに対して権限を割り当てます。

  • 利点: 初期導入がシンプルで管理しやすい。
  • 限界: 組織がスケールすると「プロジェクトAの読み取り・プロジェクトBの書き込み権限を持つロール」など、ロール数がユーザー数を上回る「ロール爆発問題」が起きます。100人の組織で200種類のロールが生まれた時点で、管理は破綻します。

ABAC（属性ベースアクセス制御）とゼロトラスト

現在の**ゼロトラストネットワークアーキテクチャ（ZTNA）**で採用されているのがABACです。「ユーザーの属性（所属、クリアランスレベル）」「リソースの属性（機密度）」「環境の属性（接続元IP、会社支給デバイスか、時間帯の妥当性）」という複数の変数を、動的なポリシーエンジン（例: OPA / AWS IAM）でリアルタイムに評価します。

  • 実装例: 「たとえ管理者（ロール）であっても、未パッチの個人スマホから、休日に、本番DB（リソース）へのアクセスを試みた場合は拒否する」——RBACではこのような文脈依存の判断はできません。

JWT（JSON Web Token）の正しい扱い方

マイクロサービス間の認可トークンとして広く使われるJWTですが、実装ミスによる脆弱性が後を絶ちません。現場で実際に見てきた問題点を挙げます。

  1. alg:none 攻撃: ヘッダーのアルゴリズム（alg）を「none」に書き換えて署名検証を突破する古典的な攻撃です。バックエンドで許可するアルゴリズム（例: HS256, RS256）をコードにハードコードして縛ること。ライブラリが「alg=none」を受け入れてはなりません。
  2. 情報の透明性: JWTはBase64エンコードされているだけで**暗号化されていません**。ペイロードは誰でもデコードして読めます。内部パスや個人情報、機密データをペイロードに入れることは重大なミスです。
  3. 失効（Revocation）の難しさ: JWTはステートレスなため、一度発行したトークンは有効期限（exp）まで生き続けます。クリティカルな操作には、DBへの状態確認（ブラックリスト/Redis）と、アクセストークンの寿命を5分程度に設定する短命トークン戦略を組み合わせる必要があります。
理解度チェック

【確認問題】現代の認証・認可におけるベストプラクティスとして「誤っているもの」はどれですか？