lu100101の日記

勉強の記録

1. 認証とアクセスコントロール

アクセスコントロール

  • 識別
    • アクセスする主体を見分けること
  • 認証
    • 正当な利用者で間違いないことを確認すること
  • 権限
    • 与えられている権利、もしくはその範囲

アクセスコントロールの種類

  • DAC(任意アクセス制御)
    • 自分の所有するリソースに自分でアクセス権を設定する
    • 全体統制を取ることが難しい
  • MAC(強制アクセス制御)
    • 特定の管理者によってセットされるセキュリティポリシに基づきアクセス権を設定・管理する
    • 機密情報の管理に向く
  • RBAC(ロールベースアクセス制御)
    • 権限をロール別に付与し、利用者はその時点で適した役割に参加させてマッチングさせる
    • 柔軟に権限を変更させるケースに向く

アクセス権付与の原則

  • 責務の分離の原則(権限分掌)
    • 複数のサブジェクトに権限を分離することで、不正防止や過失の減少につなげるという統制の考え方
  • 最小権限の原則
    • サブジェクトには必要最小限の権限を与え、必要のない権限を与えないという原則

特権ID

  • 最小権限の原則
    • 特権IDでも変わらない
  • 相互牽制
    • 複数人が集まらないと利用できないように権限を分掌する
  • 特権IDを使ってデータベースを直接変更する場合など重要な操作をするときは
    • 事前申請
      • 期間の制限
    • 業務日報
      • ログと確認できるように
    • ログ
      • ログそのものの操作権限も与えない

利用者ID

  • 個人を特定する目的で使われる
    • 共同利用しない
    • 利用者に貸し借りを禁じる
  • ID発行時には標準化された手続に基づいて申請・決済して速やかに発行する
  • 退職や異動で不要になった場合は正規の手続きを経て速やかに抹消する

パスワード - NIST(米国立標準技術研究所)の「電子的認証に関するガイドライン」 - 覚えにくいパスワードより、桁数の長い覚えやすいパスワード - 定期的に変更を強制するより、漏洩の可能性が発生した時に変更すればよい - 同じパスワードを異なるサイトで使い回さない

安全なプロトコル

  • TELNETSSH
    • PWDを平文で送信
  • FTPSSH
    • ID/PWDは平文で送信
  • HTTP BASIC認証 → DIGEST認証
    • ID/PWDは平文で送信 → PWDを暗号化(チャレンジレスポンス方式)
  • SMTPSMTP-AUTH → SASL
    • 認証なし → 認証あり
  • POP3 USER/PASS → APOP
    • ID/PWDは平文で送信 → PWDを暗号化(チャレンジレスポンス方式)
  • IMAP4 → SASL

SASL

  • PLAINやLOGINでは平文のまま認証情報をやりとりするので安全ではない
  • PLAIN
    • 通常の平文による認証方式
  • LOGIN(平文)
    • 通常の平文による認証方式
  • CRAM-MD5
    • MD5で作成したメッセージダイジェストを使ってチャレンジレスポンス方式で認証する方式
  • Digest-MD5
    • CRAM-MD5の改良版

チャレンジレスポンス方式の手順

  • 認証依頼側からIDでアクセス
  • 認証する側は、チャレンジコードを発行
  • チャレンジコード + PWDなどでハッシュ計算 = レスポンス
  • レスポンスを送信
  • 認証側でも同じ計算をして突合せ

ワンタイムパスワード

  • S/KEY方式
    • パスフレーズ
      • サーバとクライアントで秘密に管理するパスワード
    • シード
      • サーバからクライアントに送られる乱数
    • シーケンス番号
      • サーバで管理している、ハッシュ関数を使った計算をする回数の意味を持つ番号
      • 1回使うごとに1ずつ減じ、0になる前に再度サーバ側でパスフレーズを生成し、新たなシーケンス番号を取得する
    • 事前準備
      • サーバのパスフレーズを登録
      • 新たにシーケンス番号を設定
      • サーバで直接操作するか、リモート操作の場合はSSHでログインして実施する
    • ログイン時
  • タイムスタンプ方式(時刻同期方式)
    • トークンと呼ばれるパスワード計算機を使った方式
    • トークンと、サーバで管理するパスワードを一定期間ごとに変えることで毎回異なるパスワードでアクセスを可能にする
    • 同期方式に時間を使う
    • トークンの種類

リスクベース認証

  • ログイン時の端末環境や場所、時間帯などの情報から「いつも通りかどうか」という視点で、「本人かどうか」を判定する
  • いつも通りでないと判断した場合は、予め登録しておいた秘密の質問や合言葉のようなものを追加し、不正利用を防ぐ

