base 管理者ガイド - ibmpublib.boulder.ibm.com/tividd/td/itame/sc32-1132... ·...

IBM Tivoli Access Manager

Base 管理者ガイド

バージョン 4.1

SC88-9522-01

(英文原典：SC32-1132-01)

��

お願い本書および本書で紹介する製品をご使用になる前に、237 ページの『付録 C. 特記事項』に記載されている情報をお読みください。

本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。

http://www.ibm.com/jp/manuals/main/mail.html

なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは

http://www.ibm.com/jp/manuals/ の「ご注文について」をご覧ください。

(URL は、変更になる場合があります)

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　原　典： SC32–1132–01


Base Administrator’s Guide

Version 4.1

　発　行：日本アイ・ビー・エム株式会社

　担　当：ナショナル・ランゲージ・サポート

第1刷 2003.8

この文書では、平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™W5、および平成角ゴシック体™W7を使用しています。この(書体*)は、（財）日本規格協会と使用契約を締結し使用しているものです。フォントとして無断複製することは禁止されています。

　　注* 平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™W5、平成角ゴシック体™W7

© Copyright International Business Machines Corporation 1999, 2003. All rights reserved.

© Copyright IBM Japan 2003

本書は、SC88-9522-00 の改訂版です。

目次

本書について . . . . . . . . . . . . . . . . . . . . . . . . . . ix本書の対象読者 . . . . . . . . . . . . . . . . . . . . . . . . . ix本書の内容. . . . . . . . . . . . . . . . . . . . . . . . . . . ix資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xリリース情報 . . . . . . . . . . . . . . . . . . . . . . . . . x基本情報 . . . . . . . . . . . . . . . . . . . . . . . . . . xiWebSEAL 情報 . . . . . . . . . . . . . . . . . . . . . . . . xiWeb セキュリティー情報 . . . . . . . . . . . . . . . . . . . . xi開発者用解説書 . . . . . . . . . . . . . . . . . . . . . . . . xii技術補足 . . . . . . . . . . . . . . . . . . . . . . . . . . xii関連資料 . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiオンラインでの資料へのアクセス . . . . . . . . . . . . . . . . . xv

アクセシビリティー . . . . . . . . . . . . . . . . . . . . . . . xvソフトウェア・サポートへの問い合わせ. . . . . . . . . . . . . . . . xv本書で使用する規則 . . . . . . . . . . . . . . . . . . . . . . . xvi書体の規則 . . . . . . . . . . . . . . . . . . . . . . . . . xviオペレーティング・システムの相違点 . . . . . . . . . . . . . . . xvi

第 1 章 IBM Tivoli Access Manager の概要 . . . . . . . . . . . . . 1コア・テクノロジー . . . . . . . . . . . . . . . . . . . . . . . 2認証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2許可 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2保護品質 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2スケーラビリティー . . . . . . . . . . . . . . . . . . . . . . 3追跡機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4集中管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

セキュリティー・ポリシーの概要 . . . . . . . . . . . . . . . . . . 5許可 API 標準 . . . . . . . . . . . . . . . . . . . . . . . . . 6許可: 概念モデル . . . . . . . . . . . . . . . . . . . . . . . . 6標準許可サービスの利点 . . . . . . . . . . . . . . . . . . . . . 7Tivoli Access Manager 許可サービスの概要 . . . . . . . . . . . . . . 8

Tivoli Access Manager 許可サービス . . . . . . . . . . . . . . . . . 9コンポーネント . . . . . . . . . . . . . . . . . . . . . . . . 9許可サービス・インターフェース . . . . . . . . . . . . . . . . . 10スケーラビリティーとパフォーマンスの複製 . . . . . . . . . . . . . 11

ネットワーク・セキュリティー・ポリシーのインプリメント . . . . . . . . 12セキュリティー・ポリシーの定義および適用 . . . . . . . . . . . . . 12許可プロセス: 段階的 . . . . . . . . . . . . . . . . . . . . . 13

Tivoli Access Manager 許可 API. . . . . . . . . . . . . . . . . . . 14許可 API の使用: 2 つの例 . . . . . . . . . . . . . . . . . . . 15許可 API: リモート・キャッシュ・モード . . . . . . . . . . . . . . 16許可 API: ローカル・キャッシュ・モード . . . . . . . . . . . . . . 17

外部許可機能. . . . . . . . . . . . . . . . . . . . . . . . . . 18許可サービスの拡張 . . . . . . . . . . . . . . . . . . . . . . 18リソース要求の条件の制定. . . . . . . . . . . . . . . . . . . . 19許可評価プロセス . . . . . . . . . . . . . . . . . . . . . . . 19外部許可サービスのインプリメント . . . . . . . . . . . . . . . . 21デプロイメント計画 . . . . . . . . . . . . . . . . . . . . . . 21

© Copyright IBM Corp. 1999, 2003 iii

第 2 章 Tivoli Access Manager の管理 . . . . . . . . . . . . . . . 23ドメイン . . . . . . . . . . . . . . . . . . . . . . . . . . . 23保護オブジェクト・スペース . . . . . . . . . . . . . . . . . . . . 23ユーザーおよびグループ . . . . . . . . . . . . . . . . . . . . . 25セキュリティー・ポリシー. . . . . . . . . . . . . . . . . . . . . 26ACL ポリシー . . . . . . . . . . . . . . . . . . . . . . . . . 27許可サービスでの ACL ポリシーの使用. . . . . . . . . . . . . . . 27ACL の評価 . . . . . . . . . . . . . . . . . . . . . . . . . 28

POP ポリシー . . . . . . . . . . . . . . . . . . . . . . . . . 29セキュア・オブジェクト・スペースのガイドライン . . . . . . . . . . . 29

第 3 章デフォルトのセキュリティー・ポリシー . . . . . . . . . . . . 31デフォルトの管理ユーザーおよびグループ . . . . . . . . . . . . . . . 31グループ iv-admin . . . . . . . . . . . . . . . . . . . . . . . 31ユーザー sec_master . . . . . . . . . . . . . . . . . . . . . . 31グループ ivmgrd-servers . . . . . . . . . . . . . . . . . . . . . 32管理ユーザーの作成 . . . . . . . . . . . . . . . . . . . . . . 32管理 ACL ポリシーの例 . . . . . . . . . . . . . . . . . . . . 33

セキュリティー・ポリシーの定義および適用 . . . . . . . . . . . . . . 33アクセス・コントロール・リスト . . . . . . . . . . . . . . . . . 33デフォルトの管理 ACL ポリシー . . . . . . . . . . . . . . . . . 34管理許可 . . . . . . . . . . . . . . . . . . . . . . . . . . 35疎 ACL モデル . . . . . . . . . . . . . . . . . . . . . . . . 42保護オブジェクト・ポリシー . . . . . . . . . . . . . . . . . . . 47

第 4 章 Web Portal Manager の使用 . . . . . . . . . . . . . . . . 49Web Portal Manager の始動 . . . . . . . . . . . . . . . . . . . . 49

Web Portal Manager 管理機能の始動 . . . . . . . . . . . . . . . . 50Web Portal Manager 管理の代行機能の始動 . . . . . . . . . . . . . 50

ヘルプの表示. . . . . . . . . . . . . . . . . . . . . . . . . . 50ログインとサインオフ . . . . . . . . . . . . . . . . . . . . . . 51インターフェースの個人情報設定 . . . . . . . . . . . . . . . . . . 51Web Portal Manager を使用した管理の代行 . . . . . . . . . . . . . . 52管理役割のタイプ . . . . . . . . . . . . . . . . . . . . . . . 54役割管理の代行 . . . . . . . . . . . . . . . . . . . . . . . . 55

セルフケアのインプリメント . . . . . . . . . . . . . . . . . . . . 56自己登録のインプリメント. . . . . . . . . . . . . . . . . . . . . 57自己登録のサンプル . . . . . . . . . . . . . . . . . . . . . . 57自己登録サンプルのプロセス . . . . . . . . . . . . . . . . . . . 57自己登録サンプルの Java Server Pages . . . . . . . . . . . . . . . 58自己登録サンプルへのアクセス . . . . . . . . . . . . . . . . . . 59

第 5 章オブジェクト・スペース管理 . . . . . . . . . . . . . . . . 61オブジェクト・スペースの作成 . . . . . . . . . . . . . . . . . . . 61

Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 61pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

オブジェクト・スペースのリスト . . . . . . . . . . . . . . . . . . 62Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 62pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

オブジェクト・スペースの削除 . . . . . . . . . . . . . . . . . . . 63Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 63pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

iv IBM Tivoli Access Manager: Base 管理者ガイド

第 6 章ユーザーとグループの管理 . . . . . . . . . . . . . . . . . 65ユーザーの追加 . . . . . . . . . . . . . . . . . . . . . . . . . 65

Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 65pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 66ユーザーのインポート . . . . . . . . . . . . . . . . . . . . . 66

グループの追加 . . . . . . . . . . . . . . . . . . . . . . . . . 67Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 67pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 67グループのインポート . . . . . . . . . . . . . . . . . . . . . 67

第 7 章保護オブジェクトの管理 . . . . . . . . . . . . . . . . . . 69オブジェクトの作成 . . . . . . . . . . . . . . . . . . . . . . . 69

Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 69pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

オブジェクトのリスト . . . . . . . . . . . . . . . . . . . . . . 70Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 70pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

オブジェクトの削除 . . . . . . . . . . . . . . . . . . . . . . . 71Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 71pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

第 8 章アクセス・コントロール・リストの管理 . . . . . . . . . . . . 73ACL ポリシー . . . . . . . . . . . . . . . . . . . . . . . . . 73ACL エントリーの構文 . . . . . . . . . . . . . . . . . . . . . . 74タイプ属性 . . . . . . . . . . . . . . . . . . . . . . . . . 74ID 属性 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75許可 (アクション) 属性 . . . . . . . . . . . . . . . . . . . . . 76デフォルトの Tivoli Access Manager 許可 (アクション) . . . . . . . . . 76

アクセス・コントロール・リストの管理. . . . . . . . . . . . . . . . 77ACL の作成 . . . . . . . . . . . . . . . . . . . . . . . . . 77ACL のリスト . . . . . . . . . . . . . . . . . . . . . . . . 78ACL の削除 . . . . . . . . . . . . . . . . . . . . . . . . . 78ACL の変更と表示 . . . . . . . . . . . . . . . . . . . . . . 79保護オブジェクト・タイプへの ACL 属性の適用 . . . . . . . . . . . 79

ACL エントリーの例 . . . . . . . . . . . . . . . . . . . . . . . 81ACL ポリシーおよび保護オブジェクト・スペース . . . . . . . . . . . . 81ルート ( / ) コンテナー・オブジェクト . . . . . . . . . . . . . . . 81全探索許可 . . . . . . . . . . . . . . . . . . . . . . . . . 82

オブジェクトおよびオブジェクト・スペース許可 . . . . . . . . . . . . 82アクション・グループの管理 . . . . . . . . . . . . . . . . . . . . 83アクション・グループ . . . . . . . . . . . . . . . . . . . . . 83新しいアクション・グループの作成 . . . . . . . . . . . . . . . . 84アクション・グループのリスト . . . . . . . . . . . . . . . . . . 85アクション・グループの削除 . . . . . . . . . . . . . . . . . . . 85カスタム・アクションの要件 . . . . . . . . . . . . . . . . . . . 86アクション・グループでの新しいアクションの作成 . . . . . . . . . . 86ACL エントリーへのカスタム・アクションの入力 . . . . . . . . . . . 87カスタム・アクションの例. . . . . . . . . . . . . . . . . . . . 88

第 9 章保護オブジェクト・ポリシーの管理 . . . . . . . . . . . . . . 91保護オブジェクト・ポリシーの管理 . . . . . . . . . . . . . . . . . 92

POP の作成 . . . . . . . . . . . . . . . . . . . . . . . . . 92

目次 v

POP のリスト . . . . . . . . . . . . . . . . . . . . . . . . 93POP の削除 . . . . . . . . . . . . . . . . . . . . . . . . . 94POP の変更と表示 . . . . . . . . . . . . . . . . . . . . . . . 94POP 属性の保護オブジェクトへの適用 . . . . . . . . . . . . . . . 95

POP 属性の構成 . . . . . . . . . . . . . . . . . . . . . . . . 97警告モード属性 . . . . . . . . . . . . . . . . . . . . . . . . 97監査レベル属性 . . . . . . . . . . . . . . . . . . . . . . . . 97時刻属性 . . . . . . . . . . . . . . . . . . . . . . . . . . 98

認証強度 POP ポリシー (ステップアップ) . . . . . . . . . . . . . . . 99ステップアップ認証のレベルの構成 . . . . . . . . . . . . . . . . 99ステップアップ認証ポリシーの適用 . . . . . . . . . . . . . . . . 100ステップアップ認証と多元的認証の区別 . . . . . . . . . . . . . . 100

保護品質 POP ポリシー . . . . . . . . . . . . . . . . . . . . . 101ネットワーク・ベースの認証 POP ポリシー . . . . . . . . . . . . . . 102

IP アドレスおよび範囲の指定 . . . . . . . . . . . . . . . . . . 102IP アドレスによるステップアップ認証の使用不可 . . . . . . . . . . 103ネットワーク・ベースの認証アルゴリズム . . . . . . . . . . . . . 103ネットワーク・ベースの認証の注意と制限 . . . . . . . . . . . . . 103

第 10 章 Tivoli Access Manager 証明書およびパスワード管理 . . . . . 105初期構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . 106鍵リング・データベース・ファイルおよび stash ファイルの更新情報 . . . . 106信頼性の判別 . . . . . . . . . . . . . . . . . . . . . . . . . 107証明書の失効 . . . . . . . . . . . . . . . . . . . . . . . . . 108その他の考慮事項 . . . . . . . . . . . . . . . . . . . . . . . 108

第 11 章サーバー管理 . . . . . . . . . . . . . . . . . . . . . 111Tivoli Access Manager サーバー . . . . . . . . . . . . . . . . . . 111サーバー構成ファイル . . . . . . . . . . . . . . . . . . . . . 112サーバーの依存関係 . . . . . . . . . . . . . . . . . . . . . . 112

Tivoli Access Manager ユーティリティー . . . . . . . . . . . . . . . 112Tivoli Access Manager サーバーの始動および停止. . . . . . . . . . . . 113

UNIX システムでのサーバーの始動および停止 . . . . . . . . . . . . 113Windows システムでのサーバーの始動および停止. . . . . . . . . . . 114

ブート時のサーバー始動の自動化 . . . . . . . . . . . . . . . . . . 115ポリシー・サーバー . . . . . . . . . . . . . . . . . . . . . . 115許可サーバー . . . . . . . . . . . . . . . . . . . . . . . . 115

ポリシー・サーバー管理 . . . . . . . . . . . . . . . . . . . . . 116許可データベースの複製 . . . . . . . . . . . . . . . . . . . . 116更新通知スレッド数の設定 . . . . . . . . . . . . . . . . . . . 117通知遅延時間の設定 . . . . . . . . . . . . . . . . . . . . . . 118

第 12 章高可用性 . . . . . . . . . . . . . . . . . . . . . . . 119データの保全性 . . . . . . . . . . . . . . . . . . . . . . . . 119複数サーバー . . . . . . . . . . . . . . . . . . . . . . . . . 119許可サーバー . . . . . . . . . . . . . . . . . . . . . . . . 119

第 13 章代行管理 . . . . . . . . . . . . . . . . . . . . . . . 121オブジェクト・スペース管理の代行 . . . . . . . . . . . . . . . . . 121管理代行用オブジェクト・スペースの構造化 . . . . . . . . . . . . 121デフォルトの管理ユーザーおよびグループ . . . . . . . . . . . . . 122例: 管理代行 . . . . . . . . . . . . . . . . . . . . . . . . 122

グループ管理の代行 . . . . . . . . . . . . . . . . . . . . . . . 123

vi IBM Tivoli Access Manager: Base 管理者ガイド

グループ・コンテナー・オブジェクトの作成 . . . . . . . . . . . . 124グループの作成 . . . . . . . . . . . . . . . . . . . . . . . 125グループ管理に影響する ACL ポリシー . . . . . . . . . . . . . . 127ユーザー管理に影響する ACL ポリシー . . . . . . . . . . . . . . 128

代行管理ポリシーの管理 . . . . . . . . . . . . . . . . . . . . . 129

第 14 章ロギングと監査 . . . . . . . . . . . . . . . . . . . . 133サーバー・アクティビティーのロギングと監査 . . . . . . . . . . . . . 133サーバーのロギングと監査の概要 . . . . . . . . . . . . . . . . . 133Base 保守サービス・メッセージのロギング . . . . . . . . . . . . . 135Tivoli Access Manager監査証跡ファイル・パラメーター . . . . . . . . 137監査証跡ファイル・フォーマット . . . . . . . . . . . . . . . . . 139監査証跡ファイルの内容 . . . . . . . . . . . . . . . . . . . . 141

イベント・ロギング . . . . . . . . . . . . . . . . . . . . . . . 150イベント・ログの使用 . . . . . . . . . . . . . . . . . . . . . 151コンソールのロギング . . . . . . . . . . . . . . . . . . . . . 154ファイルのロギング . . . . . . . . . . . . . . . . . . . . . . 155パイプ・ロギング . . . . . . . . . . . . . . . . . . . . . . 159リモート・ロギング . . . . . . . . . . . . . . . . . . . . . . 159イベント・カテゴリーの位置決め . . . . . . . . . . . . . . . . . 162ログ・キュー・パフォーマンスのモニター . . . . . . . . . . . . . 162

付録 A. サーバー構成ファイルの解説 . . . . . . . . . . . . . . . . 165構成ファイル . . . . . . . . . . . . . . . . . . . . . . . . . 165

activedir.conf. . . . . . . . . . . . . . . . . . . . . . . . . 166domino.conf . . . . . . . . . . . . . . . . . . . . . . . . . 167ivacld.conf . . . . . . . . . . . . . . . . . . . . . . . . . 168ivmgrd.conf . . . . . . . . . . . . . . . . . . . . . . . . . 169ldap.conf . . . . . . . . . . . . . . . . . . . . . . . . . . 170pd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

ユーザー定義構成ファイル . . . . . . . . . . . . . . . . . . . . 172スタンザ構成のガイドライン . . . . . . . . . . . . . . . . . . . 173一般ガイドライン . . . . . . . . . . . . . . . . . . . . . . 173デフォルト値 . . . . . . . . . . . . . . . . . . . . . . . . 173ストリング . . . . . . . . . . . . . . . . . . . . . . . . . 174定義済みストリング . . . . . . . . . . . . . . . . . . . . . . 174ファイル名 . . . . . . . . . . . . . . . . . . . . . . . . . 174整数 . . . . . . . . . . . . . . . . . . . . . . . . . . . 175ブール値 . . . . . . . . . . . . . . . . . . . . . . . . . . 175

変更構成設定 . . . . . . . . . . . . . . . . . . . . . . . . . 176スタンザ . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

[authentication-mechanisms] スタンザ . . . . . . . . . . . . . . . . 178[aznapi-admin-services] スタンザ . . . . . . . . . . . . . . . . . 180[aznapi-configuration] スタンザ . . . . . . . . . . . . . . . . . . 182[aznapi-cred-modification-services] スタンザ . . . . . . . . . . . . . 187[aznapi-entitlement-services] stanza . . . . . . . . . . . . . . . . . 189[aznapi-external-authzn-services] スタンザ . . . . . . . . . . . . . . 191[aznapi-pac-services] スタンザ . . . . . . . . . . . . . . . . . . 193[delegated-admin] スタンザ . . . . . . . . . . . . . . . . . . . 195[ivacld] スタンザ . . . . . . . . . . . . . . . . . . . . . . . 196[ivmgrd] スタンザ . . . . . . . . . . . . . . . . . . . . . . 199[ldap] スタンザ . . . . . . . . . . . . . . . . . . . . . . . 203

目次 vii

[ldap-ext-cred-tags] スタンザ . . . . . . . . . . . . . . . . . . . 213[manager] スタンザ . . . . . . . . . . . . . . . . . . . . . . 214[pdrte] スタンザ . . . . . . . . . . . . . . . . . . . . . . . 215[ssl] スタンザ . . . . . . . . . . . . . . . . . . . . . . . . 218[uraf-ad] スタンザ . . . . . . . . . . . . . . . . . . . . . . 224[uraf-domino] スタンザ . . . . . . . . . . . . . . . . . . . . . 227

付録 B. ユーザー・レジストリーの相違点 . . . . . . . . . . . . . . 231

付録 C. 特記事項 . . . . . . . . . . . . . . . . . . . . . . . 237商標 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

用語集 . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

viii IBM Tivoli Access Manager: Base 管理者ガイド

本書について

IBM Tivoli Access Manager Base 管理者ガイドは、IBM Tivoli Access Manager

(Tivoli Access Manager) のサーバーおよびリソースを管理するための、手順および参照情報の広範囲なセットを提供します。また、Tivoli Access Manager の広範囲な機能に関する、重要なバックグラウンド情報と概念情報も記載しています。

本書の対象読者本書は、基本 Tivoli Access Manager ソフトウェアの配備および管理を担当するシステム管理者を対象としています。

読者は、以下の点に精通している必要があります。

v Microsoft® Windows® および UNIX® オペレーティング・システム

v データベースのアーキテクチャーおよび概念

v セキュリティー管理

v HTTP、TCP/IP、ファイル転送プロトコル (FTP)、および Telnet を含むインターネット・プロトコル(IP)

v Lightweight Directory Access Protocol (LDAP) およびディレクトリー・サービス

v 認証および許可

v Access Manager のセキュリティー・モデルとその機能

Secure Sockets Layer (SSL) 通信を使用可能にする場合は、SSL プロトコル、鍵交換(公開鍵と秘密鍵)、ディジタル・シグニチャー、暗号アルゴリズム、および認証局についての知識も必要です。

本書の内容本書には、以下のセクションが含まれています。

v 1ページの『第 1 章 IBM Tivoli Access Manager の概要』

IBM Tivoli Access Manager の概要を示します。

v 23ページの『第 2 章 Tivoli Access Manager の管理』

Tivoli Access Manager の管理について説明します。

v 31ページの『第 3 章デフォルトのセキュリティー・ポリシー』

Tivoli Access Manager で提供されているデフォルトのセキュリティー・ポリシーについて説明します。

v 61ページの『第 5 章オブジェクト・スペース管理』

オブジェクト・スペースの管理に伴うタスクについて説明します。

v 65ページの『第 6 章ユーザーとグループの管理』

ユーザーおよびグループの管理に伴うタスクについて説明します。

v 69ページの『第 7 章保護オブジェクトの管理』

オブジェクトの管理に伴うタスクについて説明します。

v 73ページの『第 8 章アクセス・コントロール・リストの管理』

© Copyright IBM Corp. 1999, 2003 ix

アクセス・コントロール・リスト (ACL) の管理に伴うタスクについて説明します。

v 91ページの『第 9 章保護オブジェクト・ポリシーの管理』

保護オブジェクト・ポリシー (POP) の管理に伴うタスクについて説明します。

v 105ページの『第 10 章 Tivoli Access Manager 証明書およびパスワード管理』

証明書およびパスワードの管理に伴うタスクについて説明します。

v 111ページの『第 11 章サーバー管理』

Tivoli Access Manager に関連付けられているサーバーの管理に伴うタスクについて説明します。

v 119ページの『第 12 章高可用性』

ポリシー・プロキシー・サーバー、複数のポリシー・サーバー、複数の許可サーバーなどを使用して、高可用性環境を整えるのに伴うタスクについて説明します。

v 121ページの『第 13 章代行管理』

管理の代行に伴うタスクについて説明します。

v 133ページの『第 14 章ロギングと監査』

ロギングと監査の管理に伴うタスクについて説明します。

v 165ページの『付録 A. サーバー構成ファイルの解説』

Tivoli Access Manager サーバーが使用する構成ファイルの構文に関する詳細情報を提供します。

v 231ページの『付録 B. ユーザー・レジストリーの相違点』

Tivoli Access Manager のこのバージョンで、ユーザー・レジストリーの相違点の存在が知られているものについて文書化しています。

資料Tivoli Access Manager ライブラリーは、以下のカテゴリーで編成されています。

v 『リリース情報』

v xiページの『基本情報』

v xiページの『WebSEAL 情報』

v xiページの『Web セキュリティー情報』

v xiiページの『開発者用解説書』

v xiiページの『技術補足』

リリース情報v IBM Tivoli Access Manager 最初にお読みください

GI88-8618-00 (am41_readme.pdf)

Tivoli Access Manager を使用する際のインストールおよび入門について説明しています。

v IBM Tivoli Access Manager リリース情報SC88-9520-00 (am41_relnotes.pdf)

x IBM Tivoli Access Manager: Base 管理者ガイド

ソフトウェアの制約事項、対応策、および文書更新などの最新緊急情報を記載しています。

基本情報v IBM Tivoli Access Manager Base インストール・ガイド

SC32-1131-01 (am41_install.pdf)

Web Portal Manager インターフェースを含む、Tivoli Access Manager ソフトウェアのインストール、構成、およびアップグレードの方法を説明しています。

v IBM Tivoli Access Manager Base 管理者ガイドSC32-1132-01 (am41_admin.pdf)

Tivoli Access Manager サービスの使用に関する概念と手順を説明しています。Web Portal Manager インターフェースから、ならびに pdadmin コマンドを使用してタスクを実行するための説明を記載しています。

WebSEAL 情報v IBM Tivoli Access Manager WebSEAL インストール・ガイド

SC32-1133-01 (amweb41_install.pdf)

WebSEAL サーバーおよび WebSEAL アプリケーション開発キットのインストール、構成、および除去について説明しています。

v IBM Tivoli Access Manager WebSEAL 管理者ガイドSC32-1134-01 (amweb41_admin.pdf)

WebSEAL を使用して、ご使用のセキュア Web ドメインのリソースを管理する際のバックグラウンド資料、管理手順、ならびにテクニカル・リファレンス情報を記載しています。

Web セキュリティー情報v IBM Tivoli Access Manager for WebSphere Application Server ユーザーズ・ガイド

SC32-1136-01 (amwas41_user.pdf)

Tivoli Access Manager for IBM WebSphere® Application Server のインストール、除去、および管理について説明しています。

v IBM Tivoli Access Manager for WebLogic Server ユーザーズ・ガイドSC32-1137-01 (amwls41_user.pdf)

Tivoli Access Manager for BEA WebLogic Server のインストール、除去、および管理について説明しています。

v IBM Tivoli Access Manager Plug-in for Edge Server ユーザーズ・ガイドSC32-1138-01 (amedge41_user.pdf)

WebSphere Edge Server アプリケーション用プラグインのインストール、構成、および管理方法について説明しています。

v IBM Tivoli Access Manager Plug-in for Web Servers ユーザーズ・ガイドSC32-1139-01 (amws41_user.pdf)

Web サーバー用プラグインを使用して Webドメインを保護する際の、インストールの説明、管理手順、およびテクニカル・リファレンス情報を記載しています。

本書について xi

開発者用解説書v IBM Tivoli Access Manager Authorization C API デベロッパーズ・リファレンス

SC32-1140-01 (am41_authC_devref.pdf)

Tivoli Access Manager 許可 C API および Access Manager サービス・プラグイン・インターフェースを使用して Tivoli Access Manager セキュリティーをアプリケーションに追加する方法を説明した参照情報を記載しています。

v IBM Tivoli Access Manager Authorization Java Classes デベロッパーズ・リファレンスSC32-1141-01 (am41_authJ_devref.pdf)

Tivoli Access Manager セキュリティーを使用するアプリケーションを使用可能にする際の許可 API の Java™ 言語インプリメンテーションの使用に関する参照情報を記載しています。

v IBM Tivoli Access Manager Administration C API デベロッパーズ・リファレンスSC32-1142-01 (am41_adminC_devref.pdf)

Tivoli Access Manager 管理タスクを実行するアプリケーションを使用可能にする際の、管理 API の使用に関する参照情報を記載しています。この資料では、管理API の C インプリメンテーションについて説明しています。

v IBM Tivoli Access Manager Administration Java Classes デベロッパーズ・リファレンスSC32-1143-01 (am41_adminJ_devref.pdf)

Tivoli Access Manager 管理タスクを実行するためのアプリケーションを使用可能にする際の許可 API の Java 言語インプリメンテーションの使用に関する参照情報を記載しています。

v IBM Tivoli Access Manager WebSEAL デベロッパーズ・リファレンスSC32-1135-01 (amweb41_devref.pdf)

クロスドメイン認証サービス (CDAS)、クロスドメイン・マッピング・フレームワーク (CDMF)、およびパスワード・ストレングス・モジュールの管理およびプログラミング情報を記載しています。

技術補足v IBM Tivoli Access Manager コマンド・リファレンス

GC32-1107-01 (am41_cmdref.pdf)

Tivoli Access Manager に付属のコマンド行ユーティリティーおよびスクリプトに関する情報を記載しています。

v IBM Tivoli Access Manager エラー・メッセージ・リファレンスSC32-1144-01 (am41_error_ref.pdf)

Tivoli Access Manager が作成するメッセージに関する説明および推奨処置を記載しています。

v IBM Tivoli Access Manager 問題判別ガイドGC32-1106-01 (am41_pdg.pdf)

Tivoli Access Manager の問題判別情報を記載しています。

v IBM Tivoli Access Manager パフォーマンス・チューニング・ガイドSC32-1145-01 (am41_perftune.pdf)

xii IBM Tivoli Access Manager: Base 管理者ガイド

ユーザー・レジストリーとして定義された IBM Directory Server を伴う Tivoli

Access Manager から構成される環境の、パフォーマンス・チューニング情報を記載しています。

関連資料このセクションでは、Tivoli Access Manager ライブラリーに関連する資料をリストアップします。

Tivoli Software Library は、白書、データ・シート、デモンストレーション、レッドブック、発表レターなど、さまざまな Tivoli 資料を提供します。 Tivoli Software

Library は、次のサイトで利用できます。http://www.ibm.com/software/tivoli/library/

Tivoli Software Glossary では、Tivoli ソフトウェアに関連する多数の技術用語の定義を記載しています。Tivoli Software Glossary (英語のみ) は、Tivoli Software

Library Web ページ (http://www.ibm.com/software/tivoli/library/) の左側にあるGlossary リンクから入手できます。

IBM Global Security ToolkitTivoli Access Manager では、IBM Global Security Toolkit (GSKit) を使用したデータ暗号化が行われます。 GSKit は、特定プラットフォームの IBM Tivoli Access

Manager Base CD に入っています。

GSKit パッケージは、iKeyman 鍵管理ユーティリティーの gsk5ikm をインストールします。これを使用すると、鍵データベース、公開鍵と秘密鍵のペア、および証明書要求を作成することができます。 Tivoli Information Center の Web サイトのIBM Tivoli Access Manager 製品資料と同じセクションでは、以下の資料を入手することができます。

v Secure Sockets Layer Introduction and iKeyman User’s Guide

(gskikm5c.pdf)

ネットワークやシステムのセキュリティー管理者が、Tivoli Access Manager 環境で SSL 通信を使用可能にするよう計画している場合に利用できる情報が記載されています。

IBM DB2 Universal DatabaseIBM DB2® Universal Database™ は、IBM Directory Server、z/OS™、およびOS/390® LDAP サーバーをインストールする際は必須です。 DB2 は、次のオペレーティング・システム・プラットフォーム用の製品 CD に入っています。

v IBM AIX®

v Microsoft™ Windows™

v Sun Solaris オペレーティング環境

DB2 情報は、以下のサイトで入手できます。

http://www.ibm.com/software/data/db2/

本書について xiii

http://www.ibm.com/software/tivoli/library/


http://www.ibm.com/software/data/db2/

IBM Directory ServerIBM Directory Server、バージョン 4.1 は、Linux for zSeries™ 以外のすべてのオペレーティング・システムの IBM Tivoli Access Manager Base CD に入っています。Linux for S/390 用の IBM Directory Server ソフトウェアは、以下のサイトで入手できます。

http://www.ibm.com/software/network/directory/server/download/

IBM Directory Server をユーザー・レジストリーとして使用する計画の場合は、以下のサイトの情報を参照してください。

http://www.ibm.com/software/network/directory/library/

IBM WebSphere Application ServerIBM WebSphere Application Server アドバンスド・シングル・サーバー 4.0.3 は、Web Portal Manager CD に入っていて、Web Portal Manager インターフェースによってインストールされます。 IBM WebSphere Application Server については、以下のサイトを参照してください。

http://www.ibm.com/software/webservers/appserv/infocenter.html

IBM Tivoli Access Manager for Business IntegrationIBM Tivoli Access Manager for Business Integration は個別に注文できる製品として入手可能で、IBM MQSeries®、バージョン 5.2、および IBM WebSphere® MQ、バージョン 5.3 メッセージ用のセキュリティー・ソリューションを提供します。 IBM

Tivoli Access Manager for Business Integration を使用すると、送受信アプリケーションに関連付けられたキーを使用することによって、WebSphere MQSeries アプリケーションはプライバシーおよび保全性を保持した状態でデータを送信することができます。 WebSEAL および IBM Tivoli Access Manager for Operating Systems と同様に、IBM Tivoli Access Manager for Business Integration は、IBM Tivoli Access

Manager for e-business の許可サービスを使用する一種のリソース・マネージャーです。

IBM Tivoli Access Manager for Business Integration バージョン 4.1 に関連する以下の資料は、Tivoli Information Center の Web サイトで入手できます。

v IBM Tivoli Access Manager for Business Integration 管理者ガイド (SC88-9495-00)

v IBM Tivoli Access Manager for Business Integration リリース情報 (GI88-8614-00)

v IBM Tivoli Access Manager for Business Integration 最初にお読みください(GI88-8615-00)

IBM Tivoli Access Manager for Operating SystemsIBM Tivoli Access Manager for Operating Systems は、個別に注文できる製品として入手可能であり、ネイティブ・オペレーティング・システムが提供するレイヤーに加えて、UNIX システムで許可ポリシーを実施するためのレイヤーを提供します。WebSEAL および IBM Tivoli Access Manager for Business Integration と同様に、IBM Tivoli Access Manager for Operating Systems は、IBM Tivoli Access Manager

for e-business の許可サービスを使用する一種のリソース・マネージャーです。

xiv IBM Tivoli Access Manager: Base 管理者ガイド

http://www.ibm.com/software/network/directory/server/download/

http://www.ibm.com/software/network/directory/library/

http://www.ibm.com/software/webservers/appserv/infocenter.html

IBM Tivoli Access Manager for Operating Systems バージョン 4.1 に関連した以下の資料が Tivoli Information Center の Web サイトから入手できます。

v IBM Tivoli Access Manager for Operating Systems インストール・ガイド(SC88-9494-00)

v IBM Tivoli Access Manager for Operating Systems 管理者ガイド (SC88-9492-00)

v IBM Tivoli Access Manager for Operating Systems 問題判別ガイド (SC88-9493-00)

v IBM Tivoli Access Manager for Operating Systems リリース情報 (GI88-8613-00)

v IBM Tivoli Access Manager for Operating Systems 最初にお読みください(GI88-8611-00)

オンラインでの資料へのアクセス本製品に関連する資料は、PDF または HTML 形式、もしくは両方の形式で、以下の Tivoli Software Library でオンラインで入手できます。http://www.ibm.com/software/tivoli/library

製品資料をライブラリー内で見付けるには、Library ページの左側にある Productmanuals リンクをクリックしてください。次に、Tivoli Software Information Center

ページで、製品名を見付けてクリックしてください。

製品資料には、リリース情報、インストール・ガイド、ユーザーズ・ガイド、管理者ガイド、およびデベロッパーズ・リファレンスがあります。

注: PDF 資料を適切に印刷するために、Adobe Acrobat 印刷ダイアログ (「ファイル (File)」→「印刷 (Print)」をクリックすると、使用可能になる) で「用紙サイズに合わせる (Fit to page)」チェック・ボックスを選択してください。

アクセシビリティーアクセシビリティー機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるようにサポートします。この製品では、支援機能を使用して、聞いたり、インターフェースをナビゲートしたりできます。また、マウスの代わりにキーボードを使用して、グラフィカル・ユーザー・インターフェースのすべての機能を操作することもできます。

ソフトウェア・サポートへの問い合わせ問題について IBM Tivoli Software サポートに問い合わせる前に、以下の IBM

Tivoli Software サポートの Web サイトを参照してください。http://www.ibm.com/jp/software/support/

http://www.ibm.com/software/sysmgmt/products/support/

さらにヘルプが必要な場合は、以下のサイトの IBM Software Support Guide で説明されている方法でソフトウェア・サポートに問い合わせてください。http://techsupport.services.ibm.com/guides/handbook.html

このガイドでは、以下の情報を提供しています。

v サポートを受けるための登録および有資格の条件

v 所在地により、電話番号および電子メール・アドレス

本書について xv


http://www.ibm.com/jp/software/support/

http://www.ibm.com/software/sysmgmt/products/support/

http://techsupport.services.ibm.com/guides/handbook.html

v お客様サポートに問い合わせる前に収集する必要のある情報のリスト

本書で使用する規則本書では、特殊用語、アクション、オペレーティング・システム依存のコマンドおよびパスに関して、いくつかの規則を使用しています。

書体の規則次の情報を表すのに、以下のような書体の規則が適用されています。

太字周囲のテキスト、キーワード、パラメーター、オプション、Java クラス名、オブジェクトと区別するのが困難な小文字コマンドまたは大文字小文字混合コマンドは、太字で表示されます。

イタリック変数、資料のタイトル、および強調される特殊な用語または句もイタリックで表示されます。

モノスペースコード例、コマンド行、画面出力、周囲のテキストとの区別が困難なファイルおよびディレクトリー名、システム・メッセージ、ユーザーが入力する必要のあるテキスト、引数またはコマンド・オプションの値は、モノスペースで表示されます。

オペレーティング・システムの相違点本書は、環境変数およびディレクトリー表記を指定するために UNIX 規則を使用しています。Windows コマンド行を使用する場合、環境変数として $variable を%variable% に置換し、ディレクトリー・パスでスラッシュ (/) をバックスラッシュ(\) に置換してください。Windows システム上で bash シェルを使用している場合は、UNIX 規則を使用できます。

xvi IBM Tivoli Access Manager: Base 管理者ガイド

第 1 章 IBM Tivoli Access Manager の概要

IBM Tivoli Access Manager (Tivoli Access Manager) は、企業向けの Web、クライアント/サーバー、および既存のアプリケーション向けの認証および許可ソリューションです。Tivoli Access Manager によって、保護情報やリソースへのユーザーのアクセスを制御できます。集中化された、柔軟で拡張が容易なアクセス・コントロール・ソリューションを備えることによって、Tivoli Access Manager を用いて、安全で、管理しやすいネットワーク・ベースのアプリケーションおよび e-business インフラストラクチャーを構築できます。

Tivoli Access Manager は、認証、許可、データ・セキュリティー、およびリソース管理機能をサポートします。Tivoli Access Manager を、標準のインターネット・ベースのアプリケーションと一緒に使用することで、高度に安全で、管理の行き届いたイントラネットを構築できます。

Tivoli Access Manager は、以下の機能を提供します。

認証フレームワークTivoli Access Manager は、幅広い組み込み認証子を備え、外部をサポートします。

許可フレームワークTivoli Access Manager 許可サービスは、標準の許可 API を介してアクセスされ、ネイティブ Tivoli Access Manager サーバーおよびその他のアプリケーションへのアクセス要求に対する認否の決定を行います。

許可サービスは、リソース・マネージャーと一緒になって、ビジネス・ネットワーク・システムに標準許可メカニズムを提供します。

Tivoli Access Manager は、既存のレガシーおよび新生インフラストラクチャーに組み込まれ、安全な集中ポリシー管理機能を提供します。

既存のリソース・マネージャーには、次のようなものがあります。

IBM Tivoli Access Manager WebSEALWeb ベースの情報およびリソースを管理および保護します。WebSEAL

は、Tivoli Access Manager に組み込まれています。

IBM Tivoli Access Manager for Business IntegrationIBM MQSeries および IBM WebSphere MQ メッセージのためのセキュリティー・ソリューションを提供します。

IBM Tivoli Access Manager for Operating Systemsネイティブ・オペレーティング・システムが提供するレイヤーに加えて、UNIX システムで許可ポリシー制約のレイヤーを提供します。

既存のアプリケーションは、Tivoli Access Manager 許可サービスを活用できるだけでなく、エンタープライズ全体に対して共通セキュリティー・ポリシーを提供できます。

© Copyright IBM Corp. 1999, 2003 1

コア・テクノロジーTivoli Access Manager ネットワーク・セキュリティー管理ソリューションは、次のコア・テクノロジーを提供し、サポートします。

v 認証

v 許可

v 保護品質

v スケーラビリティー

v 追跡機能

v 集中管理

認証認証は、Tivoli Access Manager によって保護されたリソースの要求を行うときに、ユーザーが取るべき最初のステップです。認証の間、ユーザーの ID が検証されます。認証プロセスは、通常、サービスを提供するアプリケーションの特定の要件によって異なります。 Tivoli Access Manager を使用すると、許可 API を使用した認証へのアプローチが高度に柔軟になります。

Tivoli Access Manager は、許可 API を介してユーザー名およびパスワード認証を行う、組み込みサポートを備えています。アプリケーションは、許可 API を使用する任意のカスタム認証メカニズムを構築できます。

許可許可は、ユーザーがアクセスできるオブジェクト、およびユーザーがこれらのオブジェクトに対して実行できるアクションを決定し、ユーザーに適切なアクセスを付与することにより、セキュリティー・ポリシーを適用します。Tivoli Access

Manager は、以下を使用することによって許可を処理します。

v Tivoli Access Manager 許可サービス

v きめ細かいアクセス・コントロールのためのアクセス・コントロール・リスト(ACL) および保護オブジェクト・ポリシー (POP)

v C 言語アプリケーションに aznAPI、Java 言語アプリケーションに Java

Authentication and Authorization Service (JAAS) を使用する、標準ベースの許可API

v 外部許可サービス機能

保護品質保護品質とは、Tivoli Access Manager が、クライアントとサーバーの間で伝送される情報を保護する度合いのことです。データ保護の品質は、暗号化規格および変更検出アルゴリズムの組み合わせ効果によって決まります。リソース・マネージャーは、データ保護の品質が適用されていることを確認する役割を担います。

保護品質には、以下のレベルがあります。

v 標準伝送制御プロトコル (TCP) 通信 (保護なし)

v データ保全性 - ネットワーク通信の間にメッセージ (データ・ストリーム) が変更されないようにします。

2 IBM Tivoli Access Manager: Base 管理者ガイド

v データ・プライバシー - メッセージがネットワーク通信中に変更または検査されないようにします。

Tivoli Access Manager は、Secure Sockets Layer (SSL) 通信プロトコルが提供するデータ保全性とデータ・プライバシーをサポートします。サポートされている暗号を解く鍵には、次のものがあります。

v 40 ビット RC2

v 128 ビット RC2

v 40 ビット RC4

v 128 ビット RC4

v 40-Data Encryption Standard (DES)

v 56 ビット DES

v 168 ビット Triple DES

スケーラビリティースケーラビリティーは、ドメインのリソースにアクセスするユーザー数の増加に対応できる能力のことです。 Tivoli Access Manager は、次の技法を使ってスケーラビリティーを提供します。

v サービスの複製

– 認証サービス

– 許可サービス

– セキュリティー・ポリシー

– データ暗号化サービス

– 監査サービス

v フロントエンドの複製サーバー

– 高可用性のためにミラーリングされたリソース

– クライアント要求のロード・バランシング

v バックエンドの複製サーバー

– バックエンド・サーバーは、Tivoli Access Manager WebSEAL、Tivoli Access

Manager for Operating Systems、Tivoli Access Manager for Business

Integration、またはその他のアプリケーション・サーバーのいずれでも使用できます。

– 高可用性のためにミラーリングされたリソース (統合されたオブジェクト・スペース)

– 追加のコンテンツおよびリソース

– 着信要求のロード・バランシング

v 認証および許可サービスを別個のサーバーにオフロードできるようにすることによるパフォーマンスの最適化

v 管理のオーバーヘッドを増加させない、サービスのスケール配置

第 1 章 IBM Tivoli Access Manager の概要 3

追跡機能Tivoli Access Manager には、いくつかのロギングおよび監査機能があります。ログ・ファイルは、Tivoli Access Manager サーバーが生成するエラーおよび警告メッセージを取り込みます。監査証跡ファイルは、Tivoli Access Manager サーバーのアクティビティーをモニターします。

集中管理セキュリティー・ポリシーおよび Tivoli Access Manager サーバーを管理するために、次の 3 つの方法が提供されています。

v pdadmin コマンド行ユーティリティー

v Web Portal Manager グラフィカル・ユーザー・インターフェース (GUI)

v 管理 API

上記の方法を用いて、ほとんどのタスクを達成することができます。ただし、一部のタスクには Web ポータル・マネージャー (WPM) を使用して実行できないものもあります。

pdadmin コマンド行ユーティリティーpdadmin コマンド行ユーティリティーは、Tivoli Access Manager の管理に使用されます。このユーティリティーは、ユーザー、グループ、役割、許可、ポリシー、ドメイン、サーバーを管理したり、その他のタスクを実行するためのコマンド行インターフェースを提供します。コマンドをスクリプトまたはバッチ・ファイルで使用して、処理を自動化できます。

pdadmin コマンド行ユーティリティーは、Tivoli Access Manager ランタイム・パッケージの一環としてインストールされています。

特定のタスクについては、本書のタスク別の章を参照してください。 pdadmin コマンド自体の詳細な構文情報については、「IBM Tivoli Access Manager コマンド・リファレンス」を参照してください。

Web ポータル・マネージャー (WPM)Web ポータル・マネージャー (WPM) は、Tivoli Access Manager 管理に使用される、オプションの Web ベースのグラフィカル・ユーザー・インターフェース(GUI) です。Web ポータル・マネージャー (WPM) は、ユーザー、グループ、役割、許可、ポリシー、ドメイン、サーバーを管理したり、その他のタスクを実行するための GUI インターフェースを提供します。

Web ポータル・マネージャー (WPM) は、AIX、Solaris、および Microsoft Windows

オペレーティング・システム上でのみ利用可能です。このオプションの GUI は、Tivoli Access Manager Web ポータル・マネージャー (WPM) CD を使用して、お使いのプラットフォームに個別にインストールする必要があります。Web ポータル・マネージャー (WPM) を使用する重要な利点は、これらのタスクをリモート側で、サポートされた Web ブラウザーを使用して、特殊なネットワーク構成なしに行えることです。

特定のタスクについては、本書のタスク別の章を参照してください。Web ポータル・マネージャー (WPM) の使用法について詳しくは、Web ポータル・マネージャー (WPM) オンライン・ヘルプを参照してください。


管理 APITivoli Access Manager の管理 API コンポーネントは、アプリケーションを書き込んで、ユーザー、グループ、ルール、許可、ポリシー、ドメイン、およびサーバーを管理することのできる、一連のプログラミング・インターフェースを提供します。これらの機能は、C 言語および Java 言語のバージョンが利用可能です。

管理 API について詳しくは、「IBM Tivoli Access Manager Administration C API

デベロッパーズ・リファレンス」および「IBM Tivoli Access Manager Administration

Java Classes デベロッパーズ・リファレンス」を参照してください。

セキュリティー・ポリシーの概要いかなるセキュリティー・ポリシーの目的も、最小限の管理努力によってビジネス資産およびリソースを適切に保護することにあります。まず、保護する必要のあるリソースを明確にします。これらは、ファイル、ディレクトリー、ネットワーク・サーバー、メッセージ、データベース、またはWeb ページなど、あらゆるタイプのデータ・オブジェクトである可能性があります。次に、これらの保護されるリソースにアクセスできるユーザーおよびユーザー・グループを決定する必要があります。また、これらのリソースに対して許可されるアクセスのタイプも決定します。最後に、これらのリソースに対して、正当なユーザーのみがアクセスできるように、適切なセキュリティー・ポリシーを適用する必要があります。

セキュリティー・ポリシーの制約は、リソース・マネージャーのジョブです。リソース・マネージャーは、要求元のユーザーの信任状、要求されたアクセスのタイプ、およびアクセスされるオブジェクトを使用して、Tivoli Access Manager 許可サービスを呼び出します。許可サービスは、許可エンジンとしても知られていますが、セキュリティー・ポリシーを使用して、要求が許可されるべきか、拒否されるべきか、またはリソース・マネージャーによる追加検証の結果が出るまで条件付きで許可されるかを決定します。リソース・マネージャーは、許可サービスの勧告に従い、さらなる検証アクションを実行し、最終的に要求を拒否、または要求の処理を許可します。

たとえば、Todd が、IBM Tivoli Access Manager WebSEAL により保護されているWeb サイトにある、特定の Web ページにアクセスしたいとします。 WebSEAL

は、Web ベースの情報およびリソースの管理および保護を担うリソース・マネージャーであり、Todd がそのページにアクセスできるかどうかを決定する必要があります。リソース・マネージャーは Todd の信任状を取得し、許可サービスに Todd がその Web ページに対する読み取りアクセスを持っているか照会します。許可サービスは、セキュリティー・ポリシーを検査し、Todd はアクセスを許可されるべきであると判断し、リソース・マネージャーに要求は許可されるべきであると勧告します。次に、リソース・マネージャーは Todd の要求を、その Web ページを提供する適切なバックエンド Web サーバーに送信します。

Tivoli Access Manager のセキュリティー・ポリシーは、アクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー (POP) を使用して定義されます。


許可 API 標準許可サービスは、アプリケーションのセキュリティー・アーキテクチャーの重要な部分です。ユーザーが認証プロセスを通過した後で、許可サービスは、そのユーザーがアクセスできるサービスと情報を決定することによってビジネス・ポリシーを実施します。

たとえば、Web ベースの退職金基金にアクセスするユーザーは、個人のアカウント情報を表示できます。その情報を表示する前に、許可サーバーは、そのユーザーのID、信任状、および特権属性を検査する必要があります。

標準ベースの許可 API (aznAPI) によって、アプリケーションは集中許可サービスを呼び出すことができるので、開発者は、新しいアプリケーションごとに許可コードを作成する必要がなくなります。

許可 API により、ビジネスにおいて、すべてのアプリケーションをトラステッド許可フレームワーク上で標準化することができます。許可 API を使用すれば、ビジネスはそのネットワーク上のリソースへのアクセスをさらに制御することができます。

許可: 概念モデルサーバーがドメインでセキュリティーを強制するときは、各クライアントはその ID

の証明を提示しなければなりません。それに対し、セキュリティー・ポリシーは、そのクライアントが要求されたリソースで操作を実行する許可を持つかどうかを判別します。ドメイン内の各リソースへのアクセスをサーバーが制御する場合、認証と許可を求めるサーバーの要求により、包括的なネットワーク・セキュリティーが実現されます。

セキュリティー・システムでは、許可 (authorization) は認証 (authentication) と区別されます。許可は、認証されたクライアントがドメイン内の特定のリソースに対して操作を実行する権利を有するかどうかを判断します。認証により、個人の本人確認は行われますが、保護リソースを操作する権利に関しては何も保証していません。

Tivoli Access Manager 許可モデルでは、許可ポリシーは、ユーザー認証に使用されるメカニズムに関係なくインプリメントされます。ユーザーは、公開 / 秘密鍵、機密鍵、またはユーザー定義のメカニズムを使って、ユーザーの ID を認証できます。

認証プロセスの一環で、クライアントの ID を記述する信任状の作成を伴います。許可サービスによって行われる認証の判断は、ユーザー信任状に基づいています。

ドメイン内のリソースは、そのドメイン内のセキュリティー・ポリシーによって指示されたレベルの保護を受けます。セキュリティー・ポリシーは、ドメインの正当な参加者を定義します。また、保護を必要とするそれぞれのリソースを取り巻く保護の程度を定義します。

7ページの図 1 に示す許可プロセスの基本コンポーネントを、以下に示します。


v 許可が付与されるときに、要求された操作のインプリメントを担当するリソース・マネージャー

リソース・マネージャーの 1 つのコンポーネントはポリシー・エンフォーサーであり、これは、要求を、処理を行うために許可サービスに送信します。

v 要求に対して意思決定アクションを行う許可サービス。

従来のアプリケーションでは、ポリシー・エンフォーサーとリソース・マネージャーを 1 つのプロセスにまとめていました。この構造の例には、Tivoli Access

Manager WebSEAL、Tivoli Access Manager for Operating Systems、および Tivoli

Access Manager for Business Integration が組み込まれています。

これらの許可コンポーネントはそれぞれ独立して機能するため、セキュリティー制約戦略の設計における柔軟性が向上します。

たとえば、この独立性により、セキュリティー管理者は次のものを制御できるようになります。

v プロセスが配置される場所

v プロセス用のコードを作成する担当者

v プロセスがタスクを実行する方法

標準許可サービスの利点ほとんどのシステム (既存、新規の両方のシステム) における許可は、個々のアプリケーションと密結合されています。各会社では、通常、時間をかけて、ビジネス・ニーズに対応するアプリケーションを作成します。これらのアプリケーションの多くは、それぞれ特定の形式の許可を必要とします。

結果として、多くの場合、許可インプリメンテーションがそれぞれに異なっている、多種多様なアプリケーションが作成されることになります。これらの所有許可インプリメンテーションでは、別個の管理を必要とし、統合が難しく、結果として所有コストが高くなります。

図 1. 一般許可モデル


分散許可サービスは、これらの独立アプリケーションに標準の許可決定メカニズムを提供します。標準許可サービスの利点には、次のものが含まれます。

v アプリケーションの開発コストおよび、そのアプリケーションへのアクセスの管理コストを削減する。

v 個別の許可システムを所有/管理するための合計コストを削減する。

v 既存のセキュリティー・インフラストラクチャーを活用する。

v 新しいビジネスをより安全にオープンできるようになる。

v さらに新しい、さまざまな種類のアプリケーションを使用可能にする。

v さらに開発サイクルを短くする。

v 情報を安全に共用する。

Tivoli Access Manager 許可サービスの概要Tivoli Access Manager は、既存のレガシーおよび新生インフラストラクチャーに組み込まれ、安全な集中ポリシー管理機能を提供します。 Tivoli Access Manager 許可サービスは、図 2 に示されるように、リソース・マネージャーとともに、ビジネス・ネットワーク・システムに標準許可メカニズムを提供します。

既存のアプリケーションは、許可サービスを活用できます。許可ポリシーは、ユーザーまたはグループ役割に基づいており、ネットワーク・サーバー、個々のトランザクションまたはデータベース要求、特定の Web ベースの情報、管理アクティビティー、およびユーザー定義のオブジェクトに適用できます。

許可 API により、既存のアプリケーションは許可サービスを呼び出し、次にその許可サービスが企業向けのセキュリティー・ポリシーに基づいて決定を行うことができます。許可 API の詳細については 14ページの『Tivoli Access Manager 許可API』を参照してください。

Tivoli Access Manager 許可サービスは、拡張することも可能で、外部許可サービスのプラグイン・インターフェースを使用した追加処理のためのその他の許可サービスを呼び出すように構成できます。

図 2. Tivoli Access Manager サーバー・コンポーネント


許可サービスには、次の利点があります。

v 許可サービスはアプリケーションに左右されない。

v 許可サービスは、言語に左右されない標準許可コード・スタイル (許可 API) を使用する。

v 許可サービスは中央管理され、したがって、管理しやすく、たとえば、新しい従業員を追加する場合、複数のシステム全体ではなく 1 つの中央設置場所にある特権データベースを変更するだけで済む。

v 許可サービスは、異種プラットフォーム間環境におけるセキュリティー・サービスのアプリケーションに対応している。

v 許可サービスは、外部許可サービス機能を介して、既存の非 Tivoli Access

Manager 許可システムを統合する。

v 許可サービスは、既存のインフラストラクチャーと簡単に統合できる、拡張が容易で柔軟性の高いアーキテクチャーを持つ。

v 許可サービスは、複数レイヤーの許可を可能にする。信任状パケットは、アプリケーション・プロセスまたはトランザクションの複数のレイヤーを経て移動することができます。

v 許可サービスは、共通かつ有効な監査モデルを使用している。

v 許可サービスは、すべての認証メカニズムからも独立している。

Tivoli Access Manager 許可サービスTivoli Access Manager 許可サービスは、ネットワーク・セキュリティー・ポリシーの実施に役立つ許可決定プロセスに責任を負っています。許可サービスが行う許可の決定によって、ドメインの保護リソースで操作を実行するクライアントの要求が承認または拒否されます。

コンポーネント許可サービスは、次の 3 つの基本コンポーネントから成り立っています。

v マスター許可ポリシー・データベース

v ポリシー・サーバー

v 許可決定評価機能

ポリシー・データベースポリシー・データベースは、マスター許可ポリシー・データベースおよびマスター許可データベースとも呼ばれ、ドメイン内のすべてのリソースに関するセキュリティー・ポリシー情報が含まれています。各ドメインには、独自のポリシー・データベースがあります。このデータベースの内容は、Web Portal Manager、pdadmin コマンド行ユーティリティー、および管理 API を使用して取り扱われます。

ポリシー・サーバーポリシー・サーバー (pdmgrd) は、ポリシー・データベースを保持し、ドメイン全体でこのポリシー情報を複製し、マスターに変更が加えられるときはいつでもデータベース・レプリカを更新します。


ポリシー・サーバーは、ドメインで稼働している他の Tivoli Access Manager および非 Tivoli Access Manager サーバーに関するロケーション情報も保持しています。

許可評価機能許可評価機能は、保護リソースにアクセスするクライアントの能力を、セキュリティー・ポリシーに基づいて決定する許可決定プロセスのことです。この評価機能は、リソース・マネージャーに対して勧告を行い、リソース・マネージャーはそれに従って応答します。

レジストリー・データベースの複製パラメーターは、評価機能ごとに定義します。

図 3 は、許可サービスの主なコンポーネントの説明図です。

許可サービス・インターフェース許可サービスには、対話が行われる以下の 2 つのインターフェースがあります。

v 管理インターフェース — セキュリティー管理者は、ドメイン内のリソースにポリシー・ルールを適用するために、Web Portal Manager、または pdadmin コマンド行ユーティリティーを使用して、セキュリティー・ポリシーを管理します。セキュリティー・ポリシーは、ポリシー・データベースでポリシー・サーバーにより管理されています。

このインターフェースは複雑であり、オブジェクト・スペース、ポリシー、信任状に関する詳しい情報が含まれています。

v 許可 API — 許可 API は、許可決定の要求をリソース・マネージャーから許可エバリュエーターに受け渡し、次に許可評価機能が要求を許可する、または拒否するという勧告を戻します。

図 3. 許可サービスのコンポーネント


スケーラビリティーとパフォーマンスの複製許可サービス・コンポーネントを複製して、要求量の多い環境での可用性を増すことができます。

マスター許可ポリシー・データベース (ポリシー・ルールおよび信任状情報を含む)

は、自動的に複製を行うように構成できます。許可サービスを呼び出すアプリケーションには、このデータベース情報を参照するためのオプションが 2 つあります。

v このアプリケーションは、許可評価機能とシームレスに働くように構成されている場合、データベースのローカル・キャッシュを使用します。

データベースの複製は、ローカル・キャッシュ・モードで許可サービスを使用するアプリケーションごとに行われます。

v このアプリケーションは、リモート許可サーバー・コンポーネントによってキャッシュに入れられる共用レプリカを使用します。

データベースは、許可サーバーのインスタンスごとに複製されます。 1 つの許可サーバーに、多数のアプリケーションがアクセスできます。

図 4 に示されるように、ポリシー・サーバーから更新が通知されると (マスター許可ポリシー・データベースに変更が加えられた場合はいつでも)、キャッシング・プロセスが起動して、すべてのレプリカを更新します。

パフォーマンス情報v アプリケーション・サーバーは、ポリシー・サーバーからの直接の通知更新に加え、数分ごとにマスター許可ポリシー・データベースのバージョンも検査して、更新通知を見逃していないか確認するよう構成できます。これはポーリングとして知られており、デフォルトでは使用可能化されていません。

更新通知がサーバーに到達できなかった場合、ログ・エントリーを作成します。どちらの場合も、再試行メカニズムが、後で必ず更新が行われるようにします。

図 4. 複製された許可サービス・コンポーネント


v 許可ポリシー情報がキャッシュに入れられることで、システム・パフォーマンスが向上します。たとえば、WebSEAL は、許可検査を行うとき、それ自身のキャッシュ・バージョンのデータベースのポリシーを検査します。 WebSEAL は、マスター・データベースからこの情報を入手するためにネットワークにアクセスする必要はありません。この結果、許可検査の応答時間 (パフォーマンス) が非常に速くなります。

v 個々の許可結果は、呼び出しアプリケーション・サーバーによってキャッシュに入れられることはありません。

ネットワーク・セキュリティー・ポリシーのインプリメントドメイン用のセキュリティー・ポリシーは、ドメイン内のユーザーおよびグループ参加を制御して、保護を必要とするリソースにルールを適用することによって決定されます。これらのルールは、アクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー (POP) の使用により定義されます。許可サービスは、ユーザーの信任状を、要求されたリソースに割り当てられたポリシーの許可と突き合わせることによって、これらのポリシーを実施します。結果として出された勧告をリソース・マネージャーに渡し、リソース・マネージャーが元の要求への応答を完了させます。

セキュリティー・ポリシーの定義および適用リソースを保護するには、セキュリティー・ポリシーを定義します。このセキュリティー・ポリシーは、アクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー (POP) を定義し、これらのポリシーをオブジェクト・スペース内のリソースのオブジェクト表現に適用することによって作成されます。同一オブジェクトに、ACL と POP の両方を適用できます。このポリシーを定義するために、pdadmin コマンド行ユーティリティー、Web ポータル・マネージャー (WPM)

GUI、および管理 API が使用されます。

許可サービスは、これらのオブジェクトに適用されるポリシーに基づいて許可決定を行います。保護オブジェクトで要求された操作を実行することを認めると、そのリソースに関する責任を負っているアプリケーションがこの操作をインプリメントします。

1 つのポリシーが、多数のオブジェクトの保護パラメーターを指示できます。このルールに変更があった場合、そのポリシーが付加されているすべてのオブジェクトに影響します。

明示的および継承されたポリシーセキュリティー・ポリシーは、明示的に適用することも継承することもできます。Tivoli Access Manager の保護オブジェクト・スペースは、ACL および POP の継承をサポートしています。このことは、オブジェクト・スペースを管理するセキュリティー管理者にとって重要な考慮事項になります。 13ページの図 5 に示されているように、管理者は、ルールの変更が必要な階層の場所においてのみ、明示的にポリシーを適用する必要があります。


ポリシー・タイプの例として、次のものが挙げられます。

v ハード・コーディング・ルール

v 外部許可機能

v 特殊セキュア・ラベル

v アクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー(POP)

アクセス・コントロール・リストアクセス・コントロール・リスト (ACL) ポリシー、または ACL ポリシーは、特定のユーザーまたはグループがそのリソースで特定の操作を行うために必要な条件を指定する、アクション、コントロール、許可の集合です。ACL ポリシー定義は、ドメイン用に設定されたセキュリティー・ポリシーの重要なコンポーネントです。

ACL ポリシーは具体的に、リソースで実行できる操作、およびそれらの操作を実行できるユーザーを定義します。ACL ポリシーは、ユーザーとグループの指定、およびそれらの特定の許可または権限のいずれかを含む、1 つ以上のエントリーから構成されます。

保護オブジェクト・ポリシー保護オブジェクト・ポリシー (POP) は、アクセスが許可されるために満たす必要のある追加条件を含みます。アクションを試みるユーザーまたはグループに依存するACL とは異なり、POP はすべてのユーザーおよびグループに影響します。また、POP は要求が監査されるべきかどうかを指示します。POP 条件を適用することはTivoli Access Manager およびリソース・マネージャーの役割です。

許可プロセス: 段階的14ページの図 6 は、許可プロセスの詳細説明図です。

図 5. 明示的および継承されたポリシー


1. リソースに関する認証済みクライアント要求を、リソース・マネージャー・サーバーに送信したり、ポリシー・エンフォーサー・プロセスによって代行受信します。リソース・マネージャーは、WebSEAL for Hypertext Transfer Protocol

(HTTP)、HTTPS アクセス、またはその他のアプリケーションのいずれでも構いません。

2. ポリシー・エンフォーサー・プロセスは許可 API を使用して、許可の決定を行うために許可サービスを呼び出します。許可 API の詳細については『Tivoli

Access Manager 許可 API』を参照してください。

3. 許可サービスは、リソースで許可検査を実行します。使用されるアルゴリズムについて詳しくは、26 ページを参照してください。

4. 要求を受け入れるか拒否するかの決定が、リソース・マネージャーへの勧告 (ポリシー・エンフォーサーを使用) として戻されます。

5. 最終的に要求が承認されると、リソース・マネージャーはその要求を該当のリソース担当のアプリケーションに渡します。

6. クライアントは、要求された操作の結果を受け取ります。

Tivoli Access Manager 許可 APITivoli Access Manager アプリケーション・プログラム・インターフェース (API) を使用すると、Tivoli Access Manager アプリケーションおよびその他のアプリケーションは、許可サービスを照会し、許可の決定を下すことができます。

許可 API は、リソース・マネージャー (許可検査を要求する) と許可サービスそれ自体の間のインターフェースです。許可 API によって、ポリシー実施アプリケーションは許可の決定を求めることができますが、アプリケーションは実際の許可決定プロセスの複雑さから守られます。

図 6. Tivoli Access Manager 許可プロセス


許可 API には、許可要求と決定をコーディングするための標準のプログラミング・モデルがあります。許可 API では、任意のレガシー・アプリケーション、または新しく開発されたアプリケーションから、集中管理許可サービスに、標準化された呼び出しを行うことができます。

許可 API は、次の 2 つのモードのうちのいずれかで使用できます。

v リモート・キャッシュ・モード

このモードでは、API の初期化を、(リモート) 許可サーバー (pdacld) を呼び出して、アプリケーションに代わって許可決定を下すように行います。許可サーバーは、レプリカ許可ポリシー・データベースの、それ自体のキャッシュを保持します。このモードは、アプリケーション・クライアントからの許可要求を処理するのに最適です。

リモート・キャッシュ・モードの詳細については 16ページの『許可 API: リモート・キャッシュ・モード』を参照してください。

v ローカル・キャッシュ・モード

このモードの場合、アプリケーションの許可データベースのローカル・レプリカをダウンロードし、保持するように API を初期化します。ローカル・キャッシュ・モードでは、アプリケーションがすべての許可決定をネットワークを介さずに、ローカルで実行するため、パフォーマンスの点で優れています。しかし、データベースの複製のオーバーヘッドと、このモードを使用する場合のセキュリティー上の意味を考慮すると、このモードは、トラステッド・アプリケーション・サーバーによる使用のほうが最適になります。

ローカル・キャッシュ・モードの詳細については 17ページの『許可 API: ローカル・キャッシュ・モード』を参照してください。

許可 API の主な価値と利点の 1 つとして、許可サービス・メカニズム自体の複雑さからユーザーを守るという機能があります。管理、保管、キャッシング、複製、信任状フォーマット、および認証方式の問題は、すべて許可 API の背後に隠されます。

許可 API も、その基礎となるセキュリティー・インフラストラクチャー、証明書フォーマット、および評価メカニズムから独立して機能します。許可 API は、許可検査を要求して、その返答として簡単な「yes」または「no」の勧告を受け取ることを可能にします。許可検査メカニズムの詳細はユーザーからは見えません。

許可 API の使用: 2 つの例アプリケーションは、許可 API を使用して、極めて限定された特殊プロセスでアクセス・コントロールを行うことができます。

例 1:タスク・ボタンを許可検査の結果に応じてアクティブまたは非アクティブとして動的に表示する、グラフィカル・ユーザー・インターフェース (GUI) を設計できます。

例 2:許可 API のもう一つの用法は 16ページの図 7 に示されており、Web アプリケーションによる共通ゲートウェイ・インターフェース (CGI) トランザクションの要求を図示しています。


図 7 の図 A に示されているように、最低レベルの許可では、Uniform Resource

Locator (URL) について「絶対的な」アクセス・コントロールを伴います。このおおまかなレベルの許可では、クライアントが CGI プログラムが実行できるかどうかだけが決定されます。 CGI アプリケーションへのアクセスを認めると、CGI アプリケーションが操作するリソースに対してそれ以上の制御はできません。

図 7 の図 B の説明では、CGI プログラムが操作するリソースにアクセス・コントロールが設定されています。 Web アプリケーションは、許可 API を使用するように構成されています。ここで、CGI プログラムは許可サービスを呼び出し、それが操作するリソースに許可決定を下すことができます (要求元クライアントの ID に基づいて)。

許可 API: リモート・キャッシュ・モードリモート・キャッシュ・モードの場合、アプリケーションは、許可 API が提供する関数呼び出しを使用して、(リモート) 許可サーバー (pdacld) と通信します。許可サーバーは、許可決定評価機能として機能し、それ自体のレプリカ許可ポリシー・データベースを保持します。

許可サーバーは、決定を行い、API を介してアプリケーションに勧告を戻します。許可サーバーは、許可決定要求の詳細を含む監査レコードの書き込みもします。

17ページの図 8 に示されているように、リモート・キャッシュ・モードを使用している場合、ドメイン内のいずれかで、許可サーバーが実行している必要があります。許可サーバーは、アプリケーションと同じマシン上にあっても、別のマシン上にあっても構いません。また、ドメイン内の複数のマシンに許可サーバーをインス

図 7. 許可 API の使用例


トールして、可用性を高めることもできます。許可 API は、特定の許可サーバーが失敗しても、透過的にフェイルオーバーを実行します。

許可 API: ローカル・キャッシュ・モードローカル・キャッシュ・モードでは、API は、許可ポリシー・データベースのレプリカをアプリケーションのローカル・ファイル・システムにダウンロードして保持します。このモードの API は、すべての許可決定をメモリー内で行うため、パフォーマンスと信頼性が増します。

ローカル・レプリカは、そのアプリケーションの呼び出し間では、持続性を保ちます。 API がレプリカ・モードで開始すると、ローカル・レプリカの作成後に発生したマスター許可ポリシー・データベースへの更新を検査します。

図 8. 許可 API: リモート・キャッシュ・モード


外部許可機能状況によって、標準の Tivoli Access Manager ポリシー・インプリメンテーション(ACL および POP) で、組織のセキュリティー・ポリシーが必要とする条件をすべて表せない場合があります。 Tivoli Access Manager は、追加の許可要件に対応するオプションの外部許可機能を備えています。

外部許可サービスを使用すると、個別の外部許可サービス・モジュールによって指示される、追加の許可制御と条件を設けることができます。

許可サービスの拡張外部許可機能は、自動的に Tivoli Access Manager 許可サービスに構築されます。外部許可サービスを構成すると、Tivoli Access Manager 許可サービスは、アクセス決定パスをその評価プロセスに単に取り込むだけです。

許可サービスを使用するアプリケーション (たとえば、WebSEAL、および許可 API

を使用するすべてのアプリケーション) は、構成された外部許可サービスの追加 (ただしシームレスの) の恩恵を受けます。外部許可サービスの使用によるセキュリティー・ポリシーへの追加は、それらのアプリケーションには透過的で、アプリケーションの変更は必要ありません。

外部許可サービス・アーキテクチャーを使用すると、組織の既存のセキュリティー・サービスを完全統合できます。外部許可サービスは、レガシー・サーバーをTivoli Access Manager 許可決定プロセスに組み込めるようにして、セキュリティー・メカニズムへの会社の初期投資を保持します。

図 9. 許可 API: ローカル・キャッシュ・モード


リソース要求の条件の制定アクセスの試みが成功か失敗かによって、より具体的な条件か、あるいはシステム固有の副次作用を課すのに、外部許可サービスを使用することができます。

このような条件の例としては、次のようなものがあります。

v 外部監査メカニズムに、アクセスの試みが成功か失敗かを記録させる。

v アクセスの試みをアクティブにモニターし、受諾不能な動作が検出されたときは常に、アラートまたはアラームが出るようにする。

v 請求または小額決済トランザクションを処理する。

v 保護リソースへアクセス割り当て量を設ける。

許可評価プロセス外部許可サーバーを組み込む許可決定は、次の方法で行われます。

1. アクセス決定の間にトリガー条件が満たされた場合、その条件で構成されている外部許可サービスがそれぞれ順番に呼び出され、その独自の外部許可制約を評価します。

外部許可サービスの呼び出しは、Tivoli Access Manager 許可サービスがそのユーザーに対して必要な許可を認めているかどうかに関係なく行われます。

2. 外部許可サービスごとに、許可、拒否、または不干渉の決定を戻します。

「不干渉」が戻された場合、外部許可サービスの決定は、決定プロセスにその機能が必要ではなく、それに参加しないということになります。

3. 外部許可サービスの決定は、そのプロセスでその決定がもたらす重要度のレベルに従って加重されます。

それぞれの外部許可サービスの重みは、サーバー・プラグインのロード時に構成されます。

4. すべての許可決定の結果は、合計され、Tivoli Access Manager 許可サービスによって行われた決定と組み合わされます。その結果の決定が呼び出し元に戻されます。

例20ページの図 10 は、アプリケーション・サーバーと外部許可サービスが関係する許可決定の説明図です。


この例で、外部許可サービスの目的は、写真品質プリンター・リソースにアクセスできる頻度で、割り当て制限を課すということです。

サービス・インプリメンテーションは、 1 週間で 1 人がこのプリンターに対して行えるジョブ実行依頼の数に制限を課します。外部許可サービスのトリガー条件がこの写真プリンター・リソースに付加されているため、写真プリンターにアクセスされると、常に外部許可サービスが呼び出されます。

外部許可サービスは、デフォルトの決定加重の 101 でロードされています。この加重により、その必要があれば、Tivoli Access Manager 許可サービスによって行われた決定を指定変更します。

1. アプリケーション・サーバーは、オンラインの写真印刷リソースへのアクセスを求めるクライアントから要求を受け取ります。そのクライアントは、該当するグループ GraphicArtists のメンバーであるため、通常そのプリンターへのジョブの実行依頼は許可されます。

2. アプリケーション・サーバーはまず Tivoli Access Manager 許可サービスを調べて、要求元ユーザーにそのプリンターへジョブを実行依頼する許可があるかどうかを判別します。

3. 許可サービスは、ターゲットの要求先オブジェクトに対するアクセス許可を検査し、それを要求元ユーザーの機能と比較します。

group GraphicArtists rx

そのプリンター・リソースに関する ACL で、「x」許可で GraphicArtists グループ内のすべてのユーザーにそのリソースへのアクセスが付与されます。したがって、許可サービスはそのユーザーにジョブを実行依頼する許可を付与します。

図 10. 外部許可サービスとアプリケーション・サーバー


4. 写真プリンター・リソースがアクセスされていて、外部許可サービスのトリガー条件がこのオブジェクトに付与されていたため、そのトリガー条件で構成されている外部許可サービスへの要求も行われます。

外部許可サービスは、アプリケーション・サーバーによる元のアクセス決定検査で渡されたアクセス決定情報 (ADI) をすべて受け取ります。

5. 外部許可サービスは、このユーザーが行ったそれまでのアクセスの記録を調べます。要求元ユーザーが週の割り当てを超えていなければ、「不干渉」のアクセス決定を戻します。

これは、アクセス拒否の条件が満たされていないため、外部許可サービスはその要求に対して不干渉であり、アクセス決定に参加する意図がないことを示しています。

しかし、ユーザーが割り当てを超えると、外部許可サービスは「アクセス拒否」の決定を戻します。

この例では、要求側が割り当てを超えており、外部許可サービスがそれを検出して、「アクセス拒否」の決定を戻したことを想定しています。

6. Tivoli Access Manager 許可サービスは、外部許可サービスから「アクセス拒否」の結果を受信します。次にこの決定を選び、デフォルトの外部許可サービスの加重値である 101 で加重します。

外部許可サービス決定の結果と、Tivoli Access Manager 許可サービスが行った決定が組み合わされます。外部許可サービスの結果 (-101) が Tivoli Access

Manager 許可サービスの結果 (100) を上回っているため、結果は「アクセス拒否」になります。

7. アプリケーション・サーバーは、写真プリンター・リソースへのジョブ実行依頼を拒否します。

8. アプリケーション・サーバーは、ジョブが拒否されたことを示す応答を呼び出し元に戻します。

外部許可サービスのインプリメント外部許可サービスをセットアップするには、以下の 2 つの一般的なステップが必要です。

1. 許可決定の際に参照できる許可インターフェースを用いて、外部許可サービスのプラグイン・モジュールを作成する。

2. 外部許可サービスを Tivoli Access Manager に登録し、Tivoli Access Manager 許可クライアントが初期化の際にプラグイン・サービスをロードできるようにする。

サービスを登録すると、外部許可サービスの呼び出しのトリガー条件が設定されます。許可検査の際にトリガー条件が検出されると、外部許可サービス・インターフェースが呼び出されて、追加の許可決定が行われます。

デプロイメント計画Tivoli Access Manager を使用すると、外部許可サービスを次のいくつかの方法でインプリメントできます。

v さまざまな許可評価を実行するために、ドメインに外部許可サービスをいくつでも追加できます。各外部許可サービスが、個々のローカル・モード許可 API クラ


イアント・アプリケーションにロードされます。外部許可サービスをロードできるアプリケーションには、許可サーバー (PDAcld)、他の Tivoli Access Manager

サーバー、およびお客様によって作成されたすべての許可アプリケーションが含まれます。

v 許可サーバーに許可決定を要求する、リモート・モード許可 API クライアントは、許可サーバーによってロードされた外部許可サービスを自動的に使用します。

v 1 つのトリガー条件で複数の外部許可サービスを呼び出せます。この場合、外部許可サービスの結果は、その結果に応じて重み付けされ、その結果が Tivoli

Access Manager 許可サービスの結果と組み合わされます。

v POP トリガーを使用して、オブジェクトにトリガー条件を定めることができます。したがって、オブジェクトを要求すると、要求される操作に関係なく、そのトリガーで構成されている外部許可サービスへの呼び出しが起動されます。

v トリガー条件は、ユーザーが要求する操作にも定めることができます。たとえば、ユーザーが保護リソースへの書き込み操作を要求しても、他の操作は要求しない場合には、外部許可サービスを起動することができます。したがって、操作のセットを開発し、それに対して、要求された操作のセットに従って 1 つ以上の外部許可サービスを組み合わせて起動させるようにすることが可能です。

v 外部許可サービスは、ダイナミック・ロード可能ライブラリー (ダイナミック・リンク・ライブラリー (DLL)) モジュールとしてインプリメントされます。これにより、外部許可サービスの開発が大幅に単純化されます。外部許可サービスへのリモート要求を行う必要がなく、呼び出しを行うオーバーヘッドは関数呼び出しのオーバーヘッドと等しくなります。

v 許可 API と外部許可サービスを組み合わせると、複雑なセキュリティー・ポリシーをインプリメントするための拡張性と柔軟性の高いソリューションが提供されます。


第 2 章 Tivoli Access Manager の管理

Tivoli Access Manager の管理には、次の主要なタスクがあります。

1. ドメインを作成する (必要な場合)。

2. オブジェクト・スペースを作成する。

3. オブジェクト・スペースで、保護されるリソースを表す保護オブジェクトを定義する。

4. 保護リソースへのアクセスを必要とするユーザーおよびグループを定義する。

5. 保護オブジェクトについて、以下を定義できます。

v アクセスを許可されるユーザー。

v 許可されるアクセスのタイプ。

v アクセスが許可される時期。

v アクセスを許可されるために満たす必要のある、その他の条件。

v アクセス要求が監査されるかどうか。

6. アクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー(POP) を保護オブジェクト・スペース内のオブジェクトに付加することにより、セキュリティー・ポリシーをインプリメントする。

ドメインドメインは、保護する必要のあるすべてのリソース、およびこれらのリソースを保護するために使用される関連セキュリティー・ポリシーで構成されています。これらのリソースは、いかなる物理または論理エンティティー (ファイル、ディレクトリー、Web ページ、プリンターおよびネットワーク・サービス、およびメッセージ・キューなどのオブジェクト) でも構いません。ドメイン内にインプリメントされたセキュリティー・ポリシーはすべて、そのドメイン内のオブジェクトにのみ影響します。

中小規模エンタープライズでは通常、1 つのドメインで十分です。Tivoli Access

Manager は、初期構成の一環として、管理ドメインと呼ばれる、Default というドメインを自動的に作成します。このドメインは、Tivoli Access Manager がセキュリティー・ポリシーを管理するのに使用され、その他の保護リソースを管理するためにも利用できます。

保護オブジェクト・スペースTivoli Access Manager は、保護オブジェクト・スペースと呼ばれる仮想表現を使用して、ドメイン内のリソースを表現します。保護オブジェクト・スペースは、ドメインに所属するリソースの論理的かつ階層的描画です。

保護オブジェクト・スペースは、次の 2 つのタイプのオブジェクトにより構成されています。

リソース・オブジェクトリソース・オブジェクトは、ドメイン内のファイル、サービス、Web ページ、メッセージ・キューなど、実際の物理的リソースの論理表現です。


コンテナー・オブジェクトコンテナー・オブジェクトは、リソース・オブジェクトを別々の機能領域に階層的にグループ化できる構造コンポーネントです。

セキュリティー・ポリシーは、両方のタイプのオブジェクトに適用できます。図 11

は、複数のコンテナー・オブジェクトとリソース・オブジェクトを含む、1 つの保護オブジェクト・スペースの論理表現を示しています。

保護オブジェクト・スペースの構造上の先頭にあるのは、ルート・コンテナー・オブジェクトで、スラッシュ (/) 文字で表示されています。ルート・コンテナー・オブジェクトの下にあるのは、1 つ以上のコンテナー・オブジェクトです。各コンテナー・オブジェクトは、関連する一連のリソースで構成されているオブジェクト・スペースを表現しています。これらのリソースは、リソース・オブジェクト、またはその他のコンテナー・オブジェクトです。

Tivoli Access Manager は、Tivoli Access Manager 自体の管理に使用されるオブジェクトにより構成されている、/Management というオブジェクト・スペースを作成します。関連する一連のリソースを保護する各アプリケーションは、独自のオブジェクト・スペースを作成します。たとえば、 WebSEAL コンポーネントは、Web ベースの情報とリソースを保護しますが、/WebSEAL というオブジェクト・スペースを作成します。このようなコンパニオン・アプリケーションは、ブレードと呼ばれます。 25ページの図 12 は、保護オブジェクト・スペース内の /Management オブジェクト・スペースを示しています。

図 11. Tivoli Access Manager 保護オブジェクト・スペース


ユーザーおよびグループTivoli Access Manager は、ユーザー・レジストリー内の Tivoli Access Manager ユーザーおよびグループに関する情報を保守します。ユーザー・レジストリーに既に存在するユーザーおよびグループは、Tivoli Access Manager にインポートできます。ユーザーまたはグループがユーザー・レジストリーに存在しない場合は、直接Tivoli Access Manager の中で作成できます。

ドメインが作成される際、ドメイン管理者として知られる特殊なユーザーが作成されます。管理ドメインには、Tivoli Access Manager ポリシー・サーバーを構成する間に、ドメイン管理者のユーザー ID (sec_master) およびパスワードが設定されます。ドメイン管理者は、ドメインに対するほぼ完全なコントロールを持っています。Tivoli Access Manager のドメイン管理者について、UNIX の root アカウント、または Microsoft Windows の Administrator ユーザーに相当すると考えてください。

ドメイン管理者は、ドメイン内の Tivoli Access Manager iv-admin グループのメンバーとして追加されます。iv-admin グループは、ドメイン管理特権を持つユーザーを表しています。このグループにユーザーを追加する際は、ドメインのセキュリティーの信頼を損ねないよう注意が必要です。

ユーザーが Tivoli Access Manager に認証された場合、ユーザー信任状が戻されます。この信任状は、別の Tivoli Access Manager 機能により、要求元のユーザーを一意的に識別するために使用されます。

図 12. Tivoli Access Manager 保護オブジェクト・スペースの領域

第 2 章 Tivoli Access Manager の管理 25

セキュリティー・ポリシードメイン内のオブジェクトへのアクセスは、セキュリティー・ポリシーを保護オブジェクト・スペース内のコンテナー・オブジェクトおよびリソース・オブジェクトに適用することによりコントロールされます。セキュリティー・ポリシーは、オブジェクトに明示的に適用されるか、階層の上方にあるオブジェクトから継承されます。ルールを変更する必要がある階層の場所でのみ、保護オブジェクト・スペースの明示的セキュリティー・ポリシーを適用する必要があります。

セキュリティー・ポリシーは、以下の組み合わせを使用することによって定義されます。

v アクセス・コントロール・リスト (ACL)

アクセス・コントロール・リスト、または ACL は、一連のユーザーおよびグループがオブジェクトに対して実行できる、一連の事前定義アクションを指定します。たとえば、特定の一連のグループまたはユーザーは、オブジェクトに対する読み取りアクセスを付与されます。

v 保護オブジェクト・ポリシー (POP)

保護オブジェクト・ポリシー、または POP は、すべてのユーザーおよびグループに影響するオブジェクトに関連するアクセス条件を指定します。たとえば、特定の時間にすべてのユーザーおよびグループをオブジェクトに対するアクセスから除外する、時刻制限をオブジェクトに設定できます。

セキュリティー・ポリシーは、保護を必要とするリソースに ACL および POP を戦略的に適用することによってインプリメントされます。Tivoli Access Manager 許可サービスは、要求元のユーザーの信任状、および ACL と POP に設定された特定の許可および条件に基づいて、リソースへのアクセスの許可または拒否の決定を行います。

許可エンジンは、以下のアルゴリズムを使用して、保護オブジェクトに付加されたポリシーを処理します。

1. ACL 許可を検査する。 ACL 評価プロセスについては、 28ページの『ACL の評価』を参照してください。

図 13. 明示的および継承されたポリシー


2. POP が付加されている場合は、インターネット・プロトコル (IP) エンドポイント認証メソッド・ポリシーを検査する。

3. POP が付加されている場合は、POP で時刻ポリシーを検査する。

4. POP が付加されている場合は、POP で監査レベル・ポリシーを検査する。

5. このアクセス決定に、外部許可サービス (EAS) 操作または POP トリガーが適用される場合は、適用される外部許可サービス (EAS) を呼び出す。

ACL または POP 評価のいずれかが失敗した場合、アクセス要求は拒否されます。外部許可サービスは、それ自体でこの決定を指定変更するよう設計されている場合、そのように実行するか、許可決定にまったく参加しないことを選択できます。

すべての ACL または POP は、ポリシーとしてみなされます。適切なアクセス条件を指定して、ポリシーを入力します。ポリシーが完成した後、ドメイン内のリソースにいくつでも適用できます。その後のポリシーへの変更は、自動的にドメイン全体に反映されます。

ACL ポリシーオブジェクトへのアクセス権の所有者、およびオブジェクトに対して実行可能な操作を定義するポリシーは、ACL ポリシーとして知られています。それぞれの ACL

ポリシーは、固有の名前を持っており、ドメイン内の複数のオブジェクトに適用できます。

ACL ポリシーは、次に述べる 1 つ以上のエントリーから構成されます。

v オブジェクトへのアクセスが明示的に制御されるような、ユーザーおよびグループの名前

v 各ユーザー、グループ、または役割に許可されている特定の操作

v 特殊な any-other (任意認証) および unauthenticated (非認証) ユーザー・カテゴリーに許可された特定の操作

許可サービスでの ACL ポリシーの使用Tivoli Access Manager では、ACL ポリシーに基づいて、特定のユーザーが保護オブジェクトで操作を実行するのに必要な条件を指定します。 ACL がオブジェクトに付加されると、ACL 中のエントリーが、このオブジェクトで可能な操作、およびその操作の実行者を指定します。

Tivoli Access Manager は、広範囲の操作を網羅したデフォルトのアクション・セットを使用します。アクション、または許可は、ASCII 英字 (a～z、A～Z) 1 文字で表されます。各許可は、許可が制御する操作を記述するラベルで表示されます(pdadmin または Web Portal Manager によって)。さらに、Web Portal Manager

は、オブジェクト・スペースの特定の部分 (WebSEAL など) での使用、またはオブジェクト・スペース全体 (基本、汎用的) での使用に応じて ACL をグループ化します。

アプリケーション・ソフトウェアには、一般的に、保護オブジェクトに対して実行される 1 つ以上の操作が含まれています。 Tivoli Access Manager では、要求された操作を進行させるには、これらのアプリケーションが、許可サービスに呼び出しを行っている必要があります。この呼び出しは、Tivoli Access Manager サービスお


よびその他のアプリケーションの両方の許可アプリケーション・プログラミング・インターフェース (許可 API) を介して行われます。

許可サービスでは ACL に含まれる情報を使用して、「このユーザー (グループ)

は要求されたオブジェクトを「表示」するための「r」許可 (例) を持っていますか」という質問に対して、単純に「yes」または「no」と応答します。

許可サービスは、「r」許可を必要とする操作について関知しません。要求元ユーザーまたはグループの ACL エントリーでの「r」許可の有無を注意しているのみです。

許可サービスは、要求されている操作から完全に独立しています。許可サービスの利点を容易に他のアプリケーションに拡張できるのは、このためです。

ACL の評価Tivoli Access Manager は、特定の評価プロセスに従って、ACL によって特定のユーザーに付与される許可を判別します。このプロセスについて理解すれば、好ましくないユーザーのリソースへのアクセスを防ぐ最善の方法を判断できます。

認証済み要求の評価Tivoli Access Manager は、認証済みユーザーの要求を次の順序で評価します。

1. ユーザー ID を ACL のユーザー・エントリーと突き合わせます。付与される許可は、一致したエントリーにあるものです。

一致した場合: 評価はここで停止します。一致しない場合: 次のステップに続行します。

2. ユーザーが所属するグループを判別し、ACL のグループ・エントリーと突き合わせます。

複数のグループ・エントリーが一致した場合は、その許可は、一致した各エントリーから付与された許可の論理「or」演算 (最も多く許可) の結果になります。


3. any-other (任意認証) エントリー (ある場合) の許可を付与します。


4. any-other (任意認証) ACL エントリーがない場合は、暗黙的な any-other (任意認証) エンティティーが存在します。この暗黙的なエントリーは、許可を何も付与しません。

一致した場合: 許可は付与されません。評価プロセスは終了します。

非認証要求の評価Tivoli Access Manager は、ACL の unauthenticated (非認証) エントリーから許可を付与することによって、非認証ユーザーを評価します。

unauthenticated (非認証) エントリーは、許可を決定するときの、 any-other (任意認証) エントリーに対するマスク (ビット単位の「and」演算) です。unauthenticated (非認証) に対する許可は、許可が any-other (任意認証) エントリーの中にも出てくるときだけ、付与されます。


unauthenticated (非認証) は、any-other (任意認証) に応じて決まるので、ACL

に any-other (任意認証) なしの unauthenticated (非認証) が含まれても、あまり意味がありません。 ACL に any-other (任意認証) がない unauthenticated (非認証) が含まれている場合のデフォルトの応答は、unauthenticated (非認証) に許可を付与しないということです。

POP ポリシーPOP ポリシーは、ユーザーまたは実行される操作にかかわらず、オブジェクトに適用されるセキュリティー・ポリシーを指定します。それぞれの POP ポリシーは、固有の名前を持っており、ドメイン内の複数のオブジェクトに適用できます。

POP の目的は、アクセスの時間に基づいてオブジェクトにアクセス条件を設け、アクセス要求が監査されるかどうかを指示することにあります。適用できる具体的な条件は以下のとおりです。

v 警告モード、監査レベル、時刻などの POP 属性。

これらの属性について詳しくは、 97ページの『POP 属性の構成』を参照してください。

v 認証強度 POP ポリシー (ステップアップ)。

このポリシーについて詳しくは、 99ページの『認証強度 POP ポリシー (ステップアップ)』を参照してください。

v 保護品質 POP ポリシー。

このポリシーについて詳しくは、 101ページの『保護品質 POP ポリシー』を参照してください。

v ネットワーク・ベースの認証 POP ポリシー。

このポリシーについて詳しくは、 102ページの『ネットワーク・ベースの認証POP ポリシー』を参照してください。

セキュア・オブジェクト・スペースのガイドライン以下のガイドラインは、セキュア・オブジェクト・スペースに適用できます。

v オブジェクト・スペースの最上部にあるコンテナー・オブジェクトに、高レベルのセキュリティー・ポリシーを設定します。階層の低い位置のオブジェクトに明示的 ACL および POP を設けて、このポリシーに例外を設定します。

v 保護オブジェクト・スペースは、ほとんどのオブジェクトが継承によって保護される (明示的、つまり ACL および POP ではなく) ように、配置します。

ツリーの保守を単純化することによって、ネットワークの信頼を損ねる恐れのあるエラーのリスクが減少します。継承された ACL および POP の場合は、保守の必要がある ACL および POP の数が減るので、ユーザーのツリーの保守が簡素化されます。

v 新しいオブジェクトは、適切な許可を継承するようなツリーに置くようにします。

オブジェクト・ツリーを一連のサブツリーに組み入れ、その各サブツリーは特定のアクセス・ポリシーによって支配されます。サブツリーのルートに明示的なACL および POP を設定することによって、サブツリー全体のアクセス・ポリシーを決定します。


v ACL および POP ポリシーのコア・セットを作成して、必要に応じてこれらのACL および POP を再利用します。

ACL および POP ポリシーは単一のソース定義なので、このポリシーを変更すると、ACL および POP と関連するすべてのオブジェクトに影響します。

v グループを用いることによって、ユーザー・アクセスを制御します。

ACL および POP をグループ・エントリーだけで構成することも可能です。個々のユーザーによるオブジェクトへのアクセスは、これらのグループへのユーザーの追加や、そこからのユーザーの除去によって効率よく制御することができます。


第 3 章デフォルトのセキュリティー・ポリシー

Tivoli Access Manager は、ドメイン内のすべてのオブジェクトを保護するためにデフォルトのセキュリティー・ポリシーを設定します。一連の管理ユーザーおよびグループが設定され、事前定義された一連の許可が与えられます。本章では、デフォルトのセキュリティー・ポリシーについて説明します。

デフォルトの管理ユーザーおよびグループインストールの際、Tivoli Access Manager には、いくつかの重要な管理グループが提供されます。デフォルトにより、これらのユーザーやグループには、ドメインにあるすべての操作を制御し、管理するための特別な許可が与えられます。 (このデフォルトのセキュリティー・ポリシーは、インストール時に作成されるアクセス・コントロール・リスト (ACL) によって定義されます。)

次のセクションで、インストール時にこれらの各ユーザーおよびグループに割り当てられる特定の役割の詳細と、管理ユーザーの作成方法について説明します。

グループ iv-adminこのグループは、アドミニストレーター・グループを表します。このグループのメンバーはすべて、デフォルト・ポリシーによって、ドメインのアドミニストレーターと考えられます。

ユーザーを iv-admin グループに加えることによって、容易にユーザーを管理の役割に入れることができます。この手順の危険な点は、ユーザーがこのグループのメンバーになる (デフォルトの ACL を持つ) と、デフォルト・ポリシー内のネーム・スペース全体のすべてのオブジェクトに対して管理操作を行う全権をただちに持つことです。

ポリシー・サーバーが構成される際、アドミニストレーター (sec_master) ユーザーが作成され、iv-admin グループに追加されます。 sec_master に、管理ドメイン内の (ただしデフォルト・ポリシー内のみ) すべての操作に対する全権を付与するのは、グループ・メンバーシップの組み合わせです。 sec_master ユーザーは、ユーザーまたはグループのメンバーとして追加されない限り、デフォルト・ポリシー外で作成された新しいグループに対する権利はありません。

ユーザー sec_mastersec_master ユーザーは、Tivoli Access Manager が最初にインストール、構成される際に作成されます。デフォルトのポリシーにより、sec_master ユーザーはiv-admin グループのメンバーになり、Tivoli Access Manager 内ですべてのアクションを実行することが許可されます。このアカウントについて、UNIX の root アカウント、または Microsoft Windows の Administrator アカウントに相当すると考えてください。


グループ ivmgrd-serversこのグループは、ポリシー・サーバーおよびポリシー・プロキシー・サーバーにより構成されていまいす。デフォルトでは、このグループのメンバーは、要求元に代わって別の Tivoli Access Manager サーバーへの要求を代行することを許可されています。

管理ユーザーの作成責任の度合いの異なる管理アカウントを作成することができます。責任は、戦略的に配置された管理 ACL を介して、アドミニストレーターに委任されます。以下のリストは、管理の役割として考えられるものを示したものです。

v ACL 管理の責任

ACL アドミニストレーターは、管理 ACL が置かれている場所に応じて、保護オブジェクトのネーム・スペース領域のすべて、または一部を制御することができます。アドミニストレーターの ACL エントリーには、ブラウズ (b)、付加 (a)、および全探索 (T) 許可に加えて、その領域のオブジェクトに対する操作に対応する他のすべての許可が含まれている可能性があります。

アドミニストレーターは、Web Portal Manager、pdadmin ユーティリティー、または許可アプリケーション・プログラミング・インターフェース (許可 API) を使用し、ACL ポリシーの既存のセットを用いて、指定されたネーム・スペースのオブジェクトに ACL を付加 (a) することができます。このアドミニストレーターには、ACL ポリシーの作成、変更、または削除の許可は必要ありません。

v ACL ポリシーの責任

ACL ポリシー・アドミニストレーターには、ドメインで使用されるすべてのACL ポリシーの作成と修正を制御する責任があります。ACL ポリシー・アドミニストレーターには、/Management または /Management/ACL オブジェクトに対する、削除 (d)、ブラウズ (b)、変更 (m)、および表示 (v) 許可の付与が必要です。

この ACL ポリシー・アドミニストレーターは、変更 (m) 許可を使用して、新しい ACL ポリシーを作成できます。新しいポリシーの作成者として、アドミニストレーターは、デフォルトにより、TcmdbsvaBl 許可付きの新しい ACL ポリシーの最初のエントリーになります。コントロール許可 (c) は、実質的に、ACL

の所有権およびそれにしたがって ACL を修正する権限を、アドミニストレーターに与えます。

ACL の所有者として、アドミニストレーターは、ポリシーのリストから ACL を除去するために削除 (d) 許可 (管理 ACL で付与されている) を使用することができます。その ACL の所有者でない限り、ACL ポリシーを削除することはできません。

v サーバー管理の責任

このアドミニストレーターには、/Management/Server オブジェクトに対する、削除 (d)、変更 (m)、サーバー管理 (s)、および表示 (v) 許可が付与されます。このアドミニストレーターは、Tivoli Access Manager サーバーに影響を与える操作を実行できます。

v 許可アクションの責任


このアドミニストレーターには、/Management/Action オブジェクトに対する、削除 (d) および変更 (m) 許可が付与されます。このアドミニストレーターは、すべてのアプリケーション用に作成されるすべての許可を作成または削除することができます。

管理 ACL ポリシーの例次の例では、管理権限をユーザーが取得する方法を示します。

以下の /WebSEAL の ACL により、ユーザー adam に管理権限が与えられます。

user sec_master abcTdmlrxgroup iv-admin abcTdmlrxgroup webseal-servers gTdmlrxgroup ivmgrd-servers Tluser adam abcTdmlrxany-other Trxunauthenticated Trx

セキュリティー・ポリシーの定義および適用セキュリティー・アドミニストレーターは、セキュリティー・ポリシーを定義することにより、リソースを保護します。セキュリティー・ポリシーは、オブジェクト・スペース内で保護されるシステム・リソースのオブジェクト表現に適用されるアクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー (POP)

により構成されています。同一のオブジェクトに、ACL と POP の両方を適用できます。

許可サービスは、これらのオブジェクトに適用されるポリシーに基づいて許可決定を行います。保護オブジェクトで要求された操作を実行することを認めると、そのリソースに関する責任を負っているアプリケーションがこの操作をインプリメントします。

1 つのポリシーが、多数のオブジェクトの保護パラメーターを指示できます。 ACL

または POP に変更があった場合、そのポリシーが付加されているすべてのオブジェクトに影響します。

アクセス・コントロール・リストアクセス・コントロール・リスト (ACL) ポリシーまたは ACL ポリシーは、そのリソースで特定の操作を行うために必要な条件を指定する、コントロール (許可) の集合です。ACL ポリシー定義は、ドメイン用に設定されたセキュリティー・ポリシーの重要なコンポーネントです。 ACL ポリシーは、すべてのポリシーと同様に、組織のセキュリティー標準を、保護オブジェクト・スペース内で表現されているリソースに適用するために使用します。

ACL ポリシーは特に以下の制御を行います。

1. そのリソースにどの操作を実行できるか。

2. だれがこれらの操作を実行できるか。

第 3 章デフォルトのセキュリティー・ポリシー 33

ACL ポリシーは、ユーザーとグループの指定、およびそれらの特定の許可または権限のいずれかが含まれている 1 つ以上のエントリーから構成されます。

デフォルトの管理 ACL ポリシードメインの特定の領域のセキュリティー保護を開始する場合、次のようなデフォルトの管理 ACL ポリシーをお勧めします。

user (ユーザー)、groups (グループ)、any-other (任意認証)、およびunauthenticated (非認証) のエントリーを追加して、さらに広い範囲のコントロールを提供し、ユーザーの保護オブジェクト・スペースの必要条件にも、さらによく合わせることができます。

コントロール (c) 許可が含まれている、各 ACL のユーザーとグループに注意してください。コントロール許可を持つユーザーおよびグループは、ACL を所有しており、ACL エントリーを変更する権利を持っています。

デフォルトのルート ACL ポリシーデフォルトのルート ACL、default root のコア・エントリーを以下に示します。

Group iv-admin TcmdbvaBAny-other TUnauthenticated T

ルート ACL は非常に基本的なもので、だれでもオブジェクト・スペースを全探索できますが、その他のアクションは実行できません。通常、ユーザーはこれを変更する必要はありません。しかし、ルート ACL の便利な機能の 1 つは、個々のユーザーまたはグループの、オブジェクト・スペース全体へのアクセスをすばやく拒否することです。

ルート ACL にある次のようなエントリーについて考えてみましょう。

user john -----------------

このエントリー (許可なし) の結果、ユーザー john は、ルート・コンテナー・オブジェクトを全探索することもできません。ツリーの中の低い位置でどのような許可が付与されていても、このユーザーは、保護オブジェクト・スペースにアクセスすることは、絶対にできません。

デフォルト /Management ACL ポリシー管理 ACL、default-management のコア・エントリーを以下に示します。

図 14. ACL ポリシー


Group iv-admin TcmdbsvaBtNWAGroup ivmgrd-servers TsAny-other Tv

インストール時に、この ACL は、オブジェクト・スペースの /Management コンテナー・オブジェクトに付加されます。

デフォルト /Replica ACL ポリシーレプリカ管理 ACL、default-replica のコア・エントリーを以下に示します。

Group iv-admin TcbvaBGroup ivmgrd-servers mGroup secmgrd-servers mdvGroup ivacld-servers mdv

デフォルト /Config ACL ポリシー構成管理 ACL、default-config のコア・エントリーを以下に示します。

Group iv-admin TcmdbsvaBAny-other TvUnauthenticated Tv

デフォルト /GSO ACL ポリシーGSO 管理 ACL、default-gso のコア・エントリーを以下に示します。

Group iv-admin TcmdbvaBNAny-other TvUnauthenticated Tv

デフォルト /Policy ACL ポリシーポリシー管理 ACL、default-policy のコア・エントリーを以下に示します。

Group iv-admin TcmdbvaBNRAny-other TvUnauthenticated Tv

管理許可保護オブジェクト・スペースの管理領域には、特定セットの許可を必要とするいくつかのサブ管理コンテナー・オブジェクトが含まれています。

v 36 ページの『/Management/ACL 許可』

v 37 ページの『/Management/Action 許可』

v 38 ページの『/Management/POP 許可』

v 38 ページの『/Management/Server 許可』

v 39 ページの『/Management/Config 許可』

v 39 ページの『/Management/Policy 許可』

v 39 ページの『/Management/Replica 許可』

v 40 ページの『/Management/Users 許可』

v 41 ページの『/Management/Groups 許可』

v 42 ページの『/Management/GSO 許可』

以下のセキュリティー上の考慮事項は、保護オブジェクト・スペースの/Management 領域に適用されます。


v 管理オブジェクトは、オブジェクト・スペースの管理領域全体のための ACL 継承のチェーンの始まりです。

v 他の ACL を明示的に適用しないと、このオブジェクトは、管理オブジェクト・スペース全体のセキュリティー・ポリシーを定義します (継承によって)。

v /Management へのアクセスには、全探索許可が必要です。

/Management/ACL 許可このオブジェクトを使用して、管理ユーザーは、ドメインのセキュリティー・ポリシーに影響を与える可能性のある高レベルの ACL 管理タスクを実行することができます。

操作説明

a 付加 ACL ポリシーをオブジェクトに付加します。ACL ポリシーをオブジェクトから除去します。

pdadmin acl attachpdadmin acl detach

c コントロール ACL ポリシーの所有権; この ACL のエントリーの作成、削除、および修正を可能にします。

pdadmin acl modify

d 削除既存の ACL ポリシーを削除します。このユーザーの ACL エントリーには、コントロール (c) 許可が含まれている必要があります。

pdadmin acl delete

m 変更新しい ACL ポリシーの作成。

pdadmin acl create

v 表示ビュー ACL をリストし見つけます。ACL の詳細を表示します。この許可は、/Management/ACL に付加される ACL のエントリーになければなりません。

pdadmin acl findpdadmin acl list pdadmin acl show

ACL アドミニストレーター・エントリーを、/Management/ACL オブジェクトのデフォルト ACL ポリシーに作成する必要があります。アドミニストレーターの ACL

エントリーに、上記の許可を含めることができます。これらの許可があると、新しい ACL ポリシーの作成、ACL のオブジェクトへの付加、および ACL ポリシーの削除の権限がアドミニストレーターに与えられます。

ACL アドミニストレーターは、コントロール (c) 許可が入っているエントリーがアドミニストレーターのその ACL にない限り、既存の ACL を変更できません。そのエントリーを変更できるのは、ACL の所有者だけです。

新しい ACL ポリシーの作成者 (/Management/ACL の m) は、その ACL の最初のエントリーになる (デフォルトで設定された TcmdbsvaBI 許可を用いて) ことに注意してください。

たとえば、sec_master が default-management ACL のアドミニストレーター・エントリーならば、sec_master は、「m」許可を用いて新しい ACL ポリシーを


作成することができます。ユーザー sec_master は、TcmdbsvaBIR 許可を用いて新しい ACL の最初のエントリーになります。

コントロール許可 (c) によって sec_master に ACL の所有権が与えられ、sec_master は ACL を変更することができます。このあと、ユーザーsec_master は、管理の許可を、その ACL の中にある他のユーザー・エントリーに付与できます。

default-management ACL 自体の所有権は、デフォルトでは sec_master とiv-admin の両方のユーザーに与えられます。

コントロール許可 (c): コントロール許可は、ACL ポリシーの所有権をユーザーに与える強力な許可です。コントロール許可を使うと、ACL にあるエントリーを変更することができます。これは、エントリーの作成、エントリーの削除、許可の認可、および許可の取り消しの機能を持つことを意味します。

ACL を ACL ポリシーのリストから削除するアドミニストレーターは、その ACL

にエントリーを持ち、かつそのエントリーにコントロール許可を設定している必要があります。

コントロール許可を用いて、ユーザーは、別のユーザーに管理の権限、たとえばその ACL をオブジェクトに付加 (a) する能力などを付与することができます。コントロール許可を使用するときは、所有権のプロパティーが非常に強力なので、十分注意してください。

コントロール許可が重要なのは /Management/ACL スペースにおいてのみです。

/Management/Action 許可このオブジェクトは、管理ユーザーが、カスタム・アクションおよびアクション・グループを管理できるようにします。アクション・タスクおよび関連する許可には、以下のものが含まれます。

操作説明

d 削除既存のアクションまたはアクション・グループを削除します。

pdadmin action deletepdadmin action group delete

m 変更新しいアクションまたはアクション・グループを作成します。

pdadmin action createpdadmin action group create

注: 以下のコマンドは、特殊な許可を必要としません。

pdadmin action list

pdadmin action group list

Tivoli Access Manager は、アプリケーションに許可サービスを提供します。たとえば Tivoli Access Manager ファミリーの一部であるアプリケーションには、WebSEAL (Web アプリケーションの場合) や、 Tivoli Access Manager for Business

Integration (メッセージング・アプリケーションの場合) などがあります。


アプリケーションは、許可 API を介して、許可サービスを呼び出すことができます。アプリケーションと許可サービスの統合に必要な 3 つのステップを以下に示します。

v アプリケーションのオブジェクト・スペースを定義する。

v アプリケーションのアクション・グループおよびアクションを定義する。

v 保護を必要とするオブジェクト (リソース) に許可を適用する。

アプリケーションのオブジェクト・スペースのアドミニストレーターは、pdadminユーティリティーを使用して、新しい許可とアクションを定義することができます。アドミニストレーターがこれらの許可またはアクションを作成および削除するには、m および d Management/Action 許可が必要です。

/Management/POP 許可このオブジェクトは、管理ユーザーが、保護オブジェクト・ポリシーを管理できるようにします。許可はすべて、/Management/POP 上の ACL のエントリーに記述される必要があります。アクション・タスクおよび関連する許可には、以下のものが含まれます。

操作説明

a 付加 POP をオブジェクトに付加します。

pdadmin pop attachpdadmin pop detach

d 削除 POP を削除します。

pdadmin pop delete

m 変更 POP を作成し、POP 属性を変更します。

pdadmin pop createpdadmin pop modify

v 表示 POP を検索してリストし、POP の詳細を表示します。

pdadmin pop findpdadmin pop listpdadmin pop show

B POP のバイパス

POP ポリシーをオブジェクトに指定変更します。

/Management/Server 許可保護オブジェクト・スペースの /Management/Server コンテナー・オブジェクトを使用すると、アドミニストレーターは、サーバー管理タスクを実行することができます (適切な許可が設定されている場合)。

サーバー管理コントロールを用いて、ユーザーが、サーバー定義の作成、変更、または削除の許可を持っているかどうか判別します。サーバー定義には、ほかのTivoli Access Manager サーバー、特にポリシー・サーバー (pdmgrd) が、そのサーバーを見つけて、通信できるようにする情報が含まれています。

インストール・プロセスの一部として、特定のリソース・マネージャー (WebSEAL

など) または許可サーバー (pdacld) 用にサーバー定義が作成されます。サーバーの定義も、サーバーのアンインストール時に削除されます。


操作説明

s サーバー許可データベースを複製します。

pdadmin server replicate

v 表示登録されたサーバーをリストし、サーバー・プロパティーを表示します。

pdadmin server listpdadmin server show

t トレース動的トレースまたは統計管理を使用可能にします。

pdadmin server task server_name tracepdadmin server task server_name stats

/Management/Config 許可保護オブジェクト・スペースの /Management/Config コンテナー・オブジェクトを使用すると、アドミニストレーターは、構成管理タスクを実行することができます(適切な許可が設定されている場合)。

サーバー定義の作成と削除は、自動的に行われます。インストール・アドミニストレーターは、定義を作成するための特別なステップを実行する必要はありません。しかし、アドミニストレーターには、インストール中に定義を作成するために、/Management/Config オブジェクトの変更 (m) 許可が付与されている必要があります。

さらに、アドミニストレーターには、アンインストール中に定義を削除するために、/Management/Config オブジェクトの削除 (d) 許可がなければなりません。

操作説明

m 変更ドメインへの構成。

svrsslcfg -configsvrsslcfg -modify

d 削除構成解除。

svrsslcfg -unconfig

/Management/Policy 許可保護オブジェクト・スペースの /Management/Policy コンテナー・オブジェクトを使用すると、アドミニストレーターは、policy get および policy set コマンドを実行できます (適切な許可が設定されている場合)。

操作説明

v 表示 policy get 操作に必要。

m 変更 policy set 操作に必要。

/Management/Replica 許可保護オブジェクト・スペースの /Management/Replica コンテナー・オブジェクトは、許可データベースの複製を制御します。このオブジェクトに対する高レベルの制御は、ドメインにおけるポリシー・サーバーおよびセキュリティー・マネージャーの操作に影響します。


レプリカ管理コントロールは、複製が正しく行われるように、マスター許可ポリシー・データベースをどのプロセスが読み取りまたは更新できるかを判別するために使用されます。

コントロールおよび関連する許可には、以下のものが含まれます。

操作説明

v 表示マスター許可データベースを読み取ります。

許可データベースのローカル・レプリカを保持するすべての Tivoli Access Manager

(これにはすべてのリソース・マネージャーおよび許可サーバーが含まれる) には、/Management/Replica オブジェクトの表示 (v) 許可が付与されている必要があります。複製プロセスでは、これらのプロセスが、マスター許可ポリシー・データベースからエントリーを表示し、アクセスできるようにすることが必要です。Tivoli Access Manager のインストールでは、許可ポリシー・データベースへのアクセスを必要とするすべてのサーバーに、読み取り許可が自動的に付与されます。

/Management/Users 許可このオブジェクトは、管理ユーザーが、ユーザー・アカウントを管理できるようにします。アクション・タスクおよび関連する許可には、以下のものが含まれます。

操作説明

d 削除ユーザー・アカウントを削除します。

pdadmin user delete

m 変更ユーザー・アカウントの詳細を変更します。

pdadmin user modify authentication-mechanismpdadmin user modify account-validpdadmin user modify gsouserpdadmin user modify description

N 作成新しいユーザーを作成し、オプションでそのユーザーを 1 つ以上のグループに割り当てます。グループ・データをユーザー・レジストリーからインポートします。

pdadmin user createpdadmin user import

v 表示ユーザー・アカウントをリストし、ユーザー・アカウントの詳細を表示します。

pdadmin user listpdadmin user list-dnpdadmin user list-gsouserpdadmin user showpdadmin user show-dnpdadmin user show-groups

W パスワードユーザー・パスワードをリセットし、妥当性検査します。

pdadmin user modify passwordpdadmin user modify password-valid

「W」許可はパスワードをリセットするのに使用でき、パスワードを忘れたユーザーを援助できるように、ヘルプ・デスク・アドミニストレーターに付与するのが適切です。この許可を使用して、アドミニストレーターは忘れたパスワードをリセットしてから、user modify password-valid コマンドを使用して「no」の値を設定


できます。このアクションで、ユーザーはログオンし、ただちに新規パスワードを適用するよう強制されます。ユーザーに対して user modify password-valid を「no」に設定することにより、グローバル設定である max-password-age ポリシーによってパスワードが無効であることを示しているのではない点にご注意ください。ポリシーの set max-password-age コマンドは、パスワードの有効期限が切れるまでの期間を設定します。

/Management/Users オブジェクトによって付与されるアクセス権により、/Management/Groups/group_name 下の、「代行管理」ポリシー ACL によって課せられるすべてのアクセス制限は指定変更されます。代行管理の詳細については121ページの『第 13 章代行管理』を参照してください。

/Management/Groups 許可このオブジェクトは、管理ユーザーが、グループおよびグループ・メンバーシップを管理できるようにします。アクション・タスクおよび関連する許可には、以下のものが含まれます。

許可操作説明

d 削除グループを削除します。

pdadmin group delete

m 変更グループ記述を変更します。グループの 1 つ以上のユーザー・メンバーを除去します。

pdadmin group modify descriptionpdadmin group modify remove

N 作成新規グループを作成します。グループ・データをユーザー・レジストリーからインポートします。

pdadmin group createpdadmin group import

v 表示グループをリストし、グループの詳細を表示します。

pdadmin group listpdadmin group list-dnpdadmin group showpdadmin group show-dnpdadmin group show-members

A 追加 1 つ以上のユーザーをグループに追加します。

pdadmin group modify add

既存のユーザーをグループに追加できるようにするには、グループの ACL のエントリーに「A」許可が必要です。新規ユーザーを作成し、随意に 1 つ以上の既存のグループに入れるには、pdadmin user create コマンドを使用します (「N」許可が必要)。

グループに既存のユーザーを追加できるということは、グループの所有者がグループ中のすべてのユーザー・メンバーを制御するので強力な機能となります。グループの所有者として、削除 (「d」) 許可も持っている場合は、このユーザーをドメイン全体から削除できます。


/Management/GSO 許可保護オブジェクト・スペースの /Management/GSO コンテナー・オブジェクトを使用すると、アドミニストレーターは、グローバル・サインオン (GSO) 管理タスクを実行することができます (適切な許可が設定されている場合)。

操作説明

m 変更 pdadmin rsrcgroup modifypdadmin rsrccred modify

v 表示 pdadmin rsrc listpdadmin rsrcgroup listpdadmin rsrccred listpdadmin rsrc showpdadmin rsrcgroup showpdadmin rsrccred show

N 作成 pdadmin rsrc createpdadmin rsrcgroup createpdadmin rsrccred create

(上記の全コマンドにも「m」が必要)

d 削除 pdadmin rsrc deletepdadmin rsrcgroup deletepdadmin rsrccred delete

(上記の全コマンドにも「m」が必要)

疎 ACL モデル保護オブジェクト・スペースにあるネットワーク・リソースを保護するために、各オブジェクトをアクセス・コントロール・リスト (ACL) ポリシーで保護する必要があります。

次の 2 つの方法のどちらかで、オブジェクトに ACL ポリシーを割り当てることができます。

v オブジェクトに明示的 ACL ポリシーを付加する。

v オブジェクトが、階層内の先行コンテナー・オブジェクトからその ACL ポリシーを継承できるようにする。

ACL のスキームを継承して採用すると、ドメイン用の管理タスクを大幅に減らすことができます。このセクションでは、継承された、すなわち疎 ACL の概念を説明します。

ACL 継承ACL 継承の権利は、明示的に付加された ACL ポリシーを持たないオブジェクトは、明示的に設定された ACL を持つ、最も近いコンテナーのポリシーを継承するという原則に基づいています。言いかえると、明示的に付加された ACL のないすべてのオブジェクトは、明示的に付加された ACL を持つコンテナー・オブジェクトから ACL を継承するということです。継承の特定のチェーンは、オブジェクトに明示的な ACL を付加すると、そこで切断されます。

ACL 継承の方法をとると、大きな、保護されたオブジェクト・スペースに対するアクセス・コントロールの設定と保守の作業が簡素化されます。典型的なオブジェク


ト・スペースでは、オブジェクト・スペース全体を保護するための鍵位置で、いくつかの ACL を付加するだけですみます。したがって、疎 ACL モデルと呼びます。

典型的なオブジェクト・スペースは、ルート・コンテナー・オブジェクトに付加されている単一の明示的な ACL から始まります。ルート ACL は、常に存在していなければならず、除去することはできません。通常、これは、ほとんど制約事項のない ACL です。オブジェクト・スペースにあるオブジェクトはすべて、この ACL

を継承します。

オブジェクト・スペース内の領域またはサブツリーに、異なるアクセス・コントロールの制約が必要な場合は、そのサブツリーのルートに明示的な ACL を付加します。このようにすると、1 次オブジェクト・スペースのルートからそのサブツリーへの、継承 ACL の流れが中断されます。継承の新しいチェーンは、新たに作成されたこの明示的な ACL から始まります。

デフォルトのルート ACL ポリシーTivoli Access Manager は、保護オブジェクト・スペースのルートから始まる継承を検査します。ツリーの他のすべてのオブジェクトで明示的に ACL を設定しない場合は、ツリー全体がこのルート ACL を継承します。

保護オブジェクト・スペースのルートには、常に明示的な ACL ポリシー・セットがあります。アドミニストレーターは、この ACL を、他のエントリーや許可の設定を持つ他の ACL と置き換えることができます。しかし、ルート ACL を完全に除去することはできません。

ルート ACL ポリシーは、初期の Tivoli Access Manager インストールおよび構成の際に明示的に設定されます。

デフォルトのルート ACL (デフォルト・ルート) のコア・エントリーには、次のものが含まれています。

Group iv-admin TcmdbvaBAny-other TUnauthenticated T

全探索許可Tivoli Access Manager アクセス・コントロールは、以下の 2 つの条件で決まります。

v 要求されたオブジェクトを制御する ACL には、要求を出しているユーザーに関する適切なアクセス許可が含まれていなければならない。

v 要求されたオブジェクトに、要求を出しているユーザーがアクセス可能でなければならない。

保護オブジェクトへのアクセス可能性は、全探索 (T) 許可によって制御されます。

全探索許可が適用されるのは、保護オブジェクト・スペースのコンテナー・オブジェクトのみです。全探索許可は、ACL エントリーで識別された user (ユーザー)、group (グループ)、any-other (任意認証)、または unauthenticated (非認証) が、階層の下の保護リソース・オブジェクトへのアクセス権を得るために、そのコンテナー・オブジェクトをパススルーする許可を持つように指定します。


ルートへのパス (ルートも含む) で、要求されているリソース上にあるコンテナー・オブジェクトに付加された ACL ごとに、要求側が全探索許可を持っている場合、保護オブジェクトにアクセス可能です。

図 15 は、全探索許可の機能の説明図です。 ACME Corporation には、Engineering

コンテナー・オブジェクト (ディレクトリー) があり、またその中に TechPubs コンテナー・オブジェクト (サブディレクトリー) が入っています。 Sales 部門のメンバーである、ユーザー kate は、リリース情報ファイルを検討するために、Engineering/TechPubs ディレクトリーの全探索を要求します。アドミニストレーターは、ルートの any-other (任意認証) に全探索を提供します。アドミニストレーターは、Engineering ディレクトリーのグループ sales に全探索を提供します。TechPubs ディレクトリーは Engineering ディレクトリーから ACL を継承します。 Kate は、これらの 2 つのディレクトリーの中に他の許可は持っていませんが、 release_note ファイルにアクセスするためにこれらのディレクトリーをパススルー (全探索) することができます。このファイルは、ユーザー kate の読み取り許可を持っているので、彼女はこのファイルを表示することができます。

指定のコンテナー・オブジェクトより下の階層へのアクセスを制限するのは容易です。これらのオブジェクトの個々の許可を再設定する必要はありません。単に、全探索許可を該当の ACL エントリーから除去するだけです。ディレクトリー・オブジェクトで全探索許可を除去すると、その下の階層のすべてのオブジェクトが保護されます (これらのオブジェクトにもっと制限の少ない他の ACL が含まれていたとしても)。

たとえば、グループ sales が Engineering ディレクトリーに全探索許可を持っていなかった場合、Kate にファイルの読み取り許可があっても、リリース情報ファイルにアクセスできません。

図 15. 全探索許可


アクセス要求の解決継承は、ルート ACL から始まり、明示的な ACL を持つオブジェクトが出てくるまで、オブジェクト・スペースにあるすべてのオブジェクトに影響を与えます。このポイントから、継承の新しいチェーンが始まります。

明示的に設定された ACL の下にあるオブジェクトは、この新しいアクセス・コントロールを継承します。明示的な ACL を削除すると、すべてのオブジェクトに対するアクセス・コントロールは、明示的に設定された ACL を持つ最も近くにあるディレクトリーまたはコンテナー・オブジェクトに戻ります。

ユーザーがセキュア・オブジェクト (Web 文書など) にアクセスしようとすると、Tivoli Access Manager は、そのユーザーがオブジェクトにアクセスする許可を持っているかどうか検査します。これは、正しく継承されたか、または明示的に設定された許可に関して、オブジェクト階層に沿ってすべてのオブジェクトをチェックすることによって、行われます。

階層の上方にある任意のディレクトリーまたはコンテナー・オブジェクトに、そのユーザーに対する全探索許可が含まれていないと、ユーザーのアクセスは拒否されます。また、要求された操作を実行するのに必要な許可をターゲット・オブジェクトが十分に持っていないときにも、アクセスが拒否されます。

アクセス・チェックに合格するには、要求側は以下の両方がなければなりません。

v 要求されるオブジェクトへのパスを全探索する許可。

v 要求されるオブジェクトに関する適切な許可。

ユーザーがオブジェクトを読み取る (表示する) ことができるかどうかを解決するプロセスを、以下に示します。

/acme/engineering/project_Y/current/report.html

Tivoli Access Manager は、以下について検査します。

v 明示的に設定されたルート ACL (/) での全探索許可。

v ディレクトリーの acme、engineering、project_Y、および current に付加された明示的 ACL の全探索許可。

v ファイル自体 (report.html) の読み取り許可。

オブジェクト階層に沿ったこれらのポイントのいずれかで、ユーザーがアクセス・チェックに失敗すると、ユーザーのアクセスは拒否されます。

異なるオブジェクト・タイプへの ACL ポリシーの適用さまざまな操作への許可は、ACL ポリシーで設定できます。 ACL が付加された特定のオブジェクトの場合に関連があるのは、これらの可能性のある操作のサブセットのみです。

この動作の理由は、管理を容易にするように設計された Tivoli Access Manager の次の 2 つの機能に関連しています。

v ACL ポリシー

v ACL 継承


ACL ポリシーを使うと、保護オブジェクト・スペースにある複数オブジェクトに、同じ ACL 定義を付加することができます。 ACL 定義は、ACL が適用されるすべてのオブジェクトの要件を満たす十分なエントリーから構成されます。しかし、それぞれのオブジェクトが影響を受けるのは、2、3 のエントリーのみです。

ACL の継承モデルでは、付加された明示的 ACL を持たないオブジェクトはいずれも、それより上方の階層にあるオブジェクトに適用された最も近い ACL から、ポリシーの定義を「継承」します。

要約すると、ACL ポリシーは、それが適用されるすべてのオブジェクト・タイプ(付加の対象のオブジェクトだけではない) の必要な許可を記述する必要があります。

ACL ポリシー継承の例47ページの図 16 は、ある会社のオブジェクト・スペースの継承された ACL と明示的 ACL が混合した場合の影響を示す説明図です。

この会社のオブジェクト・スペースには、ルート・オブジェクトに汎用のセキュリティー・ポリシー・セットがあります。ルートの後には、 /WebSEAL コンテナー・オブジェクトと、個々に制御される部門のサブツリーが続きます。

この例では、sales グループにその部門のサブツリーの所有権が与えられています。このサブツリー上の ACL は、unauthenticated (非認証) または any-other(任意認証) エントリー・タイプを、認識しなくなったことに注意してください。

年初から今日現在までの売上ファイル (ytd.html) には、sales-vp グループのメンバー (sales グループのメンバーでもある) に読み取り許可を付与する明示的 ACL

があります。

注: この ACL のスキームは、ドメイン内のユーザーの追加や削除のために変更する必要はありません。新しいユーザーは、単に適切なグループに追加されるだけです。同様に、ユーザーをこれらのグループから除去することもできます。


保護オブジェクト・ポリシーACL ポリシーは、保護オブジェクトにアクセスし、そのオブジェクトにいくつかの操作を実行する要求に、「yes」または「no」の応答を行う情報を許可サービスに提供します。

保護オブジェクト・ポリシー (POP) には、許可サービスからの「yes」ACL ポリシー決定とともに、Tivoli Access Manager Base およびリソース・マネージャーに戻される要求に関する追加の条件が含まれます。 POP 条件を適用することは Tivoli

Access Manager およびリソース・マネージャーの役割です。

POP の使用可能な属性を、以下にリストアップします。

Tivoli Access Manager Base による適用

POP 属性説明

名前ポリシーの名前。これは、pdadmin pop コマンドでpop_name になります。

説明ポリシーの記述テキスト。これは、pdadmin pop showコマンドで表示されます。

警告モード ACL および POP ポリシーをテストする手段を管理者に提供します。

監査レベル監査のタイプ (all、none、successful access、denied

access、error) を指定します。

時刻アクセス保護オブジェクトに正常にアクセスするための日時の制限。

図 16. ACL 継承の例



POP 属性説明

IP エンドポイント許可メソッド・ポリシー

外部ネットワークのメンバーからアクセスに関する許可要件を指定します。

EAS トリガー属性顧客の外部化されたポリシー・ロジックを使用して許可決定を下すために呼び出す外部許可サービス (EAS) プラグインを指定します。

リソース・マネージャーによる適用

(WebSEAL または他のブレード)

POP 属性説明

保護品質データ保護の程度 (none, integrity, privacy) を指定します。

IP エンドポイント認証メソッド・ポリシー

外部ネットワークのメンバーからのアクセスに関する認証要件を指定します。

継承、または疎 ACL の概念は、 42ページの『疎 ACL モデル』に説明されているように、 POP ポリシーにも同じように適用されます。


第 4 章 Web Portal Manager の使用

Web Portal Manager は、セキュア・ドメインのセキュリティー・ポリシーの管理に使用する Web ベースのインターフェースです。 Web Portal Manager により、ユーザー、グループ、役割、許可、ポリシー、およびアプリケーション・アクセス・プロビジョニングを管理できます。 Web Portal Manager を使用して実行できるタスクについては、オンライン・ヘルプ・システムに文書化されています。 Web Portal

Manager タスク・ベースの情報を探すときは、このヘルプ・システムを最初に参照してください。この章で概括する機能には、管理の代行と Web Portal Manager の機能があります。

注: Web Portal Manager の始動前に、IBM WebSphere Application Server が実行していることを確認してください。

本書には、以下のセクションが含まれています。

v 『Web Portal Manager の始動』

v 50ページの『ヘルプの表示』

v 51ページの『ログインとサインオフ』

v 51ページの『インターフェースの個人情報設定』

v 52ページの『Web Portal Manager を使用した管理の代行』

v 56ページの『セルフケアのインプリメント』

v 57ページの『自己登録のインプリメント』

Web Portal Manager の始動Tivoli Access Manager は、以下の 2 つのタイプの管理機能を提供します。

v Web Portal Manager 管理機能

121ページの『第 13 章代行管理』を除き、本書で説明されているタスクはWeb Portal Manager 管理機能を使用して実行されます。

v Web Portal Manager 管理の代行機能

Web Portal Manager 管理の代行機能は、個別のアプリケーションとして考えられています。Web Portal Manager 管理の代行機能に関する詳細な説明は、 52ページの『Web Portal Manager を使用した管理の代行』および 121ページの『第 13

章代行管理』を参照してください。

Web Portal Manager 管理機能は、基本のpdadmin 機能と類似した Web ベースのインターフェースを提供します。Web Portal Manager 管理機能には、管理の代行機能は含まれていません。

Web Portal Manager 管理の代行機能は一連の代行管理サービスを提供し、ユーザー管理、グループと役割の管理、セキュリティー管理、およびアプリケーション・アクセス・プロビジョニングをビジネス・システム内の参加プログラム (サブドメイン) に代行させることができます。これらのサブドメインは、自らの制御下にあるトラステッド・サブドメインに、管理をさらに代行させることができるため、役割に基づく複数レベルの代行および管理階層をサポートできます。


管理の代行機能は、以下のことをサポートします。

v 複数のエンタープライズ・ドメインの作成

v ユーザーのドメイン・アドミニストレーターへの割り当て

v アドミニストレーター・タイプの割り当て (例: Tivoli Access Manager アドミニストレーター、ドメイン・アドミニストレーター、シニア・アドミニストレーター、アドミニストレーター、およびサポート・アドミニストレーター)、および各アドミニストレーター・タイプで実行される管理機能の制約

v アドミニストレーターの介入なしに Tivoli Access Manager ユーザーとして登録する自己登録、および管理ロードを削減するセルフケア。

Web Portal Manager 管理機能の始動SSL をインストール、構成、使用可能にしていない場合は、Web Portal Manager にアクセスできません。 Web Portal Manager の始動前に、IBM WebSphere

Application Server が実行していることを確認してください。

SSL をインストール、構成、使用可能にしてから、以下の URL をお使いの Web

ブラウザーで入力してください。

https://hostname/pdadmin

hostname には、IBM HTTP サーバーおよび WebSphere が実行しているマシン名を入力してください。

Web Portal Manager 管理の代行機能の始動管理の代行機能へは、基本 pdadmin 機能とは異なる URL からアクセスされます。基本 pdadmin 機能には、管理の代行機能は含まれていません。管理の代行機能は、個別のアプリケーションと考えられています。

SSL をインストール、構成、使用可能にしていない場合は、Web Portal Manager 管理の代行機能を始動できません。Web Portal Manager の始動前に、IBM WebSphere

Application Server が実行していることを確認してください。

SSL をインストール、構成、使用可能にしてから、以下の URL をお使いの Web

ブラウザーで入力して、Web Portal Manager 管理の代行機能を始動してください。

https://hostname/delegate

hostname には、IBM HTTP サーバーおよび WebSphere が実行しているマシン名を入力してください。

ユーザーは、Web Portal Manager 管理の代行ページを開いて、そのパスワードを管理できます。ログイン後、ユーザーは「パスワードの変更」タスクを開く必要があります。

ヘルプの表示Web Portal Manager を使用してタスクを実行する方法は、オンライン・ヘルプ・システムに文書化されています。情報をフィールドに入力する場合や、Web Portal

Manager タスク・ベースの情報を選択/選択解除する場合に、ヘルプ・システムをリファレンスとして使用してください。


Web Portal Manager のオンライン・ヘルプを使用する方法は、以下のとおりです。

1. ドメインにログインする。

2. タスク (例: 「オブジェクト・スペース」→ 「オブジェクト・スペースの作成」)

を選択する。

3. Tivoli Access Manager タイトル・バーで、ウィンドウの右側にある疑問符 (?)

アイコンをクリックする。

タスクの実行に関するオンライン情報を提供するヘルプ・ウィンドウが別に開きます。

4. タスクを終了してから、ヘルプ・ウィンドウを閉じる。

ログインとサインオフWeb Portal Manager を使用してタスクを実行する方法は、オンライン・ヘルプ・システムに文書化されています。情報をフィールドに入力する場合や、Web Portal

Manager タスク・ベースの情報を選択/選択解除する場合に、ヘルプ・システムをリファレンスとして使用してください。

ドメインまたは Web Portal Manager にログインする方法は、以下のとおりです。

1. Web Portal Manager 管理機能を始動する。

2. ユーザー名およびパスワードなどの Web Portal Manager 認証を入力する。

3. Tivoli Access Manager ロゴが表示されてから、必要に応じてタスクを選択して実行する。

4. 下部のステータス・バーにある「サインオフ (Sign Off)」をクリックして Web

Portal Manager 管理機能をシャットダウンする。

インターフェースの個人情報設定Web Portal Manager を使用すると、Tivoli Access Manager ユーザーはインターフェースをカスタマイズできます。 Tivoli Access Manager ユーザーは、構成を変更して、Web Portal Manager の始動時にロードすべき HTML ページまたは GIF ファイルを指定することによって、Web Portal Manager を作り替えることができます。pdwpm.conf 構成ファイルのオプションを変更して、Web Portal Manager でカスタマイズできる領域には、次の 4 つがあります。

1. loginGif — これは、ログイン・ページのイメージを示します。

2. splashGif — これは、ログイン・ページの後のようこそページのイメージを示します。

3. infoBarGif — これは、ページの右下の IBM イメージを示します。

4. bannerFile — これは、各ページの上部のバナーを示します。

イメージのカスタマイズは、以下のように行います。

1. オプションの値を変更して、別のイメージを指定します。

2. 新しいイメージを、以下のディレクトリーのいずれかに入れます。

v UNIX システムの場合:

websphere_install_dir/WebSphere/AppServer/installedApps/pdwpm.ear/pdwpm.war/images

v Windows システムの場合:

第 4 章 Web Portal Manager の使用 51

websphere_install_dir¥WebSphere¥AppServer¥installedApps¥pdwpm.ear¥pdwpm.war¥images

3. ロケール固有バージョンのイメージの場合は、ロケールごとに以下のディレクトリーの下にサブディレクトリーを作成して、そこに新しいイメージを入れます。

v UNIX システムの場合:

websphere_install_dir/WebSphere/AppServer/installedApps/pdwpm.ear/pdwpm.war/images/locale/myImage.gif

v Windows システムの場合:

websphere_install_dir¥WebSphere¥AppServer¥installedApps¥pdwpm.ear¥pdwpm.war¥images¥locale¥myImage.gif

Web Portal Manager のカスタマイズした上部バナーを作成するには、以下のようにします。

1. JSP または HTML ファイルを作成します。

2. 作成した JSP または HTML ファイルを top_banner.jsp ファイルと同じディレクトリーに入れます。

3. デフォルト値が bannerFile=top_banner.jsp である bannerFile オプションの値を、新しい JSP または HTML ファイル名を指すように変更します。

pdmainframe.jsp ファイルによってフレームのレイアウトがセットアップされ、それによって、ページのフレームを 50 ピクセルに設定します。

Web Portal Manager を使用した管理の代行Web Portal Manager の機能の 1 つは、代行管理サービス・セットです。それらを使用することにより、業務において、ユーザー管理、グループと役割の管理、セキュリティー管理、およびアプリケーション・アクセス・プロビジョニングを、ビジネス・システム内の参加者 (サブドメイン) に代行させることができます。これらのサブドメインは、自らの制御下にあるトラステッド・サブドメインに、管理をさらに代行させることができるため、役割に基づく複数レベルの代行および管理階層をサポートできます。

Web Portal Manager を使用した管理の代行では、Tivoli Access Manager アドミニストレーターは、代行ユーザー・ドメインの作成、新規ユーザーの作成、既存ユーザーの追加ドメインへの追加、ならびにドメインへのさまざまなタイプのアドミニストレーターの割り当てを行うことができます。これらの代行アドミニストレーターは、したがってそのタイプ、すなわちその割り当てられたドメインのユーザーに応じて、管理機能のサブセットを実行できます。代行ユーザー管理のこの概念は、すべての Tivoli Access Manager ユーザーに適用できるため、ユーザー・ドメインの階層が形成されます。この階層の配置の中で、各 Tivoli Access Manager ユーザーを管理できるのは、ユーザーがそのメンバーであるドメインのアドミニストレーターか、あるいは上位ドメインのアドミニストレーター (この章で後述) に限られます。アドミニストレーターが行える実際の機能は、その割り当てられたアドミニストレーターのタイプによって決まります。

sec_master のような Tivoli Access Manager アドミニストレーターは、いくつかのエンタープライズ・ドメインを作成して、1 つまたは複数のタイプのアドミニストレーターを各エンタープライズ・ドメインに割り当てることができます。エンタ


ープライズ・ドメインのアドミニストレーターは、新規ユーザーをドメイン内に作成し、既存の Tivoli Access Manager ユーザーをドメインに追加することができます。

このユーザー関連機能に加えて、Tivoli Access Manager アドミニストレーターは、エンタープライズ・ドメインのレベル (サブドメイン) の下に新規ドメインを作成し、これら新規ドメインのアドミニストレーターとなるユーザー (ドメイン・アドミニストレーター) を決めることができます。この場合、新規ドメインのアドミニストレーターは、それ自体のドメイン内に新規ユーザーを作成できます。

エンタープライズ・ドメイン (ドメインの上位ドメイン) の Tivoli Access Manager

アドミニストレーターはドメインを管理する権限があります。 Tivoli Access

Manager アドミニストレーターは、その固有のビジネス・ニーズを実現する必要に応じて、その権限のもとに多くのドメインを作成し管理できます。

注: エンタープライズ・ドメインは、基本的には最上位のドメインであり、エンタープライズ・ドメイン・レベルの下に作成されたドメインは、すべて単にドメインと呼ばれます。

54ページの図 17 のこのタイプの複数ドメイン管理の例として、Tivoli Access

Manager アドミニストレーターはエンタープライズ・ドメイン A および B を作成して、ドメインごとにアドミニストレーターを割り当てることができます。エンタープライズ・ドメイン B のドメイン・アドミニストレーターは、新規ユーザーP、Q を作成できます。Tivoli Access Manager アドミニストレーターはエンタープライズ・ドメイン A および B の下にドメイン C および D を作成し、ドメイン・アドミニストレーターを C および D に割り当てることができます。次に Tivoli

Access Manager アドミニストレーターはドメイン D の下にドメイン E を作成し、アドミニストレーターを E に割り当てることができます。次にドメイン E のドメイン・アドミニストレーターはドメイン E 内に新規ユーザー X、Y、および Z を作成できます。ドメインのドメイン・アドミニストレーターはそのドメインのサブドメインを管理することもできるので、ドメイン D のドメイン・アドミニストレーターとエンタープライズ・ドメイン B のドメイン・アドミニストレーターはともに、ドメイン E のユーザーを作成できます（あるいは他の管理機能を実行できます)。


管理役割のタイプ代行ユーザー・ドメイン (エンタープライズ・ドメインを含む) ごとに、そのドメイン内で事前定義のアドミニストレーター・タイプを割り当てることができます。各種アドミニストレーター・タイプ、およびその各タイプに割り当てられたアドミニストレーターが実行できる管理機能のセットを、以下に示します。

v Tivoli Access Manager アドミニストレーター。 Tivoli Access Manager アドミニストレーターは、iv-admin グループのメンバーです。 Tivoli Access Manager

アドミニストレーターは、すべての管理の代行機能を実行できます。

v ドメイン・アドミニストレーター。ドメイン・アドミニストレーターは、そのドメインのユーザーの管理機能を実行できます。ドメイン・アドミニストレーターは、それ自体のドメインに新しいユーザーとアドミニストレーターを作成して、既存のドメイン・ユーザーをドメインのアドミニストレーター (ドメイン・アドミニストレーター以外のすべてのタイプの) に決めることができます。

v シニア・アドミニストレーター。シニア・アドミニストレーターには、追加のアドミニストレーターを割り当てられない点を除き、ドメイン・アドミニストレーターと同じ権限があります。

v アドミニストレーター。アドミニストレーターには、新しいドメイン・ユーザーを作成できない点を除き、シニア・アドミニストレーターと同じ権限があります。アドミニストレーターは、既存のユーザーのプロパティーを変更できます。

v サポート・アドミニストレーター。サポート・アドミニストレーターは、ヘルプ・デスクの役割でユーザーの役に立ち、ユーザー・プロパティーの表示、ユーザー・パスワードの変更、ならびにユーザーの Is Password Valid (有効なパスワード)?フラグの変更を行うことができます。

図 17. 代行アドミニストレーター


代行ユーザー管理ツールは、アドミニストレーター・タイプごとに実行できる管理機能を実施します。アドミニストレーターがログインすると、そのユーザーのアドミニストレーター・タイプに従って管理機能が使用可能になります。

役割管理の代行Web Portal Manager の管理の代行システムのもう 1 つの部分は、役割管理です。Tivoli Access Manager を正常に配置するには、オブジェクトへのアクセス、およびそのオブジェクトで実行できるアクションを規制するセキュリティー・ポリシーが定義されている必要があります。このポリシーは、セキュリティー・ポリシーが、グローバルなセキュリティー問題に重点を置いた組織の上位のメンバーによって定義される場合が多いため、通常実行するのが困難です。したがって、ポリシーをアクションに結び付けるのは、詳細とインプリメンテーションの関心レベルが低い、組織のローカル・メンバーが行う必要があります。これら 2 つのグループは、往々にして組織のセキュリティー全体に対する目標は同じですが、これら 2 つの異なる視点を相互に結び付けることは挑戦に値します。役割ベースの管理は、スケーラビリティー、単純性、および柔軟性に関して組織のセキュリティーが今日の複雑なセキュリティー要件を満たすための、強化された機能を備えています。

役割管理を理解するために定義すべき最初の概念は、役割です。役割は特定のジョブ要件を満たすのに必要ないくつかのタスク、責任、またはスキルから構成されます。この定義が Tivoli Access Manager のアクセス・コントロール・リスト (ACL)

モデルと対比されると、役割は、オブジェクトの 1 つ以上のペア、およびオブジェクトに適用される 1 つ以上のアクセス許可のリストになります。たとえば、次のとおりです。

v オブジェクト 1: 許可 1

v オブジェクト 2: 許可 2、3、および 4

v オブジェクト 3: 許可 5

役割を使用するには、活動化されなければなりません。役割は、Tivoli Access

Manager アドミニストレーターが Tivoli Access Manager ネーム・スペースでその定義を使用可能にしたとき活動化されます。役割が活動化され、ユーザーが役割に割り当てられると、ユーザーは、オブジェクト 1 に許可 1、オブジェクト 2 に許可 2、3、および 4、オブジェクト 3 に許可 5 を持ちます。ユーザーは、これらのオブジェクトのアクセス許可を使用して、オブジェクトにアクセスし、したがって、役割により定義されたジョブの責任を果たすことができます。たとえば、会計係の役割は、以下のオブジェクトと許可の 2 つのペアから構成されるように定義することができます。

v 給与計算オブジェクト: 作成/変更/削除

v 清算要求オブジェクト: 承認

この役割が活動化され、会計部門の従業員がこの役割に割り当てられると、その従業員は給与計算書の作成、変更、または削除を行って、清算要求を承認し、したがって、会計係が実行するものと期待されるジョブをこなすことになります。

アドミニストレーターは、役割を正常に管理するには、以下の 3 タイプのタスクを実行できなければなりません。

v 役割の作成


v 役割の割り当て

v 役割の活動化

役割の作成では、役割が、Tivoli Access Manager オブジェクトとそのオブジェクトに適用できる許可の 1 つ以上のペアのリストを持つように定義されます。 Web

Portal Manager で役割が作成されると、その役割を表す Tivoli Access Manager グループが作成されます。管理オブジェクト・スペースの対応するグループ・オブジェクトも作成されます。役割のオブジェクト/許可ペア情報は、グループ・オブジェクトに関連する拡張属性に保管されます。役割を作成できるのは Tivoli Access

Manager アドミニストレーターのみです。

役割の割り当ては、すでに作成された役割へのユーザーの割り当てから構成されます。役割へのユーザーの割り当ての隠れた目的は、これらのユーザーに、役割で定義されたオブジェクトへのアクセス許可を持たせることです。この機能で、役割の割り当てがオブジェクト/アクセス許可管理から分離されるため、ユーザー・許可・オブジェクト関係の維持に関係するワークロードが削減されます。ユーザーは、Web Portal Manager の役割に割り当てられると、役割を表すグループのメンバーとして追加されます。ドメイン・アドミニストレーター、シニア・アドミニストレーター、およびドメインのアドミニストレーターは、そのドメインのユーザーを役割に割り当てることができます。

役割の活動化により、新しく作成された役割が機能するようになります。役割が作成され、その役割にユーザーが割り当てられても、そのユーザーには、役割が活動化されるまでは、役割で定義されたオブジェクトのアクセス許可はありません。役割が Web Portal Manager で活動化されると、役割を表すグループと役割で定義されたアクセス許可を含む ACL エントリーが、役割で定義されたオブジェクトごとに ACL に追加されます。ユーザーは、役割に割り当てられたときにはグループに追加されているので、役割が活動化さえすれば、オブジェクトへのアクセス許可があります。役割を活動化できるのは Tivoli Access Manager アドミニストレーターのみです。

役割は、代行および管理可能なエンティティーです。役割は、作成されると、エンタープライズ・ドメインに割り当てることができます。順番に、ドメイン・アドミニストレーターは、そのドメイン内のすべての役割を任意のサブドメインに割り当てることができます。役割がサブドメインに割り当てられると、そのサブドメインのアドミニストレーターは、任意のサブドメイン・ユーザーをその役割に割り当てることができます。役割をサブドメインに割り当てるこのプロセスは、役割が適切なユーザーに使用可能になるように、必要に応じて繰り返すことができます。エンタープライズ・ドメインに役割を割り当てることができるのは、Tivoli Access

Manager アドミニストレーターのみです。ドメイン・アドミニストレーターは、役割をそのサブドメインに割り当てることができます。

セルフケアのインプリメントWeb Portal Manager は、セルフケアをサポートします。ユーザーは、Web Portal

Manager 管理の代行ページを開いて、そのパスワードを管理できます。ログイン後、ユーザーは「パスワードの変更」タスクを開く必要があります。


自己登録のインプリメントWeb Portal Manager デプロイメントは、多くのユーザーをサポートするために、大きくすることができます。ユーザー数の増加とともに、これらのユーザーの管理に必要なアドミニストレーター数も増加します。自己登録およびセルフケアは、管理の負荷を減らすのに使用できる Web Portal Manager の機能です。 Web Portal

Manager には、自己登録ページをインプリメントするサンプル・コードが付いています。サンプル・コードには、Java 2 Platform、Enterprise Edition (J2EE) サーブレットおよび Java Server Pages (JSP) とともに、Tivoli Access Manager Java

Administration API を使用して自己登録をインプリメントする方法が記載されています。 Web Portal Manager は、Tivoli Access Manager ユーザーがその Tivoli Access

Manager パスワードを Web Portal Manager を介して変更できるようにして、セルフケア操作もサポートします。

自己登録のサンプルWeb Portal Manager には、エンド・ユーザーが自己登録できるサンプル・アプリケーションが付いています。自己登録は、ユーザーが、登録 Tivoli Access Manager

ユーザーになるのに必要なデータを、アドミニストレーターの関与なしに入力できるプロセスです。自己登録インプリメントで考えられるシナリオの 1 つは、ユーザーが Web ブラウザーを開いて、自己登録 Web ページを表示する場合です。このWeb ページで、ユーザーは Tivoli Access Manager ユーザー ID およびパスワードを用いて、特定の識別情報 (会社固有かユーザー固有の) を入力します。ユーザーが提供した識別情報は、ここで妥当性検査され、そのユーザーが Tivoli Access

Manager レジストリーに作成されます。

Tivoli Access Manager には、自己登録の作動方法を示す自己登録サンプルが付いています。このサンプルがサポートされるのは LDAP レジストリーの場合のみで、Domino または Active Directory ではサポートされないことに注意してください。

自己登録サンプルのプロセス通常ユーザーには Tivoli Access Manager でオブジェクトを作成する許可がないため、自己登録サンプルでは、ユーザーを作成する許可を持つアドミニストレーターの ID およびパスワードが必要です。次に、登録ページに必要な情報が入力されたときに、このログイン情報が使用されてユーザーを作成します。

初めて自己登録サンプルにアクセスしたとき、以下の情報が要求されます。このデータは、メモリーのサーブレットに保管されてから、登録を要求するユーザーの作成に使用されます。

v アドミニストレーター名

v パスワード

v レジストリー・コンテナー

アドミニストレーター名およびパスワードは、Tivoli Access Manager でユーザーを作成する許可を持つアドミニストレーターの名前でなければなりません。デフォルトでは sec_master アドミニストレーターに正規のアクセス権があります。「レジストリー・コンテナー (Registry Container)」フィールドは、ユーザー・エントリーが入るべき LDAP の基本名でなければなりません。この値は、自己登録ユーザーの識別名 (DN) を構成するのに使用します。


たとえば、o=ibm,c=us を入力すると、cn=FirstnameLastname,o=ibm,c=us のように、登録ユーザーが LDAP 内に作成されます。このユーザーは、グループには追加されません。実際のアプリケーションでは、おそらくユーザーは、何らかのアプリケーションにアクセスできる何らかのグループに追加されます。アドミニストレーター情報が入力されると、このページは二度と表示されません。サンプルにアクセスする場合、表示されるのは、姓名およびパスワードを入力できる登録ページのみです。

アドミニストレーターのログインは、サーブレット・セッションに保管されることに注意してください。同じブラウザーから自己登録サンプルにアクセスするユーザーは、いずれも Tivoli Access Manager にユーザーを作成できます。アプリケーション・サーバーを再始動して、アドミニストレーターのログイン情報をクリアする必要があります。

このサンプルでは、ID とパスワードの保管は安全ではありません。このサンプルを実動登録アプリケーションの基本として使用する場合は、アドミニストレーターのログイン情報を保護する方法を考える必要があります。

自己登録サンプルの Java Server Pagesサンプル・アプリケーションには、以下の 3 つの JSP ページがあります。

v regAdmin.jsp は、アドミニストレーターのログイン情報を集めるときに表示されるページです。

v regProp.jsp は、ユーザーの姓名およびパスワードを集めるときに表示されます。

v regControl.jsp には、ユーザーを作成するコードが入っています。このページは、登録要求を受け取り、処理します。これは、サーブレット・クラスである場合もあります。

このファイルは、以下のディレクトリーにインストールされます。

WASdir/installedApplications/pdwpm.ear/pdwpm_sampleReg.war/register

ここで WASdir は、WebSphere がインストールされるディレクトリーです。

アドミニストレーター・ログイン情報が入力されると、JRTE PDContext が作成され、以下に示すようにユーザー・サーブレット・セッションに保管されます。

String adminid = request.getParameter("admin");String adminPassword = request.getParameter("password");String ldapSuffix = request.getParameter("suffix");

...// Try a login

try {ctx = new PDContext(adminid,

adminPassword.toCharArray(),url);

// Save the PDcontext and the LDAP Suffixsession.setAttribute("regAdminCtx", ctx);session.setAttribute("ldapSuffix", ldapSuffix);

} catch(PDException e) {// process exception...

}


ユーザーが新規ユーザー情報を入力すると、以下に示すように、PDContext がセッションから検索され、新規ユーザーの作成に使用されます。

// Creating the PD Userpwd = request.getParameter("password");ldapcn = request.getParameter("ldapcn");ldapsn = request.getParameter("ldapsn");ldapdn = "cn=" + ldapcn + ldapsn + "," + ldapSuffix;userid = ldapcn + ldapsn;desc = ldapcn + " " + ldapsn;

ctx = (PDContext)session.getAttribute("regAdminCtx");

// Make sure the session has not timed outif ( ctx == null ) {

%><%@ include file="regAdmin.jsp" %>

<% return;}

PDMessages messages = new PDMessages();try {

createUser(bundle, ctx, userid, pwd, desc, ldapcn,ldapsn, ldapdn, usergroups, acc_valid,pwd_valid, gso_user, no_pwd_pol,messages);

succmsg = userid +ResourceFile.getString(bundle,

"userRegisteredMsg");

} catch(PDException e) {// process exception...

}

新規ユーザーの ID は、姓名を連結したものです。

自己登録サンプルへのアクセス自己登録サンプルへは、以下の URL からアクセスできます。

https://hostname/register

ここで hostname は、IBM HTTP Server および WebSphere を実行するマシンです。


第 5 章オブジェクト・スペース管理

Tivoli Access Manager は、オブジェクト・スペースまたは保護オブジェクト・スペースと呼ばれる仮想表現を使用して、保護されるリソースを表現します。オブジェクト・スペースは、リソース・オブジェクトおよびコンテナー・オブジェクトにより構成されています。リソース・オブジェクトは、保護されるリソースの論理表現です。コンテナー・オブジェクトにより、リソース・オブジェクトおよびその他のコンテナー・オブジェクトを論理グループまたは論理領域に階層的にグループ化できます。類似するオブジェクトをグループ化することにより、一環したセキュリティー・ポリシーの管理が容易になります。

セキュリティー・ポリシーを適用するには、アクセス・コントロール・リスト(ACL) および保護オブジェクト・ポリシー (POP) を、保護する物理リソースを表現するオブジェクト・スペースに付加します。 Tivoli Access Manager 許可サービスは、ユーザー信任状、およびセキュリティー・ポリシーにより指定された条件に基づいて、リソースへのアクセスの許可または拒否の決定を行います。

Tivoli Access Manager セキュリティー・モデルは、ACL および POP に従って、これらのリソースにきめ細かい保護を提供します。企業向けのセキュリティー・ポリシーは、保護を必要とするそれらのリソースにカスタム ACL および POP ポリシーを戦略的に適用することによってインプリメントされます。 Tivoli Access

Manager 許可サービスは、ユーザー信任状、および ACL および POP ポリシーに設定された特定の許可および条件に基づいて、リソースへのアクセスの許可または拒否の決定を行います。

ACL および POP ポリシーを適用し、許可サービスがそのセキュリティー検査を実行できるようにするために、Tivoli Access Manager は、保護オブジェクト・スペースというドメイン・リソースの仮想オブジェクト表現を使用します。

ドメイン・アドミニストレーターとして、Web Portal Manager または pdadmin コマンド行ユーティリティーを使用して、オブジェクト・スペースのオブジェクトにACL または POP を付加できます。

オブジェクト・スペースの作成Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してオブジェクト・スペースを作成するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してオブジェクト・スペースを作成するには、次のようにします。


2. 「オブジェクト・スペース (Object Space)」→「オブジェクト・スペースの作成(Create Object Space)」をクリックする。

3. 「パス (Path)」を入力します。これは必須のフィールドです。

4. 「説明 (Description)」を入力します。


5. 「作成 (Create)」をクリックします。

pdadminpdadmin ユーティリティーを使用してドメイン内にオブジェクト・スペースを作成するには、ドメインにログインして、pdadmin objectspace create コマンドを使用します。たとえば、アプリケーション・コンテナー・オブジェクトである/Test-Space というオブジェクト・スペースを作成するには、次のように入力します。

pdadmin objectspace create /Test-Space "New Object Space" 14

上記の例の 14 のように、type は次のカテゴリーのうちの 1 つにすることができます。

オブジェクト・タイプ

0 - 不明1 - セキュア・ドメイン2 - ファイル3 - 実行可能プログラム4 - ディレクトリー5 - junction

6 - WebSEAL サーバー7 - 未使用8 - 未使用

9 - HTTP サーバー10 - 非存在オブジェクト11 - コンテナー・オブジェクト12 - リーフ・オブジェクト13 - ポート14 - アプリケーション・コンテナー・オブジェクト15 - アプリケーション・リーフ・オブジェクト16 - 管理オブジェクト17 - 未使用

注: Tivoli Access Manager またはブレードの 1 つにより作成されたオブジェクト・スペースで、pdadmin objectspace コマンドを使用しないでください。これらのオブジェクト・スペースには、/Management、/WebSEAL、/OSSEAL、および/PDMQ があります。

詳細については IBM Tivoli Access Manager コマンド・リファレンスを参照してください。

オブジェクト・スペースのリストWeb Portal Manager またはpdadmin コマンド行ユーティリティーを使用して、すべてのオブジェクト・スペースをリストするには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してすべてのオブジェクト・スペースをリストするには、次のようにします。


2. 「オブジェクト・スペース (Object Space)」→「参照 (Browse)」をクリックする。

3. 「オブジェクト・スペースの参照 (Browse Object Space)」ウィンドウに、ドメイン内のすべてのオブジェクト・スペースが表示されます。


pdadminpdadmin ユーティリティーを使用してドメイン内のすべてのオブジェクト・スペースをリストするには、ドメインにログインして pdadmin objectspace list コマンドを使用します。

pdadmin objectspace list


オブジェクト・スペースの削除Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してオブジェクト・スペースを削除するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してオブジェクト・スペースを削除するには、次のようにします。



3. 「オブジェクト・スペースの参照 (Browse Object Space)」ウィンドウから適切なオブジェクトを選択する。

4. 「保護オブジェクトのプロパティー (Protected Object Properties)」ウィンドウで、「オブジェクト名 (Object Name)」フィールドを見て、削除したいオブジェクト・スペースを確認する。

5. 「削除 (Delete)」をクリックする。「OK」をクリックして削除を確認します。正常に削除された場合、正常にオブジェクトが削除されたというメッセージが表示されます。

pdadminpdadmin ユーティリティーを使用してドメイン内のオブジェクト・スペースを削除するには、ドメインにログインして、pdadmin objectspace delete コマンドを使用します。たとえば /Test-Space というオブジェクト・スペースを削除するには、次のように入力します。

pdadmin objectspace delete /Test-Space


第 5 章オブジェクト・スペース管理 63

第 6 章ユーザーとグループの管理

新規にドメインが作成される際、初期のドメイン・アドミニストレーターが作成されます。ドメイン・アドミニストレーターは、最初にドメインを管理するのに必要な権限を持っています。ドメイン・アドミニストレーターは、ユーザー、グループ、リソース、アプリケーションの作成と構成、および必要に応じてドメイン内の管理タスクの代行のために使用できます。

ユーザーの追加Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してユーザーを追加するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

注: 管理ドメイン・アドミニストレーターは、DN (識別名) およびレジストリーUID に固有のストリングを割り当てます。ドメイン・アドミニストレーターは、ユーザーの追加およびインポートの際にこのストリングを指定する必要があります。このストリングは、pdadmin ユーティリティーを使用する場合はDN に、Web Portal Manager を使用する場合はレジストリー UID に追加されます。

Web Portal ManagerWeb Portal Manager を使用してユーザーをドメインに追加する方法は、以下のとおりです。


2. 「ユーザー (User)」→「作成 (Create) 」をクリックする。

3. 「ユーザー ID (User ID)」を入力する (例: user1)。このフィールドは必須です。

4. 「パスワード (Password)」を入力する。パスワードは、ドメイン・アドミニストレーターが設定するパスワード・ポリシーに従う必要があります。このフィールドは必須です。

5. パスワードを再度入力して確認する。このフィールドは必須です。

6. ユーザー ID の「説明 (Description)」を入力する (例: tester)。

7. ユーザーの「名 (Given Name)」を入力する。このフィールドは必須です。

8. ユーザーの「姓 (Family Name)」を入力する。このフィールドは必須です。

9. 「レジストリー UID (Registry UID)」を入力する。これは、新規ユーザーが作成されたレジストリー・データベース内の場所を指定します。作成されたユーザーの絶対パス名を入力します。パス・フォーマットは、Tivoli Access

Manager が使用しているレジストリーのタイプにより異なります。

10. 「有効なアカウントである (Is Account Valid)」をクリックして、新規ユーザーがドメインに参加する資格があることを示す。このオプションが選択されていない場合、新規ユーザーは有効とならず、ログインできません。


11. 「GSO ユーザーである (Is GSO User)」をクリックして、このユーザーがTivoli Access Manager のグローバル・サインオン機能を使用できることを示す。

12. 「有効なパスワードである (Is Password Valid)」をクリックして、ユーザーが次回ドメインにログインしたときにパスワードを強制的に変更する。このオプションが選択されていない場合、ユーザーはパスワードの有効期限が切れていると通知されます。

13. 「パスワード・ポリシーなし (No Password Policy)」をクリックして、ドメイン・アドミニストレーターが設定したパスワード・ポリシーに従うための初期パスワードを必要としないことを示す。

14. 「グループ・メンバーシップ (Group Membership)」を選択して、ユーザーID を特定のグループ (例: iv-admin) と関連付ける。グループを入力し、「Add (追加)」をクリックします。グループ名を検索するには、「リスト(List)」をクリックします。選択したグループをリストから削除するには、「除去 (Remove)」をクリックします。

15. 「作成 (Create)」をクリックする。ユーザー ID が正常に作成された場合、パスワード・フィールドを除くすべてのフィールドが表示されたフレームにメッセージが表示されます。

pdadminpdadmin ユーティリティーを使用してユーザーをドメインに追加するには、ドメインにドメイン・アドミニストレーターとしてログインし、pdadmin user create コマンドを使用します。たとえば、グローバル・サインオン能力を持つ maryj というユーザーを追加するには、次のように入力します。

pdadmin user create -gsouser maryj "cn=Mary Jones,o=tivoli,c=us,dc=mkt""cn=Mary" "sn=Jones" pwd2pwd2


ユーザーのインポートドメイン・アドミニストレーターは、既存のユーザー情報をユーザー・レジストリーから新規ドメインにインポートすることもできます。

pdadmin ユーティリティーを使用して、ユーザー情報を既存のユーザー・レジストリーからドメインにインポートするには、ドメインにドメイン・アドミニストレーターとしてログインし、pdadmin user import コマンドを使用します。たとえば、既存のユーザー・レジストリー定義から maryj というユーザーのユーザー情報をインポートするには、次のように入力します。

pdadmin user import -gsouser maryj "cn=Mary Jones,o=tivoli,c=us,dc=mkt"

注: ドメインにインポートされたユーザー情報は、再度別のドメインにインポートできます。



グループの追加Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してグループを追加するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

注: 管理ドメイン・アドミニストレーターは、DN (識別名) およびレジストリーUID に固有のストリングを割り当てます。ドメイン・アドミニストレーターは、グループの追加およびインポートの際にこのストリングを指定する必要があります。このストリングは、pdadmin ユーティリティーを使用して DN

に、Web Portal Manager を使用してレジストリー UID に追加されます。

Web Portal ManagerWeb Portal Manager を使用してグループをドメインに追加する方法は、以下のとおりです。


2. 「グループ (Group)」→「作成 (Create)」をクリックする。

3. グループの「名前 (Name)」を入力する。このフィールドは必須です。

4. グループの「説明 (Description)」を入力する。

5. グループの「グループ名 (Group Name)」を入力する。

6. 「レジストリー UID (Registry UID)」を入力する。これは、新規グループが作成されたレジストリー・データベース内の場所を指定します。作成されたグループの絶対パス名を入力します。パス・フォーマットは、Tivoli Access Manager

が使用しているレジストリーのタイプにより異なります。このフィールドは必須です。

7. オプションとして、「オブジェクト・コンテナー (Object Container)」フィールドに、グループが作成される Tivoli Access Manager オブジェクト・スペースへのパスを入力することもできる。

8. 「作成 (Create)」をクリックする。新規グループは、リンクとして表示されます。リンクを選択すると、新規グループのプロパティーが表示されます。

pdadminpdadmin ユーティリティーを使用してグループをドメインに追加する場合、ドメインにドメイン・アドミニストレーターとしてログインし、pdadmin group createコマンドを使用して、新規グループを作成し、オプションとしてこのグループをグループ・コンテナー・オブジェクトに配置します。既存のコンテナー・オブジェクトがなければ、自動的に作成されます。たとえば、sales というグループを追加するには、次のように入力します。

pdadmin group create sales "cn=sales,o=tivoli,c=us,dc=mkt" Sales


グループのインポートドメイン・アドミニストレーターは、レジストリーから既存のグループ情報をドメインにインポートすることもできます。

第 6 章ユーザーとグループの管理 67

pdadmin ユーティリティーを使用して既存のレジストリーからグループ情報をドメインにインポートするには、ドメインにログインし、pdadmin group import コマンドを使用します。たとえば、既存のユーザー・レジストリーから sales というグループのグループ情報をインポートする場合、次のように入力します。

pdadmin group import sales "cn=sales,o=tivoli,c=us,dc=mkt"

注: ドメインにインポートされたグループ情報は、再度別のドメインにインポートできます。


グループの詳細については 125ページの『グループの作成』を参照してください。


第 7 章保護オブジェクトの管理

保護オブジェクトは、アクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー (POP) を適用してユーザー・アクセスを許可するために使用される、実際のシステム・リソースの論理表現です。

ドメイン・アドミニストレーターとして、Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してオブジェクトを作成および削除できます。

オブジェクト・スペースを作成すると、ただちにそれにオブジェクトを取り込むことができます。

オブジェクト・スペースの作成について詳しくは、 61ページの『オブジェクト・スペースの作成』を参照してください。

オブジェクトの作成Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してオブジェクトを作成するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用して新規オブジェクトを作成するには、次のようにします。


2. 「オブジェクト・スペース (Object Space)」→「オブジェクトの作成 (CreateObject)」をクリックする。

3. オブジェクトの絶対パスを入力する。(例: /Management/Groups/new_group_dir)

これは必須のフィールドです。

4. 「作成 (Create)」をクリックする。

pdadminpdadmin ユーティリティーを使用してドメイン内にオブジェクトを作成するには、ドメインにログインして pdadmin object create コマンドを使用します。たとえば、アプリケーション・コンテナー・オブジェクトの /Management/test-object というオブジェクトを作成するには、次のように入力します。

pdadmin object create /Management/test-object “Test Object” 14ispolicyattachable yes


type は、次のカテゴリーのうちの 1 つにすることができます。



6 - WebSEAL サーバー7 - 未使用8 - 未使用

9 - HTTP サーバー10 - 非存在オブジェクト11 - コンテナー・オブジェクト12 - リーフ・オブジェクト13 - ポート14 - アプリケーション・コンテナー・オブジェクト15 - アプリケーション・リーフ・オブジェクト16 - 管理オブジェクト17 - 未使用

オブジェクトの作成時には、タイプを指定する必要があります。オブジェクト・タイプを指定し、それに意味を割り当てるには、適切なカテゴリーを選択することも、任意の番号を使用することもできます。

ispolicyattachable フィールドが pdadmin object create コマンドで省略される場合、ユーティリティーは、ユーザーが objectspace create コマンドを使用すると想定します。オブジェクトではなく、オブジェクト・スペースが作成されます。


オブジェクトのリストWeb Portal Manager または pdadmin コマンド行ユーティリティーを使用してすべてのオブジェクトをリストするには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb ポータル・マネージャー (WPM) を使用してすべてのオブジェクトをリストするには、次のようにします。



3. 「オブジェクト・スペースの参照 (Browse Object Space)」ウィンドウに、ドメイン内のすべてのオブジェクト・スペースが表示されます。

pdadminpdadmin ユーティリティーを使用してドメイン内のすべてのオブジェクトをリストするには、ドメインにログインして、pdadmin object list コマンドを使用します。たとえば、/Management/test-object というオブジェクトのオブジェクト属性をリストするには、次のように入力します。

pdadmin object list /Management/test-object



オブジェクトの削除Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してオブジェクトを削除するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb ポータル・マネージャー (WPM) を使用してオブジェクトを削除するには、次のようにします。



3. 「オブジェクト・スペースの参照 (Browser Object Space)」ウィンドウから希望のオブジェクトを選択する。

4. 「削除 (Delete)」をクリックする。

pdadminpdadmin ユーティリティーを使用してドメイン内のオブジェクトを削除するには、ドメインにログインして pdadmin object delete コマンドを使用します。たとえば、/Management/test-object というオブジェクトを削除するには、次のように入力します。

pdadmin object delete /Management/test-object


第 7 章保護オブジェクトの管理 71

第 8 章アクセス・コントロール・リストの管理

アクセス・コントロール・リスト (ACL) ポリシーを使用してドメイン・リソースへのアクセスを制御できます。pdadmin コマンド行ユーティリティーまたは Web

Portal Manager を使用して、ドメイン・アドミニストレーターは、ACL エントリーで構成されている ACL ポリシーを作成して、アドミニストレーターのドメインで定義されているリソースを保護できます。また、ドメイン・アドミニストレーターは、ドメイン・アドミニストレーターの ACL エントリーとマッチングするように別のユーザーの ACL を設定することにより、ユーザーが管理権限を持つように選択できます。こうすると、そのユーザーはアドミニストレーターと同じ権限を持つことになります。

ACL ポリシーACL ポリシーは、次に述べる 1 つ以上のエントリーから構成されます。

v オブジェクトへのアクセスが明示的に制御されるような、ユーザーおよびグループの名前

v 各ユーザー、グループ、または役割に許可されている特定の操作

v 特殊な any-other (任意認証) および unauthenticated (非認証) ユーザー・カテゴリーに許可された特定の操作

user (ユーザー) は認証済み Tivoli Access Manager ID を表します。通常、ユーザーとは、ネットワーク・ユーザーまたはアプリケーション・サーバーを表しています。

group (グループ) とは、 1 人以上のユーザーの集まりです。ネットワーク管理者は、グループ ACL エントリーを使用して、同じ許可を簡単に複数のユーザーに割り当てることができます。ドメインへの新しいユーザーは、該当するグループのメンバーになることによって、オブジェクトへのアクセスを獲得します。これで、新しいユーザーごとに新しい ACL エントリーを作成する必要がなくなります。グループは、ドメイン内における組織上の部や課を表すことができます。グループはまた、役割や機能的な関連性を定義する際にも役立ちます。

ユーザーおよびグループを総称してエンティティーと呼びます。

ACL にユーザーおよびグループのエントリーを保管するために、universally unique

identifier (UUID) を使用します。UUID では、ユーザーまたはグループがドメインから削除された後で、同じ名前で再作成された場合のセキュリティーがさらに提供されます。たとえば、新規ユーザーの名前が削除されたユーザーと同じであっても、Tivoli Access Manager はこのユーザーに新しい UUID を割り振ります。UUID が新しいため、古いユーザー名を参照する既存の ACL が、新しいユーザーに権限を付与することはありません。 ACL 内の失効した UUID (削除されたユーザーおよびグループからの) は、ポリシー・サーバー (pdmgrd) によって暗黙のうちに除去されます。


ACL エントリーを作成、変更、削除するには、pdadmin コマンド行ユーティリティーまたは Web Portal Manager を使用できます。

ACL エントリーの構文ACL エントリーには、ACL エントリーのタイプに応じて 2 つまたは 3 つの属性が含まれており、次のような形式で表されます。

v タイプ - ACL が作成されたエンティティーのカテゴリー (ユーザーまたはグループ)。

v ID (識別) - エンティティーの固有の ID (名前)。

ID 属性は、any-other (任意認証) および unauthenticated (非認証) ACL エントリー・タイプには不要です。

v 許可 (またはアクション) - オブジェクトに対して、ユーザーまたはグループによる実行が許可されている操作のセット。

ほとんどの許可では、リソースに対して特定の操作を実行するクライアントの機能を記述します。

上記の例では、ユーザー adam (タイプ = user、ID = adam) は、この ACL ポリシーによって保護されているオブジェクトを読み取る (表示する) 許可があります。読み取り「(r)」許可では、読み取り操作が可能です。全探索「(T)」許可では全探索ルールを適用します。

タイプ属性ACL エントリー・タイプでは、特定の ACL エントリーのユーザー、グループ、または特別なエンティティーを識別します。以下の 4 つの ACL エントリー・タイプがあります。

図 18. Web ページ・オブジェクトのアクセス・コントロール・リスト

図 19. ACL エントリーの属性


タイプ説明

user (ユーザー) ドメインの特定のユーザーに許可を設定します。このユーザーは、レジストリー中にアカウントを持つドメインのメンバーでなければなりません。ユーザーのエントリー・タイプには、ユーザー名 (ID) が必要です。エントリーの形式は、 user ID permissions

です。

例:

user anthony -------T-----r-

group (グループ) ドメインにある特定グループのすべてのメンバーに許可を設定します。グループのエントリー・タイプには、グループ名 (ID) が必要です。エントリーの形式は group ID

permissions です。

例:

group engineering -------T-----r-

any-other (任意認証)(any-authenticated

(全認証) ともいいます)

すべての認証ユーザーに許可を設定します。 ID の指定は、不要です。エントリーの形式は any-other permissions です。

例:

any-other -------T-----r-

unauthenticated ポリシー・サーバーで認証されていないユーザーに許可を設定します。ID の指定は、不要です。エントリーの形式は unauthenticated permissions です。

例:

unauthenticated -------T-----r-

この ACL エントリーは、許可セットを決定するための any-other (任意認証) ACL エントリーに対するマスク (ビット単位の「AND」演算) です。 unauthenticated (非認証) に対する許可は、許可が any-other (任意認証) エントリーの中にも出てくるときだけ、付与されます。たとえば、次の unauthenticated (非認証) ACL エントリーを、

unauthenticated -------------rw

次の any-other (任意認証) ACL エントリーに対してマスクをかけると、

any-other -------T-----r-

その結果、以下のような許可になります。

-------------r- (read only).

ID 属性ACL エントリー ID は、ユーザーまたはグループのエントリー・タイプの固有のID、つまり名前です。 ID は、ドメイン内で作成された有効なユーザーまたはグループ、もしくはその両方を表している必要があります。

例 :

user michael

user anthony

group engineering

第 8 章アクセス・コントロール・リストの管理 75

group documentation

group accounting

注: ID 属性は、any-other (任意認証) および unauthenticated (非認証) ACL エントリー・タイプには使用されません。

許可 (アクション) 属性ACL エントリーごとに、ユーザーまたはグループによってオブジェクトに許可されている特定の操作を記述する許可 (またはアクション) セットが入っています。

ACL ポリシーは、次の方法で保護リソースを制御します。

v 保護オブジェクトに対して操作を実行するユーザーの能力

v オブジェクトおよび任意のサブオブジェクトに関するアクセス・コントロール・ルールを変更する、アドミニストレーターの能力

v ユーザーの信任状を代行する Tivoli Access Manager の能力

注: ACL 許可はコンテキストに依存しています。つまり特定の許可の動作の変化は、許可が適用される保護オブジェクト・スペースの領域に応じて起こります。たとえば、変更「 m)」許可は、WebSEAL オブジェクトと管理オブジェクトで、意味が異なります。

デフォルトの Tivoli Access Manager 許可 (アクション)Tivoli Access Manager は、17 のデフォルト許可 (アクション) を定義します。Web Portal Manager では、これらの許可が以下の 3 つのカテゴリーに分けられています。

基本汎用的アプリケーションa A b B c g N t T W d m s v l r x

アクション・ビット説明カテゴリー

a 付加基本

A 追加基本

b ブラウズ基本

B 保護オブジェクト・ポリシー(POP) のバイパス

基本

c コントロール基本

d 削除汎用的

g 代行基本

l ディレクトリーのリストアプリケーション

m 変更汎用的

N 作成基本

r 読み取りアプリケーション

s サーバー管理汎用的

t トレース基本


アクション・ビット説明カテゴリー

T 全探索基本

v 表示汎用的

W パスワード基本

x 実行アプリケーション

Tivoli Access Manager は、アプリケーションが使用する、多くの追加のアクション、または許可を定義する機能を備えています。詳細については 83ページの『アクション・グループの管理』を参照してください。

アクセス・コントロール・リストの管理ACL は、POP ポリシーと同じような方法で操作します。ACL を作成・構成し、その後、保護オブジェクト・スペースのオブジェクトに ACL を付加します。

ACL ポリシーは、POP ポリシーと同じ方法で継承されます。ACL ポリシーおよびPOP ポリシーはともに、ポリシー・サーバーが制御するマスター許可データベースにドメインごとに入れられます。

次の ACL タスクを実行できます。

v 『ACL の作成』

v 78ページの『ACL のリスト』

v 78ページの『ACL の削除』

v 79ページの『ACL の変更と表示』

v 79ページの『保護オブジェクト・タイプへの ACL 属性の適用』

– 79ページの『ACL のオブジェクトへの付加』

– 80ページの『ACL の付加先の検索』

– 80ページの『ACL の切り離し』

ACL の作成Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してACL を作成するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用して ACL を作成するには、次のようにします。


2. 「ACL」→「ACL の作成 (Create ACL)」をクリックする。

3. 「新しい ACL 名 (New ACL Name)」を入力する。このフィールドは必須です。

4. ACL の「説明 (Description)」を入力する。

5. 「作成 (Create)」をクリックする。正常に作成された場合、ACL のプロパティーが表示されます。


pdadminpdadmin ユーティリティーを使用してドメインに新規 ACL を作成するには、ドメインにログインして pdadmin acl create コマンドを使用します。たとえば、Test-ACL という ACL を作成するには、次のように入力します。

pdadmin acl create Test-ACL


ACL のリストWeb Portal Manager または pdadmin コマンド行ユーティリティーを使用してすべての ACL をリストするには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してドメイン内のすべての ACL をリストするには、次のようにします。


2. 「ACL」→「ACL のリスト (List ACL)」をクリックする。

3. ACL List ウィンドウに、ドメイン内のすべての ACL が表示される。

pdadminpdadmin ユーティリティーを使用してドメイン内のすべての ACL をリストするには、ドメインにログインで pdadmin acl list コマンドを使用します。

pdadmin acl list


ACL の削除Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してACL を削除するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用して ACL を削除するには、次のようにします。


2. 「ACL」 → 「ACL のリスト (List ACL)」をクリックする。

3. 「ACL リスト (ACL List)」ウィンドウから適切な ACL を選択する。

4. 「削除 (Delete)」をクリックする。

pdadminpdadmin ユーティリティーを使用してドメイン内の ACL を削除するには、ドメインにログインして pdadmin acl delete コマンドを使用します。たとえば、Test-ACL という ACL を削除するには、次のように入力します。

pdadmin acl delete Test-ACL



ACL の変更と表示Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してACL を変更するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用して ACL を変更するには、次のようにします。


2. 「ACL」 → 「ACL のリスト (List ACL)」をクリックする。

3. 「ACL のリスト (ACL List)」ウィンドウから適切な ACL を選択する。

4. 「ACL エントリー・プロパティー (ACL Entry Properties)」ウィンドウからACL の適切な情報に変更を加える。

5. 「変更 (Modify)」をクリックする。

pdadminpdadmin ユーティリティーを使用してドメイン内の ACL エントリーを変更するには、ドメインにログインして pdadmin acl modify コマンドを使用します。たとえば、maryj というユーザーが「r (読み取り)」許可を持つように Test-ACL という ACL を変更するには、次のように入力します。

pdadmin acl modify Test-ACL set user "domain_administrator maryj" r

ACL への変更を表示するには、pdadmin acl show コマンドを使用します。

pdadmin acl show Test-ACLACL Name: Test-ACLDescription:Entries:

User domain_administrator maryj r


保護オブジェクト・タイプへの ACL 属性の適用ACL ポリシーは、POP ポリシーと同じ方法でオブジェクトに適用されます。

ACL のオブジェクトへの付加Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してACL を保護オブジェクトに付加するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal Manager: Web Portal Manager を使用して ACL を保護オブジェクトに付加するには、次のようにします。


2. ACL → List ACL をクリックする。

3. ACL List ウィンドウから適切な ACL を選択する。

4. ACL Entry Properties ウィンドウから Attach を選択する。


5. オブジェクトの絶対パスを入力する。たとえば、/WebSEAL/WS1/JCT1。このフィールドは必須です。

6. Attach をクリックする。

pdadmin: pdadmin ユーティリティーを使用して ACL を保護オブジェクトに付加するには、ドメインにログインして、pdadmin acl attach コマンドを使用します。たとえば、Test-ACL という ACL を /Management/test-object という保護オブジェクトに付加するには、次のように入力します。

pdadmin acl attach /Management/test-object Test-ACL


ACL の付加先の検索Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してACL の付加先を検索するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal Manager: Web Portal Manager を使用して ACL の付加先を検索するには、次のようにします。


2. ACL → List ACL をクリックする。

3. ACL List ウィンドウから適切な ACL を選択する。

4. ACL Entry Properties ウィンドウから Find を検索して、ACL が付加されているすべてのオブジェクトを表示する。

pdadmin: pdadmin ユーティリティーを使用して ACL の付加先を検索するには、ドメインにログインしてpdadmin acl find コマンドを使用します。たとえば、Test-ACL という ACL の付加先を検索するには、次のように入力します。

pdadmin acl find Test-ACL


ACL の切り離しWeb Portal Manager または pdadmin コマンド行ユーティリティーを使用してACL をオブジェクトから切り離すには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal Manager: Web Portal Manager を使用して ACL を保護オブジェクトから切り離すには、次のようにします。




4. 「付加された ACL (Attached ACL)」フィールドから「リスト (List)」をクリックして ACL をリストする。


5. ACL リストから適切な ACL を選択して「適用 (Apply)」をクリックする。この ACL は、「付加された ACL (Attached ACL)」フィールドにリストされます。

6. 「付加された ACL (Attached ACL)」フィールドから「切り離し (Detach)」をクリックする。

pdadmin: pdadmin ユーティリティーを使用して ACL を保護オブジェクトから切り離すには、ドメインにログインして pdadmin acl detach コマンドを使用します。たとえば、ACL を /Management/test-object という保護オブジェクトから切り離すには、次のように入力します。

pdadmin acl detach /Management/test-object


ACL エントリーの例ユーザーは、適切な ACL エントリー・タイプを指定することによって、特定のユーザー、およびグループに対して許可を設定します。以下の例で、グループdocumentation は、全アクセス権を持っています。

group documentation --bcg--Tdmsv--lrx

any-other (任意認証) エントリー・タイプを使用して、ドメインにある他の認証ユーザー (documentation グループに属さない) へのアクセスを制限することができます。

any-other -------T-------rx

ドメインのメンバーでないユーザーの unauthenticated (非認証) エントリー・タイプへのアクセスをさらに制限することができます。

unauthenticated -------T-------r-

注: unauthenticated (非認証) ACL エントリーがないと、非認証ユーザーは、ドメインの中のどのセキュア・ドキュメントもアクセスできません。

ACL ポリシーおよび保護オブジェクト・スペースコンテナー・オブジェクトは、保護オブジェクト・スペースの特定の領域を表すもので、2 つの重要なセキュリティー機能を行います。

v 明示的に他の ACL が適用されないときに、その領域内のすべてのサブオブジェクトに高レベルのポリシーを定義するときは、コンテナー・オブジェクトの ACL

を使用できます。

v コンテナー・オブジェクトの ACL から全探索許可を除去することによって、この領域にあるすべてのオブジェクトへのアクセスを即座に拒否することができます。

ルート ( / ) コンテナー・オブジェクト以下のセキュリティー上の考慮事項はルート・オブジェクトに適用されます。


v ルート・オブジェクトは、保護オブジェクト・スペース全体の ACL 継承のチェーンの始まりです。

v ほかに ACL を明示的に適用しない場合、ルート・オブジェクトは、オブジェクト・スペース全体のこのセキュリティー・ポリシーを定義します (継承によって)。

v ルートの下位にあるオブジェクトにアクセスするには全探索 (T) 許可が必要です。

全探索許可全探索許可は、保護オブジェクト・スペース全体に適用される汎用の許可です。

操作説明

T 全探索コンテナー・オブジェクトに適用された場合、リクエスターが、要求されたリソース・オブジェクトへの途中にあるコンテナー・オブジェクトを階層的にパススルーできるようにします。そのコンテナー・オブジェクトに対する他のタイプのアクセスは許されません。全探索は、要求されたリソース・オブジェクト自体には必要ありません。

オブジェクトおよびオブジェクト・スペース許可下表にリストされているコマンドを使用して、管理ユーザーは新規オブジェクトおよびオブジェクト・スペースを管理できます。アクション・タスクおよび関連する許可には、以下のものが含まれます。

操作説明

b ブラウズ objectspace listobject list

object listandshow

(additionally requires v)

d 削除 objectspace deleteobject delete

object modify set name

(additionally requires m)

m 変更 objectspace createobject createobject modify

v 表示 object show

object listandshow

(additionally requires b)


アクション・グループの管理アクションは、Tivoli Access Manager により保護されているリソースで特定の操作を実行するための許可を与えるために使用されます。 76ページの『デフォルトのTivoli Access Manager 許可 (アクション)』で説明されているように、17 のアクションが即時に使用できるように事前定義されています。Tivoli Access Manager は、アプリケーション特有のアクションを作成する機能を提供します。たとえば、Tivoli

Access Manager for Business Integration は、Enqueue および Dequeue アクションを定義して、メッセージをメッセージ・キューに書き込む、またはキューからメッセージを外すための許可を与えます。

アクション・グループこのセクションでは、カスタム・アクションの拡張セット用のコンテナーとしての役割を果たす、アクション・グループを作成する方法について説明します。

v 各アクション・グループは最大 32 アクション・ビットを保持できます。

v アクション・ビットは、文字 a～z、A～Z で構成されます。

v 各アクション・ビット文字は、アクション・グループ内で一度しか使用できません。

v ほかのアクション・グループで同じアクション・ビットを再利用できます。

v 図 20 に示されているように、デフォルトの Tivoli Access Manager アクションは、「1 次」と呼ばれる、最初に事前定義されたアクション・グループに保管されます。

Tivoli Access Manager は、合計 1024 の個々のアクション用の、合計 32 のアクション・グループ (1 次アクション・グループを含む) をサポートします。

図 20. 1 次アクション・グループ


新しいアクション・グループの作成Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してアクション・グループを作成するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してアクション・グループを作成するには、次のようにします。


2. 「ACL」→「アクション・グループの作成 (Create Action Groups)] をクリックする。

3. 適切なグループを選択する。

4. 「アクション・グループ名 (Action Group Name)」を入力する。このフィールドは必須です。

「作成 (Create)」をクリックする。アクション・グループが正常に作成されると、メッセージが表示されます。

pdadminpdadmin ユーティリティーを使用してアクション・グループを作成するには、ドメインにログインして pdadmin action group create コマンドを使用します。たとえば、test-group という新しいアクション・グループを作成するには、次のように入力します。

pdadmin action group create test-group

デフォルトの 1 次アクション・グループは、常にグループ・リストに表示され、削除できません。

アクション・グループを作成するには変更 (m) 許可、アクション・グループを削除するには削除 (d) 許可を持つエントリーが /Management/ACL オブジェクトの ACL

に必要です。


図 21. 複数のアクション・グループ


アクション・グループのリストWeb Portal Manager または pdadmin コマンド行ユーティリティーを使用してすべてのアクション・グループをリストするには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してすべてのアクション・グループをリストするには、次のようにします。


2. 「ACL」→「アクション・グループのリスト (List Action Groups)」をクリックする。

3. 「アクション・グループのリスト (List Action Groups)」ウィンドウに、ドメイン内のすべてのアクション・グループが表示される。

pdadminpdadmin ユーティリティーを使用してドメイン内のすべてのアクション・グループをリストするには、ドメインにログインして pdadmin action group list コマンドを使用します。

pdadmin action group list


アクション・グループの削除Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してアクション・グループを削除するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してアクション・グループを削除するには、次のようにします。



3. 「アクション・グループのリスト (List Action Groups)」ウィンドウから適切なアクション・グループを選択する。

4. 「削除 (Delete)」をクリックする。「OK」をクリックして削除を確認します。

pdadminpdadmin ユーティリティーを使用してアクション・グループをリストするには、ドメインにログインして pdadmin action group delete コマンドを使用します。

pdadmin action group delete test-group



カスタム・アクションの要件デフォルトの Tivoli Access Manager アクションは、すべてのアプリケーションで使用できます。アプリケーションがデフォルトの Tivoli Access Manager アクションを利用する場合は、関連操作が、通常は Tivoli Access Manager が行う実際の操作の許可と極めて密接に一致しているはずです。たとえば、保護オブジェクトへの読み取り専用アクセスを必要とする操作では、「r」許可のみが使用されるはずです。

注: 許可サービスは、操作については一切関知も関与もしないため、アプリケーションは、デフォルトの Tivoli Access Manager アクションを完全に無関係な操作に使用できます。ただし、この状況は、同一アクションの異種使用間の区別を必要とする管理者にとっては、問題が発生する可能性があります。

アプリケーションがどのデフォルトのアクションでも的確に表現されない操作を使用する場合は、Tivoli Access Manager を使用すると、このアプリケーションが使用でき、許可サービスが認識できる、新しいアクションを定義できます。

83ページの『アクション・グループの管理』を参照してください。

アクション・グループでの新しいアクションの作成Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してアクション・グループでアクションを作成するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用してアクション・グループでアクションを作成するには、次のようにします。



3. 適切なグループを選択する。

4. 「アクション・グループのプロパティー (Action Group Properties)」ウィンドウから「新規アクションの作成 (Create New Action)」を選択する。

5. アクションを作成する「アクション・グループ (Action Group)」を選択する。デフォルトでは、Action Group になっています。

6. 「アクション名 (Action Name)」を入力する。これは 1 文字の名前です。このフィールドは必須です。

7. 「ラベル (Label)」フィールドにアクションの簡略説明を入力する。このフィールドは必須です。

8. 「タイプ (Type)」フィールドに、そのアクションがどのアプリケーション特有なのか、などアクションの説明を入力する。このフィールドは必須です。

9. 「作成 (Create)」をクリックする。アクションが正常に作成された場合、メッセージが表示されます。


pdadminpdadmin ユーティリティーを使用してドメイン内のアクション・グループでアクションを作成するには、ドメインにログインして pdadmin action create コマンドを使用します。Test-Action というアクション・グループでアクションを作成するには、次のように入力します。

pdadmin action create P Test-Action Special test-group


ACL エントリーへのカスタム・アクションの入力74ページの『ACL エントリーの構文』で説明されているように、ACL エントリーには、エントリー・タイプ、タイプ ID (ユーザーおよびグループ・タイプ用)、および許可アクション・ビットのセットが入っています。

「1 次」アクション・グループ以外のアクション・グループに所属するカスタム・アクション・ビットを識別するには、特別な構文を使用する必要があります。複数のアクション・グループからのアクション・ビットを表すアクション・ストリングは、次の形式で表示されます。

action...action [action-group]action...action,,,

例:

abgTr[groupA]Pq[groupB]Rsy[groupC]ab

v アクション・ビットの最初のセット (abgTr) は、「1 次」(Tivoli Access Manager

デフォルト) アクション・グループからのアクションを表します。

v アクション・グループ A にはアクション P および q が含まれます。

v アクション・グループ B にはアクション R、s、および y が含まれます。

v アクション・グループ C にはアクション a および b が含まれます。

v アクション・グループ C には、「1 次」グループのアクション・ビットと同じ文字を使用するアクション・ビットが含まれることに注意してください。

アクション・ビットは特定のアクション・グループ (C) と関連しているため、aおよび b アクション・ビットには固有の ID があり、「1 次」アクション・グループの a および b アクション・ビットとは全く異なるアクションを表すことができます。

例アクション・グループの表示

pdadmin action group listprimarytest-group

アクション・グループ「test-group」のアクションのリスト

pdadmin action list test-groupP Test-Action SpecialS Test-Action2 Special

ACL ポリシーのリスト


pdadmin acl listdefault-websealdefault-rootdefault-gsodefault-policydefault-configtestdefault-replicadefault-management

ACL「test」の詳細の表示

pdadmin acl show testACL Name: testDescription:Entries:

User sec_master TcmdbvaGroup ivmgrd-servers TlAny-other r

アクション・グループ「primary」および「test-group」からのアクションを含むユーザー Kathy の ACL エントリーの追加

pdadmin acl modify test set user kathy brT[test-group]PSpdadmin acl show test

ACL Name: testDescription:Entries:User sec_master TcmdbvaGroup ivmgrd-servers TlAny-other rUser kathy Tbr[test-group]PS

カスタム・アクションの例89ページの図 22 に示されているように、この例では、特定のプリンターを無許可の使用から保護するための要件があります。印刷スプール・サービスが許可アプリケーション・プログラミング・インターフェース (許可 API) で作成され、許可サービスを呼び出して、プリンターに対する要求に ACL 検査を行うことができます。

標準的な Tivoli Access Manager アクションには、プリンターを保護するための明確な許可は組み込まれていません。しかし、プリンターは、新しく作成されたアクション (この例では「p」) によって保護できます。

ACL ポリシーがプリンター・オブジェクトに付加されています。ユーザーが保護プリンターの使用を要求する場合は、「p」許可が含まれている ACL エントリーを持つ必要があります。「p」許可が存在していれば、許可サービスが肯定的な応答を戻し、印刷操作は実行されます。許可サービスが、そのユーザーに「p」許可が存在していないことを検出した場合、印刷操作はその先に進めません。


図 22. カスタム印刷スプーラーのアクション


第 9 章保護オブジェクト・ポリシーの管理

アクセス・コントロール・リスト (ACL) ポリシーが、保護オブジェクトにアクセスし、そのオブジェクトにいくつかの操作を実行する要求に、「yes」または「no」の応答を行う情報を許可サービスに提供するのに対し、保護オブジェクト・ポリシー(POP) は、許可サービスから「yes」ACL ポリシー決定とともにリソース・マネージャーに戻される要求に対する追加条件を含みます。POP 条件を適用することはTivoli Access Manager およびリソース・マネージャーの役割です。

表 1 は、Tivoli Access Manager が条件を適用する Tivoli Access Manager POP に使用可能な属性のリストです。

表 1. Tivoli Access Manager により適用される条件


POP 属性説明 pdadmin pop コマンド

名前ポリシーの名前。これは、pdadmin pop コマンドでpop_name になります。

createdelete

記述ポリシーの記述テキスト。これは、pop show コマンドで表示されます。

modify set description

警告モード ACL および POP ポリシーをテストする手段を管理者に提供します。

modify set warning

監査レベル監査のタイプ(all、none、successful

access、denied access、errors) を指定します。

modify set audit-level

時刻アクセス保護オブジェクトに正常にアクセスするための日時の制限。

modify set tod-access

拡張属性補足データ・フィールドを指定します。

modify set attributemodify delete attributelist attributeshow attribute

表 2 は、リソース・マネージャー (例: WebSEAL) が条件を適用する Tivoli Access

Manager POP に使用可能な属性のリストです。

表 2. リソース・マネージャーにより適用される条件

リソース・マネージャー (WebSEAL など) によって強制されるもの

POP 属性説明 pdadmin pop コマンド

保護品質データ保護の程度 (none, integrity,

privacy) を指定します。modify set qop

IP エンドポイント認証メソッド・ポリシー

外部ネットワークのメンバーからのアクセスに関する認証要件を指定します。

modify set ipauth addmodify set ipauth removemodify set ipauth anyotherw


注:

1. 時刻アクセスおよび IP エンドポイント認証メソッド・アクセスは、オブジェクトへのアクセスを制限します。

2. 監査レベルおよび保護品質により、認証サービスに、オブジェクトへのアクセスを許可するときは、追加サービスが必要であることが通知されます。

3. 警告モードは、ACL および POP ポリシーがアクティブになる前に、テストする手段を提供します。

保護オブジェクト・ポリシーの管理保護オブジェクト・ポリシー (POP) は、ACL ポリシーと同様の方法で操作します。つまり、POP を作成し、構成してから、その POP を保護オブジェクト・スペースのオブジェクトに付加します。

POP ポリシーは、ACL ポリシーと同じ方法で継承されます。 POP ポリシーおよびACL ポリシーはともに、ポリシー・サーバーが制御するマスター許可データベースにドメインごとに入れられます。

以下に、実行可能な POP タスクを示します。

v 『POP の作成』

v 93ページの『POP のリスト』

v 94ページの『POP の削除』

v 94ページの『POP の変更と表示』

v 95ページの『POP 属性の保護オブジェクトへの適用』

– 95ページの『POP のオブジェクトへの付加』

– 96ページの『POP の付加先の検索』

– 96ページの『POPの切り離し』

POP の作成Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してPOP を作成するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用して POP を作成するには、次のようにします。


2. 「POP」→「作成 (Create)] をクリックして「POP の作成 (Create POP)」ウィンドウを表示する。

3. 「POP 名 (POP Name)」を入力する。これは必須のフィールドです。

4. POP の「説明 (Description)」を入力する。

5. 適切な「監査レベル (Audit Level)」を選択する。監査レベルは、この POP が付加されるリソースへのアクセスに適用される監査のレベルです。1 つ以上の監査レベルを選択できます。監査レベルを以下に示します。

v 許可

正常にアクセスが行われた保護オブジェクトですべての要求を監査する。


v 拒否

アクセスが拒否された保護オブジェクトですべての要求を監査する。

v エラー

保護オブジェクトへのアクセスが拒否された結果、内部的に生成されたエラー・メッセージをすべて監査する。

v Admin

Tivoli Access Manager は使用しない。このオプションはカスタム・アプリケーションにより使用されます。

6. 保護品質を選択します。この POP が付加されるリソースへのアクセスに適用される保護のレベルがアクセスされます。

7. Warn Only On Policy Violation を選択して、警告モード属性を使用可能化します。これは、リソースに関連するポリシー違反がアクセスの拒否または監査済み失敗になることを示します。監査済み失敗は、POP が拒否されたのではなく監査されているアクセスの結果を適用するリソースへのアクセスの試みです。

8. 「時刻アクセス (Time of Day Access)」を選択する。チェック・ボックスを選択して、リソースがアクセスされる時刻を指定します。選択した日のアクセス時間を「終日 (All Day)」または「時間指定 (Between hours of)」のいずれかを使って設定します。「時間指定 (Between hours of)」を選択した場合、「開始時刻 (Start time)」および「終了時刻 (End time)」を、「現地時間 (Localtime)」または「世界時 (UTC time)」(協定世界時) で指定する必要があります。

9. 「作成 (Create)」をクリックする。 POP のプロパティーが表示されます。

pdadminpdadmin ユーティリティーを使用してドメインで POP を作成するには、ドメインにログインして pdadmin pop create コマンドを使用します。たとえば、test という POP を作成するには、次のように入力します。

pdadmin pop create test

新しい POP ポリシーには、次のデフォルト設定が含まれます。

pdadmin pop show testProtected object policy: testDescription:Warning: noAudit level: noneQuality of protection: noneTime of day access: sun, mon, tue, wed, thu, fri, sat:

anytime:localIP Endpoint Authentication Method Policy

Any Other Network 0


POP のリストWeb Portal Manager または pdadmin コマンド行ユーティリティーを使用してすべての POP をリストするには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

第 9 章保護オブジェクト・ポリシーの管理 93

Web Portal ManagerWeb Portal Manager を使用してすべての POP をリストするには、次のようにします。


2. 「POP」→「リスト (List)」をクリックして、POP List ウィンドウを表示する。

3. ドメインのすべての POP が、「POP リスト (POP List)」ウィンドウに表示される。

pdadminpdadmin ユーティリティーを使用してドメインのすべての POP をリストするには、ドメインにログインして pdadmin pop list コマンドを使用します。

pdadmin pop list


POP の削除Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してPOP を削除するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用して POP を削除するには、次のようにします。


2. 「POP」→「リスト (List)」をクリックして、POP List ウィンドウを表示する。

3. 「POP リスト (POP List)」ウィンドウから希望の POP を選択する。

4. 「POP プロパティー (POP Properties)」ウィンドウから「削除 (Delete)」をクリックする。

pdadminpdadmin ユーティリティーを使用してドメインの POP を削除するには、ドメインにログインして pdadmin pop delete コマンドを使用します。たとえば、test という POP を削除するには、次のように入力します。

pdadmin pop delete test


POP の変更と表示Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してPOP を変更するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal ManagerWeb Portal Manager を使用して POP を変更するには、次のようにします。



2. 「POP」→「リスト (List)」をクリックして、「POP リスト (POP List)」ウィンドウを表示する。


4. 適切な情報を変更する。

5. 「変更 (Modify)」をクリックする。

pdadminpdadmin ユーティリティーを使用してドメインの POP を変更するには、ドメインにログインして pdadmin pop modify コマンドを使用します。たとえば、test という POP を変更するには、次のように入力します。

pdadmin pop modify test set description “Test POP”

注: 複数のワードを使用する場合は、必ず記述を二重引用符で囲んでください。

POP への変更を表示するには、pdadmin pop show コマンドを使用します。

pdadmin pop show testProtected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: noneTime of day access: sun, mon, tue, wed, thu, fri, sat:


Any Other Network 0


POP 属性の保護オブジェクトへの適用POP ポリシーは、ACL ポリシーと同じ方法でオブジェクトに適用されます。

POP のオブジェクトへの付加Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してPOP をオブジェクトに付加するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web ポータル・マネージャー (WPM): Web Portal Manager を使用して POP をオブジェクトに付加するには、次のようにします。




4. 「POP プロパティー (POP Properties)」ウィンドウで「付加 (Attach)」をクリックする。

5. 「POP の付加 (Attach POP)」ウィンドウの「オブジェクト・パス (Object

Path)」フィールドで、POP が付加されるオブジェクト・スペース・オブジェクトの絶対パスを入力する。たとえば、/WebSEAL/WS1/JCT1

6. 「付加 (Attach)」をクリックする。正常に付加された場合、POP のプロパティーが表示されます。


pdadmin: pdadmin ユーティリティーを使用して POP を保護オブジェクトに付加するには、ドメインにログインして、pdadmin pop attach コマンドを使用します。test という POP を /WebSEAL/serverA/index.html という保護オブジェクトに付加するには、次のように入力します。

pdadmin pop attach /WebSEAL/serverA/index.html test


POP の付加先の検索Web Portal Manager または pdadmin コマンド行ユーティリティーを使用してPOP の付加先を検索するには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal Manager: Web Portal Manager を使用して POP の付加先を検索するには、次のようにします。




4. 「POP エントリー・プロパティー (POP Entry Properties)」ウィンドウから「検索 (Find)」を選択して、POP が付加されているすべてのオブジェクトを表示する。

pdadmin: pdadmin ユーティリティーを使用して POP の付加先を検索するには、ドメインにログインしてpdadmin pop find コマンドを使用します。たとえば、test という POP の付加先を検索するには、次のように入力します。

pdadmin pop find test/WebSEAL/serverA/index.html


POPの切り離しWeb Portal Manager または pdadmin コマンド行ユーティリティーを使用してPOP を保護オブジェクトから切り離すには、希望のドメインにドメイン・アドミニストレーターとしてログインします。

Web Portal Manager: Web Portal Manager を使用して POP を保護オブジェクトから切り離すには、次のようにします。


2. 「オブジェクト・スペース (Object Space)」→「参照 (Browse)」をクリックして、「オブジェクト・スペースの参照 (Browse Object Space)」ウィンドウを表示する。


4. 「付加された POP (Attached POP)」フィールドから「リスト (List)」をクリックして POP をリストする。


5. POP リストから適切な POP を選択して「適用 (Apply)」をクリックする。このPOP は、「付加された POP (Attached POP)」フィールドにリストされます。

6. 「付加された POP (Attached POP)」フィールドから「切り離し (Detach)」をクリックする。

pdadmin: pdadmin ユーティリティーを使用して POP を保護オブジェクトから切り離すには、ドメインにログインして pdadmin pop detach コマンドを使用します。POP を /WebSEAL/serverA/index.html というほぼオブジェクトから切り離すには、次のように入力します。

pdadmin pop detach /WebSEAL/serverA/index.html


POP 属性の構成POP 属性は、アクセスの条件に基づいてオブジェクトにアクセス条件を設け、アクセス要求が監査されるかどうかを指示します。

警告モード属性警告属性の目的は、セキュリティー管理者が保護オブジェクト・スペースで許可ポリシー・セットの正確さをデバッグするかトラブルシューティングすることです。

警告属性を「yes」に設定すると、POP が付加されたオブジェクトで、すべてのユーザーが任意のアクションを実行できます。オブジェクトに付加されている ACL

ポリシーがこのアクセスを拒否するように設定されていても、オブジェクトへのすべてのアクセスが許可されます。

オブジェクト・スペースを介して警告モードを設定したすべての ACL ポリシーの結果を取り込む、監査レコードが生成されます。監査ログは、警告属性が「no」に設定されている場合と同様の許可決定の結果を表示します。したがって、管理者は、ポリシーが設定され、正しく実施されているかどうかを判別できます。

例:

pdadmin pop modify test set warning yes

pdadmin pop コマンドについて詳しくは、IBM Tivoli Access Manager コマンド・リファレンスを参照してください。

監査レベル属性POP 監査レベルには、監査のレベルを指定する拡張機能があります。たとえば、監査が失敗したイベントを記録するように設定されている場合、結果を使用して特定のリソース上で失敗したアクセスの試行の異常な回数を検出できます。

監査レコードは、必要なすべての情報を取り出すために簡単な解析を可能にする、標準 Extensible Markup Language (XML) フォーマットで作成されます。 134ページの『監査証跡ファイル』を参照してください。

たとえば、次のように表示されます。


pdadmin pop modify test set audit-level permit,deny

Audit-Level-List

値説明

permit 正常にアクセスが行われた保護オブジェクトですべての要求を監査する。

deny アクセスが拒否された保護オブジェクトですべての要求を監査する。

error 保護オブジェクトへのアクセスが拒否された結果、内部的に生成されたエラー・メッセージをすべて監査する。

これらの値のどんな組み合わせも適用できます。複数の値を指定する場合、コンマを区切り文字として使用してください。


時刻属性時刻 (TOD) POP 属性を使用すると、保護オブジェクトへのアクセスに、特定の日付条件を入れることができます。このタイプの条件は、変更と更新のために非活動期間を定期的に必要とする情報へのアクセスを、制限するのに役立つ場合があります。

オブジェクト上の POP 許可条件を指示変更する、ACL ポリシー・バイパス許可(「B」) があります。この許可を使用できるのは、常に保護オブジェクト・スペースの完全アクセスを必要とする、上位のアドミニストレーターに限られます。

pop modify pop_name set tod-access time_of_day_string

Time-of-day-string 引き数には、日付範囲と時刻範囲が含まれ、次の形式を使用します。

{anyday|weekday|day_list}:{anytime|time_spec-time_spec}[:{utc|local}]

day-list 変数では、以下を組み合わせられます。

mon, tue, wed, thu, fri, sat, sun

time-spec 範囲変数は、次の形式で (24 時間表記を使用して) 表現します。

hhmm-hhmm

例:

0700-1945

サーバー (クライアントではなく) のオプションの時間帯は、デフォルトでは localです。

例:

pdadmin pop modify test set tod-access mon,tue,fri:1315-1730



認証強度 POP ポリシー (ステップアップ)特定のリソースに一定のアクセス条件を適用するには、保護オブジェクト・ポリシー (POP) を使用できます。認証強度 POP ポリシーの場合は、認証方式に基づいてオブジェクトへのアクセスの制御が可能になります。

この機能は、時にステップアップ認証として知られていますが、これを使用すると、機密性の高いリソースにアクセスするユーザーはより強固な認証メカニズムを使用することができます。一定のリソースへの不適切なアクセスの脅威が高まったために、この条件が必要になることがあります。

たとえば、ドメインの最初の入力時に使用したクライアントより強い認証レベルが必要なステップアップ POP ポリシーを適用することによって、保護オブジェクト・スペースの junction 領域へのセキュリティーを強化することができます。

認証強度ポリシーは、POP ポリシーの IP エンドポイント認証メソッド属性で設定されます。

ステップアップ認証のレベルの構成認証特定アクセスを構成する最初のステップは、サポート対象の認証方式を構成し、これらの認証方式がより強いと考えられる順序を決めることです。

リソース・マネージャーにアクセスするすべてのクライアントが持つ「unauthenticated (非認証)」または「password (パスワード)」などの認証レベルは、クライアントがリソース・マネージャーによって最後に認証されるメソッドを示します。

状況によっては、特定のリソースにアクセスするのに最小安全レベルの認証の適用が必要な場合があります。たとえば、ある環境では、トークン・パスコードによる認証が、ユーザー名とパスワードによる認証より、より安全と考えられる場合もあります。環境が異なれば、標準も変わる可能性があります。

クライアントが必要なレベルの認証を満たせないときは、リソース・マネージャーとのセッションを強制的に再始動させるのではなく、ステップアップ認証メカニズムの場合は、必要なメソッド (レベル) を使用して再認証する 2 番目の機会をクライアントに与えます。

リソース・マネージャーは、ステップアップ認証を使用してユーザーが保護リソースにアクセスするメソッドを制御できます。ユーザーが十分なメソッドで認証を受けていないためにステップアップ認証が必要な場合は、アクセス決定は依然許可エンジンによって許可されますが、リソース・マネージャーには、必要な許可レベルが、許可決定の出力として提示されます。次にリソース・マネージャーは、ユーザーの認証をさらに深める方法を決めて、ユーザーがオブジェクトにアクセスするのに必要なレベルの認証を得るようにすることができます。

特定の認証方式を認証レベルにマップする方法は、すべてリソース・マネージャーのアプリケーションによって決まります。すべての場合で、認証の受け入れ可能な


絶対最小メソッドは、レベル 0 として設定され、そこからよりセキュアなメソッドが昇順 (1..x) で整数値にマップされる必要があります。

ステップアップ認証ポリシーの適用ステップアップ認証は、認証に慎重な許可を必要とするオブジェクトに適用されたPOP ポリシーを介してインプリメントされます。 POP ポリシーの IP エンドポイント認証メソッド属性を使用します。

pdadmin pop modify set ipauth コマンドは、IP エンドポイント認証方式属性で、可能なネットワークおよび必要な認証レベルの両方を指定します。

構成済み認証レベルは、IP アドレス範囲にリンクできます。このメソッドは、管理に柔軟性を持たせることを意図しています。 IP アドレスによるユーザーのフィルター掛けが重要ではない場合は、anyothernw (その他のネットワーク) の単一のエントリーを設定することができます。この設定は、IP アドレスに関係なく、アクセスするすべてのユーザーに影響し、そのユーザーを指定されたレベルで認証する必要があります。これは、ステップアップ認証をインプリメントする最も一般的なメソッドです。

anyothernw エントリーは、すべてのネットワークと一致する (一致しなければPOP で指定される) ネットワーク範囲として使用されます。このメソッドは、一致しないすべての IP アドレスを拒否するか、認証レベルの要件を満たすすべてのアクセスを認めることができるデフォルトのエントリーを作成するときに使用します。

デフォルトでは、anyothernw は、認証レベル指標 0 の POP に表示されます。このエントリーは、pop show コマンドにその他のネットワークとして表示されます。



Any Other Network0

pdadmin pop modify set ipauth コマンドについて詳しくは、IBM Tivoli Access

Manager コマンド・リファレンスを参照してください。

ステップアップ認証と多元的認証の区別Tivoli Access Manager ステップアップ認証と多元的認証は、リソースへのアクセスを制御するための 2 つの異なる別個のメカニズムです。本章での説明のように、Tivoli Access Manager が備えているのは、ステップアップ認証機能のみです。

多元的認証は、ユーザーに複数レベルの認証を使用した認証を強制します。たとえば、保護リソースへのアクセス・コントロールでは、ユーザー名/パスワードとユーザー名/トークン・パスコードの両方で、ユーザー認証を行うことが必要な場合があります。


Tivoli Access Manager ステップアップ認証は、認証レベルの事前構成階層に依存し、リソースに設定されたポリシーに従って特定のレベルの認証を実施します。ステップアップ認証は、一定のリソースへのアクセスの場合に、複数レベルの認証を使用した認証をユーザーに強制することはありません。代わりに、ステップアップ認証では、少なくともリソースを保護するポリシーが必要とする高さのレベルでの認証をユーザーに求めます。

ステップアップ認証の例を以下に示します。

以下に、構成された認証レベルを示します。

v 認証レベル 1 = ユーザー名/パスワード

v 認証レベル 2 = ユーザー名/トークン・パスコード

以下のオブジェクトは、認証レベル 1 を必要とする POP によって保護されます。

/WebSEAL/hostA/junction

以下のオブジェクトは、認証レベル 2 を必要とする POP によって保護されます。

/WebSEAL/hostA/junction/applicationA

ステップアップ認証の場合、/WebSEAL/hostA/junction へのアクセスには、ユーザー名/パスワード (レベル 1) 認証が必要です。

しかし、/WebSEAL/hostA/junction/applicationA へのアクセスには、ユーザー名/トークン・パスコード (レベル 2) 認証が必要です。ユーザーが現在ユーザー名とパスワードでログインしている場合は、ユーザー名とトークン・パスコード情報を求めるプロンプトが出されます (ステップアップ)。しかし、ユーザーがユーザー名とトークン・パスコードで WebSEAL に最初にログインしている場合は、即時にapplicationA にアクセスします (ACL 検査の結果、問題なしと想定して)。

多元的認証の場合、applicationA へのアクセスには、レベル 1 とレベル 2 の両方の認証が必要です。

保護品質 POP ポリシー保護品質 POP 属性を使用すると、オブジェクトに操作を実行する際に必要なデータ保護のレベルを指定することができます。

保護品質 POP 属性の場合は、ACL 決定に対する「yes」応答にも必要な保護品質レベルが含まれる場合に、単一トランザクションが許可されます。リソース・マネージャーが必要レベルの保護を保証できなければ、要求は拒否されます。

構文:

pdadmin pop modify pop-name set qop {none|integrity|privacy}

QOP レベル説明

Privacy Secure Sockets Layer (SSL) ではデータ暗号化が必要です。

Integrity 一種のメカニズムを用いて、データが変更されないようにします。

例:


pdadmin pop modify test set qop privacy

ネットワーク・ベースの認証 POP ポリシーネットワーク・ベースの認証 POP ポリシーでは、ユーザーの IP アドレスに基づいてオブジェクトへのアクセスの制御が可能になります。この機能を使用すると、特定の IP アドレス (あるいは IP アドレス範囲) がドメイン内のリソースにアクセスするのを防ぐことができます。

ステップアップ認証構成をこのポリシーに適用して、指定した IP アドレス範囲ごとに特定の認証方式を要求することもできます。

ネットワーク・ベースの認証ポリシーは、POP ポリシーの IP エンドポイント認証メソッド属性で設定されます。この属性では、以下の 2 つの要件を指定する必要があります。

v 認証レベル

認証レベルの詳細については 99ページの『認証強度 POP ポリシー (ステップアップ)』を参照してください。

v 許可ネットワーク

IP アドレスおよび範囲の指定pdadmin pop modify set ipauth add コマンドは、IP エンドポイント認証メソッド属性で、ネットワーク (またはネットワーク範囲) および必要な認証レベルの両方を指定します。

pdadmin pop modify set ipauth add コマンドについて詳しくは、IBM Tivoli

Access Manager コマンド・リファレンスを参照してください。

構成済み認証レベルは、IP アドレス範囲にリンクされます。このメソッドは、柔軟性を持たせることを意図しています。 IP アドレスによるユーザーのフィルター掛けが重要ではない場合は、anyothernw (その他のネットワーク) の単一のエントリーを設定することができます。この設定は、IP アドレスに関係なく、アクセスするすべてのユーザーに影響し、そのユーザーを指定されたレベルで認証する必要があります。

反対に、認証レベルを無視し、アクセスの許可または拒否を IP アドレスのみに基づいて行う必要がある場合は、許可する必要がある範囲にレベル 0 を使用し、拒否する範囲に forbidden (禁止) を使用できます。

anyothernw エントリーは、すべてのネットワークと一致する (一致しなければPOP で指定される) ネットワーク範囲として使用されます。このメソッドは、一致しないすべての IP アドレスを拒否するか、認証レベルの要件を満たすすべてのアクセスを認めることができるデフォルトのエントリーを作成するときに使用します。

デフォルトでは、anyothernw は、認証レベル指標 0 の POP に表示されます。このエントリーは、pop show コマンドにその他のネットワークとして表示されます。




Any Other Network0

pdadmin pop modify set ipauth anyothernw コマンドについて詳しくは、IBM

Tivoli Access Manager コマンド・リファレンスを参照してください。

例IP アドレス範囲 9.0.0.0 およびネットマスク 255.0.0.0 からのユーザーに、レベル1 認証 (デフォルトでは「パスワード」) の使用を求めます。

pdadmin pop modify test set ipauth add 9.0.0.0 255.0.0.0 1

特定のユーザーにレベル 0 認証の使用を求めます。

pdadmin pop modify test set ipauth add 9.1.2.3 255.255.255.255 0

すべてのユーザー (上記の例で指定されたものを除く）のオブジェクトへのアクセスを防止します。

pdadmin pop modify test set ipauth anyothernw forbidden

IP アドレスによるステップアップ認証の使用不可例:

pdadmin pop modify test set ipauth remove 9.0.0.0 255.0.0.0

pdadmin pop modify set ipauth remove コマンドについて詳しくは、IBM


ネットワーク・ベースの認証アルゴリズム許可エンジンは、以下のアルゴリズムを使用して POP 内の条件を処理します。

1. ACL 許可を検査する。

2. オブジェクトにルールが付加されているか検査し、次のルール評価の ADI すべてが存在することを検証する。存在しない場合、利用可能なソースの 1 つを照会して検索します。

3. POP の IP エンドポイント認証メソッド・ポリシーを検査する。

4. POP の時刻ポリシーを検査する。

5. POP の監査レベル・ポリシーを検査する。

6. ルールがオブジェクトに付加されているかどうかルール・ポリシーを検査する。

7. このアクセス決定に、外部許可サービス (EAS) 操作または POP トリガーが適用されている場合は、適用されている EAS を呼び出す。

ネットワーク・ベースの認証の注意と制限リソース・マネージャーがネットワーク・ベースの認証ポリシーの適用の際に使用する IP アドレスは、接続の開始元である必要があります。ネットワーク・トポロ


ジーがプロキシーを使用する場合は、リソース・マネージャーに表示されるアドレスがプロキシー・サーバーの IP アドレスであることがあります。

この場合、リソース・マネージャーは真のクライアント IP アドレスを明確に識別することはできません。ネットワーク・ベースの認証ポリシーを設定するときは、ネットワーク・クライアントがリソース・マネージャーに直接接続できるかどうか、注意する必要があります。


第 10 章 Tivoli Access Manager 証明書およびパスワード管理

Tivoli Access Manager コンポーネントは、暗号化、システム認証、およびアプリケーション・レベルの認証に Secure Sockets Layer (SSL) を使用します。 SSL は、操作に証明書を使用します。セキュアの環境において、ポリシー・サーバー pdmgrdデーモン) は、認証局 (CA) として動作し、証明書の作成と更新を担当します。Tivoli Access Manager Runtime (pdrte) が依存するのは、SSL サーバー・サイド認証のみで、したがって、クライアント・サイドの証明書は必要ありません。しかし、ポリシー・サーバー (pdmgrd)、許可サーバー (pdacld)、およびリソース・マネージャー・アプリケーション (aznAPI) サーバーなど、すべての Tivoli Access

Manager サーバーは、クライアント・サイドの証明書に依存して操作します。

サーバーは、自らの認証に証明書を使用します。たとえば、pdacld は、pdmgrdと通信する際、そのクライアント・サイド証明書を提示します。この例で、pdmgrdはサーバー、pdacld はクライアントと考えることができます。 pdmgrd サーバーは、証明書が有効であり、かつトラステッド署名者 (この場合は、PDCA 証明書を使用する pdmgrd 自体) によって署名されていることを確認します。 pdacld サーバーは、pdmgrd が提示する証明書に対して同じことを行います。 Tivoli Access

Manager アプリケーション・レベルの認証の一環で、pdmgrd は、pdacld 証明書が正当であると判断すると、その証明書を Tivoli Access Manager ユーザーにマップしようとします。認証が通れば、サーバーは通信を開始することができます。

Tivoli Access Manager が使用する証明書は、鍵リング・データベース・ファイルに保持されます (これらには .kdb 拡張子が付きます)。これらのファイルには当該証明書の秘密鍵が入っているため、使用可能な最も厳密なオペレーティング・システムの制御によって安全に保護される必要があります。たとえば、pdmgrd の鍵リング・データベース・ファイルは ivmgrd.kdb であり、デフォルトでは、ivmgr ユーザーのみがこのファイルに読み取り/書き込み可能です。

さらには、不在サーバー操作を行うため、鍵リング・データベース・ファイルにとっては分かりにくい (暗号化されていない) バージョンのパスワードの入ったファイルがあります。これらは stash ファイルと呼ばれ、.sth ファイル拡張子で表されます。これらのファイルも OS 手段を用いて安全にする必要があります。 pdmgrdの場合、stash ファイルは ivmgrd.sth であり、そのアクセス許可は ivmgrd.kdb と同じです。

安全上の理由から、証明書と鍵リング・データベース・ファイルは、ともに構成可能な時間の経過後、期限が切れるように設定できます。証明書のデフォルトの存続期間は 365 日です。鍵リング・データベース・ファイル・パスワードのデフォルトの存続期間は 183 日です。 PDCA 証明書の固定存続期間は 20 年です。またデフォルトでは、Tivoli Access Manager コンポーネントは、実行する間は証明書およびパスワードを自動的にリフレッシュして、セルフケアを行います。リフレッシュ・プロセスは、証明書およびパスワードの存続期間を延長します。これらは再発行されません。

しかし、指定された猶予時間内に、サーバーが稼働していなかった場合は、証明書またはパスワードが期限切れになる可能性があります。この場合は、手動によるリフレッシュが必要です。さらには、証明書、パスワード、または鍵リング・データ


ベース・ファイル全体が破壊された場合は、Tivoli Access Manager ドメインを安全に保持するため、手動によるリフレッシュも許されます。手動リフレッシュの実行については『鍵リング・データベース・ファイルおよび stash ファイルの更新情報』を参照してください。

初期構成Tivoli Access Manager コンポーネントが使用する証明書は、その初期構成の一環で作成されます。 Tivoli Access Manager の最初のインストールでは、pdmgrd サーバーが最初の構成サーバーです。その構成の一環で、PDCA 証明書が作成され、pdmgrd が使用する個人用証明書が作成されて、PDCA 証明書によって署名されます。これらの証明書はともに ivmgrd.kdb 鍵リング・データベース・ファイル内にあります。また、pdmgrd 構成の一環で、ランタイム鍵リング・データベース・ファイルの pd.kdb が作成され、PDCA 証明書がトラステッド証明書としてそれに挿入されます。

新しいシステムが Tivoli Access Manager ドメインに追加される際、pdrte がまず構成されます。もう一度この構成の一環で、システム pd.kdb および pd.sth ファイルが作成され、PDCA 証明書がトラステッド証明書として鍵リング・データベース・ファイルに組み込まれます。

新規 aznAPI サーバー (pdacld または WebSEAL など) が構成される際、svrsslcfg ツール (あるいは同等の API) が実行されます。このツールが鍵リング・データベース・ファイル (pdacld.kdb など) を作成し、それにサーバー用の個人証明書を入れます。またツールは、PDCA 証明書を、トラステッド証明書として鍵リング・データベース・ファイルに挿入します。この 2 つの証明書は、pdmgrd から取得され、ランタイム鍵リング・データベース・ファイルを使用して SSL によってクライアント・マシンにトランスポートされます。

鍵リング・データベース・ファイルおよび stash ファイルの更新情報以下の表に、コンポーネントとその関連鍵リングおよび stash ファイルのリストを掲載します。その作成および更新方法も記載されています。

表 3. コンポーネント、鍵リングおよび stash ファイル

コンポーネント鍵リング/stashファイル

作成方法

鍵リング・ファイルまたはパスワードあるいはその両方を自動的に更新するプロセス

手動更新用ツール

pdrte pd.kdb pd.sth

(クライアント・サイド証明書は含まない)

pdrte 構成の際 pdadmin1 の起動

bassslcfg-chgpwd

pdmgrd ivmgrd.kdb

ivmgrd.sth

pdmgrd 構成の際

pdmgrd1,2 の実行中

mgrsslcfg-chgpwd3 および mgrsslcfg-chgcert3


表 3. コンポーネント、鍵リングおよび stash ファイル (続き)

コンポーネント鍵リング/stashファイル

作成方法

鍵リング・ファイルまたはパスワードあるいはその両方を自動的に更新するプロセス

手動更新用ツール

pdacld ivacld.kdb

ivacld.sth

pdacld 構成の際

pdacld1 の実行中

svrsslcfg-chgpwd

4およ

び svrsslcfg-chgcert5

aznAPIサーバー

aznAPI.kdb

aznAPI.sth (名前は構成可能)

svrsslcfg-config の実行中

aznAPI サーバー 1 のインスタンスの実行中

svrsslcfg-chgpwd6 および svrsslcfg-chgcert7

注:

v1 - 証明書およびパスワードの自動リフレッシュは、属性 [ssl], ssl-auto-refresh をそれぞれの構成 (.conf) ファイルで「no」に設定することでオフにできます。

v3 - このコマンドの実行前に pdmgrd サーバーが停止している必要があります。

v4 - このコマンドの実行前に pdacld サーバーが停止している必要があります。

v5 - このコマンドの実行前に pdmgrd サーバーが実行中で、かつ pdacld サーバーが停止している必要があります。

v6 - このコマンドの実行前に aznAPI サーバーが停止している必要があります。

v7 - このコマンドの実行前に pdmgrd サーバーが実行中で、かつ aznAPI サーバーが停止している必要があります。

信頼性の判別鍵リング・データベース・ファイルのそれぞれにトラステッド CA のリストが入っています。 Tivoli Access Manager の場合は、あらゆる鍵リング・データベース・ファイル (ivmgrd.kdb を除く) に、トラステッド CA として PDCA 証明書が入っています。 CA は、ほかのすべての Tivoli Access Manager 証明書に署名する際に使用する証明書です。この CA は pdmgrd 構成の際に作成され、ivmgrd.kdb ファイルに入れられます。 PDCA 証明書の秘密鍵の信頼が損なわれないように保つには、ivmgrd.kdb ファイルの保護が極めて重要です。信頼が損なわれた場合は、再生成が必要です。こうなった場合は、ドメイン内のあらゆる鍵リング・データベース・ファイル、およびあらゆる証明書も同様に再生成する必要があります。これを行うステップを以下に示します。

1. mgrsslcfg -unconfig、次に mgrsslcfg -config を使用して新しい ivmgrd.kdb

ファイルを生成して、PDCA 証明書 (および pdmgrd サーバー証明書) を再生成します (pdmgrd は停止している必要がある)。

2. 最初に bassslcfg -unconfig を実行して、ドメイン内のすべての pdrte ランタイムを再生成します。次に CA 証明書を取得します。 CA 証明書の自動ダウンロードがオンで、pdmgrd が実行中ならば、bassslcfg -getcacert -h pdmgrd

hostname -c certificate file name を実行すると、CA 証明書が取得されます。自

第 10 章 Tivoli Access Manager 証明書およびパスワード管理 107

動ダウンロードがオフの場合は、PDCA 証明書のベース 64 DER エンコード・バージョンをマシンに手動でコピーする必要があります。このファイルは、pdcacert.b64 として pdmgrd マシンに保管されています。最後に、bassslcfg-config を実行して pdrte 構成を完了します。

3. ドメイン内に pdacld 鍵リング・ファイルがあれば、svrsslcfg -unconfig および svrsslcfg -config を実行して再生成します (pdmgrd は実行中でなければならない)。これらのコマンドで、pdacld のサーバー証明書とそのトラステッド証明書 (新しい PDCA 証明書) の両方が更新されます。

4. ドメイン内にほかの aznAPI サーバー鍵リング・ファイルがあれば、svrsslcfg-unconfig および svrsslcfg -config を実行して再生成します (pdmgrd は実行中でなければならない)。これらのコマンドで、pdacld のサーバー証明書とそのトラステッド証明書 (新しい PDCA 証明書) の両方が更新されます。

証明書の失効サーバーの証明書の信頼が損なわれた場合、サーバーは svrsslcfg -unconfig および svrsslcfg -config (pdmgrd は実行中でなければならない) を実行して構成解除してから再構成する必要があります。これらのコマンドで、pdacld のサーバー証明書とそのトラステッド証明書 (新しい PDCA 証明書) の両方が更新されます。

その他の考慮事項鍵リング・データベース・ファイルおよび stash ファイル更新に関するその他の考慮事項を以下に示します。

v 証明書と、その証明書の入った鍵リング・データベース・ファイルに対するパスワードの両方が期限切れになった場合は、最初にパスワードをリフレッシュする必要があります。たとえば、pdacld の場合は、svrsslcfg -chgpwd、次にsvrsslcfg -chgcert を実行します。これが必要な理由は、鍵リング・データベース・ファイルを開いて証明書を得るには、有効なパスワードが必要であるためです。

v 証明書の存続期間の値は、pdmgrd が開始されたときの ivmgrd.conf, [ssl],

ssl-cert-life 属性の値によって制御されます。発行または更新される証明書は、すべてこの値を使用します。この値を増減するには、値を変更して pdmgrd を再始動します。新しい値が有効になるのは、その時点から発行または更新された証明書の場合に限られます。

v 自動パスワード更新の場合、パスワードの存続期間の値は、サーバーが開始されたときに有効な [ssl], ssl-pwd-life 属性の値によって制御されます。パスワードの手動更新の場合、値は chgpwd コマンドに与えられた値によって決められます。この値は、該当する構成ファイルにも書き込まれます。

v Tivoli Access Manager サーバーはまた、SSL を使用して Lightweight Directory

Access Protocol (LDAP) と通信できます。標準構成の場合、この通信ではサーバー・サイド認証のみを使用します。したがって、Tivoli Access Manager サーバーには、LDAP サーバー証明書に署名した CA 証明書か、あるいは LDAP サーバー証明書そのものしか必要ありません。これらの証明書の有効期限および管理は、Tivoli Access Manager によって扱われません。しかし、svrsslcfg -configを実行し、-C オプションを使用することによって、LDAP 証明書を aznAPI サーバーの鍵リング・データベース・ファイルに組み込むことは可能です。


v bassslcfg -config の実行後、pd.kdb および pd.sth のアクセス許可の変更が必要な場合があります。

v 前述の構成ファイルは、一般に install_dir/etc ディレクトリー内にあります。たとえば、AIX の場合、pdmgrd、pdacld、および Runtime 構成ファイルはそれぞれ /opt/PolicyDirector/etc/ivmgrd.conf、/opt/PolicyDirector/etc/ivacld.conf、および/opt/PolicyDirector/etc/pd.conf 内にあります。同様に、鍵リング・データベース・ファイルおよび stash ファイルは install_dir/keytabs ディレクトリー内にあります。

v Tivoli Access Manager は、エクスポートと内部の暗号化を区別しません。鍵の最大長は 2048 ビットです。鍵の長さ 2048 ビットの証明書と鍵リング・データベース・ファイルはともに、構成ユーティリティー bassslcfg、mgrsslcfg、または svrsslcfg) を使用して生成できます。.

第 10 章 Tivoli Access Manager 証明書およびパスワード管理 109

第 11 章サーバー管理

この章では、Tivoli Access Manager サーバー上で一般管理および構成タスクを実行する際の詳細を説明します。


v 『Tivoli Access Manager サーバー』

v 112ページの『Tivoli Access Manager ユーティリティー』

v 113ページの『Tivoli Access Manager サーバーの始動および停止』

v 115ページの『ブート時のサーバー始動の自動化』

v 116ページの『ポリシー・サーバー管理』

Tivoli Access Manager サーバーTivoli Access Manager は、以下のサーバー・プロセス、またはデーモンから構成されます。

v ポリシー・サーバー (pdmgrd)

v 許可サーバー (pdacld)

ポリシー・サーバー (pdmgrd) は、マスター許可データベースとも呼ばれるポリシー・データベースを管理し、ドメイン内のほかの Tivoli Access Manager サーバーに関するロケーション情報を維持します。ドメインごとに少なくとも 1 つのポリシー・サーバーが定義されている必要があります。

許可サーバー (pdacld) により、ほかのアプリケーションは、許可アプリケーション・プログラミング・インターフェース (許可 API) を使用して、Tivoli Access

Manager に許可呼び出しを行うことができます。許可サーバーは、ロギングおよび監査コレクション・サーバーとしても作動し、サーバー・アクティビティーのレコードを保管します。

図 23. Tivoli Access Manager サーバー・コンポーネント


サーバー構成ファイルTivoli Access Manager およびそのサーバーの操作をカスタマイズする場合は、サーバー構成ファイルを使用できます。詳しくは、 165ページの『付録 A. サーバー構成ファイルの解説』を参照してください。

サーバーの依存関係v ポリシー・サーバーのインスタンスは少なくとも 1 つあります。

v ドメイン内のマスター・ポリシー・データベースは、 1 つのみである必要があります。ポリシー・データベースは、高可用性サーバーに強固なファイル・システムとともに常駐しています。それぞれのポリシー・データベースは通常のバックアップ・プロシージャーに従うことを推奨します。

v ポリシー・サーバーは、ローカル・キャッシュ・モードで実行するドメイン内の他のすべての Tivoli Access Manager サーバーへの許可データベース複製サービスを提供します。

v Tivoli Access Manager WebSEAL、Tivoli Access Manager for Business

Integration、または Tivoli Access Manager for Operating Systems などのリソース・マネージャーは、ポリシー・データベースまたは複製許可データベースからの情報に基づいてセキュリティー・ポリシーを適用します。

Tivoli Access Manager ユーティリティー次の Tivoli Access Manager ユーティリティーは、IBM Tivoli Access Manager コマンド・リファレンスで詳細に説明されています。表 4 は、使用可能なユーティリティーとその目的のリストです。 pdadmin コマンド行インターフェースにも、問題のトラブルシューティングに役立つコマンドがあることに注意してください。たとえば、pdadmin server task コマンドには stats および trace オプションが付いていて、これによって、統計の収集およびエラー状態に関する情報の取り込みを行うことができます。これらのコマンドの使用方法について詳しくは、IBM Tivoli

Access Manager 問題判別ガイドを参照してください。

表 4. Tivoli Access Manager ユーティリティー

ユーティリティー目的

bassslcfg Secure Sockets Layer (SSL) 構成タスクを実行します。

ezinstall_* バッチ・ファイル (Windows) またはスクリプト (UNIX) を使用して完全な Tivoli Access Manager システムをセットアップします。

install_pdrte 以下のソフトウェア・パッケージを用いて Tivoli Access

Manager Runtime システムをセットアップします。

v IBM Global Security Toolkit

v IBM Directory Client

v Tivoli Access Manager Runtime

install_pdrte ユーティリティーは、Linux for zSeries では利用できません。

mgrsslcfg SSL 構成タスクを実行します。


表 4. Tivoli Access Manager ユーティリティー (続き)

ユーティリティー目的

pdbackup Tivoli Access Manager データのバックアップ、復元、および抽出を行います。

pdconfig Tivoli Access Manager コンポーネントを構成します。

pdjrtecfg Tivoli Access Manager Java Runtime Environment を構成します。

pd_start サーバーを始動および停止して、サーバー状況を表示します。

pdversion インストール済み Tivoli Access Manager コンポーネントのバージョンをリストします。

svrsslcfg C 言語許可 API を使用して書き込まれたリソース・マネージャーをドメインに構成し、SSL 構成タスクを実行します。

Tivoli Access Manager サーバーの始動および停止ここでは、サーバー・プロセスの始動および停止の方法について説明します。

v 『UNIX システムでのサーバーの始動および停止』

v 114ページの『Windows システムでのサーバーの始動および停止』

UNIX システムでのサーバーの始動および停止サーバー・プロセスの始動と停止は、通常、システムの始動時とシャットダウン時に実行される、自動化されたスクリプトによって行われます。

また、UNIX 環境では、pd_start スクリプトを使用して、サーバー・プロセスを手動で始動したり、停止したりすることもできます。この技法は、インストール・システムをカスタマイズする必要のある場合や、トラブルシューティング・タスクを実行する必要のある場合に役立ちます。スクリプトを実行できるのは、ローカル・マシンの場合のみです。

pd_start の一般的な構文は、以下のとおりです。

# pd_start {start|restart|stop|status}

pd_start ユーティリティーは、任意のディレクトリーから実行できます。このスクリプトは以下のディレクトリーにあります。

/opt/PolicyDirector/bin/

pd_start ユーティリティーを使用して Tivoli Access Manager サーバーを始動する特定のマシン上で現在実行していない Tivoli Access Manager サーバーをすべて始動する場合は、pd_start ユーティリティーを使用します。

# pd_start start

このスクリプトは、すべてのサーバーが始動するのを待ってから、プロンプトを戻します。

第 11 章サーバー管理 113

個々のサーバーを手動で始動するサーバーを直接実行することによって、手動でサーバーを個別に始動できます。

始動コマンドは、 root など、管理ユーザーとして実行する必要があります。

Tivoli Access Manager サーバーは、次の順序で始動します。

1. ポリシー・サーバー (pdmgrd) の場合は、次の入力を行います。

install_path/bin/pdmgrd

2. 許可サーバー (pdacld) の場合は、次の入力を行います。

install_path/bin/pdacld

pd_start ユーティリティーを使用して Tivoli Access Manager サーバーを再始動する特定のマシン上のすべての Tivoli Access Manager サーバーを停止してから再始動する場合は、pd_start ユーティリティーを使用します。

pd_start restart

このスクリプトは、すべてのサーバーが始動するのを待ってから、プロンプトを戻します。

pd_start ユーティリティーを使用して Tivoli Access Manager サーバーを停止する特定のマシン上のすべての Tivoli Access Manager サーバーを正しい順序で停止する場合は、pd_start ユーティリティーを使用します。

pd_start stop

スクリプトは、すべてのサーバーが停止するのを待ってから、プロンプトを戻します。

pd_start ユーティリティーを使用してサーバー状況を表示するサーバー状況を表示するには、pd_start コマンドを使用します。

pd_start status

Tivoli Access Manager Servers:Server Enabled Running

pdmgrd yes yeswebseald no nopdacld yes no

Windows システムでのサーバーの始動および停止Microsoft Windows システム上では、「コントロールパネル (Control Panel)」から「サービス (Service)」ウィンドウを使用して、サーバー・プロセスを手動で始動および停止します。この方法が役立つのは、インストールのカスタマイズ時や、トラブルシューティング時です。このユーティリティーを使用する場合は、管理特権が必要です。

Tivoli Access Manager サーバーは、始動と停止をすべて同時に行うこともできますし、個別に行うこともできます。一般的に、サーバーは、正しい順序で停止し、始動する必要があります。


サービス・コントロール・パネルを使用したサーバーの停止および始動自動開始サービスは、スタートアップ構成が「自動」に設定されているときは常に、Tivoli Access Manager サーバーのそれぞれを自動的に始動します。サーバーが始動してしまうと、自動開始サービスは終了します。

個々のサーバーを手動で始動したり、停止したりする場合は、サービス・コントロール・パネルを使用することもできます。

1. Windows の「コントロールパネル」を開きます。

2. 「サービス」アイコンをダブルクリックします。

「サービス」ダイアログが表示されます。

3. リスト・ボックスで、ステップ 4 および 5 に示されている順序に従って、Tivoli Access Manager サーバーを選択します。

4. 次の順序で Tivoli Access Manager サーバーを停止します。

v 許可サーバー


5. 次の順序で Tivoli Access Manager サーバーを始動します。


v 許可サーバー

6. ボックスの右側の該当する制御オプション・ボタン (「開始」、「停止」、「スタートアップ」) をクリックします。

7. Tivoli Access Manager サーバーが自動開始サービスによって自動的に始動しないようにするには、「スタートアップ」ボタンを使用して、そのサーバーを「無効」に設定します。

ブート時のサーバー始動の自動化サーバー始動を自動化するためのパラメーターは、pd.conf 構成ファイルの[pdrte] スタンザに入っています。

ポリシー・サーバーPDMgr パッケージがインストールされていると、システムがリブートするたびに、ポリシー・サーバーが自動的に始動します。

[pdrte]boot-start-ivmgrd = yes

pdmgrd が自動的に始動しないようにする場合は、次のように設定します。

boot-start-ivmgrd = no

許可サーバーPDAcld パッケージがインストールされていると、システムがリブートするたびに、許可サーバー・デーモンが自動的に始動します。

[pdrte]boot-start-ivacld = yes

pdacld が自動的に始動しないようにする場合は、次のように設定します。


boot-start-ivacld = no

ポリシー・サーバー管理ポリシー・サーバーは、ポリシー・データベースまたはデータベースを管理し、各ドメインのほかの Tivoli Access Manager サーバーのロケーション情報を保守します。一般にポリシー・サーバーには、管理または構成はほとんど必要ありません。この節では、アドミニストレーターにできる構成タスクについて説明しています。

v 116 ページの『許可データベースの複製』

v 117 ページの『更新通知スレッド数の設定』

v 118 ページの『通知遅延時間の設定』

許可データベースの複製Tivoli Access Manager ドメイン・アドミニストレーターは、いつでもセキュリティー・ポリシーのドメインへの変更を行えます。ポリシー・サーバーの基本的な役割は、ドメイン・マスター許可データベースに必要な調整を行って、それらの変更が反映されるようにすることです。

ポリシー・サーバーは、マスター許可データベースに変更を行う場合は、この変更に関する通知をすべての許可サーバーへ送信 (レプリカ・データベースとともに) できます。その後で、許可サーバーはポリシー・サーバーからのデータベース更新を要求しなければなりません。

注: さらに、クライアント・サーバーは、一定の間隔でポリシー・サーバーのポーリングを行うことにより、データベース更新を検査できます。たとえば、WebSEAL クライアントの構成のポーリングについては、 IBM Tivoli Access

Manager WebSEAL 管理者ガイドで説明しています。

Tivoli Access Manager を使用すると、ポリシー・サーバーからの更新通知を、自動プロセスまたは手動制御タスクになるように構成できます。auto-database-update-notify パラメーターは ivmgrd.conf 構成ファイルの[ivmgrd] スタンザにあります。デフォルトでは、このパラメーターは以下のように「yes」(更新通知が、ポリシー・サーバーによって自動的に実行される) に設定されています。

[ivmgrd]auto-database-update-notify = yes

この自動的な設定は、データベースの変更の数が少なく、頻繁ではない環境に適しています。更新通知が自動化されるように構成するときは、max-notifier-threadsおよび notifier-wait-time パラメーターを正しく構成することも必要です。max-notifier-threads および notifier-wait-time パラメーターの詳細については117 ページの『更新通知スレッド数の設定』および 118ページの『通知遅延時間の設定』を参照してください。

更新通知が手動で行われるように構成する場合、 pdadmin server replicate コマンドの手動アプリケーションがこのイベントを制御します。

[ivmgrd]auto-database-update-notify = no


この手動の設定は、データベースの変更が頻繁に行われ、多くの変更が含まれる環境に適しています。場合によっては、いくつかのデータベースの変更で多くの更新通知が生成され、マスター・データベースへの継続的な変更であるために、それがすぐに不要になることがあります。これらの不要な通知は、不必要なネットワーク・トラフィックの原因となり、ポリシー更新の要求およびプロセスが続行するためにリソース・マネージャーのパフォーマンスを低下させます。

更新通知を手動で制御することにより、マスター許可データベースへの変更を完全に処理した後で、更新通知を許可サーバーへ送信 (データベース・レプリカとともに) できます。

手動モードの場合、更新通知で通知スレッド・プールが使用されます (自動モードで行われるのと同じ)。そのため、手動モードの設定では、 max-notifier-threadsパラメーターの設定が有効です。 max-notifier-threads パラメーターの詳細については 117 ページの『更新通知スレッド数の設定』を参照してください。

pdadmin server replicate コマンドの使用更新通知が手動で行われるように構成する場合、 pdadmin server replicate コマンドの手動アプリケーションがこのイベントを制御します。

pdadmin server replicate -server test_server

オプションの server-name 引き数 (test_server) が指定されると、そのサーバーだけに、マスター許可データベースへの変更が通知されます。通知および複製の成功または失敗を示す応答が戻されます。

server-name 引き数が指定されていない場合、構成されているすべての許可サーバーが更新通知を受け取ります。成功の応答が示すのは、単にポリシー・サーバーが更新通知の送信を開始したということのみです。応答では、実際の通知および複製プロセスの成功または失敗は示されません。

このコマンドの実行に必要な許可は、/Management/Server オブジェクトに対する「s」です。

pdadmin server replicate コマンドについて詳しくは、IBM Tivoli Access Manager

コマンド・リファレンスを参照してください。

更新通知スレッド数の設定ポリシー・サーバーは、ドメイン内のすべてのデータベース・レプリカの同期化を担当しています。マスター・データベースに変更が加えられると、通知スレッドがこの変更をすべてのレプリカに知らせる作業を行います。そうすると、それぞれのレプリカでは、新しい情報をマスター・データベースからダウンロードする必要があります。

ポリシー・サーバー構成ファイル ivmgrd.conf には、更新通知スレッドの最大数を設定するパラメーターが入っています。このスレッド・プールを使用すると、同時(並列) 通知ができます。

たとえば、30 のレプリカにデータベース変更を同時に通知する場合は、スレッド・プールは少なくとも 30 に設定します。レプリカの数が 30 を超えている場合は、


通知がもう 1 回繰り返されます (この例では、一度に 30)。このパラメーターの値には関係なく、すべてのレプリカへの通知が保証されています。

データベースの変更をできるだけ速やかに知らせることが、更新通知スレッド値のパフォーマンス上の目標です。一般的には、この値は既存のレプリカの数に等しく設定します。この値を設定した結果、単一のスレッド・プールで、すべてのレプリカに対する通知タスクを速やかに達成できるという、パフォーマンス上の利点が得られます。

デフォルトのイベント通知スレッド・プールは、次のように設定されます。

[ivmgrd]max-notifier-threads = 10

『通知遅延時間の設定』も参照してください。

通知遅延時間の設定ポリシー・サーバーは、マスター許可データベースへの変更を行うよう指示されると、デフォルトによる時間を待ってから、データベース・レプリカに通知を送ります。デフォルトの遅延時間は 15 秒に設定されています。この遅延時間は、今後データベースに変更が加えられるたびにリセットされます。

遅延時間の目的は、ポリシー・サーバーが、一連のデータベース変更のたびに、個別にレプリカ通知を送信しないようにすることです。遅延時間は、Tivoli Access

Manager システムが確実に最適なパフォーマンスを得るのに役立ちます。

このパフォーマンス機能は、特に、許可データベースに対してバッチ変更が加えられる環境の場合には重要です。すべての変更が完了するまで、データベース・レプリカに送信されるポリシー変更は有効ではありません。

このデフォルトの通知遅延時間は、ivmgrd.conf 構成ファイルの [ivmgrd] スタンザにある notifier-wait-time パラメーター値 (秒単位) を変更することによって、指定変更することができます。たとえば、次のように表示されます。

[ivmgrd]notifier-wait-time = 20

デフォルトでは、値が 15 秒に設定されています。


第 12 章高可用性

本章では、Tivoli Access Manager が高可用性サービスおよび優れたパフォーマンスを確実に提供するための情報を提供します。

データの保全性Tivoli Access Manager に必要なデータをいつでも確実に利用できます。データは、データの冗長のために、ミラーリングされたデバイス、または新磁気ディスク制御機構 (RAID) により構成されたデバイスに保管できます。また、データはハードウェアまたはソフトウェア・エラーの際にデータを回復できるように、強固なバックアップ・プロセスに従う必要があります。

pdbackup ユーティリティーは、Tivoli Access Manager データをバックアップ、復元、抽出する能力を提供します。このユーティリティーについて詳しくは、IBM


複数サーバー冗長性とより優れたパフォーマンスを提供するために、Tivoli Access Manager に関連するサーバーおよびデーモンを環境内の別のシステムに複製できます。

許可サーバーポリシー・サーバーから作業をオフロードするために 1 つ以上の許可サーバーを使用して、より大きな可用性とパフォーマンスを提供できます。それぞれの許可サーバー、pdacld は、ポリシー・サーバーからポリシー更新を受信するように構成されており、許可決定を下す際に最新データを利用できるようにしています。


第 13 章代行管理

上位のアドミニストレーターは、Tivoli Access Manager を使用して、ドメインを管理する責任を下位のアドミニストレーターに代行委任することができます。この機能は、多数の部門から成る非常に大きなドメインを正常に管理するのに不可欠です。

Tivoli Access Manager は、以下の分野の代行管理をサポートします。

v オブジェクト・スペースのサブリージョン内のリソースの代行管理

管理機能は、オブジェクト・スペースの部分に制限されます。

v グループおよびユーザーの代行管理

管理機能は、ユーザー集団の部分に制限されます。


v 『オブジェクト・スペース管理の代行』

v 123ページの『グループ管理の代行』

v 129ページの『代行管理ポリシーの管理』

オブジェクト・スペース管理の代行ドメインの中での管理責任の分散を管理の代行と呼びます。一般に、多くの部門やリソースの部分が含まれている大きなサイトの場合、要求が増え、管理の代行の必要性が起きてきます。

一般に、大きなオブジェクト・スペースを、これらの部門や部分を表す領域に編成することができます。ドメインの別々の領域はそれぞれ、通常は、その分野の問題点や必要性をよく理解している管理者によって編成され保守されます。

管理代行用オブジェクト・スペースの構造化別個の領域、またはブランチ (該当のブランチに固有のサブ管理責任を実行できる)

を入れるオブジェクト・スペースを構造化します。

122ページの図 24 では、オブジェクト・スペースの Engineering と Publications 領域の両方とも、別々の管理コントロールを必要としています。これらの領域のコントロールは、各領域のルートから始まり、以下のすべてのオブジェクトにまで拡張されます。


デフォルトの管理ユーザーおよびグループTivoli Access Manager には、インストールの際に重要な管理グループが提供されます。これらのユーザーおよびグループについては 31ページの『デフォルトの管理ユーザーおよびグループ』を参照してください。

例: 管理代行大きなオブジェクト・スペースでは、さまざまなサブブランチを管理するために多くの管理ユーザーが必要になる場合があります。この場合、これらの各ブランチへのパス上にあるディレクトリーのアクセス・コントロール・リスト (ACL) に、各アカウントごとに、全探索許可を持つエントリーを含める必要があります。多くの管理ユーザーのいるサイトでは、ACL には、これらの管理アカウントをすべて表すエントリーの長いリストが含まれることになります。

以下の手法を使うと、アドミニストレーター用の多数の ACL エントリーの問題が解決されます。

1. 管理グループのアカウントを作成する。

2. 新しいすべての管理ユーザーをこのグループに追加する。

3. このグループを、ACL エントリー (全探索付き) として、管理の代行を必要とする各サブブランチに通じるディレクトリーに追加する。

4. 各ブランチ・ルート ACL で、各サブブランチに管理グループを作成し、該当するユーザーを適切なサブブランチ管理グループ (b、c、T、およびその他の適切な許可を持つ) を追加する。

5. これで、アドミニストレーターは、管理グループの ACL エントリー (およびその他のエントリー) をルートから除去できるようになります。

これで、ユーザーはルートとその下にあるすべてのオブジェクトに対するコントロールを持つことができます。

図 24. 管理代行用オブジェクト・スペースの構造化


図 25 では、グループ iv-admin にすべての管理ユーザーが含まれています。ユーザー pub-manager は、このグループのメンバーであり、したがってPublications ディレクトリーにナビゲートするのに必要な全探索許可を持っています。

Publications ディレクトリーには、その ACL に、ユーザー pub-manager エントリーが含まれています。 pub-manager は、このブランチの代行アドミニストレーター (適切な許可を持つ) であるため、 pub-manager は、Publications ACL

から iv-admin グループ・アカウント (およびその他の ACL エントリー) を除去して、Web スペースのそのブランチに対する総合的コントロールを取得できます。

グループ管理の代行ユーザーの大規模な集合や複雑な集合を管理するには、特定のグループのユーザーの管理を下位のアドミニストレーターに代行委任できます。アドミニストレーターにグループのポリシー管理コントロールが付与されている場合、そのアドミニストレーターには、そのグループのユーザー・メンバー全員に対するポリシー管理コントロールがあります。

代行グループ管理では次の内容を定義します。

v 特定のグループ (およびそのグループのユーザー・メンバー) に関する管理責任が誰にあるか。

v このアドミニストレーターに付与されるグループおよびユーザー・コントロールのレベル

図 25. 管理の代行の例

第 13 章代行管理 123

この説明で、アドミニストレーターという用語は、一般的なユーザーに認可される責任およびコントロールのことを意味します。代行委任されたアドミニストレーターは通常のユーザーですが、特定の管理タスクを実行する能力が加えられています。

代行グループ管理のセットアップには、以下のステップが必要です。

1. ドメインのメンバーであるユーザーおよびユーザー・タイプの論理的かつ実際的階層を判別します。

2. この階層を反映したグループ・コンテナー・オブジェクトを作成します。

3. これらのコンテナー・オブジェクト内に該当する管理グループを作成します。

4. 該当するユーザーを、必須タスクの実行に必要な特定の許可を割り当てて適切な管理グループに追加します。

グループ・コンテナー・オブジェクトの作成デフォルトでは、Tivoli Access Manager オブジェクト・スペースの /Management

領域には、ドメイン内にグループの階層を編成できる、グループ・コンテナー・オブジェクトがあります。

コンテナー・オブジェクトは、オブジェクト・スペースを別々の機能領域に階層的に編成できる構造指定です。グループ・コンテナー・オブジェクトを使用すると、グループ・タイプのカテゴリーを別々に定義できます。特定のグループ・コンテナー・オブジェクトごとに実際のグループを作成できます。

新しいグループ・コンテナー・オブジェクトを作成するには、pdadmin objectcreate コマンドを使用してください。

pdadmin object create obj-name description type ispolicyattachable {yes|no}

表 5. オブジェクト作成のパラメーター

引き数説明

obj-name 新しいグループ・コンテナー・オブジェクトの絶対パスと名前。パスの先頭は /Management/Groups でなければなりません。

description オブジェクトについて記述したテキスト・ストリング。この情報は、object show コマンドで表示されます。

type type 引き数は、このオブジェクトに関連し、Web Portal Manager

によって表示される特定のグラフィカル・アイコンを識別します。タイプの範囲は 0 ～ 17 です ( 125ページの表 6 を参照)。

ispolicyattachable このオブジェクトに ACL ポリシーを付加できるかどうかを判別します。


表 6. オブジェクト・タイプ



6 - WebSEAL サーバー7 - 未使用8 - 未使用9 - HTTP サーバー

10 - 存在しないオブジェクト11 - コンテナー・オブジェクト12 - リーフ・オブジェクト13 - ポート14 - アプリケーション・コンテナー・オブジェクト

(代行管理に必須)

15 - アプリケーション・リーフ・オブジェクト16 - 管理オブジェクト17 - 未使用

例:

pdadmin object create /Management/Groups/Travel “TravelContainer Object” 14 ispolicyattachable yes

たとえば、pdadmin group create コマンドを使用して、グループ・コンテナー・オブジェクトを作成することもできます。『グループの作成』を参照してください。

pdadmin object create コマンドについて詳しくは、IBM Tivoli Access Manager


グループの作成新しいグループを作成し、オプションでそのグループをグループ・コンテナー・オブジェクトに入れるには、pdadmin group create コマンドを使用してください。既存のコンテナー・オブジェクトがなければ、自動的に作成されます。

pdadmin group create group_name dn cn [group_container]

引き数説明

group_name 新しいグループ・オブジェクトの名前。

dn 新しいグループの識別名。

cn 新しいグループの共通名。

図 26. グループ・コンテナー・オブジェクト


引き数説明

group_container この新しいグループを入れるグループ・コンテナー・オブジェクトの相対パス名。グループ・コンテナー・オブジェクトを指定しない場合、グループは /Management/Groups の下に置かれます。

v 新しく作成したグループ・コンテナー・オブジェクトはすべて、デフォルトの/Management/Groups コンテナーの下に表示されます。別のサブレベルにコンテナーを作成するには、group_container 変数の相対パス名を使用してください。

v group create コマンドを使用して、グループを作成せずにグループ・コンテナー・オブジェクトだけを作成することはできません。

v 新しいグループをオブジェクト・スペースに追加するには、アドミニストレーターは、関連したグループ・コンテナー・オブジェクトを管理する ACL に対して、作成 (N) 許可を持っていなければなりません。

グループ・コンテナー・オブジェクトを指定しない場合は、/Management/Groups

コンテナーを管理する ACL 中に、アドミニストレーター ACL エントリー (作成許可付き) を指定する必要があります。

インストール時に、単一のデフォルト ACL (default-management) が /Management

に付加され、すべてのグループおよびグループ・コンテナーに関する許可を定義します。このコントロールをカスタマイズするには、該当する明示 ACL を追加しなければなりません。

v 複数のグループを 1 つのグループ・コンテナーに追加できます。

グループ・コンテナー・オブジェクト上の ACL は、コンテナー・オブジェクト下にあるグループを (継承により) すべて制御します。コンテナー・オブジェクトとそのグループは、代行責任のあるアドミニストレーターのドメインになります。

v オブジェクト・スペース中の新しいグループの位置は、作成時に固定されます。

グループを作成したら、グループをオブジェクト・スペース (ただし LDAP ではなく) から削除し、次にそのグループを新しい場所にインポートするだけで、ただちにその位置を移動できます (グループ内のユーザーは維持されます)。

pdadmin group create コマンドについて詳しくは、IBM Tivoli Access Manager


例:

pdadmin group create group1 “cn=travel,c=us” Group1 Travel

pdadmin group create group2 “cn=travel,c=us” Group2 Travel


グループ管理に影響する ACL ポリシーユーザーのグループを制御する許可を取得するには、該当する ACL をグループ・オブジェクトかグループ・コンテナー・オブジェクトに付加します。

ACL は、上位アドミニストレーターが構成して付加するもので、そのグループの代行アドミニストレーターが実行しなければならないアクションに該当する許可が含まれている必要があります。

グループがオブジェクト・スペースの /Management/Groups セクションの下にある場合は、ACL を /Management/Groups かグループ自体に付加する必要があります。

グループがグループ・コンテナー・オブジェクトの下にある場合は、ACL をそのグループ・コンテナー・オブジェクトかグループ自体に付加する必要があります。ACL を /Management/Groups コンテナー・オブジェクトに付加すると、ACL はそのオブジェクト・スペース下にあるほかのグループ・コンテナー・オブジェクトすべてに影響を与えます。

上記のいずれかの場所に ACL を付加する (または継承する) と、以下のことが判別されます。v グループ・オブジェクトとグループ中のユーザーを誰が制御するのかv グループとそのユーザーにどのアクションを実行できるか。

たとえば、図 27 で、/Management/Groups/Travel 上の ACL は、group1 と group2

の両方の制御に対する許可を定義します。

グループ管理に該当する操作と ACL 許可は以下のとおりです。

操作許可

作成 (新しいグループの) インポート (グループ・データをユーザー・レジストリーから)

N (作成)

削除 (グループの) d (削除)

表示 (グループの詳細の) v (表示)

変更 (グループ記述の) m (変更)

追加 (既存のユーザーをグループに) A (追加)

除去 (グループのユーザー・メンバーを) A (追加)

図 27. 特定グループ・コンテナー下の新しいグループの作成


該当する pdadmin ユーティリティー・コマンド、または Web Portal Manager を使用して、これらの操作を実行できます。

重要追加 (「A」) 許可は、これを使用すると既存のユーザーをグループに追加できるので、強力です。外部のユーザーをグループに入れると、そのグループのアドミニストレーターはそのユーザーのコントロールを得ることになります (また、そのユーザーがメンバーになっている他のグループのアドミニストレーターと、そのユーザーのコントロールを共用することもあります)。ユーザーとグループの編成やコーポレート・ポリシーを担当する上位アドミニストレーターだけにこの許可を付与するのが最善です。

「A」許可は強力であるため、それをアドミニストレーターに割り当てるときは注意してください。「A」許可を持つ代行アドミニストレーターには、「m」、「W」、「N」、または「d」許可を持たせるべきではありません。

注:v 作成 (N) 許可は、/Management/Groups またはグループ・コンテナー・オブジェクトに付加された ACL に置く必要があります。

v リストされている他の許可はすべて、/Management/Groups、グループ・コンテナー・オブジェクト、またはグループ・オブジェクト自体に付加された ACL に入れることができます。

ユーザー管理に影響する ACL ポリシーあるユーザーがメンバーになっているグループ上に該当する許可が定義されていれば、グループ・アドミニストレーターはそのユーザーに関するアクションを実行できます。

ユーザー管理に該当する操作と ACL 許可は以下のとおりです。

操作許可

作成 (指定した 1 つ以上のグループ内の新規ユーザー) インポート (ユーザー・レジストリーからのユーザー・データ)

N (作成)

削除 (ユーザーの) d (削除)

表示 (ユーザーの詳細の) v (表示)

変更 (ユーザー記述の) m (変更)

有効なアカウント m (変更)

パスワードのリセット W (パスワード)

有効なパスワード W (パスワード)

該当する pdadmin ユーティリティー・コマンド、または Web Portal Manager を使用して、これらの操作を実行できます。


注:v 作成 (N) 許可 (グループ ACL またはグループ・コンテナー ACL 内の) を使用すると、ユーザーを作成またはインポートし、そのユーザーを制御下のグループに入れることができます。

user create user1 “cn=user1,c=us” user1 user1 adcde group1user import user2 “cn=user2,c=us” group1

v グループを指定しないでユーザーを作成することもできます。しかしこの場合、作成 (N) 許可は、/Management/Users コンテナー・オブジェクトの ACL に置く必要があります。

/Management/Users に付加された ACL は、すべてのユーザー (グループのメンバーかどうかに関係なく) の許可を定義します。

v あるユーザーがメンバーになっているグループ中に該当する許可が定義されていれば、グループ・アドミニストレーターはそのユーザーに関する操作を実行できます。

v ユーザーがいずれのグループのメンバーでもない場合、アドミニストレーターは、そのユーザーに操作を実行するために、/Management/Users の ACL 内に適切な許可を持つ必要があります。

v パスワード (W) 許可は、パスワードを失ったユーザーを助けなければならないヘルプ・デスク・オペレーターに適しています。

このオペレーターは、失われたパスワードをいずれかの既知の値にリセットしてから、user modify password-valid (pdadmin) を no に設定できます。このアクションを行うと、次回のログイン時にユーザーはパスワードを強制的に変更させられます。ユーザーに対して、user modify password-valid を「no」に設定することは、グローバル設定である max-password-age ポリシーによってパスワードが無効であることを示していません。ポリシーの set max-password-ageコマンドは、パスワードの有効期限が切れるまでの期間を設定します。

v 表示 (v) 許可は、user list、user list-dn、user show groups、group list、および group list-dn コマンドの出力を制御するときに使用します。表示許可は、これらのコマンドの出力にフィルター操作を行うのに使用します。ユーザーが、コマンドによって戻されるグループまたはユーザーに対する表示許可を持っていない場合、そのグループまたはユーザーはフィルターで出力から除かれます。

代行管理ポリシーの管理前の 2 つのセクションでは、ドメインのリソースを保護するためにセキュリティー・ポリシーの管理を代行する方法と、それらのリソースにアクセスするユーザーの管理を代行する方法についてそれぞれ説明しました。代行管理のこれら 2 つの個々の局面は、完全な代行管理セキュリティー・ポリシーを確立するために、しばしば結び付ける必要があります。

ただし、これを行う際には十分な注意が必要です。特に、お互いの組み合わせでどの許可を付与するかに注意しなければなりません。

たとえば、「A」許可は、最も強力なトラステッド・アドミニストレーターに対する場合を除き、「m」、「W」、または「d」許可と一緒に付与しないでください (おそらく、まったく)。アドミニストレーターに「A」および「W」の両方を付与する


と、結果的にそのアドミニストレーターはそれらの許可を持っているグループにすべてのユーザーを追加してから、そのユーザーのパスワードを変更できます。あらゆるユーザー (より上位のアドミニストレーターや、 sec_master さえも含む) を選ぶことができます。この方法では、悪意のあるアドミニストレーターが上位ユーザーとしてログオンすることにより、システムへの全アクセス権を持つことが可能になります。

「A」と「m」許可を一緒に付与するのも同じです。ただし、この両方の許可を持つアドミニストレーターが、グループ内のアカウントを使用不可にするためにこの組み合わせを必要とする場合を除きます。「A」と「d」許可を一緒に付与するのも同じです。ただし、この両方の許可を持つアドミニストレーターが、グループ内のユーザー ID を削除するためにのみこの組み合わせを必要とする場合を除きます。

完全な代行管理ポリシーを定義する場合、これらの制約によって特定の構造が示され、ユーザー・グループに使用されます。

ユーザー管理タスク (新しいユーザーの作成、ユーザーの削除、ユーザーのパスワードのリセットなど) を代行するのに使用する、グループを確立しなければなりません。ユーザー管理タスクを実行するアドミニストレーターは、管理を受け持っているユーザーの作成、削除、変更 (使用不可または記述の変更)、パスワードのリセットまたは無効化、および表示を行うには、「N」、「d」、「m」、「W」、および「v」許可を持っていなければなりません。これらのグループはユーザー管理の代行のみに使用します。これらのグループはドメイン内の他のリソースの保護には使用しないでください。

ドメイン内の保護リソース用の、セキュリティー・ポリシーの管理を代行するのに使用するグループも確立しなければなりません。これらのグループのセキュリティー・ポリシーを制御するアドミニストレーターには「A」および「v」許可が必要ですが、「N」、「d」、「m」、または「W」許可は必要ありません。これらのグループは、保護に必要な実リソースへのアクセスを制御するのに使用します。

例:

Web スペースをインターネットでアクセス可能にするとします。その場合、リソースは以下のようでなければなりません。

v 公開アクセス可能

v 顧客および従業員のみアクセス可能

v 従業員のみアクセス可能

スペースは以下のように構造化できます。

/WebSEAL/www.company_xyz.com/

customers/sales/

www.company_xyz.com の Web スペースのルートの ACL を使用すると、Web スペース内のすべてに公開アクセスが許可されます。 customers の ACL を使用すると、顧客および販売担当員にアクセスが許可されます。sales の別の ACL を使用すると、販売担当員のみにアクセスが許可されます。これらの ACL は以下の例のように表示されます。


public-accessuser sec_master abcTdmlrxany-other Tlrxunauthenticated Tlrx

customer-accessuser sec_master abcTdmlrxgroup customers Tlrxgroup sales Tlrxany-otherunauthenticated

sales-accessuser sec_master abcTdmlrxgroup sales Tlrxany-otherunauthenticated

これらの ACL はそれぞれ以下の場所に付加されます。

/WebSEAL/www.company_xyz.com/WebSEAL/www.company_xyz.com/customers/WebSEAL/www.company_xyz.com/sales

以下の代行ユーザー管理ポリシーを持っているとします。販売担当員 (sales グループのメンバー) は、顧客の新規アカウントを作成し、Web スペースの customers部分へのアクセス権を顧客に付与できます。新規販売担当員のアカウントを管理できるのは、アドミニストレーター (sales-admin グループのメンバー) のみです。

以下のグループ構造は、このポリシーをインプリメントしています。

/Management/Groups/

sales <- ACL sales-adminsales-users <- ACL sales-users-admincustomers <- ACL customers-admincustomers-users <- ACL customers-users-admin

sales-admin ACL は sales グループのメンバーシップを管理するのに使用され、次にこの sales グループが、Web スペースの販売担当員のみの部分へのアクセスを制御するのに使用されます。 sales-admin グループに唯一必要な許可は、このグループからユーザーを追加および削除できることです。アドミニストレーターにとっては、表示 (v) 許可も役立ち、グループ・メンバーシップおよびグループ内のユーザーを表示することができます。

sales-admingroup super-admin Tabcgroup admin TAv

sales-users-admin ACL は、sales-users グループへの付加によって、sales-users グループのメンバー (つまり、これも sales-admin グループ) をだれが管理できるかを制御できます。

sales-users-admingroup super-admin Tabcgroup admin TNWdmv

同様に、customers-admin ACL は customers グループのメンバーシップを管理するのに使用され、次にこの customers グループが、Web スペースの顧客のみの部分へのアクセスを制御するのに使用されます。

customers-admingroup super-admin Tabcgroup sales TAv


customers-users-admin ACL は、 customers-users グループのメンバーを (つまり、 sales グループ) を管理する人を制御 (customers-users グループへの付与により) します。 sales-admin グループのメンバーにも、顧客を管理させることができます。

customers-users-admingroup super-admin Tabcgroup sales TNWdmvgroup admin TNWdmv

各 ACL では、super-admin グループ・エントリーに、付加、ブラウズ、およびコントロールの許可が付与されることに注意してください。 super-admin グループのメンバーは、これらの ACL の管理を受け持っています。


第 14 章ロギングと監査

Tivoli Access Manager は、サーバー・アクティビティーのロギングと監査、およびイベント・ログを提供する機能を備えています。


v 『サーバーのロギングと監査の概要』

v 135ページの『Base 保守サービス・メッセージのロギング』

v 137ページの『Tivoli Access Manager監査証跡ファイル・パラメーター』

v 139ページの『監査証跡ファイル・フォーマット』

v 141ページの『監査証跡ファイルの内容』

v 150ページの『イベント・ロギング』

サーバー・アクティビティーのロギングと監査ログ・ファイルは、Tivoli Access Manager サーバーが生成するエラー・メッセージおよび警告メッセージを取り込むことができます。監査証跡ファイルは、Tivoli

Access Manager サーバーで発生する、許可、認証、管理イベントを取り込むことができます。

サーバーのロギングと監査の概要ログ・ファイルと監査証跡ファイルの内容は、Tivoli Access Manager サーバーのアクティビティーのモニターおよびトラブルシューティング時に、情報源として役立ちます。監査を構成するとき、これを収集する監査イベントのソースとして考えてください。ソースの選択肢は、選択肢 (許可 (azn)、認証 (authn)、または管理(mgmt)) の組み合わせ、またはすべてです。

イベント・ロギングを構成する場合は、これを「ログ・イベントの行き先はどこですか?」という質問に応答する宛先として考えてください。　宛先の選択肢は、選択肢 (リモート、コンソール、ファイル、またはパイプ) の組み合わせまたはすべてです。

Tivoli Access Manager イベントの取り込みを構成するために、プログラムの構成(.conf) ファイルの [aznapi-configuration] スタンザの 2 つのパラメーターのうち 1 つまたは両方を指定できます。

v 監査証跡ファイル

監査には、3 つのレベル (azn、authn、および mgmt) があります。同時に 3 つの監査イベントのタイプをすべて収集できます。監査イベントは、該当のサーバーの特定のアクティビティーを文書化する (記録する) 監査レコードとして保管されます。各監査アクティビティーは、監査イベントと呼ばれます。ファイルに保管される監査イベント・レコードのコレクションは、監査証跡と呼ばれます。各Tivoli Access Manager サーバーは、それ自体の監査証跡ファイルを保持します。

以下のエントリーが監査に必要です。


logaudit = {yes|no}auditcfg = {azn|authn|mgmt}auditlog = server_logfile_namelogsize = { -1|0|log_byte_size(byte size of log prior to rollover)}logflush = num_seconds to flush event queue

例:

[aznapi-configuration]logaudit = yesauditcfg = aznauditcfg = authnauditlog = /var/PolicyDirector/audit/pdmgrd.loglogsize = 0logflush = 20

これらパラメーターについては、 137ページの『Tivoli Access Manager監査証跡ファイル・パラメーター』にそれぞれ説明されています。

v イベント・ログ

イベント・ログでは、log agents という概念が使用されます。現在、4 つのタイプの宛先 (コンソール (stdout| stderr) ログ・エージェント、ファイル・ログ・エージェント、パイプ・ログ・エージェント、およびリモート・ログ・エージェント) が、ロギング・イベントの取り込みのためにサポートされています。 logcfg

パラメーター

たとえば、イベント・ロギングに必要なエントリーの一般的な形式は以下のとおりです。

[aznapi-configuration]logcfg = category:{stdout|stderr|file|pipe|remote} \[[param[=value]][param[=value]]]

パラメーターは、カテゴリー、イベントの宛先、実行する監査のタイプにより異なります。logcfg パラメーターの具体的な例については、以下のイベント・ロギング宛先を参照してください。

– 154ページの『コンソールのロギング』

– 155ページの『ファイルのロギング』

– 159ページの『パイプ・ロギング』

– 159ページの『リモート・ロギング』

監査証跡ファイル監査証跡ファイルは、Tivoli Access Manager サーバーがサーバー・アクティビティーのレコードを保管するのに使用します。特定のサーバー・イベントの出力は、レコードによって呼び出されます。監査証跡とは、サーバー・アクティビティーを文書化する複数のレコードの集合のことです。 Tivoli Access Manager 監査証跡ファイルは、すべて ASCII フォーマットです。

Tivoli Access Manager 監査証跡ファイルは、以下のサーバーのイベントを記録します。



137ページの『Tivoli Access Manager監査証跡ファイル・パラメーター』を参照してください。


139ページの『監査証跡ファイル・フォーマット』を参照してください。141ページの『監査証跡ファイルの内容』を参照してください。

文書化規則: install_pathこの章を通じて使用する install_path 変数は、オペレーティング・システム・プラットフォームに応じて、次のように解釈します。

UNIX: /opt/PolicyDirector/

Windows: ¥Program Files¥Tivoli¥Policy Director

このパス名は、UNIX では固定されており変更できません。

Windows オペレーティング・システムの場合は、Tivoli Access Manager ソフトウェアをインストールする際に install_path を定義できます。

Base 保守サービス・メッセージのロギングTivoli Access Manager Base 保守サービス・メッセージは、Tivoli Access Manager

Base ルーティング・ファイルによって制御されます。ルーティング・ファイルは、追加情報がコメント行の形式で入っている ASCII ファイルです。この構成ファイル内のエントリーによって、ログに記録される保守容易性メッセージのタイプが決まります。コメント文字 (#) を除いて、エントリーを使用できるようにしてください。

表 7. UNIX および Windows ルーティング・ファイル

ディレクトリー

UNIX:

/opt/PolicyDirector/etc/

Windows:

C:¥Program Files¥Tivoli¥Policy Director¥etc¥

デフォルト・エントリー

UNIX:

FATAL:STDOUT:-;FILE:/var/PolicyDirector/log/msg__fatal.logERROR:STDOUT:-;FILE:/var/PolicyDirector/log/msg__error.logWARNING:STDOUT:-;FILE:/var/PolicyDirector/log/msg__warning.logNOTICE:FILE.10.100:/var/PolicyDirector/log/msg__notice.log#NOTICE_VERBOSE:STDOUT:-;FILE:/var/PolicyDirector/log/msg__verbose.log

Windows:

FATAL:STDERR:-;FILE:%PDDIR%/log/msg__fatal.logERROR:STDERR:-;FILE:%PDDIR%/log/msg__error.logWARNING:STDERR:-;FILE:%PDDIR%/log/msg__warning.logNOTICE:FILE.10.100:%PDDIR%/log/msg__notice.log

注: Windows システムでは、特殊な環境変数 PDDIR が、実行時に Tivoli

Access Manager インストール・ディレクトリーに設定されます。

デフォルトでは、Tivoli Access Manager Base がフォアグラウンドで実行する際に、メッセージが以下の方法で処理されます。

1. メッセージが画面に送られる (STDOUT、STDERR)。

2. メッセージが、log ディレクトリーの該当する構成済みログ・ファイル・エントリーに送られる (msg__fatal.log、msg__error.log、msg__warning.log。

第 14 章ロギングと監査 135

デフォルトでは、Tivoli Access Manager Base がバックグラウンドで実行する際に、メッセージが以下の方法で処理されます。

1. メッセージが STDOUT および STDERR からリダイレクトされ、該当するサーバー構成ファイルの [server_name] スタンザで定義された該当するサーバー・ログ・ファイルに送られる。

サーバー構成ファイルログ・ファイルの場所

ポリシー・サーバー

(pdmgrd)

ivmgrd.conf UNIX:[ivmgrd]

log-file=/var/PolicyDirector/log/

msg__ivmgrd.log

Windows:[ivmgrd]

log-file=install_path¥log¥msg__ivmgrd.log

許可サーバー

(pdacld)

ivacld.conf UNIX:[ivacld]

log-file=/var/PolicyDirector/log/msg__ivacld.log

Windows:[ivacld]

log-file=install_path¥log¥msg__ivacld.log

2. メッセージは、log ディレクトリーの該当する構成済みログ・ファイル・エントリーにも送られる (msg__fatal.log、msg__error.log、msg__warning.log、msg__notice.log)。これは、ルーティング構成ファイル内に構成されています。

135ページの表 7 で示されるように、FILE 構文はルーティング・ファイルのデフォルト・エントリーの一部であり、ログ・ロールオーバーおよびファイルのリサイクルを制御します。

FILE.max_files.max_records

ここで以下を指定します。

v max_files で、使用するファイル数を指定します。

v max_records で、ファイル当たりの最大エントリー数を指定します。

msg__notice ファイルは、それぞれ最大 100 エントリーの 10 ファイルが作成されていることを意味する FILE.10.100 で構成されています。このファイルは、以下の名前が付けられています。

msg__notice.log.1msg__notice.log.2...msg__notice.log.10

msg__notice ファイルを除き、デフォルト・エントリーでは max_files およびmax_records を指定しません。構成ログ・ファイルのデフォルトの FILE エントリーで、ログ・ファイルがリサイクルもロールオーバーもされないことを指定します。ファイルは、無制限に継続して大きくなるように構成されます。無制限に大きくなるように構成した場合、ディスク・スペースに注意する必要があります。ディ


スク・スペースを使い尽くした場合、既存のログ・ファイルを削除するか、ログ・ファイルを定期的に枝取りする必要があります。

メッセージは、最後のファイルが限界に達するか、サーバーが停止して再始動したときに、折り返して先頭ファイルに循環します。ログ・ファイルが再利用される際、既存のレコードは上書き (消去) されます。

Tivoli Access Manager監査証跡ファイル・パラメーター監査は、Tivoli Access Manager 許可プロセスのセキュア操作に影響する、システム・アクティビティーについてのデータのコレクションとして定義されます。セキュリティー関連の監査可能アクティビティーが生じたときは、常に各 Tivoli Access

Manager サーバーで監査イベントを取り込めます。

監査イベントは、該当のサーバーの特定のアクティビティーを文書化する (記録する) 監査レコードとして保管されます。各監査アクティビティーは、監査イベントと呼ばれます。ファイルに保管される監査イベント・レコードのコレクションは、監査証跡と呼ばれます。各 Tivoli Access Manager サーバーは、それ自体の監査証跡ファイルを保持します。

Tivoli Access Manager サーバーには次のものがあります。



v 許可 ADK を使用したユーザー開発のアプリケーション

Tivoli Access Manager サーバーの監査証跡ファイルを構成するパラメーターは、各server-name.conf ファイルの [aznapi-configuration] スタンザにあります。

サーバー server-name 構成ファイル

ポリシー・サーバー pdmgrd ivmgrd.conf

許可サーバー pdacld ivacld.conf

監査の使用可能化と使用不能化監査証跡の記録は、サーバーごとに使用可能になります。監査証跡の記録は、特定サーバーの構成ファイルの [aznapi-configuration] スタンザで logaudit スタンザ・エントリー値を設定することによって使用可能になります。デフォルトでは、監査は使用不可です。

[aznapi-configuration]logaudit = no

「yes」の値で、そのサーバーの監査は可能になります。たとえば、次のとおりです。

[aznapi-configuration]logaudit = yes

ログ・ファイルの場所の指定サーバーごとの監査証跡ファイルは、デフォルトでは audit.log と呼ばれ、特定サーバーのログ・ディレクトリーに入っています。各サーバーの構成ファイル内のauditlog スタンザ・エントリー値は、監査証跡ファイルの場所を指定します。


サーバーログ・ファイルの場所

ポリシー・サーバー

(pdmgrd)

UNIX:

auditlog=/var/PolicyDirector/audit/pdmgrd.log

Windows:

auditlog=C:¥pd¥audit¥pdmgrd.log

許可サーバー

(pdacld)

UNIX:

auditlog=/var/PolicyDirector/audit/pdacld.log

Windows:

auditlog=C:¥pd¥audit¥pdacld.log

監査ファイル・ロールオーバーしきい値の指定logsize スタンザ・エントリー値は、各監査証跡ファイルが大きくなれる最大サイズを指定し、最初は以下の値 (バイト単位) で構成されます。

[aznapi-configuration]logsize = 2000000

監査証跡ファイルが指定された値 (そのロールオーバーしきい値として知られる)

に到達すると、現行の日付とタイム・スタンプが付加された、同じ名前のファイルに既存のファイルのバックアップがとられます。その後新しい監査証跡ファイルが開始します。

各種指定可能な logsize 値は、以下のように解釈されます。

v logsize 値がゼロ未満 (< 0) ならば、監査プロセスの起動ごと、かつそのインスタンスから 24 時間ごとに新規監査証跡ファイルが作成されます。

v logsize 値がゼロに等しい (= 0) 場合は、ロールオーバーは実行されず、監査証跡ファイルは無限に拡大し続けます。監査証跡ファイルがすでに存在する場合、新しいデータがそこに追加されます。

v logsize 値がゼロより大きい (> 0) 場合は、監査証跡が、構成されたしきい値に達したときにロールオーバーが実行されます。監査証跡ファイルが始動時にすでに存在する場合、新しいデータがそこに追加されます。

監査ファイル・バッファーをフラッシュする頻度の指定監査証跡ファイルは、バッファーに入れられるデータ・ストリームに書き込まれます。監査証跡ファイルをリアルタイムでモニターしている場合は、サーバーが監査証跡ファイル・バッファーのフラッシュを強制する頻度を変更することができます。

デフォルトでは、監査証跡ファイルは 20 秒ごとにフラッシュするように構成されています。

[aznapi-configuration]logflush = 20

負の値を指定した場合は、監査証跡ファイルがフラッシュされる時点の判別に、絶対値が使用されます。


監査イベントの指定監査イベントは、それらを生成するサーバーの機能性によってカテゴリー化されます。 Tivoli Access Manager サーバー全体に共通する機能性もあれば、サーバー固有の機能性もあります。サーバー機能性の各タイプは、監査タグと関連しています。

監査タグサーバーの機能性

authn 信任状獲得の認証監査。

azn 許可イベント監査

mgmt 管理コマンド監査

各 Tivoli Access Manager サーバーを構成して、監査イベントを選択してカテゴリー別に取り込むことができます。たとえば、以下の構成は、認証イベントのみを取り込み、POP 設定で使用可能になったすべての許可監査を指定変更するなど、他のすべてのイベントの取り込みを使用不可にします。

[aznapi-configuration]auditcfg = authn

以下に、認証および許可監査を使用可能にする設定を示します。その他すべての監査カテゴリーは、行をポンド記号 (#) で開始することにより行をコメント化して使用不可になっています。

[aznapi-configuration]auditcfg = authnauditcfg = azn#auditcfg = mgmt

デフォルトでは、監査タグが構成されていないプロセスに監査が可能である場合は、すべての監査可能イベントが取り込まれます。

次の表に、特定の Tivoli Access Manager サーバーごとに取り込める、監査イベント (監査タグによって示される) を示します。

監査タグ pdmgrd pdacld authadk

authn X X X

azn X X X

mgmt X

監査証跡ファイル・フォーマット監査イベントは、Extensible Markup Language (XML) スタイル・タグを使用して、標準形式で監査証跡に取り込まれます。 XML はデータの表示ビューの送達のための単なる中間ステップですが、XML ファイルは ASCII 形式で、さらに分析できるように、直接読み取ったり他の外部解析エンジンに渡したりすることができます。

監査証跡全体は複数の XML 文書。ファイル内の各監査イベントは、個別の XML

データ・ブロックとして書き込まれます。各データ・ブロックは、標準 XML 構文のルールに準拠します。


監査の管理者として、自分の基準にしたがってイベントを選択し、取り出すことが必要です。これには、適切な文書タイプ定義 (DTD) またはスキーマを、使用中の分析ツールに適用することによって、各イベントを再フォーマット設定することが含まれる場合があります。 DTD は、取り込めるデータの記述を提供する中間形式です。

推奨 DTD を以下に示します。

<!ELEMENT event (date, outcome, originator, accessor, target, data*)><!ATTLIST event

rev CDATA "1.1"link CDATA #IMPLIED >

<!ELEMENT date (#PCDATA)><!ELEMENT outcome (#PCDATA)><!ATTLIST outcome

status CDATA #IMPLIED><!ELEMENT originator (component, event, location)><!ATTLIST originator

blade CDATA #REQUIRED><!ELEMENT component rev CDATA “1.0”><!ELEMENT action (#PCDATA)><!ELEMENT location (#PCDATA)><!ELEMENT accessor (principal*)><!ATTLIST accessor

name CDATA #REQUIRED><!ELEMENT principal (#PCDATA)><!ATTLIST principal

auth CDATA #REQUIRED><!ELEMENT target (object, process?, azn?)><!ATTLIST target

resource CDATA #REQUIRED><!ELEMENT object (#PCDATA)><!ELEMENT process (pid, rid, eid, uid, gid)><!ATTLIST process

architecture (unix | nt) ’unix’><!ELEMENT pid #PCDATA><!ELEMENT rid #PCDATA><!ELEMENT eid #PCDATA><!ELEMENT uid #PCDATA><!ELEMENT gid #PCDATA><!ELEMENT azn (perm, result, qualifier)><!ELEMENT perm #PCDATA><!ELEMENT result #PCDATA><!ELEMENT qualifier #PCDATA><!ELEMENT data #PCDATA><!ATTLIST data

tag CDATA #REQUIRED>

Tivoli Access Manager 監査は標準のレコード・フォーマットを使用するので、すべてのフィールドが、記録されるすべてのイベントに関連しているというわけではありません。一般的に、各イベントは、プリンシパルがターゲット・オブジェクトで試行するアクションの結果を取り込みます。

アクションについての情報、プリンシパルの信任状、ターゲット・オブジェクト、および結果は、監査レコードの共通形式ヘッダーに取り込まれます。特定のイベントに関連しないフィールドには、デフォルト値が入っている場合があります。追加のイベント固有情報も、レコード末尾のフリー・フォーマット・データ域に記録できます。

レコード内の特定のデータ値の意味をデコードするには、Tivoli Access Manager コードおよびアーキテクチャーの高度な知識が必要となる場合があります。

結果フィールドの状況属性結果フィールドには、常に、Tivoli Access Manager 状況コードおよび結果の値が入っています。考えられる結果としては、次のものがあります。

0 = SUCCESS1 = FAILURE2 = PENDING3 = UNKNOWN

pdadmin errtext コマンドを使用すると、Tivoli Access Manager 状況コード (次の例では 412668954) を解釈することができます。

<outcome status=”412668954”>1</outcome>

ターゲット・フィールドのリソース属性ターゲット・フィールドのリソース属性は、ターゲット・オブジェクトの広範囲のカテゴリー化を表します。

0 = AUTHORIZATION1 = PROCESS2 = TCB3 = CREDENTIAL5 = GENERAL6 = APPLICATION7 = AUTHENTICATION

監査証跡ファイルの内容このセクションでは、監査証跡ファイルの内容について説明します。

v 『許可監査レコード』

v 143ページの『認証監査レコード』

v 145ページの『管理監査レコード』

許可監査レコード許可は、Tivoli Access Manager サーバーの 1 次機能です。許可監査レコードを取り込めるのは、Tivoli Access Manager 許可ポリシー・データベース (保護オブジェクト・スペース) 内のターゲット・オブジェクトに、監査機能を使用可能にするPOP が付加されているときです。

91ページの『第 9 章保護オブジェクト・ポリシーの管理』を参照してください。

「azn」を、サーバーの構成ファイルの [aznapi-configuration] スタンザの監査構成リストに追加することによって、特定のサーバーに対して監査を構成できます。

[aznapi-configuration]auditcfg = azn

以下のレコードは、ユーザー許可信任状を取得するための監査レコードの例です。

<event rev="1.1"><date>2001-11-14-16:25:08.341+00:00I-----</date><outcome status="0">0</outcome><originator blade="pdmgrd"><component rev=”1.1”>azn</component><action>0</action><location>phaedrus</location>


</originator><accessor name=""><principal auth="IV_LDAP_V3.0">sec_master</principal></accessor><target resource="3"><object>IV_LDAP_V3.0:sec_master</object></target><data>azn_id_get_creds</data></event>

以下のレコードは、ユーザー fred の許可信任状を取得する試みが失敗した監査レコードの例です。

<event rev="1.1"><date>2001-11-14-16:25:08.341+00:00I-----</date><outcome status="268809242">1</outcome><originator blade="pdmgrd"><component rev=”1.1”>azn</component><action>0</action><location>phaedrus</location></originator><accessor name=""><principal auth="IV_LDAP_V3.0">fred</principal></accessor><target resource="0"><object></Management></object><azn><perm>64</perm><result>0</result><qualifier>0</qualifier></azn></target><data></data></event>

以下は、許可 (azn) コンポーネントの監査開始および監査停止イベント・レコードのサンプルです。省略符号のところは、監査の開始と終了の間にログ記録された追加イベントを表します。

<event rev="1.1"><date>2001-11-14-16:25:08.341+00:00I-----</date><outcome status="0">0</outcome><originator blade="pdmgrd"><component rev=”1.1”>azn</component><action>0</action><location>phaedrus</location></originator><accessor>invalid</accessor><target resource="5"><object></object></target><data><audit event="Start"/></data></event>...<event rev="1.1"><date>2001-12-10-20:58:16.584+00:00I-----</date><outcome status="0">0</outcome><originator blade="pdmgrd"><component rev=”1.1”>azn</component><action>0</action><location>phaedrus</location></originator><accessor>invalid</accessor><target resource="5"><object></object></target><data><audit event="Stop"/></data></event>


認証監査レコードプリンシパルの認証は、信任状獲得中に外部の Tivoli Access Manager に対して実行されます。監査レコードは、Tivoli Access Manager がその種の認証の試みの成否を記録するのに取り込むことができます。

「authn」を、サーバーの構成ファイルの [aznapi-configuration] スタンザ内の監査構成リストに追加することによって、認証の試みの監査を構成できます。

[aznapi-configuration]auditcfg = authn

次に、非認証ユーザー用の、WebSEAL からログ記録される認証イベントの例を示します。

<event rev="1.1"><date>2001-11-14-23:04:26.630+00:00I-----</date><outcome status="0">0</outcome><originator blade="webseald"><component rev="1.1">authn</component><action>0</action><location>phaedrus</location></originator><accessor name=""><principal auth="invalid"></principal></accessor><target resource="7"><object></object></target><data></data></event>

次に、WebSEAL からログ記録される、認証されたユーザー用の認証イベントのサンプルを示します。

<event rev="1.1"><date>2001-11-14-15:56:06.551+00:00I-----</date><outcome status="0">0</outcome><originator blade="webseald"><component rev="1.1">authn</component><action>0</action><location>phaedrus</location></originator><accessor name=""><principal auth="IV_LDAP_V3.0" domain="Default">testuser2</principal></accessor><target resource="7"><object></object></target><data></data></event>

次に、WebSEAL からログ記録される認証の (パスワードの期限切れによる) 失敗のサンプルを示します。



次に、WebSEAL からログ記録される、無効なログインを試みる回数が多すぎることによる (3 回ストライク・ポリシー) 認証の失敗イベントのサンプルを示します。


次に、WebSEAL からログ記録される、正常なパスワード変更のサンプルを示します。

<event rev="1.1"><date>2001-11-14-16:25:54.543+00:00I-----</date><outcome status="0">0</outcome><originator blade="webseald"><component rev="1.1">authn</component><action>0</action>

<location>phaedrus</location></originator><accessor name=""><principal auth="passwd-ldap" domain="Default">testuser2</principal></accessor><target resource="7"><object></object></target><data></data></event>

表 8 に、認証の試みが失敗した場合に戻される認証エラー・コード、およびその<data> エレメント構造を示します。

表 8. 認証エラー

エラー・タイプエラー・タイプ (16進数)

エラー・タイプ (10進数)

生成される XML

パスワード失敗 132120c8 320938184 <data>パスワード失敗: user</data>

アカウントのロックアウト

13212132 320938290 <data>アカウントのロックアウト:

user</data>

一般的な失敗その他すべてその他すべて <data><username>

user</username>

</data>

アカウント・ロックアウト (3 回ストライク・ポリシー) などの監査されたイベントの原因を決定するには、上記の表に示されるエラー・コードを取得します。エラー・コードは、<outcome status> タグの監査結果に入っています。

<outcome status>"13212132">0</outcome>


pdadmin errtext コマンドを呼び出すと、エラー・コードが結果の原因を受け取ります。たとえば、次のとおりです。

> pdadmin errtext 13212132This account has been temporarily locked out due to too manyfailed login attempts

認証イベントのアクション・コード: 認証イベントの監査レコードには、認証イベントとパスワード変更イベントを識別するアクション・コードが入っています。認証のアクション・コードは 0 です。

管理監査レコードポリシー・サーバーの責任には、マスター許可ポリシー・データベースの維持が含まれます。このデータベースには、ドメインの保護オブジェクト・スペースの記述、アクセス・コントロール・リスト (ACL) および保護オブジェクト・ポリシー(POP)、これらのポリシーのオブジェクトへの付加場所が含まれます。

「mgmt」を、ポリシー・サーバーの構成ファイル (ivmgrd.conf) の[aznapi-configuration] スタンザ内の監査構成リストに追加することによって、ポリシー・サーバー・アクティビティーの監査を構成できます。

[aznapi-configuration]auditcfg = mgmt

以下は、次の pdadmin コマンドのサンプル・イベント・レコードです。

pdadmin> pop modify pop1 set audit-level all<event rev="1.1"><date>2001-11-14-16:25:54.543+00:00I-----</date><outcome status="0">0</outcome><originator blade="ivmgrd"><component>mgmt</component><action>13702</action><location>location not specified</location></originator><accessor name="user not specified"><principal auth="IV_DCE_V3.0">cell_admin</principal></accessor><target resource="5"><object></object></target><data>"2019""1002""pop1""0"""</data></event>

以下は、sec_master ユーザーが sngsouser1 の姓を持つ新しい Tivoli Access

Manager を作成するために発行する、以下の pdadmin コマンドのイベント・レコードの例です。

pdadmin> user create sngsouser1

<event rev="1.1"><date>2001-11-14-23:01:37.078+00:00I-----</date><outcome status="0">0</outcome><originator blade="pdmgrd"><component>mgmt</component><action>13401</action><location>phaedrus</location></originator><accessor name="user not specified"><principal auth="IV_LDAP_v3.0">sec_master</principal></accessor>


<target resource="5"><object></object></target><data>"sn=sngsouser1""o=Tivoli,c=us"</data></event>

以下は、特定のユーザー (sngsouser1) アカウントを使用不可にする、以下のpdadmin コマンドのサンプル・イベント・レコードです。false の値により、ユーザー・アカウントは使用不可になり、account-valid no パラメーターと関連付けられます。同様に、true の値により、ユーザー・アカウントは使用可能になり、account-valid yes パラメーターと関連付けられます。

pdadmin>user modify sngsouser1 account-valid no

<event rev="1.1"><date>2001-11-14-23:01:37.078+00:00I-----</date><outcome status="0">0</outcome><originator blade="pdmgrd"><component>mgmt</component><action>13406</action><location>phaedrus</location></originator><accessor name=""><principal auth="IV_LDAP_v3.0">dlucas</principal></accessor><target resource="5"><object></object></target><data>"false""sngsouser1"</data></event>

管理コマンドのアクション・コード: 管理コマンド用の監査レコードには、以下の例の 13702 などのアクション・コードが入っています。

<action>13702</action>

アクション・コードは、Tivoli Access Manager pdadmin 管理コマンドの 1 つを識別します。管理コマンドとアクション・コード参照番号を関連付ける表 9を参照してください。たとえば、アクション・コード 13702 は、POP_MODIFY アクション・コマンド (pdadmin pop modify コマンド) と関連付けられています。

コマンドの引き数は、その内部フォーマットで、イベント・レコードのデータ・セクションにリストされます。データベースの状態の変更 (リストおよび表示などの)

を行ったが、有効にならなかったコマンドは取り込まれないことに注意してください。

表 9. ACL 管理コマンド

ACL 管理コマンド

ACL_LIST 13000

ACL_GET 13001

ACL_SET_LEGACY 13002

ACL_DELETE 13003

ACL_FIND 13005

ACTION_LIST 13006

ACTION_SET 13007


表 9. ACL 管理コマンド (続き)

ACTION_DELETE 13008

ACTION_GROUPLIST 13009

ACTION_GROUPCREATE 13010

ACTION_GROUPDELETE 13011

ACTION_LISTGROUP 13012

ACTION_CREATEGROUP 13013

ACTION_DELETEGROUP 13014

ACL_CREATE 13020

ACL_SET 13021

オブジェクト管理コマンド

OBJSPC_CREATE 13103

OBJSPC_DELETE 13104

OBJSPC_LIST 13105

OBJ_CREATE 13106

OBJ_DELETE 13107

OBJ_MOD_SET_NAME 13110

OBJ_MOD_SET_DESC 13111

OBJ_MOD_SET_TYPE 13112

OBJ_MOD_SET_ISLF 13113

OBJ_MOD_SET_ISPOL 13114

OBJ_MOD_SET_ATTR 13115

OBJ_MOD_DEL_ATTR 13116

OBJ_MOD_DEL_ATTRVAL 13117

OBJ_SHOW_ATTR 13118

OBJ_LIST_ATTR 13119

ACL_ATTACH 13120

ACL_DETACH 13121

ACL_MOD_SET_ATTR 13123

ACL_MOD_DEL_ATTR 13124

ACL_MOD_DEL_ATTRVAL 13125

ACL_SHOW_ATTR 13126

ACL_LIST_ATTR 13127

POP_MOD_SET_ATTR 13128

POP_MOD_DEL_ATTR 13129

POP_MOD_DEL_ATTRVAL 13130

POP_SHOW_ATTR 13131

POP_LIST_ATTR 13132

OBJ_SHOW_ATTRS 13133

ACL_SHOW_ATTRS 13134

POP_SHOW_ATTRS 13135

OBJ_SHOW 13136



OBJ_LIST 13137

OBJ_LISTANDSHOW 13138

サーバー管理コマンド

SERVER_GET 13200

SERVER_LIST 13203

SERVER_PERFORMTASK 13204

SERVER_GETTASKLIST 13205

SERVER_REPLICATE 13206

SERVER_ACTION 13207

SERVER_STATUS_GET 13208

SERVER_ENABLE 13209

SERVER_DISABLE 13210

管理、ユーザー、およびグループ管理コマンド

ADMIN_SHOWCONF 13400

USER_CREATE 13401

USER_IMPORT 13402

USER_MODDESC 13403

USER_MODPWD 13404

USER_MODAUTHMECH 13405

USER_MODACCVALID 13406

USER_MODPWDVALID 13407

USER_DELETE 13408

USER_SHOWGROUPS 13409

USER_SHOW 13410

USER_SHOWDN 13411

USER_LIST 13412

USER_LISTDN 13413

GROUP_CREATE 13414

GROUP_IMPORT 13415

GROUP_MODDESC 13416

GROUP_MODADD 13417

GROUP_MODREMOVE 13418

GROUP_DELETE 13419

GROUP_SHOW 13420

GROUP_SHOWDN 13421

GROUP_LIST 13422

GROUP_LISTDN 13423

GROUP_SHOWMEMB 13424

USER_MODGSOUSER 13425

USER_SET 13426

GROUP_SET 13427



PDCMD_ID_GROUP_MODADD2 13428

13500 から 13599 は GSO によって使用される

GSO_RESOURCE_CREATE 13500

GSO_RESOURCE_DELETE 13501

GSO_RESOURCE_LIST 13502

GSO_RESOURCE_SHOW 13503

GSO リソース信任状コマンド

GSO_RESOURCE_CRED_CREATE 13504

GSO_RESOURCE_CRED_DELETE 13505

GSO_RESOURCE_CRED_MODIFY 13506

GSO_RESOURCE_CRED_LIST 13507

GSO_RESOURCE_CRED_SHOW 13508

GSO リソース・グループ・コマンド

GSO_RESOURCE_GROUP_CREATE 13509

GSO_RESOURCE_GROUP_DELETE 13510

GSO_RESOURCE_GROUP_ADD 13511

GSO_RESOURCE_GROUP_REMOVE 13512

GSO_RESOURCE_GROUP_LIST 13513

GSO_RESOURCE_GROUP_SHOW 13514

ポリシー・コマンド

POLICY_SET_MAX_LOGIN_FAILURES 13600

POLICY_GET_MAX_LOGIN_FAILURES 13601

POLICY_SET_DISABLE_TIME_INTERVAL 13602

POLICY_GET_DISABLE_TIME_INTERVAL 13603

POLICY_SET_MAX_ACCOUNT_AGE 13604

POLICY_GET_MAX_ACCOUNT_AGE 13605

POLICY_SET_ACCOUNT_EXPIRY_DATE 13606

POLICY_GET_ACCOUNT_EXPIRY_DATE 13607

POLICY_SET_MAX_INACTIVITY_TIME 13608

POLICY_GET_MAX_INACTIVITY_TIME 13609

POLICY_GET_ACCOUNT_CREATION_DATE 13610

POLICY_GET_LAST_LOGIN_ATTEMPT_DATE 13611

POLICY_SET_MAX_PASSWORD_AGE 13612

POLICY_GET_MAX_PASSWORD_AGE 13613

POLICY_SET_MIN_PASSWORD_AGE 13614

POLICY_GET_MIN_PASSWORD_AGE 13615

POLICY_SET_MAX_PASSWORD_REPEATED_CHARS 13616

POLICY_GET_MAX_PASSWORD_REPEATED_CHARS 13617

POLICY_SET_MIN_PASSWORD_ALPHAS 13618

POLICY_GET_MIN_PASSWORD_ALPHAS 13619

POLICY_SET_MIN_PASSWORD_NON_ALPHAS 13620



POLICY_GET_MIN_PASSWORD_NON_ALPHAS 13621

POLICY_SET_MIN_PASSWORD_DIFFERENT_CHARS 13622

POLICY_GET_MIN_PASSWORD_DIFFERENT_CHARS 13623

POLICY_SET_PASSWORD_SPACES 13624

POLICY_GET_PASSWORD_SPACES 13625

POLICY_SET_MIN_PASSWORD_LENGTH 13626

POLICY_GET_MIN_PASSWORD_LENGTH 13627

POLICY_SET_MIN_PASSWORD_REUSE_TIME 13628

POLICY_GET_MIN_PASSWORD_REUSE_TIME 13629

POLICY_GET_PASSWORD_FAILURES 13630

POLICY_GET_LAST_PASSWORD_CHANGE_DATE 13631

POLICY_SET_NUMBER_WARN_DAYS 13632

POLICY_GET_NUMBER_WARN_DAYS 13633

POLICY_SET_PASSWORD_REUSE_NUM 13634

POLICY_GET_PASSWORD_REUSE_NUM 13635

POLICY_SET_TOD_ACCESS 13636

POLICY_GET_TOD_ACCESS 13637

POP コマンド

POP_CREATE 13700

POP_DELETE 13701

POP_MODIFY 13702

POP_SHOW 13703

POP_LIST 13704

POP_ATTACH 13705

POP_DETACH 13706

POP_FIND 13707

構成コマンド 13800 から 13899

CFG_CONFIG 13800

CFG_UNCONFIG 13801

CFG_RENEWCERT 13802

CFG_CHGPORT 13803

イベント・ロギングプログラムの始動時に作成される一部のメッセージを除き、Tivoli Access Manager

が監査およびその他の保守サービスの目的で生成するメッセージは、すべて Tivoli

Access Manager イベントの構造化された階層で作成されます。

この階層内でイベントが正常にカテゴリー化されると、イベントのクラスと、そのイベントの記録に使用されるログ・エージェント間にランタイムの関連を作成することができます。さらに、ログ・エージェントの概念を拡張して、ローカル・ファイル・システム以外の宛先へのイベントの記録を含めることができます。イベント


階層は、プログラム実行の間に動的に構築されます。 Tivoli Access Manager プログラムの実行時に存在が予想できる既知のイベント・カテゴリーもある一方、他のカテゴリーにはプログラム特有のものや、一時的なものもあります。

このセクションでは、ログ・エージェントを、イベントを記録するイベント・プール階層のポイントに関連付ける方法を説明します。ここでは、階層内のすべての指定可能なイベントの特性については説明しません。監査用に生成される場合のような既知のイベントについては、該当する製品固有の資料を参照してください。

一般に、イベント・プールの階層は、以下に類似しています。

特定のイベント・カテゴリーは、名前のドット分離リストによって識別されます。カテゴリー内の名前の第 1 レベルには、特殊な重みがあります。この最上位カテゴリー名は、Tivoli Access Manager の前のリリースで説明したレガシー・ログ・ファイルに以前に関連付けられていたイベントと一致している場合もあります。

たとえば、イベント・カテゴリー名は、以下のように構成されていることが前提です。

domain_category.sub_category.sub_category...

インプリメンテーション上の注: 効率上、そのカテゴリーのイベントの記録にサブスクライブされたログ・エージェントがなければ、イベントは一般には作成されません。イベントが生成され、かつその記録にサブスクライブされたログ・エージェントがない場合、そのイベントは廃棄されます。

イベント・ログの使用ログ・ファイル構成の逆方向互換方式 (auditcfg = {authn|azn|mgmt}) に加えて、プログラムの構成 (.conf) ファイルの [aznapi-configuration] スタンザの行項目を指定して、 logcfg スタンザ・エントリーを使用して Tivoli Access Manager イベントの取り込みを構成することができます。

図 28. イベント・プール階層


インターフェースを使用して Tivoli Access Manager イベントの記録を可能にするには、ロギングの宛先をイベント・プールのイベントのカテゴリーに関連付ける必要があります。イベントの取り込み用に、現在以下の 4 タイプの宛先がサポートされています。

v コンソール・ログ・エージェント

v ファイル・ログ・エージェント

v パイプ・ログ・エージェント

v リモート・ログ・エージェント

ログ・エージェント構成行の形式を、以下に示します。

[aznapi-configuration]logcfg =category:{stdout|stderr|file|pipe|remote} ¥[[param[=value]][param[=value]]]

これらのログ・エージェント・タイプのオプションは、任意の順序で指定でき、一般にはオプショナルです。各ログ・エージェント・タイプの有効なオプションについては、以下に説明します。構成エントリーで、オプション名は大文字小文字を区別せず、固有性が維持される限り、完全なオプション名を任意の短縮した長さに省略できます。

たとえば、以下の単純形を考えてください。

[aznapi-configuration]logcfg = category:log-agent

カテゴリー名は、イベント・プール階層の任意のノードを指すことができます。カテゴリー・イベントの取り込みには、階層内のすべてのサブコンポーネントが含まれます。すなわち、foo.bar.fred イベントも、foo.bar カテゴリーで取り込まれます。

同じカテゴリーに複数のログ・エージェントを付加することができます。たとえば、以下の構成では、許可監査イベントをファイルにコピーして、それをパイプでlisten するプログラムに中継します。

[aznapi-configuration]logcfg = audit.azn:file path=/var/PolicyDirector/log/audit.aznlogcfg = audit.azn:pipe path=/bin/analyse.exe

以下の図は、ロギング・プロセス内のステップ間の関連を示しています。図の 3 つの部分の最上部は、Tivoli Access Manager サーバーのコードを表しています。プログラマーは、プローブ・ポイントを、特定タイプのイベントが生成される可能性があるコードに追加しました。生成されたイベントは、次にサーバーのイベント・プールにサブミットされ、イベント・カテゴリーを定義する、取り込みのポイント(シンク) を介して記録する可能性があります。

実行時、ユーザーは、イベント・プール階層内の任意のポイントでログ・エージェントをサブスクライブして、プログラムのプローブ・ポイントで生成されたイベントを選択して記録することができます。これは、図の中央部分に表されています。

イベントの取り込み用にサブスクライブできるログ・エージェントの 1 つは、リモート・ログ・クライアントです。このクライアントは、選択されたイベントをリモートの pdacld サーバーにフォワードします。図の下の部分は、このリモート・サーバーを表しています。下の部分は、中継されたイベントが、pdacld リモート・プ


ローブ・ポイントのイベント・プールにある、上の部分と基本的には同じであることに注意してください。

中央イベント伝搬キューの構成イベントは、イベントを構成して記録するアプリケーション・レベルの要求とは非同期に、サブスクライブされたログ・エージェントに渡されます。イベントは、最初、共通の伝搬キューを通過してから、サブスクライブされた各種ログ・エージェントに分散されます。

この伝搬キューのサービス・プロファイルは構成可能です。伝搬キューを構成するには、短縮形式の logcfg エントリーを指定する必要があります。短縮された構成エントリーは、カテゴリー名に EventPool を使用して、ログ宛先タイプを指定せずにキューイング・オプションを指定します。たとえば、次のとおりです。

[aznapi-configuration]logcfg = EventPool:queue_size=number,hi_water=number,flush_interval=number

メモリー内のキューに入れられるイベントの最大数の指定伝搬キューのイベントが使用できるメモリー容量を制御するため、増加できるキューの最大サイズに制限を設けることができます。新規イベントが生成されたときに最大サイズに到達すると、スレッドがそれをキューに入れようとしても、キューに


スペースができるまで阻止されます。この影響で、スレッドを作成するイベントのパフォーマンスは、スレッド・ロギング速度に減速されます (スレッド・ロギング速度が追いつかない場合)。

queue_size のデフォルト値は 0 です。ゼロのキュー・サイズは、イベント・キューの増加に制限が掛けられないことを意味します。デフォルト値を使用した場合は、イベントが、サブスクライブされたログ・エージェントがクリアする速度よりも速い速度で作成されたとき、未処理のイベント・キューが管理できないサイズにまで大きくなる可能性があることに留意してください。

イベント・キュー上限基準点の指定イベント・キューの処理は、構成済みのフラッシュ間隔で定期的にスケジュールされています。また、キュー・サイズが上限基準点に達した場合も非同期に起動します。

hi_water のデフォルト値は 1024 です。 queue_size の値を指定しても、hi_water の値を指定しなかった場合、デフォルトの hi_water は構成済み最大キュー・サイズの 3 分の 2 で計算されます。最大キュー・サイズが 0 ならば、上限基準点はデフォルトの 100 に設定されます。

イベント・キューの上限基準点が 1 に設定されると、キューに入れられたあらゆるイベントが、サブスクライブされたログ・エージェントにただちに中継されます。hi_water の設定値が低いと、全体のパフォーマンスに悪影響が出る場合があります。

ログ・ファイル・バッファーをフラッシュする頻度の指定イベントがログ・エージェントにフォワードされるまでに伝搬キューで待機する時間に限度を指定する場合は、flush-interval を使用します。イベントの生成速度が遅く、適時に上限基準点に到達したことによって処理が起動されない場合、イベントは、この頻度で伝搬キューからフラッシュされます。

flush_interval=seconds

flush_interval のデフォルト値は 10 秒です。 0 のフラッシュ間隔は使用できません。 0 の値を指定すると、キューは 600 秒ごとにフラッシュされることになります。

コンソールのロギングコンソールへのロギングは、構成が最も容易なオプションです。単に、標準出力または標準エラーの出力宛先をイベント・プール内のイベントのカテゴリーに関連付けて取り込むだけです。

[aznapi-configuration]logcfg = category:{stdout|stderr}

構成例を以下に示します。

v 標準出力にすべての監査出力を取り込むには、ldap.conf 構成ファイルの[aznapi-configuration] スタンザで以下を指定します。

logcfg = audit:stdout

v 許可監査イベントのみを標準エラーに取り込むには、以下の指定を行います。

logcfg = audit.azn:stderr


コンソールへのロギング自体では、キューイングを使用しません。イベントは、伝搬キューから受け取られる際にコンソールに書き込まれます。しかし、そのイベントは、そのキューの設定によっては、伝搬キューで遅らされることがあります。

コンソール出力を使用し、デバッグ目的でサーバーをフォアグラウンドで実行している場合は、それに応じて伝搬キュー設定値を設定することが必要になる場合もあります。たとえば、hi_water オプションを低い値に設定します。

ファイルのロギングイベントをファイルに記録するには、ログ・ファイル構成を以下のように指定します。

[aznapi-configuration]logcfg = category:file path=file_pathname, ¥flush_interval=seconds, ¥rollover_size=number, ¥log_id=logid, ¥queue_size=number, ¥hi_water=number, ¥buffer_size=number, ¥mode={text|binary}

ファイルを開くのは 1 回のみです。複数の構成エントリーが存在して、イベント・プール階層の異なるポイントでイベントを選択して同じファイルに取り込む場合は、処理される最初の構成エントリーで検索されたオプションに従ってファイルが開きます。

ファイルが開いた後、それ以降のファイル構成は以下の省略表現を使用するだけで、イベントを同じファイルに記録できます。

[aznapi-configuration]logcfg = <category>:file log_id=<logid>

ファイルへの書き込み操作は、タスクのイベント生成と比較して遅い場合があるため、イベントのファイル・ログ・エージェントへの追加は、2 次レベルのキューイングを介して行われます。この 2 次レベルのイベントのキューイングの構成方法は、中央のイベント伝搬キューに類似していますが、デフォルト値が異なります。

ログ・ファイルの場所の指定ログ・ファイルの場所を指定する場合は path を使用します。 log_id 値が優先するため、ファイル・パス名のデフォルト値はありません。 UNIX の場合のWebSEAL 監査証跡ファイルのパス値の例を、以下に示します。

path=/var/pdweb/log/audit.log

このパス名には、ディレクトリー部分がなければなりません。ログ・ファイルがまだ存在していない場合は、作成されます。

ログ・ファイル ID の指定オープン・ログ・ファイルを短縮名 ID に関連付けて、異なるカテゴリーから同じファイルへのイベントの記録を容易にします。

log_id オプションを使用して、ログ・ファイル ID を明示的に指定します。それ以外では、デフォルト値が指定されます。path オプションが指定された場合のデフォルト値は、構成済みのパス名です。 path が指定されなかった場合、ログ ID のデ


フォルトは、取り込まれるイベント・カテゴリーのドメイン・コンポーネントに設定されます。たとえば、次のとおりです。

logcfg = audit.azn:file

は、

log_id=audit

イベントを共通ファイルに取り込むには、ログ・ファイル ID を完全にオプション選択されたファイル構成の適切な値に設定します。次に、以下のように、構成の省略形を使用して追加のカテゴリーからイベントを取り込みます。

[aznapi-configuration]logcfg = audit.azn:file path=/opt/PolicyDirector/log/audit.log, ¥rollover_size=-1,flush=20,log_id=audit

logcfg = audit.authn:file log_id=audit

デフォルト・ルールにより、この構成は以下の指定とも同等です。

[aznapi-configuration]logcfg = audit.azn:file ¥path=/opt/PolicyDirector/log/audit.log,rollover_size=-1

logcfg = audit.authn:file

log_id 値がオープン・ログ・ファイルと一致しない構成を作成すると、イベントは取り込まれません。たとえば、以下の構成は、ログ・ファイルを初期化する構成行がコメント化されているので、イベントを記録しません。

[aznapi-configuration]#logcfg = audit.azn:file path=/tmp/azn.log,log_id=aznlogcfg = audit.authn:file log_id=azn

最大ログ・ファイル・サイズの指定ログ・ファイルが増加できる最大サイズを指定する場合は、rollover_size オプションを使用します。このオプションには、以下のデフォルト値 (バイト単位) があります。

rollover_size=2000000

ログ・ファイルのサイズが指定値 (そのロールオーバーしきい値として知られる) に到達すると、現行の日付とタイム・スタンプを付加された、同じ名前のファイルに既存のファイルのバックアップがとられます。次に、新しいログ・ファイルが開始されます。

さまざまに解釈される指定可能な rollover_size 値を、以下に示します。

v rollover_size 値がゼロ未満 (< 0) ならば、プロセスの起動ごと、かつそのインスタンスから 24 時間ごとに新規ログ・ファイルが作成されます。

v rollover_size 値がゼロに等しい (= 0) 場合は、ロールオーバーは実行されず、ログ・ファイルは無限に拡大し続けます。ログ・ファイルがすでに存在する場合、新しいデータがそこに追加されます。

v rollover_size 値がゼロより大きい (> 0) 場合は、ログ・ファイルが、構成されたしきい値に達したときにロールオーバーが実行されます。ログ・ファイルが始動時にすでに存在する場合、新しいデータがそこに追加されます。


最大バッファー・サイズの指定多数の小イベントをファイル・ログ・エージェントに個別にキューに入れるのではなく、メモリーのフラグメント化を減らし、ファイルへの書き込みパフォーマンスを向上させるため、イベントを、サイズを指定したブロックのバッファーに入れてから、書き込みのキューに入れることができます。 buffer_size オプションは、プログラムが小さなイベントを結合して大きなバッファーに入れて構成しようとする、最大サイズのメッセージを指定します。

バッファーは、整数値のイベントからのみ構成され、イベントは複数のバッファーにまたがって分割されません。個々のイベントがその構成された最大サイズを超過すると、その大きなイベントがそれ自体のバッファーに記録され、構成された値を超過します。

buffer_size=number_of_bytes

ファイルにロギングするデフォルトのバッファー・サイズは 0 バイトです。この値ではバッファリングは行われず、各イベントは個別に処理されます。

buffer_size に値が指定されると、イベントは圧縮されてそのサイズのバッファーに入れられてから、ファイル・ログ・エージェントのキューに入れられます。

たとえば、buffer_size の値が 2 KB に設定され、イベントを約 256 バイトと想定すると、おおよそ 10 のイベントがファイルに書き込まれる各バッファーに圧縮されます。これで、ロギングの間に行われるディスク入力/出力 (I/O) の数は、バッファリングなしの場合の 10 % 相当が削減されます。

2 KB の buffer_size のデフォルトのキュー・サイズが 200 の場合も、バッファリングなしで行ったデフォルト構成のメモリーの場合の約 10 倍を消費する (イベント・サイズが約 200 バイトとして) ことに注意してください。これは、最大のキュー・サイズ値が変更されずに、キューに入れられるイベントのサイズが 10 倍に増加したためです。

メモリー内のキューに入れられるイベントの最大数の指定キューに入れられるイベントとそれを除去するファイル・ログ・エージェントとの間には遅延が出ます。 queue_size オプションは、キューが増加できる最大サイズを指定します。新規イベントがキューに入れられる準備ができたときに最大サイズに到達すると、要求元のスレッドは、キューにスペースができるまでブロックされます。この影響で、イベント伝搬スレッドのパフォーマンスは、ファイル・ロギング・スレッドの速度に減速されます (ファイル・ロギング・スレッドの速度が追いつかない場合)。

queue_size のデフォルト値は 0 です。ゼロのキュー・サイズは、未処理イベント・キューの増加に制限が掛けられないことを意味します。それに対応して、イベント伝搬スレッドはロギング・スレッドの速度による制限を受けません。デフォルトを使用した場合は、イベントが生成される速度がファイルに記録できる速度を上回ると、記録されないイベント・キューが管理できないサイズに増加する可能性があることに留意してください。


イベント・キュー上限基準点の指定イベント・キューの処理は、構成済みのフラッシュ間隔で定期的にスケジュールされています。また、キュー・サイズがイベント・キューの上限基準点に達した場合も非同期に起動します。

hi_water のデフォルト値は、構成済み最大キュー・サイズの 3 分の 2 です。最大キュー・サイズがゼロならば、上限基準点はデフォルトの 100 に設定されます。

トランザクション速度およびこれらのオプションの値により、ファイルへのイベント・ロギングを可能にすることで消費されるメモリーの最大容量が決まります。

イベント・キューの上限基準点が 1 に設定されると、キューに入れられたあらゆるイベントが、ログ・エージェントにただちに中継されます。この設定は、全体のパフォーマンスを犠牲にしても、できるだけすみやかにイベントをディスクに到達させたい場合に使用することができますが、最適ではありません。

ログ・ファイル・バッファーをフラッシュする頻度の指定flush_interval オプションは、複数使用オプションです。ファイル flush_intervalオプションへのロギングには、以下のデフォルト値 (秒単位) があります。

flush_interval=20

0 のフラッシュ間隔は使用できません。 0 の値を指定すると、600 の値が使用されることになります。

ログ・ファイルは、バッファー付きデータ・ストリームに書き込まれます。ストリーム・バッファーを確実に定期的にディスクにフラッシュさせるには、サーバーが、ファイル・ストリームのディスクへのフラッシュを非同期に実施する頻度を、このオプションを使用して構成することができます。

負の値を指定した場合は、非同期のフラッシュ頻度として絶対値が使用されますが、ストリーム・フラッシュも、レコードの書き込みごとに非同期に実施されます。

buffer_size オプションを指定して、イベントが大きなバッファーに統合される場合は、flush_interval オプションも、書き込まれるバッファーのサイズに影響する場合があります。フラッシュをスケジュールする際にメモリー内に部分的に埋められたバッファーがあると、そのバッファーも、いっぱいになるまで書き込みのキューに入れられます。

最後に、イベント・キューは、起動され、フラッシュ間隔の速度で処理されます。これにより、スケジュールされたフラッシュの間にキューの上限基準点に到達しないときに、イベントが処理を待つ長さが、スケジュールされたフラッシュ時間より長くならないようにします。

ファイル・モードの指定テキスト・モードかバイナリー・モードのいずれかでファイルを開く場合は、modeオプションを使用します。たとえば、次のとおりです。

mode={text|binary}


テキスト・モードは UNIX オペレーティング・システムには使用すべきでなく、かつ効果がありません。 WIN32 オペレーティング・システムでは、ファイルをテキスト・モードで開くと、ログ・ファイルの行の終わりの文字変換が可能になります。 Windows オペレーティング・システムでのバイナリー・モードの場合、ログ・ファイルは UNIX 互換フォーマットで書き込まれます。

パイプ・ロギング出力を別のプログラムの標準入力に書き込む場合は、pipe オプションを使用します。たとえば、次のとおりです。

[aznapi-configuration]logcfg=<category>:pipe path=<program_pathname>, ¥queue_size=<number>, ¥hi_water=<number>, ¥flush_interval=<number>

名前付きプログラムが存在し、実行可能でなければなりません。実行するプログラムのセキュリティーについては、管理者が確実にする責任があります。

構成ファイルでパイプ・エージェントが発生するつど、パイプ・プログラムの新規コピーが起動します。ファイルへのロギングと異なり、パイプ付きイベントは、異なるカテゴリーの取り込みポイントからプログラムの単一コピーに多重化されません。

実行するプログラムの指定標準入力でログ出力を受け取る、プログラムの場所を指定する場合は、path オプションを使用します。たとえば、次のとおりです。

path=/opt/risk_analyser/bin/my_log_watcher

パス名にはデフォルト値がないことに注意してください。

イベント・キュー・プロファイルの指定パイプ・ロギング・イベント・キュー管理の構成は、ファイルへのロギングを構成する場合と同じ方法で行います。 queue_size、hi_water、および flush_intervalオプションには、ファイル・ロギングで説明したオプションと類似した意味があります。

リモート・ロギングイベントをリモート・サーバーに送り記録する場合は、remote オプションを使用します。たとえば、次のとおりです。

[aznapi-configuration]logcfg = category:remote ¥buffer_size=size, ¥compress={yes|no}, ¥error_retry=timeout, ¥path=name, ¥flush_interval=number, ¥rebind_retry=timeout, ¥server=hostname, ¥port=number, ¥dn=identity, ¥queue_size=number,hi_water=number


イベントをリモートでログに記録する要求は、必ず受け入れられるとは限りません。リモート・サーバーが利用不能の場合、取り込まれたイベントはローカルでキャッシュに入れられ、後日、かつリモート・サーバーが使用可能になった場合に中継されます。

リモート・サーバーに対して確立されるリモート・ロギング接続は 1 つのみです。複数の構成エントリーが設定されて、イベント・プール階層の異なるポイントでイベントを選択して同じリモート・サーバーに取り込む場合、リモート接続は、処理される最初のリモート構成エントリーのオプションに従って確立されます。複数のリモート接続を構成して、さまざまなリモート・サーバーのログに記録できます。

リモート・サーバーで受け取られたイベントは、クライアント・システムで最初に取り込まれたところとは別の位置の、そのサーバーのイベント・プールに入れられます。リモート・ロギング・サービスを介してホストに入るすべてのイベントは、以下の方法で構成されたカテゴリーに入れられます。

remote.client-category-domain.hostname.program

クライアント側の内部ロギング・コードは、gethostname() システム・コールを使用してホスト名を提供します。受け取るホストは、gethostname() がクライアント側で常に利用可能であるため、いつでも送信側のホスト名を解決できます。したがって、ネットワーク・ホスト名の解決に特別な要件はありません。この呼び出しは、ローカル・ホストの内部ホスト名 (常に短縮名の形式で) を戻します。

たとえば、ホスト amazon 上のプログラム pdmgrd からリモートでログに記録されたすべての監査イベントは、プール remote.audit.amazon.pdmgrd の下のリモート・ログ・サーバーに表示されます。 1 つのプールの下に表示されることによって、リモート・サーバーは、標準構成を使用したさまざまな宛先にイベントを選択しながら記録することができます。たとえば、ホスト amazon からのすべての監査イベントは、以下のような構成によって主としてホスト timelord に記録することができます。

ホスト amazon でイベントをリモートで中継する場合、以下の例を使用します。

[aznapi-configuration]logcfg = audit:remote buffer=2000,compress=y,error=2, ¥path=/opt/PolicyDirector/log/remote.cache,rebind=600,server=timelord,port=7136

ホスト timelord でイベントをファイルに記録する場合、以下を使用します。

[aznapi-configuration]logcfg = remote.audit:file path=consolidated_audit.log

logcfg = remote.audit.amazon.pdmgrd:file path=amazon_pdmgrd_audit.log

最大バッファー・サイズの指定ネットワーク・トラフィックを減らすために、イベントは指定されたサイズのブロックでバッファーに入れられてから、リモート・サーバーに中継されます。buffer_size オプションは、ローカル・プログラムが小さなイベントを結合して大きなバッファーに入れて構成しようとする、最大サイズのメッセージを指定します。バッファーは、整数値のイベントからのみ構成され、イベントは複数のバッファーにまたがって分割されません。個々のイベントがその構成された最大サイズを超過すると、その大きなイベントがそれ自体のバッファーに送られ、構成された値を超過します。


buffer_size=number_of_bytes

デフォルトのバッファー・サイズは 1024 バイトです。

統合バッファーをフラッシュする頻度の指定イベントが非常に大きなバッファーに統合されて、ロギング・アクティビティーがあまりない場合は、イベントを長時間メモリー内に置いてから、リモート・サーバーにフォワードしたり、あるいはキャッシュ・ファイルに書き込むことができます。 flush_interval オプションは、統合バッファーが埋まるまでプロセスが待つ時間を制限します。たとえば、次のとおりです。

flush_interval=seconds

デフォルトのフラッシュ間隔は 20 秒です。 0 のフラッシュ間隔は使用できません。 0 の値を指定すると、バッファーは 600 秒ごとにフラッシュされることになります。

キュー・サイズの指定リモート・ロギング接続の queue_size および hi_water 値は、ファイルへのロギングに指定された値に類似しています。デフォルト値は次のとおりです。

queue_size=0hi_water=100

メッセージの圧縮の指定Tivoli Access Manager イベントは、基本的にはテキスト・メッセージです。ネットワーク・トラフィックを減らすには、圧縮オプションを使用して、送信前にバッファーを圧縮し、受信で解凍します。たとえば、次のとおりです。

compress={yes|no}

デフォルトの圧縮値は no です。

エラー再試行タイムアウトの指定リモート・サービス送信が失敗すると、数秒のエラー再試行タイムアウトの待機後再試行されます。再試行も失敗すると、そのリンクにはマークが付けられ、このイベントとその後のイベントは、リモート・サービスが再バインドされるまで、ローカル・イベント・キャッシュ・ファイルに保管されます。

error=seconds

デフォルトのエラー再試行タイムアウトは 2 秒です。

キャッシュ・ファイルの場所の指定path オプションは、ローカル・ホスト上のキャッシュ・ファイルの場所を指定します。キャッシュ・ファイル名は、デフォルトでは ./server.cache に指定されます。ここで server はログ記録されるリモート・サーバーの名前です。

実行中のプロセスがリモート・サーバーとの通信を確立できないか、リンクが操作中に失敗した場合、そのサーバーが再度使用可能になるまで、イベントの記録は指定されたファイルへのイベントの保管に切り替わります。サーバーが使用可能になると、イベントはディスク・キャッシュからドレーンされ、リモート・サーバーへ中継されます。


たとえば、UNIX での pdmgrd のパス値が、以下のようであるとします。

path=/var/PolicyDirector/log/pdmgrd_remote.cache

このパス名には、ディレクトリー部分がなければなりません。ログ・ファイルがまだ存在していない場合は、作成されます。このファイルのサイズがバインドされていないので、ロールオーバーする能力はありません。リモート・サーバーにアクセスできる時間が十分なければ、ディスク・スペース切れになるおそれがあります。

再バインド再試行タイムアウトの指定リモート・サーバーが使用できない場合、ログ・エージェントは、秒単位の頻度(デフォルトは 300) でサーバーへの再バインドを試みます。

rebind_interval=60

リモート・サーバーの指定リモート・ロギング・サービスは、pdacld プログラムによって提供されます。リモート・ロギングは、azn_initialize() を呼び出して初期化されたときに許可サービスにセットアップされた証明書を基本としています。このオプションは、イベントの記録用にバインドされるホスト pdacld プロセスを指定します。

server=hostname

リモート・サーバー・ポートの指定リモート pdacld がリモート・ロギング要求で listens する場合のポートを指定するときは、 port オプションを使用します。

port=number

デフォルト値は 7136 です。

リモート・サーバー識別名の指定リモート・サーバーの相互認証を確立する場合は、リモート・サーバーの証明書で戻される名前と照合できる識別名 (DN) を構成する必要があります。 DN のデフォルト値はヌル・ストリングです。 DN は、二重引用符で囲んだストリングで指定する必要があります。デフォルト値を使用するか、空ストリングを明示的に指定すると、ロギング・クライアントは listen しているサーバーとのリモート・サーバー接続を無差別に確立できます。 DN に値を指定すると、特定のサーバーへの正常な接続に制限されます。

dn="cn=ivacld/timelord.testnet.tivoli.com,o=policy director,c=us"

イベント・カテゴリーの位置決め例示されたとおり、各イベント・カテゴリーの名前は、trace イベントに書き込まれます。トレース・レコードを表示するには、ルーティング・ファイルに以下の行を追加して、始動時に trace を使用できるようにします。

*:*.9:TEXTFILE:pd_dir/log/trace_%ld.log

ログ・キュー・パフォーマンスのモニター主な伝搬キュー (および各ファイル・エージェント、リモート・エージェント、およびパイプ・ログ・エージェント) 用に構成されたキューイングのプロファイルは、統計インターフェースを使用してモニターできます。


各キューは、ログ・エージェント・タイプおよびストリング、pd.log から構成したカテゴリー名を使用して、自らを統計サブシステムに登録する EventQueue オブジェクトをインスタンス化することによって、インプリメントされます。

イベント・キューの統計は pdadmin server task コマンドを使用して、問い合わせることができます。サーバー上でインプリメントするキューを確立する場合は、server task server_name stats list コマンドを発行します。以下のようなレポートが戻されます。

pdadmin> server task ivacld-barra.surf.ap.tivoli.com stats listpd.ras.stats.monitorpd.log.EventPool.queue // Main event propagation queuepd.log.file.audit // Audit log queuepdadmin

キューの統計を調べるには、以下のように stats get コマンドを入力します。

pdadmin> server task ivacld-barra.surf.ap.tivoli.com ¥

stats get pd.log.EventPool.queue

以下のような report が表示されます。

dispatcher wakes on timeout(20) : 3617dispatcher wakes by notify : 0

notifies above highwater (100) : 0notifies below highwater : 0spurious notifies : 0

total events processed : 24average number of events handled per activation : 1greatest number of events handled per activation : 7blocks in queue requests : 0pdadmin>

キュー・フラッシュ頻度が、timeout のワードの後に括弧で囲まれてリストされます。キューの上限基準設定値が、highwater のワードの後に括弧で囲まれてリストされます。

各種キュー構成オプション用に選ばれる設定値は、特定のログ・エージェントがイベントを消費できる比率でキューが活動化する間に消費される最大メモリー容量のバランスを取ることを試みる必要があります。

キューが活動化する間に処理されるイベント数で処理タイム・スライスが埋まるように、上限基準点を設定するのが最適です。この設定で、不必要なスレッド・コンテキストの切り替えは避けられます。しかし、単にこれらのオプションを高い値に設定するだけでは、おそらく効果は上がりません。なぜなら、イベント・ログ処理はあるポイントで行う必要があり、無制限に据え置きできないためです。また、大量のメモリーを消費すること自体がその難点です。


付録 A. サーバー構成ファイルの解説

Tivoli Access Manager サーバーの操作は、構成ファイルを使用して制御されます。各構成ファイルには、スタンザと呼ばれるセクションが含まれています。

構成ファイルサーバー構成ファイルは、ASCII テキスト・ベースであり、スタンザ・エントリーを含んでいます。構成ファイルは、サーバー始動時にのみ処理されます。以下の表は、現行の Tivoli Access Manager 構成ファイルのリストです。

構成ファイル目的サーバー

171ページの『pd.conf』

Tivoli Access Manager 構成許可サーバー (pdacld) に使用される

168ページの『ivacld.conf』

許可サーバー構成 Tivoli Access Manager 許可サーバー(pdacld)

169ページの『ivmgrd.conf』

ポリシー・サーバー構成 Tivoli Access Manager ポリシー・サーバー (pdmgrd)

170ページの『ldap.conf』

LDAP ベースのユーザー・レジストリー構成

LDAP ベースのサーバー

166ページの『activedir.conf』

Active Directory ベースのユーザー・レジストリー構成

Microsoft Active Directory サーバー

167ページの『domino.conf』

Domino ベースのユーザー・レジストリー構成

IBM Lotus Domino サーバー

Tivoli Access Manager のインストール時に、インストール・ディレクトリーを変更しなかった場合、構成ファイルは以下のデフォルトのディレクトリーに常駐しています。

UNIX /opt/PolicyDirector/etc

Windows C:¥Program Files¥Tivoli¥Policy Director¥etc¥


activedir.confMicrosoft Active Directory サーバーを Tivoli Access Manager のユーザー・レジストリーとして使用する場合、サーバー構成ファイル activedir.conf を持つ必要があります。この構成ファイルを使用して、各 Active Directory レジストリー・サーバーの操作をカスタマイズします。

注: Active Directory は、Microsoft Windows でのみポリシー・サーバー用にサポートされています。

この構成ファイルに入れることのできるスタンザは、以下のとおりです。

v [uraf-ad]

activedir.conf を構成解除するときも、この構成ファイルから情報を照会します。

以下に、この構成ファイルに表示できるスタンザ・エントリーの例を示します。

[uraf-ad]

enabled =multi-domain =hostname =domain =useEncryption =bind-id =bind-pwd =dnforpd =

また、ivacld.conf および ivmgrd.conf 構成ファイルの [uraf-ad] スタンザで、Active Directory スタンザ・エントリーの値を設定できます。たとえば、以下のスタンザ・エントリーのみが表示されます。

[uraf-ad]ad-server-config =bind-dn =bind-pwd =

[uraf-registry]ad-server-config =bind-dn =bind-pwd =


domino.confLotus Domino サーバーを Tivoli Access Manager のユーザー・レジストリーとして使用する場合、サーバー構成ファイル domino.conf を持つ必要があります。この構成ファイルを使用して、各 Domino レジストリー・サーバーの操作をカスタマイズします。


v [uraf-domino]

domino.conf を構成解除するときも、この構成ファイルから情報を照会します。

以下に、この構成ファイルに表示することのできるスタンザ・エントリーの例を示します。

[uraf-domino]

enabled =server =hostname =ldapport =usessl =keyfile =keyfile-pw =keyfile-dn =password =NAB =PDM =

また、ivacld.conf および ivmgrd.conf 構成ファイルの [uraf-domino] スタンザで、Domino スタンザ・エントリーの値を設定できます。たとえば、これらのスタンザ・エントリーのみが表示されます。

[uraf-domino]domino-server-config =bind-dn =bind-pwd =

[uraf-registry]domino-server-config =bind-dn =bind-pwd =

付録 A. サーバー構成ファイルの解説 167

ivacld.conf許可サーバー、pdacld を Tivoli Access Manager で使用する場合、サーバー構成ファイル ivacld.conf を持つ必要があります。この構成ファイルを使用して、各許可サーバーの操作をカスタマイズします。


v [ivacld]

v [ldap]

v [uraf-ad]

v [uraf-domino]

v [ssl]

v [manager]

v [authentication-mechanisms]

v [aznapi-configuration]

v [aznapi-entitlement-services]

v [aznapi-external-authzn-services]

v [aznapi-pac-services]

v [aznapi-cred-modification-services]

v [aznapi-admin-services]

ivacld.conf を構成解除するときも、この構成ファイルから情報を照会します。

# azn-app-host =listen-flags = enable


ivmgrd.confポリシー・サーバー pdmgrd を Tivoli Access Manager で使用する場合、サーバー構成ファイル ivmgrd.conf を持つ必要があります。この構成ファイルを使用して、各ポリシー・サーバーの操作をカスタマイズします。


v [ivmgrd]

v [ldap]

v [uraf-ad]

v [uraf-domino]

v [ssl]

v [authentication-mechanisms]

v [aznapi-configuration]

v [aznapi-entitlement-services]

v [aznapi-pac-services]

v [aznapi-cred-modification-services]

v [aznapi-external-authzn-services]

v [aznapi-admin-services]

v [delegated-admin]

ivmgrd.conf を構成解除するときも、この構成ファイルから情報を照会します。


ldap.confLDAP を Tivoli Access Manager のユーザー・レジストリーとして使用する場合、ldap.conf 構成ファイルを使用して、LDAP ベースのスタンザ・エントリーをカスタマイズします。

この構成ファイルに含まれているスタンザは、以下のとおりです。

v [ldap]

以下のスタンザ内容の例は、ldap.conf 構成ファイルの [ldap] スタンザに含まれている可能性のあるスタンザ・エントリーです。

[ldap]enabled =host =port = 389ssl-port = 636max-search-size = 2048LdapSSL =LdapSSLKeyFile =LdapSSLKeyFileDn =LdapSSLKeyFilePwd =GsoSuffix =# replica = replica1.ldap.tivoli.com,389,readonly,5# replica = replica2.ldap.tivoli.com,389,readonly,5

以下の [ldap] スタンザの例は、activedir.conf と domino.conf 構成ファイルで表示される場合に異なることに注意してください。たとえば、これらのスタンザ・エントリーのみが表示されます。

[ldap]ldap-server-config =bind-dn =bind-pwd =


pd.confTivoli Access Manager で、pd.conf 構成ファイルを持つ必要があります。この構成ファイルを使用して、サーバー始動を自動化し、Tivoli Access Manager ランタイム・パッケージが構成されているかどうかを示し、ユーザー・レジストリーに関する情報を指定します。

サーバー始動を自動化するためのスタンザ・エントリーは、pd.conf 構成ファイルの [pdrte] スタンザに入っています。


v [pdrte]

v [ssl]

v [manager]

v [ldap-ext-cred-tags]

pd.conf を構成解除するときも、この構成ファイルから情報を照会します。

以下に、この構成ファイルに表示できるスタンザ・エントリーの例を示します。

[pdrte]configured = yesuser-reg-type = ldapuser-reg-server = librauser-reg-host = librauser-reg-hostport = 389boot-start-ivmgrd = noboot-start-ivacld = no

[ssl]ssl-keyfile = C:\pd\keytab\pd.kdbssl-keyfile-stash = C:\pd\keytab\pd.sth#ssl-keyfile-label =ssl-v3-timeout = 7200ssl-pwd-life = 7299ssl-io-inactivity-timeout = 90ssl-auto-refresh = yesssl-local-domain = Default

[manager]master-host = libramaster-port = 7135

[ldap-ext-cred-tags]#credential-field-name =


ユーザー定義構成ファイルTivoli Access Manager は、より一般的な構成ファイルのテンプレートを備えています。独自のセキュリティー・アプリケーションを作成したり、Tivoli Access

Manager が提供する機能を拡張する場合、aznAPI.conf 構成ファイルをテンプレートとして使用できます。このファイルは、example/authzn/demo/cpp サブディレクトリーに、許可 ADK パッケージとともに入っています。

独自のプラグイン、またはセキュリティーが強化されたアプリケーションをインプリメントする場合の文書ソースは、IBM Tivoli Access Manager Authorization C API

デベロッパーズ・リファレンス、または IBM Tivoli Access Manager Authorization

Java Classes デベロッパーズ・リファレンスです。


スタンザ構成のガイドラインこれらのガイドラインは、Tivoli Access Manager 構成ファイルに変更を加える際のヘルプを提供します。ガイドラインは、以下のタイプに分類されます。

v その他

v デフォルト設定

v ストリング

v 定義済みストリング

v ファイル名

v 整数

v ブール値

説明については、 176ページの『変更構成設定』を参照してください。

一般ガイドライン構成設定を変更する際、以下の一般ガイドラインを使用してください。

v いずれの構成ファイルのスタンザにも、順序の依存関係またはロケーションの依存関係はありません。

v スタンザ・エントリーは、必須またはオプションとしてマークされています。エントリーが必須の場合、エントリーに有効なキーまたは値が入力されている必要があります。

v 構成ファイル内のキー名は変更しないでください。キー名を変更すると、サーバーに予測不能な問題が起こる可能性があります。

v キーの大文字化は重要ではありません。たとえば、UseSSL または usessl のいずれも使用できます。

v キー名に、スペースは許可されていません。

v key = value のキー値ペア・フォーマットで、等号 (=) を囲むスペースは必須ではありませんが、推奨されています。

v スタンザ・エントリーの最後に表示される印刷不可能な文字 (例: タブ、復帰、改行) は、無視されます。印刷不可能な文字は、10 進数で 32 以下の ASCII 文字です。

デフォルト値デフォルト構成設定を変更する場合、以下のガイドラインを使用します。

v 多くの値が、構成プログラムを使用してのみ作成または変更されます。これらのスタンザまたは値を手動で編集しないでください。

v 値によっては、構成時に自動的に入力されるものもあります。これらの値は、構成の後にサーバーを初期化するために必要です。

v スタンザ・エントリーのデフォルト値は、サーバー構成により異なります。一部のキー値ペアは特定のサーバーに適用できず、このサーバーのデフォルト構成ファイルから削除されます。


ストリング一部の値は、ストリング値を受け入れます。構成ファイルを手動で編集する場合、以下のガイドラインを使用して、ストリングが必要な構成設定を変更します。

v ストリング値は、ローカル・コード・セットの一部の文字であると想定されます。

v 許容されるストリング文字のセットに対して、追加または別の制限が課される場合もあります。たとえば、多くのストリングは ASCII 文字に制限されています。制限については、各スタンザ・エントリーの詳細を参照してください。

v 値にスペースまたは 1 つ以上の単語を使用する場合には、必ずではありませんが、二重引用符が必須となる場合もあります。判別がつかない場合は、各スタンザ・エントリーの詳細または例を参照してください。

v ユーザー・レジストリーに関連するストリング値の最小または最大の長さに制限がある場合、基本レジストリーにより設定されます。たとえば、Active Directory

の場合、最大長は英数字 256 文字です。

定義済みストリング一部の値はストリング値を受け入れますが、値は定義済みストリングのセットである必要があります。構成ファイルを手動で編集する場合、入力するストリング値が有効な定義済みストリング値の 1 つと一致するように、ご注意ください。

たとえば、[aznapi-configuration] スタンザ・セクションには、以下のエントリーが含まれています。

auditcfg = {azn|authn|mgmt}

auditcfg の値は、azn または authn または mgmt です。その他の値は無効であり、エラーとなります。

ファイル名一部の値は、ファイル名です。ファイル名を値とする各スタンザ・エントリーの場合、スタンザ・エントリーの詳細が、以下の構成のうち有効なものを指定します。

v ファイル名

ディレクトリー・パスは含まれていません。

v 相対ファイル名

ディレクトリー・パスは許可されていますが、必須ではありません。

これらのファイルは通常、標準的な Tivoli Access Manager ディレクトリーの場所に相対する場所にあると想定されています。各相対パス名のスタンザ・エントリーは、ファイル名が相対するルート・ディレクトリーをリストします。

v 完全修飾 (絶対) パス

絶対ディレクトリー・パスは必須です。

注: 一部のスタンザ・エントリーでは、上記のうち複数の選択肢が許可されています。

ファイル名で許可されている文字セットは、ファイル・システムおよびローカル・コード・セットにより決定されます。Windows の場合、バックスラッシュ (\)、コロン (:)、疑問符 (?)、または二重引用符をファイル名に含むことはできません。


整数多くのスタンザ・エントリーでは、エントリーの値が整数で表示されることが想定されています。

v 整数値のスタンザ・エントリーでは、有効な範囲内の整数値が想定されています。範囲は、最小値および最大値によって記述されます。

たとえば、[logging] スタンザで、logflush スタンザ・エントリーの最小値は 1

秒、最大値は 600 秒です。

v 一部のエントリーでは、整数値が正数でなければならず、その最小値は 1 です。その他のエントリーでは、整数の最小値を 0 にできます。

整数値を 0 に設定するときは注意してください。たとえば、整数値を 0 に設定することによって、そのスタンザ・エントリーにより制御されている機能が使用不可になる場合もあります。たとえば、[ivacld] スタンザでは、エントリーtcp-req-port = 0 によりポート番号が使用不可になります。また、整数値を 0

に設定することにより、番号が無限であることを意味する場合もあります。たとえば、[ldap] スタンザでは、エントリー max-search-size = 0 は、検索の最大サイズが無限であることを意味します。

v 整数値を要求するエントリーに対し、Tivoli Access Manager は許可される最大限の番号を設定しません。たとえば、通常、タイムアウトに関連する値に最大値はありません (例: [ldap] スタンザの timeout = number)。

このタイプのエントリーの最大数は、整数データ・タイプに割り当てられたメモリーのサイズによってのみ制限されます。この番号は、オペレーティング・システムのタイプにより異なります。整数に 4 バイトを割り当てるシステムの場合、値は 2147483647 です。

ただし、アドミニストレーターは、設定する値に対して最も論理的な値を表す番号を使用する必要があります。

ブール値多くのスタンザ・エントリーは、ブール値で表されます。Tivoli Access Manager

は、ブール値の「yes」および「no」を認識します。

構成ファイル内の一部の構成は、別のサーバーおよびユーティリティーにより読み取られます。たとえば、[ldap] スタンザ内の多くのエントリーは、LDAP クライアントにより読み取られます。これらのほかのプログラムの一部では、別のブール文字を認識します。

v yes または true

v no または false

yes|true 以外のすべての値は、ブランク値も含め、no|false として解釈されます。

認識されたブール・エントリーは各スタンザ・エントリーにリストされます。true

または false も認識される場合を判別するには、それぞれの詳細を参照してください。


変更構成設定構成設定を変更するには、次のようにします。

1. 変更する予定の構成ファイルのバックアップ・コピーをとる。

こうすると、後にエラーが発生した場合に、構成ファイルを既知の作業状態に戻すことができます。

2. 影響を与える Tivoli Access Manager サーバーを停止する。

3. 以下のいずれか 1 つを行って変更する。

v ASCII テキスト・エディターを使用して構成ファイルを編集し、必要な変更を加える。変更を保存します。

v サーバーに適切な構成ツールを使用して、構成設定を変更する。– ivmgrd.conf では、mgrsslcfg ユーティリティーを使用する。– pd.conf では、bassslcfg ユーティリティーを使用する。– その他すべての構成ファイルには、svrsslcfg ユーティリティーを使用する。

多くのスタンザまたは値は、構成プログラムを使用してのみ作成または変更されます。一部の値は、構成の完了後に自動的に入力されます。これらの値を手動で編集しないでください。

4. 影響のある Tivoli Access Manager サーバーを再始動する。

たとえば、ivmgrd.conf ファイルに変更を加える場合、ポリシー・サーバーを停止し、変更を加え、変更を有効にするためにすべてのポリシー・サーバーを再始動します。


スタンザスタンザ・レベルは、たとえば [stanza-name] のように、ブラケット内に表示されます。. たとえば、ivmgrd.conf 構成ファイルの [ssl] スタンザは、ポリシー・サーバーの Secure Sockets Layer (SSL) 構成の設定を定義します。[ldap] スタンザは、LDAP ベースのユーザー・レジストリーと通信するためにポリシー・サーバーが必要とする構成の設定を定義します。

Tivoli Access Manager 構成ファイルの各スタンザには、パラメーターのペア・セットとして表現される情報を含む、1 つ以上のキー値ペアが入っています。各スタンザ・エントリーは、次の形式で示されます。

キー = 値

構成ファイル内のキー名は変更しないでください。キー名を変更すると、サーバーに予測不能な問題が起こる可能性があります。等号 (=) を囲むスペースは必須ではありませんが、推奨されています。

Tivoli Access Manager の初期インストールの際、多くのデフォルト値が設定されます。一部の値は、静的で変更できないものもありますが、それ以外の値は、変更して、サーバー機能やパフォーマンスのカスタマイズを行うことができます。

以下の各スタンザの説明で、キー値ペアで構成されている各スタンザの有効なスタンザ・エントリーのリストをスタンザごとに示します。スタンザ・エントリーには、そのエントリーのデフォルトの動作の説明が含まれています。


[authentication-mechanisms] スタンザこのスタンザは、パスワードおよび証明書認証に使用されるライブラリーを定義します。

このスタンザの構成エントリーは、サーバーがユーザー・レジストリーと通信するために必要です。ユーザー・レジストリーのタイプによって、User Registry Adapter

Framework (URAF) レジストリー (Active Directory または Domino)、または LDAP

レジストリー・ライブラリーを使用できます。

ユーザー・レジストリーのタイプは 1 つのみを指定するためできないため、[authentication-mechanisms] スタンザ内の特定のキー値ペアは相互排除的です。たとえば、次のとおりです。

# passwd-uraf = /opt/PolicyDirector/lib/liburafauthn.a# cert-uraf = /opt/PolicyDirector/lib/liburafcertauthn.apasswd-ldap = C:\pd\bin\ldapauthn.dll & -cfgfile [C:/pd/etc/ivacld.conf]cert-ldap = C:\pd\bin\certauthn.dll & -cfgfile [C:/pd/etc/ivacld.conf]

この例では、URAF レジストリー項目は、ポンド記号 (#) を使用してコメント化されています。LDAP 指向のスタンザ・エントリーはコメント化されていません。

Tivoli Access Manager ユーザー・レジストリーを構成するためのスタンザ・エントリーは、以下の構成ファイルの各 [authentication-mechanism] スタンザにあります。

v 許可サーバー pdacld の ivacld.conf

v ポリシー・サーバー pdmgrd の ivmgrd.conf

以下の値は手動で編集できます。構成ユーティリティーは必要ありません。

[authentication-mechanisms] スタンザ

passwd-uraf = fully_qualified_path

パスワード認証に使用するライブラリーの場所

このスタンザ・エントリーは、URAF レジストリーをユーザー・レジストリーとして使用する場合に必要です。

デフォルト値は次のとおりです。v AIX: /opt/PolicyDirector/lib/liburafauthn.a

v HP: /opt/PolicyDirector/lib/liburafauthn.sl

v Sun: /opt/PolicyDirector/lib/liburafauthn.so

v Linux: /opt/PolicyDirector/lib/liburafauthn.so

v Windows: install_dir¥bin¥urafauthn.dll

Linux の例: passwd-uraf = ../opt/PolicyDirector/lib/liburafauthn.so

cert-uraf = fully_qualified_path


証明書認証に使用するライブラリーの場所

このスタンザ・エントリーは、URAF レジストリーをユーザー・レジストリーとして使用する場合に必要です。

デフォルト値は次のとおりです。v AIX: /opt/PolicyDirector/lib/liburafcertauthn.a

v HP: /opt/PolicyDirector/lib/liburafcertauthn.sl

v Solaris: /opt/PolicyDirector/lib/liburafauthn.so

v Linux: /opt/PolicyDirector/lib/liburafcertauthn.so

v Windows: install_dir¥bin¥urafcertauthn.dll

Solaris の例: cert-uraf = ../opt/PolicyDirector/lib/liburafauthn.so

passwd-ldap=fully_qualified_path

LDAP パスワード認証に使用するライブラリーの場所

このスタンザ・エントリーは、LDAP をユーザー・レジストリーとして使用する場合に必要です。

デフォルト値は次のとおりです。v AIX: /opt/PolicyDirector/lib/libldapauthn.a

v HP: /opt/PolicyDirector/lib/libldapauthn.sl

v Solaris: /opt/PolicyDirector/lib/libldapauthn.so

v Linux: /opt/PolicyDirector/lib/libldapauthn.so

v Windows: install_dir¥bin¥ldapauthn.dll

AIX の例: passwd-ldap = ../opt/PolicyDirector/lib/libldapauthn.a

cert-ldap = fully_qualified_path

LDAP 証明書認証に使用するライブラリーの場所

このスタンザ・エントリーは、LDAP をユーザー・レジストリーとして使用する場合に必要です。

デフォルト値は次のとおりです。v AIX: /opt/PolicyDirector/lib/libcertauthn.a

v HP: /opt/PolicyDirector/lib/libcertauthn.sl

v Solaris: /opt/PolicyDirector/lib/libcertauthn.so

v Linux: /opt/PolicyDirector/lib/libcertauthn.so

v Windows: install_dirbin¥certauthn.dll

Windows の例: passwd-ldap = C:\pd\bin\certauthn.dll & -cfgfile

[C:/pd/etc/ivacld.conf]


[aznapi-admin-services] スタンザ管理サービス・プラグインにより、アプリケーションは Tivoli Access Manager セキュア・ドメイン内で保護されている保護オブジェクト・リソースで、アプリケーション固有の管理タスクを実行できます。

管理サービス・プラグインは、Tivoli Access Manager 管理 API 呼び出しを送信する呼び出しアプリケーションによりアクセスされます。呼び出しアプリケーションは、Tivoli Access Manager pdadmin コマンド、または Tivoli Access Manager Web

Portal Manager などの管理ユーティリティー、または特注アプリケーションのいずれかです。アドミニストレーション・サービスは、管理 API 呼び出しを、対応するアドミニストレーション・サービス API 呼び出しにマップし、要求されたアクションを実行します。各アドミニストレーション・サービス・プラグインは、許可サービスに動的にロードされるスタンドアロンのモジュールです。

Tivoli Access Manager アドミニストレーション・サービス・プラグインを構成するパラメーターは、Tivoli Access Manager が提供する以下の構成ファイルの[aznapi-admin-services] スタンザで宣言されています。



アドミニストレーション・サービス・プラグインは通常、[aznapi-admin-services]

スタンザの下にある aznapi.conf 構成ファイルでも構成できます。

アドミニストレーション・サービス・プラグインの開発者は、標準的な機能を提供する必要があります。外部許可サービス (EAS) プラグインをインプリメントする前に、IBM Tivoli Access Manager Authorization C API デベロッパーズ・リファレンスで説明されている概説を読んで完全に理解してください。


[aznapi-admin-services] スタンザ

service-id = {short_name|path_to_dll} [-pobj protected_object_hierarchy_name ] [& params]

プラグインが保護プロジェクト階層の定義済みの部分のコンテンツを取得できる、またはプラグインがアプリケーション固有の管理タスクを実行するコマンドを返す管理タスクを定義できる機能の許可 API サービスを定義します。各スタンザ・エントリーはさまざまなタイプの aznAPI サービスを定義し、各エントリーは同じフォーマットで示され、以下を指定します。

service-id

アドミニストレーション・サービスの開発者固有の ID 許可 API アプリケーションは 1 つ以上のアドミニストレーション・サービス・プラグインを登録できますが、それぞれのサービス ID は固有である必要があります。

{short_name|path_to_dll}

サービス実行可能コードを含むダイナミック・リンク・ライブラリー (DLL) へのパス

DLL が、DLL 用システム (例: UNIX プラットフォームの /usr/lib およびWindows NT の %PATH%) が通常検索するディレクトリに常駐している場合は、DLL への絶対パスを指定する必要はなく、DLL 名のみを指定します。任意のサポートされている Tivoli Access Manager プラットフォームでロードできる、プラットフォームに依存しない DLL 名を必要とする場合は、ライブラリーの短縮名を入力します。短縮名は前に付加され、各プラットフォームの既知のライブラリーのプレフィックスおよびサフィックスが付加され、すべての可能性は順番に検索されます。たとえば、azn_ent_user のライブラリー短縮名を使用すると、以下の名前が自動的に各プラットフォーム用に検索されます。

NT: azn_ent_user.dllAIX: libazn_ent_user.so, libazn_ent_user.aSolaris: libazn_ent_user.soHP/UX: libazn_ent_user.sl

protected_object_hierarchy_name

保護オブジェクト階層名はオプションのパラメーターです。このパラメーターは、保護オブジェクト・スペース (階層) の名前、または単純に保護オブジェクトを参照します。保護オブジェクト階層名は、許可 API アプリケーションの範囲内でアドミニストレーション・サービス・プラグインごとに固有である必要があります。ただし、複数の許可 API アプリケーションのインスタンスを、同じ保護オブジェクト階層名を保守するために登録できます。これにより、特定の許可 API

アプリケーション・サーバーに障害が発生した場合に、オブジェクト・スペースの管理に対してフェイルオーバー・サポートを提供します。

params オプションで、外部許可サービス (EAS) は、引き数の形式で追加の初期化情報を受け渡すことができます。引き数は、アンパーサンド (例: & -server fred) に先行される必要があります。許可サービスは、アンパーサンド & の後の文字を処理しません。これらの文字は、アドミニストレーション・サービス・プラグインに直接受け渡されます。サービスの定義については、IBM Tivoli Access Manager

Authorization C API デベロッパーズ・リファレンスに詳しく説明されています。

このスタンザ・エントリーはオプションです。

デフォルト値はありません。

例: AZN_ADMIN_SVC_TRACE = pdtraceadmin


[aznapi-configuration] スタンザTivoli Access Manager を使用すると、許可 API を使用した認証へのアプローチが高度に柔軟になります。標準ベースの許可 API によって、アプリケーションは集中許可サービスを呼び出すことができます。Tivoli Access Manager は、許可 API を介してユーザー名およびパスワード許可を行う、組み込みサポートを備えています。開発者は、許可 API を使用する任意のカスタム許可メカニズムを構築できます。

Tivoli Access Manager サーバー監査証跡ファイルを構成する構成キー値ペアは、以下の構成ファイルの各 [aznapi-configuration] スタンザにあります。



[aznapi-configuration] スタンザ

logsize = {0|neg_number_bytes number_bytes}

監査ログのログ・ファイル・ロールオーバーしきい値 (バイト単位)。監査ログ・ファイルがこのしきい値に到達した場合、オリジナルの監査ログ・ファイルは名前変更され、新しいログ・ファイルがオリジナルの名前で作成されます。

有効値は次のとおりです。0 ゼロは、ロールオーバー・ファイルが作成されていないことを示しま

す。neg_number_bytes

負の数値はすべて、ログがサイズにかかわらず、毎日ロールオーバーされていることを示します。

number_bytes

ロールオーバーが発生する前の監査ログ・ファイルの最大サイズ (バイト)。許容範囲は、1 バイトから 2 メガバイトです。


デフォルト値: 0

例: logsize = 2000000

logflush = number_seconds

監査ログのログ・ファイル・バッファーのログ・フラッシュの時間間隔 (秒)

有効値は次のとおりです。number_seconds

秒数。有効範囲は、1 秒から 600 秒 (10 分)。


デフォルト値: 600 秒

例: logflush = 20

logaudit = {yes|true|no|false}


監査パラメーターのオン/オフを切り替えることによって、監査するかどうかを指示します。

有効値は次のとおりです。yes|true 監査が使用可能またはオンになっているno|false 監査が使用不可またはオフになっている。


デフォルト値: no|false

例: logaudit = no

auditlog = fully_qualified_path

ローカル・クライアント用の監査証跡ファイルの場所。場所と名前が提供されていない場合、監査は実行されません。各サーバーは、対応する構成ファイルに独自の監査ログ設定を提供しています。

完全修飾パス値は、英数字ストリングで表わされます。

logaudit = yes の場合、このスタンザ・エントリーは必須です。


Windows の例: auditlog = C:\pd\audit\pdacld.log

auditcfg = {azn|authn|mgmt}

監査ロギング構成イベントの取り込み。

コンポーネント固有の監査レコードを使用可能にするには、適切な定義を追加します。各サーバーは、構成ファイルで独自の値を提供します。たとえば、aznAPI.conf のデフォルトの動作は、azn です。pdacld.conf のデフォルトの動作も azn です。

1 つ以上の auditcfg 値を同時に使用できます。適用されないスタンザ・エントリーをコメント化します。スタンザ・エントリーをコメント化するには、エントリーの開始にポンド記号 (#) を使用します。たとえば、次のとおりです。

auditcfg = aznauditcfg = authn#auditcfg = mgmt

有効値は次のとおりです。azn 許可イベントの取り込みに使用。authn 認証イベントの取り込みに使用。mgmt 管理イベントの取り込みに使用。

このスタンザ・エントリーは、logaudit = yes の場合に必須です。


例: auditcfg = azn

logcfg = category:[{stdout|stderr|file|pipe|remote}] \

[[param[=value]][param[=value]]]


Tivoli Access Manager イベントの取り込みに使用されるカテゴリー、宛先、およびパラメーター。各サーバーは、対応する構成ファイルで独自のイベント・ロギング設定を提供しています。

有効値は次のとおりです。category

イベント・プール内のイベントのカテゴリー

例:

audit.azn:log-agentEventPool:param=value

param 許可パラメーター。パラメーターは、カテゴリー、イベントの宛先、および実行する監査のタイプにより異なります。logcfg パラメーターの具体的な例については、以下のイベントのロギング宛先を参照してください。v 154ページの『コンソールのロギング』v 155ページの『ファイルのロギング』v 159ページの『パイプ・ロギング』v 159ページの『リモート・ロギング』

value フォーマットで指定されるパラメーターの値

hi_water = number



許可監査とロギングを構成する例:

logcfg = audit.azn:file ¥path=/opt/PolicyDirector/log/audit.log,rollover_size=-1

リモート監査とロギングの構成例:

logcfg = audit:remote buffer=2000,compress=y,error=2, ¥path=/opt/PolicyDirector/log/remote.cache,rebind=600,¥server=timelord,port=7136

標準出力にすべての監査出力を取り込む例:

logcfg = audit:stdout

イベントをファイルに記録し、ログ・ファイル構成を指定する例:

logcfg = audit.azn:file path=/opt/PolicyDirector/log/audit.log, ¥rollover_size=-1,flush=20,log_id=audit

db-file = fully_qualified_path

認証イベントを取り込むための pdacld データベース・キャッシュ・ファイルの名前と場所。この値は指定される必要があり、各サーバーは独自の値を提供しています。

fully_qualified_path 値は、大文字小文字の区別のない英数字ストリングで表されます。

logaudit = yes の場合、このスタンザ・エントリーは必須です。


Windows の例: db-file = C:\pd\db\ivacld.db


cache-refresh-interval = {disable|default|number_seconds}

マスター許可サーバーへの更新を検査するポーリング間隔。注: ローカル・キャッシュが再ビルドされるのは、更新が検出された場合のみです。

このスタンザ・エントリーは、このサーバーが許可ポリシー・データベース・パスを指定する独自のスタンザ・エントリーを持つため、ivmgrd.conf ファイルで使用されません。

有効値は次のとおりです。disable

秒単位の間隔値は設定されていません。default デフォルト値の 600 秒が使用されています。number_seconds

秒数を指定することにより設定される正確な時間間隔。有効範囲は、0

から符号なしの整数 (およそ 136 年) です。


デフォルト値: default

例: cache-refresh-interval = 500

listen-flags = {enable|disable}

ポリシー・キャッシュ更新通知の受信をオンまたはオフにする指示。このパラメーターは、svrsslcfg ユーティリティーで設定されます。

有効値は次のとおりです。enable 通知リスナーを活動化します。disable

通知リスナーを非活動化します。


デフォルト値: disable

例: listen-flags = enable

azn-app-host = other_hostname


AZN アプリケーションが listen するホストをカスタマイズするために使用される属性。

other_hostname に、任意の有効なインターネット・ホスト名を規定できます。この属性が指定されない場合は、デフォルトのホスト名が使用されます。

デフォルトでは、この属性は使用不可です。使用不可の場合、スタンザ・エントリーは、構成ファイルのスタンザ・エントリーの開始にポンド記号 (#) を使用することによりコメント化されます。たとえば、次のとおりです。

#azn-app-host = libra

この値を使用可能にするには、構成ファイルのエントリーを、ポンド記号 (#) を除去することによりアンコメントします。AZN アプリケーションが listen するホストのホスト名値を含むようにしてください。



例: azn-app-host = libra.dallas.ibm.com


[aznapi-cred-modification-services] スタンザ信任状変更サービス・プラグインを使用すると、許可 API アプリケーションはTivoli Access Manager 信任状を変更できます。次に、信任状変更サービスは、この変更された信任状を呼び出しアプリケーションで使用できるように戻します。アプリケーションは、このサービスを使用して、ユーザーの信任状に情報を追加できます。たとえば、この追加情報にはユーザーのクレジット・カード番号およびユーザーの信用限度が含まれます。各信任状変更サービス・プラグインは、許可サービスに動的にロードされるスタンドアロンのモジュールです。

Tivoli Access Manager 信任状変更サービス・プラグインを構成するパラメーターは、Tivoli Access Manager が提供する以下の各構成ファイルの[aznapi-cred-modification-services] スタンザで宣言されています。



信任状変更サービス・プラグインは通常、[aznapi-cred-modification-service] スタンザの下にある aznapi.conf 構成ファイルでも構成できます。

信任状変更サービス・プラグインの開発者は、特定の標準機能を提供する必要があります。信任状変更サービス・プラグインをインプリメントする前に、IBM Tivoli

Access Manager Authorization C API デベロッパーズ・リファレンスで説明されている概説を読んで完全に理解してください。

[aznapi-cred-modification-services] スタンザ

service-id = short_name|path_to_dll [ & params ... ]


信任状属性リスト変更サービスの許可 API サービスを定義します。各スタンザ・エントリーは、さまざまなタイプの aznAPI サービスを定義し、各エントリーは同じ形式で示され、以下を指定します。

service-id

信任状変更サービスの開発者固有の ID。サービス ID ストリングは固有である必要があります。

{short_name|path_to_dll}サービス実行可能コードを含むダイナミック・リンク・ライブラリー(DLL) へのパス。

DLL が、DLL 用システム (例: UNIX プラットフォームの /usr/lib および Windows NT の %PATH%) が通常検索するディレクトリーに常駐している場合は、DLL への絶対パスを指定する必要はなく、DLL 名のみを指定します。任意のサポートされている Tivoli Access Manager プラットフォームでロードできる、プラットフォームに依存しない DLL 名を必要とする場合は、ライブラリーの短縮名を入力します。短縮名は前に付加され、各プラットフォームの既知のライブラリーのプレフィックスおよびサフィックスが付加され、すべての可能性は順番に検索されます。たとえば、azn_ent_user のライブラリー短縮名を使用すると、以下の名前が自動的に各プラットフォーム用に検索されます。


params オプションで、aznAPI により初期化された場合にサービスに受け渡すパラメーターを指定できます。ストリング内でアンパーサンド (&) 記号に続くすべてのデータが、パラメーターであるとみなされます。サービスの定義については、IBM Tivoli Access Manager Authorization C API デベロッパーズ・リファレンスに詳しく説明されています。



例: AZN_MOD_SVC_RAD_2AB = azn_mod_rad


[aznapi-entitlement-services] stanza資格サービス・プラグインを使用すると、許可 API アプリケーションは資格リポジトリーからユーザーの資格を検索できます。各資格サービス・プラグインは、許可サービスに動的にロードされるスタンドアロンのモジュールです。

Tivoli Access Manager 資格サービス・プラグインを構成するスタンザ・エントリーは、Tivoli Access Manager が提供する以下の各構成ファイルの[aznapi-entitlement-services] スタンザで宣言されています。



資格サービス・プラグインは通常、[aznapi-entitlement-services] スタンザの下にある aznapi.conf 構成ファイルでも構成できます。

資格サービス・プラグインの開発者は、特定の標準機能を提供する必要があります。資格サービス・プラグインをインプリメントする前に、IBM Tivoli Access

Manager Authorization C API デベロッパーズ・リファレンスで説明されている概説を読んで完全に理解してください。

[aznapi-entitlement-services] スタンザ

service-id = {short_name|path_to_dll} [ & params ... ]


保護オブジェクト資格サービスの許可 API サービスを定義します。各スタンザ・エントリーはさまざまなタイプの aznAPI サービスを定義し、各エントリーは同じフォーマットで示され、以下を指定します。

service-id

aznAPI クライアントによりサービスを識別できる開発者固有の ID。サービス ID ストリングは固有である必要があります。




params オプションで、aznAPI により初期化された場合にサービスに受け渡す、1 つ以上のパラメーターを指定できます。ストリング内でアンパーサンド (&) 記号に続くすべてのデータが、パラメーターであるとみなされます。サービスの定義については、IBM Tivoli Access Manager

Authorization C API デベロッパーズ・リファレンスに詳しく説明されています。



例: AZN_ENT_EXT_ATTR = azn_ent_ext_attr


[aznapi-external-authzn-services] スタンザ外部許可サービス (EAS) プラグインは、Tivoli Access Manager 許可サービスのオプション拡張機能であり、これによって追加の許可コントロールと条件を設定できます。外部許可サービス (EAS) プラグインを使用して、Tivoli Access Manager 許可サービスが関知しないアプリケーション固有の基準に基づいて許可決定を下すように設定できます。各外部許可サービス (EAS) プラグインは、許可サービスに動的にロードされるスタンドアロンのモジュールです。

Tivoli Access Manager 外部許可サービス (EAS) プラグインを構成するパラメーターは、Tivoli Access Manager が提供する以下の構成ファイルの[aznapi-external-authzn-services] スタンザで宣言されています。



資格サービス・プラグインは、[aznapi-external-authzn-services] スタンザの下にある aznapi.conf 構成ファイルでも構成できます。

外部許可サービス (EAS) プラグインの開発者は、特定の標準機能を提供する必要があります。外部許可サービス (EAS) プラグインをインプリメントする前に、IBM

Tivoli Access Manager Authorization C API デベロッパーズ・リファレンスで説明されている概説を読んで完全に理解してください。

[aznapi-external-authzn-services] スタンザ

policy-trigger = {short_name|path_to_dll} [ & params ... ]


アプリケーション固有の基準に基づいて許可決定を下すように設定する、外部許可サービス(EAS) の定義の許可 API を定義します。各スタンザ・エントリーは、さまざまなタイプのaznAPI サービスを定義し、各エントリーは同じ形式で示され、以下を指定します。

policy-trigger

ポリシー・トリガーは、外部許可サービス (EAS) を許可エンジンにより呼び出す手段です。これは、サービス ID またはアクセス・コントロール・リスト (ACL)

アクション・ストリングのいずれかです。たとえば、my_service_1 または Trx

です。サービスがサービス ID を使用して定義される場合、サービス ID は、オブジェクトが POP を付加するときは常に外部許可サービス (EAS) をトリガーする POP ポリシーで拡張属性として使用されます。サービスが ACL アクション・ストリングを使用して定義される場合、サービスは、この ACL アクション・マスクが許可決定の一環として要求されるときは常に呼び出されます。

ポリシー・トリガーは、有効キー名として認識される任意のストリングです。policy-trigger ストリングは、アクション自体に大文字小文字の区別があるため、アクション・セットの定義で大文字小文字を区別します。ただし、トリガーが POP 属性である場合は、ポリシー・トリガーは大文字小文字を区別しません。

{short_name`|path_to_dll}

サービス実行可能コードを含むダイナミック・リンク・ライブラリー (DLL) へのパス。

DLL が、DLL 用システム (例: UNIX プラットフォームの /usr/lib およびWindows NT の %PATH%) が通常検索するディレクトリーに常駐している場合は、DLL への絶対パスを指定する必要はなく、DLL 名のみを指定します。任意のサポートされている Tivoli Access Manager プラットフォームでロードできる、プラットフォームに依存しない DLL 名を必要とする場合は、ライブラリーの短縮名を入力します。短縮名は前に付加され、各プラットフォームの既知のライブラリーのプレフィックスおよびサフィックスが付加され、すべての可能性は順番に検索されます。たとえば、azn_ent_user のライブラリー短縮名を使用すると、以下の名前が自動的に各プラットフォーム用に検索されます。


[-weight number]

特定の外部許可サービス (EAS) へのアクセス決定プロセスに割り当てられている加重。重量パラメーターは、符号なしの size_t 値であり、オプションです。値は、この外部許可サービス (EAS) により戻された決定が決定プロセス全体で与えられる必要のある重量を示しています。デフォルト値は 101 です。

params オプションで、外部許可サービス (EAS) は、引き数の形式で追加の初期化情報を受け渡すことができます。引き数は、アンパーサンド (例: & -server fred) に先行される必要があります。サービスの定義については、IBM Tivoli Access

Manager Authorization C API デベロッパーズ・リファレンスに詳しく説明されています。




[aznapi-pac-services] スタンザPAC サービス・プラグインにより、許可 API アプリケーションは、Tivoli Access

Manager 信任状を、ネイティブ Tivoli Access Manager 信用状フォーマットと特権属性証明書 (PAC) と呼ばれる代替フォーマットの間で移動できます。各 PAC サービス・プラグインは、許可サービスに動的にロードされるスタンドアロンのモジュールです。

ID 情報は PAC から取得できます。アプリケーションは、PAC へのユーザー信任状をほかの許可ドメインで使用できるように変換できます。次に、アプリケーションは、PAC をほかの許可ドメインのサーバーに受け渡して、操作を実行できます。

Tivoli Access Manager PAC サービス・プラグインを構成するスタンザ・エントリーは、Tivoli Access Manager が提供する以下の各構成ファイルの[aznapi-pac-services] スタンザで宣言されています。



PAC サービス・プラグインは通常、[aznapi-pac-services] スタンザの下にあるaznapi.conf 構成ファイルでも構成できます。

PAC サービス・プラグインの開発者は、特定の標準機能を提供する必要があります。 PAC サービス・プラグインをインプリメントする前に、IBM Tivoli Access

Manager Authorization C API デベロッパーズ・リファレンスで説明されている概説を読んで完全に理解してください。

[aznapi-pac-services] スタンザ

service-id = {short_name|path_to_dll} [ & params ... ]


Tivoli Access Manager 特権属性証明書 (PAC) エンコード・サービスの許可 API

サービスを定義します。各スタンザ・エントリーは、さまざまなタイプの aznAPI

サービスを定義し、各エントリーは同じ形式で示され、以下を指定します。

service-id

PAC を生成する PAC サービスの開発者固有の ID。サービス ID ストリングは固有である必要があります。




params オプションで、aznAPI により初期化された場合にサービスに受け渡すパラメーターを指定できます。ストリング内でアンパーサンド (&) 記号に続くすべてのデータが、パラメーターであるとみなされます。サービスの定義については、IBM Tivoli Access Manager Authorization C API デベロッパーズ・リファレンスに詳しく説明されています。




[delegated-admin] スタンザTivoli Access Manager 構成は、ユーザーにグループ・リストで戻された各グループを表示することを許可するように要求できます。または、ユーザーは最初に許可されずにリストを戻すために許可されることもできます。

代行管理の場合、1 タイプのインターフェースをプロセス全体に使用して、最適な結果を得る必要があります。Web Portal Manager または pdadmin コマンドのいずれかを使用します。このスタンザは、pdadmin コマンドのみと関連があります。

さらに必要と思われる情報

グループおよびユーザーの代行管理のために許可チェックの設定のオン/オフを切り替えるスタンザ・エントリーは、次の構成ファイルの [delegated-admin] スタンザにあります。


[delegated-admin] スタンザ

authorize-group-list = {yes|no}

group list および group list-dn pdadmin コマンドの許可チェックが行われるかどうかの指示。

このキーワードは、性能特性として提供されます。

有効値は次のとおりです。yes 許可チェックを使用可能にします。no 許可チェックを使用不可にします。


デフォルト値: no

例: authorize-group-list = yes


[ivacld] スタンザ許可サーバーに関連する情報を構成するためのスタンザ・エントリーは、次の構成ファイルの [ivacld] スタンザにあります。


[ivacld] スタンザ

tcp-req-port = {0|port_number}

サーバーが要求を listen している伝送制御プロトコル (TCP)。

有効値は次のとおりです。0 ポート番号を使用不可にします。port_number

ポート番号を使用可能にします。

port_numberに、任意の有効なポート番号を使用します。有効なポート番号は、TCP/IP で許可されていて、現在ほかのアプリケーションに使用されていない任意の正数です。デフォルトのポート番号の値を使用するか、または現在使用されていない 1000 以上のポート番号を使用することをお勧めします。

このスタンザ・エントリーは必須です。


例: tcp-req-port = 7136

pid-file = fully_qualified_path

PID ファイルの場所および名前。


Windows 用のデフォルト値:

C:¥pd¥log¥ivacld.pid

UNIX 用のデフォルト値:

/var/PolicyDirector/log/ivacld.pid

Windows の例:

pid-file = C:\pd\log\ivacld.pid

log-file = fully_qualified_path


サーバー・ログ・ファイルの場所および名前。メッセージが STDOUT およびSTDERR からリダイレクトされ、pdacld 許可サーバー構成ファイルで定義されたサーバー・ログ・ファイルに送られます。



C:¥pd¥log¥msg__ivacld.log


/var/PolicyDirector/log/msg__ivdacld.log

Windows の例:

log-file = C:\pd\log\msg__ivacld.log

unix-user = user_name

このサーバーの UNIX ユーザー・アカウント。 UNIX グループとユーザー名は異なる項目であり、両者に同じ値を割り当てることができます。指定されたユーザー名の妥当性は、UNIX プラットフォームの要件により異なります。

UNIX ユーザー・アカウントで作業する場合、このスタンザ・エントリーは必須です。

デフォルト値: ivmgr

例: unix-user = ivmgr

unix-group = group_name

このサーバーの UNIX グループ・アカウント。 UNIX グループとユーザー名は異なる項目であり、両者に同じ値を割り当てることができます。指定されたグループ名の妥当性は、UNIX プラットフォームの要件により異なります。

UNIX でグループで作業する場合、このスタンザ・エントリーは必須です。


例: unix-group = ivmgr

permit-unauth-remote-caller= {true|false}


許可 API クライアントの要求が処理される前に、その許可 API クライアントが許可サーバーによって許可されているべきかどうかの指示。

有効値は次のとおりです。true 許可 API クライアントは許可されるべきではありません。

警告: true に設定すると、ポリシー・データベースがドメイン内で公開され、remote-acl-users グループでメンバーシップに正当に許可されたクライアントに限らず、すべてのクライアントが読み取れます。ドメイン・セキュリティー内のポリシーの性質に応じて、システム・プランナーはすべてのクライアントがシステム定義ポリシーを読み取ることのできる状況をセキュリティー問題とみなす必要があります。

false 許可 API クライアントは許可されるべきです。


デフォルト値: false

例: permit-unauth-remote-caller= false


[ivmgrd] スタンザポリシー・サーバーおよびポリシー・データベース (マスター許可データベースとしても知られる) を構成するためのスタンザ・エントリーは、次の構成ファイルの[ivmgrd] スタンザにあります。


[ivmgrd] スタンザ

unix-user = user_name

このサーバーの UNIX ユーザー・アカウント。 UNIX グループとユーザー名は異なる項目であり、両者に同じ値を割り当てることができます。指定されたユーザー名の妥当性は、UNIX プラットフォームの要件により異なります。



例: unix-user = ivmgr

unix-group = group_name

このサーバーの UNIX グループ・アカウント。 UNIX グループとユーザー名は異なる項目であり、両者に同じ値を割り当てることができます。指定されたグループ名の妥当性は、UNIX プラットフォームの要件により異なります。



例: unix-group = ivmgr

database-path = fully_qualified_path

ポリシー・データベース (マスター許可データベースとしても知られる) の場所と名前。ファイル・タイプは任意ですが、通常、拡張子は .db です。注: このスタンザ・エントリーを構成ファイル内で編集することはお勧めしません。


UNIX 用のデフォルト値

/var/PolicyDirector/db/master_authzn.db


C:¥pd¥db¥master_authzn.db

Windows の例: database-path = C:\pd\db\master_authzn.db

tcp-req-port = {0|port_number}


サーバーが要求を listen している TCP ポート。

有効値は次のとおりです。0 ポート番号を使用不可にします。port_number

ポート番号を使用可能にします。

port_numberには、任意の有効なポート番号を使用します。有効なポート番号は、TCP/IP で許可されていて、現在ほかのアプリケーションに使用されていない任意の正数です。デフォルトのポート番号の値を使用するか、または現在使用されていない 1000 以上のポート番号を使用することをお勧めします。



例: tcp-req-port = 7135

auto-database-update-notify = {yes|true|no|false}

許可データベース・レプリカの自動または手動の更新通知の指示。

有効値は以下のとおりです。yes|true

自動更新通知を使用可能にします。この自動的な設定は、データベースの変更の数が少なく、頻繁ではない環境に適しています。更新通知が自動化されるように構成するときは、max-notifier-threads= およびnotifier-wait-time= スタンザ・エントリーを正しく構成することも必要です。

no|false手動更新通知を使用可能にします。


デフォルト値: yes

例: auto-database-update-notify = yes

max-notifier-threads = num_threads


イベント通知スレッドの最大数。ポリシー・サーバーは、セキュア・ドメイン内のすべてのデータベース・レプリカの同期化を担当しています。マスター・データベースに変更が加えられると、通知スレッドがこの変更をすべてのレプリカに知らせる作業を行います。そうすると、それぞれのレプリカでは、新しい情報をマスター・データベースからダウンロードする必要があります。

更新通知スタンザ・エントリーが自動に設定されている場合 (yes)、このスタンザ・エントリーおよび notifier-wait-time= スタンザ・エントリーを正しく構成する必要があります。

通常、num_threads には、既存のレプリカと同じ数を設定します。有効な正の整数を指定します。スレッド数の有効範囲は、1 から 128 スレッドです。

auto-database-update-notify = yes の場合、このスタンザ・エントリーは必須です。


例: max-notifier-threads = 20.

notifier-wait-time = time_seconds

許可ポリシー・データベースが活動停止中になってから、レプリカに通知が送信されるまでの時間。ポリシー・サーバーは、マスター許可データベースへの変更を行うよう指示されると、デフォルトによる時間を待ってから、データベース・レプリカに通知を送ります。この遅延時間は、今後データベースに変更が加えられるたびにリセットされます。

更新通知スタンザ・エントリーが自動に設定されている場合 (yes)、このスタンザ・エントリーおよび max-notifier-threads= スタンザ・エントリーを正しく構成する必要があります。

有効な値:

number_seconds

許可ポリシー・データベースが活動停止中になってから、レプリカに通知が送信されるまでの秒数。有効範囲は、??? 秒から ??? 秒までです。

auto-database-update-notify = yes の場合、このスタンザ・エントリーは必須です。


例: notifier-wait-time = 30

pid-file = fully_qualified_path


PID ファイルの場所および名前。



/var/PolicyDirector/log/ivmgrd.pid


C:¥pd¥log¥ivmgrd.pid

UNIX の例: pid-file = /var/PolicyDirector/log/ivmgrd.pid

log-file = fully_qualified_path

ログ・ファイルの場所および名前。メッセージが STDOUT および STDERR からリダイレクトされ、サーバー構成ファイルで定義されるサーバー・ログ・ファイルに送られます。



C:¥pd¥log¥msg__pdmgrd.log


/var/PolicyDirector/log/ msg__ivmgrd.log

Windows の例: log-file = C:\pd\log\msg__pdmgrd.log

ca-cert-download-enabled = {yes|no}

ほかの Tivoli Access Manager ランタイムがルート CA 証明書を自動的にダウンロードできるかどうかの指示。この値を設定するには、 mgrsslcfg 構成ユーティリティーを使用します。

有効値は以下のとおりです。yes クライアントがルート CA 証明書を自動的にダウンロードすることを許

可します。。no クライアントがルート CA 証明書を自動的にダウンロードすることを許

可しません。


有効値: no

例: ca-cert-download-enabled = yes


[ldap] スタンザこのスタンザは、LDAP レジストリー・サーバーと通信するのに必要な構成キー値ペアを定義します。たとえば、構成ファイルのこのスタンザでは、マスターおよびレプリカ・サーバーの使用を含めて、LDAP フェイルオーバーの構成キーおよび値を検索できます。

ユーザー・レジストリーの値は、pd.conf ファイルにより決定されます。pd.conf

ファイルは、Tivoli Access Manager ランタイム・コンポーネントが構成されるときに作成されます。

構成のキー値ペアは、以下の各構成ファイルの [ldap] スタンザにあります。

v IBM Directory サーバーをユーザー・レジストリーとして使用する場合は、ldap.conf



このスタンザでキー=値ペアをパフォーマンス・チューニングの目的で使用する方法については、IBM Tivoli Access Manager パフォーマンス・チューニング・ガイドを参照してください。

[ldap] スタンザ

ldap-server-config = fully_qualified_path

ldap.conf 構成ファイルの場所。 fully_qualified_path の値は、大文字小文字の区別のない英数字ストリングで表されます。

このスタンザ・エントリーは、ldap.conf 以外の構成ファイルで必須です。


/opt/PolicyDirector/etc/ldap.conf

Windows 用のデフォルト値: C:\pd\etc\ldap.conf

UNIX の例: ldap-server-config = /opt/PolicyDirector/etc/ldap.conf

enabled = {yes|true|no|false}

LDAP がユーザー・レジストリーとして使用されているかどうかの指示。一度に指定できるユーザー・レジストリーは 1 つのみです。


LDAP ユーザー・レジストリー・サポートを使用可能にします。no|false

LDAP ユーザー・レジストリー・サポートを使用不可にし、LDAP が使用中のユーザー・レジストリーではないことを示します。yes|true 以外のすべては、ブランク値も含め、no|false として解釈されます。

このスタンザ・エントリーは、LDAP がユーザー・レジストリーである場合に必須です。

デフォルトの値は、サーバーの構成方法に応じて異なります。

例: enabled = yes


host = host_name

LDAP サーバーのホスト名。host_name の有効な値は、任意のインターネット・プロトコル (IP) ホスト名です。

host_name の値は、pd.conf ファイルから取得されます。pd.conf ファイルは、Tivoli Access Manager ランタイム・コンポーネントがマシン上で構成されるときに作成されます。

svrsslcfg ユーティリティーを、構成された Policy Director ユーザー・レジストリーが LDAP である場合、host_name の値を設定するために使用します。


デフォルト値はありません。値は、pd.conf ファイルから取得されます。

ホスト名の例:

host = libra

host = libra.dallas.ibm.com

port = port_number

LDAP サーバーと通信するために使用される非 SSL IP ポート番号。port_number

に、任意の有効なポート番号を使用します。有効なポート番号は、TCP/IP で許可されていて、現在、他のアプリケーションにより使用されていない任意の正数です。



例: port = 389

bind-dn = LDAP_dn

LDAP サーバーにバインドする (サインオンする) ときに使用される LDAP ユーザー識別名 (DN)。LDAP_dn の値は、-n server_name フラグおよびマシンのローカル・ホストで指定されているサーバー名に基づいて作成されます。

svrsslcfg ユーティリティーを、LDAP_dn の値を設定するために使用します。

このスタンザ・エントリーは、構成されたユーザー・レジストリーが LDAP である場合に必須です。

キー=値ペアをパフォーマンス・チューニングの目的で使用する方法については、IBM Tivoli Access Manager パフォーマンス・チューニング・ガイドを参照してください。


例: bind-dn = cn=ivacld/libra,cn=SecurityDaemons,secAuthority=Default

bind-pwd = LDAP_password


bind-dn = dn キー値ペアで識別される LDAP ユーザー識別名 (DN)のパスワード。LDAP_password の値は、-S password フラグを使用して指定されたパスワードに基づいて作成されます。

svrsslcfg ユーティリティーを使用して、LDAP_password の値を設定します。

このスタンザ・エントリーは、構成されたユーザー・レジストリーが LDAP である場合に必須です。



例: bind-pwd = zs77WVoLSZn1rKrL

cache-enabled = {yes|true|no|false}

類似の LDAP 照会のパフォーマンスを改善するために、LDAP クライアント・サイドのキャッシングを使用するかどうかの指示。


LDAP クライアント・サイドのキャッシングを使用可能にします。no|false

LDAP クライアント・サイドのキャッシングを使用不可にします。この値はデフォルト値です。yes|true 以外のすべては、ブランク値も含め、no|false として解釈されます。




例: cache-enabled = no

prefer-readwrite-server = {yes|true|no|false}


クライアントが、ドメインで構成される任意のレプリカ読み取り専用サーバーを照会する前に、読み取り/書き込み LDAP サーバーに問い合わせることができるかどうかの指示。

デフォルト値はさまざまです。たとえば、ivmgrd.conf のデフォルト値は yes、ivacld.conf のデフォルト値は no です。

有効値は次のとおりです。yes|true

クライアントが読み取り/書き込み LDAP サーバーに問い合わせることを使用可能にします。

no|falseクライアントを使用不可にします。yes|true 以外のすべては、ブランク値も含め、no|false として解釈されます。


デフォルト値は、サーバーに依存しています。

例: prefer-readwrite-server = no

ssl-enabled = {yes|true|no|false}

LDAP サーバーとの SSL 通信を使用可能にするかどうかの指示。各サーバーの値は、サーバーの構成方法に応じて異なります。


SSL 通信を使用可能化します。no|false

SSL 通信を使用不可にします。yes|true 以外のすべては、ブランク値も含め、自no|false として解釈され、SSL は自動的に構成されます。



例: ssl-enabled = yes

ssl-keyfile = ldap-ssl-key-filename

SSL 鍵ファイルの名前および場所。SSL 鍵ファイルを使用して、LDAP 通信に使用される証明書を処理します。ファイル・タイプは任意ですが、拡張子は通常、.kdb です。

このスタンザ・エントリーは、ssl-enabled = yes の場合にのみ必須です。



C:¥pd¥keytab¥ivmgrd.kdb


/opt/PolicyDirector/keytab/ivmgrd.kdb

UNIX の例: ssl-keyfile = /opt/PolicyDirector/keytab/ivmgrd.kdb

ssl-keyfile-dn = keyLabel


SSL 鍵ファイル内のクライアントの個人用証明書の鍵ラベル。この鍵ラベルは、LDAP サーバーに提出されるクライアント証明書を識別するために使用されます。

LDAP サーバーがクライアント認証を実行するように構成されている場合、このスタンザ・エントリーは必須です。


例: ssl-keyfile-dn = "PD_LDAP"

ssl-keyfile-pwd = ldap-ssl-keyfile-password

SSL 鍵ファイルにアクセスするためのパスワード。注: デフォルトの SSL 鍵ファイルに関連づけられているパスワードは、gsk4ikm です。



例: ssl-keyfile-pwd = mysslpwd

ssl-port = port_number

LDAP サーバーに接続するために使用される SSL IP ポート。 port_numberに、任意の有効なポート番号を使用します。有効なポート番号は、TCP/IP で許可されていて、現在ほかのアプリケーションにより使用されていない任意の正数です。



例: ssl-port = 636

max-search-size = [0|number_entries]

LDAP サーバーから戻すことのできる、エントリー数として指定される検索サイズの最大限度。各サーバーの値は、サーバーの構成方法に応じて異なります。

有効値は以下のとおりです。0 番号は無制限です。最大検索サイズに限界はありません。number_entries 整数で指定される、検索のエントリー最大数。この値は、

LDAP サーバー自体により制限されます。


デフォルト値はサーバーに依存しますが、構成されない場合はデフォルトの 2048

です。

例: max-search-size = 2048

LdapSSL = {yes|true|no|false}


LDAP サーバーとの SSL 通信を使用可能にするかどうかの指示。各サーバーの値は、サーバーの構成方法に応じて異なります。


SSL 通信を使用可能にします。no|false

SSL 通信を使用不可にします。yes|true 以外のすべては、ブランク値も含め、自no|false として解釈され、SSL は自動的に構成されます。



例: LdapSSL = yes

LdapSSLKeyFile = ldap-ssl-key-filename

SSL 鍵ファイルの名前および場所。SSL 鍵ファイルを使用して、LDAP 通信に使用される証明書を処理します。ファイル・タイプは任意ですが、拡張子は通常、.kdb です。

このスタンザ・エントリーは、LdapSSL = yes の場合にのみ必須です。

デフォルトの値はサーバーに依存しています。




/opt/PolicyDirector/keytab/ivmgrd.kdb

UNIX の例: LdapSSLKeyFile = /opt/PolicyDirector/keytab/ivmgrd.kdb

LdapSSLKeyFileDn = keyLabel

SSL 鍵ファイル内のクライアントの個人用証明書の鍵ラベル。この鍵ラベルは、LDAP サーバーに提出されるクライアント証明書を識別するために使用されます。このスタンザ・エントリーは、LDAP サーバーがクライアント認証を実行するように構成されている場合に使用されます。



例: LdapSSLKeyFileDn = "PD_LDAP".

LdapSSLKeyFilePwd = ldap-ssl-keyfile-password

SSL 鍵ファイルにアクセスするためのパスワード。注: デフォルトの SSL 鍵ファイルに関連づけられているパスワードは、gsk4ikm です。



例: LdapSSLKeyFilePwd = mysslpwd

GsoSuffix =


アクセス・マネージャー・ユーザーまたはグループ情報を保管するのに使用されるグローバル・サインオン (GSO) サフィックス。

auth-using-compare = {yes|true|no|false}

パスワードを検証し、ユーザーを認証するために、ldap_bind( ) 呼び出しではなく、ldap_compare( ) を使用するかどうかの選択。これを許可する LDAP サーバーの場合、比較操作はバインド操作よりも高速に実行される可能性があります。各サーバーの値は、サーバーの構成方法に応じて異なります。

このオプションは、これらの aznAPI 呼び出しにより使用されるメソッドを変更します。v azn_util_client_authenticate( )

v azn_util_password_authenticate( )


比較操作は、バインド操作に代わりに LDAP ユーザーを認証するために使用されます。

no|falseバインド操作は、比較操作の代わりに LDAP ユーザーを認証するために使用されます。yes|true 以外のすべては、ブランク値も含め、no|false として解釈されます。



デフォルト値: yes|true

例: auth-using-compare = true

timeout = {0|number_seconds}

LDAP サーバーがダウンしているとみなされるまで、認証または検索操作に許可されている時間 (秒)。指定される場合、スタンザ・エントリー authn-timeout =

または search-timeout = の値は、このスタンザ・エントリーの値を指定変更します。注: ldap.conf サーバー構成ファイルで、このスタンザ・エントリーを指定しないでください。

有効値は次のとおりです。0 タイムアウトなし。number_seconds

認証または検索に許可される、正の整数/自然数で示される指定された秒数。タイムアウト値に、範囲限界はありません。



例: timeout = 0

authn-timeout = {0|number_seconds}


LDAP サーバーがダウンしているとみなされるまで、認証操作に許可されている時間 (秒単位)。指定される場合、この値は、認証操作の timeout = の任意の値を指定変更します。注: このスタンザ・エントリーは、ldap.conf サーバー構成ファイルで指定しないでください。

有効値は以下のとおりです。0 タイムアウトは許可されません。number_seconds

認証に許可される、正の整数で指定される秒数。タイムアウト値に、範囲制限はありません。



例: authn-timeout = 0

search-timeout = {0|number_seconds}

LDAP サーバーがダウンしているとみなされるまで、検索操作に許可されている時間 (秒単位)。指定される場合、この値は、検索操作の timeout = の任意の値を指定変更します。注: このスタンザ・エントリーは、ldap.conf サーバー構成ファイルで指定しないでください。

有効値は以下のとおりです。0 タイムアウトは許可されません。number_seconds

検索操作に許可される、正の整数で指定される秒数。タイムアウト値に、範囲制限はありません。



例: search-timeout = 0

replica = ldap-server, port, type, pref


ドメイン内の LDAP ユーザー・レジストリー・レプリカの定義。以下を指定します。

v ldap_server はサーバーのネットワーク名です。

v port は、LDAP サーバーのポート番号です。有効なポート番号は、TCP/IP で許可されていて、現在ほかのアプリケーションにより使用されていない任意の正数です。

v type は、readonly か readwrite のいずれかです。

v preference は 1 ～ 10 の数です (10 が最高の優先度です)


デフォルト値では、レプリカは指定されていません。

指定された 1 つのレプリカおよびコメント化された 2 つのレプリカの例:

replica = freddy,390,readonly,1#replica = barney,391,readwrite,2#replica = benny,392,readwrite,3

default-policy-override-support = {yes|true|no|false}

ユーザー・レベルのポリシー・サポートが許可されるかどうかの指示。

有効値は次のとおりです。yes|true

ユーザー・ポリシー・サポートは使用不可になり、グローバル (デフォルト) ポリシーのみが検査されます。このオプションにより、ユーザー・ポリシーは、指定されている場合でも検査されません。

no|falseユーザー・ポリシーを使用可能にします。ユーザー・ポリシーは、アドミニストレーターにより指定される場合、グローバル・ポリシーを指定変更します。値が指定されない場合、default-policy-override-support

= no が値となります。




例: default-policy-override-support = yes

user-and-group-in-same-suffix = {yes|true|no|false}


ユーザーがメンバーであるグループが、ユーザー定義と同じ LDAP サフィックスで定義されるかどうかの指示。

ユーザーが認証された場合、ユーザーがメンバーであるグループを信任状を構築するために決定する必要があります。通常、すべての LDAP サフィックスで、ユーザーがメンバーであるグループが検索されます。


グループは、ユーザー定義と同じ LDAP サフィックスで定義されていると想定されています。そのサフィックスのみがグループ・メンバーシップのために検索されます。この動作は、グループ・メンバーシップに単一のサフィックスのみが検索されるため、グループ検索のパフォーマンスを改善します。このオプションは、グループ定義がユーザー定義と同じサフィックスに制限されている場合にのみ指定される必要があります。

no|falseグループは、任意の LDAP サフィックスで定義されます。値が指定されない場合、user-and-group-in-same-suffix = no がデフォルト値になります。




例: user-and-group-in-same-suffix = yes


[ldap-ext-cred-tags] スタンザこのスタンザを使用して、補足の LDAP ユーザー・データを信任状に挿入します。特定の LDAP データを信任状の拡張属性にマップする pd.conf 構成ファイルの[ldap-ext-cred-tags] スタンザにエントリーを作成できます。たとえば、いかなるアプリケーションでも独自の組み込み資格メカニズムを備えて、ユーザー定義の補足の LDAP 情報を、ユーザー信任状に拡張属性データとして挿入できます。

拡張属性を Tivoli Access Manager 信任状に追加するには、LDAP オブジェクト・クラス inetOrgPerson を使用します。このオブジェクト・クラスについて詳しい情報が必要な倍は、IBM Directory 資料を参照してください。

LDAP ユーザー・レジストリーの外部信任状タグを構成するためのスタンザ・エントリーは、以下の構成ファイルの [ldap-ext-cred-tags] スタンザにあります。


v 許可サーバー pdacld を使用し、LDAP がユーザー・レジストリーである場合は、pd.conf。

[ldap-ext-cred-tags] スタンザ

credential-field-name = ldap-inetOrgPerson-field

inetOrgPerson LDAP オブジェクト・クラス内の既存のフィールドから Tivoli

Access Manager 証明書に拡張属性を追加するメカニズム。


ldap-inetOrgPerson-field 値には、デフォルト値はありません。

例 :

credential-field-name = departmentNumbercredential-field-name = employeeNumber


[manager] スタンザマスター・サーバー設定を構成するためのスタンザ・エントリーは、以下の構成ファイルの [manager] スタンザにあります。


v 許可サーバー pdacld を使用する場合、pd.conf

[manager] スタンザ

master-host = server_hostname

Tivoli Access Manager サーバーのホスト名。

有効なホスト名の例:

v mycomputer.city.company.com

v mycomputer

このスタンザ・エントリーは、オプションまたは必須 ??? です。


例: master-host = libra

master-port = port_number

サーバーが要求を listen している TCP ポート。この値は、以下のユーティリティーのいずれかにより作成、設定されます。v pd.conf では、値は bassslcfg ユーティリティーを使用して設定されます。v それ以外のすべてでは、値は svrsslcfg ユーティリティーを使用して設定されます。

port_numberに、任意の有効なポート番号を使用します。有効なポート番号は、TCP/IP で許可されていて、現在ほかのアプリケーションにより使用されていない任意の正数です。デフォルトのポート番号の値を使用するか、または現在使用されていない 1000 以上のポート番号を使用することをお勧めします。

このスタンザ・エントリーは、オプションまたは必須 ??? です。


例: master-port = 7135


[pdrte] スタンザポリシー・サーバーでは、PDMgr パッケージがインストールされていると、システムがリブートするたびに、ポリシー・サーバーが自動的に始動します。許可サーバーでは、PDAcld パッケージがインストールされていると、システムがリブートするたびに、許可サーバーが・デーモンが自動的に始動します。

ユーザー・レジストリーを使用する場合にサーバー始動を自動化するためのスタンザ・エントリーは、次の構成ファイルの [pdrte] スタンザにあります。


許可サーバー、pdacld for Tivoli Access Manager を使用する場合、pd.conf 構成ファイルを持つ必要があります。

[pdrte] スタンザ

configured = {yes|no}

Tivoli Access Manager ランタイム・パッケージが構成されているかどうかの指示。

有効値は次のとおりです。yes ランタイム・パッケージは構成されています。no ランタイム・パッケージは構成されていません。


デフォルト値は生成されています。変更しないでください。

例: configured = no

user-reg-type = {ldap|domino|active_directory}

ユーザー・レジストリー・タイプ。

Windows 用の有効値:

ldap LDAP はユーザー・レジストリーとして構成されています。domino Lotus Domino がユーザー・レジストリーとして構成されてい

ます。active_directory

Microsoft Active Directory がユーザー・レジストリーとして構成されています。

UNIX 用の有効値は ldap です。



例: user-reg-type = ldap

user-reg-server = server_name


ユーザー・レジストリー・サーバー名。有効な server_name は、TCP/IP プロトコルにより許可されている、任意の大文字小文字の区別のない英数字の名前です。



例: user-reg-server = libra

user-reg-host = hostname

ユーザー・レジストリーのホスト名の例:

mycomputer.city.company.commycomputer

このスタンザ・エントリーは、必須です。


例: user-reg-host = libra

user-reg-hostport = port_number

ユーザー・レジストリー・サーバーと通信するために使用される非 SSL IP ポート番号。port_number は、任意の有効なポート番号、すなわち TCP/IP で許可されていて、現在ほかのアプリケーションにより使用されていない任意の正の整数です。



例: user-reg-hostport = 389

boot-start-ivmgrd = {yes|no}

システム・ブート時にポリシー・サーバー (pdmgrd) を始動するかどうかの指示。

有効値は次のとおりです。yes システム・ブート時に pdmgrd ポリシー・サーバーを始動し

ます。no システム・ブート時に pdmgrd ポリシー・サーバーを始動し

ません。

このスタンザ・エントリーは、UNIX システムでのみ必須です。


例: boot-start-ivmgrd = yes

boot-start-ivacld = {yes|no}


システム・ブート時に許可サーバー (pdacld) を始動するかどうかの指示。

有効値は次のとおりです。yes システム・ブート時に pdacld 許可サーバーを始動します。no システム・ブート時に pdacld 許可サーバーを始動しません。



例: boot-start-ivacld = yes


[ssl] スタンザ構成ファイルの [ssl] スタンザは、ポリシー・サーバーの SSL 構成の設定を定義します。

Tivoli Access Manager SSL 構成の設定をポリシー・サーバー用に構成するためのスタンザ・エントリーは、以下の構成ファイルの [ssl-info] スタンザにあります。




[ssl] スタンザ

ssl-cert-life = number_days

証明書の存続期間 (日数) の値。発行または更新される証明書は、すべてこの値を使用する必要があります。注: ポリシー・サーバー pdmgrd のみがこの値を使用します。

ivmgrd.conf の場合、number_days 値を設定するのに、mgrsslcfg ユーティリティーを使用します。ivmgrd.conf の場合、名前とパスは固定されています。このユーティリティーを使用して、この値を初期構成の後で変更してください。

number_days には、1 から 7300 の範囲内の正の整数を使用します。

値を増減するには、値を変更して pdmgrd サーバーを再始動します。新しい値が有効になるのは、その時点から発行または更新された証明書の場合に限られます。証明書と、その証明書の入った鍵リング・データベース・ファイルに対するパスワードの両方が期限切れになった場合は、最初にパスワードをリフレッシュする必要があります。



例: ssl-cert-life = 365

ssl-keyfile = ssl-key-path


SSL 鍵ファイルのローカル・システムのパスの場所とファイル名。鍵値ペアが構成ファイルに存在しない場合、アプリケーションは失敗します。ファイルの拡張子は任意ですが、通常は .kdb です。

以下のユーティリティーを使用して、このファイルは作成され、値が設定されます。v ivmgrd.conf は、mgrsslcfg により設定されます。ivmgrd.conf の場合、名前とパスは固定されています。

v pd.confは、bassslcfg により設定されます。pd.conf の場合、名前とパスは固定されています。

v その他すべては、svrsslcfg により設定されます。

このスタンザ・エントリーは、SSL が使用可能である場合に必須です。


opt/PolicyDirector/keytab/ivmgrd.kdb



UNIX の例: ssl-keyfile = opt/PolicyDirector/keytab/ivmgrd.kdb

ssl-keyfile-stash = ssl-stash-path

SSL パスワード stash ファイルのパスの場所とファイル名。ファイルの拡張子は任意ですが、通常は .sth です。

鍵ファイルの秘密鍵を保護するためにパスワードが使用されています。パスワードは、stash ファイルに暗号化されて保管される場合があります。ssl-keyfile-pwd と ssl-keyfile-stash の両方が指定される場合は、ssl-keyfile-pwd 値が使用されます。

以下のユーティリティーを使用して、このファイルは作成され、値が設定されます。

v ivmgrd.conf は、mgrsslcfg により設定されます。ivmgrd.conf の場合、名前とパスは固定されています。

v pd.confは、bassslcfg により設定されます。pd.conf の場合、名前とパスは固定されています。

v その他すべては、svrsslcfg により設定されます。パスは、svrsslcfg ユーティリティーの -d オプションにより定義されています。名前は、-n オプションにより、svrsslcfg ユーティリティーに定義されています。



opt/PolicyDirector/keytab/ivmgrd.sth


C:¥pd¥keytab¥ivmgrd.sth

Windows の例: ssl-keyfile-stash = C:\pd\keytab\ivmgrd.sth

ssl-keyfile-label = label


デフォルト以外を使用するための鍵のラベル。 label 値を囲む引用符は許可されていません。

ユーザー指定の名前に対するサポートはありません。以下のユーティリティーを使用して、このラベルは作成され、値が設定されます。v ivmgrd.conf は、mgrsslcfg により設定されます。v pd.conf では、このパラメーターは適用されません。v その他すべては、svrsslcfg により設定されます。


デフォルト値はありません。名前は、それを設定するユーティリティーにより異なります。

例: ssl-keyfile-label = PD Management Server

ssl-v3-timeout = number_seconds

クライアントとサーバー間の SSL v3 接続のセッション・タイムアウト (秒単位)。このタイムアウト値は、フル SSL ハンドシェークが Tivoli Access Manager

クライアントとサーバー間で完了する頻度を制御します。

number_seconds 値の有効範囲は 10 ～ 86400 秒で、86400 秒は 1 日に相当します。この範囲外の番号を指定した場合は、デフォルト番号が使用されます。

以下のユーティリティーを使用して、このタイムアウト値は作成され、値が設定されます。v ivmgrd.conf は、mgrsslcfg により設定されます。v pd.confは、bassslcfg により設定されます。pd.conf の場合、名前とパスは固定されています。

v その他すべては、svrsslcfg により設定されます。パスは、svrsslcfg ユーティリティーの -d オプションにより定義されます。名前は、svrsslcfg の -nオプションにより定義されます。

注: ネットワーク環境によっては、タイムアウト値が小さい場合、Tivoli Access

Manager コンポーネントが機能しないこともあります。



例: ssl-v3-timeout = 9800.

ssl-listening-port = {0|port_number}


着信要求について listen する場合の TCP ポート。

有効値は次のとおりです。0 listen を使用不可にします。この値は、構成時に svrsslcfg ユーティリ

ティーを使用して指定されます。port_number

指定されたポート番号で listen を使用可能にします。port_number の有効範囲は、TCP/IP で許可されていて、現在ほかのアプリケーションにより使用されていない任意の正数です。

各デーモンの構成プログラムが独自のデフォルト値を指定するため、デフォルト値はありません。たとえば、ポリシー・サーバーを構成する場合、ユーザーに、7135 をデフォルトとして、ポートに対するプロンプトが出されます。この値は、次に、mgrsslcfg ユーティリティーへの呼び出しで使用されます。同様に、許可サーバーの構成プログラムもデフォルト値 7137 を使用します。


デフォルト値は、構成時に指定されない場合は、0 です。その他の場合は、値はサーバーに依存しています。

例: ssl-listening-port = 7139

ssl-io-inactivity-timeout = {0|number_seconds}

SSL 接続がタイムアウトになるまでの応答の待機時間 (秒単位)。デフォルト値は各サーバーの構成プログラムにより設定されているため、デフォルト値はありません。

有効値は次のとおりです。0 タイムアウトなし。number_seconds

秒数で指定されるタイムアウト。タイムアウト値に、範囲制限はありません。

秒数の値は、以下のユーティリティーのうち、いずれかを使用して設定されます。v ivmgrd.conf は、mgrsslcfg により設定されます。v pd.conf は、bassslcfg により設定されます。v その他すべては、svrsslcfg により設定されます。



例: ssl-io-inactivity-timeout = 90

ssl-maximum-worker-threads = number_threads


着信要求を扱うためにサーバーが作成するスレッド数。

有効値は次のとおりです。number_threads

指定できるスレッド数。有効範囲は、1、または 1 以上である必要があります。最大数は、利用可能なシステム・リソースに依存しているため、さまざまです。



例: ssl-maximum-worker-threads = 80

ssl-pwd-life = number_days

日数で指定される、鍵データベース・ファイルのパスワード存続期間。自動パスワード更新の場合、パスワードの存続期間の値は、サーバーが開始されたときのnumber_days 値によって制御されます。number_days の有効値は、1 日から 7,299

日です。

パスワードの手動更新の場合、値は svrsslcfg —chgpwd コマンドに与えられた値によって決められます。この値は、該当する構成ファイルにも書き込まれます。注: 証明書と、その証明書の入った鍵リング・データベース・ファイルに対するパスワードの両方が期限切れになった場合は、最初にパスワードをリフレッシュする必要があります。

以下のユーティリティーを使用して、日数の値が作成され、値が設定されます。

v ivmgrd.conf は、mgrsslcfg により設定されます。

v pd.conf は、bassslcfg により設定されます。




例: ssl-pwd-life = 105

ssl-auto-refresh = {yes|no}


SSL 証明書および鍵データベース・ファイル・パスワードの自動リフレッシュが発生するかどうかの指示。

有効値は次のとおりです。yes 自動リフレッシュを使用可能にします。使用可能にされた場合、証明書

およびパスワードは、いずれかの有効期限が切れる危険がある (残された期間が半分以下になる) ときに再生成されます。

no 証明書およびパスワードの自動リフレッシュをオフにします。

この値は、以下のユーティリティーのいずれかを使用して作成され、設定されます。

v ivmgrd.conf は、mgrsslcfg により設定されます。

v pd.conf は、bassslcfg により設定されます。




例: ssl-auto-refresh = no

ssl-authn-type = certificate

認証のタイプ

この値は、以下のユーティリティーのいずれかを使用して作成され、設定されます。v ivmgrd.conf は、mgrsslcfg により設定されます。v pd.conf では、使用されません。v その他すべては、svrsslcfg により設定されます。


デフォルト値: certificate

例: ssl-authn-type = certificate

ssl-local-domain = {Default|domain_name}

ローカル・ドメインの名前。サーバーは、このドメイン上で稼動します。この値が構成ファイルにない場合、この存在に依存する操作は失敗します。domain_name 値は、大文字小文字の区別のない英数字ストリングです。

たとえば、このコマンド (pdadmin -a userID -p password) は、この値により指定されたドメインに対して稼動します。

ドメイン名の値は、以下のユーティリティーのいずれかを使用して作成され、設定されます。v ivmgrd.conf は、mgrsslcfg により設定されます。v pd.conf は、bassslcfg により設定されます。v その他すべては、svrsslcfg により設定されます。


デフォルト値: default

例: ssl-local-domain = mydomain1


[uraf-ad] スタンザUser Registry Adapter Framework (URAF) と呼ばれるユーザー・レジストリーのタイプを使用する場合、現行のサーバー構成ファイルの選択肢は以下のとおりです。v Microsoft Active Directory がユーザー・レジストリー・サーバーである場合は、

activedir.conf

v Lotus Domino がユーザー・レジストリー・サーバーである場合は、domino.conf

Active Directory スタンザ・エントリーの値を、以下の構成ファイルの [uraf-ad]

スタンザで設定できます。v 許可サーバー pdacld の ivacld.conf


v Microsoft Active Directory をユーザー・レジストリーとして構成する場合は、activedir.conf

[uraf-ad] スタンザ

ad-server-config = fully_qualified_path

Active Directory レジストリー activedir.conf 構成ファイルの場所とファイル名。この値は生成されますが、変更できます。

fully_qualified_path の値は、大文字小文字の区別のない英数字ストリングで表されます。Active Directory ユーザー・レジストリーのストリングの最大長は、英数字 256 文字です。

このスタンザ・エントリーは、ユーザー・レジストリーが Microsoft Active

Directory である場合に必須であり、activedir.conf 以外の構成ファイルでのみ必須です。


/opt/PolicyDirector/etc/activedir.conf


c:\Program files\tivoli\Policy Director\etc\activedir.conf

UNIX の例:

ad-server-config = /opt/PolicyDirector/etc/activedir.conf

enabled = {yes|no}

Active Directory がユーザー・レジストリーとして使用されているかどうかの指示。

有効値は次のとおりです。yes Active Directory がユーザー・レジストリーであることを示します。no Active Directory がユーザー・レジストリーではないことを示します。

yes 以外は、ブランクも含め、no として解釈されます。


Directory である場合に必須です。


例: enabled = yes

multi-domain = {true|false}


ドメインが単一ドメイン構成、もしくははマルチ・ドメイン構成であることの指示。値は、ランタイムが Tivoli Access Manager で構成されるときに選択します。値は、ランタイム構成時に提供される情報に基づいて自動的に入力されます。

有効値は次のとおりです。true 複数の Active Directory ドメイン用。false 単一の Active Directory ドメイン用。




例: multi-domain = true

hostname = hostname

Active Directory ドメイン名システム (DNS) ホスト名。値は、ランタイム構成時に提供される情報に基づいて自動的に入力されます。hostname は、大文字小文字の区別のない英数字ストリングです。ドット (.) は、ホスト名の最後の文字として使用できません。 Active Directory ユーザー・レジストリーのストリングの最大長は、英数字 256 文字です。




例: hostname = adserver.tivoli.com

domain = root_domain_name

Active Directory ルート (1 次) ドメイン。値は、ランタイム構成時に提供される情報に基づいて自動的に入力されます。root_domain_name は、大文字小文字の区別のない英数字ストリングです。ドメイン名の最大長は、ユーザー・レジストリーに依存しています。Active Directory の場合、最大長は英数字 256 文字です。

このスタンザ・エントリーは、multi-domain = true の場合に必須です。

デフォルトの動作はありません。

例: domain = dc=tivoli,dc=com

useEncryption = {true|false}

Active Directory への暗号化通信が使用されているかどうかの指示。この値は、ランタイム構成時に提供される情報に基づいて自動的に入力されます。

有効値は次のとおりです。true 暗号化通信を使用可能にします。false 暗号化通信を使用不可にします。



デフォルトの動作はありません。

例: useEncryption = false

bind-id = ad_id


レジストリー・サーバーにバインド (サインオン) するために使用される、Active

Directory アドミニストレーターまたはユーザー・ログイン ID。ID がアドミニストレーターではなくユーザーに属している場合、Active Directory ユーザーはユーザー・レジストリーのデータを更新および変更するために十分な特権を持つ必要があります。

ad_id の値は、大文字小文字の区別のない英数字ストリングです。ID の最小長および最大長は、制限がある場合、基本レジストリーにより設定されます。Active

Directory の場合、最大長は英数字 256 文字です。

この値は、サーバー構成時に提供される情報に基づいて自動的に入力されます。この値を構成が終了した後に変更する場合は常に、競合が発生します。




例: bind-id = adpdadmin

bind-pwd = admin_password

Active Directory レジストリー・サーバーにバインド (サインオン) するために使用される、エンコードされたアドミニストレーター・ログイン・パスワード。追加パスワード要件は、製品のインストール後に、Tivoli Access Manager に指定できます。ただし、初期パスワードが必ずしもこれらの要件に従うとは限りません。

admin_password の値は、サーバー構成時に提供される情報に基づいて自動的に入力されます。パスワードは、暗号化されたストリングです。




例: bind-pwd = MyADbindPwd

dnforpd = ad_dn

Active Directory が Tivoli Access Manager データを保管するために使用する識別名 (DN)。ad_id の値は、大文字小文字の区別のない英数字ストリングです。識別名 (DN) の最小長および最大長は、制限がある場合、基本レジストリーに課されます。Active Directory の場合、最大長は英数字 256 文字です。




例: dnforpd = dc=child2,dc=com


[uraf-domino] スタンザUser Registry Adapter Framework (URAF) レジストリーを使用する場合、現行の選択肢は以下のとおりです。　v Microsoft Active Directory がユーザー・レジストリー・サーバーである場合は、

activedir.conf

v Lotus Domino がユーザー・レジストリー・サーバーである場合は、domino.conf

IBM Lotus Domino サーバーをユーザー・レジストリーとして構成するためのスタンザ・エントリーを、以下の構成ファイルの [uraf-domino] スタンザで設定できます。v 許可サーバー pdacld の ivacld.conf


v IBM Lotus Domino がユーザー・レジストリー・サーバーである場合は、domino.conf

[uraf-domino] スタンザ

domino-server-config = fully_qualified_path

Active Directory registry activedir.conf 構成ファイルの場所とファイル名。

Lotus Domino レジストリーの domino.conf 構成ファイルの名前と場所。

fully_qualified_path は、大文字小文字の区別のない英数字ストリングで表されます。

このスタンザ・エントリーは、ユーザー・レジストリーが Lotus Domino である場合に必須であり、domino.conf 以外の構成ファイルでのみ必須です。


/opt/PolicyDirector/etc/domino.conf


c:¥Program files¥tivoli¥Policy Director¥etc¥domino.conf

Windows の例:

domino-server-config = c:\Program files\tivoli\Policy Director\etc\domino.conf

enabled = {yes|no}

Domino がユーザー・レジストリーとして使用されているかどうかの指示。

有効値は次のとおりです。yes Domino がユーザー・レジストリーであることを示します。no Domino がユーザー・レジストリーではないことを示します。

yes 以外は、ブランクも含め、no として解釈されます。

このスタンザ・エントリーは、ユーザー・レジストリーが Lotus Domino である場合に必須です。


例: enabled = yes

server = server_name


Lotus Domino™ サーバーの名前。server_name の値は、大文字小文字の区別のない英数字ストリングです。名前の最小長および最大長は、基本レジストリーにより設定されます。



例: server = grizzly/Austin/IBM

grizzly は Domino サーバー・マシンのホスト名で、残りは Domino ドメイン名です。

hostname = hostname

Lotus Domino サーバー TCP/IP ホスト名。 hostname の値は、構成時に手動で入力します。hostname の値は、大文字小文字の区別のない英数字ストリングである必要があります。フォーマットは、通常の TCP/IP ホスト名と同じです。



例: hostname = myhost.austin.ibm.com

LDAPPort = port_number

Lotus Domino サーバーの LDAP ポート番号。port_number の値は、構成時に手動で入力します。有効なポート番号は、TCP/IP で許可されていて、現在ほかのアプリケーションにより使用されていない任意の正数です。



例: LDAPPort = 389

UseSSL = {yes|no}

SSL の使用の有無の指示。

有効値は以下のとおりです。yes SSL の使用を指定します。no SSL の不使用を指定します。



例: UseSSL = no

keyfile = filename


SSL 鍵ファイルの名前および場所。SSL 鍵ファイルを、LDAP 通信に使用される証明書を扱うために使用します。filename は、基本 (Windows) ファイル・システムの命名規則に従う必要のある、大文字小文字の区別のない英数字ストリングです。ファイルは、クライアント・マシン上にある、既存のファイルである必要があります。ファイル・タイプは任意ですが、拡張子は通常 .kdb です。

このスタンザ・エントリーは、UseSSL = yes の場合に必須です。


Windows の例: keyfile = C:/pd/keytab/ivacld.kdb

KeyFile-PW = password

SSL 鍵ファイルのパスワード。



例: KeyFile-PW = mykeyfilepw

KeyFile-DN = cert_label

SSL 鍵ファイルの秘密鍵の識別名 (DN)。cert_label の値は、SSL 鍵ファイル内のクライアントの個人用証明書の証明書レベルを表す、英数字ストリングです。この鍵ラベルは、Domino サーバーに提出されるクライアント証明書を識別するために使用されます。



例: KeyFile-DN = "PD_LDAP"

password = password

Domino レジストリー・サーバーにバインド (サインオン) するために使用される、Domino サーバー・パスワード。パスワードは、暗号化されたストリングです。

このスタンザ・エントリーは、enabled = yes の場合に必須です。

デフォルト値は生成されます。変更しないでください。

例: password = myEncryptedSrvrPwd

NAB = names.nsf

Lotus Domino Name and Address Book (NAB) データベース。 names.nsf データベースは、構成時に設定され、変更できません。


デフォルト値: names.nsf

例: NAB = names.nsf

PDM = nsf_filename


Tivoli Access Manager メタデータ・データベース。 nsf_filename は、Domino データベース・ファイル名を表します。ファイル名は、Domino サーバーの基本オペレーティング・システムの命名規則に従います。推奨されるファイル拡張子は.nsf です。このファイルは、Domino サーバーで構成時に作成されます。


デフォルト値: PDMdata.nsf

例: PDM = PDMdata.nsf


付録 B. ユーザー・レジストリーの相違点

IBM Tivoli Access Manager (Tivoli Access Manager) のこのバージョンでは、以下のユーザー・レジストリーの相違点の存在が知られています。

1. LDAP または Microsoft Active Directory を Tivoli Access Manager セキュア・ドメインのユーザー・レジストリーとして使用する際、ユーザー名およびグループ名の先行ブランクおよび末尾ブランクは無視されます。しかし、Lotus

Domino サーバーをユーザー・レジストリーとして使用するときは、先行ブランクおよび末尾ブランクは有効です。使用するユーザー・レジストリーに関係なく、処理の一貫性を確保するには、名前に先行ブランクまたは末尾ブランクを付けずに、ユーザー・レジストリーでユーザーおよびグループを定義します。

2. 識別名ストリングを使用して定義したユーザーおよびグループ名では、スラッシュ文字 (/) は避けるべきです。スラッシュ文字は、異なるユーザー・レジストリーでは処理の方法が異なります。

Lotus Domino サーバーユーザーおよびグループは、スラッシュ文字を含む識別名ストリングを使用した名前で作成できます。この問題を避けるために、スラッシュを使用しないか、あるいは、次のように、識別名の指定を使用しないでユーザーしないか、識別名指定を使用せずにユーザーを定義してください。

pdadmin user create myuser username/locinfo test test testpwd

上記を使用せずに、次を使用してください。

pdadmin user create myuser cn=username/o=locinfo test test testpwd

Microsoft Active Directoryユーザーおよびグループは、スラッシュ文字を含む識別名ストリングを使用した名前を作成できます。ただし、その後にそのオブジェクトで操作したときに、Active Directory 機能によって、スラッシュ文字をオブジェクト名とホスト名間の分離文字として解釈する場合があるため、失敗することがあります。この問題を避けるには、スラッシュ文字をユーザーの定義に使用しないでください。

3. マルチ・ドメインの Microsoft Active Directory ユーザー・レジストリーを使用するときは、複数のユーザーおよびグループが異なるドメインに常駐する限り、それらを同じ長さの短縮名で定義できます。特定のユーザーまたはグループに関連する情報を照会する場合は、ドメインを含むユーザーまたはグループのフルネームを使用して、正しい情報を得られるようにしてください。ドメイン情報が削除されている場合は、想定されるユーザーまたはグループとは異なる、デフォルト・ドメインで定義されているユーザーまたはグループに関する情報が返されます。同じ理由で、ユーザーまたはグループを識別するための短縮名だけを使用することは避ける必要があります。

4. Microsoft Active Directory がユーザー・レジストリーとして使用されている場合、ピリオド文字 (.) を含むユーザーおよびグループの名前に注意する必要があります。Active Directory では、ピリオドで終わる名前を許可しません。(詳しくは、Microsoft Knowledge Base 第 316595 条を参照してください。) Tivoli

Access Manager に作成されたユーザーまたはグループの名前の最初の 20 文字


は、Active Directory の SAMAccountName にマップされています。もし 20 番目の文字がピリオド文字である場合は、Active Directory は、その名前を有効とはみなさず、エラーを生成します。これは、Tivoli Access Manager のサーバーがその名前のその場所にピリオドを使用している場合 (例:

centralpolicyserver.company.com) に起こります。

この問題を避けるために、Tivoli Access Manager 環境で名前の 20 番目にピリオド文字を使用しているサーバーの名前を変更します。交互に、Microsoft

Windows サーバーの DNS サフィックスにピリオドがある場合、プライマリーの DNS サフィックスを Network 設定から除去することにより、この問題を避けられます。

5. iPlanet バージョン 5.0 をユーザー・レジストリーとして使用すると、作成され、グループに追加された後ユーザー・レジストリーから削除されたユーザーは、そのグループ・メンバーシップを保持します。その後同じ名前のユーザーが作成された場合は、新規ユーザーが古いグループ・メンバーシップを自動的に継承して、不適切な許可を与えられる場合があります。ユーザーを削除する前に、そのユーザーをすべてのグループから除去することが、強く推奨されています。この問題は、ほかのサポート対象ユーザー・レジストリーを使用した場合は発生しません。

6. グループにユーザーを重複して追加しようとすると、使用するユーザー・レジストリーによって異なる結果となります。表 10 はその相違点の概要です。

表 10. グループにユーザーを重複して追加した場合のユーザー・レジストリーの相違点

操作 LDAP Lotus Dominoサーバー

Microsoft ActiveDirectory

ユーザーを 1 つ追加し、そのユーザーが重複

エラーエラーなしエラー

複数のユーザーを追加し、最初のユーザーが重複

すべてのユーザーでエラー

エラーなしすべてのユーザーでエラー

複数のユーザーを追加し、最初以外のユーザーが重複


エラーなし部分完了メッセージ

7. ユーザーをグループのメンバーではないグループから除去しようとすると、使用するユーザー・レジストリーによって異なる結果となります。表 11 はその相違点の概要です。

表 11. ユーザーをグループのメンバーではないグループから除去する際のユーザー・レジストリーの相違点



グループにない 1 ユーザーを除去

エラーエラーエラー

複数のユーザーを除去し、最初のユーザーがグループ内にない


エラーすべてのユーザーでエラー


表 11. ユーザーをグループのメンバーではないグループから除去する際のユーザー・レジストリーの相違点 (続き)



複数のユーザーを除去し、最初以外のユーザーがグループ内にない


部分完了メッセージ部分完了メッセージ

8. Tivoli Access Managerに関連するさまざまな名前の最大長は、使用するユーザー・レジストリーによって異なります。使用可能な最大長の比較と、Tivoli

Access Manager がサポートするすべてのユーザー・レジストリーとの互換性を確保するために使用する推奨最大長については、表 12 を参照してください。

表 12. ユーザー・レジストリーに基づく名前の最大長

最大長 LDAP MicrosoftActive

Directory

Lotus Dominoサーバー

推奨最大値

名 (LDAP CN) 256 64 960 64

名前 128 64 65535 64

ラスト・ネーム(姓)

128 64 960 64

レジストリーUID (LDAP DN)

1024 2048 255 この値は、ユーザー・レジストリーに固有で、ユーザー・レジストリーを変更するときは変更する必要があり

ます。

Tivoli Access

Manager ユーザー ID

256 2048 ～ 1 -

length_of_

domain_name

200 ～ 4 -

length_of_

domain_name

この値は、ユーザー・レジストリーに固有で、ユーザー・レジストリーを変更するときは変更する必要があり

ます。

ユーザー・パスワード

無制限 256 無制限 256

ユーザー詳細 1024 1024 1024 1024

グループ名 256 256

グループ詳細 1024 1024 1024 1024

シングル・サインオン・リソース名

240 256 256 240

付録 B. ユーザー・レジストリーの相違点 233

表 12. ユーザー・レジストリーに基づく名前の最大長 (続き)

最大長 LDAP MicrosoftActive

Directory

Lotus Dominoサーバー

推奨最大値

シングル・サインオン・リソース詳細

1024 1024 1024 1024

シングル・サインオン・ユーザー ID

240 256 256 240

シングル・サインオン・パスワード

無制限 256 無制限 256

シングル・サインオン・グループ名

240 256 256 240

シングル・サインオン・グループ詳細

1024 1024 1024 1024

アクション名 1 1 1 1

アクション詳細、アクション・タイプ

無制限無制限無制限

オブジェクト名、オブジェクト・スペース名、ACL 名、POP 名


オブジェクト詳細、オブジェクト・スペース詳細、ACL 詳細、POP 詳細


長さが無制限の名前もありますが、過剰な長さにより、ポリシーの状況の中では、管理が困難であるという結果をまねくことがあり、システム・パフォーマンスが低下するという結果になる可能性があります。お使いの環境で論理的な最大値を選択します。

9. Lotus Domino サーバーまたは Microsoft Active Directory ユーザー・レジストリーで作成されるユーザーには、シングル・サインオン信任状を所有する能力が自動的に与えられ、この能力は除去できません。 LDAP ユーザー・レジストリーを使用するときは、この能力を明示的にユーザーに認可する必要があり、後で除去できます。

10. Tivoli Access Manager ポリシー・サーバーが Microsoft Active Directory またはLotus Domino サーバーをそのユーザー・レジストリーとして使用していると、既存の Tivoli SecureWay Policy Director、バージョン 3.8 クライアントはその


ポリシー・サーバーに接続できません。別のユーザー・レジストリーを使用するか、クライアントを Tivoli Access Manager にアップグレードしてください。

付録 B. ユーザー・レジストリーの相違点 235

付録 C. 特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものであり、本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM

の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒106-0032

東京都港区六本木 3-2-31

IBM World Trade Asia Corporation

Licensing

以下の保証は、国または地域の法律に沿わない場合は、適用されません。IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム（本プログラムを含む）との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。


IBM Corporation

2Z4A/101

11400 Burnet Road

Austin, TX 78758

U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

著作権使用許諾:

本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。お客様は、IBM のアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。

それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生した創作物には、次のように、著作権表示を入れていただく必要があります。

© (お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。 © Copyright IBM Corp. _年を入れる_. All rights

reserved.


この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。

商標以下は、IBM Corporation の商標です。

AIX

DB2

IBM

IBM ロゴOS/390

SecureWay

Tivoli

Tivoli ロゴUniversal Database

WebSphere

zSeries

z/OS

Lotus および Domino は、IBM Corporation および Lotus Development Corporation

の商標です。

Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。

Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。

UNIX は、The Open Group がライセンスしている米国およびその他の国における登録商標です。

他の会社名、製品名またはサービス名などはそれぞれ各社の商標または登録商標です。

付録 C. 特記事項 239

用語集

［ア行］アクション (action). アクセス・コントロール・リスト (ACL) 許可属性。アクセス・コントロール・リスト(access control list) も参照。

アクセス許可 (access permission). オブジェクト全体に適用されるアクセス権。

アクセス・コントロール (access control). コンピューター・セキュリティーにおいて、許可ユーザーがコンピューター・システムのリソースに許可された方法でしかアクセスできないようにするプロセス。

アクセス・コントロール・リスト (ACL)(accesscontrol list(ACL)). コンピューター・セキュリティーにおいて、オブジェクトにアクセスできるすべての対象、およびそのアクセス権限を識別するオブジェクトに関連するリスト。たとえば、アクセス・コントロール・リストは、ファイルにアクセスできるユーザーを識別し、そのファイルへのユーザーのアクセス権限を識別するファイルに関連するリストである。

暗号 (cipher). 鍵を用いて平易なデータに変換しなければ読めない暗号化されたデータ。

暗号化 (encryption). コンピューター・セキュリティーにおいて、元データを入手できないようにしたり、あるいは暗号化解除プロセスを使用しなければ入手できないような方法で、データを理解できない形式に変換するプロセス。

インターネット・スイートのプロトコル (Internet suiteof protocols). インターネットで使用するために開発され、Internet Engineering Task Force (IETF) を介してRequests for Comments (RFC) として公開される一連のプロトコル。

インターネット・プロトコル (IP)(Internet protocol(IP)). インターネット・スイートのプロトコルにおいて、データをネットワークまたは相互接続ネットワークを介して経路指定し、高位プロトコル・レイヤーと物理ネットワーク間を中継する接続のないプロトコル。

応答ファイル (response file). プログラムからの質問に対する事前定義された一連の応答、およびそれらの値を一度に 1 つずつ入力する代わりに使用するファイル。

［カ行］外部許可サービス (external authorization service).Tivoli Access Manager 許可決定チェーンの一部としてアプリケーションまたは環境固有の許可決定を行う場合に使用できる、許可 API ランタイム・プラグイン。お客さまは、これらのサービスを許可 ADK を使用して開発できる。

鍵 (key). コンピューター・セキュリティーにおいて、データの暗号化または暗号化解除用の暗号アルゴリズムと一緒に使用する一連のシンボル。秘密鍵 (private key)

および公開鍵 (public key) を参照。

鍵データベース・ファイル (key database file). 鍵リング (key ring) を参照。

鍵ファイル (key file). 鍵リング (key ring) を参照。

鍵ペア (key pair). コンピューター・セキュリティーにおいて、公開鍵と秘密鍵。鍵ペアが暗号化に使用されると、送信側は公開鍵を使用してメッセージを暗号化し、受信側は秘密鍵を使用してメッセージを暗号化解除する。鍵ペアが署名に使用されると、署名者は公開鍵を使用してメッセージの表記を暗号化し、受信側は秘密鍵を使用してメッセージの表記を暗号化解除して、シグニチャーの検査を行う。

鍵リング (key ring). コンピューター・セキュリティーにおいて、公開鍵、秘密鍵、トラステッド・ルート、および証明書の入ったファイル。

仮想ホスト (virtual hosting). インターネットに対して複数のホストとして発生することができる Web サーバーの能力。

管理サーバー (management server). 廃止。ポリシー・サーバー (policy server) を参照。

管理サービス (administration service). Tivoli Access

Manager リソース・マネージャー・アプリケーションへの管理要求を実行する場合に使用できる、許可 API ランタイム・プラグイン。アドミニストレーション・サービスは、保護オブジェクト・ツリー内の特定ノード下のオブジェクトをリストするなどのタスクを実行する、pdadmin コマンドからのリモート要求に応答する。お客さまは、これらのサービスを許可 ADK を使用して開発できる。

管理ドメイン (management domain). Tivoli Access

Manager が認証、許可およびアクセス・コントロールに


ついて、セキュリティー・ポリシーを実行するデフォルトのドメイン。このドメインはポリシー・サーバーの構成時に作成される。ドメイン (domain) も参照。

基本認証 (basic authentication). ユーザーが有効なユーザー名とパスワードを入力しなければ、セキュア・オンライン・リソースへのアクセスが認可されない認証の方式。

許可 (authorization). (1) コンピューター・セキュリティーにおいて、コンピューター・システムと通信し、それを使用する、ユーザーに認可された権限。 (2) オブジェクト、リソース、または機能への完全アクセスか制限付きのアクセスのいずれかをユーザーに認可するプロセス。

許可 (permission). ファイルまたはディレクトリーなどの保護オブジェクトにアクセスする能力。オブジェクトの許可の数および意味は、アクセス・コントロール・リスト (ACL) によって定義される。アクセス・コントロール・リスト (access control list) も参照。

許可サービス・プラグイン (authorization serviceplug-in). 許可 API 内のサービス・インターフェースを拡張する操作を実行するために、Tivoli Access

Manager 許可 API ランタイム・クライアントが初期化時にロードできるダイナミック・ロード可能ライブラリー (DLL または共用ライブラリー)。現在使用可能なサービス・インターフェースには、管理、外部許可、信任状変更、資格および PAC 操作インターフェースがある。お客さまは、これらのサービスを許可 ADK を使用して開発できる。

許可ルール (authorization rule). ルール (rule) を参照。

グローバル・サインオン (GSO)(global signon(GSO)). ユーザーが、バックエンド Web アプリケーション・サーバーに代替ユーザー名およびパスワードを指定できるようにする、柔軟なシングル・サインオン・ソリューション。ユーザーは、グローバル・サインオンにより、単一のログインで、使用の許可を得ているコンピューター・リソースへのアクセスを認可される。異なる種類の分散コンピューティング環境内の複数のシステムおよびアプリケーションから構成される大企業向けに設計されていて、GSO を利用すれば、ユーザーは複数のユーザー名およびパスワードを管理する必要がない。シングル・サインオン (single signon) も参照。

クロスドメイン認証サービス (CDAS)(cross domainauthentication service (CDAS)). デフォルトのWebSEAL 認証メカニズムを、Tivoli Access Manager ID

を WebSEAL に戻すカスタム・プロセスに換えること

ができる、共用ライブラリー・メカニズムを備えたWebSEAL サービス。 WebSEAL も参照。

クロスドメイン・マッピング・フレームワーク(CDMF)(cross domain mapping framework(CDMF)). 開発者が、WebSEAL e-Community SSO 機能が使用された際に、ユーザー ID のマッピングやユーザー属性の処理をカスタマイズできる、プログラミング・インターフェース。

公開鍵 (public key). コンピューター・セキュリティーにおいて、だれでも使用できる鍵。秘密鍵（private

key) と対比。

構成 (configuration). (1) 情報処理システムのハードウェアおよびソフトウェアを編成し、相互接続する方法。 (2) システム、サブシステムまたはネットワークを構成するマシン、デバイスおよびプログラム。

コモン・ゲートウェイ・インターフェース(CGI)(common gateway interface (CGI)). HTTP を介して、Web サーバーからアプリケーション・プログラムへ (逆の場合もある) 情報をパスするスクリプトを定義するためのインターネット標準のインターフェース。CGI スクリプトは、PERL のようなスクリプト記述言語で書かれた CGI プログラム。

コンテナー・オブジェクト (container object). オブジェクト・スペースを、個別の機能領域内に編成する構造に関する指定。

［サ行］サービス (service). サーバーが行う作業。サービスは、データの送信または保管といった単純な要求 (ファイル・サーバー、HTTP サーバー、E メール・サーバーおよびフィンガー・サーバーによる要求のような) の場合もあれば、プリント・サーバーまたはプロセス・サーバーの作業のようなより複雑な作業の場合もある。

サイレント・インストール (silent installation). メッセージをコンソールに送信ぜずに、代わりに、メッセージおよびエラーをログ・ファイルに保管するインストール。また、サイレント・インストールはデータ入力の代わりに応答ファイルを使用できる。応答ファイル(response file) も参照。

サフィックス (suffix). ローカルに保持されたディレクトリー階層の上部エントリーを識別する、識別名。Lightweight Directory Access Protocol (LDAP) で使用される相対命名方式のために、このサフィックスは、そのディレクトリー階層内の他のすべてのエントリーに適用される。ディレクトリー・サーバーは、それぞれローカ


ルに保持されたディレクトリー階層を識別する複数のサフィックスを持つことができる。

資格 (entitlement). 外部化セキュリティー・ポリシー情報の入ったデータ構造。資格には、特定のアプリケーションに理解できる方法でフォーマットされたポリシー・データまたは能力が入っている。

資格サービス. プリンシパルの外部ソースまたは条件のセットから資格を戻す場合に使用できる、許可 API

ランタイム・プラグイン。資格は、通常はアプリケーション固有のデータであり、ある意味ではリソース・マネージャー・アプリケーションによって使い尽くされるか、あるいは将来許可プロセスで使用するためにプリンシパルの信任状に追加される。お客さまは、これらのサービスを許可 ADK を使用して開発できる。

識別名 (DN)(distinguished name (DN)). ディレクトリー内のエントリーを一意的に識別する名前。識別名は、コンマで分離した、attribute:value のペアから構成される。

自己登録 (self-registration). ユーザーが、アドミニストレーターの関与なしに、必要なデータを入力して、登録 Tivoli Access Manager ユーザーになれるプロセス。

証明書 (certificate). コンピューター・セキュリティーにおいて、公開鍵を証明書所有者の ID とバインドし、それによって証明書所有者の認証を可能にするディジタル文書。証明書は認証局が発行する。

シングル・サインオン (SSO)(single signon (SSO)).一度ログオンしたら、アプリケーションごとに別々にログオンせずに、複数のアプリケーションにアクセスするユーザーの能力。グローバル・サインオン (global

signon) も参照。

信任状. 認証の際に獲得され、ユーザー、すべてのグループ関連、およびその他のセキュリティー関連の識別属性を記述する詳細情報。信任状は、許可、監査、および代行などの多数のサービスを行う際に使用できる。

信任状変更サービス (credentials modificationservice). Tivoli Access Manager 信任状を変更する場合に使用できる、許可 API ランタイム・プラグイン。お客さまによって外部で開発された信任状変更サービスは、信任状属性リストでの追加および除去操作の実行、ならびに変更可能と考えられる属性のみに限定されます。

スキーマ (schema). データベースの構造を完全に記述する、データ定義言語で表されたステートメントの集合。リレーショナル・データベースでは、スキーマは、テーブル、テーブル内のフィールドおよびフィールドとテーブル間の関係を定義する。

スケーラビリティー (scalability). ネットワーク・システムの、リソースにアクセスするユーザー数の増加に対応する能力。

ステップアップ認証 (step-up authentication). 認証レベルの事前構成階層に依存し、リソースに設定されたポリシーに従って特定レベルの認証を実施する、保護オブジェクト・ポリシー (POP)。ステップアップ認証 POP

は、一定のリソースへのアクセスの場合に、複数レベルの認証を使用した認証をユーザーに強制することはないが、少なくともリソースを保護するポリシーが必要とする高さのレベルで認証することをユーザーに求める。

セキュリティー管理 (security management). アプリケーションや、組織の成功にとって重要なデータへのアクセスを制御する、組織の能力について述べた管理規律。

接続 (connection). (1) データ通信において、情報を運ぶ機能単位間ので確立される関連。 (2) TCP/IP において、確実なデータ・ストリーム送達サービスを提供する、2 つのプロトコル・アプリケーション間のパス。インターネットにおいては、接続は、あるシステムのTCP アプリケーションから別のシステムの TCP アプリケーションへ拡張する。 (3) システム通信において、2

つのシステムの間、またはステムとデバイス間でデータの受け渡しを行える回線。

属性リスト (attribute list). 許可決定を下すときに使用する拡張情報の入ったリンク・リスト。属性リストは、一連の name = value のペアから構成される。

［タ行］多重化プロキシー・エージェント (MPA)(multiplexingproxy agent (MPA)). 複数のクライアント・アクセスを収容するゲートウェイ。これらのゲートウェイは、クライアントが WAP を使用してセキュア・ドメインにアクセスするときは、Wireless Access Protocol (WAP) ゲートウェイとして知られている場合もある。ゲートウェイは起点サーバーに対しただ一つの認証済みチャネルを確立し、このチャネルを通じてすべてのクライアント要求と応答を「トンネル」する。

多元子の認証 (multi-factor authentication). ユーザーに複数レベルの認証を使用した認証を強制する、保護オブジェクト・ポリシー (POP)。たとえば、保護リソースへのアクセス・コントロールでは、ユーザー名/パスワードとユーザー名/トークン・パスコードの両方によるユーザー認証を求められることがある。保護オブジェクト・ポリシー (protected object policy) も参照。

用語集 243

デーモン (daemon). ネットワーク制御のような、システム全体に関係する機能を、継続的または定期的に、不在モードで実行するプログラム。デーモンには、自動的に起動してそのタスクを実行するものもあれば、定期的に動作するものもある。

ディジタル署名 (digital signature). e-commerce において、データ単位に付加されるか、あるいはその暗号変形であり、しかもデータ単位の受信側がその単位のソースおよび保全性を検査できて、偽造の可能性を認識できるデータ。

ディレクトリー・スキーマ (directory schema). ディレクトリー内に表示できる有効な属性タイプおよびオブジェクト・クラス。属性タイプおよびオブジェクト・クラスは属性値の構文、ディレクトリーについてどの属性が存在しなければならないか、どの属性が存在してもよいかを定義する。

トークン (token). (1) ローカル・エリア・ネットワークにおいて、データ装置が一時的に伝送メディアの制御下にあることを示すために、データ装置間で連続して渡される権限のシンボル。各データ装置には、トークンを獲得し、使用して、メディアを制御する機会が与えられる。トークンは、伝送の許可を意味する特定のメッセージまたはビット・パターンである。 (2) ローカル・エリア・ネットワーク (LAN) において、伝送メディアとともにデバイスからデバイスに渡される一連のビット。トークンにデータが付加されると、フレームになる。

特権属性証明書 (privilege attribute certificate). プリンシパルの認証と許可属性およびプリンシパルの能力を記載したディジタル文書。

特権属性証明書サービス (privilege attributecertificate service). 所定のフォーマットの PAC からTivoli Access Manager 信任状、およびその反対の変換を行う、許可 API ランタイム・クライアント・プラグイン。これらのサービスは、セキュア・ドメインの他のメンバーへの伝送で、Tivoli Access Manager 信任状を圧縮または整理する際に使用することもできる。お客さまは、これらのサービスを許可 ADK を使用して開発できる。特権属性証明書 (privilege attribute certificate) も参照。

ドメイン (domain). (1) 共通の目的で共通のサービスを共用し、通常は共通の機能も共用する、ユーザー、システム、およびリソースの論理的なグループ。 (2) データ処理リソースが共通のコントロール下にあるコンピューター・ネットワークのその部分。ドメイン名 (domain

name) も参照。

ドメイン名 (domain name). インターネット・スイートのプロトコルにおいて、ホスト・システムの名前。ド

メイン名は、区切り文字で分離された一連のサブネームから構成される。たとえば、ホスト・システムの完全修飾ドメイン名 (FQDN) が、as400.rchland.vnet.ibm.com であれば、as400.rchland.vnet.ibm.com、vnet.ibm.com、ibm.com. はそれぞれドメイン名である。

トラステッド・ルート (trusted root). Secure Socket

Layer (SSL) において、認証局 (CA) の公開鍵および関連識別名。

［ナ行］認証 (authentication). (1) コンピューター・セキュリティーにおいて、ユーザー ID またはユーザーのオブジェクトにアクセスする資格の検査。 (2) コンピューター・セキュリティーにおいて、メッセージの変更または破壊の有無を検査。 (3) コンピューター・セキュリティーにおいて、情報システムまたは保護リソースのユーザーを検査する際に使用するプロセス。多元的認証(multi-factor authentication)、ネットワーク・ベースの認証 (network-based authentication)、およびステップアップ認証 (step-up authentication) も参照。

認証局 (CA)(certificate authority (CA)). 証明書を発行する組織。認証局は、証明書所有者の ID および所有者が使用を許可されたサービスの認証、新しい証明書の発行、既存の証明書の更新、ならびに使用の許可がなくなったユーザーに属する証明書の取り消しを行う。

ネットワーク・ベースの認証 (network-basedauthentication). ユーザーのインターネット・プロトコル (IP) アドレスに基づいてオブジェクトへのアクセスを制御する、保護オブジェクト・ポリシー (POP)。保護オブジェクト・ポリシー (protected object policy) も参照。

［ハ行］バインド (bind). ID をプログラム内の別のオブジェクトに関連付けること。たとえば、ID を値、アドレスまたは別の ID に関連付けるか、仮パラメーターと実パラメーターを関連付けること。

ビジネス資格 (business entitlement). リソースに対する許可要求で使用できるきめ細かな条件を記述する、ユーザー信任状の補足属性。

秘密鍵 (private key). コンピューター・セキュリティーにおいて、その所有者のみが知る鍵。公開鍵 (public

key) と対比。


ファイル転送プロトコル (FTP)(file transfer protocol(FTP)). インターネット・スイートのプロトコルにおいて、伝送制御プロトコル (TCP) および Telnet サービスを使用してマシンまたはホスト間で大量データのファイルを伝送する、アプリケーション・レイヤー・プロトコル。

ブレード (blade). アプリケーション固有のサービスおよびコンポーネントを提供するコンポーネント。

プロセス間通信 (IPC)(interprocess communication(IPC)). (1) プログラム間で相互にデータを通信し、アクティビティーを同期化するプロセス。セマフォー、シグナル、および内部メッセージ・キューはプロセス間通信のコモン・メソッド。 (2) 同一コンピューター内、またはネットワークを越えて、プロセス間の通信を許可するオペレーティング・システムの仕組み。

ポータル (portal). 特定ユーザーのアクセス許可に基づいて特定のユーザーに使用できる、リンク、コンテンツ、またはサービスなど、カスタマイズされた Web リソースのリストを動的に作成する統合 Web サイト。

ポーリング (polling). データ送信の必要性を判断するために、一定の間隔でデータベースに問い合わせを行うプロセス。

保護オブジェクト (protected object). ACL (アクセス・コントロール・リスト) および POP (保護オブジェクト・ポリシー) の適用、およびユーザー・アクセス許可に使用する、実際のシステム・リソースの論理上のオブジェクト表示。保護オブジェクト・ポリシー(protected object policy) および保護オブジェクト・スペース (protected object space) も参照。

保護オブジェクト・スペース (protected objectspace). ACL (アクセス・コントロール・リスト) および POP (保護オブジェクト・ポリシー) の適用、およびユーザー・アクセス許可に使用する、実際のシステム・リソースの仮想オブジェクト表示。保護オブジェクト(protected object) および保護オブジェクト・ポリシー(protected object policy) も参照。

保護オブジェクト・ポリシー (POP)(protected objectpolicy (POP)). 保護オブジェクトにアクセスするために、ACL ポリシーで許可されたオペレーションに条件を追加するセキュリティー・ポリシーのタイプ。 POP

条件を適用するのはリソース・マネージャーの役割です。アクセス・コントロール・リスト、保護オブジェクト、および保護オブジェクト・スペースも参照。

保護品質 (quality of protection). 認証、保全性、およびプライバシー条件を組み合わせて決定されるデータ・セキュリティーのレベル。

ホスト (host). ネットワーク (インターネットまたはSNA ネットワーク) に接続し、そのネットワークにアクセス・ポイントを提供するコンピューター。また、環境によっては、ホストがネットワークの中央制御を行う場合もある。ホストは、クライアントでもサーバーでもよく、あるいは同時にその両方の場合もある。

ポリシー (policy). 管理対象リソースに適用される一連のルール。

ポリシー・サーバー (policy server). セキュア・ドメイン内のほかのサーバーに関するロケーション情報を保持している Tivoli Access Manager サーバー。

［マ行］マイグレーション (migration). プログラムの旧バージョンまたはリリースに換わる、新規バージョンまたはリリースのインストール。

メタデータ (metadata). 保管データの特性を記述するデータ。

［ヤ行］役割の活動化 (role activation). 役割にアクセス許可を適用するプロセス。

役割の割り当て (role assignment). ユーザーが、その役割に定義されたオブジェクトへの適切なアクセス許可を持つなどの、ユーザーに役割を割り当てるプロセス。

ユーザー (user). 他から提供されたサービスを使用する人、組織、プロセス、デバイス、プログラム、プロトコル、またはシステム。

ユーザー・レジストリー (user registry). レジストリー (registry) を参照。

［ラ行］ランタイム (run time). コンピューター・プログラムが実行する間の時間。ランタイム環境は、実行環境のこと。

リソース・オブジェクト (resource object). サービス、ファイル、およびプログラムなどの実際のネットワーク・リソースの表現。

ルーティング・ファイル (routing file). メッセージの構成を制御するコマンドを収めた ASCII ファイル。

用語集 245

ルール (rule). イベント・サーバーが、イベント間の関連 (イベント相関) を認識することにより、自動応答の実行が可能となるような 1 つ以上の論理ステートメント。

レジストリー (registry). ユーザー、システムおよびソフトウェアのアクセス情報および構成情報が含まれているデータ・ストア。

レプリカ (replica). 他のサーバーのディレクトリーのコピーが入ったサーバー。レプリカは、パフォーマンスまたは応答時間を強化し、データ保全性を確保するために、サーバーをバックアップする。

A

ACL. アクセス・コントロール・リスト (access control

list) を参照。

B

BA. 基本認証 (basic authentication) を参照。

C

CA. 認証局 (certificate authority) を参照。

CDAS. クロスドメイン認証サービス (Cross Domain

Authentication Service) を参照。

CDMF. クロスドメイン・マッピング・フレームワーク(Cross Domain Mapping Framework) を参照。

CGI. コモン・ゲートウェイ・インターフェース(common gateway interface) を参照。

Cookie. サーバーがクライアント・マシン上に保管し、次のセッションの際にアクセスする情報。サーバーは、Cookies を使用して、クライアントに関する特定情報を記憶できる。

D

DN. 識別名 (distinguished name) を参照。

E

EAS. 外部許可サービス (External Authorization

Service) を参照。

G

GSO. グローバル・サインオン (global signon) を参照。

H

HTTP. Hypertext Transfer Protocol を参照。

hypertext transfer protocol (HTTP). インターネット・スイートのプロトコルにおいて、ハイパーテキスト文書の転送および表示に使用するプロトコル。

I

IP. インターネット・プロトコル (Internet Protocol) を参照。

IPC. プロセス間通信 (Interprocess Communication) を参照。

J

junction. フロントエンド WebSEAL サーバーとバックエンド Web アプリケーション・サーバー間の HTTP

または HTTPS 接続。 WebSEAL はジャンクションを使用して、バックエンド・サーバーの代わりに保護サービスを提供することができる。

L

LDAP. Lightweight Directory Access Protocol を参照。

Lightweight Directory Access Protocol (LDAP).(a) TCP/IP を使用して X.500 モデルをサポートするディレクトリーへのアクセスを行い (b) さらに複雑なX.500 Directory Access Protocol (DAP) のリソース要件を発生させない、オープン・プロトコル。 LDAP を使用するアプリケーション (ディレクトリー対応アプリケーションとして知られる) は、このディレクトリーを共通のデータストアとして使用し、かつ E メール・アドレス、公開鍵、またはサービス固有の構成パラメーターなどの人またはサービスに関する情報の検索に使用できる。 LDAP は、最初 RFC 1777 で指定された。 RFC

2251 では LDAP バージョン 3 が指定され、IETF は引き続き追加の標準機能として作動する。 LDAP 用のIETF 定義標準スキーマには、RFC 2256 にあるものもある。


Lightweight Third Party Authentication (LTPA). 単一のサインオンが、インターネット・ドメイン内に入る一連の Web サーバーを全探索できるようになる、認証フレームワーク。

LTPA. Lightweight Third Party Authentication を参照。

P

PAC. 特権属性証明書 (privilege attribute certificate) を参照。

POP. 保護オブジェクト・ポリシー (protected object

policy) を参照。

R

RSA の暗号化 (RSA encryption). 暗号化と認証に使用される公開鍵暗号方式のシステム。 1977 年に Ron

Rivest、Adi Shamir、および Leonard Adleman によって発明された。システムのセキュリティーは、2 つの大きな素数の積を因数処理する難易度によって変わる。

S

Secure Socket Layer (SSL). 通信のプライバシーを提供する、セキュリティー・プロトコル。 SSL により、クライアント/サーバー・アプリケーションは、盗聴、改ざん、およびメッセージの偽造を予防するように設計された方法で、通信することができる。 SSL は、Netscape Communications Corp. と RSA Data Security,

Inc. の開発による。

SSL. Secure Sockets Layer を参照。

SSO. シングル・サインオン (Single Signon) を参照。

U

uniform resource identifier (URI). インターネットで、コンテンツを識別するために使用される文字列。リソースの名前 (ディレクトリーおよびファイル名)、リソースのロケーション (ディレクトリーおよびファイル名が存在するコンピューター)、およびリソースのアクセス方法 (HTTP 等のプロトコル) を含む。ユニフォーム・リソース・ロケーター (URL) は URI の 1 例。

uniform resource locator (URL). コンピューター、またはインターネットなどのネットワークの情報リソースを表す一連の文字。この文字のシーケンスには、(a)

情報リソースへのアクセスに使用するプロトコルの省略名および (b) プロトコルが情報リソースを探すときに使用する情報が組み込まれている。たとえば、インターネ

ットのコンテキストにおいて、これらは、各種情報リソースへのアクセスに使用するある種のプロトコルの省略名 (http、ftp、gopher、telnet、および news) であり、http://www.ibm.com は IBM ホーム・ページの URL である。

URI. uniform resource identifier を参照。

URL. uniform resource locator を参照。

W

Web Portal Manager (WPM). セキュア・ドメイン内の Tivoli Access Manager Base および WebSEAL セキュリティー・ポリシーの管理に使用する、Web ベースのグラフィカル・アプリケーション。 pdadmin コマンド行インターフェースの代わりである、この GUI を使用すると、リモート・アドミニストレーターのアクセスを可能にし、アドミニストレーターは代行ユーザー・ドメインを作成し、代行アドミニストレーターをそのドメインに割り当てることができる。

WebSEAL. Tivoli Access Manager ブレード。WebSEAL は、セキュリティー・ポリシーを保護オブジェクト・スペースに適用する、ハイパフォーマンスで、マルチスレッドの Web サーバーである。 WebSEAL

は、単一のサインオン・ソリューションを提供し、バックエンド Web アプリケーション・サーバー・リソースをそのセキュリティー・ポリシーに取り込む。

WPM. Web Portal Manager を参照。

用語集 247

索引日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］アクション 76

カスタム 86

カスタムの例 88

ACL エントリーへの入力 87

Action 許可の管理 37

アクション・グループアクション・グループでの新しいアクションの作成

86

ガイドライン 83

削除 85

作成 84

リスト 85

アクション・コード管理コマンド 146

認証イベント 145

アクション・コマンドcreate コマンド 87

アクセス・コントロール・リスト参照： ACL

アクセス・コントロール・リスト (ACL)

オブジェクトからの切り離し 80

検索 80

アドミニストレーターアドミニストレーター 54

エンタープライズ・ドメイン 53

サポート 54

事前定義 54

シニア 54

上位ドメイン 53

タイプ 54

タスク 55

ドメイン 54

複数ドメイン 53

sec_master 52

Tivoli Access Manager 54

アプリケーション・アクション実行 (x) 77

ディレクトリーのリスト (l) 76

読み取り (r) 76

アルゴリズム、ネットワーク・ベースの認証 103

依存関係サーバー 112

イベント・カテゴリー 162

イベント・キュー・プロファイル 159

イベント・ロギング概要 150

構成 151

インストールTivoli Access Manager 112

Tivoli Access Manager Runtime 112

エラー再試行タイムアウト 161

エンタープライズ・ドメイン 53

オブジェクト削除 71

作成 69

タイプ 70

タスクの管理 69

リスト 70

オブジェクト許可 82

オブジェクト・コマンド削除 71

作成 69, 124

リスト 70

オブジェクト・スペース削除 63

作成 62

代行管理 121

タイプ 62

タスクの管理 61

定義 23

リスト 63

オブジェクト・スペース許可 82

オブジェクト・タイプ 125

［カ行］外部許可サービスインプリメント 21

概要 18

デプロイメント 21

解決、ACL 要求の 45

ガイドライン鍵リングおよび stash ファイルの更新 108

セキュア・オブジェクト・スペース 29

鍵リング・ファイル定義 105

aznAPI.kdb 107

ivacld.kdb 107

ivmgrd.kdb 106

pd.kdb 106

カスタム・アクション 87


活動化役割 56

監査概要 133

使用可能化と使用不能可 137

監査イベント、定義 137

監査イベントの取り込み 139

監査証跡、定義 137

監査証跡ファイル 134, 137, 138

内容 141

バッファーのフラッシュ 138

フォーマット 139

監査タグ 139

監査ファイル・バッファー 138

監査レコード管理 145

許可 141

認証 143

管理エンタープライズ・ドメイン 53

オブジェクト 69

オブジェクト・スペース 61

監査レコード 145

サーバー 111

サーバー許可 38


証明書 105

代行管理ポリシー 129

パスワード 105


役割 55

役割の代行 55

ユーザーとグループ 65

ACL 許可 36

Action 許可 37

Config 許可 39

groups 許可 41

GSO 許可 42

policy 許可 39

POP 許可 38

Replica 許可 39

Users 許可 40

管理 ACL (デフォルト) 34

管理 API

Tivoli Access Manager コンポーネント 5

管理インターフェース 10

管理グループ 122

管理権限取得 33

管理ドメイン 23

管理の代行 121, 123

管理ユーザー作成 32

管理ユーザーおよびグループデフォルト 31

管理領域許可 35

関連資料 xiii

基準点、イベント・キュー 154, 158

規則 135

基本アクションコントロール (c) 76

作成 (N) 76

全探索 (T) 77

代行 (g) 76

追加 (A) 76

トレース (t) 76

バイパス POP (B) 76

パスワード (W) 77

ブラウズ (b) 76

キャッシュ・ファイルの場所 161

キュー上限基準点 154, 158

キューに入れられるイベントの最大数 157

許可 76



カスタム 86

監査レコード 141

管理ユーザー 32

コントロール (c) 37

全探索 (T) 43, 82

段階的プロセス 13

評価プロセス 19

役割 55

iv-admin グループ 31

sec_master 31


/Management/ACL 許可 36

/management/Action 許可 37

/Management/Config 許可 39

/Management/Groups 許可 41

/Management/GSO 許可 42

/Management/Policy 許可 39

/Management/POP 許可 38

/Management/Replica 許可 39

/Management/Server 許可 38

/Management/Users 許可 40

許可 API

概要 14

標準 6

リモート・キャッシュ・モード 16

ローカル・キャッシュ・モード 17

許可アクション 32


許可サーバー始動の自動化の防止 115

pdacld デーモン 111

許可サービス 7

インターフェース 10

概要 9

拡張 18

許可 API 10

利点 7

Tivoli Access Manager 8

許可サービスの利点 7

許可データベース複製 116

許可評価機能概要 10

許可ポリシー・データベース 9

許可モデル 6

概念モデル 6

グループ管理の代行 123

作成 125

タイプ属性 75

定義 73

groups 許可の管理 41

ivmgrd-servers 32

iv-admin 25

iv-admin グループ 31

グループ管理 127

グループ・コマンドコマンドのインポート 67

コマンドの作成 67

作成 125, 126

グループ・コンテナー・オブジェクト作成 124

グローバル・サインオン参照： GSO

継承された ACL 42, 46

継承されたポリシー 12

結果の値状況属性 141

コア・テクノロジー 2

更新、鍵リングおよび stash ファイル 106

更新通知スレッド 117

構成イベント・キュー上限基準点 154, 158

イベント・キュー・プロファイル 159

イベント・ロギング 151

監査タグ・イベント 139

監査ファイル・バッファーをフラッシュする頻度138

基本 SSL 112

キューに入れられるイベントの最大数 153

構成 (続き)

サーバー・ファイル 112

証明書 106

ステップアップ認証のレベル 99

中央イベント伝播キュー 153

統合バッファーをフラッシュする頻度 161

標準出力へのパイプ 159

ファイルのロギング 155

ファイル・モード 158

リソース・マネージャー 113

ログ出力を受け取るプログラムの場所 159

ログ・ファイル・バッファーをフラッシュする頻度154, 158

bassslcfg -config コマンド 109

Config 許可の管理 39

SSL 112

Tivoli Access Manager Java ランタイム環境(JRE) 113


構成 ACL (デフォルト) 35

構成ファイルデフォルトの場所 165

ldap.conf 203

コマンドbassslcfg -config 109

group list 129

group list-dn 129

pdadmin acl attach 80

pdadmin acl create 78

pdadmin acl delete 78

pdadmin acl detach 81

pdadmin acl find 80

pdadmin acl list 78

pdadmin acl modify 79

pdadmin acl show 79

pdadmin action create 87

pdadmin action group create 84

pdadmin action group delete 85

pdadmin action group list 85

pdadmin errtext 141

pdadmin group create 67

pdadmin group create コマンド 125, 126

pdadmin group import 67

pdadmin object create 69

pdadmin object create コマンド 124

pdadmin object delete 71

pdadmin object list 70

pdadmin objectspace create 62

pdadmin objectspace delete 63

pdadmin objectspace list 63

pdadmin pop attach 96

pdadmin pop create 93

索引 251

コマンド (続き)

pdadmin pop delete 94

pdadmin pop detach 97

pdadmin pop find 96

pdadmin pop list 94

pdadmin pop modify 95

pdadmin pop show 95

pdadmin server replicate 117

pdadmin server task 162

pdadmin user create 66

pdadmin user import 66

stats get 163

stats list 162

svrsslcfg -chgcert 108

svrsslcfg -chgpwd 108

svrsslcfg -unconfig 108

user list 129

user list-dn 129

user show groups 129

コンソールのロギング 154

コンテナー・オブジェクト 24, 124

コントロール許可 37

コントロール・アクション 76

コンポーネントTivoli Access Manager インストール済みバージョン

113

Tivoli Access Manager、構成 113

［サ行］サーバー依存関係 112

監査イベントの取り込み 139

許可サーバー 114, 119

構成ファイル 112

サーバー許可の管理 38

始動 113

始動の自動化 115

順番に手動で始動 114

の管理 111

の状況表示 113

ポリシー・サーバー 114

リモートの識別名 162

リモートのポート 162

pd_start ユーティリティーを使用した再始動 114

pd_start ユーティリティーを使用した始動 113

pd_start ユーティリティーを使用した停止 114

UNIX での始動および停止 113

Windows Services Control Panel を使用した始動 115

Windows での始動および停止 114

サーバー管理 32

サーバー管理アクション 76

サーバーの再始動 114

サーバーの始動手動で順番に 114

pd_start ユーティリティーの使用 113

UNIX 113

Windows 114

Windows Services Control Panel の使用 115

サーバーの停止pd_start ユーティリティーの使用 114

UNIX 113

Windows 114

Windows サービス・コントロールパネルの使用115

再試行タイムアウト 162

再試行タイムアウト値 161

再バインド再試行タイムアウト 162

削除アクション・グループ 85



ACL 78

削除アクション 76

作成アクション・グループ 84

アクション・グループでの新しいアクション 86



グループ・コンテナー・オブジェクト 124

役割 56

ACL 77

POP 92

作成アクション 76

サブドメイン 53

識別名、リモート・サーバー 162

事項 237

実行アクション 77

始動サーバー 113

始動の自動化の防止許可サーバー 115

ポリシー・サーバー 115

集中管理 4

手動証明書更新のツール 106


使用可能化監査 137

状況、サーバーの 114

上限基準点 161

上限基準点イベント・キュー 154, 158

商標 239

使用不能可監査 137


証明書管理タスク 105

更新のツール 106

自動リフレッシュ 107

初期構成 106

取り消し 108

証明書およびパスワードの自動リフレッシュ 107

スケーラビリティー 3, 11

スタンザauthentication-mechanisms 178

delegated-admin 195

ivacld 196

ivmgrd 199

ldap 182, 203

ldap-ext-cred-tags 213

manager 214

pdrte 215

ssl 218

uraf-ad in activedir.conf 224

uraf-domino 227

ステップアップ認証構成 99

多元的認証に対する 100

適用 100

ステップアップ認証のレベル 99

制限、ネットワーク・ベースの認証 103

責任許可アクション 32

サーバー管理 32

ACL 管理 32

ACL ポリシー 32

セキュリティーポリシー 55

セキュリティー・ポリシー 26

インプリメント 12

概要 5

定義 33

デフォルト 31

全探索 82

全探索アクション 77

全探索許可 43, 82

疎 ACL モデル 42

属性状況、結果フィールド 141

リソース、ターゲット・フィールド 141

ACL エントリー・タイプ 74

POP 91

［タ行］ターゲット・フィールドリソース属性 141

代行アクション 76

代行アドミニストレーターの説明図 54

代行管理オブジェクト・スペース管理 121

管理ユーザーおよびグループ 31, 122

グループ ACL 許可 127

グループ・コンテナー・オブジェクト 124

ポリシーの管理 129

ユーザー管理 128

代行された管理グループ管理 123

タイプオブジェクト・スペース 62

Tivoli Access Manager サーバー 111

タイプ属性 74

タイムアウト、再バインド再試行 162

タイムアウト値、エラー再試行 161

タスクタイプ 55

役割 55

役割管理 55

役割の活動化 55, 56

役割の作成 55, 56

役割の割り当て 55, 56

多元的認証 100

追加アクション 76

追跡機能 4

通知の遅延時間 118

データ、復元 113

データの抽出 113

データのバックアップ 113

定義セキュリティー・ポリシー 33

ディレクトリーのリスト・アクション 76

適用ステップアップ認証のレベル 100

デフォルト管理 ACL 34

管理ユーザーおよびグループ 122

構成 ACL 35


ポリシー ACL 35

ルート ACL 34, 43

レプリカ ACL 35

GSO ACL 35

伝搬キュー 162

統合バッファー 161

特記事項 237

商標 239

ドメインアドミニストレーター 54

索引 253

ドメイン (続き)

エンタープライズ 53

管理者 (sec_master) 25

サブドメインの記述 53


定義 23

複数 53

ドメイン・アドミニストレーター 65

トレース・アクション 76

トレース・イベント 162

［ナ行］内容、監査証跡ファイル 141

任意認証ユーザー 27

認証監査レコード 143

ステップアップのレベルの構成 99

ステップアップ・ポリシーの適用 100

多元的認証 100


認証局 (CA)

信頼性の判別 107

定義 105

認証済み認証済み要求 28

非認証要求 28

認証済み要求 28

ネットワーク・ベースの認証アルゴリズム 103

制限 103

のタイプオブジェクト 70

Tivoli Access Manager ユーティリティー 112

の場所キャッシュ・ファイル 161

ログ出力を受け取るプログラム 159

ログ・ファイル 155

［ハ行］バージョンインストールされたコンポーネント 113

パイプ・ロギング 159

パスワード管理タスク 105

自動リフレッシュ 107

トラブルシューティング 54

パスワード・アクション 77

バッファー監査ファイル・バッファーのフラッシュ 138

統合バッファーのフラッシュ 161

バッファー (続き)

メッセージの圧縮 161

ログ・ファイル・バッファーのフラッシュ 154, 158

パフォーマンス 162

パラメーターauditcfg 139

hi_water 154

logcfg 153

logflush 138

logsize 138

queue_size 153

汎用的アクションサーバー管理 (s) 76

削除 (d) 76

表示 (v) 77

変更 (m) 76

非認証ユーザー 27

非認証要求 28

評価プロセス、許可 19

表示アクション 77

標準出力 159

ファイルaudit.log 137

ファイルのロギング 155

フォーマット監査イベント 139

付加ACL のオブジェクトへの 79

復元Tivoli Access Manager データ 113


説明図 54

例 53

複製 11

Replica 許可の管理 39

複製 pdadmin サーバー 117

複製、許可データベースの 116

ブラウズ・アクション 76

フラッシュ監査ファイル・バッファー 138


ログ・ファイル・バッファー 154, 158

フラッシュする頻度監査ファイル・バッファー 138



ブレード 24

プロファイル、イベント・キュー 159

文書タイプの定義参照： DTD

変更証明書 108


変更 (続き)

パスワード 108

ACL 79

変更アクション 76

ポート、リモート・サーバー 162

保護オブジェクト 79

保護オブジェクト・スペース 23

ガイドライン 29

保護オブジェクト・ポリシー参照： POP

保護品質 2

保守サービス・メッセージ 135

error.log 135

fatal.log 135

notice.log 135

warning.log 135

ポリシーACL 33

policy 許可の管理 39

POP 29

ポリシー ACL (デフォルト) 35

ポリシー・エンフォーサー 7

ポリシー・サーバー始動の自動化の防止 115

pdmgrd デーモン 111

参照： pdmgrd

ポリシー・データベース 9

［マ行］マスター許可ポリシー・データベース 9

明示的 ACL 42

明示的ポリシー 12

メッセージバッファーの圧縮 161

error.log 135

fatal.log 135

notice.log 135

warning.log 135

メッセージ、保守サービス 135

メモリー内のキュー 153

モード許可 API リモート・キャッシュ 16

許可 API ローカル・キャッシュ 17

テキストまたはバイナリー・ファイル 158

［ヤ行］役割許可 55

代行 55

定義済み 55

役割 (続き)

役割の活動化 55, 56

役割の作成 55, 56

役割の割り当て 55

割り当て 56

役割の代行管理 55

ユーザーアドミニストレーター 25, 54

アドミニストレーター、サポート 54

アドミニストレーター、シニア 54

アドミニストレーター、ドメイン 54

アドミニストレーター、sec_master 52

アドミニストレーター、Tivoli Access Manager 54

代行 55

タイプ属性 75

定義 73

sec_master 31

users 許可の管理 40

ユーザー管理 128

ユーザー・コマンドコマンドのインポート 66

コマンドの作成 66

ユーザー・レジストリー最大値 233, 234

相違点 231

LDAP 構成ファイル 203

ユーティリティー 113

bassslcfg 112

ezinstall_* 112

install_pdrte.exe 112

mgrsslcfg 112

pdbackup 113

pdjrtecfg 113

pdversion 113

pd_start 113

svrsslcfg 113

読み取りアクション 76

［ラ行］ランタイム・ソフトウェア・パッケージセットアップ 112

リストアクション・グループ 85



ACL 78

リソース要求 19

リソース・オブジェクト 23

リソース・マネージャー 6

構成 113

索引 255

リソース・マネージャー (続き)

POP 属性の制約 48

リフレッシュ、証明書およびパスワード 107

リモート・キャッシュ・モード 15, 16

リモート・サーバー大きなバッファーへの統合 161

キャッシュ・ファイルの場所 161

再バインド再試行タイムアウト 162

識別名 162

中継の前のバッファー・サイズ 160

にイベントを送る 159

ポート 162

ホストの指定 162

リモート・ロギング・パラメーター 159, 160

ルート ACL (デフォルト) 34, 43

例外部許可サービス 19


POP IP アドレスおよび範囲の指定 103

レプリカ ACL (デフォルト) 35

ローカル・キャッシュ・モード 15, 17

ロールオーバーしきい値 138

ロギング概要 133

コンソールへの 154

標準出力へのパイプ 159

ファイルに 155

remote 159

ロギングの path オプション 155

ロギングの標準エラー (stderr) 154

ロギングの標準出力 (stdout) 154

ロギング・パラメーターエラー再試行タイムアウト 161

再バインド 162

パイプ 159

パス 155, 159, 161

ポート 162

メッセージ・バッファーの圧縮 161

モード 158

auditlog 137

buffer_size 157, 160

dn 162

flush_interval 159

flush_interval、統合バッファー 161

flush_interval、ログ・ファイル・バッファー 154,

158

hi_water 158, 159, 161

log_id 155

queue_size 157, 159, 161

remote 159

rollover_size 156

ログ出力 159

ログ・キュー、モニター 162

ログ・ファイルキューに入れられるイベントの最大数 157

キュー・サイズ 161

最大バッファー・サイズ 157, 160

の場所の指定 137

ロールオーバーしきい値の指定 138

ロールオーバーの最大サイズ 156

ロケーション 155

hi_water 161

ID 155

ログ・ファイルの ID 155

ログ・ファイルのサイズ 156

ログ・ファイルのバッファー・サイズ 157, 160


ロケーションログ・ファイル 137

AACL 33

エントリー構文 74

エントリー・タイプ属性 74

オブジェクトからの切り離し 80

オブジェクトに対する操作 27

オブジェクトへの適用 79

オブジェクトへの付加 79


カスタム・アクションの入力 87

カスタム・アクションの例 88

管理許可 35

管理タスク 77

許可 76

許可属性 76

グループ管理ポリシー 127

検索 80

異なるオブジェクト・タイプへのポリシーの適用 45

コントロール許可 37

削除 78

作成 77

全探索許可 82

定義 26

デフォルト GSO ACL 35

デフォルト管理 ACL 34

デフォルト構成 ACL 35

デフォルト・ポリシー ACL 35

デフォルト・ルート ACL 34

デフォルト・レプリカ ACL 35

の定義 13

評価 28

表示 79

変更 79


ACL (続き)

ポリシー 27

ポリシー・エントリー 73

明示的に対する継承 42

ユーザー管理ポリシー 128

要求の解決 45

リスト 78

ACL 許可の管理 36

ID 属性 75

ACL 管理コマンド 146

ACL コマンドattach コマンド 80

create コマンド 78

delete コマンド 78

detach コマンド 81

find コマンド 80

list コマンド 78

modify コマンド 79

show コマンド 79

ACL の評価 28

ACL ポリシー 33

継承 46

明示的 46

ACL ポリシーの定義 12

ACL ポリシーの適用 45

ACL ポリシー・アドミニストレーター 32

action group コマンドcreate コマンド 84

delete コマンド 85

list コマンド 85

activedir.conf の uraf-ad スタンザ 224

any-authenticated (全認証) タイプ属性参照： any-other (任意認証)

any-other (任意認証)

タイプ属性 75

認証済み要求 28

非認証要求 28

auditcfg パラメーター 139

auditlog ロギング・パラメーター 137

audit.log ファイル 137

authentication-mechanisms スタンザ 178

auto-database-update-notify 116

auto-database-update-notify コマンド 116

aznAPI

鍵リングおよび stash ファイル 107

aznAPI.kdb 鍵リング・ファイル 107

aznAPI.sth stash ファイル 107

Bbassslcfg コマンドの config オプション 109

bassslcfg ユーティリティー 112

bassslcfg -config コマンド 109

boot-start-ivacld コマンド 115

boot-start-ivmgrd コマンド 115

buffer_size ロギング・パラメーター 157, 160

CCA

参照：認証局 (CA)

compress ロギング・パラメーター 161

Ddelegated-admin スタンザ 195

dn ロギング・パラメーター 162

DTD

監査イベント・フォーマット 139

Eerror ロギング・パラメーター 161

error.log 135

EventPool カテゴリー名 153

ezinstall_* ユーティリティー 112

Ffatal.log 135

flush_interval ロギング・パラメーター 159

ログ・ファイル・バッファー 154

flush_intreval ロギング・パラメーター統合バッファー 161

ログ・ファイル・バッファー 158

Ggroup list コマンド 129

group list-dn コマンド 129

group (グループ)

インポート 67

追加 67

iv-admin 25

GSO

GSO 許可の管理 42

GSO ACL (デフォルト) 35

Hhi_water パラメーター 154

hi_water ロギング・パラメーター 158, 159, 161

索引 257

IIBM Directory ユーザー・レジストリー参照： LDAP server


WebSEAL コンポーネント 1

IBM Tivoli Access Manager for Business Integration 1

IBM Tivoli Access Manager for Operating Systems 1

IBM 製品IBM Tivoli Access Manager 1

IBM Tivoli Access Manager for Business

Integration 1

IBM Tivoli Access Manager for Operating Systems 1

IBM Tivoli Access Manager WebSEAL 1

install_pdrte.exe ユーティリティー 112

IP アドレスPOP のステップアップ認証の使用不可 103

POPの指定 102

IP アドレスによるステップアップ認証 103

ivacld スタンザ 196

ivacld.kdb 鍵リング・ファイル 107

ivacld.sth stash ファイル 107

ivmgrd スタンザ 199

ivmgrd-servers グループ 32

ivmgrd.kdb 鍵リング・ファイル 106

ivmgrd.sth stash ファイル 106

iv-admin グループ 25, 31

JJava ランタイム環境 (JRE)

構成 113

LLDAP

構成ファイル ldap.conf 203

ldap スタンザ 182, 203

ldap-ext-cred-tags スタンザ 213

ldap.conf 構成ファイル 203

logaudit 137

logcfg パラメーター 153

logflush パラメーター 138

logsize パラメーター 138

log_id ロギング・パラメーター 155

MManagement/ACL 許可 36

management/Action 許可 37

Management/Config 許可 39

Management/Groups 許可 41

Management/GSO 許可 42

Management/Policy 許可 39

Management/POP 許可 38

Management/Replica 許可 39

Management/Server 許可 38

Management/Users 許可 40

manager スタンザ 214

max-notifier-threads 116

max-notifier-threads コマンド 117

mgrsslcfg ユーティリティー 112

mode ロギング・パラメーター 158

MQSeries 1

Nnotice.log 135

notifier-wait-time 116

notifier-wait-time コマンド 118

Oobject create コマンド 69

object delete command 71

object list コマンド 70

objectspace create 62

objectspace delete 63

objectspace list 63

objectspace コマンド削除 63

作成 62

リスト 63

Ppath ロギング・パラメーター 155, 159, 161

pdacld 111


pdadmin action create コマンド 87

pdadmin action group create コマンド 84

pdadmin action group delete コマンド 85

pdadmin action group list コマンド 85

pdadmin errtext コマンド 141

pdadmin group create コマンド 125, 126

pdadmin object create コマンド 69, 124

pdadmin object delete 71

pdadmin object list 70

pdadmin objectspace create 62

pdadmin objectspace delete 63

pdadmin objectspace list 63

pdadmin pop attach コマンド 96

pdadmin pop create コマンド 93

pdadmin pop delete コマンド 94


pdadmin pop detach コマンド 97

pdadmin pop find コマンド 96

pdadmin pop list コマンド 94

pdadmin pop modify コマンド 95

pdadmin pop show コマンド 95

pdadmin server replicate 117

pdadmin server task コマンド 162

pdadmin stats get コマンド 163

pdadmin stats list コマンド 162

pdadmin サーバー複製 117

pdadmin サーバー複製コマンド 117

pdadmin ユーティリティーTivoli Access Manager コンポーネント 4

pdbackup ユーティリティー 113

PDCA 証明書参照：証明書

pdjrtecfg ユーティリティー 113

pdmgrd 111


pdrte


pdrte スタンザ 215

pdversion ユーティリティー 113

pd.kdb 鍵リング・ファイル 106

pd.sth stash ファイル 106

pd_start ユーティリティー 113

pd_start ユーティリティーを使用したサーバー状況 114

pipe ロギング・パラメーター 159

POP

オブジェクトへの適用 95

概要 91

検索 96

コマンド 91

削除 94

作成 92

属性 91

属性の構成 97

定義 26

の属性 47

の定義 13

表示 94

付加 95

変更 94

ポリシー 29

リスト 93

IP アドレスおよび範囲の指定 102

IP アドレスによるステップアップ認証の使用不可103

POP 許可の管理 38

pop attach コマンド 96

pop create コマンド 93

pop delete コマンド 94

pop detach コマンド 97

pop find コマンド 96

pop list コマンド 94

pop modify コマンド 95

pop show コマンド 95

POP コマンド削除 94

作成 93

付加 96

変更 95

リスト 94

detach 97

find 96

show 95

POP 属性監査レベル 97

警告モード 97

時刻 98

POP 属性制約リソース・マネージャーによる 48

Tivoli Access Manager Base による 47

POP のバイパス・アクション 76

POP ポリシーネットワーク・ベースの認証 102

保護品質 101

POP ポリシーの定義 12

port ロギング・パラメーター 162

Qqueue_size パラメーター 153

queue_size ロギング・パラメーター 157, 159, 161

Rrebind ロギング・パラメーター 162

rollover_size ロギング・パラメーター 156

Ssec_master 52

sec_master ドメイン管理者 25

sec_master ユーザー 25, 31

server replicate 117

server task コマンド 162

set ipauth add option 102

set ipauth remove オプション 103

SSL

基本構成タスクの実行 112

構成タスクの実行 112

ssl スタンザ 218

索引 259

stash ファイル 105

aznAPI.sth 107

ivacld.sth 107

ivmgrd.sth 106

pd.sth 106

stats get コマンド 163

stats list コマンド 162

svrsslcfg コマンドの chgcert オプション 108

svrsslcfg コマンドの chgpwd オプション 108

svrsslcfg ユーティリティー 113

svrsslcfg -chgpwd コマンド 108

svrsslcfg -unconfig コマンド 108

TTivoli Access Manager

アドミニストレーター 54

概要 1

監査証跡ファイル 137

管理 API 5

許可 2

許可 API 14

許可サービス 8, 9

コア・テクノロジー 2

サーバーを手動で順番に始動する 114

集中管理 4

スケーラビリティー 3

追跡機能 4

データの復元 113

認証 2

のコンポーネントの構成 113

バッチ・ファイルおよびスクリプトを使用したインストール 112

保護品質 2

ユーティリティー 112

ランタイム・ソフトウェア・パッケージのセットアップ 112

Java ランタイム環境 (JRE) の構成 113

pdadmin コマンド行ユーティリティー 4

pd_start ユーティリティーを使用したサーバーの再始動 114

pd_start ユーティリティーを使用したサーバーの始動113

pd_start ユーティリティーを使用したサーバーの停止114

Web ポータル・マネージャー (WPM) 4

Windows サービス・コントロール・パネルを使用したサーバーの始動 115

Windows サービス・コントロール・パネルを使用したサーバーの停止 115

Tivoli Access Manager Base

POP 属性の制約 47

Uunauthenticated (非認証)

タイプ属性 75

UNIX サーバー始動および停止 113

uraf-domino 227

user list コマンド 129

user list-dn コマンド 129

User Registry Adapter Framework (URAF) 224

user show groups コマンド 129

user (ユーザー)

インポート 66

作成 65

sec_master 25

Wwarning.log 135

Web Portal Manager


Web ポータル・マネージャー (WPM)


WebSEAL 1

Windows

サーバーの始動および停止 114

XXML

監査証跡文書 139


��

Printed in Japan

SC88-9522-01

base 管理者ガイド - ibmpublib.boulder.ibm.com/tividd/td/itame/sc32-1132... ·...

Documents