NRIグループの情報セキュリティ専門企業

鈴木悠太氏:NRIセキュアテクノロジーズの鈴木と申します。私のセッションでは、「効果的な特権ID管理はアクセス制御から」というテーマで30分ほどお話しします。よろしくお願いいたします。

最初に弊社の紹介を簡単にさせていただいた後、特権ID管理が求められる背景や、ここ最近の要件変化についてお話しします。後半はソリューション導入の効果や、導入に向けた課題と解決策についてお話をさせていただきます。

最初に簡単に自己紹介させていただきます。私、NRIセキュアテクノロジーズの統制ソリューション事業部に所属しております、鈴木と申します。

担当業務は自社開発の特権ID管理製品の営業、企画、導入、プリセールスのマネジメントです。かれこれ特権ID管理の事業に5年以上関わっておりまして、日々お客さまの要件変化などのキャッチアップに努めております。

続いて弊社の紹介になります。弊社NRIセキュアテクノロジーズは、NRIグループにおける情報セキュリティの専門企業です。本社は大手町で、そのほかに横浜と北米に拠点があります。

社員数は600名を超えており、年々規模が拡大しています。弊社は、コンサルティング事業、DXセキュリティ事業、マネージドセキュリティサービス事業、ソフトウェア事業の4つのコア事業があり、これらの事業を横断的に支える研究開発の機能もございます。

ご提供しているソリューションは、コンサルティング、セキュリティ診断、マネージドセキュリティサービス、ソリューションセキュリティ教育と、幅広いメニューとなっており、お客さまの課題に合わせたご提案が可能です。

本日、私からお話しするソリューションは、オレンジ枠で囲っているソリューションです。続いて、特権ID管理が求められる背景についてお話させていただきます。

システムに大きな影響を与える「特権ID」の管理

まず「特権IDとは何か」について簡単に触れさせていただきます。特権IDは、システムの維持・管理のために用意された、システムに大きな影響を与える権限を持つIDです。Unix系ではroot、Windows系ではadministrator権限を持つアカウントが該当します。

特権IDは一つのIDを共有して使われることが多く、非常に高権限であるという特徴がございますので、しっかり管理しないと多大な損害をもたらす原因になりえます。

特権IDが求められる背景としては、大きくは各種監査や基準への対応と、セキュリティ課題への対応という二大テーマがございます。

各種監査や基準への対応に関しては、監査における特権ID管理の不備指摘への対応や、PCI DSS(クレジットカード業界の情報セキュリティ基準)、FISC(金融情報システムセンター)、J−SOX(内部統制報告制度)などの基準への対応といったお話になります。

セキュリティ課題の対応に関しては、外部脅威の観点ですと、マルウェア感染による特権ID奪取への対策ですとか、内部脅威の観点ですと、内部で権限を持った人が不正行為を働いたり、作業ミスをするといったことに対して、しっかり検知や抑止をしていくというお話になります。

各種監査や基準への対応の一例として、内部統制の観点でよく参照される『システム管理基準 追補版』においても、特権ID管理に関わる統制目標について複数記載がございます。

アクセス制御、パスワード管理、ネットワークアクセスの制御、OSのアクセス制御といった大項目に対して、主に赤字で記載しているところが特権ID管理に関わる部分です。

また、PCI DSSにおいても、特権ID管理に関連する要件が複数ございまして、12の要件のうち7、8、10が、主に特権ID管理に関わる部分になっています。

これ以外のガイドラインや基準でも特権IDに関する記載は多く、非常に注目されている要件となっています。

「特権ID」を悪用された場合のリスクと、近年見られる変化

セキュリティ課題への対応に関しては、例えば特権IDを悪用された場合には、サービスが停止したり、データの盗難・改ざん・破壊が発生したり、さらなる攻撃への踏み台として利用されるといったことが発生します。

こういったことが発生しますと、信用の失墜や対策の費用が必要になったり、場合によってはお客さまが離れていってしまう等、企業組織へのダメージにつながります。ですので、しっかりとした管理が必要になります。

続いて、ここ最近の要件変化についてお話をさせていただきます。お客さまのIT環境や、外部環境の変化に伴い、特権ID管理で考えるべき範囲も広がってきています。例えば、特権ID管理の管理対象機器の設置場所に関しても、今まではオンプレメインだったのが、最近はクラウド上の機器が拡大しています。

