10. Security Considerations (セキュリティ考慮事項)

Kerberosは認証プロトコルであるため, セキュリティはその設計の中心的な側面です。このセクションでは, Kerberos実装と展開における重要なセキュリティ考慮事項について説明します。

10.1. クロックスキュー (Clock Skew)

Kerberosは, リプレイ攻撃を防ぐためにタイムスタンプに依存しています:

クライアント, サーバー, およびKDC間でクロックが同期されている必要があります
デフォルトのクロックスキュー許容範囲は通常5分です
クロックスキューが大きすぎると, 正当な認証が失敗する可能性があります
クロックスキュー許容範囲が大きすぎると, リプレイ攻撃のウィンドウが広がります
NTP (Network Time Protocol) などのメカニズムを使用してクロックを同期することを強く推奨します (RECOMMENDED)

10.2. パスワードの強度

ユーザーのパスワードは, Kerberos認証の基盤です:

弱いパスワードは辞書攻撃に対して脆弱です
実装は強力なパスワードポリシーを強制すべきです (SHOULD)
パスワードの複雑さ要件 (長さ, 文字の種類) を設定することを推奨します
定期的なパスワード変更を検討すべきです
多要素認証 (MFA) の使用を検討することを推奨します

10.3. 鍵の管理

暗号鍵の適切な管理は重要です:

長期鍵 (プリンシパルの秘密鍵) は安全に保存されなければなりません (MUST)
KDCの鍵データベースは物理的およびネットワーク的に保護されるべきです (SHOULD)
セッション鍵は適切に保護され, 不要になったら破棄されるべきです (SHOULD)
鍵のバックアップは暗号化して保存すべきです (SHOULD)

10.4. KDCのセキュリティ

KDCはKerberosシステムの信頼の中心です:

KDCは物理的に安全な場所に配置されるべきです (SHOULD)
KDCへのネットワークアクセスは制限されるべきです (SHOULD)
KDCは専用のハードウェアで実行することを推奨します
KDCのログを監視してセキュリティイベントを検出すべきです (SHOULD)
高可用性のために複数のKDCを展開することを検討すべきです

10.5. ネットワーク攻撃

Kerberosは様々なネットワーク攻撃に対する保護を提供しますが, 完全ではありません:

パケット盗聴: Kerberosは認証情報を暗号化しますが, 暗号化されていないアプリケーションデータは保護しません
中間者攻撃: 初期認証は中間者攻撃に対して脆弱である可能性があります。PKINIT (公開鍵初期認証) の使用を検討してください
パスワード推測攻撃: AS-REQメッセージをキャプチャすることで, オフライン辞書攻撃が可能です。事前認証を使用すべきです (SHOULD)

10.6. 事前認証 (Pre-authentication)

事前認証は, パスワード推測攻撃を防ぐために重要です:

事前認証なしでは, 攻撃者はAS-REPメッセージを取得し, オフラインでパスワードを推測できます
PA-ENC-TIMESTAMP事前認証メカニズムを使用すべきです (SHOULD)
すべてのプリンシパルに事前認証を要求することを強く推奨します (RECOMMENDED)

10.7. クロスレルム認証

クロスレルム認証は追加のセキュリティリスクを導入します:

信頼されたレルムは慎重に選択されるべきです (SHOULD)
transitedフィールドは検証されるべきです (SHOULD)
クロスレルムパスの長さを制限することを検討すべきです
信頼関係は定期的に見直されるべきです (SHOULD)

10.8. サービスチケットの保護

サービスチケットとセッション鍵は適切に保護される必要があります:

チケットは認証された後でも価値があります
プロキシおよび転送可能チケットは特に慎重に扱うべきです (SHOULD)
チケットの有効期限を適切に設定すべきです (SHOULD)
不要になったチケットは資格情報キャッシュから削除すべきです (SHOULD)

10.9. 暗号化アルゴリズム

適切な暗号化アルゴリズムの選択は重要です:

弱い暗号化タイプ (DES, RC4) の使用は避けるべきです (SHOULD)
AES暗号化の使用を推奨します (RECOMMENDED)
暗号化タイプは定期的に見直し, 更新すべきです (SHOULD)
既知の脆弱性を持つ暗号化タイプは無効にすべきです (SHOULD)

10.10. アドレス制限

クライアントアドレスの検証はオプションですが, セキュリティを向上させることができます:

アドレスフィールドは, チケットの盗難に対する追加の保護を提供します
ただし, NAT (Network Address Translation) 環境では問題が発生する可能性があります
方向性アドレスタイプの使用を検討できます (MAY)

10.11. 認可 vs 認証

Kerberosは主に認証プロトコルです:

Kerberosはユーザーのアイデンティティを検証しますが, 認可 (何ができるか) は別のメカニズムで処理される必要があります
アプリケーションは, 認証後に適切な認可チェックを実装しなければなりません (MUST)
AuthorizationDataフィールドは認可情報を伝えるために使用できますが, 慎重に検証する必要があります

10.12. セッション鍵の寿命

セッション鍵の寿命は適切に管理されるべきです:

長時間有効なセッション鍵は, 暗号解析攻撃のリスクを増加させます
チケットの有効期限はセキュリティとユーザビリティのバランスを取るべきです (SHOULD)
更新可能チケットを使用する場合, 最大更新時間を設定すべきです (SHOULD)

10.13. 実装のセキュリティ

実装レベルのセキュリティも重要です:

バッファオーバーフローなどの一般的な脆弱性を回避すべきです (SHOULD)
鍵と認証情報はメモリ内で適切に保護されるべきです (SHOULD)
使用後の機密データはメモリから消去すべきです (SHOULD)
セキュリティ更新を定期的に適用すべきです (SHOULD)

Kerberosは強力な認証プロトコルですが, 適切に実装および展開された場合にのみセキュアです。管理者と開発者は, これらのセキュリティ考慮事項を理解し, 適切な対策を実装する必要があります。