なぜ企業はクラウドにおける最小特権にいまだ苦慮しているのでしょうか

By 清水 孝郎 - MARCH 14, 2023

SHARE:

なぜ企業はクラウドにおける最小特権にいまだ苦慮しているのでしょうか

本文の内容は、2023年3月14日に MIGUEL HERNÁNDEZ が投稿したブログ(https://sysdig.com/blog/identity-access-management-difficult-cloud)を元に日本語に翻訳・再構成した内容となっております。 脆弱性は、クラウドセキュリティを語る上でのほんの一部に過ぎません。セキュリティインシデントの最大の要因は設定ミスであり、それゆえ、組織における最大の懸念事項の1つであるべきです。 Gartner®によると、”2023年までに、セキュリティ障害の75%がアイデンティティ、アクセス、および特権の不適切な管理に起因するようになり、2020年の50%から増加する “とされています。[1]多くの組織が最小特権の強制などゼロトラスト原則について話していますが、私たちのデータでは、行動を起こした証拠はほとんどありません。この情報により、いくつかの疑問が生じ始めます。

  • なぜ、多くの企業が今日でも設定ミスを抱えているのでしょうか?
  • クラウド上のアクセス制御を正しく設定することは、組織にとってそれほど複雑なことなのでしょうか。
  • フレームワークやベストプラクティスが存在するにもかかわらず、なぜそれが守られないのか?
IAMの設定ミス脆弱性の優先順位付けサプライチェーン攻撃、あるいはKubernetesで今どれだけのリソースと費用を無駄にしているかなど、もっと知りたい方は、ぜひSysdigの2023年度クラウドネイティブセキュリティおよび利用状況レポートを読んでみてください。

最小特権の原則とは何ですか?

自分の役割によっては、タスクを実行するために必要な特定の権限しか持っていないと思いがちです。例えば、プロジェクト内の開発者であれば、コードの閲覧や編集のみが可能で、新規プロジェクトの作成はできないはずです。 これは最小権限の原則と呼ばれるもので、開発者、セキュリティ・アーキテクト、コンプライアンス・エキスパートは、ブロッカーなしで仕事をすることができるはずですが、この範囲を超えることはできないはずです。人間以外のアカウントもまた、最小特権に従わなければならない独自の権限を持っていることを忘れてはなりません。 しかし、冷静に考えてみてください。クラウドプロバイダーは、IAM、ポリシー、ロール、ユーザー、グループなど、保護されたアカウントを維持するためのすべてのリソースとサービスを提供しています。また、ベストプラクティスもあり、それに従えば、リスクをできる限り抑えることができます。 では、どこに問題があるのでしょうか? RSAC - 7 Cloud Security Reasons for Rating Breach FaceSysdigのMaya Levineが、クラウドの侵害の実例、何が問題だったのか、防御者が同じ罠にはまらないための方法を探るセッション「Seven Cloud Security Reasons for Resting Breach Face」に参加します。

最小限の権限とクラウド導入の断絶

なぜ、最小権限による安全な設計を意図していたのに、実際にクラウドを導入すると、このような乖離が生じるのでしょうか。多くのアクセス制御要素が関与し、組織によって実装が異なるため、単純な答えや答えはありません。私たちは、重要度の高い順にではなく、簡単にするために主な原因を3つのカテゴリーに分類しています。

すべての開発者または会社の従業員が例外である

組織において、誰がどのような権限を必要とするのか、効率よく仕事をするためにはどうすればいいのかを知ることは難しいかもしれません。 IAMの基本は、役職や部署などのパラメータに基づいてユーザーをグループ化し、業務遂行に必要な正確なルールを持つアクセスポリシーのみを添付することです。一般的に、これはロールベースのアクセスコントロールとして説明されますが、この理論は、個人が孤立したチームで仕事をしていない複雑な組織構造の現実と喧嘩します。 チーム横断的な取り組みについて考えてみましょう。個人やグループは、さまざまなエンジニアリングチームに貢献し、営業とやり取りし、開発者に支援を提供します。このような取り組みには、それぞれのプロジェクトやサポートラインが存在するため、理想的には一時的に許可されるべきパーミッションが発生します。しかし、それを毎回行うのは粒度が細かく、作業負荷が大きくなるため、簡略化のためにグローバルまたは永続的に権限を付与する状況になっています。 まとめると、ユーザーが仕事をするためには、パーミッションに何らかの調整が必要で、それが過剰なパーミッションを持つユーザーを生み出すという意図しない副作用があります。 結局、DevOpsとセキュリティチームは、必要以上の権限を付与する傾向があり、チームは阻害されることなく業務を遂行し、ビジネス目標に集中できるようになります。通常、機能性と可用性が最優先され、時には堅牢なセキュリティが犠牲になることもあります。DevOpsムーブメントの一環として、セキュリティチームには「NOの文化」から脱却するよう強いプレッシャーがかかっています。誰かが、あるいは何かが、なぜ高い権限を必要とするのかを精査することは、ビジネスプロセスやアプリケーションのリリースを遅らせることになります。 このようなビジネスの現実とその結果生じる影響を示す証拠として、Sysdigは、付与された権限の90%が使用されていないことを利用レポートに示しています。 さらに、クラウドベンダーとその提供するサービスは、前年比で驚くほど速く進化しています。サービスの継続的な追加や既存のサービスの変更は、許可をさらに複雑化させ、スケーリングの課題につながります。

アイデンティティとアクセス管理の拡張は困難

最初の根本的な原因は、2つ目の根本的な原因につながります。ポリシーが常に変更されるため、それを管理するチーム全体が必要になってきます。多くの場合、IAM専門チームを配置できるのは大企業だけですが、それでも負け戦になる可能性があります。 個々のユーザーやグループに焦点を当てるのは、粒度を考えると管理が難しすぎるのです。ユーザーの数は、指数関数的な量のアイデンティティとアクセス・ルールを生み出します。さらに、複雑さを増すリソースがあり、それらを手動で維持することは、スケールを大きくすることを不可能にしています。 また、対処しなければならないのは、人間や従来のユーザーだけではありません。アプリケーション、クラウドサービス、商用ツール、その他多くのエンティティ(またはマシンのアイデンティティ)も、同様に適切に認証・認可されなければなりません。携帯電話のアプリケーションが、連絡先、写真、カメラ、マイクなどに対するパーミッションを要求するのと同様に、これらのマシン・アイデンティティは、あなたの環境に対するパーミッションを要求します。このため、このような非人間的な存在に対するアクセス管理も考慮しなければなりません。 この種のアカウント認証に挑戦することは、従来のユーザーとは異なり、システムインテグレーションや自動化を壊すことにもなりかねません。 企業がID管理を拡張する際にこの課題に直面することは明らかです。正確でありながら柔軟に活動を許可する必要がありますが、同時に管理する各アカウント、グループ、またはポリシーにおいて最小特権の原則を維持しなければならないからである。これらの制約は、多くの組織が追求しているゼロトラストアーキテクチャーの基礎にもなっています。

アクセス制御の可視化と分析が不十分である

なぜ、付与されたパーミッションの多くが使われないのでしょうか?少なくとも、組織はユーザーアカウント、非人間的なアイデンティティ、および関連するパーミッションを可視化する必要があります。
  • 非人間的なIDに付与された権限の98%以上が、少なくとも90日間使用されていません。
このような未使用のパーミッションは、期限切れのテストアカウントやサードパーティアカウントなど、孤児となったIDに付与されていることがよくあります。また、クラウドへの移行時や複数の認証システムがある場合、LDAPなどの古典的なIDマネージャと直接1対1のマッピングができないため、このようなことが起こることもあります。多くのシステムで、DACMACRBACも混在しており、整合性がとれていないことも排除できません。 過剰な権限は、セキュリティインシデントや侵害の可能性を高めると考えるべきでしょう。セキュリティに不備があったときに想定されるリスクを理解するために、IDの種類に関わらず、常に可能な限りパーミッションを減らすべきでしょう。OWASP Kubernetesは、あなたが直面する可能性の高いリスクを整理して、手助けしてくれるでしょう。 私たちは、管理者権限を持つSysdigのすべてのお客様アカウントを詳しく調べ、相対的なリスクスコアを算出しました。リスクスコアは、お客様のクラウドアカウントのうち、セキュリティ衛生状態が悪いものの割合を表しています。私たちは、管理者権限のあるアカウント、多要素認証(MFA)が有効でないアカウント、90日以上のアカウントの非アクティブをパラメータとして設定しました。これらのアカウントは、攻撃者が求める便利なものであり、高い権限を持つアカウントへのアクセスが容易になり、これらのアカウントでの通常の活動が防御的な検出アラートにキャプチャーされない可能性があるため、検出の可能性が低くなります。

不要なリスクを軽減するための最善の戦略

私たちの調査によると、IAMプロセス、ツール、ゼロトラストアプローチに対する認識はあるものの、クラウドにおける適切なアクセスコントロールは、クラウド導入の速いペースに比べると、まだ遅れていることがわかります。 それでは、上記のような課題に立ち向かうための最適な戦略とはどのようなものかを説明しましょう。

権限例外の適切なバランスを見つける

企業としては、ユーザーに付与する最も正確なポリシー、グループ、およびロールの作成にリソースと時間を投資しています。しかし、前述したように、ユーザーが自分のタスクを完了するために、より多くの権限を欲したり、必要としたりしたときに、問題が発生するのです。私たちは、いかなる例外も許可してはいけないのでしょうか?これは、自分自身に問いかけるべき重要な質問です。設定ミスを確実に回避したいのであれば、例外を認めないことが最良の解決策です。残念ながら、現実の世界では、可用性が第一優先で、セキュリティは二の次です。このような安全な設計の選択も、一方的に行う必要はありません。ミッションクリティカルな環境やビジネスクリティカルな環境、あるいはクラウドテナントのような露出度の高い環境においてのみ、より厳格なアクセスコントロールを採用することができます。 規模に関係なく、すべての例外をインベントリ化し、ユーザーに対する権限のライフサイクルに沿って、最も機密性の高い管理者やポリシーに焦点を当て、最後に、変更を受け入れるたびにリスクを受け入れることです。

IAMチームとITチーム間のコラボレーションを促進する

では、このアイデンティティとアクセス管理を大規模に行うにはどうすればいいのでしょうか? それは、権限のガバナンス(ポリシー、グループ、ロールなどのリソースの管理とプロビジョニング)だけを専門に行う担当者やチームを配置することだけではありません。これは助けになりますが、残念ながら完璧な解決策ではありません。すべてが一点に依存している場合や、組織に専門チームを維持するリソースがない場合には、スケーラビリティの問題を解決することはできません。 そこで考えられる解決策は、アカウントや人間以外のユーザーへの権限付与の粒度を維持するために、異なるチームの協力と所有権を通すことです。各チーム(エンジニア、ビジネスチーム、プラットフォームオプスなど)は、自分の仕事領域を把握し、必要最低限のリソースを知っています。ITチームやIAMチームが存在する場合は、クラウドプロバイダーが提供するコントロールを使用して、最小特権の原則に従う必要があります。 もう一つの解決策は、セルフサービスで、厳格なポリシーを持ち、リスクを最小限に抑えるために一時的にこれらの許可を取得することです。さもなければ、人々は過剰な許可を与え、アクセス制御が劣化する可能性があります。これらの自動化されたソリューションは、アイデンティティとアクセス管理に複雑さを加えることで、リクエストと承認という大きな問題を解決できるかもしれません。 他の組織チームと連携する個人は、CISベンチマークやよく設計されたフレームワークなど、クラウドセキュリティのベストプラクティスへの準拠を満たすためのより良い能力を身につけることができるでしょう。 RSAC_Container Breaches Kubernetesやコンテナが流行っていますが、主要なセキュリティインシデントはどこにあるのでしょうか?本セッションでは、コンテナ化されたワークフローに対する攻撃がどのように発生しやすいか、また何をすべきかを検討します。

時間の無駄を省き、ランタイム検知に傾注する

最後になりますが、検出を使用することによって、権限と権限マネージャに加えられたすべての変更を認識し続ける必要があります。そうでなければ、敵の最初のアクセスを見逃して、侵害リスクの増大を許してしまうかもしれません。 従来、組織はアプリケーションやサービス(データレイクなど)からすべてのデータログをダンプし、SIEMなどのツールを使って脅威を検出しようとし、平均検出時間(MTTD)を最小化することにリソースを投入していました。私たちは、お客様のパーミッションマネージャーやクラウドテナントにおけるあらゆる変更のこの検出を高速化し、不適切な変更をその場で制限したり、ユーザーの通常の行動に基づいてデフォルト設定に戻したりするランタイムセキュリティ機能を生じさせることが必要だと考えています。さらに、脅威検出システムを効率的に動作させるために組織が必要とするインフラストラクチャーのコストを削減することができます。 また、IAMチームとITチームは、可能な限り未使用のテストアカウントを削除して、初期アクセスの機会を防ぎ、攻撃対象領域を縮小する必要があります。これは手動で決定するのは面倒ですが、自動的にポリシーを定義するスマートな方法は、ユーザーの行動と彼らが通常使用する権限の分析に基づくことができます。この情報は、理想的にはコード化され(policy-as-codeの形など)、そして強制力を持つベースラインを生成するために使用することができます。この“in-use” 権限ポリシーは、フィルタとして機能し、自動的に推奨事項を生成し、このプロセスをより効率的にすることができます。 これらの推奨事項は、確立されたセキュリティのベストプラクティスに従っており、全体的なサイバーセキュリティプログラムの一部であるべきです。これらを遵守することで、リスク態勢にメリットをもたらします。

最終的な考え方

クラウドでのID管理が難しい理由と、組織が一般的にアクセス制御を誤って設定し、IDを過剰に許可していることについて、表面を掻い摘んで説明しました。ここで提供されたガイダンスと提案を利用して、アクセス権管理の実践を改善することができます。 アイデンティティとアクセス管理は、すべてのセキュリティ・プログラムのアプローチではないにしても、そのほとんどを支える非常に密度の高いトピックです。クラウド環境では、IAMがより複雑になることは明らかです。実務家は、最小権限の原則に従い、ゼロトラスト・イニシアチブを追求すべきであると知っていますが、「どのように」に対する答えは微妙です。クラウドにおける効果的なIAMは、Sysdigの使用状況レポートの統計が示すように、どの組織にとっても大きな課題であり、最適な戦略は画一的なものではないと考えています。
[1] Gartner, Best Practices for Optimizing IGA Access Certification, Gautham Mudra, 4 April 2022. ガートナーは、米国および国際的なガートナー社および/またはその関連会社の登録商標およびサービスマークであり、本書では許可を得て使用されています。無断転載を禁じます。 ぜひSysdigの2023年度クラウドネイティブセキュリティおよび利用状況レポートを読んでみてください。