기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 작동 방식
런타임 모니터링을 사용하려면 런타임 모니터링을 사용 설정한 다음 GuardDuty 보안 에이전트를 관리해야 합니다. 다음 목록은 이 2단계 프로세스를 설명합니다.
1. GuardDuty가 Amazon EC2 인스턴스, Amazon ECS 클러스터 및 Amazon EKS 워크로드에서 수신하는 런타임 이벤트를 수락할 수 있도록 계정에 대한 **런타임 모니터링을 활성화**합니다.
1. 런타임 동작을 모니터링하려는 개별 리소스에 대해 **GuardDuty 에이전트**를 관리합니다. 리소스 유형에 따라 다음을 선택할 수 있습니다.
+ GuardDuty가 에이전트 배포를 관리하고 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트를 자동으로 관리하는 자동 에이전트 구성을 사용합니다.
+ 에이전트를 수동으로 관리하려면 VPC 엔드포인트를 사전 조건으로 생성해야 합니다.
보안 에이전트는 VPC 엔드포인트를 사용하여 이벤트를 GuardDuty에 전송하여 데이터가 AWS 네트워크 내에 유지되도록 합니다. 이 접근 방식은 보안을 강화하고 GuardDuty가 리소스(Amazon EKS, Amazon EC2 및 AWS Fargate Amazon ECS) 전반의 런타임 동작을 모니터링하고 분석할 수 있도록 합니다. GuardDuty는 각 리소스 유형의 보안 에이전트를 인증하는 [인스턴스 자격 증명 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#ec2-instance-identity-roles)을 사용하여 연결된 런타임 이벤트를 VPC 엔드포인트로 보냅니다.
**참고**
GuardDuty에서는 런타임 이벤트에 액세스할 수 없습니다.
EC2 인스턴스에 대한 EKS 런타임 모니터링 또는 런타임 모니터링에서 보안 에이전트를 (수동으로 또는 GuardDuty를 통해) 관리하고 GuardDuty가 현재 Amazon EC2 인스턴스에 배포되고이 인스턴스[수집된 런타임 이벤트 유형](runtime-monitoring-collected-events.md)에서를 수신하는 경우 GuardDuty는이 Amazon EC2 인스턴스의 VPC 흐름 로그 분석에 AWS 계정 대해에 요금을 부과하지 않습니다. 이렇게 하면 GuardDuty가 계정에서 두 배의 사용 비용을 방지할 수 있습니다.
다음 주제에서는 런타임 모니터링 활성화 및 GuardDuty 보안 에이전트 관리가 리소스 유형별로 어떻게 다르게 작동하는지 설명합니다.
**Topics**
+ [Amazon EKS 클러스터에서 Runtime Monitoring이 작동하는 방식](how-runtime-monitoring-works-eks.md)
+ [Amazon EC2 인스턴스에서 Runtime Monitoring이 작동하는 방식](how-runtime-monitoring-works-ec2.md)
+ [런타임 모니터링이 Fargate에서 작동하는 방식(Amazon ECS만 해당)](how-runtime-monitoring-works-ecs-fargate.md)
+ [런타임 모니터링을 활성화한 후](runtime-monitoring-after-configuration.md)
# Amazon EKS 클러스터에서 Runtime Monitoring이 작동하는 방식
런타임 모니터링은 GuardDuty 보안 에이전트라고도 하는 [EKS 애드온 기능 `aws-guardduty-agent`](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#workloads-add-ons-available-eks)을 사용합니다. GuardDuty 보안 에이전트가 EKS 클러스터에 배포되면 GuardDuty는 이러한 EKS 클러스터에 대한 런타임 이벤트를 수신할 수 있습니다.
**참고**
Runtime Monitoring은 Amazon EC2 인스턴스 및 Amazon EKS 자율 모드에서 실행되는 Amazon EKS 클러스터를 **지원합니다**.
Runtime Monitoring은 Amazon EKS Hybrid Nodes가 있는 Amazon EKS 클러스터와 AWS Fargate에서 실행되는 클러스터를 **지원하지 않습니다**.
Amazon EKS 기능에 관한 자세한 내용은 **Amazon EKS 사용 설명서**의 [Amazon EKS란 무엇입니까?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)를 참조하세요.
계정 또는 클러스터 수준에서 Amazon EKS 클러스터의 런타임 이벤트를 모니터링할 수 있습니다. 위협 탐지를 위해 모니터링하려는 Amazon EKS 클러스터에 대해서만 GuardDuty 보안 에이전트를 관리할 수 있습니다. GuardDuty 보안 에이전트는 수동으로 관리하거나 자동 에이전트 구성을 사용하여 GuardDuty가 사용자를 대신하여 관리하도록 허용하여 관리할 수 있습니다.
자동 에이전트 구성 접근 방식을 사용하여 GuardDuty가 사용자를 대신하여 보안 에이전트의 배포를 관리할 수 있도록 하면 ** Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트가 자동으로 생성**됩니다. 보안 에이전트는 이 Amazon VPC 엔드포인트를 사용하여 런타임 이벤트를 GuardDuty에 전달합니다.
VPC 엔드포인트와 함께 GuardDuty는 새 보안 그룹도 생성합니다. 인바운드(인그레스) 규칙은 보안 그룹과 연결된 리소스에 도달할 수 있는 트래픽을 제어합니다. GuardDuty는 리소스의 VPC CIDR 범위와 일치하는 인바운드 규칙을 추가하고 CIDR 범위가 변경될 때도 이에 적응합니다. 자세한 내용은 *Amazon VPC 사용 설명서*에서 [VPC CIDR 범위](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)를 참조하세요.
**참고**
VPC 엔드포인트 사용에 대한 추가 비용은 없습니다.
자동화 에이전트를 사용하여 중앙 집중식 VPC 작업 - 리소스 유형에 GuardDuty 자동화 에이전트 구성을 사용하는 경우 GuardDuty는 모든 VPC에 대해 사용자를 대신하여 VPCs 엔드포인트를 생성합니다. 여기에는 중앙 집중식 VPC 및 스포크 VPCs 포함됩니다. GuardDuty는 중앙 집중식 VPC에 대해서만 VPC 엔드포인트 생성을 지원하지 않습니다. 중앙 집중식 VPC의 작동 방식에 대한 자세한 내용은 백서 - 확장 가능하고 안전한 다중 [VPC 네트워크 인프라 구축의 인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints)를 참조하세요. *AWS AWS *
## Amazon EKS 클러스터에서 GuardDuty 보안 에이전트를 관리하는 방법
2023년 9월 13일 이전에는 계정 수준에서 보안 에이전트를 관리하도록 GuardDuty를 구성할 수 있었습니다. 이 동작은 기본적으로 GuardDuty에서 AWS 계정에 속하는 모든 EKS 클러스터의 보안 에이전트를 관리함을 나타냅니다. 이제 GuardDuty에서 보안 에이전트를 관리할 EKS 클러스터를 선택하는 데 도움이 되도록 세분화된 기능이 제공됩니다.
[GuardDuty 보안 에이전트를 수동으로 관리](#eks-runtime-using-gdu-agent-manually) 방법을 선택한 경우에도 모니터링하려는 EKS 클러스터를 선택할 수 있습니다. 그러나 에이전트를 수동으로 관리하려면에 대한 Amazon VPC 엔드포인트를 생성 AWS 계정 해야 합니다.
**참고**
GuardDuty 보안 에이전트를 관리하는 데 사용하는 접근 방식과 무관하게 EKS 런타임 모니터링은 계정 수준에서 항상 활성화됩니다.
**Topics**
+ [GuardDuty를 통한 보안 에이전트 관리](#eks-runtime-using-gdu-agent-management-auto)
+ [GuardDuty 보안 에이전트를 수동으로 관리](#eks-runtime-using-gdu-agent-manually)
### GuardDuty를 통한 보안 에이전트 관리
GuardDuty는 사용자를 대신하여 보안 에이전트를 배포 및 관리합니다. 언제든 다음 접근 방식 중 하나를 사용하여 계정의 EKS 클러스터를 모니터링할 수 있습니다.
**Topics**
+ [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)
+ [선택적 EKS 클러스터 제외](#eks-runtime-using-exclusion-tags)
+ [선택적 EKS 클러스터 포함](#eks-runtime-using-inclusion-tags)
#### 모든 EKS 클러스터 모니터링
GuardDuty에서 계정의 모든 EKS 클러스터에 대해 보안 에이전트를 배포 및 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 기본적으로 GuardDuty는 사용자 계정에 생성된 잠재적으로 새로운 EKS 클러스터에도 보안 에이전트를 배포합니다.
**이 접근 방식을 사용할 때의 영향**
+ GuardDuty는 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트를 생성하여, 이 엔드포인트를 통해 GuardDuty 보안 에이전트는 GuardDuty에 런타임 이벤트를 제공합니다. GuardDuty를 통해 보안 에이전트를 관리하는 경우 Amazon VPC 엔드포인트 생성에 따른 추가 비용은 없습니다.
+ 워커 노드에 활성 `guardduty-data` VPC 엔드포인트에 대해 유효한 네트워크 경로가 있어야 합니다. GuardDuty는 EKS 클러스터에 보안 에이전트를 배포합니다. Amazon Elastic Kubernetes Service(Amazon EKS)는 EKS 클러스터 내의 노드에 보안 에이전트 배포를 조정합니다.
+ GuardDuty는 IP 가용성을 기반으로 VPC 엔드포인트를 생성할 서브넷을 선택합니다. 고급 네트워크 토폴로지를 사용하는 경우 연결이 가능한지 검증해야 합니다.
#### 선택적 EKS 클러스터 제외
GuardDuty에서 계정의 모든 EKS 클러스터에 대해(단, 선택적 EKS 클러스터 제외) 보안 에이전트를 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 이 방법은 런타임 이벤트를 수신하지 않으려는 EKS 클러스터에 태그를 지정할 수 있는 태그 기반[1](#eks-runtime-inclusion-exclusion-tags) 접근 방식을 사용합니다. 사전 정의된 태그에는 키-값 쌍으로 `GuardDutyManaged`-`false`가 있어야 합니다.
**이 접근 방식을 사용할 때의 영향**
이 방법을 사용하려면 모니터링에서 제외하려는 EKS 클러스터에 태그를 추가한 후에만 GuardDuty 에이전트 자동 관리를 활성화해야 합니다.
따라서 [GuardDuty를 통한 보안 에이전트 관리](#eks-runtime-using-gdu-agent-management-auto)의 영향이 이 접근 방식에도 적용됩니다. GuardDuty 에이전트 자동 관리를 활성화하기 전에 태그를 추가하면 GuardDuty는 모니터링에서 제외된 EKS 클러스터의 보안 에이전트를 배포하지도 않고 관리하지도 않습니다.
**고려 사항**
+ 자동 에이전트 구성을 활성화하기 전에 선택적 EKS 클러스터에 대해 태그 키-값 쌍을 `GuardDutyManaged`:`false`로 추가해야 합니다. 그렇지 않으면 태그를 사용할 때까지 GuardDuty 보안 에이전트가 모든 EKS 클러스터에 배포됩니다.
+ 신뢰할 수 있는 ID를 제외하고는 태그가 수정되지 않도록 해야 합니다.
**중요**
서비스 제어 정책 또는 IAM 정책을 사용하여 EKS 클러스터의 `GuardDutyManaged` 태그 값을 수정하는 권한을 관리합니다. 자세한 내용은AWS Organizations 사용 설명서**의 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 또는 IAM 사용 설명서**의 [AWS 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)를 참조하세요.
+ 모니터링하지 않으려는 잠재적으로 새로운 EKS 클러스터의 경우 이 EKS 클러스터를 생성할 때 `GuardDutyManaged`-`false` 키-값 쌍을 추가해야 합니다.
+ 이 접근 방식에도 [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)에 대해 지정된 것과 동일한 고려 사항이 적용됩니다.
#### 선택적 EKS 클러스터 포함
GuardDuty에서 계정의 선택적 EKS 클러스터에 대해서만 보안 에이전트를 배포하고 업데이트를 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 이 방법은 런타임 이벤트를 수신하려는 EKS 클러스터에 태그를 지정할 수 있는 태그 기반[1](#eks-runtime-inclusion-exclusion-tags) 접근 방식을 사용합니다.
**이 접근 방식을 사용할 때의 영향**
+ 포함 태그를 사용하면 GuardDuty는 키-값 쌍으로 `GuardDutyManaged`-`true` 태그가 지정된 선택적 EKS 클러스터에 대해서만 보안 에이전트를 자동으로 배포 및 관리합니다.
+ 이 접근 방식을 사용해도 [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)에 대해 지정된 것과 동일한 영향을 미칩니다.
**고려 사항**
+ `GuardDutyManaged` 태그의 값이 `true`로 설정되지 않으면 포함 태그가 예상대로 작동하지 않고 EKS 클러스터 모니터링에 영향을 미칠 수 있습니다.
+ 선택적 EKS 클러스터가 모니터링되도록 신뢰할 수 있는 ID를 제외하고는 태그가 수정되지 않도록 해야 합니다.
**중요**
서비스 제어 정책 또는 IAM 정책을 사용하여 EKS 클러스터의 `GuardDutyManaged` 태그 값을 수정하는 권한을 관리합니다. 자세한 내용은AWS Organizations 사용 설명서**의 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 또는 IAM 사용 설명서**의 [AWS 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)를 참조하세요.
+ 모니터링하지 않으려는 잠재적으로 새로운 EKS 클러스터의 경우 이 EKS 클러스터를 생성할 때 `GuardDutyManaged`-`false` 키-값 쌍을 추가해야 합니다.
+ 이 접근 방식에도 [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)에 대해 지정된 것과 동일한 고려 사항이 적용됩니다.
1 선택적 EKS 클러스터의 태그 지정에 대한 자세한 내용은 Amazon EKS 사용 설명서****의 [Amazon EKS 리소스 태깅](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html)을 참조하세요.
### GuardDuty 보안 에이전트를 수동으로 관리
GuardDuty에서 모든 EKS 클러스터에 수동으로 보안 에이전트를 배포 및 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 계정에 EKS 런타임 모니터링이 활성화되어 있어야 합니다. EKS 런타임 모니터링을 활성화하지 않으면 GuardDuty 보안 에이전트가 예상대로 작동하지 않을 수 있습니다.
**이 접근 방식을 사용할 때의 영향**
모든 계정 및이 기능을 사용할 수 AWS 리전 있는 EKS 클러스터 내에서 GuardDuty 보안 에이전트의 배포를 조정해야 합니다. 또한 GuardDuty가 릴리스할 때 에이전트 버전을 업데이트해야 합니다. EKS용 에이전트 버전에 대한 자세한 내용은 [Amazon EKS 리소스용 GuardDuty 보안 에이전트 버전](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)을 참조하세요.
**고려 사항**
새 클러스터와 워크로드가 지속적으로 배포되는 상황에서 적용 범위 격차를 모니터링하고 해결하면서 안전한 데이터 흐름을 지원해야 합니다.
# Amazon EC2 인스턴스에서 Runtime Monitoring이 작동하는 방식
Amazon EC2 인스턴스는 AWS 환경에서 여러 유형의 애플리케이션 및 워크로드를 실행할 수 있습니다. 런타임 모니터링을 활성화하고 GuardDuty 보안 에이전트를 관리하면 GuardDuty는 기존 Amazon EC2 인스턴스와 잠재적으로 새로운 인스턴스의 위협을 탐지하는 데 도움이 됩니다. 이 기능은 Amazon ECS 관리형 Amazon EC2 인스턴스도 지원합니다. 자세한 내용은 [Guardduty의 관리형 인스턴스 지원을 참조하세요](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_managed-instances.html).
**참고**
Runtime Monitoring은 [Amazon ECS 관리형 인스턴스](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html)에서 실행되는 애플리케이션을 지원하지 않습니다.
런타임 모니터링을 활성화하면 GuardDuty가 Amazon EC2 인스턴스 내에서 현재 실행 중인 및 새 프로세스에서 런타임 이벤트를 사용할 준비가 됩니다. GuardDuty를 사용하려면 보안 에이전트가 EC2 인스턴스에서 GuardDuty 로 런타임 이벤트를 보내야 합니다.
Amazon EC2 인스턴스의 경우 GuardDuty 보안 에이전트는 인스턴스 수준에서 작동합니다. 계정의 Amazon EC2 인스턴스를 모두 모니터링할지 아니면 선택적으로 모니터링할지 결정할 수 있습니다. 선택적 인스턴스를 관리하려는 경우 보안 에이전트는 이러한 인스턴스에만 필요합니다.
GuardDuty는 Amazon ECS 클러스터 내의 Amazon EC2 인스턴스에서 실행되는 새 작업 및 기존 작업에서 런타임 이벤트를 사용할 수도 있습니다.
GuardDuty 보안 에이전트를 설치하기 위해 런타임 모니터링은 다음 두 가지 옵션을 제공합니다.
+ [자동 에이전트 구성 사용(권장)](#use-automated-agent-config-ec2) 또는
+ [수동으로 보안 에이전트 관리](#ec2-security-agent-option2-manual)
## GuardDuty를 통한 자동 에이전트 구성 사용(권장)
GuardDuty가 사용자를 대신하여 Amazon EC2 인스턴스에 보안 에이전트를 설치할 수 있도록 허용하는 자동 에이전트 구성을 사용합니다. GuardDuty는 보안 에이전트에 대한 업데이트도 관리합니다.
기본적으로 GuardDuty는 계정의 모든 인스턴스에 보안 에이전트를 설치합니다. GuardDuty가 선택한 EC2 인스턴스에 대해서만 보안 에이전트를 설치하고 관리하도록 하려면 필요에 따라 EC2 인스턴스에 포함 또는 제외 태그를 추가합니다.
경우에 따라 계정에 속한 모든 Amazon EC2 인스턴스에 대한 런타임 이벤트를 모니터링하지 않을 수 있습니다. 제한된 수의 인스턴스에 대한 런타임 이벤트를 모니터링하려는 경우 선택한 인스턴스에 포함 태그를 `GuardDutyManaged`:`true`로 추가합니다. Amazon EC2에 대한 자동 에이전트 구성의 가용성부터 EC2 인스턴스에 포함 태그(`GuardDutyManaged`:`true`)가 있는 경우 GuardDuty는 태그를 적용하고 자동 에이전트 구성을 명시적으로 활성화하지 않은 경우에도 선택한 인스턴스에 대한 보안 에이전트를 관리합니다.
반면 런타임 이벤트를 모니터링하지 않으려는 EC2 인스턴스 수가 제한적인 경우 선택한 인스턴스에 제외 태그(`GuardDutyManaged`:`false`)를 추가합니다. GuardDuty는 이러한 EC2 리소스에 대한 보안 에이전트를 **설치하거나** **관리하지 않음**으로써 제외 태그를 존중합니다.
### 영향
AWS 계정 또는 조직에서 자동 에이전트 구성을 사용하는 경우 GuardDuty가 사용자를 대신하여 다음 단계를 수행하도록 허용합니다.
+ GuardDuty는 SSM이 관리되고 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 콘솔의 **Fleet Manager**에 표시되는 모든 Amazon EC2 인스턴스에 대해 하나의 SSM 연결을 생성합니다.
+ 자동 에이전트 구성이 비활성화된 상태에서 포함 태그 사용 - 런타임 모니터링을 활성화한 후 자동 에이전트 구성을 활성화하지 않고 Amazon EC2 인스턴스에 포함 태그를 추가하면 GuardDuty가 사용자를 대신하여 보안 에이전트를 관리하도록 허용하는 것입니다. 그러면 SSM 연결에서 포함 태그(`GuardDutyManaged`:`true`)가 있는 각 인스턴스에 보안 에이전트를 설치합니다.
+ 자동 에이전트 구성을 활성화하는 경우 - SSM 연결은 계정에 속한 모든 EC2 인스턴스에 보안 에이전트를 설치합니다.
+ 자동 에이전트 구성에서 제외 태그 사용 - 자동 에이전트 구성을 활성화하기 전에 Amazon EC2 인스턴스에 제외 태그를 추가할 때 GuardDuty가 선택한 인스턴스의 보안 에이전트를 설치하고 관리하는 것을 방지하도록 허용해야 합니다.
이제 자동 에이전트 구성을 활성화하면 SSM 연결은 제외 태그로 태그가 지정된 인스턴스를 제외한 모든 EC2 인스턴스에 보안 에이전트를 설치하고 관리합니다.
+ GuardDuty는 VPC에 종료 또는 종료 인스턴스 상태가 아닌 Linux EC2 인스턴스가 하나 이상 있는 한 공유 VPCs를 VPCs 포함한 모든 VPC 에서 VPC 엔드포인트를 생성합니다. 여기에는 중앙 집중식 VPC 및 스포크 VPCs 포함됩니다. GuardDuty는 중앙 집중식 VPC에 대해서만 VPC 엔드포인트 생성을 지원하지 않습니다. 중앙 집중식 VPC의 작동 방식에 대한 자세한 내용은 백서 - 확장 가능하고 안전한 다중 [VPC 네트워크 인프라 구축의 인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints)를 참조하세요. *AWS AWS *
다양한 인스턴스 상태에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 수명 주기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html)를 참조하세요.
GuardDuty는 [Runtime Monitoring과 함께 공유 VPC 사용](runtime-monitoring-shared-vpc.md)도 지원합니다. 조직에 대한 모든 사전 조건이 고려되고 AWS 계정 GuardDuty는 공유 VPC를 사용하여 런타임 이벤트를 수신합니다.
**참고**
VPC 엔드포인트 사용에 대한 추가 비용은 없습니다.
+ VPC 엔드포인트와 함께 GuardDuty는 새 보안 그룹도 생성합니다. 인바운드(인그레스) 규칙은 보안 그룹과 연결된 리소스에 도달할 수 있는 트래픽을 제어합니다. GuardDuty는 리소스의 VPC CIDR 범위와 일치하는 인바운드 규칙을 추가하고 CIDR 범위가 변경될 때도 이에 적응합니다. 자세한 내용은 *Amazon VPC 사용 설명서*에서 [VPC CIDR 범위](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)를 참조하세요.
## 수동으로 보안 에이전트 관리
Amazon EC2의 보안 에이전트를 수동으로 관리하는 방법은 두 가지가 있습니다.
+ 의 GuardDuty 관리형 문서를 사용하여 이미 SSM 관리형 Amazon EC2 인스턴스에 보안 에이전트를 AWS Systems Manager 설치합니다.
새 Amazon EC2 인스턴스를 시작할 때마다 SSM이 활성화되어 있는지 확인합니다.
+ RPM 패키지 관리자(RPM) 스크립트를 사용하여 SSM 관리 여부와 관계없이 Amazon EC2 인스턴스에 보안 에이전트를 설치합니다.
## 다음 단계
Amazon EC2 인스턴스를 모니터링하기 위한 런타임 모니터링 구성을 시작하려면 [Amazon EC2 인스턴스 지원의 사전 조건](prereq-runtime-monitoring-ec2-support.md)을 참조하세요.
# 런타임 모니터링이 Fargate에서 작동하는 방식(Amazon ECS만 해당)
런타임 모니터링을 활성화하면 GuardDuty가 태스크에서 런타임 이벤트를 사용할 준비가 됩니다. 이러한 작업은 Amazon ECS 클러스터 내에서 실행되며, 그러면 AWS Fargate 인스턴스에서 실행됩니다. GuardDuty가 이러한 런타임 이벤트를 수신하려면 완전히 관리되는 전용 보안 에이전트를 사용해야 합니다.
**참고**
Runtime Monitoring은 [Amazon ECS 관리형 인스턴스](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html)에서 실행되는 애플리케이션을 지원하지 않습니다.
AWS 계정 또는 조직의 자동 에이전트 구성을 사용하여 GuardDuty가 사용자를 대신하여 GuardDuty 보안 에이전트를 관리하도록 허용할 수 있습니다. GuardDuty는 Amazon ECS 클러스터에서 시작된 새 Fargate 작업에 보안 에이전트를 배포하기 시작합니다. 다음 목록은 GuardDuty 보안 에이전트를 활성화할 때 예상되는 사항을 지정합니다.**GuardDuty 보안 에이전트 활성화의 영향**
**GuardDuty가 Virtual Private Cloud(VPC) 엔드포인트 및 보안 그룹 생성**
+ GuardDuty 보안 에이전트를 배포하면 GuardDuty는 보안 에이전트가 GuardDuty 에 런타임 이벤트를 전달하는 VPC 엔드포인트를 생성합니다.
VPC 엔드포인트와 함께 GuardDuty는 새 보안 그룹도 생성합니다. 인바운드(인그레스) 규칙은 보안 그룹과 연결된 리소스에 도달할 수 있는 트래픽을 제어합니다. GuardDuty는 리소스의 VPC CIDR 범위와 일치하는 인바운드 규칙을 추가하고 CIDR 범위가 변경될 때도 이에 적응합니다. 자세한 내용은 *Amazon VPC 사용 설명서*에서 [VPC CIDR 범위](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)를 참조하세요.
+ 자동화 에이전트를 사용하여 중앙 집중식 VPC 작업 - 리소스 유형에 GuardDuty 자동화 에이전트 구성을 사용하는 경우 GuardDuty는 모든 VPC에 대해 사용자를 대신하여 VPCs 엔드포인트를 생성합니다. 여기에는 중앙 집중식 VPC 및 스포크 VPCs 포함됩니다. GuardDuty는 중앙 집중식 VPC에 대해서만 VPC 엔드포인트 생성을 지원하지 않습니다. 중앙 집중식 VPC의 작동 방식에 대한 자세한 내용은 백서 - 확장 가능하고 안전한 다중 [VPC 네트워크 인프라 구축의 인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints)를 참조하세요. *AWS AWS *
+ VPC 엔드포인트 사용에 대한 추가 비용은 없습니다.
**GuardDuty가 사이드카 컨테이너 추가**
실행을 시작하는 새 Fargate 태스크 또는 서비스의 경우 GuardDuty 컨테이너(사이드카)가 Amazon ECS Fargate 태스크 내의 각 컨테이너에 연결됩니다. GuardDuty 보안 에이전트는 연결된 GuardDuty 컨테이너 내에서 실행됩니다. 이를 통해 GuardDuty는 이러한 작업 내에서 실행되는 각 컨테이너의 런타임 이벤트를 수집할 수 있습니다.
GuardDuty 사이드카 컨테이너 이미지는 Amazon S3에 저장된 이미지 계층과 함께 Amazon Elastic Container Registry(Amazon ECR)에 저장됩니다. 작업이 시작되면 ECR에서 이 이미지를 가져와야 합니다. 네트워크 구성에 따라 ECR과 S3 모두에 액세스할 수 있도록 별도의 설정이 필요할 수 있습니다. 예를 들어 액세스가 제한된 보안 그룹을 사용하는 경우 S3 관리형 접두사 목록에 대한 액세스를 허용해야 합니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 [컨테이너 이미지 액세스를 위한 사전 조건](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs) 단원을 참조하세요.
Fargate 작업을 시작할 때 GuardDuty 컨테이너(사이드카)가 정상 상태에서 시작할 수 없는 경우 런타임 모니터링은 작업이 실행되지 않도록 설계되었습니다.
기본적으로 Fargate 작업은 변경할 수 없습니다. GuardDuty는 작업이 이미 실행 중 상태일 때 사이드카를 배포하지 않습니다. 이미 실행 중인 작업에서 컨테이너를 모니터링하려면 작업을 중지하고 다시 시작할 수 있습니다.
## Amazon ECS-Fargate 리소스에서 GuardDuty 보안 에이전트를 관리하는 방법
런타임 모니터링은 계정의 모든 Amazon ECS 클러스터(계정 수준) 또는 선택적 클러스터(클러스터 수준)에서 잠재적 보안 위협을 탐지하는 옵션을 제공합니다. 실행할 각 Amazon ECS Fargate 작업에 대해 자동 에이전트 구성을 활성화하면 GuardDuty는 해당 작업 내의 각 컨테이너 워크로드에 사이드카 컨테이너를 추가합니다. GuardDuty 보안 에이전트가 이 사이드카 컨테이너에 배포됩니다. 이것이 GuardDuty가 Amazon ECS 작업 내 컨테이너의 런타임 동작을 볼 수 있는 방법입니다.
런타임 모니터링은 GuardDuty 를 통해서만 Amazon ECS 클러스터(AWS Fargate)의 보안 에이전트 관리를 지원합니다. Amazon ECS 클러스터에서 보안 에이전트를 수동으로 관리하는 것은 지원되지 않습니다.
계정을 구성하기 전에 Amazon ECS 태스크에 속하는 모든 컨테이너의 런타임 동작을 모니터링할지 또는 특정 리소스를 포함하거나 제외할지 평가합니다. 다음 접근 방식을 고려합니다.
**모든 Amazon ECS 클러스터 모니터링**
이 접근 방식은 계정 수준에서 잠재적 보안 위협을 탐지하는 데 도움이 됩니다. GuardDuty가 계정에 속한 모든 Amazon ECS 클러스터에 대한 잠재적 보안 위협을 탐지하도록 하려면 이 접근 방식을 사용합니다.
**특정 Amazon ECS 클러스터 제외**
GuardDuty가 AWS 환경의 대부분의 Amazon ECS 클러스터에 대한 잠재적 보안 위협을 탐지하되 일부 클러스터를 제외하도록 하려면이 접근 방식을 사용합니다. 이 접근 방식을 사용하면 클러스터 수준에서 Amazon ECS 작업 내 컨테이너의 런타임 동작을 모니터링할 수 있습니다. 예를 들어 계정에 속한 Amazon ECS 클러스터 수는 1000개입니다. 하지만 Amazon ECS 클러스터는 930개만 모니터링하려고 합니다.
이 접근 방식을 사용하려면 모니터링하지 않으려는 Amazon ECS 클러스터에 사전 정의된 GuardDuty 태그를 추가해야 합니다. 자세한 내용은 [Fargate용 자동 보안 에이전트 관리(Amazon ECS만 해당)](managing-gdu-agent-ecs-automated.md) 단원을 참조하십시오.
**특정 Amazon ECS 클러스터 포함**
GuardDuty가 일부 Amazon ECS 클러스터에 대한 잠재적 보안 위협을 탐지하도록 하려면 이 접근 방식을 사용합니다. 이 접근 방식을 사용하면 클러스터 수준에서 Amazon ECS 작업 내 컨테이너의 런타임 동작을 모니터링할 수 있습니다. 예를 들어 계정에 속한 Amazon ECS 클러스터 수는 1000개입니다. 하지만 클러스터 230개만 모니터링하려고 합니다.
이 접근 방식을 사용하려면 모니터링하려는 Amazon ECS 클러스터에 사전 정의된 GuardDuty 태그를 추가해야 합니다. 자세한 내용은 [Fargate용 자동 보안 에이전트 관리(Amazon ECS만 해당)](managing-gdu-agent-ecs-automated.md) 단원을 참조하십시오.
# 런타임 모니터링을 활성화한 후
런타임 모니터링을 활성화하고 독립 실행형 계정 또는 여러 멤버 계정에 GuardDuty 보안 에이전트를 설치한 후 다음 단계를 수행하여 보호 계획 설정이 예상대로 작동하는지 확인하고 GuardDuty 보안 에이전트가 사용하는 메모리 및 CPU의 양을 모니터링할 수 있습니다.
**런타임 범위 평가**
GuardDuty는 보안 에이전트를 배포한 리소스의 적용 범위 상태를 지속적으로 평가할 것을 권장합니다. 적용 범위는 **정상** 또는 **비정상**일 수 있습니다. **정상** 적용 상태는 운영 체제 수준 활동이 있을 때 GuardDuty가 해당 리소스로부터 런타임 이벤트를 수신하고 있음을 나타냅니다.
리소스의 적용 범위 상태가 **정상**이 되면 GuardDuty는 런타임 이벤트를 수신하고 위협 탐지를 위해 분석할 수 있습니다. GuardDuty가 컨테이너 워크로드 및 인스턴스에서 실행되는 태스크 또는 애플리케이션에서 잠재적 보안 위협을 감지하면 GuardDuty가 [GuardDuty 런타임 모니터링 조사 결과 유형](findings-runtime-monitoring.md)를 생성합니다.
적용 범위가 **비정상**에서 **정상**으로 변경되는 경우 알림을 받도록 Amazon EventBridge(EventBridge)를 구성할 수도 있습니다. 자세한 내용은 [런타임 범위 통계 검토 및 문제 해결](runtime-monitoring-assessing-coverage.md) 단원을 참조하십시오.
**GuardDuty 보안 에이전트에 대한 CPU 및 메모리 모니터링 설정**
적용 범위 상태가 **정상**으로 표시되는지 평가한 후 리소스 유형에 대한 보안 에이전트의 성능을 평가할 수 있습니다. 보안 에이전트 릴리스 v1.5 이상이 있는 Amazon EKS 클러스터의 경우 GuardDuty는 (추가 기능) 보안 에이전트의 파라미터 구성을 지원합니다. 자세한 내용은 [CPU 및 메모리 모니터링 설정](runtime-monitoring-setting-cpu-mem-monitoring.md) 단원을 참조하십시오.
**GuardDuty가 잠재적 위협 탐지**
GuardDuty가 리소스에 대한 런타임 이벤트를 수신하기 시작하면 해당 이벤트를 분석하기 시작합니다. GuardDuty가 Amazon EC2 인스턴스, Amazon ECS 클러스터 또는 Amazon EKS 클러스터에서 잠재적 보안 위협을 감지하면 하나 이상의 [GuardDuty 런타임 모니터링 조사 결과 유형](findings-runtime-monitoring.md)를 생성합니다. 조사 결과 세부 정보에 액세스하여 영향을 받는 리소스 세부 정보를 볼 수 있습니다.