

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 변경 요청 보안 검토
<a name="acc-sec-change-request-review"></a>

AWS Managed Services 변경 요청 검토 프로세스를 통해 AMS는 요청된 변경 사항이 계정에서 사용자를 대신하여 구현될 때 보안 검토를 수행할 수 있습니다.

[AMS Accelerate 기술 표준](acc-sec-technical-standards.md) 최소 보안 기준, 구성 및 프로세스를 정의하여 계정의 기본 보안을 설정합니다. AMS가 요청된 변경 사항을 구현하면 이러한 표준을 따릅니다.

AMS는 AMS 기술 표준을 기준으로 모든 변경 요청을 평가합니다. 기술 표준을 벗어나 계정의 보안 태세를 저하시킬 수 있는 모든 변경 사항은 보안 검토 프로세스를 거칩니다. 이 프로세스 중에 AMS가 관련 위험을 강조 표시하고 승인된 위험 승인자가 검토 및 승인하여 보안 및 비즈니스 요구 사항의 균형을 유지합니다.

# 고객 보안 위험 관리 프로세스
<a name="acc-sec-csrm-process"></a>

AMS Accelerate Customer Security Risk Management(CSRM) 프로세스는 위험을 명확하게 식별하고 적절한 소유자에게 알리는 데 도움이 됩니다. 이 프로세스는 환경의 보안 위험을 최소화하고 식별된 위험에 대한 지속적인 운영 오버헤드를 줄입니다.

기본적으로 조직의 누군가가 AMS가 관리형 환경에 대한 변경을 구현하도록 요청하면 AMS는 변경 사항을 검토하여 요청이 기술 표준을 벗어나 계정의 보안 태세를 변경할 수 있는지 확인합니다. 보안 위험이 높거나 매우 높은 경우 권한 있는 보안 담당자가 변경 검토를 수락하거나 거부합니다. 요청된 변경 사항도 AMS의 계정 운영 능력에 부정적인 영향을 미치는지 평가됩니다. 검토에서 가능한 부정적인 영향이 발견되면 AMS 내에서 추가 검토 및 승인이 필요합니다.

위험이 높거나 매우 높은 경우 CSRM 프로세스의 승인 기반 워크플로에서 옵트아웃할 수 있습니다. 특정 계정의 CSRM 옵션을 **표준 CSRM**에서 **알림 전용**으로 변경하려면 Cloud Service Delivery Manager와 협력하여 일회성 위험 수락을 생성합니다. **알림 전용** 옵션을 선택하면 AMS는 위험 범주에 관계없이 요청된 변경 사항을 구현합니다. 또한 AMS는 변경 구현 전에 승인을 구하는 대신 승인된 위험 승인자에게 위험 알림을 보냅니다. AMS CSRM 프로세스, 새 AMS 계정을 온보딩할 때 기본 CSRM 옵션을 변경하는 방법 또는 기존 계정을 업데이트하는 방법에 대한 자세한 내용은 Cloud Architects 또는 Cloud Service Delivery Manager에게 문의하세요.

**참고**  
AMS는 모든 계정에서 **표준 CSRM**의 기본 옵션을 사용할 것을 적극 권장합니다.

# AMS Accelerate 기술 표준
<a name="acc-sec-technical-standards"></a>

다음은 Accelerate 기술 표준 범주입니다.


| ID | 범주 | 
| --- | --- | 
| AMS-STD-X002 | AWS Identity and Access Management | 
| AMS-STD-X003 | 네트워크 보안 | 
| AMS-STD-X004 | 침투 테스트 | 
| AMS-STD-X005 | Amazon GuardDuty | 
| AMS-STD-X007 | 로깅 | 

# AMS Accelerate의 표준 제어
<a name="acc-sec-stand-controls"></a>

다음은 AMS의 표준 컨트롤입니다.

## AMS-STD-X002 - AWS Identity and Access Management (IAM)
<a name="acc-sec-stand-controls-iam"></a>


