NHI5:2025 過剰特権の NHI (Overprivileged NHI)
悪用可能性: 困難
蔓延度: 広範 検出可能性: 普通
技術的影響: 重大 ビジネスへの影響: 限定
過剰特権の NHI の悪用に成功するには、脅威エージェントがまず環境にアクセスする必要があります。したがって、過剰特権の NHI は個別の初期アクセスベクトルに依存します。
NHI の権限を適切に設定するのは非常に困難で時間のかかる作業であるため、NHI に過剰な権限が与えられることは非常に一般的です。過剰特権の非人間アイデンティティの検出は環境の種類によって異なります。クラウド環境では検出を容易にするツールを提供していますが、オンプレミス環境では同様の機能が組み込まれていないため、そのようなアイデンティティの検出は非常に困難になります。
関連する権限の量が多いため、過剰特権の NHI の影響は大きくなります。これらは広範囲に影響を及ぼす管理者アカウントである傾向があります。
説明
サービスアカウント、API トークン、ワークロードアイデンティティなどの非人間アイデンティティ (NHI) はクラウドリソースとサービスへのプログラムによるアクセスのために設計されています。これらによりアプリケーション、サービス、自動化されたプロセスが人間の介入なしに安全に機能できます。しかし、アプリケーション開発や保守の際に、開発者や管理者が誤って NHI に機能要件を超える過剰な権限を割り当て、侵害が発生した場合の潜在的な影響範囲を不必要に広げてしまう可能性があります。 過剰特権の NHI が、アプリケーションの脆弱性、マルウェア、その他のセキュリティ侵害によって侵害された場合、攻撃者は過剰な権限を悪用して以下を行うことができます。
機密データにアクセスする: 機密ファイル、データベース、ユーザー情報へ不正アクセスします。
権限を昇格する: システム内でより高いレベルのアクセス権を取得し、管理者レベルまたはルートレベルに達する可能性があります。
ネットワーク内でラテラルムーブする: NHI が到達できる組織のネットワーク内で他のシステムやサービスにアクセスします。
悪意のあるソフトウェアをインストールする: マルウェア、ランサムウェア、その他の悪意のあるツールをデプロイして、システムをさらに侵害します。
クラウドアカウント全体を乗っ取る: クラウドルートアカウントまたは管理者に関連するアイデンティティが漏洩すると、完全な制御やアカウントの乗っ取りにつながる可能性があります。
攻撃シナリオの例
過剰な権限を持つウェブサーバーユーザー: ウェブサーバーは、他のアプリケーション、システムファイル、機密データディレクトリにもアクセスできる Linux マシン上のローカルユーザーアカウントで実行します。ウェブサーバーにリモートコード実行を許可する脆弱性がある場合、攻撃者はこれを悪用してウェブサーバープロセスを制御できます。ユーザーアカウントの過剰な権限により、攻撃者は他のアプリケーションにアクセスや変更したり、機密データを盗んだり、不正なシステム変更を行う可能性があります。
過剰な権限を持つ VM: Jenkins EC2 インスタンスは EKS と ECS の権限のみが必要であるにもかかわらず、誤って AWS AdministratorAccess 管理ポリシーが割り当てられています。インスタンスの脆弱性を悪用して、攻撃者は初期アクセスを獲得し、過剰な権限を活用してクラウド環境をナビゲートし、S3 バケットから機密データを盗み出します。
過剰な権限を持つ OAuth アプリケーション: 開発者は開発中の OAuth アプリケーションを本番 Azure アカウントにインストールします。そのアプリは Azure Blob Storage 内の特定のディレクトリへの読み取りアクセスのみを必要としているにもかかわらず、AppRoleAssignment.ReadWriteAll 権限を付与します。これにより悪意のあるエンティティがそのアプリケーションを入手した場合に与えることができる損害の影響が大幅に増加します。
過剰な権限を持つデータベースサービスアカウント: 管理されたデータベースサービスは、アカウントの管理者権限を持つサービスアカウントで動作します。攻撃者がデータベースへのアクセスに成功した場合、サービスアカウントの高レベルの権限を使用して、クラウドアカウント全体にアクセスし、アクションを実行できます。
広範なネットワークアクセスを持つ制限のないアプリケーションユーザー: データベースアプリケーションはサーバー上で管理者権限を持つサービスアカウントで動作します。攻撃者がデータベースソフトウェアの脆弱性を悪用すると、サービスアカウントの高レベルの権限を使用して任意のコマンドを実行したり、マルウェアをインストールしたり、新しいユーザーアカウントを作成し、システム全体の侵害につながる可能性があります。
防御方法
最小権限の原則を適用する: 各アイデンティティには特定のタスクに必要なパーミッションのみを割り当て、絶対に必要な場合を除き、いかなる形式の管理者権限も避けます。
パーミッションを定期的に監査およびレビューする: アイデンティティに付与されたパーミッションが厳密に必要であることを確認するために、それらを継続的に評価します。特権アイデンティティを監査し、潜在的な誤用や過剰プロビジョニングを検出して対処します。
予防的なガードレールを確立する: 組織レベルで拒否ポリシーを実装し、過度に寛容な構成を禁止し、厳格なアクセス制御を実施します。
Just-in-Time (JIT) アクセスを活用する: 一時的でオンデマンドの権限昇格を可能にするツールを活用して、必要な場合にのみ定義された時間枠内で高レベルのアクセスを許可します。
参考情報
データポイント
17.6% は、アカウント内のすべての S3 バケットからデータを一覧表示してアクセスするなど、過剰なデータアクセスを持っています。
10% のクラスタには、完全な管理者アクセスを持ったり、権限昇格を許可したり、過度に寛容なデータアクセス (すべての S3 バケットなど) を持ったり、アカウント内のすべてのワークロード間でのラテラルムーブメントを許可する危険なノードロールがあります。
3 分の 1 以上の Google Cloud VM (33%) にはプロジェクトに対する機密性の高いパーミッションがあります。
33% の回答者が過剰な権限を持つアカウントを最も懸念される NHI 脅威のトップ 3 の一つに挙げています。 (3/10)
37% の場合に過剰な権限を持つアイデンティティを NHI 関連のセキュリティインシデントの原因に挙げています。 (2/10)
22% の組織が NHI ツールの最も重要な機能としてパーミッションの管理を必要としています。 (5/16)
26% の組織がサービスアカウントの 50% 以上が過剰な権限を持っていると考えています。
44% の環境には少なくとも一つの特権アイデンティティアクセス管理 (IAM) ロールがあります。
23% には管理者 IAM ロールを持つ EC2 インスタンスが少なくとも一つあります。
Last updated