5.13.統合アカウント管理・認証・認可(アクセス制御) · ③web...
TRANSCRIPT
165
5.13.統合アカウント管理・認証・認可(アクセス制御)
5.13.1.統合アカウント管理・認証・認可(アクセス制御)の定義
統合アカウント管理・認証・認可(アクセス制御)は、情報システムの利用者を統合的、一元的に管理する仕
組みを提供する。利用者がその ID をもっている本人であることを確認し、利用者の権限に基づきリソースへ
のアクセス制御を行う。
府省個別府省個別人事・給与情報システム人事・給与情報システム
＜認証情報＞・職員番号・氏名・所属・官職・ID/パスワード
・電子証明書 等
WebWebアプリケーション用アプリケーション用
ディレクトリディレクトリ
OSOS用ディレクトリ用ディレクトリ
グループウェア用グループウェア用ディレクトリディレクトリ
WebWebアプリアプリ““AA””
WebWebアプリアプリ““BB””
ファイル共有ファイル共有
メールメール//掲示板掲示板
Web
W
eb
シングルサインオン
シングルサインオン
デスクトップ・シングルサインオン
デスクトップ・シングルサインオン
ディレクトリ連携
ディレクトリ連携
統合ディレクトリ統合ディレクトリ
統合アカウント管理統合アカウント管理
利用者利用者
OSOSアクセス制御アクセス制御
アクセス制御
ポリシー
アクセス制御
ポリシー
アクセス制御
ポリシー
アクセス制御
ポリシー
アクセス制御
ポリシー
図 5.13-1 統合アカウント管理・認証・認可(アクセス制御)の機能・サービス
統合アカウント管理・認証･認可(アクセス制御)の機能･サービスとして、次の５つが挙げられる。
①統合アカウント管理
②ディレクトリ連携
③Web シングルサインオン
④デスクトップ･シングルサインオン
⑤OS アクセス制御
これらの機能・サービスにより、アカウント情報を一元的に管理する仕組みと、利用者の利便性向上に寄与
するシングルサインオン環境が実現される。統合ディレクトリの情報は、組織内の電子電話帳、メールシステ
166
ムの共有アドレス帳、インスタント・メッセージングの宛先に活用することも考えられる。
統合アカウント管理・認証・認可(アクセス制御)の機能・サービス
機能･サービス 定義
統合アカウント管理 利用者の認証情報(ユーザ ID、パスワード)と属性情報(グループ、所属部門等)
を一元的に管理する機能を提供する。一元的に管理されたアカウント情報は、
あらかじめ定義されたポリシーに基づいて、関連するシステムやディレクトリへ自動
又は手動で反映される(プロビジョニング機能)。アカウント管理に関する各種管
理業務を支援するためのワークフロー機能も提供する。
ディレクトリ連携 アカウント情報が、RDB や LDAP、CSV ファイル等異なる方式のディレクトリに格
納されている環境において、各種ディレクトリやデータベースへ接続するコネクタ機
能とアカウント情報の属性を変換(データ変換/マッピング)する機能により、ディレ
クトリ間の連携を実現する。
Web シングルサインオン 複数の Web アプリケーションに対する認証とアクセス制御を一元的に管理し、シ
ングルサインオンを実現する。利用者は、Webシングルサインオンへ1 度だけログイ
ンすれば、アクセスが可能なすべての Web アプリケーションを個別にログインするこ
となく利用することができる。Web アプリケーションへのアクセス履歴の記録や、タイ
ムアウトにより再認証を要求する機能も提供する。
デスクトップ･シングルサイ
ンオン
端末の OS だけでなく、グループウェアや Web アプリケーション、C/S 型アプリケー
ション等に一括してログインし、シングルサインオンを実現する。利用者は、デスク
トップ・シングルサインオンへ 1 度だけログインすれば、端末上の利用可能なアプリ
ケーションを個別にログインすることなく利用することができる。
OS アクセス制御 あらかじめ定義したアクセス制御ポリシーに従って、OS のリソース(ファイルやネット
ワーク、ユーザ等)に対するアクセス制御を行う。アクセス制御ポリシーは集中的に
管理され、管理対象のシステムに対して一括で適用することができる。いつ、誰
が、どのリソースへアクセスし、成功したか/失敗したかといった情報を監査ログとし
て取得し、蓄積する機能も有する。アクセス制御ポリシーは、一般のユーザだけ
でなく、いわゆる管理者ユーザと呼ばれる特権ユーザに対しても、管理者の作業
内容に合わせて適用することができる。
167
5.13.2.統合アカウント管理の機能要件・非機能要件・標準技術
機能要件
1 基本 アカウント情報の登録/変更/削除を一元的に行う機能を提供すること。
2 基本 アカウント情報の登録/変更/削除等、ポリシーを作成しておくことで、アカウント情報のライフ
サイクル管理を自動化できること。
3 基本 定義されたポリシーに基づいて、利用者の登録や属性変更を、自動的に宛先(あてさき)のシ
ステムに反映するための仕組み(プロビジョニング機能)を提供すること。
4 基本 ユーザ ID について、命名規則や有効期限等の制約事項に基づき制限をかけることができるこ
と。パスワードについても長さや文字種、有効期限等を制限することができること。
5 基本 アカウント情報の登録/変更/削除等の申請後、ワークフローによる承認を経て、各種 OS や
ディレクトリへ適用する仕組みを有すること。
6 基本 ユーザ ID に対して利用停止(非アクティブ化)と利用再開(アクティブ化)の設定ができること。
7 基本 利用者は、自分自身でパスワードの変更作業やリセット作業が可能なこと(セルフケア)。
8 基本 アカウント情報やポリシーの追加・変更・削除等、重要な操作を監査ログに記録すること。
9 加点 監査ログはレポートとしてわかりやすい形式で表示できること。
非機能要件 (個別の要件がある場合のみ記述)
可用性 加点 サーバの冗長化やクラスタ・ソフト、レプリケーション等の技術により可用性を高める
構成を採用すること。
セキュリティ 基本 認証を受けた管理者のみが、アカウント情報にアクセスできる仕組みを有すること。
基本 管理者の役割や管理対象の範囲に応じて、適切なアクセス権を設定してアカウン
ト情報を保護することができること。
基本 長期間使われていないユーザ ID を識別して、無効又は削除できること。
加点 通信の暗号化が可能なこと。
パフォーマンス 基本 ｛約 5 万｝のアカウントを管理することとなり、人事異動の際には短期間に大量のユ
ーザ属性を更新することが求められる。事前に明示された性能要件に対して、十
分な処理能力をもった構成とすること。
拡張性 加点 対象とするシステムや利用者の増加に伴い、アカウントの増加が予想されるため、
処理能力の柔軟な増強ができる構成とすること。
バックアップ 基本 アカウント情報やポリシーのバックアップを取得ができること。
関連する技術
ディレクトリサービス
アクセスプロトコル
LDAP(Lightweight Directory Access Protocol) - ディレクトリ・サービスに接続するた
めに使用される標準プロトコル。LDAP V3 が規定されている。
ディレクトリサービス
交換形式
LDIF(LDAP Data Interchange Format) - LDAP のアカウント情報を交換する際に用い
るファイル・フォーマットである。
プロビジョニング情
報交換言語
SPML(Service Provisioning Markup Language) - ID プロビジョニングのための標準プロ
トコル。SPML V2 が規定されている。
・物理構成モデルのセグメントに対応する項目：S1～S6
168
5.13.3.ディレクトリ連携の機能要件・非機能要件・標準技術
機能要件
1 基本 複数のディレクトリを連携し、格納されているアカウント情報の内容を同期させる機能を提供
すること。
2 基本 コネクタ(データ通信)機能を提供すること。分散された各種ディレクトリ【RDB、LDAP、CSV フ
ァイル 等】に対して、アカウント情報を配信することができること。
3 基本 マッチング・エンジン(データ変換/マッピング)機能を提供すること。アカウント情報を配信する際
に、宛先(あてさき)ディレクトリの環境に合わせて、データの型変換、マッピングを行うことができ
ること。
4 基本 データ変換やマッピングの設定を行うためのツール【GUI、SDK 等】を提供すること。
5 基本 複数のディレクトリから取得したデータを結合したり加工したりする等、運用中にロジックを自
由に組み込むことができること。
6 基本 統合ディレクトリに格納されたパスワードを同期するための仕組みを提供すること。
7 基本 ディレクトリに格納されたアカウント情報に矛盾がないか、不正なアカウントが追加されていない
かの棚卸しを行う仕組みを提供すること。
非機能要件 (個別の要件がある場合のみ記述)
可用性 加点 サーバの冗長化やクラスタ・ソフト、レプリケーション等の技術により可用性を高める
構成を採用すること。
セキュリティ 加点 通信の暗号化が可能なこと。
パフォーマンス 基本 ｛約 5 万｝のアカウントを管理することとなり、人事異動の際には短期間に大量のユ
ーザ属性を更新することが求められる。事前に明示された性能要件に対して、十
分な処理能力をもった構成とすること。
拡張性 加点 対象とするシステムや利用者の増加に伴い、アカウントの増加が予想されるため、
処理能力の柔軟な増強ができる構成とすること。
バックアップ 基本 マッチング・ルール等の管理データのバックアップを取得すること。
関連する技術
ディレクトリサービス
アクセスプロトコル
LDAP(Lightweight Directory Access Protocol) - ディレクトリ・サービスに接続するた
めに使用される標準プロトコル。LDAP V3 が規定されている。
データベース接続
API
JDBC(Java Database Connectivity) - Java プログラムから RDB へアクセスするための
API。ディレクトリが RDB のケースでは利用が想定される。
・物理構成モデルのセグメントに対応する項目：S1～S6
169
5.13.4.Web シングルサインオンの機能要件・非機能要件・標準技術
機能要件
1 基本 Web アプリケーションに対して、指定された認証方式【ユーザ ID、パスワード 等】による認証
と、URL をベースとしたアクセス制御の機能を提供すること。
2 基本 利用者は一度だけログインを行えば、アクセスが可能なすべての Web アプリケーションを個別に
ログインすることなく利用することができること(シングルサインオン)。
3 基本 アクセス制御ポリシーを集中管理して、複数の認証プロキシやエージェントへ同時に適用でき
ること。
4 基本 ログインした利用者のアカウント情報【ユーザ ID、所属 等】を、Web アプリケーションに対して
渡す仕組みを有すること。
5 基本 あらかじめ決められた回数、ログインに失敗したアカウントを、自動的にロックして使用不能にで
きること。
6 基本 アカウントの認証履歴を、監査ログとして取得し、蓄積できること。
7 加点 トークン認証(ワンタイム・パスワード)、IC カード認証、生体認証等の強力な認証方式と組み
合わせることが可能であること。
非機能要件 (個別の要件がある場合のみ記述)
可用性 加点 サーバの冗長化やクラスタ・ソフト、レプリケーション等の技術により可用性を高める
構成を採用すること。
セキュリティ 基本 取得した監査ログはアクセス制御を徹底して改ざんを防止すること。
加点 通信の暗号化が可能なこと。
パフォーマンス 基本 ｛約 5 万｝のアカウントが想定される。事前に性能要件を明確にし、十分な処理能
力をもった構成とすること。
拡張性 加点 対象とする Web アプリケーションや利用者の増加が予想されるため、処理能力の
柔軟な増強ができる構成とすること。
バックアップ 基本 アクセス制御ポリシー等の設定情報や監査ログはバックアップを取得すること。
関連する技術
ディレクトリサービス
アクセスプロトコル
LDAP(Lightweight Directory Access Protocol) - ディレクトリ・サービスに接続するた
めに使用される標準プロトコル。LDAP V3 が規定されている。
・物理構成モデルのセグメントに対応する項目：S1～S6
170
5.13.5.デスクトップ・シングルサインオンの機能要件・非機能要件・標準技術
機能要件
1 基本 端末上で稼動するエージェントが、利用者に代わってユーザ認証を行うことにより、Web アプリ
ケーションやグループウェア、C/S 型アプリケーション等に自動的にログインし、シングルサインオ
ンを実現すること。
2 基本 利用者はデスクトップに一度ログオンすれば、端末上の利用可能なアプリケーションをログイン
の手間をかけずに利用することができること。デスクトップ OS のログオン認証と連携するアプリケ
ーションの採用、又は、あらかじめユーザ ID とパスワードを登録して利用するアプリケーションに
合わせてエージェントが認証情報を自動的に入力することにより、シングルサインオンを実現す
る。
3 基本 シングルサインオンの対象とするアプリケーションや自動入力されるユーザ ID とパスワードは、シ
ステム管理者が一元的に管理できること。端末の設定を集中管理できること。
4 加点 デスクトップ・シングルサインオンのエージェントへログインする際のパスワードを利用者が忘れた
場合を考慮し、パスワードリマインダ機能等のパスワード忘れ時の対応機能があること。
5 加点 トークン認証(ワンタイム・パスワード)、IC カード認証、生体認証等の強力な認証方式と組み
合わせることが可能であること。
非機能要件 (個別の要件がある場合のみ記述)
可用性 加点 サーバの冗長化やクラスタ・ソフト、レプリケーション等の技術により可用性を高める
構成を採用すること。
セキュリティ 基本 自動入力されるユーザ ID とパスワードは、暗号化して保持すること。
パフォーマンス 基本 ｛約 5 万｝のアカウントが想定される。事前に性能要件を明確にし、十分な処理能
力をもった構成とすること。
拡張性 加点 対象とするアプリケーションや利用者の増加が予想されるため、処理能力の柔軟
な増強ができる構成とすること。
バックアップ 基本 エージェントの設定情報はバックアップを取得すること。
・物理構成モデルのセグメントに対応する項目：S1～S6
5.13.6.OS アクセス制御の機能要件・非機能要件・標準技術
ここでは OS に限定したアクセス制御の機能要件、非機能要件のみを記載している。しかし、 近のインタ
ーネット技術の発達により、アイデンティティ管理の一環として OS に限定しないアクセス制御技術や権限管
理の仕組みが標準化(RBAC や XACML 等)されている。OS に限定しない方式は、あらかじめ定義したアク
セス制御ポリシーに従い、リソースに対するアクセス制御情報を配布する。アクセス制御ポリシーは集中的に
管理され、作成、変更、削除の監査、ライフサイクル管理機能を有する。アクセス制御はロールベース、ルー
ルベースでの定義が可能で、独自のロジックの組み込みが可能となる。
171
機能要件
1 基本 OS のリソース(ファイルやネットワーク、ユーザ等)に対するアクセスを監視して、あらかじめ定義さ
れたアクセス制御ポリシーで許可されたアクセスのみを許可すること。
2 基本 OS の管理者権限をもつアカウントに対してもシステム操作やファイル、プログラムへのアクセス
を制御すること。
3 基本 アクセス制御ポリシーを集中管理して、複数の管理対象サーバへ適用できること。
4 基本 重要データ、プログラムの改ざん防止及び検知ができること。
5 基本 不正アクセス等のポリシー違反を検知した場合は、監視コンソールへ通知できること。
6 加点 OS のリソース(ファイルやネットワーク、ユーザ等)に対するアクセスの監査ログとして【日時、ユー
ザ名、リソース名、アクセス内容、アクセス結果 等】の内容を記録すること。
7 加点 不正アクセス等のポリシー違反を検知した場合は、記録された監査ログを参照することによ
り、【不正アクセスの日時、ユーザ名、リソース名、アクセス内容、アクセス結果 等】の情報を
分析することができること。
8 基本 管理対象サーバ上で取得された監査ログを収集し、一元的に管理・保管する仕組みを有す
ること。
非機能要件 (個別の要件がある場合のみ記述)
可用性 加点 サーバの冗長化やクラスタ・ソフト、レプリケーション等の技術により可用性を高める
構成を採用すること。
セキュリティ 基本 取得した監査ログはアクセス制御を徹底して改ざんを防止すること。
加点 通信の暗号化が可能なこと。
パフォーマンス 基本 ｛約 5 万｝のアカウントが想定される。事前に性能要件を明確にし、十分な処理能
力をもった構成とすること。
拡張性 加点 対象とするシステムや利用者の増加が予想されるため、処理能力の柔軟な増強
ができる構成とすること。
バックアップ 基本 アクセス制御ポリシー等の設定情報や監査ログはバックアップを取得すること。
関連する技術
アクセス制御 RBAC (Role Based Access Control) - ロールをもとにアクセス制御を実行する考え方。
管理者はユーザ(あるいはグループ)とロールの紐(ひも)付け(User Role Assignment: UA)とロ
ールと権限の紐(ひも)付け(Permission Role Assignment: PA)を管理することで適切な権
限の付与を実現する。
アクセスコントロ
ール記述言語
XACML(eXtensible Access Control Markup Language) - XML ベースのアクセス制御ポリ
シーを記述するための言語仕様。リソースに対し複雑な条件を設定することが可能となって
いる。国際標準規格 ITU-T Recommendation X.1142
・ 物理構成モデルのセグメントに対応する項目：S1～S6