特権IDの適切な管理を行い内外のリスク要因に対して必要な対処を行うために、特権ID管理の専用システムを使用する選択肢があります。

専用のツールになりますので、正しいプロセス・要件のすり合わせを行い選択すれば、高い効果が得られます。しかし、残念ながら選定を失敗してしまい、システム自体が定着化せず結果としてほとんど効果が得られないケースも存在します。

こちらのコラムでは、弊社エンカレッジ・テクノロジがお客様の特権ID管理強化のご支援を行う中で比較的よく遭遇する失敗事例を通して、間違った選択をしないためのポイントをご紹介します。

特権ID管理システム導入は失敗しやすいプロジェクト？

特権ID管理は、セキュリティ対策の取り組みである一方、特権ID自体を日々運用担当者が業務で使用することから、業務への影響が大きいシステムです。

そのため、運用担当者に過剰な負担を強いたり、利便性を低下させてしまう場合には、反発を招く恐れがあります。また、特権ID「管理」の内容があいまいで、共通認識を持ちづらい点や、昨今のセキュリティ情勢を考慮したシステム仕様であるかどうかなど、必要な要件をしっかり盛り込まれていないことによる導入後の問題発覚などの事例もあります。

ここで、システムが定着しない結果に終わった事例から失敗の原因を探っていきたいと思います。

事例① ワークフローの二重作業で管理工数が倍増

製造業Ａ社では、外部監査の指摘により特権ID管理強化を実施。選定の結果、取引ベンダーから紹介を受けた比較的安価な特権ID管理システムを導入。

しかし、同梱されていたワークフローシステムは同社の要件を満たせないことが導入後に判明。

特権ID管理システムとは別にワークフローシステムを併用することで対応はできたものの、特権ID管理システムに同梱されているワークフローシステムを使用しない使い方ができないことから、作業の都度、二重のワークフローを用いなければならない状態となり、管理工数が倍増してしまった。

同社は正式採用前に、選定予定の特権ID管理システムにワークフロー機能が同梱されていることは確認していたものの、どの程度の機能があるのかまでは確認していなかった。

外部監査の指摘では、特権IDを使用する場合、システム部門の責任者と当該システムのオーナーであるユーザー部門の責任者に承認を得ることとされていたが、選定したワークフローシステムでは、単純な１段の承認には対応するものの、多段承認、ましてや同一の作業者であっても、操作する対象システムによって承認者を変えるといった設定ができないことが判明。

カスタマイズによる対応を要請したものの、大幅な費用が掛かることが判明、要件を満たす別のワークフローシステムとの連携も難しいということで、二重の申請書起票を余儀なくされている状態に...。

事例② 運用担当部門からの猛反発でほぼ利用されない状態に

情報通信業Ｂ社では、自社が納めたシステムの運用代行を、アウトソーシング事業部にて実施している。同社のサービス企画部門では、自社サービスのサービスレベル向上のため、お客様システムへの特権IDを用いたアクセスに対する統制レベルの向上を検討することになり、同業他社で使用している特権ID管理システムを選定し導入することになった。

導入に先立って、アウトソーシング事業部に特権ID管理システムの説明を行い、導入によって変更になる運用業務についてのすり合わせを実施。結果、選定した特権ID管理システムを導入すると今行っている運用代行業務に大きな支障が生じてしまうことが判明した。

選定した特権ID管理システムでは、お客様システムに特権アクセスする際、ブラウザを用いる必要があり、これまで使用していたシステム管理用の専用ツールが使えなくなってしまう。アウトソーシング事業部では、運用業務を効率化するため、マクロによる自動作業など、専用ツールの機能を最大限駆使していた。

事業部長レベルでの協議を行った結果、アウトソーシング事業部としては特権ID管理ツールを使用することで、業務効率が大きく下がることが許容できないとして導入を断念することになり、プロジェクトは頓挫した。

事例③ 一部システムが手作業のまま取り残される結果に

ITを活用して個人消費者にさまざまなサービスを提供するサービス業C社は、自社サービスの提供基盤であるクラウド上のシステムのサイバーセキュリティリスクを低減する目的で特権ID管理を強化することに。自社で独自の選定した結果、海外ベンダーが提供する特権ID管理システムを導入することになった。

