SysAdmin's Group システム管理者の会
日本最大規模の
システム管理者のネットワーク

運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

IT運用の内部統制/J-SOX適用 第5回 重点対応プロセスの参照モデル 《 その1:アクセス管理プロセス 》
2009年11月11日 17:58

前回は、当該活動のフレームワークで作成するドキュメントのサンプルを紹介しました。今回は、当該の活動で重点的に対応(再構築)するプロセスとして選定し、設計した業務プロセスのひとつ、「アクセス管理プロセス」の概要を紹介します。これは、汎用的なプロセスとして設計したものではなく、具体的な特定の組織を想定して作成しています。実際には、企業毎に異なる業務プロセスが存在します。組織は、ビジネスを取り巻く環境とか、経営戦略およびITを構成する組織のミッションとか、組織が共有する風土・文化とか・・・、種々の要因に適応して編成され、活動します。設計する業務プロセスの対象は、その「組織の活動そのものと言えます。当然ですが、組織マネジメントのレベルも異なります。したがって、ここで紹介するモデルは、当該の活動における成果物(特定の組織を想定した)として紹介する、ひとつの参照モデルです。

1.コントロール目標と成果指標

 当該の「アクセス管理プロセス」は、システムの情報セキュリティを保証するために、その情報資源を不正なアクセスから保護し、そのインテグリティ(完全性)を維持することを目標にします。そのために必要な手続きと管理の基準を定め、適時にその目標と達成状況(成果指標)をモニタリングし、必要な改善を継続して実施します。

< コントロール目標 >
    1. 情報資源(データ)へのアクセスを許可する、すべての利用者(システムの管理スタッフを含む)と、そのアクテビティを識別する。
    2. システム利用者に対するアクセス権は、組織が定める職務分掌に基づき、その職務を担う個人に付与する。
    3. 適用業務システム等の利用者に付与するアクセス権は、そのシステムを利用する部門が申請し、システムオーナー部門(利用部門を統括する管理部門)が承認し、IT運用部門がシステムに実装する。
    4. 特殊権限は、IT部門の職務分掌に基づき、その職務を担う個人に、期限を付けて貸与する。特殊権限は、IT部門の管理者が申請し、IT部門を統括するマネージャーが承認し、IT運用部門が、これをシステムに実装する。
    5. システム利用者のアカウントおよびそれに付随するアクセス権限の登録、変更、削除の手続きを定め、その手続きを確実に行う。定期的に、プロセスの実行をモニタリングし、その確実性を保証する。
    6. 情報資源(データ)に対する利用者のアクテビティを記録するログ情報は、単一のリポジトリィで集中して管理する。
    7. システムのログ情報などから不正なアクセスの予兆を早めに検知し、その状態を適正に是正し、セキュリティインシデントの発生を予防する。
    8. 不正なアクセスによって発生したインシデントは、インシデント管理プロセスに連係し、定められた判断基準と影響レベルに即して、速やかに解決する。
    9. コスト効率に優れた技術面および手続き面の対策を講じ、マネジメントサイクルとして、常に継続的な改善を行う。
    10. IT部門を統括するマネージャーは、率先して、情報資源(データ)へのアクセスに関する管理状況をレビューし、必要な対策を指示する。
< 成果指標 >
上述のコントロール目標の達成状況を測定します。成果指標は当該のアクセス管理プロセスの中で測定し、IT部門の目標管理プロセス(システム)で管理されます。

    1. 権限プロファイル設定の要件を満たさないシステムの数
    2. アカウントの実査(実地棚卸)の結果、検出された差異件数
    3. 不正の予兆を検知したアクセスの件数
    4. 「影響度レベル=大」の不正アクセス(セキュリティインシデント)の件数

2.管理プロセス

 上述のコントロール目標に適応したプロセスを再設計します。以下に、その概要を示します。

《 0.00 アクセス管理プロセス 》
09111100tasaka.png
ここで紹介するアクセス管理プロセスは、次の5つの業務(上図)で構成されています。それは、情報システムや重要データに対するアクセスの制御とアカウントの管理を対象とするものです。