管理対象機器の種類に関しても、今まではWindows、Linux、ネットワーク機器などがメインだったのが、最近はAWSなどのクラウドサービスの特権ID管理も必要になってきています。

作業場所に関しても、(これまでは)現地作業が中心でしたが、最近はリモートでの作業が増えていたり、製品の導入目的も監査や基準への対応や、内部犯行抑止といったところから、サイバー攻撃による特権ID奪取の対策も視野に入ってきています。

最後に外部製品との連携についても、今までは統合ログ管理製品との連携ぐらいしかニーズはなかったのですが、最近はさまざまな製品との連携が求められるようになってきています。

こちらのスライドでは実際に現場でここ数年間で言われることが増えてきたキーワードをまとめています。例えばクラウド系ですと、クラウド上に特権ID管理の製品を導入したい、オンプレとクラウドの両方の機器を管理したい、AWSやAzure、Salesforceなどのクラウドサービスの特権IDを管理したい。場合によっては、クラウドサービス型の特権ID管理製品を導入したいというお話も増えてきています。

脅威検知系では、外部攻撃に対応するために意図しない特権IDの利用を検知したい、製品連携系のお話では、脆弱性の診断ツールや、ITSM(ITサービスマネジメント)のツールと連携したいといったお話も増えてきています。

また、リモートアクセス環境の整備に伴い、リモートからのアクセスを統制したいというお話も増えてきています。こういったキーワードは、5年ほど前にはあまりお客さまから言われることがなく、ここ最近増えてきている要件です。

「特権ID」を手動で管理するか、サービスで管理するか

ここで、最近の導入事例として、リモートメンテナンス環境のアクセス統制事例を1件ご紹介します。こちらの事例は、西日本にある病院で、リモートメンテナンス環境のアクセス統制を行うために、弊社の製品を導入いただいた事例です。

こちらの右上が導入前のイメージで、右下が導入後のイメージです。委託ベンダーさんがリモートアクセス作業をするにあたって、ルーターで都度、手動でオンオフの対応をされていましたので、その対応に非常に工数がかかっていました。

こういった運用のため、緊急時の対応が困難であったり、ログもしっかり取れていなかったという課題がありましたが、弊社の製品を導入いただいたことによって、きめ細やかなアクセス制御が実現でき、リモートメンテナンスの回線も1つに集約できました。また、システム化による工数削減や、ログ確認の効率化にもつながりました。

昨今のコロナ禍の状況や働き方改革の状況を踏まえましても、今後もこういったリモートメンテナンス環境のアクセス統制ニーズは増えてくると考えております。

続いてソリューション導入の効果と、代表的な制御方式についてお話しします。まず特権IDの管理方法としては、手運用による管理とソリューション利用による管理がございます。

コストとセキュリティの観点で比べた資料がこちらですが、まずコストの観点で見ると、ソリューションを利用した場合には、当然、その導入や維持の費用がかかります。

ただ一方で、手運用と比べると運用工数を大きく削減できますので、最終的にはソリューション費用と運用工数の削減費用の比較になってくるかなと思います。

セキュリティの観点ですと、導入前はいろいろな抜け漏れが発生しやすい状況がありますが、ソリューションを導入することによって作業のミスや漏れが発生しにくくなったり、不正行為の実施のハードルが非常に上がったりします。

また、インシデントが発生しても、迅速に対応できるといったメリットがあります。コストの観点で見ると、「運用工数をどれぐらい削減できたか」がキーになってきますが、セキュリティの観点で見ると、確実にセキュリティ強化に貢献できます。

手作業で特権IDを管理・運用する際の工数と課題

また、実際に特権IDの管理を手運用で対応しようとした場合には、いくつかの課題に直面します。こちらはあくまで一例ですが、利用者の特定や申請・承認とアクセス制御、特権IDのパスワード管理、ログ確認等について、いくつかの課題が出てきます。

まず、特権IDは共有して使われるという特徴があるため、何かあっても利用者の把握や特定ができないという課題があります。申請・承認とアクセス制御に関しては、ツールを使わない場合は、紙運用やExcel運用がベースになるため、運用工数が非常にかかるという課題があります。

また、ワークフロー単体の仕組みを持っていたとしても、申請・承認と利用の制御が紐づいていない場合には、ルール通りの運用を徹底できないといった課題もあります。