同社は、自社サービスをIaaS、SaaS、PaaSなどさまざまなクラウドサービスを組み合わせて提供しており、選定した海外製の特権ID管理システムは、管理できるシステムのバリエーションが充実しており、同社が利用しているクラウドサービスも管理対象として資料に明記されていた点が選定の大きな理由であった。

しかし、導入を進める際に、一部のシステムに対する必要機能が提供されていないことが判明。選定時に確認した資料には管理対象にできるシステムの一覧に同社が管理したいシステムが含まれていたものの、実際には、「管理」のレベルが均一ではなく、システムによって異なることが判明した。

同社の特権ID管理の目的は、サイバーセキュリティリスクの低減であったことから、不審なアクセスの有無を早期に把握できるよう、ログ検査の仕組みが最も重要な要件であったが、同社が選定した特権ID管理システムでは、ログ検査ができるシステムはOSなど管理対象システムの中の一部に過ぎなかった。

同社では、対象にできないシステムのログの収集と点検を一部マニュアル作業による方法も組み合わせて実施しなければならない結果となった。

事例④ 特権ID管理システムがシステムの脆弱性を増長？

同業他社でマルウェア感染被害を招いたインシデントを受け、対策強化の一環で特権ID管理の強化を行うことになった大手流通業D社は、自社と取引ベンダーによって策定した要件をもと、複数製品から導入実績の多い特権ID管理システムを選択し、無事導入し運用を開始していた。使い勝手も良く選定に誤りはなかったと担当者しても自負する思いだった。

ところが、導入から１年を経過し行われたセキュリティ診断によって、選定した特権ID管理システムが企業ネットワーク全体のセキュリティレベルを低下させ、マルウェア感染による機密性侵害のリスクがかえって高まっているという指摘を受け大きなショックを受けた。

セキュリティ診断の内容を参照すると以下のような点が指摘されていた。

1. 特権ID管理システムと対象システム間の通信が暗号化されておらず、ネットワーク盗聴によって特権IDのパスワードが奪われる可能性
2. 一部のシステムで特権ID管理システムの管理対象とするために、通常は推奨されないセキュリティ設定にせざるを得ない状況となっている
3. SSHやRDP、SMBなど、サイバー攻撃の入り口として狙われやすいサービスのポート変更に対応していないためブルートフォースの攻撃を受けやすい状況となっている

選定の際、製品自体のセキュリティに関する非機能要件は選定基準に盛り込まれておらず、考慮点から漏れていた。しかし、セキュリティ対策製品である特権ID管理システムがまさかそんな仕様であることは信じられなかった。開発元に確認したところ、仕様としては指摘の通りであった。同製品は主に内部不正・内部統制を目的として導入されるケースが多く、今回指摘のあった点については他のユーザーでもほとんど課題視されていないということであった。

同社の導入目的はサイバーセキュリティ対策が主体であったため、やむなく選定した製品の使用を停止し、改めて選定をし直す羽目になった。

失敗事例から学ぶ選定の際のポイント

ご紹介した４つの失敗事例を踏まえ、具体的にどのような点を留意すべきだったか分かりましたか？それぞれの事例に基づき、選定の際のポイントを解説していきます。

(1) ワークフローは機能の有無だけではなく、必要な詳細機能が網羅されているか

ワークフローシステムが同梱されており、申請・承認ベースで特権IDの使用を許可する仕組みを有するものは多く存在します。

しかしながら、単にワークフローシステムの有無を確認しただけでは、本当にそのシステムが自社の運用に耐えうる仕様となっているか判断できません。組織や体制、職務分掌の内容、さらには申請件数、夜間や休日における緊急対応の有無などによって必要な要件が異なるため、詳細にわたり確認をする必要があります。

以下のような機能の有無について確認することがポイントです。

• 多段承認に対応するか？ 対象システムや業務内容によって同一作業者であっても異なる承認ルートを設定できるか？
• 申請内容に誤りがあった際に却下とせず、引き戻し・差し戻しによる再申請が可能か？
• 申請時に記載すべき項目の追加など申請様式のカスタマイズは可能か？
• 夜間休日など承認者が不在の場合でも、特権IDが使用できるような緊急作業のフローは用意されているか？
• 多くの申請書を１件ずつ承認する手間を省略できる一括処理可能か？

(2) 運用業務の要件をしっかり確認し、特権ID管理システム導入による影響がないか

