翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# EKS Protection の検出結果の修復
Amazon GuardDuty は、アカウント用に EKS Protection が有効になっている場合に、Kubernetes のセキュリティ問題の可能性を示す[検出結果](guardduty_findings.md)を生成します。詳細については、「[EKS Protection](kubernetes-protection.md)」を参照してください。次のセクションでは、これらのシナリオにおいて推奨される修復ステップについて説明します。特定の修復アクションは、その特定の検出結果タイプのエントリで説明されています。検出結果タイプに関する完全な情報にアクセスするには、[[Active findings types table]](guardduty_finding-types-active.md) (アクティブな検出結果タイプテーブル) を選択します。
EKS Protection の検出結果タイプのいずれかが予想どおりに生成された場合は、今後アラートが発生しないように [GuardDuty の抑制ルール](findings_suppression-rule.md)を追加することを検討してください。
さまざまなタイプの攻撃と設定の問題によって、GuardDuty EKS Protection の検出結果がトリガーされる可能性があります。このガイドは、適切な修復ガイダンスを概説するものであり、クラスターに対する GuardDuty の検出結果の根本原因を特定するのに役立ちます。GuardDuty の Kubernetes の検出結果につながる主な根本原因は次のとおりです。
+ [潜在的な設定の問題](#compromised-kubernetes-config)
+ [侵害された可能性のある Kubernetes ユーザーの修復](#compromised-kubernetes-user)
+ [侵害された可能性のある Kubernetes ポッドの修復](#compromised-kubernetes-pod)
+ [侵害された可能性のある Kubernetes ノードの修復](#compromised-kubernetes-node)
+ [侵害された可能性のあるコンテナイメージの修復](#compromised-kubernetes-image)
**注記**
Kubernetes バージョン 1.14 より前では、`system:unauthenticated` グループは、デフォルトで `system:discovery` と `system:basic-user` **ClusterRoles** に関連付けられていました。これは、匿名ユーザーからの意図しないアクセスを許可する場合があります。クラスターの更新では、これらの許可は取り消されません。つまり、クラスターをバージョン 1.14 以降に更新した場合でも、これらの許可は引き続き有効である可能性があります。これらの許可の関連付けを `system:unauthenticated` グループから解除することをお勧めします。
これらのアクセス許可の削除の詳細については、「**Amazon EKS ユーザーガイド**」の「[ベストプラクティスによる Amazon EKS クラスターの保護](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html)」を参照してください。
## 潜在的な設定の問題
検出結果で設定の問題が示されている場合、その特定の問題の解決に関するガイダンスについては、その検出結果の修復セクションを参照してください。詳細については、設定上の問題を示す次の検出結果タイプを参照してください。
+ [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted)
+ [Policy:Kubernetes/ExposedDashboard](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-exposeddashboard)
+ [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount)
+ [Policy:Kubernetes/KubeflowDashboardExposed](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-kubeflowdashboardexposed)
+ **SuccessfulAnonymousAccess** で終わる検出結果。
## 侵害された可能性のある Kubernetes ユーザーの修復
GuardDuty の検出結果は、検出結果で特定されたユーザーが想定されていない API アクションを実行したときに、侵害された Kubernetes ユーザーを示している場合があります。ユーザーは、コンソールの検出結果の詳細の **[Kubernetes user details]** (Kubernetes ユーザー詳細) セクション、または検出結果の JSON の `resource.kubernetesDetails.kubernetesUserDetails` で識別できます。これらのユーザーの詳細には、`user name`、`uid`、およびユーザーが属する Kubernetes グループが含まれます。
ユーザーが IAM エンティティを使用してワークロードにアクセスしていた場合は、この `Access Key details` セクションを使用して、IAM ロールまたはユーザーの詳細を識別できます。次のユーザータイプとその修復ガイダンスを参照してください。
**注記**
Amazon Detective を使用して、検出結果で特定された IAM ロールまたはユーザーをさらに調査できます。GuardDuty コンソールで検出結果の詳細を表示しているときに、**[Detective で調査]** を選択します。次に、リストされた項目から AWS ユーザーまたはロールを選択して、Detective で調査します。
**組み込みの Kubernetes 管理者** – クラスターを作成した IAM アイデンティティに Amazon EKS によって割り当てられたデフォルトのユーザー。このユーザータイプは、ユーザー名 `kubernetes-admin` で識別されます。
**組み込みの Kubernetes 管理者のアクセスを取り消すには:**
+ `Access Key details` セクションから `userType` を識別します。
+ `userType` が **[Role]** (ロール) であり、ロールが EC2 インスタンスロールに属している場合:
+ そのインスタンスを特定し、「[侵害された可能性のある Amazon EC2 インスタンスの修復](compromised-ec2.md)」の手順に従います。
+ `userType` が **[User]** (ユーザー) の場合、またはユーザーが引き受けた **[Role]** (ロール) の場合:
1. そのユーザーの[アクセスキーをローテーション](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)します。
1. ユーザーがアクセス権を有していたシークレットをローテーションします。
1. 詳細については、[「My AWS アカウント may be compromised](https://repost.aws/knowledge-center/potential-account-compromise)」の情報を確認してください。
**OIDC 認証済みユーザー** – OIDC プロバイダーを通じてアクセス権を付与されたユーザー。通常、OIDC ユーザーは、ユーザー名としてメールアドレスを持っています。次のコマンドを使用して、クラスターが OIDC を使用しているかどうかを確認できます: `aws eks list-identity-provider-configs --cluster-name your-cluster-name `。
**OIDC 認証済みユーザーのアクセスを取り消すには:**
1. OIDC プロバイダーでそのユーザーの認証情報をローテーションします。
1. ユーザーがアクセス権を有していたシークレットをローテーションします。
**AWS-Auth ConfigMap 定義ユーザー** – AWS認証 ConfigMap を通じてアクセス権が付与された IAM ユーザー。詳細については、「**Amazon EKS ユーザーガイド**」の「[Managing users or IAM roles for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)」を参照してください。次のコマンドを使用して、許可を確認できます: `kubectl edit configmaps aws-auth --namespace kube-system`。
** AWS ConfigMap ユーザーのアクセスを取り消すには:**
1. 次のコマンドを使用して、ConfigMap を開きます。
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. GuardDuty の検出結果の [Kubernetes user details] (Kubernetes ユーザー詳細) セクションで報告されたものと同じユーザー名で、**mapRoles** または **mapUsers** セクションの下のロールまたはユーザーエントリを特定します。次の例を参照してください。ここでは、管理者ユーザーが検出結果で特定されています。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
user name: system:node:EC2_PrivateDNSName
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::123456789012:user/admin
username: admin
groups:
- system:masters
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. そのユーザーを ConfigMap から削除します。管理者ユーザーが削除された次の例を参照してください。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. `userType` が **[User]** (ユーザー) の場合、またはユーザーが引き受けた **[Role]** (ロール) の場合:
1. そのユーザーの[アクセスキーをローテーション](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)します。
1. ユーザーがアクセス権を有していたシークレットをローテーションします。
1. 詳細については、[AWS 「アカウントが侵害されている可能性がある](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/)」の情報を確認してください。
検出結果に `resource.accessKeyDetails` セクションがない場合、ユーザーは Kubernetes サービスアカウントです。
**サービスアカウント** – サービスアカウントはポッドのアイデンティティを提供し、次の形式のユーザー名で識別できます: `system:serviceaccount:namespace:service_account_name`。
**サービスアカウントへのアクセス権を取り消すには:**
1. サービスアカウントの認証情報をローテーションします。
1. 次のセクションでポッドの侵害に関するガイダンスを確認します。
## 侵害された可能性のある Kubernetes ポッドの修復
GuardDuty が `resource.kubernetesDetails.kubernetesWorkloadDetails` セクション内のポッドまたはワークロードリソースの詳細を指定する場合、そのポッドまたはワークロードリソースが侵害されている可能性があります。GuardDuty の検出結果は、単一のポッドが侵害されたか、または上位レベルのリソースを介して複数のポッドが侵害されたことを示している場合があります。侵害されたポッドを特定する方法のガイダンスについては、次の侵害シナリオを参照してください。
**単一のポッドの侵害**
`resource.kubernetesDetails.kubernetesWorkloadDetails` セクション内の `type` フィールドが **[Pod]** (ポッド) である場合、検出結果は単一のポッドを特定します。名前フィールドはポッドの `name` であり、`namespace` フィールドはその名前空間です。
ポッドを実行しているワーカーノードの特定の詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify the offending pods and worker node](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node)」を参照してください。
**ワークロードリソースを通じて侵害されたポッド**
`type` セクション内の `resource.kubernetesDetails.kubernetesWorkloadDetails` フィールドが、`Deployment` などの **[Workload Resource]** (ワークロードリソース) を識別している場合、そのワークロードリソース内のすべてのポッドが侵害されている可能性があります。
ワークロードリソースのすべてのポッドとそれらが実行されているノードの特定の詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify the offending pods and worker nodes using workload name](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name)」を参照してください。
**サービスアカウントを通じて侵害されたポッド**
GuardDuty の検出結果が `resource.kubernetesDetails.kubernetesUserDetails` セクションでサービスアカウントを識別した場合、識別されたサービスアカウントを使用しているポッドが侵害されている可能性があります。検出結果によって報告されたユーザー名は、次の形式の場合はサービスアカウントです: `system:serviceaccount:namespace:service_account_name`。
サービスアカウントを使用しているすべてのポッドとそれらが実行されているノードの特定の詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify the offending pods and worker nodes using service account name](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_service_account_name)」を参照してください。
侵害されたポッドとそれらが実行されているノードをすべて特定したら、「*Amazon EKS Best Practices Guide*」の「[Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)」を参照してください。
**侵害されている可能性のあるポッドを修復するには:**
1. ポッドを侵害した脆弱性を特定します。
1. その脆弱性の修復を実装し、新しい代替ポッドを起動します。
1. 脆弱なポッドを削除します。
詳細については、「*Amazon EKS Best Practices Guide*」の「[Redeploy compromised pod or workload resource](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource)」を参照してください。
ワーカーノードに Pod が他の AWS リソースにアクセスできるようにする IAM ロールが割り当てられている場合は、攻撃によるさらなる損害を防ぐために、それらのロールをインスタンスから削除します。同様に、ポッドに IAM ロールが割り当てられている場合は、他のワークロードに影響を与えることなく、ロールから IAM ポリシーを安全に削除できるかどうかを評価します。
## 侵害された可能性のあるコンテナイメージの修復
GuardDuty の検出結果でポッドの侵害が示されている場合、ポッドの起動に使用されたイメージが潜在的に悪意があるものであるか、または侵害されている可能性があります。GuardDuty の検出結果では、`resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` フィールド内のコンテナイメージが識別されます。マルウェアがないかを調べるためにスキャンして、イメージが悪意のあるものであるかどうかを判断できます。
**侵害されたコンテナイメージを修復するには:**
1. 直ちにイメージの使用を停止し、イメージリポジトリから削除します。
1. 侵害された可能性のあるイメージを使用しているすべてのポッドを特定します。
詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify pods with vulnerable or compromised images and worker nodes](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes)」 を参照してください。
1. 侵害された可能性のあるポッドを分離し、認証情報をローテーションして、分析のためにデータを収集します。詳細については、*「Amazon EKS Best Practices Guide*」の「[Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)」を参照してください。
1. 侵害された可能性のあるイメージを使用しているすべてのポッドを削除します。
## 侵害された可能性のある Kubernetes ノードの修復
GuardDuty の検出結果は、検出結果で識別されたユーザーがノードアイデンティティを表す場合、または検出結果が特権コンテナの使用を示している場合、ノードの侵害を示している場合があります。
**[username]** (ユーザーネーム) フィールドの形式が次の場合、ユーザーアイデンティティはワーカーノードです: `system:node:node name`。例えば、`system:node:ip-192-168-3-201.ec2.internal`。これは、攻撃者がノードへのアクセスを取得し、ノードの認証情報を使用して Kubernetes API エンドポイントと通信していることを示すものです。
検出結果では、検出結果にリストされている 1 つ以上のコンテナの `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` 検出結果フィールドが `True` に設定されている場合に、特権コンテナの使用を示します。
**侵害されている可能性のあるノードを修復するには:**
1. ポッドを分離し、認証情報をローテーションして、フォレンジック分析のためにデータを収集します。
詳細については、*「Amazon EKS Best Practices Guide*」の「[Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)」を参照してください。
1. 侵害されている可能性のあるノードで実行されているすべてのポッドが使用するサービスアカウントを特定します。許可を確認し、必要に応じてサービスアカウントをローテーションします。
1. 侵害されている可能性のあるノードを終了します。