特権IDのパスワード管理に関しても、例えば利用を制御するために、手動でパスワードを都度変更するといった運用がありますが、その対応工数が多くかかったり、ユーザーさんに貸し出したパスワードが、その後他者に共有され使い回されるというリスクもあります。

最後、ログ確認に関しても、ログの保管場所がバラバラのため、確認するのが大変だったり、見るべきログを判断するための情報が何もないので、結局全件見ないとわからないといった課題が出てきます。

ID管理やパスワード更新、ログ確認の工数が約80%減

これらの課題が、特権ID管理製品を導入することによってすべて解決します。まず利用者の特定に関しては、特権ID管理製品の認証機能によって、しっかり個人の特定ができるようになります。

申請・承認に関しても、特権ID管理製品の標準機能でWF機能を持っていますので、システム化による工数の削減が可能です。また、ワークフローと利用の制御がしっかり紐づくようになりますので、ルール通りの運用ができます。

特権IDのパスワード管理に関しても、パスワード定期変更を製品機能で自動化したり、場合によっては定期変更の運用をなくすこともできるかなと思います。

パスワードの共有利用に関しても、隠蔽機能がございますので、ユーザーさんにパスワードを知られないように運用することもできます。ログ確認に関しましても、1つの場所にログが集約されていきますので、確認が容易になります。

また、各種検知機能やレポート機能もございますので、どのログを重点的に見るべきなのかも、しっかり判断できるようになります。

ここで、ソリューション導入によって、実際に工数を大きく削減できた事例を1件ご紹介します。こちらがお客さまの導入前と導入後のイメージです。

導入前は、IDの貸出管理を手運用でされており、内部で不要IDの削除漏れの指摘があったり、ログと申請の突き合わせ作業が追いつかないといった課題がありましたが、我々の製品を導入いただいたことによって、こちらのイメージの通り、シンプルな構成に変わりました。

結果的に、ID管理やパスワード更新、ログ確認の工数等が約78パーセント削減でき、業務が大きく効率化されました。これぐらい大きく運用工数を削減できますと、確実にかけた費用以上の回収があると言えるかなと思っております。

また、こちらのお客さまは、ソリューションを導入したことによって、セキュリティを強化できた事例です。

もともとはPCI DSSに準拠することがメインの目的でしたが、製品を導入したことによって、従業員のみなさまのセキュリティ意識が大きく向上し、セキュリティを強化できたというコメントをお客さまからいただいております。

特権ID管理における、3つの代表的な制御方式

ここで、特権ID管理製品とはどういった機能を持っているのかについて、簡単にお話させていただきます。主に予防的統制の観点の機能と発見的統制の機能がありますが、まず予防的統制に関しては、ID管理やワークフロー、アクセス制御の機能があります。

発見的統制の観点としては、ログの管理や監査支援の機能があります。これらはだいたいどの製品も持ち合わせている、コア機能となります。

続いて、特権ID管理製品の代表的な制御方式についてもお話したいと思います。代表的な制御方式としては、ゲートウェイ方式、エージェント方式、ID棚卸・貸出方式があります。

ゲートウェイ方式はこちらのイメージの通りで、接続元と接続先の間のポイントにゲートウェイサーバーを構築して、この部分で制御する方式です。

エージェント方式に関しては、接続元か接続先の機器にエージェントを入れて制御していく方式になります。

最後に、ID棚卸・貸出方式に関しては、IDを貸出管理するような専用システムを設けて、この部分で制御する方式となっております。

これらの方式を、システム導入、システム運用、アクセス制御、ログ取得の4つの観点で比較したのが、こちらのスライドになりますが、全般的にゲートウェイ方式がバランスがよく、考慮すべき点が少ないことがわかります。

まずゲートウェイ方式は、エージェントレスでシンプルな構成のため、システムの導入や運用が非常に容易です。また、ログの取得に関しても、ゲートウェイ部分で取得しますので、特にエージェントを入れずに対応することが可能です。ゲートウェイ方式で唯一考慮すべき点は、「ゲートウェイを迂回したアクセスをどうするのか」というところになります。

エージェントを入れる方式のメリットとしては、エージェントならではのきめ細かい制御ができるという点になりますが、導入前の影響調査に時間がかかったり、台数が多い場合には、バージョンアップやメンテナンスに時間がかかったり、エージェントを入れていない端末の制御が効かないという課題があります。

