侵入前提型防御も重要な今、なぜ「特権アクセス保護」（PAM：Privilege Access Management）が必要なのか：ゼロトラスト時代の特権IDの守り方（1）

古くて新しい「特権アクセス保護」（PAM：Privilege Access Management）について技術的内容を分かりやすく解説する連載。初回は、そもそも「特権」とは何か、特権の持つ特徴リスク、抱える課題などについて整理する。

[金子和孝，CyberArk Software]

　本連載「ゼロトラスト時代の特権IDの守り方」では、古くて新しい「特権アクセス保護」（PAM：Privilege Access Management）について技術的内容を分かりやすく解説します。「そもそもPAMって何？」という方や、PAMについて検討し始めた方にはぴったりの内容です。

　初回は、そもそも「特権」とは何か、特権の持つ特徴リスク、抱える課題などについて整理します。

そもそも「特権」とは

　まずは、本連載の主要キーワードとして「特権」について、あらためて解説します。

　サイバーセキュリティの文脈で使われる「特権」がどんなものを指しているのか、あまりぴんとこない方もまだ多いと思います。日本語の意味からして、「特別な権利、権限」を意味するのが、世間の認識だと思いますが、サイバーセキュリティの文脈では、特権は「最高権限を有するID／アカウント」を意味します。Windowsの「Local Administrator」、Linuxの「root」、データベースの「System Administrator」などのアカウントをイメージしてもらえれば十分です。サイバーセキュリティの世界では、「特権アカウント」「特権ID」「特権ユーザー」などを指す場合もあります。

　そのような「特権」は、従来はデータセンターに構築されるサーバ、ネットワーク機器、データベースに組み込まれているビルトインのIDが主な対象でした。しかし、近年は、技術の進化によって、アプリケーションやクラウドサービス、プラットフォームなどに拡大、拡散しています。

　ちなみにCyberArkの調査によると、エンドポイントや、アプリなどの特権IDをカウントすると、平均して全従業員の3〜4倍の数が存在しているとのことです（参考：「CyberArk Survey Shows Majority of Organizations Underestimate Scope of Privileged Account Security Risk」）。

　読者の周りの環境でも幾つの特権IDが、どのように使われているか、ぜひ調査してもらいたいと思います。

特権の持つ特徴とリスク

　ここでは、主にセキュリティの観点で、特権の持つ特徴とリスクについて解説します。

　1つ目は、「何でも実行できる権限」ということです。

　最初から存在している特権IDは、必ずその装置やシステムの全ての機能を管理者が使えるように設計されているはずです（ただし、ライセンス的な制御を除く）。最高権限を持つので、「便利で使い勝手が良いアカウント」ともいえます。その半面、この特権IDが盗まれたり、悪用されたりした際のリスクや影響度合いが、非常に高いことを認識してください。

　2つ目は、「特権IDが共有IDとして使われていることが多い」ということです。

　ある程度のインフラ規模となると、複数人の専属チームといった単位で、運用しているケースがほとんどです。その場合、最初から存在する特権IDは複数人で共有されて、利用されているのは間違いないでしょう。となると、複数の人がその特権IDを使うためのパスワードを知っていることになります。これは、対象のシステムの専門性が高かったりすると、ベンダーの技術者と共有されていることもありますし、企業の業務方針によっては、アウトソースしているために、外部委託事業者に共有していることも、よくあることだと思います。

　3つ目は「パスワードの変更」についてです。

　定期メンテナンスのバッチや自動化のスクリプトにも特権IDが使われていることが多いので、パスワードを変更しようにも関係する範囲がつかめず、長年そのまま放置されてしまいがちになってしまうこともあります。

　このように特権IDは特別なIDです。普段何気なく使っている、rootやAdministratorといった管理者IDがこのようなセキュリティのリスクにつながる特徴を持っていることは意識していたでしょうか？

　例えば、特権IDのパスワードを知っている従業員が退職した場合、何も管理していないと、その従業員が侵入して情報を持ち出したり、勝手に裏アカウントを作ってシャドーITの温床になったりしてしまうかもしれません。または、メンテナンス作業のために、ベンダーに渡したrootのパスワードをそのままにして、勝手に侵入されない保証はありません。

　そのようなリスクを意識したことがなかった方は、これを機に他にも特徴がないかどうか、ぜひ気にしてみてください。「意識したことがある」「心配している」という方はおそらく次のような課題意識を持って、何かしらの対策を講じている、もしくは講じることを検討しているかと思います。ここからは、特権の持つ課題について整理します。

特権の持つ課題

　先に挙げた3つの特徴に対抗する策を講じるには、どうすればいいのでしょうか。

　1つ目の特徴については、厳重にその特権IDを保管、保護、制御することが必要なります。では、それは具体的に何を意味するのでしょうか？

　人間の生活を見てみると、大事なものは金庫に入れて、鍵を掛けて保管していないでしょうか。これと同様の仕組みをサイバーの世界でも作ります。セキュリティの世界では大切な情報を保管、保護するものを「Vault」といいます。日本語で「金庫」のことです。