シングルサインオン

  • SAML認証
    • IDP
    • SP
      • Service Provider
      • アクセスするサーバに設定しておく
      • 認証要求メッセージをブラウザ経由でIDPに送信
      • 認証アサーションを検証して、ユーザを認証する
    • リダイレクト
  • OpenID
  • SPNEGOプロトコル
    • SPNEGOによるSSOを利用する設定が行われているクライアントがSPNEGO対応の認証サーバにアクセスする
    • サーバはHTTP応答を返す
    • クライアントはKDCからTGTを取得し、さらにSPNEGO対応の認証サーバのSTを取得する(Kerberos認証)
    • クライアントはそのSTとHTTP要求を認証サーバに送る
    • サーバはSTを検証し、問題なければSSOを可能にする認証Cookieを発行する
  • Kerberos
    • レルム
      • 認証の範囲
    • KDC
      • Key Distribution Center
      • 1台でレルム内全体を管理するサーバ
      • AS + TGS + KDB
      • AS
        • Authentication Server(認証サーバ)
      • TGS
        • Ticket Granting Server(チケット認可サーバ)
      • KDB
        • Kerberos DataBase
        • principals + その共有鍵
      • principals
        • レルム内のすべてのリソース
    • TGT
      • Ticket-Granting Ticket(チケット認可チケット)
    • ST
      • Service Ticket(サービスチケット)
    • 認証の手順
      • 利用者は最初にKDC内のASにアクセスし、自分のIDとパスワードを入力し、認証を要求
      • 問題がなければASはTGTとその後使用するセッション鍵(クライアント-TGS間)を発行
        • ここまでのやり取りは共有鍵で暗号化するので安全
      • 次にKDC内のTGSに対して、アクセスしたいリソース(サーバB)のSTを要求する
        • この時にTGTを使用する
      • ここでも問題なければTGSから、サーバBの共有鍵で暗号化されたサーバ使用許可証(サーバBのST)とクライアント-サーバB間のセッション鍵が発行される
        • ここまでのやり取りはクライアント-TGS間のセッション鍵で暗号化されているので安全
      • クライアントはSTを用いてサーバBにアクセスする
        • このやり取りはクライアント-サーバB間ののセッション鍵で暗号化されているので安全

バイオメトリクス認証

  • 正常認識
    • 本人受入率
    • 他人拒否率
  • 異常認識
    • 他人受入率
    • 本人拒否率

IEEE 802.1X認証

  • モバイル端末を会社のLANや無線LANに接続する際に求められる強固な利用者認証を実現する規格
  • ネットワークに参加するために物理的に端末をLANポートに接続することに加え端末認証を必要とする
    • 正接続によるネットワーク侵入を防止
    • 私用PCの勝手な接続を防止
    • セキュリティ上問題を抱えている端末を検査して治療した上で接続
  • 対応したLANスイッチ製品や無線LAN製品(オーセンティケータ)と認証サーバ(RADIUS、CA)が、端末にも対応ソフト(サプリカント)が必要
  • EAP(認証)
  • 検証ネットワーク
    • クライアントPCの安全性を検査するために社内LANから隔離されたネットワーク
    • 認証サーバが認証した後、検査サーバがセキュリティパッチ適用状況を確認し不合格なら、治療サーバがセキュリティパッチを配布する

ICカード

  • 脅威とセキュリティ対策
    • 不正利用
      • PINによる所有者本人確認(ホルダ認証)
    • 偽造カードの利用
      • 相互認証(内部認証)端末がICカードの正当性を認証
    • 不正読出し・不正書込み
      • 相互認証(外部認証)ICカードが端末の正当性を認証
    • 盗聴
      • 暗号化
  • 耐タンパ性
  • PIN
    • Personal Identification Number
    • カード使用者が正当な利用者であることを証明するためにICカードを使用するときに入力する番号
    • アカウントロックアウト
    • ロックアウトの解除方法
      • 管理者が新たに鍵ペアを生成(再発行)
      • 管理者PINでアクセスし、再度初期PINを設定する
        • 管理者用パスワードが漏洩した場合の変更が困難
      • 解除用コマンドを用意しておき、利用者を確認して利用者に伝える
  • 内部格納情報のセキュリティ属性の例
    • PIN
      • 書込みだけ可
      • 初期設定から変更したり、所有者が定期的に変更したりする
    • 所有者の秘密鍵
      • 読み書き不可
      • 作成、利用、破棄のいずれも専用のコマンドを使ってICカード内部で行われる
    • 所有者の公開鍵証明書
      • 読み書き可
      • 公開鍵をCAに送ってCAから得るものなので外部から書き込める必要がある
      • 公開鍵証明書は第三者に公開されるものであり、必要に応じて配付されなければならないため読出し可能でないといけない

新しい認証技術

  • 二要素認証
    • 記憶(知識)
    • 所有
    • 生体
  • 3Dセキュア
    • カード情報だけでなく、予めカード会社に登録したパスワード等を用いて認証する方式
  • FIDO認証
    • First IDentity Online
    • FIDO Allianceが策定
    • パスワードレス認証を目指す
    • 認証手順
      • 端末側で鍵ペアを生成し、公開鍵を事前にサービスに設定しておく
      • サービスからクライアントにチャレンジコードを送信し署名を要求
      • 端末側ではデバイス(認証器)の持つ生体認証などを利用して本人確認
      • 本人確認ができたら、秘密鍵でチャレンジコードを暗号化してサービスに送信する
      • サーバ側では、公開鍵を使って元のチャレンジコードを取り出して認証を行う
    • 認証情報がデバイス側に保存されておりネットワーク上を流れないため安全で、端末側での生体認証等を活用するため利便性も向上
    • 主な規格
      • UAF
        • Universal Authentication Framework
        • FIDO対応の認証器を使った認証
        • スマホからの利用を想定
        • バイス側で生体認証を行う
      • U2F
        • Universal Second Factor
        • FIDO対応の認証器が不要
        • Webブラウザからの利用を想定
        • パスワードとUSBキーなどを使った二要素認証
      • FIDO2
        • WebAuthn
          • Web Authentication
        • CTAP
          • Client To Authentication Protocol

認証情報の窃取

  • ネットワークの盗聴
  • キーロガー
    • 端末から入力されたIDとパスワード等のキー操作が記録され窃取される
    • 対応策
      • ソフトウェアキーボードの使用
  • Webブラウザのオートコンプリート情報の窃取
    • 対応策
      • 利便性との兼ね合いになるが、オートコンプリート機能をOFFにする
  • パスワードクラッキング
    • 総当たり攻撃や辞書攻撃
  • フィッシング
  • ゴールデンチケット
    • 管理者権限を奪取する攻撃