| ID | 기술 표준 | 
| --- | --- | 
| 1.0 | 제한 시간 지속 시간 | 
| 1.1 | 페더레이션 사용자 기본 제한 시간 세션은 1시간이며 최대 4시간까지 늘릴 수 있습니다. | 
| 1.2 | Microsoft Windows Server의 RDP 세션 제한 시간은 15분으로 설정되며 사용 사례에 따라 연장할 수 있습니다. | 
| 2.0 | AWS 루트 계정 사용 | 
| 2.1 | 어떤 이유로든 루트 계정 사용량이 있는 경우 관련 조사 결과를 생성하도록 Amazon GuardDuty를 구성해야 합니다. | 
| 2.2 | 루트 계정의 액세스 키는 생성해서는 안 됩니다. | 
| 3.0 | 사용자 생성 및 수정 | 
| 3.1 | 프로그래밍 방식 액세스 권한과 읽기 전용 권한이 있는 IAM 사용자/역할은 시간 제한 정책 없이 생성할 수 있습니다. 그러나 권한 o는 계정의 모든 Amazon Simple Storage Service 버킷에서 객체(예: S3:GetObject) 읽기를 허용하지 않습니다. | 
| 3.1.1 | 콘솔 액세스 및 읽기 전용 권한을 가진 IAM 인간 사용자는 시간 제한 정책(최대 180일)을 사용하여 생성할 수 있지만 시간 제한 정책을 removal/renewal/extension하면 위험 알림이 발생합니다. 그러나 계정의 모든 S3 버킷에서 객체(예: S3:GetObject)를 읽을 수 있는 권한은 허용되지 않습니다. | 
| 3.2 | 고객 계정의 인프라 변경 권한(쓰기 및 권한 관리)을 사용한 콘솔 및 프로그래밍 방식 액세스에 대한 IAM 사용자 및 역할은 위험 수락 없이 생성해서는 안 됩니다. 특정 버킷이 비 AMS 관련 태그의 범위 및 태그 지정 작업에 있는 한 위험 수락 없이 허용되는 S3 객체 수준 쓰기 권한에는 예외가 있습니다. | 
| 3.3 | Microsoft Windows Servers에서는 Microsoft 그룹 관리형 서비스 계정(gMSA)만 생성해야 합니다. | 
| 4.0 | 정책, 작업 및 APIs | 
| 4.4 | 정책은 위험 수락 없이 "Effect": "Allow" with "Action": "\$1" over "Resource": "\$1"에 해당하는 문으로 관리자 액세스를 제공해서는 안 됩니다. | 
| 4.6 |  고객 IAM 정책의 AMS 인프라 키에 대한 KMS 키 정책에 대한 API 호출은 허용되지 않아야 합니다. | 
| 4.8 | Amazon Route 53에서 AMS 인프라 DNS 레코드를 변경하는 작업은 허용되지 않아야 합니다. | 
| 4.9 |  적절한 프로세스를 따른 후 콘솔 액세스 권한이 생성된 IAM 인간 사용자는 신뢰 정책, 역할 수임 및 시간 제한 정책을 제외하고 직접 연결된 정책이 없어야 합니다. | 
| 4.10 | 동일한 계정 AWS Secrets Manager 내의 특정 보안 암호 또는 네임스페이스에 대한 읽기 액세스 권한이 있는 Amazon EC2 인스턴스 프로파일을 생성할 수 있습니다. | 
| 4.12 | IAM 정책에는 AMS Amazon CloudWatch 로그 그룹에서 로그:DeleteLogGroup 및 로그:DeleteLogStream 허용 작업이 포함된 작업이 포함되어서는 안 됩니다. | 
| 4.13 | 다중 리전 키를 생성할 수 있는 권한은 허용되지 않아야 합니다. | 
| 4.14 | 서비스별 S3 조건 키 s3:ResourceAccount를 사용하여 계정 번호를 지정하여 버킷에 대한 액세스를 고객 계정으로 제한하여 고객 계정에 아직 생성되지 않은 S3 버킷 ARN에 대한 액세스를 제공할 수 있습니다. | 
| 4.15.1 | S3 스토리지 렌즈 사용자 지정 대시보드에 대한 보기, 생성, 나열 및 삭제 액세스 권한을 가질 수 있습니다. | 
| 4.16 | Amazon Redshift 데이터베이스에서 작업할 수 있도록 역할/사용자에게 SQL Workbench 관련 전체 권한을 부여할 수 있습니다. | 
| 4.17 | CLI의 대안으로 고객 역할에 모든 AWS CloudShell 권한을 부여할 수 있습니다. | 
| 4.18 |  AWS 서비스가 신뢰할 수 있는 보안 주체인 IAM 역할도 IAM 기술 표준을 준수해야 합니다. | 
| 4.19 |  서비스 연결 역할(SLRs)은 IAM 서비스 팀에서 구축 및 유지 관리하므로 AMS IAM 기술 표준의 적용을 받지 않습니다. | 
| 4.20 | IAM 정책은 계정의 모든 S3 버킷에서 객체(예: S3:GetObject)의 읽기를 허용해서는 안 됩니다. | 
| 4.21 | 리소스 유형 “savingsplan”에 대한 모든 IAM 권한을 고객에게 부여할 수 있습니다. | 
| 4.22 | AMS 엔지니어는 Amazon S3, Amazon S3 객체, 데이터베이스 등)를 수동으로 복사하거나 이동할 수 없습니다. Amazon Relational Database Service DynamoDB | 
| 6.0 | 교차 계정 정책 | 
| 6.1 | IAM 역할은 고객 레코드에 따라 동일한 고객에게 속한 AMS 계정 간에 정책을 신뢰합니다. | 
| 6.2 | IAM 역할은 동일한 AMS 고객이 비 AMS 계정을 소유한 경우에만(동일한 계정인지 확인하거나 이메일 도메인을 고객의 회사 이름과 일치시켜) AMS 계정과 비 AMS AWS Organizations 계정 간의 신뢰 정책을 구성해야 합니다. | 
| 6.3 | IAM 역할은 위험 수락 없이 AMS 계정과 타사 계정 간의 정책을 신뢰합니다. | 
| 6.4 | 동일한 고객의 AMS 계정 간에 고객 관리형 CMKs에 액세스하는 교차 계정 정책을 구성할 수 있습니다. | 
| 6.5 | AMS 계정을 통해 비 AMS 계정 내의 모든 KMS 키에 액세스하기 위한 교차 계정 정책을 구성할 수 있습니다. | 
| 6.6 | 타사 계정이 AMS 계정 내의 KMS 키에 액세스하기 위한 교차 계정 정책은 위험 수락 없이 허용되지 않아야 합니다. | 
| 6.6.1 | 비 AMS 계정이 AMS 계정 내의 모든 KMS 키에 액세스하기 위한 교차 계정 정책은 비 AMS 계정을 동일한 AMS 고객이 소유한 경우에만 구성할 수 있습니다. | 
| 6.7 | 동일한 고객의 AMS 계정 간에 데이터를 저장할 수 있는 모든 S3 버킷 데이터 또는 리소스(예: Amazon RDS, Amazon DynamoDB 또는 Amazon Redshift)에 액세스하기 위한 교차 계정 정책을 구성할 수 있습니다. | 
| 6.8 | 읽기 전용 액세스 권한이 있는 AMS 계정의 비 AMS 계정에 데이터를 저장할 수 있는 모든 S3 버킷 데이터 또는 리소스(예: Amazon RDS, Amazon DynamoDB 또는 Amazon Redshift)에 액세스하기 위한 교차 계정 정책을 구성할 수 있습니다. | 
| 6.9 | AMS를 비AMS 계정(또는 비AMS에서 AMS 계정)에 쓰기 권한으로 데이터를 저장할 수 있는 S3 버킷 데이터 또는 리소스(예: Amazon RDS, Amazon DynamoDB 또는 Amazon Redshift)에 액세스하기 위한 교차 계정 정책은 AMS 계정이 동일한 AMS 고객이 소유한 경우에만(동일 AWS Organizations 한 계정인지 확인하거나 이메일 도메인을 고객의 회사 이름과 일치시켜) 구성해야 합니다. | 
| 6.10 |  읽기 전용 액세스 권한이 있는 AMS 계정의 타사 계정에 데이터를 저장할 수 있는 모든 S3 버킷 데이터 또는 리소스(예: Amazon RDS, Amazon DynamoDB 또는 Amazon Redshift)에 액세스하기 위한 교차 계정 정책을 구성할 수 있습니다. | 
| 6.11 | 쓰기 액세스 권한이 있는 AMS 계정의 타사 계정에 데이터를 저장할 수 있는 S3 버킷 데이터 또는 리소스(예: Amazon RDS, Amazon DynamoDB 또는 Amazon Redshift)에 액세스하기 위한 교차 계정 정책은 구성하면 안 됩니다. | 
| 6.12 | 데이터를 저장할 수 있는 AMS 고객 S3 버킷 또는 리소스(asAmazon RDS, Amazon DynamoDB 또는 Amazon Redshift)에 액세스하기 위한 타사 계정의 교차 계정 정책은 위험 수락 없이 구성해서는 안 됩니다. | 
| 7.0 | 사용자 그룹 | 
| 7.1 | 읽기 전용 및 비변동 권한이 있는 IAM 그룹은 허용됩니다. | 
| 8.0 | 리소스 기반 정책 | 
| 8.4 | AMS 인프라 리소스는 리소스 기반 정책을 연결하여 승인되지 않은 자격 증명으로 관리로부터 보호해야 합니다. | 
| 8.2 | 고객이 다른 정책을 명시적으로 지정하지 않는 한 고객 리소스는 최소 권한 리소스 기반 정책으로 구성해야 합니다. | 

