Skip to content

DNET_SCAuthAccessControl

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

SC：対策技術 - 認証・アクセス制御

概要

防止・防御、検知・追跡に該当。

※ 基礎の該当節（情報セキュリティ）が参考になる。

認証

基礎（認証）

用語

  • 真正性(Authenticity)
    ある主体（subject）又は資源が、主張（claim）どおりであることを確実にする特性。
    （SC：基礎の該当節を参照）

  • 認証(Authentication)

    • 真正性(Authenticity)を明らかにする行為が認証(Authentication)

    • 認証(Authentication)のプロセスは、識別(Identification)と検証(Verification)で構成される。

    • 識別(Identification)と検証(Verification)をざっくり説明すると、以下の様な感じ。

      • 識別(Identification) ≒ ユーザID
      • 検証(Verification) ≒ パスワード

  • 認可(Authorization)と許可(Permission)

    • 認可(Authorization)
      認証(Authentication)の結果を用いて、アクセス制御を行う。
      コレには、下記のリソースに付与された許可(Permission)の情報も使用している。

    • 許可(Permission)
      原則禁止のトコロ、許可する事を言うらしいが、
      コンピューター界隈では、リソースに付与されている属性を指す。

  • 言語上の混乱

    • 日本では、二つの「認証」で混乱

      • Authentication
        前述の認証で、2者間認証とも言う。

      • Certification
        監査やデジタル署名で、3者間認証とも言う。

    • 英語では、以下が紛らわしい（らしい。

      • Authentication
        前述の認証(Authentication)

      • Identification
        前述の識別(Identification)

  • 参考

分類

  • 対象

    • 人の認証：各種本人認証手段による
    • モノの認証：MACアドレスなど
    • 情報の認証：デジタル署名など

  • 各種本人認証手段
    詳しくは認証基盤の該当節を参照。

    • ユーザが知っていること（知識情報）
    • ユーザが持っているもの（所持情報）
    • ユーザ自身の特徴（生体情報）

固定式パスワード

特徴（固定式パスワード）

  • 方式

    • 基本的な
    • 簡単な
    • 容易な
    • 最古の

  • ちなみに、以下の条件で
    作成可能なパスワードの総数 = M^n らしい。

    • 使用可能な文字種 = M

    • 使用可能な文字数 = n

    • 文字数 = 1-nでの総数は、

       n
 ∑M^i
 i=1

脆弱性（固定式パスワード）

  • 運用面
    ソーシャルエンジニアリングなどに対する非技術的な脆弱性
    （脅威の該当節を参照）

  • 実装面
    パスワード・クラックなどに対する技術的な脆弱性
    （脅威の該当節を参照）

ワンタイム・パスワード(OTP)

特徴（OTP）

  • ランダムな文字列を生成
  • 覚える必要が無い

方式

脆弱性（OTP）

  • チャレンジ＆レスポンス

    • サーバー自体の認証が存在しない。
    • パスワードは平文で保存されている。

  • ワンタイム・パスワードの脆弱性
    （ワンタイム・パスワードの該当節を参照）

ICカードによる認証

特徴（ICカード）

  • 高い耐タンパ性
  • 反面、紛失盗難に弱いので、
    生体認証と組合わせる方式がある。

利用例

  • 公開鍵暗号化

    • 公開鍵で、情報と暗号鍵を暗号化
    • ICカード内の秘密鍵で、暗号化された暗号鍵を復号化
    • 復号化した暗号鍵を使用して暗号化された情報を復号化

  • デジタル署名

    • 秘密鍵で、情報にデジタル署名を付与
    • 公開鍵で、送られてきたICカードの情報を検証

攻撃 / 対策 / 評価

  • 攻撃手段
# 手法 内容
1 破壊攻撃 ICチップに直接アクセス、高コスト
1-1 プロービング ICチップに針を当て信号を読み取る。
1-2 リバース・エンジニアリング ICチップの観察（秘密鍵は漏れないがメカニズムが解明される。）
2 非破壊攻撃（サイドチャネル攻撃） 外部から観察、低コスト
2-1 DPA（Differential Power Analysis） 多数の消費電力波形を統計処理して秘密鍵を推定する。
2-2 SPA（Simple Power Analysis） 消費電力波形を比較解析して秘密鍵を推定
2-3 グリッチ（glitch） flip-flopのサンプリングや誤動作を起こし出力の比較解析して秘密鍵を推定する。
2-4 光照射 不良動作を発生させる攻撃
2-5 タイミング攻撃 時間差を測定することで秘密鍵を推定する。
  • 対策方法
# 手法 内容
1 破壊攻撃 ICチップに直接アクセス、高コスト
1-1 配線の多層化 上層の剥ぎ取りで下層のICチップが破壊されるようにする
1-2 テスト回路の削除 出荷後、テスト回路を使用不可能な状態にする。
2 非破壊攻撃（サイドチャネル攻撃） 外部から観察、低コスト
2-1 センサ センサにより使用範囲外の動作環境で動作しなくする。
2-2 動作クロックの内部生成 アタック・タイミングの同期を困難にする
2-3 メモリ・チェック機構 グリッチによるflip-flopやメモリ値の破壊を検出する。
2-4 暗号化アルゴリズムの工夫 同一演算の時間が異なるようにする
  • 評価
    JIWG(Joint Interpretation library Working Group)が行っている。
    • ICカード評価の公平性、客観性の実現する活動
    • Common Criteria（ISO/IEC 15408）の解釈の統一