ID棚卸・貸出方式は、IDやパスワードを定期的に変更したいという要件にはマッチしやすいですが、その代わりの条件としてID・パスワードの棚卸が必須だったり、ログ取得に関しても、別の仕組みが必要になるという課題があります。

それぞれの方式の特徴と選び方のポイント

ゲートウェイ方式とID棚卸方式に関して、少し違いがイメージしづらいかと思いますので、こちらのスライドで補足をさせていただきます。

ゲートウェイ方式は、こちらの左上のイメージの通り、管理対象機器へのアクセスを制御する方式になりますので、管理対象機器のIDパスワードの管理は必須ではありません。

対して、ID棚卸と貸出方式は、アクセスを制御するために都度IDやパスワードを貸出管理するため、IDやパスワードの棚卸や管理が必須の方式になっております。

また、ゲートウェイ方式の場合、ID管理は必須ではないとお話させていただきましたが、IDとパスワードを管理して、ユーザーさんにパスワードを隠蔽して使わせたいというケースやパスワードを定期的に変更したいというニーズも当然あります。

そういった場合は②、③のようにパスワードを隠蔽したり、定期変更するという使い方も可能です。システムの重要度に応じて使い分けできます。

ゲートウェイ方式は、迂回アクセスが課題と先ほどお伝えしましたが、その対策としては、例えばネットワーク機器でゲートウェイ経由以外のアクセスはブロックしたり、サーバーサイドで制限を加えたり。パスワードを隠蔽することによって、実質裏口から入れないようにするという方法があります。

また、対象システムのログと定期的に突合することによって、裏口から入ってくるものがないかどうかを検出できるので、この課題に対しても十分対応が可能です。

「コスト・運用体制・導入タスク」の3つの壁の乗り越え方

最後に、ソリューション導入に向けた課題と解決策についてお話させていただきます。まずソリューション導入に向けた課題に関しては、お客さまによってそれぞれ課題感は違うとは思いますが、一般的にはコストの面、ヒトの面、あとは導入タスクのボリュームが大きな障壁になっていると感じております。

これらの課題を分解していきますと、コストに関しては特権ID管理製品のライセンスや保守費、それをインストールするためのハードやOS、クラスタソフトなどの費用、設計や導入費、運用の費用というものがあります。

例えば有償オプションなどは利用せず、基本ライセンスでできる範囲から始めることや、管理対象機器を重要システムのみに絞り込む、シングル構成で開始する、というような解決策があるかと思います。

ヒトに関しては申請・承認などの対応やこまめなログ確認、バージョンアップや拡張等の対応というようなハードルがありますが、このハードルについてもまずは申請・承認機能の利用はなしで、運用を開始する、重点的に見るべきログを絞っていく。加えて、バージョンアップが容易で拡張性の高い製品を選定する、といった解決策がございます。

導入に向けたタスクに関しては、現状の課題把握やあるべき姿の検討、製品選定、要件定義、設計、構築、設定作業などがあります。こちらに関しても、設計要素が少ない製品や導入ハードルが低い製品を採用したり、フェーズ分けして、まずは最低限の統制から始めていく、というアプローチもできますし、こういった作業が得意なベンダーさんに依頼するという解決策もあります。

また、導入や運用のハードルを下げるためのより具体的な方法をこちらのスライドにまとめていますが、ソリューションにいくつかのモデルがある場合は、まずエントリーモデルから開始する。ゲートウェイ型の製品を積極的に採用する、初期フェーズではIDパスワードの管理まではせず、特権アクセスの管理にフォーカスする。

認証に関しても、まずは2要素ではなくて、1要素認証で開始する、アクセス制御の範囲もまずは広い範囲でアクセスを制御する、踏み台サーバーを設置して、踏み台サーバーまでのアクセスを制御する、というようなアプローチがあります。

3段階でセキュリティレベルを上げていく方法

最初から100点を目指すのが難しい場合は、こういった柔軟なアプローチがおすすめです。まずは最低限のレベルから始めていって、フェーズ2・フェーズ3と、徐々にセキュリティレベルを上げていくというアプローチです。

