...

資料 - 国立情報学研究所

by user

on
Category: Documents
1

views

Report

Comments

Transcript

資料 - 国立情報学研究所
認証局を実際に運用するには
国立情報学研究所
学術ネットワーク研究開発センター
島岡 政基
Sep 4, 2008
H20情報処理軽井沢セミナー
1
なぜ認証局は信頼できるのか?
認証局に求められること
高い
セキュリティ
運用の
継続性
高いセキュリティが継続的に担保される仕組み
CP/CPS
セキュリティレベルの宣言
Sep 4, 2008
定期監査
CP/CPSを裏付ける実践
H20情報処理軽井沢セミナー
2
認証局のPDCAサイクル
①運用文書の策定
・CP/CPS
・運用規程・業務規程
・各種手順書 等
Plan
確立・計画
④監査指摘事項に
もとづく是正・改善
・CP/CPS・規程類の改訂
・各種手順書の改訂 等
Act
見直し
Do
運用
Check
検査
③定期監査
Sep 4, 2008
②運用文書にもとづく
認証局運用
・週次・月次メンテナンス
・定期メンテナンス
・各種申請受付・対応
・教育/啓蒙 等
・CP/CPS・規程類への適合性確認
・ログ・帳票等の試査 等
H20情報処理軽井沢セミナー
3
認証局の運用に必要なもの
„
„
„
„
„
„
„
システム
施設・設備
規程類
マニュアル類
帳票類
運用組織・体制
運用要員
Sep 4, 2008
H20情報処理軽井沢セミナー
4
施設・設備のセキュリティ(例)
„
CA室
{
{
いわゆるサーバルームにCAを設置
サーバルームへの入退室は個人のICカード
„
„
{
CAを設置したサーバラックの開錠は、ラック管理者の承認が必要
„
„
„
RA室
{
{
{
{
Sep 4, 2008
単なる認可ではなく、「誰が」を特定することが証跡として重要
退室記録も取ることで、入室者と在室時間帯を明確化
CA管理者が単独行動で不正できない仕組み
実際の開錠はCA管理者が行う
いわゆるオペレーションルームにRA端末を設置
オペレーションルームへの入退室は個人のICカード
RA責任者、RA担当者はICカードでRA端末にログイン
各種申請書(紙媒体)は全てRA室の施錠ロッカーで保管
H20情報処理軽井沢セミナー
5
運用開始までの流れ
Sep 4, 2008
1. 運用設計
組織・体制
ポリシ、規程、マニュアル
ワークフロー、帳票
システム運用・監視、障害対策
2. 引き継ぎ
構築・開発チーム→運用チーム
3. 運用開始
キーセレモニー
4. 定常業務
各種申請受付・対応
ヘルプデスク
定期メンテナンス
5. 定期監査
指摘事項に対する是正
H20情報処理軽井沢セミナー
6
運用組織・体制の例
ポリシ委員会
運用責任者
CP/CPSなどの策定・改廃の指示
監査指摘事項への対応指示
システム変更・運用手続変更の承認
各運用担当者への作業指示
CA鍵ペア操作に関する作業立ち会い
CA管理者
CA鍵ペア操作に関する作業の実施
システム設定・変更の実施
RA責任者
RA担当者の作業承認
RA担当者
発行・失効・更新の申請受付および試査
発行・失効・更新に関する作業の実施
ログ検査者
定期的なログ検査の実施
ヘルプデスク 加入者からの問い合わせ対応など
監査者
Sep 4, 2008
定期的な監査の実施
運用部門から独立している必要あり
H20情報処理軽井沢セミナー
管理部門
•ポリシ委員会
監査部門
•監査者
運用部門
•運用責任者
•CA管理者
•(RA責任者)
•RA担当者
•ログ検査者
•ヘルプデスク
7
運用の文書体系
„
方針 (Policy)
{
{
„
規程 (Rule)
{
{
„
Why: 基本的な考え方 を示す文書
あるべき論、要求仕様
What: 方針を実践するための基準を示した文書
基本設計、機能仕様
手順 (Manual)
{
{
How: 方針・規定を実践するための具体的な
方法を示した文書
詳細設計、操作手順
方針
規定
手順
Sep 4, 2008
H20情報処理軽井沢セミナー
8
運用設計(1)
„
CP (Certificate Policy)
{
{
„
CPS (Certification Practice Statement)
{
{
„
„
証明書の発行・失効・更新の登録・発行業務などに関する方針
本人性確認、加入者鍵ペア管理、証明書の用途など
認証局の運用業務などに関する方針
物理的セキュリティ、権限分離、監査、認証局自身の鍵ペア管理など
1認証局に対して1本のCPSと1本以上のCP
CPが1本だけの場合、CP/CPSを1本の文書にまとめることもある
認証局
CP (サーバ証明書用)
CPS
CP (教職員証明書用)
CP (学生証明書用)
Sep 4, 2008
H20情報処理軽井沢セミナー
9
CP/CPSの網羅性
„
CP/CPS Framework
{
{
{
RFC 3647で定義 (RFC 2527から改訂)
CP/CPSの文書構成を体系化したもの
ほとんどのCP/CPSが準拠
„
„
UPKI共通仕様のCP/CPSガイドラインも当然準拠
Frameworkによる網羅性確保
{
やる項目、やらない項目の明確化
„
„
Sep 4, 2008
やらない項目を削除すると網羅性が確保できない
文書構成が共通なので把握・比較しやすい
H20情報処理軽井沢セミナー
10
CP/CPS Framework
1.
2.
3.
4.
5.
6.
7.
8.
9.
はじめに
公開とリポジトリの責任
本人性確認と認証
証明書のライフサイクル
設備、管理、運用上の統制
技術的セキュリティ管理
証明書、失効リスト、OCSPのプロファイル
準拠性監査とその他の評価
他の業務上の問題及び法的問題
Sep 4, 2008
H20情報処理軽井沢セミナー
11
網羅性確保の例
NIIオープンドメイン認証局CPより
„
„
„
6. 技術面のセキュリティ管理
6.1 鍵ペアの生成と導入
6.1.1 鍵ペアの生成
{
{
{
„
6.1.2 加入者への秘密鍵の送付
{
„
本CA では、FIPS140-2 レベル3 準拠のハードウェアセキュリ
ティモジュール(Hardware Security Module:以下、
「HSM」という)上でCA の鍵ペアを生成する。
鍵ペアの生成作業は、複数名の権限者による操作によって行う。
加入者の鍵ペアは、加入者自身で生成する。
加入者の秘密鍵は、加入者自身が生成する。本CA からの秘密鍵
の送付は行わない。
6.1.3 認証局への公開鍵の送付
{
Sep 4, 2008
本CA への加入者公開鍵の送付は、オンライン若しくはオフライ
ンによる安全な方法によって行われる。
H20情報処理軽井沢セミナー
12
CP/CPSの事例
„
UPKIサーバ証明書プロジェクト
{
{
{
{
„
UPKI共通仕様
{
キャンパスPKI CP/CPSガイドライン (アウトソース編・インソース編)
キャンパスPKI CP/CPSテンプレート (アウトソース編・インソース編)
https://upki-portal.nii.ac.jp/upkispecific
{
http://repository.secomtrust.net/
{
https://www.verisign.co.jp/repository/
{
{
„
„
NIIオープンドメイン認証局CP
https://repo1.secomtrust.net/sppca/NII/ODCA/NIIODCA-CPV3.pdf
セコム電子認証基盤認証運用規程
https://repo1.secomtrust.net/spcpp/SECOM-CPS.pdf
セコムトラストシステムズ リポジトリ
日本ベリサイン リポジトリ
Sep 4, 2008
H20情報処理軽井沢セミナー
13
運用設計(2)
„
運用管理規程
{
CP/CPSにもとづいて運用業務で行う事項を規定する
„
{
„
運用手順が参照する網羅的なリファレンス
利用者合意事項 (Relying Party Agreement)
{
{
„
具体的な方法はマニュアルで記述
利用者が負うべき責任範囲、認証局が利用者に対して負う
べき責任範囲について規定する
そもそも利用者は、認証局との間に明確な契約行為が発生
しないため、こうした合意文書が必要とされる
加入者合意事項 (オプション)
{
Sep 4, 2008
認証局との契約行為の中で規定されるため、改めて別途用
意する必要はほとんどない
H20情報処理軽井沢セミナー
14
運用管理規定の網羅性
ISMSとのマッピング
要件
検討内容
ポリシの策定
CP/CPS、運用・業務規程など
組織・体制
ポリシ委員会の設置、各責任者・担当者の任命など
運用対象の定義
CA/RA/リポジトリなどのシステム、各システムの動
作環境(OS)、物理的な機器と設置場所(部屋)など
人的セキュリティ セキュリティ教育、職務範囲の定義など
物理セキュリティ 入退室管理、電波漏洩対策、災害対策など
通信・運用の管理 許容・遮断する通信の規定、F/WやIDSの設置など
システム保守
脆弱性対策、ソフトウェアのライフサイクル管理など
アクセス管理
権限分離、パスワード管理など
業務継続計画
可用性、SLA、障害対策、復旧計画など
適合性
情報セキュリティポリシ、UPKI共通仕様など
Sep 4, 2008
H20情報処理軽井沢セミナー
15
利用者合意事項記載項目の例
„
„
„
„
„
„
„
証明書の用途
利用者の義務
認証局の保証内容
免責事項
補償額
準拠法
その他
Sep 4, 2008
H20情報処理軽井沢セミナー
16
利用者合意事項の事例
„
UPKIサーバ証明書プロジェクト
{
{
„
日本ベリサイン
{
{
„
サーバ証明書利用に係る申合せ
https://upki-portal.nii.ac.jp/cerpj/riyo.pdf
依拠当事者規約
https://www.verisign.co.jp/repository/rpa.html
セコムトラストシステムズ
{
{
Sep 4, 2008
セコムパスポート for G-ID 注意事項
http://www.secomtrust.net/service/ninsyo/gchu.ht
ml
H20情報処理軽井沢セミナー
17
運用設計(3)
„
RA業務マニュアル
{
{
{
„
RA操作マニュアル
{
{
„
登録・発行に係る認証局・RAの操作手順書
対象: RA担当者
システム運用マニュアル
{
{
„
発行・失効・更新に係る業務の手順書
登録審査に必要な書類、確認項目、合否基準などを含む
対象: RA担当者(およびRA責任者)
認証局システムの操作手順書
対象: CA管理者
加入者マニュアル
{
{
{
Sep 4, 2008
加入者が各種申請や証明書を利用するための手順書
サーバ証明書、S/MIME証明書など用途に応じて内容は異なる
対象: 加入者
H20情報処理軽井沢セミナー
18
ワークフロー設計(例)
„
発行フロー
{
{
{
„
失効フロー
{
{
„
発行申請書
発行(準備)完了通知書
証明書受領書
失効申請書
失効完了通知書
発行+失効で代替す
る場合も多い
更新フロー (オプション)
{
{
{
{
Sep 4, 2008
更新申請書
更新(準備)完了通知書
新証明書受領書・旧鍵ペア廃棄報告書
失効完了通知書
H20情報処理軽井沢セミナー
19
監査を意識した
ワークフロー・帳票設計
„
誰がどの項目を記載するのか
{
„
誰がどの項目を確認するのか
{
{
„
記載事項について責任を負う人を明確化
確認時に参照する台帳類
確認時の判断基準、NG時の手続き
確認完了の証跡をどこに残すのか
{
{
誰が、いつ、何を
確認の粒度はトレードオフ
„
Sep 4, 2008
粒度が細かいほど否認防止に役立つが作業は煩雑化
H20情報処理軽井沢セミナー
20
帳票設計の例
加入者
…
確認担当者
…
審査結果
…
○× 太郎
…
△□
…
○
…
:
花子
:
:
参照情報・確認方法などが唯
一であればこれでも十分
加入者
…
確認担当者
…
実在性確認
本人性確認
…
○× 太郎
…
△□
…
○
○
…
:
:
:
加入者
花子
:
…
実在性確認
参照情報
確認担当者
確認方法
H21年度職員録
同左
Out-of-Band Call
…
人事発令 H21-123号
同左
対面
…
:
:
:
…
△□ 花子
☆◇ 次郎
…
△□
Sep 4, 2008
…
確認担当者
○× 太郎
:
本人性確認
花子
:
H20情報処理軽井沢セミナー
21
システム監視
„
監視ポリシ
{
{
„
セキュリティ上の留意点
{
CAに限っては、inboundアクセスを避けるため、
エージェントを用いるなど工夫する必要あり
CA室への入室が頻繁に発生する監視はダメ
{
CRLの発行確認(特にLDAPベースの場合)
{
„
定常業務を遂行できる状態にあるかどうか
サービスレベルでの監視
その他
„
„
Sep 4, 2008
ファイルタイムスタンプでは確認ができない
modifiedTimeなどのオペレーション属性を参照する
H20情報処理軽井沢セミナー
22
障害対応
„
システム(OS)のバックアップ・リストア
{
{
„
ネットワーク設定、アカウント情報、各種アプリケーションなど
スタティックな情報に限定してバックアップ頻度を少なくする
→ディスクコピーなど
CAデータのバックアップ・リストア
{
{
CA設定情報、監査ログなど
こまめに差分バックアップ
„
„
リストアを短時間で行うには、フルバックアップもそれなりにこまめ
に。
復旧作業時間とCRL更新
CRLに記載する更新周期(48h)
CRLに記載する更新周期(48h)
実際の更新周期
(24h)
Sep 4, 2008
最短復旧猶予
(24h) +α
H20情報処理軽井沢セミナー
23
システム引き継ぎ
„
運用メンバにて一連の作業を全て実行して
みる
{
{
„
運用要員の教育
各マニュアル・帳票等のデバッグ
障害対応
{
一連の復旧手順を可能な限り実行してみる
„
{
{
Sep 4, 2008
再現不可能・実行困難な作業を除く
作業時間の見積り
対応に必要な連絡先の確認・調整
H20情報処理軽井沢セミナー
24
キーセレモニー(例)
„
運用責任者立ち会いの下、CA管理者が以下
の操作を行う
{
{
{
„
CAの初期化
CA鍵ペアの生成・バックアップ
CA証明書・CRLの発行
CA鍵ペアの生成やCAの初期化に不正がない
ことを確認することが目的
{
{
Sep 4, 2008
厳格な例では、CAの物理サーバを開梱するとこ
ろからやる、という話も。。。
何時間かかるのか??
H20情報処理軽井沢セミナー
25
結託不正の防止・検知
„
よく認証局の運用担当者は2名ペアの相互牽制で運
用する、と言われるが…
{
{
{
一人が端末操作、もう一人が操作の監視
共犯に対する司法取引が成立する米国ならではの文化
日本では必ずしも抑止効果は期待できない
„
„
人的コストが倍になるのでコストパフォーマンスも悪い
権限分離と証跡(否認防止)をうまく使いこなして解
決する
{
例: CA管理者がCAを操作するためには、、、
„
„
„
„
Sep 4, 2008
CA操作の承認→運用責任者
CA室への入室→生体認証
CAマシンのラック開錠→ラック管理者
CAマシンへのログイン→運用責任者
H20情報処理軽井沢セミナー
26
定常運用(例)
„
週次・月次メンテナンス
{
{
{
{
„
監査ログのアーカイブ
発行・失効・更新件数、ログの照合
TripwireなどでOS上の設定ファイル等の改ざん検知
差分バックアップ・ログローテーション等
定期メンテナンス
{
{
{
{
„
これだけ
ログ検査者の業務
予備機の稼働確認
CA鍵ペアのバックアップ
フルバックアップ
パスワード変更等
いずれもCA管理者の作業
Sep 4, 2008
H20情報処理軽井沢セミナー
27
定期監査の目的
„
ポリシ・規程類と手順のギャップを埋める
{
{
„
不備を見つけ、改善するための作業
{
{
{
„
不正を暴くことが第一の目的ではない
齟齬に目を背けることなく積極的に是正する姿勢を示すことが
重要
是正事項なし(満点)は、むしろ信頼できないと考えるべき
認証局運用の公正性を利用者に示す証跡となり得る
{
{
{
„
ポリシ・規程類に対する運用手順の適合性を確認
現実的な運用手順に対して、机上で策定したポリシ・規程類を
改訂
必ずしも公開する必要はない。必要に応じて開示。
利用者が関係者のみ(学内など): 内部監査でも十分
利用者が部外者である場合: 外部監査が望ましい
PDCAサイクルの継続こそが信頼
Sep 4, 2008
H20情報処理軽井沢セミナー
28
監査の流れ
„
„
„
„
監査形態
{
外部監査 or 内部監査
{
スケジュール、担当などを決定
{
CP/CPS、情報セキュリティポリシ、etc.
監査計画書
監査基準
監査チェックリスト
{
規程類と手順書の整合
運用証跡(ログ、帳票など)を用いた試査
セキュリティ設定の確認
{
指摘事項とそれにもとづく是正
{
{
„
監査報告書
Sep 4, 2008
H20情報処理軽井沢セミナー
29
監査計画立案の例
項目
監査対象
内容
RA(CAはアウトソース)
監査対象期間 2008/04/01∼2009/03/31
監査体制
監査責任者、監査担当者を明記
(運用関係者は監査体制に含めてはならない)
監査実施時期 2009/04/xx∼2009/04/xx
項目
管理レベル
運用レベル
技術レベル
監査目標 ポリシ・規程類に対する
運用手順の適合性
運用手順書に対する ポリシ・規定類に対する
運用証跡の適合性
セキュリティ設定の適合性
監査手続 運用手順の精査
運用証跡の試査
Sep 4, 2008
H20情報処理軽井沢セミナー
セキュリティ設定の精査
30
監査チェックリストの例
管理レベル
監査基準(CP)
確認結果
監査結果
是正内容
:
:
:
:
3.2.1 私有鍵の所持を証明する方法
加入者が公開鍵に対して自己署名した
CSRを、認証局が受け取り署名検証する
ことで、加入者が公開鍵と対になる私有
鍵を所有していることの確認とする。
:
4.3.2 証明書発行後の通知
本CAは、証明書発行後速やかに加入者の
指定したメールアドレスに対して証明書
を送付する。
:
Sep 4, 2008
RA業務マニュアル
3.3.4 CSRの審査
OK
なし
スクリプトを用いて以下の項目を確
認する。
・CSRの署名検証
・鍵長が1024bit以上
:
RA業務マニュアル
3.5.5 証明書の送付
:
指摘
H20情報処理軽井沢セミナー
加入者が受領したことを確認で
きる仕組みがあるべき。
→証明書配付をダウンロード形
式として、ダウンロード完了を
以て受領確認とするよう修正す
る。
証明書をPEM形式に変換し、台帳に
記載された加入者メールアドレスに
送付した後、台帳のステータスを送
付完了に更新する。
:
:
:
:
31
監査チェックリストの例
運用レベル
監査基準(RA業務マニュアル)
試査
監査結果
是正内容
:
:
:
:
台帳のステータスが「申請受
領」以降の記録のうち、全体
の3%以上をランダムに抽出し
て、各発行申請書の以下の項
目を確認する。
・記入漏れがないこと
・加入者合意事項がチェック
されていること
OK
[9/9]
:
:
3.2 (d) 申請の受付
発行申請書について以下の項目を
確認する。
・記入漏れの有無
・加入者合意事項のチェック
確認後、台帳のステータスを「申
請受領」に更新する。
:
Sep 4, 2008
H20情報処理軽井沢セミナー
なし
:
32
監査チェックリストの例
技術レベル
監査基準(CP)
確認結果
監査結果
是正内容
:
:
:
:
4.9.7 CRLの発行周期
CA構築マニュアル
4.2 CA設定シート
CRLは失効処理の有無に関わらず、 /usr/etc/openssl.cnf
24時間ごとに更新を行う。
default_crl_days= 3
CRLの有効期間は72時間とする。
OK
なし
6.3 タスクスケジューリング
/etc/crontab
0 0 * * * root
/opt/ca/crlpub.sh
:
Sep 4, 2008
:
H20情報処理軽井沢セミナー
:
:
33
まとめ
„
網羅性の確保が重要
{
{
„
精度は後から上げられる
{
{
{
„
リファレンスをうまく活用
RFC 3647、ISMS、既存の規程類など
PDCAサイクルを回すことで必要な精度がわかってくる
最初からガチガチにすると大変
後から下げるのは勇気が要る
信頼は一日にして成らず
{
{
PDCAサイクルを回すことが信頼につながる
継続は金では買えない
漏れがないようしっかり囲んで
後でゆっくり積み上げていく
Sep 4, 2008
H20情報処理軽井沢セミナー
34
Q&A
Sep 4, 2008
H20情報処理軽井沢セミナー
35
Fly UP