翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# インシデント対応とフォレンジック
<a name="incident-response-and-forensics"></a>

インシデントに迅速に対応できれば、違反による損害を最小限に抑えることができます。疑わしい動作を警告できる信頼性の高いアラートシステムを持つことは、適切なインシデント対応計画の最初のステップです。インシデントが発生した場合は、影響を受けたコンテナを破棄して置き換えるか、コンテナを分離して検査するかをすばやく決定する必要があります。フォレンジック調査と根本原因分析の一環としてコンテナを分離することを選択した場合は、次の一連のアクティビティに従う必要があります。

## インシデント対応計画の例
<a name="_sample_incident_response_plan"></a>

### 問題のある Pod とワーカーノードを特定する
<a name="_identify_the_offending_pod_and_worker_node"></a>

最初のアクションは、ダメージを分離することです。まず、侵害が発生した場所を特定し、その Pod とそのノードを残りのインフラストラクチャから分離します。

### ワークロード名を使用して問題のある Pod とワーカーノードを特定する
<a name="_identify_the_offending_pods_and_worker_nodes_using_workload_name"></a>

問題のあるポッドの名前と名前空間がわかっている場合は、次のようにポッドを実行しているワーカーノードを特定できます。

```
kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'
```

デプロイなどの[ワークロードリソース](https://kubernetes.io/docs/concepts/workloads/controllers/)が侵害された場合、ワークロードリソースの一部であるすべてのポッドが侵害されている可能性があります。次のコマンドを使用して、ワークロードリソースのすべてのポッドとそれらが実行されているノードを一覧表示します。

```
selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'
```

上記のコマンドはデプロイ用です。レプリカセット、ステートフルセットなど、他のワークロードリソースに対しても同じコマンドを実行できます。

### サービスアカウント名を使用して問題のある Pod とワーカーノードを特定する
<a name="_identify_the_offending_pods_and_worker_nodes_using_service_account_name"></a>

場合によっては、サービスアカウントが侵害されていることを特定できます。識別されたサービスアカウントを使用するポッドが侵害されている可能性があります。次のコマンドを使用して、サービスアカウントとそれらが実行されているノードを使用して、すべてのポッドを識別できます。

```
kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'
```

### 脆弱または侵害されたイメージとワーカーノードを持つポッドを特定する
<a name="_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes"></a>

場合によっては、クラスターのポッドで使用されているコンテナイメージが悪意のあるものであったり、侵害されていることが判明することがあります。コンテナイメージにマルウェアが含まれていることが判明した場合、既知の不正なイメージであるか、悪用された CVE がある場合、コンテナイメージは悪意のあるものであるか、侵害されています。コンテナイメージが侵害されたすべてのポッドを考慮する必要があります。次のコマンドを使用して、実行中のイメージとノードを使用してポッドを識別できます。

```
IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'
```

### ポッドへのすべての入出力トラフィックを拒否するネットワークポリシーを作成してポッドを分離する
<a name="_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod"></a>

すべてのトラフィック拒否ルールは、ポッドへのすべての接続を切断することで、すでに進行中の攻撃を停止するのに役立ちます。次のネットワークポリシーは、 というラベルのポッドに適用されます`app=web`。

```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
```

**重要**  
攻撃者が基盤となるホストにアクセスした場合、ネットワークポリシーは無効である可能性があります。が発生したと思われる場合は、[AWS セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)を使用して、侵害されたホストを他のホストから分離できます。ホストのセキュリティグループを変更する場合、そのホストで実行されているすべてのコンテナに影響することに注意してください。

### 必要に応じて、ポッドまたはワーカーノードに割り当てられた一時的なセキュリティ認証情報を取り消す
<a name="_revoke_temporary_security_credentials_assigned_to_the_pod_or_worker_node_if_necessary"></a>

ワーカーノードに Pod が他の AWS リソースにアクセスできるようにする IAM ロールが割り当てられている場合は、それらのロールをインスタンスから削除して、攻撃によるさらなる損害を防ぎます。同様に、ポッドに IAM ロールが割り当てられている場合は、他のワークロードに影響を与えることなく、ロールから IAM ポリシーを安全に削除できるかどうかを評価します。

### ワーカーノードをコーディングする
<a name="_cordon_the_worker_node"></a>

影響を受けるワーカーノードを遮断することで、影響を受けるノードにポッドをスケジュールしないようにスケジューラに通知します。これにより、他のワークロードを中断することなく、フォレンジック調査用のノードを削除できます。

**注記**  
このガイダンスは、各 Fargate ポッドが独自のサンドボックス環境で実行される Fargate には適用されません。グルーニングの代わりに、すべての入出力トラフィックを拒否するネットワークポリシーを適用して、影響を受ける Fargate ポッドを隔離します。

### 影響を受けるワーカーノードで終了保護を有効にする
<a name="_enable_termination_protection_on_impacted_worker_node"></a>

攻撃者は、影響を受けたノードを終了することで、不正行為を消去しようとする可能性があります。[終了保護](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination)を有効にすると、これを防ぐことができます。[インスタンスのスケールイン保護](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection)は、スケールインイベントからノードを保護します。

**警告**  
スポットインスタンスで終了保護を有効にすることはできません。

### 問題のある Pod/Node に、アクティブな調査の一部であることを示すラベルを付けます。
<a name="_label_the_offending_podnode_with_a_label_indicating_that_it_is_part_of_an_active_investigation"></a>

これは、クラスター管理者が調査が完了するまで、影響を受ける Pods/Nodes を改ざんしないように警告するのに役立ちます。

### ワーカーノードで揮発性アーティファクトをキャプチャする
<a name="_capture_volatile_artifacts_on_the_worker_node"></a>
+  **オペレーティングシステムのメモリをキャプチャします**。これにより、Docker デーモン (または他のコンテナランタイム) とそのサブプロセスがコンテナごとにキャプチャされます。これは、[LiME](https://github.com/504ensicsLabs/LiME) や [Volatility](https://www.volatilityfoundation.org/) などのツール、またはそれら上に構築される [ Amazon EC2 用自動フォレンジックオーケストレーター](https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/)などの高レベルのツールを使用して実現できます。
+  **実行中のプロセスと開いているポートの netstat ツリーダンプを実行します**。これにより、コンテナごとに docker デーモンとそのサブプロセスがキャプチャされます。
+  **証拠が変更される前に、コマンドを実行してコンテナレベルの状態を保存します**。コンテナランタイムの機能を使用して、現在実行中のコンテナに関する情報をキャプチャできます。例えば、Containerd では、以下を実行できます。
  +  `crictl ps` 実行中のプロセス用。
  +  `crictl logs CONTAINER` デーモンレベルの保持ログの 。

    代わりに [nerdctl](https://github.com/containerd/nerdctl) CLI を使用して containerd でも同じことが実現できます `docker` (例： `nerdctl inspect`)。コンテナランタイムに応じて、いくつかの追加のコマンドを使用できます。たとえば、Docker はコンテナファイルシステムの変更を確認したり`docker checkpoint`、揮発性メモリ (RAM) を含むすべてのコンテナ状態を保存`docker diff`したりする必要があります。containerd または [CRI-O ランタイムの同様の機能については、この Kubernetes ブログ記事](https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/)を参照してください。
+  **フォレンジックキャプチャのためにコンテナを一時停止します**。
+  **インスタンスの EBS ボリュームをスナップショットします**。

### 侵害された Pod またはワークロードリソースを再デプロイする
<a name="_redeploy_compromised_pod_or_workload_resource"></a>

フォレンジック分析のためにデータを収集したら、侵害されたポッドまたはワークロードリソースを再デプロイできます。

まず、侵害された脆弱性の修正をロールアウトし、新しい代替ポッドを開始します。次に、脆弱なポッドを削除します。

脆弱なポッドが上位レベルの Kubernetes ワークロードリソース (デプロイや DaemonSet など) によって管理されている場合、それらを削除すると新しいポッドがスケジュールされます。そのため、脆弱なポッドは再び起動されます。その場合は、脆弱性を修正した後に新しい代替ワークロードリソースをデプロイする必要があります。次に、脆弱なワークロードを削除する必要があります。

## 推奨事項
<a name="_recommendations"></a>

### AWS セキュリティインシデント対応ホワイトペーパーを確認する
<a name="_review_the_aws_security_incident_response_whitepaper"></a>

このセクションでは、セキュリティ違反の疑いに対処するための簡単な概要といくつかの推奨事項を示しますが、このトピックはホワイトペーパー[「AWS セキュリティインシデント対応](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)」で網羅されています。

### セキュリティゲームデーを練習する
<a name="_practice_security_game_days"></a>

セキュリティ担当者を赤と青の 2 つのチームに分割します。赤チームはさまざまなシステムの脆弱性を調べることに集中し、青チームはそれらに対する防御を担当します。個別のチームを作成するのに十分なセキュリティ担当者がない場合は、Kubernetes の悪用に関する知識を持つ外部エンティティの採用を検討してください。

 [Kubesploit](https://github.com/cyberark/kubesploit) は、CyberArk の侵入テストフレームワークで、ゲームデーの実行に使用できます。クラスターの脆弱性をスキャンする他のツールとは異なり、kubesploit は実際の攻撃をシミュレートします。これにより、ブルーチームは攻撃への対応を練習し、その有効性を評価する機会が得られます。

### クラスターに対して侵入テストを実行する
<a name="_run_penetration_tests_against_your_cluster"></a>

独自のクラスターを定期的に攻撃すると、脆弱性や設定ミスを検出するのに役立ちます。開始する前に、クラスターに対してテストを実行する前に、[ペネトレーションテストのガイドライン](https://aws.amazon.com/security/penetration-testing/)に従ってください。

## ツールとリソース
<a name="_tools_and_resources"></a>
+  Kubernetes の侵入テストツールである [kube-hunter](https://github.com/aquasecurity/kube-hunter)。
+  [Gremlin](https://www.gremlin.com/product/#kubernetes) は、アプリケーションやインフラストラクチャに対する攻撃をシミュレートするために使用できるカオスエンジニアリングツールキットです。
+  [Kubernetes インストールの攻撃と防御](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2019/findings/AtredisPartners_Attacking_Kubernetes-v1.0.pdf) 
+  [kubesploit](https://www.cyberark.com/resources/threat-research-blog/kubesploit-a-new-offensive-tool-for-testing-containerized-environments) 
+  [SUSE オープンソースのゼロトラストコンテナセキュリティプラットフォームによる NeuVector ](https://www.suse.com/neuvector/) は、脆弱性とリスクのレポートとセキュリティイベント通知を提供します。
+  [高度な永続的な脅威](https://www.youtube.com/watch?v=CH7S5rE3j8w) 
+  [Kubernetes の実用的な攻撃と防御](https://www.youtube.com/watch?v=LtCx3zZpOfs) 
+  [RBAC アクセス許可を利用して Kubernetes クラスターを侵害する](https://www.youtube.com/watch?v=1LMo0CftVC4)