## AMS-STD-X003 - 네트워크 보안
<a name="acc-sec-stand-controls-network"></a>

다음은 X003 - 네트워크 보안에 대한 표준 제어입니다.


| ID | 기술 표준 | 
| --- | --- | 
|  | 네트워킹 | 
| 1.0 | 향후 제어를 위해 예약됨 | 
| 2.0 | EC2 인스턴스에서 탄력적 IP 허용 | 
| 3.0 | 데이터 영역 TLS 1.2 이상에서 AMS 컨트롤 플레인 및 확장별를 사용해야 합니다. | 
| 5.0 | 9.0에 따라 로드 밸런서에 연결되지 않은 경우 보안 그룹에 인바운드 규칙에서 소스가 0.0.0.0/0이 아니어야 합니다. | 
| 6.0 | 위험 수락 없이 S3 버킷 또는 객체를 공개해서는 안 됩니다. | 
| 7.0 | 포트 SSH/22 또는 SSH/2222(SFTP/2222 아님), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 또는 1604, LDAP/389 또는 636 및 RPC/135에서 서버 관리 액세스는 보안 그룹을 통해 VPC 외부에서 허용되지 않아야 합니다. | 
| 8.0 | 포트(MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) 또는 사용자 지정 포트의 데이터베이스 관리 액세스는 보안 그룹을 통해 DX, VPC 피어 또는 VPN을 통해 VPC로 라우팅되지 않은 퍼블릭 IPs에서 허용되지 않아야 합니다. | 
| 8.1 | 고객 데이터를 저장할 수 있는 리소스는 퍼블릭 인터넷에 직접 노출되어서는 안 됩니다. | 
| 9.0 | 인터넷에서 포트 HTTP/80, HTTPS/8443 및 HTTPS/443을 통한 직접 애플리케이션 액세스는 로드 밸런서에만 허용되며 EC2 인스턴스, ECS/EKS/Fargate 컨테이너 등과 같은 직접 컴퓨팅 리소스에는 허용되지 않습니다. | 
| 10.0 | 고객 프라이빗 IP 범위에서 포트 HTTP/80 및 HTTPS/443을 통한 애플리케이션 액세스를 허용할 수 있습니다. | 
| 11.0 | AMS 인프라에 대한 액세스를 제어하는 보안 그룹에 대한 모든 변경은 위험 수락 없이 허용되지 않아야 합니다. | 
| 12.0 | AMS Security는 보안 그룹이 인스턴스에 연결되도록 요청될 때마다 표준을 참조합니다. | 
| 14.0 | AMS에서 비 AMS 계정(또는 비 AMS에서 AMS 계정)으로의 VPCs와 프라이빗 호스팅 영역의 교차 계정 연결은 내부 도구를 사용하여 동일한 AMS 고객이 비 AMS 계정을 소유한 경우에만(동일한 AWS 조직 계정인지 확인하거나 이메일 도메인을 고객의 회사 이름과 일치시켜) 구성해야 합니다. | 
| 15.0 | 동일한 고객에게 속한 계정 간의 VPC 피어링 연결을 허용할 수 있습니다. | 
| 16.0 | AMS 기본 AMIs는 내부 도구를 사용하여 동일한 고객이 두 계정을 소유하는 한(동일한 계정인지 확인하거나 이메일 도메인을 고객의 회사 이름과 일치시키는 방법으로) 비 AMS AWS Organizations 계정과 공유할 수 있습니다. | 
| 17.0 | FTP 포트 21은 위험 수락 없이 보안 그룹에 구성해서는 안 됩니다. | 
| 18.0 | 고객이 모든 계정을 소유하는 한 전송 게이트웨이를 통한 교차 계정 네트워크 연결이 허용됩니다. | 
| 19.0 | 프라이빗 서브넷을 퍼블릭으로 설정하는 것은 허용되지 않습니다. | 
| 20.0 | 타사 계정(고객이 소유하지 않음)과의 VPC 피어링 연결은 허용되지 않습니다. | 
| 21.0 | 타사 계정(고객이 소유하지 않음)과의 Transit Gateway 연결은 허용되지 않습니다. | 
| 22.0 | AMS가 고객에게 서비스를 제공하는 데 필요한 네트워크 트래픽은 고객 네트워크 송신 지점에서 차단되어서는 안 됩니다. | 
| 23.0 | 고객 인프라에서 Amazon EC2에 대한 인바운드 ICMP 요청에는 위험 알림이 필요합니다. | 
| 24.0 | 보안 그룹을 통해 DX, VPC 피어 또는 VPN을 통해 Amazon VPC로 라우팅된 퍼블릭 IPs의 인바운드 요청은 허용됩니다. | 
| 25.0 | 보안 그룹을 통해 DX, VPC-peer 또는 VPN을 통해 Amazon VPC로 라우팅되지 않은 퍼블릭 IPs의 인바운드 요청은 위험 수락이 필요합니다. | 
| 26.0 |  Amazon EC2에서 모든 대상으로의 아웃바운드 ICMP 요청이 허용됩니다. | 
| 27.0 | 보안 그룹 공유 | 
| 27.1 | 보안 그룹이이 보안 표준을 충족하는 경우 동일한 계정VPCs와 동일한 조직의 계정 간에 공유할 수 있습니다. | 
| 27.2 | 보안 그룹이이 표준을 충족하지 못하고 이전에이 보안 그룹에 대해 위험 수락이 필요한 경우, 동일한 계정의 VPCs 간 또는 동일한 조직의 계정 간 보안 그룹 공유 기능의 사용은 해당 VPC 또는 계정에 대한 위험 수락 없이 허용되지 않습니다. | 

