DX（デジタルトランスフォーメーション）時代に突入した今、特権ID管理に求められる要件はどうなるのでしょうか？数回に分けて解説してまいります。

DXで起きている特権ID管理の3つの変化

企業のITシステムに対するリスク対処の考えは、ITシステムに対する依存度、障害発生に伴う事業への影響度が増加するにつれ整備されてきましたが、IT統制が上場企業を中心に一気に浸透したきっかけは、2008年4月以降の会計報告から施行されたJSOX法でした。

財務諸表の正当性を担保するため、ITシステムに依存する財務会計業務においては、健全なシステム運用が損なわれないようシステムの開発・運用におけるルール整備や変更管理プロセスなどが整備されました。
IT統制の要とも言える特権ID管理も、対処すべきリスク要因の一つとして管理プロセスが整備されてきました。

それ以降、私たち企業は、様々な課題を解決するためにITシステムの適用分野を拡大させるとともに、ITシステムを取り巻く環境も大きく変化しています。

中でも以下の3つの変化が、特権ID管理の要件に対しても大きな影響を与えています。

（１）オンプレミスからクラウドへ

現在、基幹系を含む多くのシステムは、オンプレミスではなくクラウド上で稼働するようになりました。オンプレミスで稼働していたシステムを単純にクラウド上のIaaSにマイグレーションするといったものだけではなく、PaaSやSaaS、IaaSに開発した独自システムも組み合わせた形のシステムも増加しています。

（２）セキュリティ脅威の変化

標的型攻撃やランサムウェアなど、サイバーセキュリティの攻撃手法が劇的に巧妙化しています。攻撃の目的も、かつての愉快犯的な攻撃から政治目的、金銭目的など、より事業への影響が大きいものへと変化。システムのクラウド移行や、テレワーク・モバイルワークなどの働き方の多様化も相まって、境界線による防御が機能しない「ゼロトラストネットワーク」を前提にした対策が急務になっています。

（３）ITシステムのカバー範囲とシステムに求められる対応のスピード

DX（デジタルトランスフォーメーション）というキーワードにあるように、ITシステムはかつての基幹系を中心とした社内ユーザーのための社内システムには留まらず、ITシステムを使って直接サービスを顧客に提供する役割に変化する時代になりました。

DX時代では、ITシステムが提供する価値や品質がサービス品質に直結するため、顧客のニーズに対していかにスピーディーに対応できるかが商機を見出すための重要な要件になりました。

今回は、その中でクラウド移行によって変化する特権ID管理の要件について触れていきます。

クラウド移行が影響を与えた特権ID管理要件の変化とは

システムのクラウド移行が特権ID管理の要件にもたらした変化は、単に設置場所がオンプレミスからクラウド上に変化したことだけに留まりません。

リモートアクセスが基本的な考え方に

1点目の変化は、システムへの管理アクセスがリモートアクセス前提になりつつあるということです。

自社データセンター内に設置されているシステムの場合、データセンターに直接入り、サーバーに直接接続されているコンソールから操作ができます。企業によってはそれが基本的な管理アクセスの方法という場合もあります。
一方、クラウド上のシステムではリモートアクセスが前提になり物理的なアクセス制御は機能せず、論理制御が重要になります。論理制御の一つの方法がID管理になるわけです。

クラウド移行により、特権ID管理は、リモートからのアクセスを前提にした制御・許可の仕組みが重要となり、かつそれは物理制御の代替としての役割を担うため、より強固な制御によって不正アクセスを防止する必要性が高まっています。

アクセス元の限定が適切なアクセス制御の手段ではない

2つ目の変化は、アクセス元を限定することによる制御は、あまり適切な方法ではなくなってきたという点です。

前項にある通り、クラウドの場合リモートによる管理アクセスが大前提となる中、従来の考え方を踏襲し、アクセス元を社内ネットワークに限定するリスク低減の方法を取る発想は残念ながらクラウドのメリットを台無しにしてしまいます。
システムをクラウドに移行するメリットは、どこからでもアクセスが可能になるアクセシビリティの向上にあるためです。これは利用者アクセスに限らず、管理アクセスも同様です。例えば緊急時に管理者が外出先からでもアクセスできる方が、原因究明や復旧までの時間短縮に繋がります。外部ベンダーにシステム保守を委託する場合、わざわざ社内に来てもらう必要性もありません。

このように、クラウド上にあるシステムの管理アクセスの統制には、アクセス元を制限する考え方は適切ではありません。したがって、特権ID管理は不正アクセス／正常アクセスかの判別を「どこからのアクセスか」ではなく、「誰によるアクセスなのか」をより厳格に判別できる必要性が高まっていると言えます。

管理の対象がOS（オペレーティングシステム）からSaaSまで多様化

IaaS、PaaS、SaaSなど様々な形態を組み合わせて利用するシステムにおいて、特権ID管理は、何をどう管理すべきでしょうか？

オンプレミスの場合、特権ID管理は主にOSレベルの管理アクセスに対する制御を行うことが目的でした。
...それでは、PaaSやSaaSはOSなど基盤部分をお客様が管理すべき要素ではないため、特権IDは存在しない、すなわち管理は不要でしょうか？
いいえ、PaaSやSaaSにも管理者権限という考え方は存在し、その管理不備には一定のリスクがあります。したがって、OSの特権ID管理同様、一定の管理が必要になるわけです。

PaaSやSaaSの特権IDには以下のような課題・特徴があります。

一般IDと同じWebベースのアクセスであり、アクセス方法（プロトコル）などで一般IDと区分けができない

PaaSやSaaSの特権IDは、一般権限のIDと仕組みは同じで、利用できる範囲が異なるだけの違いになります。したがって、特権IDも一般IDも同じログイン画面からアクセスすることになります。つまり、ネットワーク的な制御によって特権IDのアクセスだけをコントロールすることが難しいといえます。

細かな権限付与を行えないサービスが比較的多い

PaaSやSaaSのサービスの中には、付与できる権限を細かく設定できず、管理者IDにはすべての権限が設定されてしまう仕様が多いのが現状です。例えば多くのSaaSでは、管理者アカウントには設定変更の権限に加え保存されているデータに対しても全件閲覧・編集する権限が付与されており、権限を分離させることができません。

つまり、システムのクラウド移行によって、特権ID管理に求められる要件として、OSアカウントだけではなく、OSとは異なった性質を持つPaaSやSaaSにも対応できる必要性が加わりました。

クラウドの管理者のアカウントが管理すべき要素として追加

クラウドにシステムが移行されることで、オンプレミスの環境には存在しなかったシステム上のレイヤーが発生し、そのレイヤーにおける特権IDがリスク要素として高く、管理の必要性が高まっています。

それが、IaaSの管理基盤のための特権IDです。例えば、パブリッククラウドのアマゾン ウェブ サービスの場合、AWSマネジメントコンソールを使って仮想マシンなどを設定します。そのため、AWSマネジドメントコンソールを操作するための管理アカウントは、システムに対して非常に影響度の高い権限を有していることになります。 IaaS上のシステムにおける特権ID管理において、IaaS管理基盤の特権ID管理は外すことができない要素になっています。

次回は、セキュリティ脅威編です。

次回のコラムはこちらから⇒ 「DXがもたらした特権ID管理の3つの変化　～セキュリティ脅威編～」