기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
AMS Advanced의 표준 제어
다음은 AMS의 표준 컨트롤입니다.
다음은 001 - 태그 지정 구성에 대한 표준 컨트롤입니다.
운영 및 관리를 위해 AMS 팀에 필요한 모든 AWS 리소스에는 다음과 같은 키-값 페어가 있어야 합니다.
AppId= AMSInfrastructure
환경= AMSInfrastructure
AppName = AMSInfrastructure
AMSResource=True
이전에 나열된 태그 이외의 AMS 팀에 필요한 모든 태그에는 AMS 접두사 목록에 언급된 접두사가 있어야 합니다(참고 참조).
AMS 팀(AppId, 환경 및 AppName)에 필요한 태그 값은 변경 요청에 따라 사용자가 생성한 모든 리소스에서 변경할 수 있습니다.
AMS에 필요한 스택의 태그는 변경 요청에 따라 삭제해서는 안 됩니다.
2번에서 언급한 것처럼 인프라에 AMS 태그 이름 지정 규칙을 사용할 수 없습니다.
AMS에 필요한 리소스에서 사용자 지정 태그를 생성할 수 있습니다(일반적으로 결제 및 비용 보고 사용 사례의 경우). 사용자 지정 태그는 템플릿 업데이트가 아닌 스택 업데이트로 리소스를 업데이트하는 경우 유지됩니다.
참고
AMS 접두사 목록
ams-*
AWSManagedServices*
/ams/*
ams*
AMS*
Ams*
mc*
MC*
맥*
sentinel*
Sentinel*
Managed_Services*
NewAMS*
AWS_*
aws*
VPC_*
CloudTrail*
Cloudtrail*
/aws_reserved/
수집*
EPSDB*
MMS*
TemplateId*
StackSet-ams*
StackSet-AWS-Landing-Zone
IAMPolicy*
고객-mc-*
루트*
LandingZone*
StateMachine*
codedeploy_service_role
관리 호스트
sentinel.int.
eps
UnhealthyInServiceBastion
ms-
| ID | 기술 표준 |
|---|---|
| 1.0 | 제한 시간 지속 시간 |
| 1.1 | 페더레이션 사용자 기본 제한 시간 세션은 1시간이며 최대 4시간까지 늘릴 수 있습니다. |
| 1.2 | 기본 스택 액세스 시간은 12시간입니다. |
| 2.0 | AWS 루트 계정 사용 |
| 2.1 | 어떤 이유로든 루트 계정 사용량이 있는 경우 관련 조사 결과를 생성하도록 Amazon GuardDuty를 구성해야 합니다. |
| 2.2 | 단일 계정 랜딩 존(SALZ) 계정 및 다중 계정 랜딩 존(MALZ) 관리 계정(이전에는 마스터/청구 계정이라고 함)의 경우, 루트 사용자 계정에 가상 MFA가 활성화되어 있어야 하며 계정 온보딩 중에 MFA 소프트 토큰이 삭제되어 AMS와 고객 모두 루트로 로그인할 수 없습니다. AMS Cloud Service Delivery Manager(CSDM)와 함께 표준 AWS 루트 암호 분실 프로세스를 따라야 합니다. 이 구성은 AMS 관리형 계정의 수명 주기 동안 유지되어야 합니다. |
| 2.3 | 루트 계정에 대한 액세스 키를 생성해서는 안 됩니다. |
| 3.0 | 사용자 생성 및 수정 |
| 3.1 | 프로그래밍 방식 액세스 권한과 읽기 전용 권한이 있는 IAM 사용자/역할은 시간 제한 정책 없이 생성할 수 있습니다. 그러나 계정의 모든 Amazon Simple Storage Service 버킷에서 객체(예: S3:GetObject)를 읽을 수 있는 권한은 허용되지 않습니다. |
| 3.1.1 | 콘솔 액세스 및 읽기 전용 권한을 가진 IAM 인간 사용자는 시간 제한 정책(최대 180일)을 사용하여 생성할 수 있지만 시간 제한 정책을 removal/renewal/extension하면 위험 알림이 발생합니다. 그러나 계정의 모든 S3 버킷에서 객체(예: S3:GetObject)를 읽을 수 있는 권한은 허용되지 않습니다. |
| 3.2 | 고객 계정의 인프라 변경 권한(쓰기 및 권한 관리)을 사용한 콘솔 및 프로그래밍 방식 액세스에 대한 IAM 사용자 및 역할은 위험 수락 없이 생성해서는 안 됩니다. 특정 버킷이 비 AMS 관련 태그의 범위 및 태그 지정 작업에 있는 한 위험 수락 없이 허용되는 S3 객체 수준 쓰기 권한에는 예외가 있습니다. |
| 3.3 | SALZ 또는 MALZ 애플리케이션 계정 customer_servicenow_user 및 *코어 계정*의 ServiceNow 통합에 이름이 지정되고 customer_servicenow_logging_user 필요한 프로그래밍 방식 액세스 권한이 있는 IAM 사용자는 시간 제한 정책 없이 생성할 수 있습니다. |
| 3.4 | SALZ customer_cloud_endure_policy 및 MALZ 계정에서 CloudEndure 통합에 필요한 및 customer_cloud_endure_deny_policy (읽기 전용 액세스 포함)를 사용하고 프로그래밍 방식으로 액세스할 수 있는 IAM 사용자는 생성할 수 있지만 계획된 마이그레이션 기간 동안 시간 제한 정책이 필요합니다. 시간 제한은 RA 없이 최대 180일일 수 있습니다. 또한 SCP는 이러한 정책이 필요한 기간 동안 작동하도록 MALZ 계정에 대한 변경 권한이 부여됩니다. 필요에 따라 적절한 마이그레이션 기간을 정의하고 필요에 따라 조정합니다. |
| 4.0 | 정책, 작업 및 APIs |
| 4.1 | SALZ 계정의 모든 IAM 사용자 및 역할에는 AMS 인프라가 실수로 또는 의도적으로 손상되지 않도록 보호하기 위한 기본 고객 거부 정책(CDP)이 연결되어 있어야 합니다. |
| 4.2 | AMS SCPs MALZ의 모든 AMS 관리 계정에서 활성화되어야 합니다. |
| 4.3 | PutKeyPolicy및와 같이 KMS 키에 대한 관리 작업을 수행할 수 있는 자격 증명은 AMS 연산자 및 자동화 보안 주체로만 제한되어야 ScheduleKeyDeletion합니다. |
| 4.4 | 정책은 위험 수락 없이 "Effect": "Allow" with "Action": "*" over "Resource": "*"에 해당하는 문과 함께 관리자 액세스 권한을 제공해서는 안 됩니다. |
| 4.5 | IAM 정책에는 위험 수락 없이 버킷에서 S3:*** 허용 작업이 포함된 작업이 포함되어서는 안 됩니다. |
| 4.6 | 고객 IAM 정책의 AMS 인프라 키에 대한 KMS 키 정책에 대한 API 호출은 허용되지 않아야 합니다. |
| 4.7 | 인스턴스 시작 또는 중지, S3 버킷 또는 RDS 인스턴스 생성 등과 같이 변경 관리 프로세스(RFC)를 우회하는 작업은 허용되지 않아야 합니다. |
| 4.8 | Amazon Route 53에서 AMS 인프라 DNS 레코드를 변경하는 작업은 허용되지 않아야 합니다. |
| 4.9 | 적절한 프로세스를 따른 후 콘솔 액세스 권한이 생성된 IAM 인간 사용자는 신뢰 정책, 역할 수임 및 시간 제한 정책을 제외하고 직접 연결된 정책이 없어야 합니다. |
| 4.10 | 동일한 계정 AWS Secrets Manager 내의 특정 보안 암호 또는 네임스페이스에 대한 읽기 액세스 권한이 있는 Amazon EC2 인스턴스 프로파일을 생성할 수 있습니다. |
| 4.11 | AWS Managed Services Change Management(AMSCM) 또는 AWS Managed Services Service Knowledge Management System(AMSSKMS) 권한을 모든 역할에 추가할 수 있습니다(SR/Incident/RFC를 열 수 있음). |
| 4.12 | IAM 정책에는 AMS Amazon CloudWatch 로그 그룹에서 로그:DeleteLogGroup 및 로그:DeleteLogStream 허용 작업이 포함된 작업이 포함되어서는 안 됩니다. |
| 4.13 | 다중 리전 키를 생성할 수 있는 권한은 허용되지 않아야 합니다. |
| 4.14 | 계정에 아직 생성되지 않은 S3 버킷 ARNs에 대한 액세스를 제공하려면 서비스별 S3 조건 키를 사용하여 계정 번호를 s3:ResourceAccount 지정합니다. |
| 4.15 | 사용자 지정 대시보드에 대한 액세스 권한은 확인, 생성, 나열 및 삭제할 수 있지만 Amazon CloudWatch 대시보드에서는 액세스 권한만 보고 나열할 수 있습니다. |
| 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 정책은 계정의 모든 버킷에서 Amazon S3 버킷 객체(예: Amazon S3:GetObject)에 대한 무제한 읽기 액세스를 허용해서는 안 됩니다.
|
| 4.21 | 리소스 유형 "savingsplan"에 대한 모든 IAM 권한을 고객에게 부여할 수 있습니다. |
| 4.22 | AMS 엔지니어는 Amazon S3, Amazon S3 객체, 데이터베이스)를 수동으로 복사하거나 이동할 수 없습니다. Amazon Relational Database Service DynamoDB |
| 4.23 | AMS 관리형 계정에서 추가 액세스를 허용하도록 SCP 정책을 수정해서는 안 됩니다. |
| 4.24 | AMS 인프라 또는 관리 기능을 손상시킬 수 있는 SCP 정책 변경은 허용되지 않습니다. (참고: AMS 리소스에는 태그가 AppId= AMSInfrastructure 있으며 AMS 보호 네임스페이스를 따릅니다). |
| 4.25 | AMS 자동 IAM 프로비저닝 기능은 계정에서 옵트인 기능으로 활성화해야 합니다. |
| 4.26 | AMS 사람이 맡은 역할 또는 사용자는 S3, RDS, DynamoDB, Redshift, Elasticache, EFS 및 FSx의 고객 콘텐츠에 액세스할 수 없어야 합니다. 또한 고객 콘텐츠에 대한 액세스 권한을 AWS 서비스 부여하는 다른에서 릴리스한 알려진 새 APIs에 대한 액세스는 운영자 역할에서 명시적으로 거부되어야 합니다. |
| 5.0 | 연동 |
| 5.1 | 인증은 AMS 관리형 계정의 페더레이션을 사용하여 구성해야 합니다. |
| 5.2 | AMS AD에서 활성 디렉터리로의 단방향 발신 신뢰만 있어야 합니다(AMS AD는 온프레미스 AD를 신뢰함). |
| 5.3 | AMS에 인증하는 데 사용되는 자격 증명 스토어가 AMS 관리형 애플리케이션 계정에 없어야 합니다. |
| 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.1 | AMS 인프라 리소스는 리소스 기반 정책을 연결하여 승인되지 않은 자격 증명으로 관리로부터 보호해야 합니다. |
| 8.2 | 다른 정책을 명시적으로 지정하지 않는 한 리소스는 최소 권한 리소스 기반 정책으로 구성해야 합니다. |
| 9.0 | 셀프 서비스 프로비저닝된 서비스(SSPS) |
| 9.1 | AMS 기본 IAM 역할 또는 정책(인스턴스 프로파일, SSPS, 패턴 포함)은 위험 수락 여부에 관계없이 수정해서는 안 됩니다. 신뢰 정책에는 예외가 허용됩니다(위험 수락 없음). 역할, 정책 또는 사용자 변경 사항의 태그 지정은 기본 SSP 역할에서도 허용됩니다. |
| 9.3 | Systems Manager Automation 콘솔 역할에 대한 SSPS 정책은 기본 역할 이외의 사용자 지정 역할에 연결할 수 없습니다. 다른 SSPS 정책은 정책을 사용자 지정 역할에 연결하는 것이 기본 SSPS 서비스에 대해 의도된 설계 이외의 추가 권한을 제공하지 않는지 확인한 후에만 사용자 지정 IAM 역할에 연결해야 합니다. |
다음은 003 - 네트워크 보안에 대한 표준 제어입니다.
| ID | 기술 표준 |
|---|---|
| 네트워킹 | |
| 1.0 | 모든 EC2 인스턴스는 접속 호스트, 접속 호스트 VPC CIDR 범위 또는 동일한 인스턴스 VPC CIDR 범위를 통해서만 SSH 또는 RDP를 통해 액세스해야 합니다. |
| 2.0 | EC2 인스턴스에서 탄력적 IP 허용 |
| 3.0 | 데이터 영역 TLS 1.2 이상에서 AMS 컨트롤 플레인 및 확장별를 사용해야 합니다. |
| 4.0 | 모든 송신 트래픽은 계정 IGW 또는 TGW를 사용하여 전달해야 합니다. |
| 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 보안은 보안 그룹이 인스턴스에 연결되도록 요청될 때마다 표준을 나타냅니다. |
| 13.0 | 포트 3389 및 22의 고객 접속 액세스는 DX, VPC-peer 또는 VPN을 통해 VPC로 라우팅되는 프라이빗 IP 범위에서만 허용되어야 합니다. |
| 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 | 위험 알림을 통해 동일한 고객이 AWS 계정 소유한와 해석기 규칙을 공유할 수 있습니다. |
| 19.0 | ICMP |
| 19.1 | 고객 인프라에서 Amazon EC2로 인바운드 ICMP를 요청하려면 위험 알림이 필요합니다. |
| 19.2 | 보안 그룹을 통해 DX, VPC 피어 또는 VPN을 통해 Amazon VPC로 라우팅된 퍼블릭 IPs의 인바운드 요청은 허용됩니다. |
| 19.3 | 보안 그룹을 통해 DX, VPC-peer 또는 VPN을 통해 Amazon VPC로 라우팅되지 않은 퍼블릭 IPs의 인바운드 요청은 위험 승인을 받아야 합니다. |
| 19.4 | Amazon EC2에서 모든 대상으로의 아웃바운드 ICMP 요청이 허용됩니다. |
| 20.0 | 보안 그룹 공유 |
| 20.1 | 보안 그룹이이 보안 표준을 충족하는 경우 동일한 계정VPCs와 동일한 조직의 계정 간에 공유할 수 있습니다. |
| 20.2 | 보안 그룹이이 표준을 충족하지 않고 이전에이 보안 그룹에 대해 위험 수락이 필요한 경우, 동일한 계정의 VPCs 간 또는 동일한 조직의 계정 간 보안 그룹 공유 기능의 사용은 해당 VPC 또는 계정에 대한 위험 수락 없이 허용되지 않습니다. |
다음은 004 - 침투 테스트를 위한 표준 컨트롤입니다.
AMS는 pentest 인프라를 지원하지 않습니다. 이는 고객의 책임입니다. 예를 들어 Kali는 Linux의 AMS 지원 배포판이 아닙니다.
고객은 침투 테스트를
준수해야 합니다. 고객이 계정 내에서 인프라 침투 테스트를 수행하려는 경우 24시간 전에 AMS에 미리 알려야 합니다.
AMS는 고객의 변경 요청 또는 서비스 요청에 명시적으로 명시된 고객 요구 사항에 따라 고객 검사 인프라를 프로비저닝합니다.
인프라를 테스트하는 고객의 자격 증명 관리는 고객의 책임입니다.
다음은 005 - GuardDuty의 표준 컨트롤입니다.
GuardDuty는 모든 고객 계정에서 항상 활성화되어야 합니다.
MALZ의 고객 관리형 애플리케이션 계정(CMA)의 GuardDuty 결과는 운영 팀에 경보를 발생시키지 않습니다.
GuardDuty 알림은 동일한 계정 또는 동일한 조직의 다른 관리형 계정 내에 저장되어야 합니다.
GuardDuty의 신뢰할 수 있는 IP 목록 기능은 사용해서는 안 됩니다. 대신 자동 보관을 대안으로 사용할 수 있으며, 이는 감사 목적에 유용합니다.
위임된 관리자는 위험 수락 없이 다른 계정에서 GuardDuty를 비활성화하는 등의 높은 권한 작업을 수행할 수 있으므로 MALZ에서 GuardDuty 관리자 위임을 활성화해서는 안 됩니다.
GuardDuty Auto Archive Filters는 최대 반환을 위해 최소 범위를 사용해야 합니다. 예를 들어 AMS가 여러 CIDR 블록에서 예측할 수 없는 IPs 여러 개 볼 수 있고 사용하기에 적합한 기업 ASN이 있는 경우 ASN을 사용합니다. 그러나 특정 범위 또는 /32 주소로 범위를 좁힐 수 있는 경우 해당 범위로 범위를 지정합니다.
다음은 006 - 호스트 보안에 대한 표준 제어입니다.
바이러스 백신 에이전트는 항상 모든 EC2 인스턴스에서 실행되어야 합니다(예: Trend Micro").
맬웨어 방지 모듈을 활성화해야 합니다.
EPS 에이전트에는 스캔을 위한 모든 디렉터리와 파일이 포함되어야 합니다.
바이러스 백신 솔루션으로 격리된 파일은 온디맨드 방식으로와 공유할 수 있습니다.
타사 엔드포인트 보안 솔루션을 설치해서는 안 됩니다.
바이러스 백신 서명 업데이트 빈도는 하루에 한 번 이상으로 설정해야 합니다.
예약된 스캔 빈도는 한 달에 한 번 이상으로 설정해야 합니다.
실시간(액세스 중) 스캔은 항상 활성화되고 실행되어야 합니다.
AMS는 인스턴스에서 AMS가 소유하거나 작성하지 않은 사용자 지정 스크립트를 실행해서는 안 됩니다. (참고: 스택 관리자 액세스 CT를 통해 스택 관리자 액세스를 사용하거나 AWS Systems Manager 자동화(AMS SSPS)를 사용하여이 작업을 수행할 수 있습니다.
Windows 호스트에서 네트워크 수준 인증(NLA)을 비활성화해서는 안 됩니다.
호스트 운영 체제는 구성된 패치 주기에 따라 최신 보안 패치를 사용하여 최신 상태여야 합니다.
AMS 관리형 계정에는 계정에 비관리형 인스턴스가 없어야 합니다.
AMS에서 인스턴스에 로컬 관리자 계정을 생성할 수 없습니다.
EC2의 키 페어를 생성해서는 안 됩니다.
수명 종료(EOL)로 선언된 운영 체제를 사용해서는 안 되며 공급업체 또는 타사에서 제공하는 추가 보안 지원이 없어야 합니다.
다음은 007 - 로깅에 대한 표준 컨트롤입니다.
| 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.6 | 엔드포인트 보호 시스템(EPS) 로그: 로그를 CloudWatch Logs 로그 그룹에 전달하도록 EPS 솔루션 로깅을 활성화하고 구성해야 합니다. |
| 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.1 | 로그 및 CloudWatch Logs; 로그 그룹을 저장하는 AMS에 필요한 S3 버킷에는 쓰기 또는 삭제 액세스 권한이 없어야 합니다. |
| 2.2 | 계정의 모든 로그에 대한 읽기 전용 액세스 권한이 있어야 합니다. |
| 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 고객이 소유한 경우에만 모든 로그를 AMS에서 비 AMS 계정으로 전달할 수 있습니다. |
| 6.3 | 고객 계정의 로그는 타사 계정(고객이 소유하지 않은 계정)으로 전달해서는 안 됩니다. |
다음은 008 - AMS-MAD에 대한 표준 컨트롤입니다.
| ID | 기술 표준 |
|---|---|
| 1.0 | 액세스 관리 |
| 1.1 | 대화형 로그인 및 자동화 작업이 있는 AMS 권한이 있는 사용자만 고객 계정에서 관리형 AD를 관리하기 위해 관리 호스트에 로그인할 수 있어야 합니다. |
| 1.2 | AD 관리자는 위임된 관리자 권한(AMS 위임된 관리자 그룹)만 있어야 합니다. |
| 1.3 | 고객 AD 환경(관리 호스트 또는 인스턴스)에 로그인하는 엔지니어는 시간 제한 액세스 권한이 있어야 합니다. |
| 1.4 | 고객은 EC2 인스턴스에서 원격 서버 관리자 도구를 사용하여 AD 객체에 대한 읽기 전용 액세스 권한을 가집니다. |
| 1.5 | Active Directory 사용자 또는 그룹에 대한 관리 권한은 허용되지 않아야 합니다. |
| 1.6 | AWS 동일한 고객이 AWS 계정 소유한 와의 디렉터리 공유는 위험 알림과 함께 허용됩니다. |
| 2.0 | 서비스 계정 |
| 2.1 | 그룹 관리형 서비스 계정(gMSA)은 표준 서비스 계정 대신 애플리케이션에서 지원하는 모든 곳에서 사용해야 합니다. |
| 2.2 | 다른 모든 서비스 계정은 위험 수락 프로세스 후에 생성해야 합니다. |
| 2.3 | AD 보안 그룹은 고객이 명시적으로 요청하지 않는 한 재사용해서는 안 됩니다. 새 AD 그룹을 생성해야 합니다. 서비스 계정에 대한 액세스를 요청하는 컴퓨터 객체를 새 보안 그룹에 추가해야 합니다. |
| 2.4 | 모든 gMSA 서비스 계정(들)은 "관리형 서비스 계정" 조직 단위(OU) 아래에 추가해야 합니다. |
| 2.5 | gMSA가 아닌 서비스 계정(들)은 "Users"Service Accounts" OU 아래에 추가해야 합니다. |
| 3.0 | 그룹 정책 객체(GPO) |
| 3.1 | "Windows Settings > Security Settings" GPO 아래의 설정은 현재 상태에서 어떤 방식으로든 계정의 보안 태세를 저하시키는 경우 수정해서는 안 됩니다. |
| 3.2 | GPO 생성을 요청하는 애플리케이션 계정에서 제출된 RFCs인 MALZ에서는 GPO를 앱 계정에 해당하는 OU에 연결해야 합니다. 모든 계정에 영향을 미치는 모든 GPOs는 공유 서비스 계정에서 가져와야 합니다. |
| 3.3 | 활성 디렉터리 도메인의 모든 서버에 대해 기본 RDP 유휴 세션 제한 시간을 15분으로 설정해야 합니다. |
| 4.0 | Active Directory 신뢰 |
| 4.1 | 조건부 전달자의 IPs가 DX, VPC-peer 또는 VPN을 통해 VPC로 라우팅되는 경우 단방향 아웃바운드 신뢰(AMS 호스팅 디렉터리에서 고객 디렉터리로)가 허용됩니다. |
| 5.0 | 기타 |
| 5.1 | 로그 파일 무결성 메커니즘을 활성화해야 합니다. "로그 파일 검증"은 AMS 팀에 필요한 AWS CloudTrail 추적에서 구성해야 합니다. |
| 6.0 | 로그 전달 |
| 6.1 | 고객 사용자, 그룹, 컴퓨터 객체, OU 또는 기타 엔터티는 AMS 명명 규칙에 따라 AMS 명명 규칙을 사용해서는 안 됩니다. |
| 6.2 | 모든 OUs AMS에서 관리해야 합니다. |
다음은 009 - 기타에 대한 표준 컨트롤입니다.
리소스, 객체, 데이터베이스 또는 파일 시스템에서 암호화가 활성화된 경우 암호화를 비활성화해서는 안 됩니다.
