日本版SOX法・徹底解析

時代とともに変化する「ID管理をシステム化すべき理由」。ITでいま最も求められるポイントを、ID管理システムでどうクリアすべきかを解説する（編集部）

　第1回「“ID管理システム化プロジェクト”のその後」ではID／アクセス管理のシステム化に取り組んだ企業の“その後”を振り返ってみた。第2回からは、ID／アクセス管理のシステム化プロジェクトについて、そのポイントを見ていきたい。

http://www.atmarkit.co.jp/fsecurity/rensai/idmanagement02/idmanagement01.html

　ID管理プロジェクトの目的は何か

　ID／アクセス管理のシステム化も、そのほかのシステム化プロジェクトと同様に、何らかの目的があり、プロジェクトがスタートする。ではID／アクセス管理のシステム化には、どのような目的があるのだろうか。まずは、システム化プロジェクトの準備編として、その目的について考えてみたい。

　多くのシステム化プロジェクトは、競争激化、好況／不況、法整備など、企業を取り巻く環境の変化に応じて行われる。そのような環境変化に自社の実態を照らし合わせて、各種業務のシステム化プロジェクトは進められる。これはID／アクセス管理も同様である。

　企業を取り巻く環境の変化

　筆者の企業がID管理システムを販売開始した2004年ころより、多くの企業のID管理システム化を支援させていただいた。その経験から、ID／アクセス管理のシステム化の目的が、下表のように時代とともに移り変わってきているのを感じている。

年代 テーマ

ID管理黎明（れいめい）期 2000年前後 IT運用管理工数削減のためのID管理システム化

個人情報保護法対応期 2004年ころ 情報漏えい対策としてのID管理システム化

J-SOX対策期 2006年ころ アクセス管理の前提としてのID管理システム化

金融危機＋アフターJ-SOX期 2008年秋以降 コスト削減・業務効率化のためのID管理システム化

　2000年前後には、ID管理は情報システム部門の省力化を支援するものとして期待されていた。とくに従業員1000人前後の企業で、情報システム部門でインフラからアプリケーションまですべての企業内ITの運用管理を行っていた企業での事例が多かった。振り返ってみると、「1000人前後」という規模がポイントであった。1000人を超える企業の情報システム部門では、ネットワークやメールなど全社インフラ的なITの管理のみを行っていた。そして業務アプリケーションは、それぞれの主幹部門で運用を行うケースが多かった。つまり大企業においてはむしろID／アクセス管理の工数は分散しており、問題は顕在化していなかった。

　当時、さまざまな業務改善、効率化、OA化の一環で、企業内にはさまざまなITが導入され、現場の業務効率化が進んだ。その一方で情報システム部門の管理工数が大きくなっていたことが問題としてクローズアップされていた。企業はビジネスを拡大すると同時に従業員数も増加する傾向にある。従業員の追加雇用においては非正社員（派遣、委託、パートなど）の割合も増え、それら複雑な雇用形態もID／アクセス管理の課題を大きくしていた。

　情報システム部門は、日々のIT運用できゅうきゅうとし、本来の使命である企業にとっての戦略的IT化に手が回らなくなり始めていた。そのようななか、情報システム部門の業務を省力化するものとしてID管理が注目を集め始めたといえる。

　その後、通信業界などで発生した大量の顧客個人情報漏えい事件が社会的な問題となった。とくに「グループID（共有ID）」を使用した情報漏えい事件や個人情報保護法の施行などを受け、情報漏えい対策、セキュリティ強化を支援するものとしてID管理が注目を集める。1人1IDを徹底することで、ログなどと併せて事件発生時の追跡を可能にする、不正行為への抑止力を発揮するという目的である。

　時代とともに移り変わる「ID管理システムが必要な理由」

　一方、1人1IDを徹底するには大きな労力が必要だ。結果、この労力を低減するためにID管理をシステム化しようという動きが出てきた。現場はIDの発行についてはタイムリーな発行を要求してくるが、IDの削除についてはタイムリーに削除を連絡してくることはまずない。そのため、前回触れたような幽霊ID問題が起こりがちである。このような問題を回避することもID管理システム化の目的の1つであった。