生体認証（バイオメトリック認証）

シングルサインオン（SSO）

Cookie認証チケット型の統合認証基盤

  • 認証基盤の該当節を参照。

  • 認証基盤がクッキー認証チケットを発行する。

  • エージェント型とリバース・プロキシ型がある。

  • 製品としては、SiteMinderやIceWall SSO等が有名。

クレームベース認証型の認証基盤

  • 認証基盤の該当節を参照。

  • クロスドメインでのSSOを実現する

  • エージェント型とリバース・プロキシ型、ライブラリ型がある。

  • プロトコルとしては、SAML2、OAuth2、OIDC、FAPI等がある。

リスクベース認証

  • 最近のWebサービスなどで採用されている。

  • 以下の様な情報を元に通常の環境と異なる
    環境からのアクセスを検出し2FA（2要素認証）を要求する。

    • OS
    • ブラウザ
    • IPアドレス
    • 利用時間

その他さまざまな技術

ディレクトリ サービス

RADIUS

  • RADIUS : Remote Authentication Dial In User Service（ラディウス）

  • IP上で認証とアカウンティングを実現するプロトコルと、それを実装したサーバ

    • 目的

      • ネットワーク資源の利用の可否の判断（認証）と、利用の事実の記録を、
      • ネットワーク上のRAS（Remote Access Server）と分離して一元化する。

    • 利用

      • 元はダイヤルアップ・インターネット接続を目的として開発されたが、
      • 昨今は、インターネット接続サービス、無線LANなどで幅広く利用されている。

    • アルゴリズム

      • MD5ハッシュを使用した、チャレンジ＆レスポンス
        （認証基盤の該当節を参照）
      • 最近は、デジタル署名、OTP、生体認証などを提供する
        他の認証サーバに認証要求をフォワードする拡張がされている。

    • 脆弱性
      何れもプロトコル自体の脆弱性ではなくベンダの実装の問題に起因

      • メッセージダイジェストに対するBOF攻撃
      • Vendor-Lengthを2以下に設定したDoS攻撃

  • 参考

TACACS/TACACS+

  • TACACS : Terminal Access Controller Access Control System（タカクス）

  • 目的
    RADIUSとほぼ同様だが、以下の３機能（AAA）をサポート。

    • 認証（AuthN）
    • 認可（AuthZ）
    • 課金（Accounting）

  • 利用
    現在はTACACS+が主流。

    • TACACSは、UDP
    • TACACS+は、TCP

PPP / EAP

層 内容
Authentication層 TLS / MD5 / S/Key / その他
EAP層 EAP（Datalink層 側は EAPOL）
Datalink層 PPP / IEEE802.3（イーサネット） / IEEE802.5（トークンリング） / IEEE802.11x（無線）
  • EAPの認証方式
# 名称 概要 サーバ認証
証明書		 クライアント認証
証明書		 クライアント認証
その他		 無線LANでの安全性
1 EAP-TLS TLSによる相互認証 〇 〇 × 〇
2 EAP-TTLS TLS暗号化通信中でクライアント認証 〇 オプション 選択可 〇
3 PEAP EAP-TTLSとほぼ同じ 〇 オプション 選択可（EAP準拠の方式のみ） 〇
4 EAP-MD5 無線LANに不向き（有線LAN向き） × × MD5のチャレンジ＆レスポンス ×

Kerberos

認可（アクセス制御）

基礎（認可）

以下から構成される。

  • 利用者、若しくは利用者属性

  • リソースに与えられた、
    利用者、若しくは利用者属性に対応する認可情報（パーミッション）

    • 読み、書き、実行などの権限がある。
    • これは、アクセス制御リスト（ACL）と呼ばれる。

実施（場所）

以下、アクセス制御が実施される場所

物理環境

コンピューター・システム的なものではなく、
環境的・物理的（マネジメントの該当節を参照）な、セキュリティ。

ネットワーク環境

ネットワーク機器やF/Wなどで制御できる範囲でのアクセス制御

ホストやアプリケーション

ホストやアプリケーションに対するログインとアクセス制御

システム・リソース

主に、OSの機能で実現されている。

種類

任意（DAC）

強制（MAC）

  • MAC : Mandatory Access Control
  • セキュアOS（SC：対策技術 - 防御・侵入検知の該当節を参照）などに実装がある。
  • 所有者ではなくシステムが決定するアクセス方針
    （サブジェクトやオブジェクトを複数のレベルにクラス分けする）

ロールベース（RBAC）

  • RBAC : Role-Based Access Control
  • Windowsなどの一般的なアクセス制御
  • 任意（DAC）にロール（利用者属性の一つ）を追加した方式