1.00 アクセス権定義の運用移行 
2.00 アカウントの維持更新 
3.00 特権アカウントの貸与 
4.00 アカウントの実査 
5.00 モニタリング

 従来の管理プロセスは「危険なアクセスを定義して、不正なアクセスを排除する」ことをベースに組み立てた組織(企業)が多かったように思います。それは都合よく解釈された「性善説:人間の本性は基本的に善であるとする概念」を元に設計されたプロセスで、不正なアクセスそのものを管理するプロセスだったように思います。所謂、例外を管理するもので、裏切られることも多かったように思います。当該の管理プロセスは「安全なアクセスを定義して、不正なアクセスを排除する」ことをベースにしています。これは、例外を管理するものではありません。したがって、マネジメントの効率性に対する配慮と手当が必要になります。当該プロセスのシステム化や管理ツールの導入を行うなどの手当てによって、効率性が維持され、より確かなマネジメントのレベルアップが可能になります。
 当該の管理プロセスは、ISMS(情報セキュリティマネジメントシステム)導入のフレームワークの中で、重点的に対応するプロセスとして、抽出したものです。情報セキュリティの方針および、方針に基づくルールの設定、ルールの改廃/承認や周知の方法等の手続きは、活動の母体であるISMS(情報セキュリティマネジメントシステム)の導入作業として実施します。
※ 詳細は「第2回 内部統制強化のための活動計画を策定する。」に記述しています。

 その他の留意すべきアクセス管理プロセスとして「情報セキュリティ制御エリアへの物理的な入退室管理」や「データの外部保管」等々のプロセスがあります。物理的な制御エリア(コンピュータセンター、マシンルーム、データ保管室等の情報処理施設)へのアクセスを、必要な要員のみに制限するための方策を講じること、これもアクセス管理プロセスの対象範囲です。これらのプロセスを含めて再設計(改善)する場合は、階層レベルを1階層下げて全体の構造を整理することになります。
 

《 1.00 アクセス権定義の運用移行 》
09111101tasaka.png
当該のプロセス(上図)は、アクセスのルールを設定する業務で、次の4つの要素で構成されています。当該の業務は、業務分掌に基づいたアクセスを保証するために、職務内容に一致した権限プロファイル(権限付与情報)を定義して、利用者によるアクセスをコントロールする環境を準備します。実際のアクセスは、この権限プロファイル(権限付与情報)と個人別に付与する「利用者ID」との照合によって制御されます。

 1.10 コンタクト
 コンタクト先と要件はつぎのとおりです。
* システムを調達し導入する部門(システム開発部門/プロジェクト)
→ システムの運用引き継ぎ
* システムオーナー部門(適用業務の管理スタッフ部門)
→ システム利用者の権限プロファイル(権限付与情報)の定義要求
* IT部門(IT部門全体)
→ 特殊権限プロファイル(権限付与情報)の確認 
 
 1.20 アクセス権定義表の取得
 システムオーナー部門からアクセス権限定義表(プロファイル)を入手します。
適用業務システムの引き継ぎ書類と照合しその内容を確認します。不備、不適確な事項をオーナー部門と調整し、当該のアクセス権限定義表(プロファイル)を確定させます。不適格な事項の中には、開発された適用業務システムのメニュー構成(遷移)に問題がある場合もあります。このような場合は、オーナー部門とシステムの調達導入部門との調整(問題を解決すること)が必要になります。
 1.30 アクセス特殊権限の定義
 この要素業務は、自ら(IT運用を含むIT部門の要員)に付与する特殊権限(プロファイル)を定義します。
多くの場合、アクセスの権限設定・監視・管理等々の業務を担う組織は、IT運用部門かと思います。悪く言うと、IT運用を担う人達には、システムが扱うデータを不正に取得することや、アクセス履歴の改竄などの不正な行為を、造作もなく行うことができます。リスクの高い特殊な権限を所有しています。これらの特殊権限が必要以上に、野放しで付与されている状況は、極めて危険な状況と言えます。(一般的に軽視されがちで、要対応の組織が多いようです)。
 1.40 システム設定
 システム利用者を対象とする「アクセス権限定義表」とシステム管理者を対象とする「特殊権限定義表」からアクセスするアカウントを管理する台帳(システム的に用意されたアカウント管理台帳)を作成(初期設定を)します。

 