## AMS-STD-X004 - 침투 테스트
<a name="acc-sec-stand-controls-pentest"></a>

다음은 X004 - 침투 테스트를 위한 표준 컨트롤입니다.

1. AMS는 pentest 인프라를 지원하지 않습니다. 이는 고객의 책임입니다. 예를 들어 Kali는 Linux의 AMS 지원 배포판이 아닙니다.

1. 고객은 [침투 테스트를](https://aws.amazon.com/security/penetration-testing/) 준수해야 합니다.

1. 고객이 계정 내에서 인프라 침투 테스트를 수행하려는 경우 24시간 전에 AMS에 미리 알립니다.

1. AMS는 고객의 변경 요청 또는 서비스 요청에 명시적으로 명시된 고객 요구 사항에 따라 고객 테스트 인프라를 프로비저닝합니다.

1. 인프라를 테스트하는 고객의 자격 증명 관리는 고객의 책임입니다.

## AMS-STD-X005 - GuardDuty
<a name="acc-sec-stand-controls-gdu"></a>

다음은 X005 - GuardDuty에 대한 표준 컨트롤입니다.

1. GuardDuty는 모든 고객 계정에서 항상 활성화되어야 합니다.

1. GuardDuty 알림은 동일한 계정 또는 동일한 조직의 다른 관리형 계정 내에 저장되어야 합니다.

1. GuardDuty의 신뢰할 수 있는 IP 목록 기능은 사용해서는 안 됩니다. 대신 자동 아카이브를 대안으로 사용할 수 있으며, 이는 감사 목적에 유용합니다.

## AMS-STD-X007 - 로깅
<a name="acc-sec-stand-controls-logging"></a>

다음은 X007 - 로깅에 대한 표준 컨트롤입니다.


| ID | 기술 표준 | 
| --- | --- | 
| 1.0 | 로그 유형 | 
| 1.1 | OS 로그: 모든 호스트는 최소 호스트 인증 이벤트, 승격된 권한의 모든 사용에 대한 액세스 이벤트, 성공 및 실패를 포함한 액세스 및 권한 구성에 대한 모든 변경 사항에 대한 액세스 이벤트를 로깅해야 합니다. | 
| 1.2 | AWS CloudTrail: 로그를 S3 버킷에 전달하도록 CloudTrail 관리 이벤트 로깅을 활성화하고 구성해야 합니다. | 
| 1.3 | VPC 흐름 로그: 모든 네트워크 트래픽 로그는 VPC 흐름 로그를 통해 로깅되어야 합니다. | 
| 1.4 | Amazon S3 서버 액세스 로깅: 로그를 저장하는 AMS 필수 S3 버킷에는 서버 액세스 로깅이 활성화되어 있어야 합니다. | 
| 1.5 | AWS Config 스냅샷: AWS Config 모든 리전에서 지원되는 모든 리소스에 대한 구성 변경을 기록하고 구성 스냅샷 파일을 하루에 한 번 이상 S3 버킷에 전달해야 합니다. | 
| 1.7 | 애플리케이션 로그: 고객은 애플리케이션에서 로깅을 활성화하고 CloudWatch Logs 로그 그룹 또는 S3 버킷에 저장할 수 있습니다. | 
| 1.8 | S3 객체 수준 로깅: 고객은 S3 버킷에서 객체 수준 로깅을 활성화할 수 있습니다. | 
| 1.9 | 서비스 로깅: 고객은 모든 핵심 서비스와 같은 SSPS 서비스에 대한 로그를 활성화하고 전달할 수 있습니다. | 
| 1.10 | Elastic Load Balancing(Classic/Application Load Balancer/Network Load Balancer) 로그: 액세스 및 오류 로그 항목은 AMS 2.0 관리형 S3 버킷에 저장되어야 합니다. | 
| 2.0 | 액세스 제어 | 
| 2.3 | 로그를 저장하는 AMS 필수 S3 버킷은 타사 계정 사용자를 버킷 정책의 원칙으로 허용해서는 안 됩니다. | 
| 2.4 | CloudWatch Logs 로그 그룹의 로그는 고객이 승인한 보안 담당자의 명시적 승인 없이 삭제해서는 안 됩니다. | 
| 3.0 | 로그 보존 | 
| 3.1 | AMS 필수 CloudWatch Logs 로그 그룹의 로그 보존 기간은 최소 90일이어야 합니다. | 
| 3.2 | 로그를 저장하는 AMS 필수 S3 버킷은 로그에서 최소 보존 기간이 18개월이어야 합니다. | 
| 3.3 | AWS Backup 스냅샷은 지원되는 리소스에서 최소 31일 동안 보존할 수 있어야 합니다. | 
| 4.0 | 암호화(Encryption) | 
| 4.1 | 로그를 저장하는 AMS Teams에 필요한 모든 S3 버킷에서 암호화를 활성화해야 합니다. | 
| 4.2 | 고객 계정에서 다른 계정으로 로그를 전달하는 것은 암호화되어야 합니다. | 
| 5.0 | 무결성 | 
| 5.1 | 로그 파일 무결성 메커니즘을 활성화해야 합니다. 즉, AMS 팀에 필요한 AWS CloudTrail 추적에서 “로그 파일 검증”을 구성합니다. | 
| 6.0 | 로그 전달 | 
| 6.1 | 모든 로그는 한 AMS 계정에서 동일한 고객의 다른 AMS 계정으로 전달할 수 있습니다. | 
| 6.2 | 내부 도구를 사용하여 동일한 AMS 고객이 비 AMS 계정을 소유한 경우에만(동일한 계정인지 확인하거나 이메일 도메인을 고객의 회사 이름 및 PAYER 연결 계정과 AWS Organizations 일치시켜) 모든 로그를 AMS에서 비 AMS 계정으로 전달할 수 있습니다. | 

# 환경에서 보안 위험이 높거나 매우 높은 변경 사항
<a name="acc-sec-high-risk-con"></a>

다음과 같은 변경 사항으로 인해 환경에서 보안 위험이 높거나 매우 높습니다.

**AWS Identity and Access Management**
+ High\$1Risk-IAM-001: 루트 계정에 대한 액세스 키 생성
+ High\$1Risk-IAM-002: 추가 액세스를 허용하는 SCP 정책 수정
+ High\$1Risk-IAM-003: AMS 인프라를 손상시킬 수 있는 SCP 정책 수정
+ High\$1Risk-IAM-004: 고객 계정에서 인프라 변경 권한(쓰기, 권한 관리 또는 태그 지정)이 있는 역할/사용자 생성
+ High\$1Risk-IAM-005: IAM 역할은 AMS 계정과 타사 계정(고객이 소유하지 않음) 간의 정책을 신뢰합니다.
+ High\$1Risk-IAM-006: 타사 계정을 통해 AMS 계정에서 모든 KMS 키에 액세스하기 위한 교차 계정 정책)
+ High\$1Risk-IAM-007: 데이터를 저장할 수 있는 AMS 고객 S3 버킷 또는 리소스(예: Amazon RDS, Amazon DynamoDB 또는 Amazon Redshift)에 액세스하기 위한 타사 계정의 교차 계정 정책
+ High\$1Risk-IAM-008: 고객 계정의 인프라 변경 권한을 사용하여 IAM 권한 할당
+ High\$1Risk-IAM-009: 계정의 모든 S3 버킷에 대한 나열 및 읽기 허용