　そして、米国発のSOX法を基にしたJ-SOXが施行されるのを受け、内部統制強化としてアクセス管理とその前提としてのID管理が必要となった。このとき「必要な人に必要なだけの権限を与える」「権限付与の承認記録を管理する」「定期的な棚卸しなどを実施し、必要以上の権限が与えられていないことを確認する」という業務が必要となった。

　それまでも現場には運用管理コストの低減というニーズがあったなかで、さらにトップダウンで内部統制強化というニーズも出てきたため、このタイミングでシステム化を推進した企業が最も多いのではないだろうか。

　さらに2008年秋以降は、（これもまた）米国発の金融危機を受け、企業内のITコストの見直し、とくにIT運用コストの削減ニーズを受けて、ID管理システム化の機運がさらに高まるようになった。2009年に入ってからは、J-SOX初年度は「なんとか人海作業で乗り切れそうだが、来年以降もこれを続けるとなると……」といった企業から、J-SOX監査における工数削減を検討し始める声も聞こえてきた。

　このようにID／アクセス管理のシステム化の動機、目的は、時代とともに移り変わり、また、企業により優先順位はさまざまではあるものの、「セキュリティ強化」「内部統制強化」「コスト削減」が、その三本柱であることは変わらない。また、この3点が互いに矛盾したり打ち消しあったりすることなく、同時に並び立つのもID／アクセス管理システム化の特徴である。

　例えば、セキュリティ強化の一環で、情報漏えい対策に取り組み、クライアントPCのハードディスク暗号化、USBデバイス制御ツールを展開する場合、セキュリティは強化されるが、ユーザー、管理者とも運用管理コストが上昇する。一方、ID／アクセス管理については、1人1IDの徹底などセキュリティの強化、基盤づくりが進むものの、運用管理に掛かるコスト低減も期待できる。

　これからID管理に取り組むのであれば、読者の企業を取り巻く環境と経営ニーズをかんがみ、何を主要テーマに取り組むべきかを検討いただきたい。

ID管理業務のコストとリスクを把握する

　ID／アクセス管理に限らず、すべてのシステム化プロジェクトは、その費用対効果を確認する必要がある。ID管理においては、発生した1つの変更をどれだけのシステムに反映するかという処理件数が、そのコストに直結する。

　例えば中途採用で社員を1人採用したらどれだけのシステムにIDを登録するのか、人事異動があるとどれだけのシステムの権限を変更しなければならないのかといった点で、ID／アクセス管理の工数が見えてくる。ID管理業務の費用対効果については、JNSA（日本情報セキュリティ協会）などが、ID管理業務にかかるコスト試算のガイドラインを提示しているのでそちらも参考にしていただきたい。

【参考】

JNSAの資料『内部統制におけるアイデンティティ管理解説書』

http://www.jnsa.org/result/2007/pol/idm/index.html

　ID改廃作業が、システムごとに異なるルールで実施されているケースは珍しくない。例えばAシステムではあらかじめ定めたルールにより利用者を定義し、ルールに該当しない従業員は申請により、その利用可否を決定している。しかしBシステムではルールがなく、電子メールや電話などでオンデマンドで受け付け、改廃作業を行っているというようなケースである。また「○○さんと同じアクセス権限を付与してほしい」というあいまいな依頼もある。このような問い合わせ、依頼対応などの作業コストも軽視できない。

　さらに、情報セキュリティの点で、もしID改廃が遅れたら、もしID改廃に間違いがあり不適切な権限状態になったら、といったリスクを勘案する必要もある。

　コストを計る――大きな繁閑の差をどう考えるか

　ここで、ある企業のID管理業務の実態を、その処理件数という観点で見てみたい。

グラフ1　ある企業のID更新数の月別推移