《 2.00 アカウントの維持更新 》
09111102tasaka.png
当該のプロセス(上図)は、適用業務システムの利用者に対するアカウントの発行と権限内容の変更、失効を管理する業務で、次の8つの要素で構成されています。これらの要素業務は利用者IDとアクセス権限の付与申請、承認、発行、一時停止、削除を適切に行うための手続きを示しています。当該のモデルでは採用していませんが、可能であれば利用者IDの管理を人事システムと連動させることも検討すべきです。拡張すると、システム毎に所有する複数のIDを一元化するなどのシステム的な対応も可能になります。

 2.10 申請書の作成
 システム利用部門の管理者は、利用者(個人)を識別するIDとアクセス権限の付与を、システムオーナー部門に申請します。申請の内容は登録・変更・削除に大別されます。

 2.20 申請書の受付/審査(オーナー部門)
  システムオーナー部門は、システム利用部門の申請を受け付けて、人事情報、ID作成要領およびアクセス権限定義表(プロファイル)などから、申請内容の適正・適確性を審査し受理します。システムオーナー部門の管理者は申請内容をレビューして、IT運用部門に申請に基づく作業を依頼します。

 2.30 申請書の受付/審査(IT運用部門)
 IT運用部門はシステムオーナー部門から申請書を受け付けて、手続きおよび申請内容の整合性を確認し受理します。IT運用部門の管理者は申請内容の整合性をレビューして、システム担当者に申請に基づく作業を指示します。

 2.40 変更作業の実施
 システム担当者は申請書に基づく作業(登録・変更・削除)を実施します。

 2.50 作業結果の検証
 システム担当者は作業の結果を記録し、検証して管理者に報告します。

 2.60 作業完了の報告
 IT運用部門の管理者はシステム担当者の作業結果を検証して、システムオーナー部門に作業の完了を報告します。システム担当者は、システム利用者に付与するIDと初期パスワードを連絡します。

 2.70 作業完了の確認
 システムオーナー部門の管理者はIT運用部門の管理者による報告を受けて、依頼した作業の完了を確認し、システム利用部門の管理者にその内容を伝えます。

 2.80 初期パスワードの更新
 システム利用者は、IT運用部門のシステム担当者から交付されたIDの初期パスワードを更新します。(初期パスワードの更新によってアクセスを可能にします。以降、更新したパスワードを失念した場合などは、新たに申請をし直すことになります。)


 当該のプロセスおよび次のプロセス(3.0特権アカウントの貸与)の前提として、パスワードの漏洩等を防止するためのルールを定めておく必要があります。
例えば、上述「2.80 初期パスワードの更新」は、「初期パスワードを設定して、強制的な変更を義務づける」というルールに従っています。
* 利用者IDの作成標準として、共用IDの作成を禁止する(個人使用とする)。
* 利用者IDの貸し借り禁止などの利用ルールを規定する。
* パスワードの有効期間を設定する(変更の間隔を定めて、強制的な変更を義務づける)。
* パスワードの最小桁数および複雑性(英数字/大文字・小文字・数字、記号の混在)を規定する。
* パスワード入力ミスの回数を制限する。(ロックアウトする)
* パスワードの変更履歴から、同一の設定を制限する。
* パスワードの取り扱いに関するルールを規定する。
* パスワードのリセット手続きを定める。
* etc