**네트워크 보안**
+ High\$1Risk-NET-001: 인터넷에서 OS 관리 포트 SSH/22 또는 SSH/2222(SFTP/2222 아님), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 또는 1604, LDAP/389 또는 636 및 NETBIOS/137-139를 엽니다.
+ High\$1Risk-NET-002: 데이터베이스 관리 포트 MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433 또는 인터넷의 모든 관리 고객 포트 열기
+ High\$1Risk-NET-003: 모든 컴퓨팅 리소스에서 직접 애플리케이션 포트 HTTP/80, HTTPS/8443 및 HTTPS/443을 엽니다. 예: 인터넷에서 EC2 인스턴스, ECS/EKS/Fargate 컨테이너 등
+ High\$1Risk-NET-004: AMS 인프라에 대한 액세스를 제어하는 보안 그룹에 대한 모든 변경 사항
+ High\$1Risk-NET-006: 타사 계정과의 VPC 피어링(고객이 소유하지 않음)
+ High\$1Risk-NET-007: 고객 방화벽을 모든 AMS 트래픽의 송신 지점으로 추가
+ High\$1Risk-NET-008: 타사 계정과의 Transit Gateway 연결이 허용되지 않음
+ High\$1Risk-S3-001: S3 버킷에서 퍼블릭 액세스 프로비저닝 또는 활성화

**로깅**
+ High\$1Risk-LOG-001: CloudTrail을 비활성화합니다.
+ High\$1Risk-LOG-002: VPC 흐름 로그를 비활성화합니다.
+ High\$1Risk-LOG-003: AMS 관리형 계정에서 타사 계정(고객이 소유하지 않음)으로 모든 메서드(S3 이벤트 알림, SIEM 에이전트 풀, SIEM 에이전트 푸시 등)를 통한 로그 전달
+ High\$1Risk-LOG-004: CloudTrail에 비 AMS 추적 사용

**기타사항**
+ High\$1Risk-ENC-001: 활성화된 경우 모든 리소스에서 암호화 비활성화