事例②でご紹介した通り、特権IDはシステム保守・運用業務で日々使用しているため、特権ID管理システムの導入により、運用担当者の業務に少なからず影響を及ぼします。
運用部門は立場上、業務の効率性やミス発生防止などに主眼が置かれているため、それらを損ねるような影響が懸念される場合には、協力を得られない可能性が高くなります。

セキュリティを推進し特権IDの管理強化を進めたい推進部門が、システム運用部門の協力を取り付けセキュリティ向上という当初の目的を果たすためには、導入前の時点から必要な部門間の調整を行っておくことが肝要となります。

以下のような点がすり合わせをすべきポイントです。

• 特権ID使用の際のツールの種類、変更によって生じる影響の有無
• 特権ID使用の際の申請・承認などのプロセスの現状
• 現状の管理作業における課題、解決したい問題など

導入する特権ID管理システムが、システム運用部門の現状にマッチしていること、さらには現場で抱えている課題を解決できる点などを見いだせれば、推進を後押ししてくれる可能性もあります。
例えば、部門内で申請を書類で行っているのが現状であれば、特権ID管理システムによってワークフローシステムを利用できるようになり、利便性の向上につながります。

複数のシステム運用部門を横断して特権IDシステムを適用する場合には、部門によって運用方法が異なるケースも存在します。手間にはなりますが、運用部門ごとに認識のすり合わせを行うことが必要です。

(3) 管理対象のシステムの「管理」レベルが要件と合致しているかどうか？

特権ID管理システムでは、管理対象として設定できるシステムについて資料などで明記されている場合が多いですが、この「管理」とは何ができれば管理できると言えるのかは開発元の解釈に依存するため、お客様との認識齟齬が起きやすいポイントです。

一般的には、以下のような制御・統制の一部またはすべてに対応できることを「管理できる」としている場合が多いです。しかし、対象システムすべてに同一の機能が提供されるわけではない点も留意する必要があります。例えばWindows Serverに対してはすべての機能を提供できる一方で、SaaSの特権は一部のみといったケースが存在します。

• 申請またはポリシーに基づくアクセス制御
• パスワード変更処理
• 操作内容の記録・ログ取得
• 不正アクセスの識別・発見

必須となる要件がある場合、対象とするシステムと提供機能のマトリクス表を準備して、管理対象としたいシステムに必要となる機能が提供されているかをしっかりと確認する必要があります。

(４) ゼロトラストを前提にした非機能要件をしっかりと定める

サイバーセキュリティ脅威が高まり、ファイアウォールで囲った内部ネットワークであっても安全である前提で考えてはいけない「ゼロトラストセキュリティ」が提唱されている今、内部ネットワーク内のシステムに対しても、必要なセキュリティ対策を講じる必要があります。特権ID管理システムの導入目的自体も、社内システムの特権IDを外部の攻撃者に奪われないようにするためでもあります。

そのため、特権ID管理システム自身のセキュリティに関する非機能要件もしっかりと確認することが肝要です。具体的には以下のような要件を確認しておく必要があります。

• 管理対象システムと管理サーバー間で行われる通信は暗号化に対応していること
• RDP・SSHなどポートスキャニングのターゲットにされやすいプロトコルは、ポート変更に対応できること
• SMBなどサイバー攻撃の際に悪用されやすいサービスは可能な限り使用しない仕様であること
• 内部で保持されている資格情報や操作記録データは強固なアルゴリズムで暗号化されていること
• リプレイ攻撃への対応を考慮した多要素認証に対応していること

かつて、サイバーセキュリティの脅威が今ほど高くなかった時代は社内ネットワークに所在して直接インターネットからアクセスすることが不可能なシステムは、それほどセキュリティ対策を講じる必要はないと考える企業も多い状況でした。パッチの適用を行っていなかったり、暗号化されていない通信を用いていたりしても問題ないと考えるケースが一定数存在していたわけです。

そのため、社内ネットワーク内で使用するシステムのセキュリティに関する非機能要件もそれほど厳格なものを要件として定義されていないケースがあり、その時代の特権ID管理システムは、そのような背景の中で仕様が策定されている場合があります。

上述した通り、特権ID管理システムの中には、前世代型でゼロトラストを前提とした内部仕様になっていないものも存在しますので留意が必要です。