《 3.00 特権アカウントの貸与 》 
09111103tasaka.png
当該のプロセス(上図)は、IT部門の特権を有する技術者および管理スタッフに対するアカウントの発行と権限内容の変更、失効を管理する業務で、次の8つの要素で構成されています。これらの要素業務は利用者IDとアクセス権限の借用申請、承認、発行、一時停止、削除を適切に行うための手続きを示しています。当該のプロセスは平常時・緊急時を問わずに適用されます。

 3.10 貸与申請書の作成
 IT運用を含むIT部門の管理者は、技術者および管理スタッフ(個人)を識別するIDとアクセス特殊権限の借用を、IT部門のマネージャーに申請します。申請の内容は登録・変更・削除に大別されます。

 3.20 貸与申請書の受付/審査
 IT運用部門は、IT部門のマネージャーの貸与申請を受け付けて、人事異動情報、ID作成要領およびアクセス権限定義表(プロファイル)などから、申請内容および手続きの適正・適確性等を審査し受理します。IT運用部門の管理者は申請内容をレビューして、システムの担当者に申請に基づく作業を指示します。

 3.30 変更作業の実施
 システムの担当者は貸与申請書に基づく作業(登録・変更・削除)を実施します。

 3.40 作業結果の検証
 システム担当者は作業の結果を記録し、検証して管理者に報告します。

 3.50 作業完了の報告
 IT運用部門の管理者はシステム担当者の作業結果を検証して、IT部門の管理者およびマネージャーに作業の完了を報告します。 (システム利用者は、システム担当者から貸与されたIDの初期パスワードを更新することによって、該当システムへのアクセスが可能になります。)

 3.60 有効期間のパトロール
 登録されているアカウントの有効期間を定期的にパトロールします。有効期間は臨時(短期的)に貸与するものと定期に貸与するものがあります。パトロールは臨時と定期に対応して行い、有効期限を満たすアカウントを検出します。

 3.70 使用の停止
 有効期限を満たしたアカウントのシステム利用を停止します。

 3.80 アカウントの削除
 使用を停止しているアカウントを定期的に抹消します。(期間の延長はしません。新たに貸与の申請をし直すことになります。)

 

《 4.00 アカウントの実査 》
09111104tasaka.png
当該のプロセス(上図)は、前述の1.00~3.00のプロセスの正当性を保証します。職務分掌に基づいたアクセス権限を設定し、利用者IDおよびそれに付随する権限の申請、発行、登録(設定)、変更、削除(抹消)が、定めたルールに従って、確実に実行されていることを実査(棚卸)する業務で、次の6つの要素で構成されています。システム的に用意されたアカウント管理台帳とは別に、人為的に更新される管理台帳などを利用する場合は、加えて、その相互の整合性を担保する必要があります。

 4.10 棚卸表の作成
 定期的に、システム的に用意されたアカウント管理台帳より、その登録情報を一覧形式の棚卸表を出力します。定期的に実査を行う日、間隔等々はルール化しておくと良いでしょう。

 4.20 棚卸の依頼
 IT運用部門は、出力した棚卸表をシステムオーナー部門に配付します。システムオーナー部門は、棚卸表を作業単位に仕訳して、システム利用部門に、実地棚卸の作業を指示します。

 4.30 棚卸の実施
 システム利用部門はシステムオーナー部門の指示に従って棚卸を実施します。

 4.40 差異の原因調査
 棚卸表と実地が異なる場合は、その差異が発生した原因を調査し、その調査結果を記録します。システム利用部門の管理者は差異およびその調査結果の記録をレビューします。

 4.50 棚卸の実施報告と審査
 システム利用部門の管理者は、上述の差異の調査を含む実地棚卸の結果をシステムオーナー部門に報告します。システムオーナー部門は報告内容を審査します。システムオーナー部門の管理者は棚卸の実施と実地に基づく差異修正の許可をマネージャーに求めます。

 4.60 差異の修正指示
 システムオーナー部門の管理者は、マネージャーが許可する棚卸の差異修正をシステム利用部門に指示します。差異の修正は《2.00 アカウントの維持更新》あるいは《 3.00 特権アカウントの貸与 》のプロセスで実施されます。

 

《 5.00 モニタリング 》
09111105tasaka.png
当該のプロセス(上図)は、アクセス管理プロセスが有効に機能しているかを検証する業務で、次の6つの要素で構成されています。これらの要素業務は、情報の漏洩や不正な使用につながるアクセスを監視し追跡することを含みます。当該の業務は、IT運用部門の固有業務で、特殊権限を貸与された担当者(システム管理者)が定められたルール(ログ情報へのアクセス権限/ログの保存基準・・等々)に従って行います。

 5.10 アクセスログの取得
 ログを取得して蓄積します。ログの取得対象は、オペレーションシステムや適用業務システム、種々の監視および制御ソフトウエア、物理的なアクセスを管理する入退室管理システムや監視カメラ、等々、多種多様で、しかも多量です。したがって、コスト効率に優れた技術面の対策(多種多様かつ、多量のログを統合して一元管理するツールの導入など・・)が必要かと思います。

 5.20 パトロール(予兆の検知)
 発生したログの中から不正な兆候を示すログを検知し、その詳細を追跡します。そのために、不正なアクセスを含むセキュリティインシデントの特性を定義しておく必要があります。その定義には不正な兆候を判断する基準および不正が及ぼす影響レベルも含みます。検知した不正な兆候を示すアクセスをした利用者に対しては必要な是正措置を求めます。セキュリティインシデントと判定したアクセスは「インシデント管理プロセス」で現状の回復措置を、「問題管理プロセス」で恒久的な回避対策を実施します。

たとえば、不正な兆候を示すアクセスとして
* 権限外のアクセス
* 未許可の外部媒体へのデータコピー
* 深夜・早朝時間帯に集中するアクセス
* 臨時貸与の特権ユーザーのオペレーション
* 特定データベースへのアクセス状況
* 状況の不整合の検出
・・・ 等々、適用する組織の状況を考慮して定義します。
 5.30 ログの検索(調査)
 「インシデント管理プロセス」および「問題管理プロセス」の原因調査・分析のための調査は、そのプロセスに含みます。この要素業務は次の2つの作業を行います。
1つは、当該のアクセス管理プロセスの信頼性テストです。たとえば「削除申請されたアカウントが正しく削除されているか」とか、「削除した筈のアカウントが使用されないか」、「交付した初期パスワードが更新されているか」等々、サンプリングデータを用いてプロセスの信頼に関わる要件をテストします。
もう1つは、後続の要素業務「5.50 管理レポートの作成」に必要なデータを定期的に検索して出力します。

 5.40 ログの解析
 テストの結果、および管理レポートの仕様に基づくデータの解析を行います。不具合があれば、その不具合を改善するためのアクションプランを策定します。

 5.50 管理レポートの作成
 管理レポートを作成し管理者およびIT部門を統括するマネージャーに提出します。管理レポートには上述の「不具合を改善するためのアクションプラン」も含みます。

 5.60 マネジメントレビュー
 IT部門を統括するマネージャーは、報告された管理レポートを確認し、当該の情報セキュリティに関わるアクセス管理が、適切に実施されていることを検証します。必要であれば、組織化されているIS(情報セキュリティ)委員会に検討を含む改善の指示をします。(IS委員会は、「第2回、内部統制強化のための活動計画を策定する」の「1.実行のための組織、体制図の作成」で述べている組織です。)

 
次回は、「 重点対応プロセスの参照モデル 《 その2 .変更管理プロセス 》 」と題して、当該の活動において選定した「重点対応プロセス(重点的に再構築するプロセス)」の一つ、「変更管理プロセス」を参照のモデルとして紹介します。
IFRS/J-SOX
IT運用の内部統制/J-SOX適用

内部統制の強化という観点から、企業の活動をその仕組みとして支えるIT運用のあり方が今、注目されています。そこで、「IT運用の内部統制」/J-SOX適用と題して、J-SOXへの対応を契機とするIT運用プロセスの改善活動(ひとつのモデル)を紹介します。

記事一覧へ
筆者紹介

ITC横浜 ITコーディネータ  田坂孝志

  • 新着Q&A
  • 最新の回答
回答数:22019年11月12日

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

毎年恒例となった「システム管理者の会」の年に一度の大イベントとなる「システム管理者感謝の日イベント」の模様をお届けします。 今年のテーマは、「集まれ若いチカラ!システム管理者のための夏期講習!!」です。

個人情報保護方針
運営者につい て
利用規約
サイトマップ