　特権IDを金庫に入れて保護するとはどういうことでしょうか？　もう少し、かみ砕くと、認証情報（パスワード、SSH鍵、API Secret Key、トークンなど）を保護するということです。認証情報を保護するには、認証情報を知られない、もしくは知らせるとしても悪用を回避できるような仕組みを持っておくことが大切です。

　2つ目の特徴については、「ここを誰が、いつ、どのように使ったのか」を、きちんと把握することが課題になります。これについては、利用の記録を取っていればある程度カバーできるので、工夫次第でやり方は複数あると思います。

　一番コストがかからない典型的な方法が、「Microsoft Excel」などのファイルを使った台帳管理です。特権IDを使いたい人が、使いたい日時や、ログイン先のホストを入力して、使い終わったらその記録を残せばいいのです。ただし、これは基本手作業の運用なので、抜けや漏れの可能性も大きいですし、数が大きくなると管轄のITシステム部門の人たちの苦労は大変そうです。しかも、特権IDの払い出しをExcelで管理できたとしても、特権を使って何をしたのかは記録することができません。これでは、不審な行動があったとしても、見つけることは不可能です。

　結構厄介なのが3つ目の特徴についてです。まず、バッチやスクリプトで利用しているパスワードを把握すること、棚卸しすること、そしてそれらをセキュリティポリシーに準じて一元管理することが課題となります。

　これは、ITガバナンスを持つ意味でも重要です。ここについて、既に課題意識を持って何かしら取り組んでいる組織はセキュリティに対して非常に感度が高い組織だと思います。

特権を保護する理由、特権アクセス保護が必要な理由

　特権IDが持つリスクについては、既に触れたところですが、今度は視点を変えて、攻撃者の目線で考えてみます。調査会社Forresterのレポート「The Forrester Wave：Privileged Identity Management, Q3 2016」によると、内部に侵入された被害のうち、80％は特権の認証情報が関与しているとのことです。では、なぜ攻撃者は特権IDの奪取を狙うのでしょうか？　それは、特権IDを奪うことで、次のことが可能になるからです。

• セキュリティ管理を迂回（うかい）できる
• 認証システムをバイパスして自由に動き回れる
• 怪しい動きを検知されずに、潜伏を続けることができる（「Mandiant M-TRENDS 2018」によると、平均498日）

　そのため、攻撃者は高度化されたツールを駆使して、何としてもまずは特権IDを取りにきます。そのため、特段の措置もなく特権IDを保護していないと、3日もあればいともたやすく特権を取られてしまうことが、明らかになっています（参考：「Mandiant M-TRENDS 2016」）。

　もう一つ、興味深いデータを共有します。下図は、横軸に攻撃者の攻撃手法、縦軸にその攻撃による被害の大きさを描いています。

　まず、限定的な権限のIDを奪取されると、初期段階の被害は個人端末といった狭い範囲に限定されます。しかし、特権昇格を許してしまうと、そこから一気に被害が急拡大してしまい、重大な侵害につながってしまうことが分かっています。これは、先に述べたように管理者権限を持つと、抜け穴を作りやすくなり、隣接しているホストに飛び移ることができるからです。

　ここから得られる示唆としては、特権昇格をさせないこと、つまり特権IDを保護することが非常に効果的、効率的な防御手法ということです。別な言い方をすると、特権IDを保護する製品は広く知られていませんが、その導入は、実はコストパフォーマンス的に優秀なセキュリティ措置といえると思います。従って、サイバーセキュリティに潤沢にコストをかけられない中小企業こそ、導入して得られる効果は十分にあると思います。

特権IDを保護するには？

　最近の高度化した攻撃手法からデータやシステムを守るには、入らせないことを主とする境界型防御だけでは十分ではなく、入られることを前提とした、侵入前提型防御手法も組織として備えておくべきです。

　ひと昔前は、特権ID保護の主な対象ターゲットはオンプレミスの装置だったので、オンプレミスに特権ID保護のシステムを構築していましたが、最近は、クラウドシフトの流れを受けて、クラウド上にも構築できるようになっています。ただし、機能を提供するために必要とされる基盤のインスタンスも管理しなくてはいけませんでした。これは、細かなチューニングができる一方で、バージョンアップやパッチ適用、バックアップなどのメンテナンスにリソースが取られるといった性質も持っていました。しかし、それが今ではサブスクリプションモデルのトレンドに乗るようにSaaSの特権ID保護製品も市場に投入されています。素早く、小さく始めるスモールスタートをしたい場合や、運用の最適化が図れるマネージドサービスが期待される場合にはピッタリではないでしょうか。

　機能を限定して価格優位性を出している製品や、高度なセキュリティを売りにしている製品もあるので、企業のポリシーやユースケース、コストに応じて選択できる環境になってきたと思います。

　また、人が利用する特権IDの保護の次は、アプリケーションに代表されるような、モノが利用する特権IDに関しても同様に保護することが、デジタル化が進む世の中でサービスを提供、開発する企業には重要な経営課題です。

　連載第2回では、特権アクセス保護についてさらに詳しく解説するので、どうぞお付き合いください。