　これは、横軸に年月を、縦軸にID改廃数を置いた2008年1月から同12月までの1年間の総ID改廃処理件数である。従業員規模は約2000人弱、システム部門で管理するシステム数は数十といった企業の実績値である。

　ご覧いただくと分かるとおり、少ない月でも総処理件数は数千件、多い月であれば数万件にのぼる。この処理件数の多さ以上に、繁閑の差が非常に大きくなっていることが分かる。

　これはID管理業務の特徴であり、多少の高低差、時期の差はあれ、多くの企業が同じ傾向にある。期初には定期入社や大きな組織変更、人事異動があり、四半期ごとに組織や人事の見直しがあるような場合、IDの改廃数はグラフ1のようになる。このように大きな繁閑が発生しているのがID管理業務のコストである。

　また、「IDの改廃数」＝「ID管理にかかるコスト」ととらえがちであるが、そのほかにも各種業務システムの組織マスタなど、所属部署に関する情報があればそのメンテナンスも必要になる。加えて承認権限、特権の付与や変更といったアクセス権設定コスト、パスワード忘れなどのユーザー問い合わせに対するコストなども考えておくべきである。まずは、自社のID管理業務が、各月でどれくらいの件数を処理し、どう推移しているのかを調査することで、おおよそのコストは明確になるだろう。

　次に、日々の業務の中でID、パスワードにまつわるユーザーからの問い合わせがどれくらい発生しているのか、「○○システムを使用したいのだけれどどうすればよいのか」といったユーザーサポートがどれくらい発生しているのかといったところを見ることで、コストの全体像がつかめてくる。

　特に大きな企業の場合、情報システム部門ではネットワークやメールなど全社インフラのみを運用管理し、各種の業務システムは各部門にその運用管理を任せているケースが多い。そのような部門管理のシステムについても、情報セキュリティ、内部統制、あるいはコスト削減効果の観点から重要かつ効果が大きいと判断される場合、このような部門管理のシステムも含めて調査を行う必要がある。逆に頻度や重要度の低いシステムについては、まずは考慮から外し、将来の取り組み課題としてもよいだろう。

　例えば、基幹システムの代表的なパッケージであるSAPのパッケージを使用している場合、SAP上にさまざまなロールを定義し、その承認権限などを付与している企業が多い。ある従業員がこのロールに属することの承認記録や、ある従業員に対して必要以上の権限がないことを確認することは、内部統制上、非常に重要である。米国でもSOX初年度において、SAPなど基幹システムの承認権限や特権が、経理部門の全従業員に付与されていたというケースが内部統制上の不備として複数社から報告されていた。

　情報漏えい対策としてのID管理システム

　一方、情報漏えい対策という観点では、顧客情報や技術情報のデータベースなどへのアクセス権限の1人1IDが徹底されているとともに、業務上必要な従業員にのみ限定されているべきである（技術部門から営業部門に異動した従業員は、技術情報データベースにアクセスできるべきではない、など）。

　こういった機密情報を管理するシステムのID改廃は、たとえそれが部門管理のシステムであったとしても、できるだけ人手を介さずに、そしてタイムリーに改廃が行われるように、全社で実施するID管理・アクセス管理システムの管理対象とすべきである。

　また、電子申請などワークフローシステムも、ID改廃作業や組織変更の反映作業が大きな負担となるシステムである。各種の申請には必ず決裁経路が決まっており、日本の企業においては、決裁経路は必ず組織や役職が登場する（金額○○万円以上の支払いは、所属事業部の事業部長以上の承認後、経理部門の確認が必要、など）。このような組織や役職が頻繁に登場するワークフローシステムについて、そのマスタメンテナンスを迅速に行えなければ、マスタメンテナンスが終了するまで業務が止まってしまう。もっと悪いケースでは、あらかじめ決められた決裁経路を回覧されず（旧組織、旧役職のまま）、さまざまな業務処理が業務ルールを逸脱して行われてしまうことになる。

　ID管理をシステム化していない企業においては、このマスタメンテナンスは人事異動や組織変更の都度、大きなコストとなって現れているはずである。

