システム管理の操作者を特定することの重要性
システム管理者の操作は性質上、特権IDといわれる管理者権限を用いる必要があります。この管理者権限は、システムに対し、さまざまな変更を行ったり、データベースへの直接アクセスなど、情報に対して制限なくアクセスができたり、多くの権限を有します。そのため、特権IDの濫用がシステムトラブルや機密情報の漏えいなどの問題につながる可能性があります。
これまでも特権IDを使用したシステム管理者の不正や誤操作に起因する問題は発生しており、IT統制上、この特権IDの使用に対する統制は、重要な取り組みの一つです。
特権ID管理の原則は、
- 過剰な権限を付与しない
- 使用者が誰かを特定する
- 作業内容(操作内容)を記録し、濫用がなかったかを点検する
といった取り組みがあげられます。
つまり、システム管理における特権IDの使用者の特定は、権限濫用リスクへの対処のひとつとして重要です。
これまでのアプローチの課題
一般的にITシステムでは、IDとパスワードによって、特定のユーザーを識別します。システムは、利用するユーザーを識別すると、プロファイルを参照し、そのユーザーが使用できる権限に応じて機能やアクセス範囲を設定します。つまり、システムにおけるIDは、ユーザーの特定と、権限制御の両方に影響を与えることになります。
この考え方はシステムへのアクセスに対して有効な統制のように思われますが、実現場では以下のような理由により、支障が生じることがあります。
アカウントを切替えできない
24時間365日稼働させなければならない重要なシステムを維持するために、システム運用要員が交代で24時間365日、システム監視業務が行われているケース。
このような業務においては、一般的に同一の監視用端末を複数のオペレーターが、交代制で使用する形態をとっています。勤務交代の際に、端末のOSや監視用アプリケーションのユーザーをログオフし、新しいユーザーIDでログオンしなおすことは通常しません。アカウント切替え時にシステム監視ができなくなってしまうからです。
従って、このような環境では、共有でアカウントを使用する場合が多く、システム上、誰が実際の作業者であったかを特定することが困難となってしまう場合があります。
管理者権限が固定されている古いアプリケーション
古い設計で開発された一部のアプリケーションを利用しているケース。そうしたアプリケーションの一部では、現在のIT統制のような考え方に沿った設計開発がされておらず、特定のアカウントにのみ管理者権限を設定するような仕様になっている場合があります。
この場合、複数の管理者が存在しても、同一の管理者アカウントを使用せざるを得ず、作業者の特定が困難になります。
これを解決するためには、アプリケーションそのものを修正する必要があり、場合によっては多額の費用が発生することもあります。
個人に権限を割り当てると、権限管理がかえって煩雑になってしまう
大量のサーバーに対し、多くの作業者が交代で作業が行うケース。このような場合、対象の各サーバーに、作業するユーザーすべてに固有の特権IDを作成すると、管理対象のアカウント数そのものが膨大になってしまい、管理が煩雑になってしまいます。
例えば、150台のサーバーで構成されるシステムを約30人の保守担当者が作業を行う体制の場合、管理対象のアカウント数は4,500アカウントになります。
アカウントを集中管理できないの?
ディレクトリサービスを使用して、30名のアカウントを集中管理すればよいと思われるかもしれません。しかし、システム運用作業を行うアカウントの場合、個々のサーバーの特定のディレクトリに対する変更権限やサーバー管理機能に対する権限が必要なため、個々のサーバーローカルのアカウントを作成し、使用せざるを得ない場合が多いのです。
また、Active Directoryのドメイン管理者権限が良い例ですが、ディレクトリサービス上の管理者権限は、そこに属するコンピューター全体に対して管理者としての権限を持ってしまうため、統制上大きなリスクになってしまうデメリットも存在するのです。
ID Inspectorのコンセプト
ID Inspector(IDI)は以下のようなコンセプトによって、前項のような課題を解決します。
権限と作業者の特定を分離して別々に管理
OSやアプリケーションの認証とは別に、その時点の作業者を特定する「本人確認」だけを行う機能を提供することで、OSやアプリケーションで行う認証ロジックの仕様や運用上の仕組みで発生してしまう問題点を解決します。
- OS上の作業者をログオン、再ログオンすることなく特定
- 古い設計のアプリケーションを改修することなく、IT統制に対応
- 大勢の作業者の個別IDを作成し管理する煩雑さから解放
常に必要なタイミングで確認
OSやアプリケーションの認証は使用開始時に求められ、認証後は一定の手続きや時間が経過するまで、同一の認証下にあるとみなされる仕様になっています。
IDIは、ユーザー操作の内容を監視し、重要な情報へのアクセスや重要な業務を行う際、本人確認を行うよう設定することが可能です。これにより、重要な操作に対する注意喚起と、成り代わり防止を行うことで、よりセキュアなシステム管理環境を提供します。
活用シーンとシナリオ
上述したコンセプトにより、以下のようなシーンにおいて、特権IDの管理にかかわる課題を解決することが可能です。
24時間365日 交代でシステムの監視・運用
24時間365日の稼働を行う重要システムの監視・運用業務において、勤務交代時、操作端末やシステム管理アプリケーションのログオンユーザーを切り替えることなく、作業者の特定を可能にします。これにより、システム監視・運用業務を中断することなく、業務を継続しつつ、課題であった操作者の本人確認とそのトレーサリビティを高めることができます。
マルチベンダーによるシステム保守、運用のアウトソーシング
一般企業では多くの場合、システム保守・運用管理をSIerに委託していると思います。
本来であれば、委託先のスタッフである個人レベルまで作業者の特定を行う必要がありますが、委託先企業の個人アカウントを管理対象サーバーに作成して都度管理することは、セキュリティポリシー上、問題となる場合があります。
IDIを利用すれば、委託作業者向けの共有IDを使用しつつ、委託先作業者の個人を特定することができ、結果としてベンダーに委託したシステム保守・運用作業の作業者の特定を可能にします。
クレジットカード情報を扱う重要システムのセキュリティ基準への対応
機密情報を扱うシステムに対するアクセスは、情報の持ち出しリスクが非常に高いため、一般のシステム以上に認証システムを強固にする必要があります。たとえば、クレジットカード情報を扱うシステムに対するセキュリティ基準PCI DSSでは、カード情報へのアクセスの際、IDとパスワード以外の認証要素を加える二要素認証が必要であると定めています。
ところが、既存のシステムを二要素認証に対応させるためには、認証ロジックを修正するアプリケーションのカスタマイズが必要になり、費用面で大きな負担となる場合があります。
IDIは本人確認の方法として、ID/パスワード以外にFeliCaをはじめとするスマートカードにも対応しているため、既存のシステムをカスタマイズすることなく、疑似的に二要素認証を実現することで、このような基準に対応することが可能となります。