情報フロー制御

  • 情報の流れを分析して情報が、
    上位から下位に移動しないように制御する方式

  • MLSやBLPモデルで制御される。

    • MLS : Multi Level Security
    • 前述の強制（MAC）で利用される。
    • MLSを数学的に定式化した状態遷移モデルがBLP（Bell–LaPadula Model）

  • MLSによるアクセス制御ルール例

ユーザの機密レベル 情報の機密レベル 関係 読取 追記 修正 実行
極秘 極秘 ユーザ＝情報 〇 〇 〇 〇
極秘 秘 ユーザ＞情報 〇 × × 〇
極秘 一般 ユーザ＞情報 〇 × × 〇
秘 極秘 ユーザ＜情報 × 〇 × ×
秘 秘 ユーザ＝情報 〇 〇 〇 〇
秘 一般 ユーザ＞情報 〇 × × 〇
一般 極秘 ユーザ＜情報 × 〇 × ×
一般 秘 ユーザ＜情報 × 〇 × ×
一般 一般 ユーザ＝情報 〇 〇 〇 〇

  • 説明
    ユーザと情報の関係ですべて決まる。

    • ユーザ＞情報：

      • 読取・実行のみ許可（参照）
      • ユーザの方が秘の場合、読取・実行（≒参照）のみ可能。

    • ユーザ＝情報：

      • 更新含め全て許可（当事者）
      • レベルが同じ場合は、すべての操作が可能。

    • ユーザ＜情報：

      • 追記のみ許可（報告）
      • 情報の方が秘の場合、追記・修正（≒報告）のみ可能。

実施（PDCA）

ある意味、PDCA的ではある。

(P) : 方針の明確化

方針＝アクセス制御のルール

(D1) : 実装の明確化

上記の方針をどのような技術で実装するか？

(D2) : 実装

実装の明確化≒仕様で、これを実装。

(C) : 適切性評価

方針や実装を評価し、

(A) : 見直し

方針や実装を見直す。

ID管理

ディレクトリ・システム

一般的には、ディレクトリ サービスを使用する

プロビジョニング・システム

  • ID同期。

  • 自動的に複数システムやサービスでIDが整合性を取るよう管理する機能。

  • システムによってユーザ・ストアが異なっているケースがあり、
    これらのストアの情報もマスタとなるディレクトリ・システムから同期する。

  • SAML2のHybrid-IdPなどでは、事前に、ID同期を行った上で、
    ID連携をするなどする場合がある（これは、SAMLの仕様の外）。

アクセス制御システム

※ 元 Wiki では見出しのみで、本文は書かれていない。

ワークフロー・システム

※ 元 Wiki では見出しのみで、本文は書かれていない。

移行メモ

  • 「高い耐タンパ製」→「耐タンパ性」に正した。
  • EAP の認証方式の表の「EPA-TLS」「EPA-TTLS」「PEPA」「EPA-MD5」は、 それぞれ「EAP-TLS」「EAP-TTLS」「PEAP」「EAP-MD5」に正した。
  • MLS によるアクセス制御ルール例の最終行（一般 / 一般）は、 関係が「ユーザ＞情報」でありながら全項目が「〇」であったため、 同レベルを表す「ユーザ＝情報」に正した。
  • 「これは、SAMLの使用の外」→「仕様の外」に正した。
  • リスクベース認証の「2FA」は、元 Wiki のページ内アンカのリンク先が このページに存在しなかったため、リンクを外して「2FA（2要素認証）」とした。
  • 元 Wiki の結合セル（> / ~）を含む表は、GitHub Wiki では再現できないため、 セルの内容を展開し、番号列は「1-1」のような表記に直して平坦な表にした。 また EAP のプロトコル・スタックの図表は、 表では再現しきれないため層ごとの一覧に整理した。
  • 元 Wiki で見出しそのものが他ページへのリンクになっていた箇所 （「生体認証（バイオメトリック認証）」「Cookie認証チケット型の統合認証基盤」 「クレームベース認証型の認証基盤」「ディレクトリ サービス」「PPP / EAP」 「Kerberos」）は、GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
  • 同名の見出しが複数あり GitHub Wiki でアンカが衝突するため、括弧で文脈を補って一意にした （「基礎（認証）」「基礎（認可）」「特徴（固定式パスワード）」「特徴（OTP）」 「特徴（ICカード）」「脆弱性（固定式パスワード）」「脆弱性（OTP）」 「実施（場所）」「実施（PDCA）」）。
  • マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの 認証基盤 / ワンタイム・パスワード / 生体認証 / ディレクトリ サービス / ネットワークの基礎編 / ケルベロス認証 に張り替えた。
  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
  • 未移行のページはファイル名を予約し、TODO.md に記録した。

Tags: 移行, 資格, SC, 対策技術, 認証, 認可, アクセス制御, ワンタイム・パスワード, ICカード, 生体認証, SSO, RADIUS, TACACS, EAP, Kerberos, DAC, MAC, RBAC, MLS

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally