기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
AMS Accelerate의 표준 제어
다음은 AMS의 표준 컨트롤입니다.
| 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": "*" over "Resource": "*"에 해당하는 문으로 관리자 액세스를 제공해서는 안 됩니다. |
| 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 | 고객이 다른 정책을 명시적으로 지정하지 않는 한 고객 리소스는 최소 권한 리소스 기반 정책으로 구성해야 합니다. |
다음은 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 또는 계정에 대한 위험 수락 없이 허용되지 않습니다. |
다음은 X004 - 침투 테스트를 위한 표준 컨트롤입니다.
AMS는 pentest 인프라를 지원하지 않습니다. 이는 고객의 책임입니다. 예를 들어 Kali는 Linux의 AMS 지원 배포판이 아닙니다.
고객은 침투 테스트를
준수해야 합니다. 고객이 계정 내에서 인프라 침투 테스트를 수행하려는 경우 24시간 전에 AMS에 미리 알립니다.
AMS는 고객의 변경 요청 또는 서비스 요청에 명시적으로 명시된 고객 요구 사항에 따라 고객 테스트 인프라를 프로비저닝합니다.
인프라를 테스트하는 고객의 자격 증명 관리는 고객의 책임입니다.
다음은 X005 - GuardDuty에 대한 표준 컨트롤입니다.
GuardDuty는 모든 고객 계정에서 항상 활성화되어야 합니다.
GuardDuty 알림은 동일한 계정 또는 동일한 조직의 다른 관리형 계정 내에 저장되어야 합니다.
GuardDuty의 신뢰할 수 있는 IP 목록 기능은 사용해서는 안 됩니다. 대신 자동 아카이브를 대안으로 사용할 수 있으며, 이는 감사 목적에 유용합니다.
다음은 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 계정으로 전달할 수 있습니다. |
