# NHI8:2025 環境の分離 (Environment Isolation)

| 脅威エージェントと攻撃ベクトル                                                                          | セキュリティ上の弱点                                                                                                | 影響度                                                                     |
| ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| 悪用可能性: **普通**                                                                            | <p>蔓延度: <strong>まれ</strong><br>検出可能性: <strong>困難</strong></p>                                             | <p>技術的影響: <strong>普通</strong><br>ビジネスへの影響: <strong>限定</strong></p>      |
| 分離されていない NHI の悪用に成功するには、脅威エージェントがまずテスト環境にアクセスする必要があります。とはいえ、テスト環境は本番環境と比べて保護が大幅に不足しがちです。 | 非本番環境と本番環境の間で NHI を再利用することはあまりありません。同じ NHI を使用する可能性のあるワークロードと環境の組み合わせは多岐にわたるため、分離されていない NHI を検出することは困難です。 | 分離された NHI の影響は、関連する NHI の権限に依存します。関連する NHI は、本来、本番環境にあるため、その影響は無視できません。 |

## 説明

環境分離はクラウドアプリケーションのデプロイメントにおける基本的なセキュリティプラクティスであり、開発、テスト、ステージング、本番に個別の環境を使用します。この分離は、ある環境で発生した問題が他の環境、特に実際のユーザーや機密データが存在する本番環境に影響を及ぼさないことを確保します。 サービスアカウント、API キー、ロールなどの非人間アイデンティティ (NHI) は、デプロイメントプロセス時やアプリケーションのライフサイクル全体を通じてしばしば利用されます。しかし、複数の環境、特にテスト環境と本番環境の間で同じ NHI を再使用すると、重大なセキュリティ脆弱性が生じる可能性があります。安全性の低いテスト環境で使用される NHI が本番リソースにアクセスするパーミッションを持つ場合、テスト環境を侵害した攻撃者がこの NHI を活用して本番環境に侵入する可能性があります。 これらのリスクを緩和するには、NHI が動作する環境に基づいて NHI を厳密に分離することが重要です。これには以下があります。

* **環境ごとに個別の NHI を使用すること:** 環境ごとに一意の NHI を割り当て、環境をまたいだアクセスを防ぎます。
* **最小権限の原則を適用すること:** NHI のパーミッションを特定の環境に必要なものだけに制限します。
* **環境固有のアクセス制御を実施すること:** 非本番環境の NHI が本番リソースにアクセスできないようにします。
* **定期的に監査および監視すること:** NHI を継続的に監視して、不正アクセスの試みや異常がないか確認します。

環境とそれに関連する NHI を分離することで、組織は攻撃対象領域を大幅に削減し、潜在的な侵害が環境全体に伝播することを防止できます。

## 攻撃シナリオの例

* **環境間で共有される AWS アクセスキー:** AWS アクセスキーはテスト環境と本番環境の両方で Amazon S3 バケットにアクセスするために使用されます。このキーはテスト環境のモックデータへのアクセスを目的としていますが、機密性の高い本番データにアクセスするためのパーミッションも持ちます。テスト環境が侵害された場合、攻撃者は共有アクセスキーを使用して本番データを取得または操作し、データ侵害やサービス停止につながる可能性があります。
* **サブスクリプション間で共有される Azure システム割り当てのマネージドアイデンティティ:** システム割り当てのマネージドアイデンティティは、リソースがテストサブスクリプションと本番サブスクリプションの両方でそれを使用でき、両方のサブスクリプションのリソースに対するパーミッションを持ちます。この設定により、テスト環境のプロセスが本番環境のリソースにアクセスできるようになります。攻撃者がテスト環境にアクセスすると、マネージドアイデンティティを悪用して重要なリソースに不正にアクセスし、本番環境全体を侵害する可能性があります。

## 防御方法

* **NHI の厳格な環境分離:** 環境 (開発、テスト、ステージング、本番) ごとに一意の NHI を割り当て、ある環境のクレデンシャルやアイデンティティを別の環境で再使用できないようにします。
* **最小権限の原則 (PoLP) を適用する:** NHI には、指定された環境内での特定のタスクに必要な最小限のパーミッションのみを付与します。これにより NHI が侵害された場合の潜在的な損害を最小限に抑えます。
* **環境固有のアクセス制御を実施する:** 非本番環境 (テストなど) の NHI が本番環境のリソースとやり取りやアクセスできないようにアクセスポリシーを設定します。
* **機密リソースのためのインフラストラクチャを分離する:** 個別のリソースグループ、サブスクリプション、アカウントを使用して、本番環境と非本番環境を分離します。これにより、NHI が侵害された場合でも、影響範囲はその環境に限定されます。

## 参考情報

* [AWS Recommendations on Workload Isolation](https://aws.amazon.com/solutions/guidance/workload-isolation-on-aws/)

## データポイント

* **CSA NHI Report** - 32% の場合に設定エラーを NHI 関連のセキュリティインシデントの原因に挙げています。 (4/10)