ID管理システムのリスクを測る

　ID管理業務のリスクには、手作業による漏れ、遅れ、誤り、不適切な権限設定による情報漏えい、データ改ざんなどが挙げられる。

　ID／アクセス管理業務を手作業で遂行する場合、厳重なチェック体制を設けたとしても、どうしても人間のやることには漏れや誤りが発生する。このようなミスがなくとも、キャパシティを超えるデータ量に対する作業の遅れも避けたい事項である。

　加えて、ここでもまた、ID管理業務の繁閑の差がリスクの温床となっている。

　ID管理のように繁閑の差が大きな業務においては、要員計画が大変難しい。仮に、先のグラフ１で表した企業が、8000件／月の処理件数をさばくことのできる要員、体制を保持したとしよう（グラフの破線）。この企業では、1月、2月には無駄が発生する一方で、3月から6月にはキャパシティオーバーによるミスのリスクがある。さらに、異動や変更の発令が1日や15日などに決まっているような場合、ID改廃業務はそれぞれ前月最終稼働日や14日に集中し、さらにその危険性は高まる。このように特定の時期に集中する業務については、その平準化やピーク時の作業の省力化がなければ、現実的には堅実な作業は不可能だろう。

　また、ID改廃業務は特定メンバーで実施しているケースが多く、属人化する傾向にある。繁閑の差が激しいことも起因しているかもしれないが、複数メンバーにてシェアされているケースはまれである。そのため、担当メンバーの負荷は集中しかつブラックボックス化し、担当者しか改廃作業が行えない状態となっているのである。

　こういったことに対しては、システムによる省力化および見える化を図ることが適切であることは、いうまでもない。

　「自社の経営課題とID管理システム化プロジェクトの目的もリンクした。自社におけるID管理業務のコストが見えてきた。自分たちの要員キャパシティも分かっている。キャパシティを超える作業に関するリスクもある」ということになると、いよいよシステム化の計画に着手することになる。ここではシステム化のパートナーであるベンダ選定までを解説しよう。

　必要なのは「企業文化や業務内容に詳しいパートナー」

　ID管理のシステム化プロジェクトは、そのほかのシステム化プロジェクトと異なり、多分に人間系の判断を要求されるプロジェクトである。詳細については次回以降触れたいと思うが、（単価×数量）＋（単価×数量）＋…＝合計金額というような、四則演算に単純化できないケースや、正しいデータであってもそのまま転用できないケースがある。

　また、ID管理・アクセス管理にまつわる企業ポリシーというものは、各社の企業文化、風土の影響を大きく受ける。例えば異動に伴う権限変更について、発令と同時に必ず権限を変更しなければならない企業（金融業などに多い）もあれば、一定期間は業務引き継ぎ期間として重複した権限を持つべきとする企業もある。つまり、ID管理・アクセス管理は、受発注や在庫管理などのように、各社で同じような業務を行っているというものではない。

　この点からも、ID管理のシステム化を行う場合のパートナーであるベンダ、システムインテグレータの選定には十分な注意が必要である。自社の業務要件を確認しながら、それをそのままシステムに落としていくのではなく、「ある会社さんではこのように運用されていましたよ。貴社の場合もこうしたらよいのではないですか」という提案ができる、豊富なID管理システム化の経験を有するベンダを選ぶ必要がある。

　ID管理のシステム化を行うタイミングで、従来の運用を見直し新たなルールを定めるケースが多い。現運用をシステム化するだけではなく、業務を改善改良できる機会でもあるので、そのような提案もベンダには期待したい。

　またRFPなどを作成し、ベンダ各社に提案依頼をかける場合、当然各ベンダは自社製品を前提とした提案を行ってくるだろう。この場合、その製品には各社のID管理に関する考え方やコンセプトが反映されている。カタログスペックや機能比較などの○×表ではなく、あなたの会社の考え方や取り組みの目的に即した製品を提案してきているのかどうかを判断する必要がある。

　次回は、ID管理システム化のプロジェクト遂行について触れてみたいと思う。