ID管理における “成熟度モデル” の例
この章では、ID管理における成熟度モデルについてを紹介します。 自社の中長期的な事業計画の実行において、IT部門として欠かせないのが情報セキュリティ対策です。
なぜ今 “ID管理” が求められている?
情報セキュリティ対策の中でも、ID管理は近年重要なファクターとなっています。 なぜ、ID管理が重要になってきているのでしょうか。
近年、業務で利用するITサービスに、クラウドサービスを利用するケースが急速に増加しています。 特に、働き方改革に牽引されて導入の広がるテレワーク(リモートワーク)などでは、もはやクラウドなしでは実現不可能とも言えるでしょう。
ID管理やアクセス権限管理は、個人情報保護法や、通称J-SOX法と呼ばれる内部統制の一環で、大企業を中心に重要性は認識されています。 特に2000年台後半には、この対応に合わせてID管理システムや統合認証基盤が多くの企業に導入されたことでしょう。
ただ、セキュリティの側面では、IDよりネットワークが砦として使われていました。 当時は業務システムは社内に構築されていることが大半であったため、この頃のID管理は、境界(社内/社外)によって保護された信頼できるネットワーク内を前提として設計・構築されていました。 業務システムが企業のネットワーク内のみで完結しているため、社内ネットワークに接続できる端末を限定し、端末や情報を外に出さないことでセキュリティを確保していれば、情報は守られました。
ところが、クラウドの時代においては、データはインターネットの上を流通し、どこのサーバーに保存されるかはっきりとわからない状況となってしまいました。 クラウドサービスを業務で利用するメリットとして、インターネットがつながればどこにいても業務ができるということが挙げられますが、言い換えれば信頼できないユーザーやデバイスからもアクセスできてしまうリスクがある、ということになります。 そこで今再び、各クラウドサービスを利用する “ユーザーアカウント(ID)” に注目が集まっています。 信頼できないユーザーやデバイスからのアクセスも行われうることを前提としたセキュリティの設計として、より厳密なID管理と、IDを用いた情報へのアクセス管理の実現が必要だからです。 “ID” がないと、各サービスにアクセスすることもできないですし、アカウントごとの権限管理を適切に行うことで、アカウントが漏れたときのリスク管理も行えるようになります。 つまり、この “ID” を守ることで、企業の重要な資産である “情報” を守ることができるのです。 このようなセキュリティの考え方を、ID-Based Security と呼んだりもしています。
クラウドサービスが業務に欠かせなくなり、社員のアカウントさえクラウドサービスで管理する時代になりつつあります。 内部統制の観点だけではなく、情報セキュリティの観点からも重要ということとなり、より一層ID管理の重要性が高まっているのです。
ところで、ID管理をはじめとする、企業の情報セキュリティ対策は、自身の置かれている現状が満たせている現状の把握と、対策内容を定期的に見直し、継続的に改善を行う(PDCAのサイクルを回す)ことが非常に重要です。 このうち、自身の置かれてる現状を把握し、理想的な水準に向けて行うべきことを示す足がかりとして用いることができるのが、成熟度モデルと呼ばれるものです。
成熟度モデルとは
成熟度モデルというのは、組織のプロセス管理を最適化するための指針を体系化したものです。 有名なものとして、アメリカの情報システムコントロール協会(ISACA)と、日本のITガバナンス協会(ITGI)が提唱しているCOBITなどがあります。 日本でも、J-SOX法施行時の “内部統制成熟度モデル” などで馴染みのある方も多いのではないでしょうか。
成熟度モデルは、下記のような状態を指す大きく0〜5の6段階のレベルに分けます。
- 0.存在しない
- プロセスが存在していないか、問題があることに気づいていない状態
- 1.初期
- 作業工程が非公式で、プロセスが標準化されていない
- 場当たり的な手法を用いて実施される
- 2.反復可能
- 作業担当者が、毎回同様の手順で実施している(プロセスは存在する)
- 作業者個人の経験への依存度が高く、伝達の過程で誤りが生じやすい
- 3.定義済み
- 手順が標準化・文章化されている
- 作業はチェックされていないため、手順に従っているとは限らない
- 4.管理可能
- 作業手順がモニタリングされていて、問題点を検出できる
- プロセスが定期的に改良されている
- 部分的に自動化や管理ツールが利用されている
- 5.最適化
- プロセスはベストプラクティスの域に達している
- 作業が自動化されていて、品質が高い
- 管理者が一貫して実行している
特に、4や5の域に一度達したときに、時代の変化(クラウド対応など)に合わせて改善を続けていくことがポイントです。
セキュリティ管理基準は、一般的なものを参考にしつつ、組織体ごとのリスク評価結果に基づいて作成する事が多いです。 現在の自社に求められているセキュリティ対策の水準を確認しながら、自分たちがいまどの段階にいて、次の段階に進むためには何をしなければならないかを、把握しなければなりません。 先程上げた成熟度モデルを使うことで、理想像と現実のギャップや、次のステップに進むために求められる要件が見えてくるのではないでしょうか。
ID管理における成熟度モデルの例
最後に、ID管理における成熟度モデルの例を示してみます。 このモデルは、情報システム部門に多くのリソースを割けない(”一人情シス” のような)規模の会社をイメージして作成してみました。 これを参考にしながら、自社に求められているセキュリティ対策水準に照らし合わせながら、理想像を描いてみてはいかがでしょうか?
ID管理の成熟度モデル例
成熟度の段階 | 状態の説明 |
---|---|
1.初期状態 | 権限のある人が、各システムのIDを場当たり的に作成している |
2.反復可能 | 人事から名簿を受け取って、ローカルのExcelで管理している |
各システムにおいて、手動でアカウントを作成している | |
3.制度化済 | 人事と名簿を受け渡すフォーマットが定まっている |
アカウントの作り方が手順としてまとまっている | |
導入するシステムへの要求がまとまっている | |
4.定量管理 | アカウントの作成プロセスが可視化されている |
年に1回以上、プロセスのチェックや改善プロセスが回っている | |
5.最適達成 | 人事システムが更新されたら、ID基盤のアカウントが自動的に作成・変更される |
業務システムが増えたときも、所定の作業を行うことでプロビジョニングが出来る |
ID連携の成熟度モデル例
成熟度の段階 | 状態の説明 |
---|---|
1.初期状態 | ID連携している業務システムと、ID連携していない業務システムが混在している |
ID連携の設定が場当たり的に実施されている | |
2.反復可能 | ID連携の設定方法を理解している人が、ID連携の設定をしている |
3.制度化済 | 導入するシステムはID連携機能を備えるように要求できている |
ID基盤側のID連携の設定方法がドキュメント化されて、誰でも実施できる | |
4.定量管理 | ID連携の設定が構成管理されている |
どの業務システムがID連携できているか管理されている | |
ID連携の設定内容や対象システムについて、年1回以上見直しが行われている | |
5.最適達成 | ID連携の設定が自動的に設定できる |
業務システムが増えたときも、所定の作業により速やかにID連携が行われる |