기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 런타임 모니터링을 활성화하기 위한 사전 조건 런타임 모니터링을 사용 설정하고 GuardDuty 보안 에이전트를 관리하려면 위협 탐지를 위해 모니터링하려는 각 리소스 유형에 대한 사전 요구 사항을 충족해야 합니다. 각 리소스 유형에는 서로 다른 사전 조건이 있습니다. 예를 들어 GuardDuty는 리소스 유형에 따라 다양한 OS 배포를 지원합니다. Amazon EC2 리소스만 모니터링하려는 경우 Amazon EC2 인스턴스에 대한 전제 조건을 따릅니다. 나중에 Amazon EKS 리소스를 모니터링하기로 선택한 경우, Amazon EKS 클러스터와 관련된 전제 조건을 따라야 합니다. 다음 섹션에는 리소스 유형에 따른 사전 조건이 포함되어 있습니다. **Topics** + [Amazon EC2 인스턴스 지원의 사전 조건](prereq-runtime-monitoring-ec2-support.md) + [AWS Fargate (Amazon ECS만 해당) 지원을 위한 사전 조건](prereq-runtime-monitoring-ecs-support.md) + [Amazon EKS 클러스터 지원을 위한 사전 조건](prereq-runtime-monitoring-eks-support.md) # Amazon EC2 인스턴스 지원의 사전 조건 이 섹션에는 Amazon EC2 인스턴스의 런타임 동작을 모니터링하기 위한 전제 조건이 포함되어 있습니다. 이러한 사전 요구 사항이 충족되면 [GuardDuty 런타임 모니터링 활성화](runtime-monitoring-configuration.md)을 참조하세요. **Topics** + [EC2 인스턴스를 SSM 관리형으로 설정(자동화된 에이전트 구성 전용)](#ssm-managed-prereq-ec2) + [아키텍처 요구 사항 검증](#validating-architecture-req-ec2) + [다중 계정 환경에서 조직 서비스 제어 정책 검증](#validate-organization-scp-ec2) + [자동 에이전트 구성을 사용하는 경우](#runtime-ec2-prereq-automated-agent) + [GuardDuty 에이전트의 CPU 및 메모리 제한](#ec2-cpu-memory-limits-gdu-agent) + [다음 단계](#next-step-after-prereq-ec2) ## EC2 인스턴스를 SSM 관리형으로 설정(자동화된 에이전트 구성 전용) GuardDuty는 AWS Systems Manager (SSM)를 사용하여 인스턴스에 보안 에이전트를 자동으로 배포, 설치 및 관리합니다. GuardDuty 에이전트를 수동으로 설치하고 관리하려는 경우 SSM이 필요하지 않습니다. 시스템 관리자를 사용하여 Amazon EC2 인스턴스를 관리하려면*AWS Systems Manager 사용 설명서*의 [Amazon EC2 인스턴스용 Systems Manager 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)을 참조하세요. ## 아키텍처 요구 사항 검증 OS 배포의 아키텍처에 따라 GuardDuty 보안 에이전트의 작동 방식에 영향을 미칠 수 있습니다. Amazon EC2 인스턴스에 대한 런타임 모니터링을 사용하려면 다음 요구 사항을 충족해야 합니다. + 커널 지원에는 `eBPF`, `Tracepoints` 및 `Kprobe`가 포함됩니다. CPU 아키텍처의 경우 Runtime Monitoring은 AMD64(`x64`) 및 ARM64(Graviton2 이상)[1](#runtime-monitoring-ec2-graviton-2-support)를 지원합니다. 다음 표는 Amazon EC2 인스턴스에 대해 GuardDuty 보안 에이전트를 지원하는 것으로 확인된 OS 배포를 보여줍니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) 1. Amazon EC2 리소스에 대한 Runtime Monitoring은 A1 인스턴스 유형과 같은 1세대 Graviton 인스턴스를 지원하지 않습니다. 1. 다양한 운영 체제 지원 - GuardDuty는 상기 표에 기재된 운영 체제 배포판에 대한 Runtime Monitoring 지원을 검증했습니다. GuardDuty 보안 에이전트가 위 표에 나열되지 않은 운영 체제에서 실행될 수 있지만 GuardDuty 팀이 예상 보안 값을 보장할 수는 없습니다. 1. 커널 버전의 경우 `CONFIG_DEBUG_INFO_BTF` 플래그를 `y`(*true* 의미)로 설정해야 합니다. 이는 GuardDuty 보안 에이전트가 예상대로 실행될 수 있도록 하기 위해 필요합니다. 1. 커널 버전 5.10 이하의 경우 GuardDuty 보안 에이전트는 RAM의 잠긴 메모리(`RLIMIT_MEMLOCK`)를 사용하여 예상대로 작동합니다. 시스템의 `RLIMIT_MEMLOCK` 값이 너무 낮게 설정된 경우 GuardDuty는 하드 제한과 소프트 제한을 모두 32MB 이상으로 설정할 것을 권장합니다. 기본 `RLIMIT_MEMLOCK` 값 확인 및 수정에 대한 자세한 내용은 [`RLIMIT_MEMLOCK` 값 확인 및 업데이트](#runtime-monitoring-ec2-modify-rlimit-memlock) 섹션을 참조하세요. 1. Ubuntu 24.04의 경우 커널 버전 6.13 및 6.14는 EC2 에이전트 버전 1.9.2 이상만 지원합니다. + 추가 요구 사항 - Amazon ECS/Amazon EC2가 있는 경우에만 해당 Amazon ECS/Amazon EC2의 경우 최신 Amazon ECS에 최적화된 AMI(2023년 9월 29일 이후 날짜)를 사용하거나 Amazon ECS 에이전트 버전 v1.77.0을 사용하는 것이 좋습니다. ### `RLIMIT_MEMLOCK` 값 확인 및 업데이트 시스템의 `RLIMIT_MEMLOCK` 제한이 너무 낮게 설정되면 GuardDuty 보안 에이전트가 설계된 대로 작동하지 않을 수 있습니다. GuardDuty 권장 사항에 따르면 하드 제한과 소프트 제한이 모두 32MB 이상이어야 합니다. 제한을 업데이트하지 않으면 GuardDuty가 리소스의 런타임 이벤트를 모니터링할 수 없습니다. `RLIMIT_MEMLOCK`이 명시된 최소 제한을 초과하면 이러한 제한을 업데이트하는 것은 선택 사항이 됩니다. GuardDuty 보안 에이전트를 설치하기 전이나 후에 기본 `RLIMIT_MEMLOCK` 값을 수정할 수 있습니다. **`RLIMIT_MEMLOCK` 값을 보려면** 1. `ps aux | grep guardduty`를 실행합니다. 이를 통해 프로세스 ID(`pid`)가 출력됩니다. 1. 이전 명령의 출력에서 프로세스 ID(`pid`)를 복사합니다. 1. `pid`를 이전 단계에서 복사한 프로세스 ID로 바꾼 후 `grep "Max locked memory" /proc/pid/limits`를 실행합니다. 그러면 GuardDuty 보안 에이전트를 실행하기 위한 최대 잠긴 메모리가 표시됩니다. **`RLIMIT_MEMLOCK` 값을 업데이트하려면** 1. `/etc/systemd/system.conf.d/NUMBER-limits.conf` 파일이 있는 경우 이 파일에서 `DefaultLimitMEMLOCK`의 줄을 주석 처리합니다. 이 파일은 우선 순위가 높은 기본 `RLIMIT_MEMLOCK`을 설정하여 `/etc/systemd/system.conf` 파일의 설정을 덮어씁니다. 1. `/etc/systemd/system.conf` 파일을 열고 `#DefaultLimitMEMLOCK=`이 있는 줄의 주석 처리를 해제합니다. 1. 하드 제한과 소프트 `RLIMIT_MEMLOCK` 제한을 모두 32MB 이상으로 제공하여 기본값을 업데이트합니다. 업데이트된 정책은 `DefaultLimitMEMLOCK=32M:32M`과 같을 것입니다. 형식은 `soft-limit:hard-limit`입니다. 1. `sudo reboot`를 실행합니다. ## 다중 계정 환경에서 조직 서비스 제어 정책 검증 조직의 권한을 관리하기 위해 서비스 제어 정책(SCP)을 설정한 경우 권한 경계가 `guardduty:SendSecurityTelemetry` 동작을 제한하지 않는지 확인합니다. GuardDuty가 다양한 리소스 유형에서 런타임 모니터링을 지원하는 데 필요합니다. 멤버 계정인 경우 연결된 위임된 관리자와 연결합니다. 조직의 SCP 관리에 대한 자세한 내용은 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 참조하세요. ## 자동 에이전트 구성을 사용하는 경우 를 사용하려면 [자동 에이전트 구성 사용(권장)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2)가 다음 사전 조건을 충족해야 AWS 계정 합니다. + 자동화된 에이전트 구성과 함께 포함 태그를 사용하는 경우 GuardDuty가 새 인스턴스에 대한 SSM 연결을 만들려면 새 인스턴스가 SSM 관리 대상이고 **https://console.aws.amazon.com/systems-manager/** 콘솔의 [Fleet Manager](https://console.aws.amazon.com/systems-manager/) 아래에 표시되는지 확인합니다. + 자동 에이전트 구성에서 제외 태그를 사용하는 경우: + 계정에 GuardDuty 자동 에이전트를 구성하기 전에 `GuardDutyManaged`:`false` 태그를 추가합니다. 시작하기 전에 Amazon EC2 인스턴스에 제외 태그를 추가해야 합니다. Amazon EC2에 대한 자동화된 에이전트 구성을 사용 설정하면 제외 태그 없이 실행되는 모든 EC2 인스턴스가 GuardDuty 자동화된 에이전트 구성의 적용을 받습니다. + 인스턴스에 대하여 **메타데이터에서 태그 허용** 설정을 활성화합니다. 이 설정은 GuardDuty가 인스턴스 메타데이터 서비스(IMDS)에서 제외 태그를 읽어 에이전트 설치에서 인스턴스를 제외해야 하는지 여부를 결정해야 하기 때문에 필요합니다. 자세한 내용은 *Amazon EC2 사용 설명서*에서 [인스턴스 메타데이터에서 태그에 대한 액세스 활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS)를 참조하세요. ## GuardDuty 에이전트의 CPU 및 메모리 제한 **CPU 제한** Amazon EC2 인스턴스와 연결된 GuardDuty 보안 에이전트의 최대 CPU 제한은 전체 vCPU 코어의 10%입니다. 예를 들어, EC2 인스턴스에 4개의 vCPU 코어가 있는 경우 보안 에이전트는 총 사용 가능한 400% 중 최대 40%를 사용할 수 있습니다. **메모리 제한** Amazon EC2 인스턴스와 연결된 메모리에서 GuardDuty 보안 에이전트가 사용할 수 있는 메모리가 제한되어 있습니다. 다음 표에는 메모리 제한이 나와 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) ## 다음 단계 다음 단계는 런타임 모니터링을 구성하고 보안 에이전트를 관리(자동 또는 수동)하는 것입니다. # AWS Fargate (Amazon ECS만 해당) 지원을 위한 사전 조건 이 섹션에는 Fargate-Amazon ECS 리소스의 런타임 동작을 모니터링하기 위한 전제 조건이 포함되어 있습니다. 이러한 사전 요구 사항이 충족되면 [GuardDuty 런타임 모니터링 활성화](runtime-monitoring-configuration.md)을 참조하세요. **Topics** + [아키텍처 요구 사항 검증](#validating-architecture-req-ecs) + [컨테이너 이미지 액세스를 위한 사전 조건](#before-enable-runtime-monitoring-ecs) + [다중 계정 환경에서 조직 서비스 제어 정책 검증](#validate-organization-scp-ecs) + [역할 권한 및 정책 권한 경계 검증](#guardduty-runtime-monitoring-ecs-permission-boundary) + [CPU 및 메모리 제한](#ecs-runtime-agent-cpu-memory-limits) ## 아키텍처 요구 사항 검증 사용하는 플랫폼이 GuardDuty 보안 에이전트가 Amazon ECS 클러스터로부터 런타임 이벤트를 수신하는 데 있어 GuardDuty를 지원하는 방식에 영향을 미칠 수 있습니다. 확인된 플랫폼 중 하나를 사용하고 있는지 검증해야 합니다. **초기 고려 사항:** Amazon ECS 클러스터의 AWS Fargate 플랫폼은 Linux여야 합니다. 해당 플랫폼 버전은 `1.4.0`, 또는 `LATEST` 이상이어야 합니다. 플랫폼 버전에 대한 자세한 내용은 *Amazon Elastic 컨테이너 서비스 개발자 가이드*에서 [Linux 플랫폼 버전](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-linux-fargate.html)을 참조하세요. Windows 플랫폼 버전은 아직 지원되지 않습니다. ### 검증된 플랫폼 OS 배포 및 CPU 아키텍처는 GuardDuty 보안 에이전트가 제공하는 지원에 영향을 미칩니다. 다음 표는 GuardDuty 보안 에이전트를 배포하고 런타임 모니터링을 구성하는 데 있어 검증된 구성을 보여줍니다. | OS 배포**[1](#runtime-monitoring-ecs-os-support)** | 커널 지원 | CPU 아키텍처 x64(AMD64) | CPU 아키텍처 Graviton(ARM64) | | --- | --- | --- | --- | | Linux | eBPF, Tracepoints, Kprobe | 지원됨 | 지원됨 | 1다양한 운영 체제 지원 - GuardDuty는 상기 표에 기재된 운영 체제 배포판에 대한 Runtime Monitoring 지원을 검증했습니다. GuardDuty 보안 에이전트가 위 표에 나열되지 않은 운영 체제에서 실행될 수 있지만 GuardDuty 팀이 예상 보안 값을 보장할 수는 없습니다. ## 컨테이너 이미지 액세스를 위한 사전 조건 다음 사전 조건은 Amazon ECR 리포지토리에서 GuardDuty 사이드카 컨테이너 이미지에 액세스하는 데 도움이 됩니다. ### 권한 요구 사항 GuardDuty 보안 에이전트 컨테이너 이미지를 다운로드하려면 작업 실행 역할에 특정 Amazon Elastic Container Registry(Amazon ECR) 권한이 필요합니다. ``` ... "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", ... ``` Amazon ECR 권한을 추가로 제한하려면 GuardDuty 보안 에이전트를 호스팅하는 Amazon ECR 리포지토리 URI를 추가할 수 있습니다 AWS Fargate (Amazon ECS만 해당). 자세한 내용은 [Amazon ECR 리포지토리 호스팅 GuardDuty 에이전트](runtime-monitoring-ecr-repository-gdu-agent.md) 단원을 참조하십시오. [AmazonECSTaskExecutionRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) 관리형 정책을 사용하거나 `TaskExecutionRole` 정책에 위의 권한을 추가할 수 있습니다. ### 작업 정의 구성 Amazon ECS 서비스를 생성하거나 업데이트할 때 작업 정의에 서브넷 정보를 제공해야 합니다. *Amazon Elastic Container Service API 참조*에서 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) 및 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) API를 실행하려면 서브넷 정보를 전달해야 합니다. 자세한 내용은 *Amazon Elastic 컨테이너 서비스 개발자 가이드*의 [Amazon ECS 작업 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)를 참조하세요. ### 네트워크 및 연결 요구 사항 Amazon ECR에서 GuardDuty 컨테이너 이미지를 다운로드하려면 네트워크 연결을 확인해야 합니다. 이 요구 사항은 Amazon ECR을 사용하여 보안 에이전트를 호스팅하기 때문에 GuardDuty에만 해당됩니다. 네트워크 구성에 따라 다음 옵션 중 하나를 구현해야 합니다. **옵션 1 - 퍼블릭 네트워크 액세스 사용(사용 가능한 경우)** Fargate 작업이 아웃바운드 인터넷 액세스가 가능한 서브넷에서 실행되는 경우 추가 네트워크 구성이 필요하지 않습니다. **옵션 2 - Amazon VPC 엔드포인트 사용(프라이빗 서브넷용)** Fargate 태스크가 인터넷 액세스 없이 프라이빗 서브넷에서 실행되는 경우 GuardDuty 보안 에이전트를 호스팅하는 ECR 리포지토리 URI가 네트워크에 액세스할 수 있도록 ECR에 대한 VPC 엔드포인트를 구성해야 합니다. 이러한 엔드포인트가 없으면 프라이빗 서브넷의 태스크가 GuardDuty 컨테이너 이미지를 다운로드할 수 없습니다. VPC 엔드포인트 설정 지침은 *Amazon Elastic Container Registry 사용 설명서*의 [Create the VPC endpoints for Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) 섹션을 참조하세요. Fargate가 GuardDuty 컨테이너를 다운로드하도록 활성화하는 방법에 대한 자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*에서 [Amazon ECS와 함께 Amazon ECR 이미지 사용](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html)을 참조하세요. ### 보안 그룹 구성 GuardDuty 컨테이너 이미지는 Amazon ECR에 있으며 Amazon S3 액세스가 필요합니다. 이 요구 사항은 Amazon ECR에서 컨테이너 이미지를 다운로드할 때에만 적용됩니다. 네트워크 액세스가 제한된 작업의 경우 S3에 대한 액세스를 허용하도록 보안 그룹을 구성해야 합니다. [포트 443의 S3 관리형 접두사 목록(`pl-xxxxxxxx`)](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security)으로의 트래픽을 허용하는 아웃바운드 규칙을 보안 그룹에 추가합니다. 아웃바운드 규칙을 추가하려면 *Amazon VPC 사용 설명서*의 [보안 그룹 규칙 구성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)을 참조하세요. 콘솔에서 AWS관리형 접두사 목록을 보거나 AWS Command Line Interface (AWS CLI)를 사용하여 설명하려면 *Amazon VPC 사용 설명서*의 [AWS관리형 접두사 목록을](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) 참조하세요. ## 다중 계정 환경에서 조직 서비스 제어 정책 검증 이 섹션에서는 서비스 제어 정책(SCP) 설정을 검증하여 Runtime Monitoring이 조직 전체에서 예상대로 작동하는지 확인하는 방법을 설명합니다. 조직의 권한을 관리하기 위해 하나 이상의 서비스 제어 정책을 설정한 경우 `guardduty:SendSecurityTelemetry` 작업을 거부하지 않는지 확인해야 합니다. SCP 작동 방식에 대한 자세한 내용은 *AWS Organizations 사용 설명서*의 [SCP evaluation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html)을 참조하세요. 멤버 계정인 경우 연결된 위임된 관리자와 연결합니다. 조직의 SCP 관리에 대한 자세한 내용은 *AWS Organizations 사용 설명서*의 [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)를 참조하세요. 다중 계정 환경에서 설정한 모든 SCP에 대해 다음 단계를 수행합니다. **SCP에서 `guardduty:SendSecurityTelemetry`가 거부되지 않았는지 확인하려면** 1. [https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/)에서 Organizations 콘솔에 로그인합니다. 조직의 관리 계정에서 IAM 역할로 로그인하거나 루트 사용자로 로그인([권장되지 않음](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials))해야 합니다. 1. 왼쪽 탐색 창에서 **정책**을 선택합니다. 그런 다음 **지원되는 정책 유형**에서 **서비스 제어 정책**을 선택합니다. 1. **서비스 제어 정책** 페이지에서 검증할 정책의 이름을 선택합니다. 1. 정책의 세부 정보 페이지에서 이 정책의 **내용**을 확인합니다. `guardduty:SendSecurityTelemetry` 작업을 거부하지 않는지 확인합니다. 다음 SCP 정책은 `guardduty:SendSecurityTelemetry` 작업을 *거부하지 않는* 예입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:SendSecurityTelemetry" ], "Resource": "*" } ] } ``` ------ 정책이 이 작업을 거부하는 경우 정책을 업데이트해야 합니다. 자세한 내용은 *AWS Organizations 사용 설명서*의 [서비스 제어 정책(SCP) 업데이트](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy)를 참조하세요. ## 역할 권한 및 정책 권한 경계 검증 다음 단계를 사용하여 역할 및 해당 정책과 연결된 권한 경계가 제한 `guardduty:SendSecurityTelemetry` 작업이 **아닌지** 확인합니다. **역할 및 해당 정책에 대한 권한 경계를 보려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) IAM 콘솔을 엽니다. 1. 왼쪽 탐색 창의 **액세스 관리**에서 **역할**을 선택합니다. 1. **역할** 페이지에서 방금 생성한 역할 *`TaskExecutionRole`*을 선택합니다. 1. 선택한 역할 페이지의 **권한** 탭에서 이 역할과 연결된 정책 이름을 확장합니다. 그런 다음 이 정책이 `guardduty:SendSecurityTelemetry`를 제한하지 않는지 확인합니다. 1. **권한 경계**가 설정된 경우 이 섹션을 확장합니다. 그런 다음 각 정책을 확장하여 `guardduty:SendSecurityTelemetry` 작업을 제한하지 않는지 검토합니다. 정책은 이 [Example SCP policy](#ecs-runtime-scp-not-deny-policy-example)과 비슷할 것입니다. 필요한 경우, 다음 작업 중 하나를 수행하세요. + 정책을 수정하려면 **편집**을 선택합니다. 이 정책의 **권한 수정** 페이지의 **정책 편집기**에서 정책을 업데이트합니다. JSON 스키마가 유효한지 확인합니다. 그리고 **다음**을 선택합니다. 그런 다음, 변경 사항을 검토하고 저장할 수 있습니다. + 이 권한 경계를 변경하고 다른 경계를 선택하려면 **경계 변경**을 선택합니다. + 이 권한 경계를 제거하려면 **경계 제거**를 선택합니다. 정책 관리에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS Identity and Access Management의 정책 및 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)을 참조하세요. ## CPU 및 메모리 제한 Fargate 작업 정의에서 작업 수준에서 CPU 및 메모리 값을 지정해야 합니다. 다음 표에는 작업 수준 CPU 및 메모리 값의 유효한 조합과 GuardDuty 컨테이너에 대한 해당 GuardDuty 보안 에이전트 최대 메모리 제한이 나와 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html) 런타임 모니터링을 활성화하고 클러스터의 적용 범위 상태가 **정상**인 것으로 평가한 후 컨테이너 인사이트 지표를 설정하고 볼 수 있습니다. 자세한 설명은 [Amazon ECS 클러스터에서 모니터링 설정](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent) 섹션을 참조하세요. 다음 단계는 런타임 모니터링을 구성하고 보안 에이전트도 구성하는 것입니다. # Amazon EKS 클러스터 지원을 위한 사전 조건 이 섹션에는 Amazon EKS 리소스의 런타임 동작을 모니터링하기 위한 사전 요구 사항이 포함되어 있습니다. 이러한 사전 조건은 GuardDuty 에이전트가 예상대로 작동하는 데 매우 중요합니다. 이러한 사전 조건이 충족되면 [GuardDuty 런타임 모니터링 활성화](runtime-monitoring-configuration.md)을 참조하여 리소스 모니터링을 시작합니다. ## Amazon 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)를 참조하세요. ## 아키텍처 요구 사항 검증 사용하는 플랫폼이 GuardDuty 보안 에이전트가 EKS 클러스터로부터 런타임 이벤트를 수신하는 데 있어 GuardDuty를 지원하는 방식에 영향을 미칠 수 있습니다. 확인된 플랫폼 중 하나를 사용하고 있는지 검증해야 합니다. GuardDuty 에이전트를 수동으로 관리하는 경우, Kubernetes 버전이 현재 사용 중인 GuardDuty 에이전트 버전을 지원하는지 확인해야 합니다. ### 검증된 플랫폼 OS 배포판, 커널 버전 및 CPU 아키텍처는 GuardDuty 보안 에이전트에서 제공하는 지원에 영향을 미칩니다. 커널 지원에는 `eBPF`, `Tracepoints` 및 `Kprobe`가 포함됩니다. CPU 아키텍처의 경우 Runtime Monitoring은 AMD64(`x64`) 및 ARM64(Graviton2 이상)[1](#runtime-monitoring-eks-graviton-2-support)를 지원합니다. 다음 표는 GuardDuty 보안 에이전트를 배포하고 EKS 런타임 모니터링을 구성하는 데 있어 검증된 구성을 보여줍니다. | OS 배포**[2](#runtime-monitoring-eks-os-support)** | 커널 버전**[3](#runtime-monitoring-eks-kernel-version-required-flag)** | 지원되는 Kubernetes 버전 | | --- | --- | --- | | Bottlerocket | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23 - v1.35 | | Ubuntu | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2 | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2023*[5](#runtime-eks-al2023-support-v1.6.0)* | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | RedHat 9.4 | 5.14[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Fedora 34 | 5.11, 5,17 | v1.21 - v1.35 | | Fedora 40 | 6.8 | v1.28 - v1.35 | | Fedora 41 | 6.12 | v1.28 - v1.35 | | CentOS Stream 9 | 5.14 | v1.21 - v1.35 | 1. Amazon EKS 클러스터에 대한 런타임 모니터링은 A1 인스턴스 유형과 같은 1세대 Graviton 인스턴스를 지원하지 않습니다. 1. 다양한 운영 체제 지원 - GuardDuty는 상기 표에 기재된 운영 체제 배포판에 대한 Runtime Monitoring 지원을 검증했습니다. GuardDuty 보안 에이전트가 위 표에 나열되지 않은 운영 체제에서 실행될 수 있지만 GuardDuty 팀이 예상 보안 값을 보장할 수는 없습니다. 1. 커널 버전의 경우 `CONFIG_DEBUG_INFO_BTF` 플래그를 `y`(*true* 의미)로 설정해야 합니다. 이는 GuardDuty 보안 에이전트가 예상대로 실행될 수 있도록 하기 위해 필요합니다. 1. 현재 커널 버전 `6.1`에서는 [도메인 이름 시스템(DNS) 이벤트](runtime-monitoring-collected-events.md#eks-runtime-dns-events)와 관련된 GuardDuty[GuardDuty 런타임 모니터링 조사 결과 유형](findings-runtime-monitoring.md)를 생성할 수 없습니다. 1. 런타임 모니터링은 GuardDuty 보안 에이전트 v1.6.0 이상의 릴리스와 함께 AL2023을 지원합니다. 자세한 내용은 [Amazon EKS 리소스용 GuardDuty 보안 에이전트 버전](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history) 단원을 참조하십시오. #### GuardDuty 보안 에이전트가 지원하는 Kubernetes 버전 다음 표는 GuardDuty 보안 에이전트에서 지원하는 EKS 클러스터의 Kubernetes 버전을 보여줍니다. | Amazon EKS 추가 기능 GuardDuty 보안 에이전트 버전 | Kubernetes 버전 | | --- | --- | | v1.12.1(최신 - v1.12.1-eksbuild.2) | 1.28\$11.35 | | v1.11.0(최신 - v1.11.0-eksbuild.4) | 1.28\$11.34 | | v1.10.0(최신 - v1.10.0-eksbuild.2) | 1.21\$11.33 | | v1.9.0(최신 - v1.9.0-eksbuild.2) v1.8.1(최신 - v1.8.1-eksbuild.2) | 1.21\$11.32 | | v1.7.1 v1.7.0 v1.6.1 | 1.21\$11.31 | | v1.6.0 v1.5.0 v1.4.1 v1.4.0 v1.3.1 | 1.21\$11.29 | | v1.3.0 v1.2.0 | 1.21\$11.28 | | v1.1.0 | 1.21\$11.26 | | v1.0.0 | 1.21 - 1.25 | 일부 GuardDuty 보안 에이전트 버전은 표준 지원이 종료됩니다. 에이전트 릴리스 버전에 대한 자세한 내용은 [Amazon EKS 리소스용 GuardDuty 보안 에이전트 버전](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)를 참조하세요. ### CPU 및 메모리 제한 다음 표는 GuardDuty용 Amazon EKS 추가 기능(`aws-guardduty-agent`)의 CPU 및 메모리 제한을 보여줍니다. | 파라미터 | 최소 제한 | 최대 제한 | | --- | --- | --- | | CPU | 200m | 1,000m | | Memory | 256Mi | 1024Mi | Amazon EKS 추가 기능 버전 1.5.0 이상을 사용하는 경우 GuardDuty는 CPU 및 메모리 값에 대한 애드온 기능 스키마를 구성하는 기능을 제공합니다. 구성 범위에 대한 자세한 설명은 [구성 가능한 파라미터 및 값](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values)을 참조하세요. EKS 런타임 모니터링을 활성화하고 EKS 클러스터의 적용 범위 상태를 평가한 후 컨테이너 인사이트 지표를 설정하고 볼 수 있습니다. 자세한 내용은 [CPU 및 메모리 모니터링 설정](runtime-monitoring-setting-cpu-mem-monitoring.md) 단원을 참조하십시오. ## 조직 서비스 제어 정책 검증 조직의 권한을 관리하기 위해 서비스 제어 정책(SCP)을 설정한 경우 권한 경계가 `guardduty:SendSecurityTelemetry`를 제한하지 않는지 확인합니다. GuardDuty가 다양한 리소스 유형에서 런타임 모니터링을 지원하는 데 필요합니다. 멤버 계정인 경우 연결된 위임된 관리자와 연결합니다. 조직의 SCP 관리에 대한 자세한 내용은 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 참조하세요.