例えばフェーズ2ではアクセス範囲を見直して、最小限のアクセス範囲に変えていったり、システムに関しても、重要システム以外の機器も徐々に管理対象に加えていったり。申請・承認機能の利用を開始したり、パスワードの隠蔽機能を開始するというアプローチがとれるかなと思います。

さらにフェーズ3では、認証を2要素認証に切り替えたり、クラウドサービスの特権IDも管理対象に加えたり、承認に関しても必要なものは多段階承認にしたり、パスワードの定期変更を実施したり、等のアプローチがとれますので、フェーズ分けして段階的にセキュリティレベルを上げていくというアプローチもおすすめしております。

こういったアプローチを、弊社の製品に当てはめると、フェーズ1では「Access Check Essential」というパッケージで対応が可能です。

フェーズ2に関しては「SecureCube Access Check」というパッケージで対応できます。

フェーズ3に関しても、「SecureCube Access Check」と一部の有償オプションを組み合わせることによって対応可能となっています。

権限に応じたアクセス管理も可能

弊社のソリューションを簡単にご紹介します。まず「SecureCube Access Check」は、特権ID管理に必要な機能をすべて備えたオールインワンの製品です。

左側が構成イメージになりますが、接続元、接続先の機器の間のポイントにゲートウェイサーバを構築して、この部分でアクセス制御やログの管理をしていく製品になります。実績に関してもITR(ビジネスとITに関する問題解決を提供する独立系IT調査・ コンサルティング会社)のレポートで、シェアナンバーワンの評価をいただいており、非常に多くの実績があります。

また「Access Check Essential」というパッケージは「SecureCube Access Check」の機能のうち、アクセス統制に不可欠なアクセス制御、ログ管理、監査補助の3つの機能に限定して、リーズナブルな価格でご提供するソリューションです。

こちらのスライドにそれぞれの比較をまとめていますが、先ほどお伝えした機能の限定に加えて、プロトコルやオプション機能の制限や、拡張性、ポリシー数の制限などが主な違いになります。導入メニューやサポート、ライセンス体系についても一部違いがあります。

アクセス制御の設定イメージに関しては、どちらのパッケージも同様の考え方で、ユーザーさんがいて接続先があって、それらをポリシーで紐づけるかたちで、アクセス制御を実現していきます。

例えば、こちらの例では社員用のポリシーは、本番系も開発系もアクセスが許可されていますが、協力会社さんのポリシーは開発系のみがアクセス可能なポリシーとなっています。このようなイメージで、権限に応じたアクセス管理が可能となっています。

ログに関しても、下のほうにアクセスログのイメージを貼り付けていますが、アクセスの概要をまとめたアクセスログと、実際の操作内容を記録した操作ログの2種類が取得可能です。

「SecureCube Access Check」の機能において、申請・承認の機能も使っている場合にはこういったかたちで申請がしっかり紐づきますので、どのログとどの申請が紐づいているかもしっかりと確認することが可能です。

特権IDの管理が重要視されている理由

また、先ほどフェーズ分けのお話をさせていただきましたが、「Access Check Essential」から「SecureCube Access Check」への移行もサポートしています。

一部新規構築は必要ですが、データなどの移行ができるので、まずは「Access Check Essential」から始めて、フェーズ2で「SecureCube Access Check」に移行するというアプローチが可能です。

また、これ以外にもAWS環境に特化したクラウドサービス型モデルの「Cloud Auditor by Access Check」というパッケージもございますので、お客さまのご要件に応じて、ご提案・ご選択が可能です。

また、前半でここ数年間で増えてきたキーワードをご紹介しましたが、こちらのスライドでそれぞれのキーワードにマッチしたソリューションをまとめています。お客さまの要件に応じて選択が可能となります。

本日のまとめとなります。まず、特権IDの管理は、各種監査や基準、セキュリティ課題への対応において、重要テーマとなっています。昨今のクラウドサービスの普及や外部脅威の高まりによって、特権ID管理に求められる要件も変化してきています。

当然、特権IDを手運用で管理することも可能ですが、工数がかかりセキュリティリスクも残ってしまうため、ソリューションの導入をおすすめしています。

ソリューションの導入には、コスト、人、導入タスクボリュームなどの課題はありますが、段階的にセキュリティレベルを上げていくアプローチを取ることで、初期導入時のハードルを大きく下げられます。

私のセッションは以上とさせていただきます。ご清聴ありがとうございました。