# Amazon EC2의 보안
AWS에서는 클라우드 보안을 가장 중요하게 생각합니다. AWS 고객은 보안에 가장 보안에 민감한 조직의 요구 사항에 부합하도록 빌드된 데이터 센터 및 네트워크 아키텍처의 혜택을 누릴 수 있습니다.
보안은 AWS와 여러분의 공동 책임입니다. [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 이 사항을 클라우드의 보안 및 클라우드 내 보안으로 설명합니다.
+ **클라우드의 보안**: AWS는 AWS클라우드에서 AWS서비스를 실행하는 인프라를 보호할 책임이 있습니다. AWS는 안전하게 사용할 수 있는 서비스 또한 제공합니다. 타사 감사자는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)의 일환으로 보안 효과를 정기적으로 테스트하고 검증합니다. Amazon EC2에 적용되는 규정 준수 프로그램에 대한 자세한 내용은 [규정 준수 프로그램의 범위에 속하는 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하세요.
+ **클라우드 내부의 보안** - 고객의 책임에는 다음 영역이 포함됩니다.
+ VPC 및 보안 그룹을 구성하는 등의 작업을 통해 인스턴스에 대한 네트워크 액세스를 제어합니다. 자세한 내용은 [네트워크 트래픽 제어](infrastructure-security.md#control-network-traffic) 섹션을 참조하세요.
+ 인스턴스 연결에 사용되는 자격 증명을 관리합니다.
+ 업데이트 및 보안 패치를 포함하여 게스트 운영 체제에 배포된 게스트 운영 체제 및 소프트웨어를 관리합니다. 자세한 내용은 [Amazon EC2 인스턴스에 대한 업데이트 관리](update-management.md) 섹션을 참조하세요.
+ 인스턴스에 연결된 IAM 역할 및 해당 역할과 연결된 권한을 구성합니다. 자세한 내용은 [Amazon EC2의 IAM 역할](iam-roles-for-amazon-ec2.md) 섹션을 참조하세요.
이 설명서는 Amazon EC2를 사용할 때 공동 책임 모델을 적용하는 방법을 이해하는 데 도움이 됩니다. 보안 및 규정 준수 목표에 맞게 Amazon EC2를 구성하는 방법을 보여줍니다. 또한 Amazon EC2 리소스를 모니터링하고 보호하는 데 도움이 되는 다른 AWS 서비스를 사용하는 방법을 알아봅니다.
**Topics**
+ [데이터 보호](data-protection.md)
+ [인프라 보안](infrastructure-security.md)
+ [복원성](disaster-recovery-resiliency.md)
+ [규정 준수 확인](compliance-validation.md)
+ [Identity and Access Management](security-iam.md)
+ [업데이트 관리](update-management.md)
+ [Windows 인스턴스 모범 사례](ec2-windows-security-best-practices.md)
+ [키 페어](ec2-key-pairs.md)
+ [보안 그룹](ec2-security-groups.md)
+ [NitroTPM](nitrotpm.md)
+ [EC2 인스턴스 증명](nitrotpm-attestation.md)
+ [Windows 인스턴스용 Credential Guard](credential-guard.md)
+ [AWS PrivateLink](interface-vpc-endpoints.md)
# Amazon EC2의 데이터 보호
AWS [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 Amazon Elastic Compute Cloud의 데이터 보호에 적용됩니다. 이 모델에서 설명하는 것처럼 AWS는 모든 AWS 클라우드를 실행하는 글로벌 인프라를 보호할 책임이 있습니다. 사용자는 이 인프라에 호스팅되는 콘텐츠에 대한 통제 권한을 유지할 책임이 있습니다. 사용하는 AWS 서비스의 보안 구성과 관리 태스크에 대한 책임도 사용자에게 있습니다. 데이터 프라이버시에 관한 자세한 내용은 [데이터 프라이버시 FAQ](https://aws.amazon.com/compliance/data-privacy-faq/)를 참조하세요. 유럽의 데이터 보호에 대한 자세한 내용은 *AWS보안 블로그*의 [AWS공동 책임 모델 및 GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 블로그 게시물을 참조하세요.
데이터를 보호하려면 AWS 계정자격 증명을 보호하고 AWS IAM Identity Center또는 AWS Identity and Access Management(IAM)를 통해 개별 사용자 계정을 설정하는 것이 좋습니다. 이렇게 하면 개별 사용자에게 자신의 직무를 충실히 이행하는 데 필요한 권한만 부여됩니다. 또한 다음과 같은 방법으로 데이터를 보호하는 것이 좋습니다.
+ 각 계정에 다중 인증(MFA)을 사용합니다.
+ SSL/TLS를 사용하여 AWS리소스와 통신하세요. TLS 1.2는 필수이며 TLS 1.3을 권장합니다.
+ AWS CloudTrail으로 API 및 사용자 활동 로깅을 설정하세요. AWS 활동 캡처에 CloudTrail 추적을 사용하는 방법에 대한 자세한 내용은 *AWS CloudTrail사용 설명서*의 [CloudTrail 추적 작업](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)을 참조하세요.
+ AWS 암호화 솔루션을 AWS 서비스내의 모든 기본 보안 컨트롤과 함께 사용하세요.
+ Amazon S3에 저장된 민감한 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용합니다.
+ 명령줄 인터페이스 또는 API를 통해 AWS에 액세스할 때 FIPS 140-3 검증된 암호화 모듈이 필요한 경우, FIPS 엔드포인트를 사용합니다. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 [연방 정보 처리 표준(FIPS) 140-3](https://aws.amazon.com/compliance/fips/)을 참조하세요.
고객의 이메일 주소와 같은 기밀 정보나 중요한 정보는 태그나 **이름** 필드와 같은 자유 형식 텍스트 필드에 입력하지 않는 것이 좋습니다. 여기에는 Amazon EC2 또는 기타 AWS 서비스에서 콘솔, API, AWS CLI 또는 AWS SDK를 사용하여 작업하는 경우가 포함됩니다. 이름에 사용되는 태그 또는 자유 형식 텍스트 필드에 입력하는 모든 데이터는 청구 또는 진단 로그에 사용될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 자격 증명을 URL에 포함해서는 안 됩니다.
**Topics**
+ [Amazon EBS 데이터 보안](#ebs-data-security)
+ [저장 시 암호화](#encryption-rest)
+ [전송 중 데이터 암호화](#encryption-transit)
## Amazon EBS 데이터 보안
Amazon EBS 볼륨은 포맷되지 않은 원시 블록 디바이스로 제공됩니다. 이러한 디바이스는 EBS 인프라에서 생성되는 논리적 디바이스이며 Amazon EBS 서비스는 고객이 사용하거나 재사용하기 전에 디바이스가 논리적으로 비어 있는지(즉, 원시 블록이 0이 되거나 암호화된 의사 난수 데이터를 포함하는지) 확인합니다.
**DoD 5220.22-M**(국가 산업 보안 프로그램 운영 매뉴얼) 또는 **NIST 800-88**(미디어 삭제 지침)에 자세히 설명된 것과 같이 사용 후, 사용 전 또는 사용 전후에 특정 방법을 사용하여 모든 데이터를 지워야 하는 절차가 있는 경우 Amazon EBS에서 해당 작업을 수행할 수 있습니다. 해당 블록 수준 활동은 Amazon EBS 서비스 내의 기본 스토리지 미디어에 반영됩니다.
## 저장 시 암호화
**EBS 볼륨**
Amazon EBS 암호화는 EBS 볼륨과 스냅샷에 대한 암호화 솔루션입니다. 이는 AWS KMS keys을(를) 사용합니다. 자세한 내용은 *Amazon EBS 사용 설명서*의 [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html)을 참조하세요.
[Windows 인스턴스] 또한 폴더 및 파일 수준 암호화에 Microsoft EFS 및 NTFS 권한을 사용할 수도 있습니다.
**인스턴스 저장소 볼륨**
인스턴스의 하드웨어 모듈에 구현된 XTS-AES-256 암호를 사용하여 NVMe 인스턴스 저장소 볼륨의 데이터를 암호화합니다. 로컬로 연결된 NVMe 스토리지 디바이스에 기록된 데이터를 암호화하는 데 사용되는 키는 고객별 및 볼륨별입니다. 키는 AWS 직원이 액세스할 수 없는 하드웨어 모듈에 의해 생성되고 그 안에만 상주합니다. 인스턴스가 중지되거나 종료되면 암호화 키가 손상되어 복구가 불가능해집니다. 이 암호화를 비활성화할 수 없으며, 사용자 자신의 암호화 키를 제공할 수 없습니다.
H1, D3 및 D3en 인스턴스의 HDD 인스턴스 저장소 볼륨에 저장되는 데이터는 XTS-AES-256 및 일회용 키를 사용하여 암호화됩니다.
인스턴스를 중지하거나 최대 절전 모드로 전환하거나 종료하면 인스턴스 저장소 볼륨의 모든 스토리지 블록이 재설정됩니다. 따라서 다른 인스턴스의 인스턴스 저장소를 통해 데이터를 액세스할 수 없습니다.
**Memory**
메모리 암호화는 다음 인스턴스에서 활성화됩니다.
+ AWS Graviton2 이상 AWS Graviton 프로세서가 있는 인스턴스는 상시 작동 메모리 암호화를 지원합니다. 암호화 키는 호스트 시스템 내에서 안전하게 생성되고 호스트 시스템을 벗어나지 않으며 호스트를 재부팅하거나 전원을 끌 때 삭제됩니다. 자세한 내용은 [AWS Graviton 프로세서](https://aws.amazon.com/ec2/graviton/)를 참조하세요.
+ 3세대 인텔 제온 스케일러블 프로세서(Ice Lake)가 있는 인스턴스(예: M6i 인스턴스)와 4세대 인텔 제온 스케일러블 프로세서(Sapphire Rapids)가 있는 인스턴스(예: M7i 인스턴스)입니다. 이 프로세서는 인텔 전체 메모리 암호화(TME)를 사용한 상시 메모리 암호화를 지원합니다.
+ 3세대 AMD EPYC 프로세서(Milan)가 있는 인스턴스(예: M6a 인스턴스)와 4세대 AMD EPYC 프로세서(Genoa)가 있는 인스턴스(예: M7a 인스턴스)입니다. 이러한 프로세서에서는 AMD SME(Secure Memory Encryption)를 사용하는 상시 메모리 암호화를 지원합니다.
+ AMD Secure Encrypted Virtualization-Secure Nested Paging(SEV-SNP)은 일부 AMD 기반 인스턴스 유형에서 지원됩니다. 자세한 내용은 [AMD SEV-SNP를 지원하는 EC2 인스턴스 유형 찾기](snp-find-instance-types.md) 섹션을 참조하세요.
## 전송 중 데이터 암호화
**물리적 계층에서의 암호화**
AWS 글로벌 네트워크를 통해 AWS 리전으로 흐르는 모든 데이터는 AWS 보안 시설을 떠나기 전에 물리적 계층에서 자동으로 암호화됩니다. AZ 간에 전송되는 모든 트래픽은 암호화됩니다. 이 섹션에 나열된 암호화 계층을 비롯한 추가 암호화 계층은 추가적인 보호 기능을 제공할 수 있습니다.
**Amazon VPC 피어링 및 전송 게이트웨이 리전 간 피어링에서 제공하는 암호화**
Amazon VPC 피어링 및 전송 게이트웨이 피어링을 사용하는 모든 리전 간 트래픽은 리전을 종료하면 자동으로 대량 암호화됩니다. 앞서 이 섹션에서 설명한 것처럼 AWS 보안 시설에서 나가기 전에 모든 트래픽에 대한 추가 암호화 계층이 물리적 계층에서 자동으로 제공됩니다.
**인스턴스 간 암호화**
AWS는 모든 유형의 EC2 인스턴스 간 보안 프라이빗 연결을 제공합니다. 또한 일부 인스턴스 유형은 기본 Nitro 시스템 하드웨어의 오프로드 기능을 사용하여 인스턴스 간 전송 중 트래픽을 자동으로 암호화합니다. 이 암호화는 256비트 암호화와 함께 관련 데이터로 인증된 암호화(AEAD) 알고리즘을 사용합니다. 네트워크 성능에는 영향을 미치지 않습니다. 인스턴스 간에 이러한 전송 중 트래픽 암호화를 추가로 지원하려면 다음 요구 사항을 충족해야 합니다.
+ 이러한 인스턴스는 다음 인스턴스 유형을 사용합니다.
+ **범용**: M5dn, M5n, M5zn, M6a, M6i, M6id, M6idn, M6in, M7a, M7g, M7gd, M7i, M7i-flex, M8a, M8azn, M8g, M8gb, M8gd, M8gn, M8i, M8id, M8i-flex, Mac-m4, Mac-m4pro
+ **컴퓨팅 최적화:** C5n, C6a, C6gn, C6i, C6id, C6in, C7a, C7g, C7gd, C7gn, C7i, C7i-flex, C8a, C8g, C8gb, C8gd, C8gn, C8i, C8id, C8i-flex
+ **메모리 최적화:** R5dn, R5n, R6a, R6i, R6id, R6idn, R6in, R7a, R7g, R7gd, R7i, R7iz, R8a, R8g, R8gb, R8gd, R8gn, R8i, R8id, R8i-flex, U-3tb1, U-6tb1, U-9tb1, U-12tb1, U-18tb1, U-24tb1, U7i-6tb, U7i-8tb, U7i-12tb, U7in-16tb, U7in-24tb, U7in-32tb, U7inh-32tb, X2idn, X2iedn, X2iezn, X8g, X8aedz, X8i
+ **스토리지 최적화:** D3, D3en, I3en, I4g, I4i, I7i, I7ie, I8g, I8ge, Im4gn, Is4gen
+ **가속 컴퓨팅:** DL1, DL2q, F2, G4ad, G4dn, G5, G6, G6e, G6f, Gr6, Gr6f, G7e, Inf1, Inf2, P3dn, P4d, P4de, P5, P5e, P5en, P6-B200, P6-B300, P6e-GB200, Trn1, Trn1n, Trn2, Trn2u, VT1
+ **고성능 컴퓨팅:** Hpc6a, Hpc6id, Hpc7a, Hpc7g, Hpc8a
+ 인스턴스가 동일한 리전에 있습니다.
+ 인스턴스가 동일한 VPC 또는 피어링된 VPC에 있으며, 트래픽이 로드 밸런서나 전송 게이트웨이 같은 가상 네트워크 디바이스 또는 서비스를 통과하지 않습니다.
앞서 이 섹션에서 설명한 것처럼 AWS 보안 시설에서 나가기 전에 모든 트래픽에 대한 추가 암호화 계층이 물리적 계층에서 자동으로 제공됩니다.
**AWS CLI를 사용하여 인스턴스 간에 전송 중인 트래픽을 암호화하는 인스턴스 유형을 보려면**
다음 [ describe-instance-types](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-types.html) 명령을 사용합니다.
```
aws ec2 describe-instance-types \
--filters Name=network-info.encryption-in-transit-supported,Values=true \
--query "InstanceTypes[*].[InstanceType]" \
--output text | sort
```
**AWS Outposts로의 암호화**
Outpost는 AWS 홈 리전에 대한 *서비스 링크*라는 특정 네트워크 연결을 생성하고 선택적으로 사용자가 지정한 VPC 서브넷에 대한 프라이빗 연결을 생성합니다. 이러한 연결을 통한 모든 트래픽은 완전히 암호화됩니다. 자세한 내용은 *AWS Outposts 사용 설명서*에서 [서비스 링크를 통한 연결](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links) 및 [전송 중 암호화](https://docs.aws.amazon.com/outposts/latest/userguide/data-protection.html#encryption-transit)를 참조하세요.
**원격 액세스 암호화**
SSH 및 RDP 프로토콜은 직접 또는 EC2 인스턴스 연결을 통해 인스턴스에 원격으로 액세스할 수 있는 보안 통신 채널을 제공합니다. AWS Systems Manager Session Manager 및 Run Command를 사용하는 인스턴스에 대한 원격 액세스는 TLS 1.2를 사용하여 암호화되며, 연결을 생성하기 위한 요청은 [SigV4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)를 사용하여 서명되고 [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)에 의해 인증되고 권한이 부여됩니다.
Transport Layer Security(TLS)와 같은 암호화 프로토콜을 사용하여 클라이언트와 Amazon EC2 인스턴스 간에 전송 중인 민감한 데이터를 암호화할 책임은 사용자에게 있습니다.
(Windows 인스턴스) EC2 인스턴스와 AWS API 엔드포인트 또는 기타 중요한 원격 네트워크 서비스 간에는 암호화된 연결만 허용해야 합니다. 아웃바운드 보안 그룹 또는 [Windows 방화벽](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/) 규칙을 통해 이를 적용할 수 있습니다.
# Amazon EC2의 인프라 보안
관리형 서비스인 Amazon Elastic Compute Cloud는 AWS 글로벌 네트워크 보안으로 보호됩니다. AWS 보안 서비스와 AWS의 인프라 보호 방법에 대한 자세한 내용은 [AWS 클라우드 보안](https://aws.amazon.com/security/)을 참조하세요. 인프라 보안에 대한 모범 사례를 사용하여 AWS 환경을 설계하려면 *보안 원칙 AWS Well‐Architected 프레임워크*의 [인프라 보호](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)를 참조하세요.
AWS에서 게시한 API 호출을 사용하여 네트워크를 통해 Amazon EC2에 액세스합니다. 클라이언트는 다음을 지원해야 합니다.
+ Transport Layer Security(TLS). TLS 1.2는 필수이며 TLS 1.3을 권장합니다.
+ DHE(Ephemeral Diffie-Hellman) 또는 ECDHE(Elliptic Curve Ephemeral Diffie-Hellman)와 같은 완전 전송 보안(PFS)이 포함된 암호 제품군. Java 7 이상의 최신 시스템은 대부분 이러한 모드를 지원합니다.
자세한 내용은 *보안 부문 - AWS Well-Architected 프레임워크*의 [인프라 보호](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)를 참조하세요.
## 네트워크 격리
가상 프라이빗 클라우드(VPC)는 AWS 클라우드에서 논리적으로 격리된 고유한 영역의 가상 네트워크입니다. 별도의 VPC를 사용하여 워크로드별 또는 조직체별로 인프라를 격리합니다.
서브넷은 VPC의 IP 주소 범위입니다. 인스턴스를 시작할 때 VPC의 서브넷에서 인스턴스를 시작합니다. 서브넷을 사용하여 단일 VPC 내의 애플리케이션 티어(예: 웹, 애플리케이션 및 데이터베이스)를 격리합니다. 인터넷에서 직접 액세스하면 안 되는 경우 프라이빗 서브넷을 인스턴스에 사용합니다.
프라이빗 IP 주소를 사용하여 VPC에서 Amazon EC2 API를 호출하려면 AWS PrivateLink을(를) 사용합니다. 자세한 내용은 [인터페이스 VPC 엔드포인트를 사용하여 Amazon EC2에 액세스](interface-vpc-endpoints.md) 섹션을 참조하세요.
## 물리적 호스트에서 격리
동일한 물리적 호스트에 있는 다양한 EC2 인스턴스는 개별 물리적 호스트에 있는 것처럼 서로 격리됩니다. 하이퍼바이저는 CPU와 메모리를 격리하며, 인스턴스에는 원시 디스크 디바이스에 대한 액세스 대신 가상화된 디스크가 제공됩니다.
인스턴스를 중지하거나 종료하면 인스턴스에 할당된 메모리는 새 인스턴스에 할당되기 전에 하이퍼바이저에서 스크러빙(0으로 설정)되며 스토리지의 모든 블록은 재설정됩니다. 이 방법으로 데이터가 의도하지 않게 다른 인스턴스에 노출되지 않도록 보호합니다.
네트워크 MAC 주소는 AWS 네트워크 인프라에서 인스턴스에 동적으로 할당됩니다. IP 주소는 AWS 네트워크 인프라에서 인스턴스에 동적으로 할당되거나, 인증된 API 요청을 통해 EC2 관리자가 할당합니다. AWS 네트워크에서 인스턴스는 할당된 MAC 및 IP 주소에서만 트래픽을 전송할 수 있습니다. 그렇지 않으면 트래픽이 끊어집니다.
기본적으로 인스턴스는 특정하게 주소 지정되지 않은 트래픽을 수신할 수 없습니다. 인스턴스에서 네트워크 주소 변환(NAT), 라우팅 또는 방화벽 서비스를 실행해야 하는 경우 네트워크 인터페이스에 대한 소스/대상 확인을 비활성화할 수 있습니다.
## 네트워크 트래픽 제어
EC2 인스턴스의 네트워크 트래픽을 제어하기 위해 다음 옵션을 고려해 보세요.
+ [보안 그룹](ec2-security-groups.md)을 사용하여 인스턴스에 대한 액세스를 제한합니다. 필요한 최소한의 네트워크 트래픽을 허용하는 규칙을 구성합니다. 예를 들어 회사 네트워크 주소 범위의 트래픽만 허용하거나 HTTPS와 같은 특정 프로토콜에 대해서만 트래픽을 허용할 수 있습니다. Windows 인스턴스의 경우 Windows 관리 트래픽과 최소한의 아웃바운드 연결을 허용합니다.
+ 보안 그룹을 Amazon EC2 인스턴스에 대한 네트워크 액세스를 제어하는 기본 메커니즘으로 활용합니다. 필요한 경우 네트워크 ACL을 거의 사용하지 않고 상태 비저장, 거친 네트워크 제어를 제공합니다. 보안 그룹은 상태 저장 패킷 필터링을 수행하고 다른 보안 그룹을 참조하는 규칙을 만들 수 있기 때문에 네트워크 ACL보다 다재다능합니다. 그러나 네트워크 ACL은 특정한 트래픽 하위 집합을 거부하거나 상위 수준의 서브넷 가드레일을 제공하는 보조적 제어 장치로 효과를 발휘할 수 있습니다. 또한 네트워크 ACL은 전체 서브넷에 적용되므로 인스턴스가 올바른 보안 그룹 없이 실수로 시작될 경우 이를 심층 방어 기능으로 사용할 수 있습니다.
+ [Windows 인스턴스] Windows 방화벽 설정을 그룹 정책 개체(GPO)로 중앙에서 관리하여 네트워크 제어를 더욱 강화합니다. 고객들은 종종 네트워크 트래픽을 더 잘 파악하고 보안 그룹 필터를 보완하기 위해 Windows 방화벽을 사용하며, 고급 규칙을 만들어 특정 애플리케이션이 네트워크에 액세스하지 못하도록 차단하거나 하위 집합 IP 주소에서 오는 트래픽을 필터링하기도 합니다. 예를 들어 Windows 방화벽은 특정 사용자 또는 애플리케이션만 EC2 메타데이터 서비스 IP 주소에 액세스할 수 있도록 제한할 수 있습니다. 또는 공용 서비스에서 보안 그룹을 사용하여 트래픽을 특정 포트로 제한하고 Windows 방화벽을 사용하여 명시적으로 차단된 IP 주소의 목록을 유지 관리할 수 있습니다.
+ 인터넷에서 직접 액세스하면 안 되는 경우 프라이빗 서브넷을 인스턴스에 사용합니다. 프라이빗 서브넷에 있는 인스턴스에서 인터넷에 액세스하려면 Bastion Host 또는 NAT 게이트웨이를 사용합니다.
+ [Windows instances] SSL/TLS를 통한 RDP 캡슐화와 같은 보안 관리 프로토콜을 사용합니다. 원격 데스크톱 게이트웨이 빠른 시작은 SSL/TLS를 사용하도록 RDP를 구성하는 등 원격 데스크톱 게이트웨이 배포의 모범 사례를 제공합니다.
+ [Windows 인스턴스] Active Directory 또는 Directory Service를 사용하여 Windows 인스턴스에 대한 사용자 및 그룹의 대화식 액세스를 중앙 집중식으로 엄격하게 제어 및 모니터링하고 로컬 사용자 권한을 피할 수 있습니다. 또한 도메인 관리자를 사용하지 않고 보다 세분화된 애플리케이션별 역할 기반 계정을 만들 수 있습니다. JEA(충분한 관리)를 사용하면 대화식 액세스 또는 관리자 액세스 없이도 Windows 인스턴스의 변경 사항을 관리할 수 있습니다. 또한 JEA에서는 인스턴스 관리에 필요한 Windows PowerShell 명령의 하위 집합에 대한 관리 액세스를 잠글 수 있습니다. 자세한 내용은 [AWS 보안 모범 사례](https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf) 백서의 “Amazon EC2에 대한 OS 수준 액세스 관리” 섹션을 참조하세요.
+ [Windows 인스턴스] 시스템 관리자는 액세스 권한이 제한된 Windows 계정을 사용하여 일상적인 작업을 수행하고 특정한 구성 변경을 수행하는 데 필요한 경우에만 액세스 권한을 상승해야 합니다. 또한 절대적으로 필요한 경우에만 Windows 인스턴스에 직접 액세스합니다. 그 대신 EC2 실행 명령, SCCM(시스템 센터 구성 관리자), Windows PowerShell DSC 또는 SSM(Amazon EC2 Systems Manager)과 같은 중앙 구성 관리 시스템을 활용하여 Windows 서버에 변경 사항을 적용합니다.
+ 필요한 최소한의 네트워크 경로로 Amazon VPC 서브넷 라우팅 테이블을 구성합니다. 예를 들어, 인터넷 게이트웨이로 가는 경로가 있는 서브넷에는 인터넷에 직접 액세스해야 하는 Amazon EC2 인스턴스만 배치하고, 가상 프라이빗 게이트웨이로 가는 경로가 있는 서브넷에는 내부 네트워크에 직접 액세스해야 하는 Amazon EC2 인스턴스만 배치합니다.
+ 보안 그룹 또는 네트워크 인터페이스를 추가로 사용하여 일반 애플리케이션 트래픽과 별도로 Amazon EC2 인스턴스 관리 트래픽을 제어하고 감사하는 방법을 고려해 보세요. 이렇게 하면 변경 제어를 위한 특별한 IAM 정책을 고객이 구현할 수 있으므로 보안 그룹 규칙 또는 자동화된 규칙 확인 스크립트의 변경 사항을 감사하기가 쉬워집니다. 여러 네트워크 인터페이스를 사용하면 호스트 기반 라우팅 정책을 생성하거나 네트워크 인터페이스의 할당된 서브넷에 따라 다른 VPC 서브넷 라우팅 규칙을 활용하는 기능 등 네트워크 트래픽을 제어할 수 있는 추가 옵션도 제공됩니다.
+ AWS Virtual Private Network 또는 Direct Connect를 사용하여 원격 네트워크에서 VPC로 프라이빗 연결을 설정합니다. 자세한 내용은 [네트워크-Amazon VPC 연결 옵션](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)을 참조하세요.
+ [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)를 사용하여 인스턴스에 도달하는 트래픽을 모니터링합니다.
+ [GuardDuty Malware Protection](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection.html)을 사용하여 인스턴스에서 워크로드를 손상시키고 리소스를 악의적인 용도로 재사용하며 이터에 대한 무단으로 액세스할 수 있는 악성 소프트웨어를 나타내는 의심스러운 동작을 식별합니다.
+ [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)을 사용하여 인스턴스에 대한 잠재적 위협을 식별하고 이에 대응합니다. 자세한 내용은 [How Runtime Monitoring works with Amazon EC2 instances](https://docs.aws.amazon.com/guardduty/latest/ug/how-runtime-monitoring-works-ec2.html)를 참조하세요.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/), [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/) 또는 [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/)를 사용하여 인스턴스에서 의도하지 않은 네트워크 액세스를 검사합니다.
+ [EC2 Instance Connect](connect-linux-inst-eic.md)를 사용하여 SSH 키를 공유하고 관리할 필요 없이 Secure Shell(SSH)을 통해 인스턴스에 연결합니다.
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)를 사용하면 인바운드 SSH 또는 RDP 포트를 열고 키 페어를 관리하는 대신 원격으로 인스턴스에 액세스할 수 있습니다.
+ [AWS Systems Manager 실행 명령](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)을 사용하여 인스턴스에 연결하는 대신 일반적인 관리 작업을 자동화할 수 있습니다.
+ [Windows 인스턴스] Windows OS 역할 및 Microsoft 비즈니스 애플리케이션은 대부분 IIS 내 IP 주소 범위 제한, Microsoft SQL Server의 TCP/IP 필터링 정책 및 Microsoft Exchange의 연결 필터 정책과 같은 향상된 기능을 제공합니다. 애플리케이션 계층 내 네트워크 제한 기능은 중요한 비즈니스 애플리케이션 서버에 대한 추가 방어 계층을 제공할 수 있습니다.
Amazon VPC는 게이트웨이, 프록시 서버, 네트워크 모니터링 옵션과 같은 추가 네트워크 보안 제어를 지원합니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [네트워크 트래픽 제어](https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html#control-network-traffic)를 참조하세요.
# Amazon EC2의 복원성
AWS 글로벌 인프라는 AWS 리전 및 가용 영역을 중심으로 구축됩니다. 리전은 물리적으로 분리되고 격리된 다수의 가용 영역을 제공하며, 이러한 영역은 짧은 지연 시간, 높은 처리량 및 높은 중복성을 갖춘 네트워크를 통해 연결되어 있습니다. 가용 영역을 사용하면 중단 없이 영역 간에 자동으로 장애 극복 조치가 이루어지는 애플리케이션 및 데이터베이스를 설계하고 운영할 수 있습니다. 가용 영역은 기존의 단일 또는 다중 데이터 센터 인프라보다 가용성, 내결함성, 확장성이 뛰어납니다.
더 먼 지역적 거리를 두고 데이터 또는 애플리케이션을 복제해야 하는 경우 AWS 로컬 영역을 사용하세요. AWS 로컬 영역은 사용자와 지리적으로 근접한 AWS 리전의 확장입니다. 로컬 영역은 인터넷에 대한 자체 연결을 가지고 있으며 Direct Connect를 지원합니다. 모든 AWS 리전과 마찬가지로 AWS 로컬 영역은 다른 AWS 영역과 완벽히 격리되어 있습니다.
AWS 로컬 영역에서 데이터나 애플리케이션을 복제해야 하는 경우 AWS에서는 다음 영역 중 하나를 장애 조치 영역으로 사용하는 것이 좋습니다.
+ 다른 로컬 영역
+ 상위 영역이 아닌 리전의 가용 영역입니다. [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) 명령을 사용하여 상위 영역을 볼 수 있습니다.
AWS 리전 및 가용 영역에 대한 자세한 내용은 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요.
AWS 글로벌 인프라 외에도 Amazon EC2는 데이터 복원력을 지원하기 위해 다음과 같은 기능을 제공합니다.
+ 리전 간 AMI 복사
+ 리전 간 EBS 스냅샷 복사
+ Amazon Data Lifecycle Manager를 사용하여 EBS-backed AMI 자동화
+ Amazon Data Lifecycle Manager를 사용하여 EBS 스냅샷 자동화
+ Amazon EC2 Auto Scaling을 사용하여 플릿의 상태 및 가용성 유지 관리
+ Elastic Load Balancing을 사용하여 단일 가용 영역 또는 여러 가용 영역의 여러 인스턴스 간에 수신 트래픽 분산
# Amazon EC2의 규정 준수 확인
AWS 서비스가 특정 규정 준수 프로그램의 범위에 포함되는지 알아보려면 [규정 준수 프로그램 제공 범위 내 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하고 관심 있는 규정 준수 프로그램을 선택합니다. 일반적인 정보는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)을 참조하세요.
AWS Artifact를 사용하여 타사 감사 보고서를 다운로드할 수 있습니다. 자세한 내용은 [AWS Artifact에서 보고서 다운로드](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)를 참조하세요.
AWS 서비스 사용 시 규정 준수 책임은 데이터의 민감도, 회사의 규정 준수 목표 및 관련 법률 및 규정에 따라 결정됩니다. AWS 서비스 사용 시 규정 준수 책임에 대한 자세한 내용은 [AWS 보안 설명서](https://docs.aws.amazon.com/security/)를 참조하세요.
# Amazon EC2의 자격 증명 및 액세스 관리
AWS Identity and Access Management(IAM)는 관리자가 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있도록 지원하는 AWS 서비스입니다. IAM 관리자는 어떤 사용자가 Amazon EC2 리소스를 사용할 수 있도록 인증**(로그인)되고 권한이 부여**(권한 있음)될 수 있는지 제어합니다. IAM은 추가 비용 없이 사용할 수 있는 AWS 서비스입니다.
보안 자격 증명은 AWS의 서비스에서 사용자를 식별하고 Amazon EC2 리소스와 같은 AWS 리소스의 액세스를 허가합니다. Amazon EC2 및 IAM의 기능을 사용하면 보안 자격 증명을 공유하지 않고도 다른 사용자, 서비스 및 애플리케이션에 Amazon EC2 리소스 사용을 허가할 수 있습니다. IAM을 사용하여 다른 사용자가 AWS 계정의 리소스를 사용하는 방법을 제어하고 보안 그룹을 사용하여 Amazon EC2 인스턴스에 대한 액세스를 제어할 수 있습니다. Amazon EC2 리소스의 전체 또는 제한 사용을 허가할 수 있습니다.
개발자는 IAM 역할을 사용하여 EC2 인스턴스에서 실행하는 애플리케이션에 필요한 보안 자격 증명을 관리할 수 있습니다. 인스턴스에 IAM 역할을 연결하면 인스턴스에서 실행되는 애플리케이션이 인스턴스 메타데이터 서비스(IMDS)에서 자격 증명을 검색할 수 있습니다.
IAM을 사용하는 AWS 리소스를 보호하기 위한 모범 사례의 경우 **IAM 사용 설명서의 [IAM 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요.
**Topics**
+ [Amazon EC2의 ID 기반 정책](iam-policies-for-amazon-ec2.md)
+ [Amazon EC2 API에 대한 액세스를 제어하는 정책 예제](ExamplePolicies_EC2.md)
+ [Amazon EC2 콘솔에 대한 액세스를 제어하는 정책 예제](iam-policies-ec2-console.md)
+ [Amazon EC2에 대한 AWS 관리형 정책](security-iam-awsmanpol.md)
+ [Amazon EC2의 IAM 역할](iam-roles-for-amazon-ec2.md)
# Amazon EC2의 ID 기반 정책
기본적으로 사용자에게는 Amazon EC2 리소스를 생성 또는 수정하거나 Amazon EC2 API, Amazon EC2 콘솔 또는 CLI를 사용하여 태스크를 수행할 권한이 없습니다. 사용자에게 리소스 생성 또는 수정 및 태스크 수행을 허용하려면 사용자에게 필요한 특정 리소스 및 API 작업을 사용할 권한을 부여하는 IAM 정책을 생성하고, 해당 권한을 필요로 하는 사용자, 그룹 또는 IAM 역할에 정책을 연결해야 합니다.
사용자, 사용자 그룹 또는 역할에 정책을 연결하면 지정된 리소스에 대해 지정된 태스크를 수행할 권한이 허용되거나 거부됩니다. IAM 정책에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM의 정책 및 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)을 참조하세요. IAM 정책 관리 및 생성에 대한 자세한 내용은 [IAM 정책 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)를 참조하세요.
IAM 정책은 하나 이상의 Amazon EC2 작업을 사용할 권한을 허용하거나 거부해야 합니다. 또한 작업에 사용할 수 있는 리소스를 지정해야 합니다. 모든 리소스일 수도 있고, 경우에 따라서는 특정 리소스일 수도 있습니다. 또한 정책은 리소스에 적용할 조건을 포함할 수 있습니다.
시작을 위해 Amazon EC2의 AWS 관리형 정책이 요구 사항을 충족하는지 확인할 수 있습니다. 아니면 고유한 사용자 지정 정책을 생성할 수 있습니다. 자세한 내용은 [Amazon EC2에 대한 AWS 관리형 정책](security-iam-awsmanpol.md) 섹션을 참조하세요.
**Topics**
+ [정책 구문](#policy-syntax)
+ [Amazon EC2 작업](#UsingWithEC2_Actions)
+ [Amazon EC2 API 작업에 지원되는 리소스 수준 권한](#ec2-supported-iam-actions-resources)
+ [Amazon EC2의 Amazon 리소스 이름(ARN)](#EC2_ARN_Format)
+ [Amazon EC2에 사용되는 조건 키](#amazon-ec2-keys)
+ [속성 기반 액세스를 사용하여 액세스 제어](#control-access-with-tags)
+ [사용자, 그룹 및 역할에 권한 부여](#granting-iam-permissions)
+ [사용자에게 필요한 권한이 있는지 확인](#check-required-permissions)
## 정책 구문
IAM 정책은 하나 이상의 문으로 구성된 JSON 문서입니다. 각 명령문의 구조는 다음과 같습니다.
```
{
"Statement":[{
"Effect":"effect",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value"
}
}
}
]
}
```
명령문을 이루는 요소는 다양합니다.
+ **효과(Effect)**: *효과(effect)*는 `Allow` 또는 `Deny`일 수 있습니다. 기본적으로 사용자에게는 리소스 및 API 작업을 사용할 권한이 없으므로 모든 요청이 거부됩니다. 명시적 허용은 기본 설정을 무시합니다. 명시적 거부는 모든 허용을 무시합니다.
+ **Action**: *action*은 권한을 부여하거나 거부할 특정 API 작업입니다. *작업*을 지정하는 방법에 대한 자세한 내용은 [Amazon EC2 작업](#UsingWithEC2_Actions) 단원을 참조하십시오.
+ **리소스**: 작업의 영향을 받는 리소스입니다. 일부 Amazon EC2 API 작업의 경우 작업이 생성하거나 수정할 수 있는 리소스를 정책에 구체적으로 포함할 수 있습니다. Amazon 리소스 이름(ARN)을 사용하거나 명령문이 모든 리소스에 적용됨을 표시하는 와일드카드(\$1)를 사용하여 리소스를 지정합니다. 자세한 내용은 [Amazon EC2 API 작업에 지원되는 리소스 수준 권한](#ec2-supported-iam-actions-resources) 섹션을 참조하세요.
+ **Condition**: Condition은 선택 사항으로서 정책이 적용되는 시점을 제어하는 데 사용할 수 있습니다. Amazon EC2에 조건을 지정하는 방법에 대한 자세한 내용은 [Amazon EC2에 사용되는 조건 키](#amazon-ec2-keys) 섹션을 참조하세요.
정책에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)를 참조하세요. Amazon EC2용 IAM 정책 명령문 예제는 [Amazon EC2 API에 대한 액세스를 제어하는 정책 예제](ExamplePolicies_EC2.md) 섹션을 참조하세요.
## Amazon EC2 작업
IAM 정책 명령문에는 IAM을 지원하는 모든 서비스의 모든 API 작업을 지정할 수 있습니다. Amazon EC2의 경우 `ec2:` 접두사와 함께 API 작업 이름을 사용합니다. 예를 들면 `ec2:RunInstances` 및 `ec2:CreateImage` 등입니다.
명령문 하나에 여러 작업을 지정하려면 다음과 같이 쉼표로 구분합니다.
```
"Action": ["ec2:action1", "ec2:action2"]
```
와일드카드를 사용하여 여러 작업을 지정할 수도 있습니다. 예를 들어 다음과 같이 이름이 "Describe"로 시작되는 모든 작업을 지정할 수 있습니다.
```
"Action": "ec2:Describe*"
```
**참고**
현재 Amazon EC2 Describe\$1 API 작업은 리소스 수준 권한을 지원하지 않습니다. Amazon EC2용 리소스 수준 권한에 대한 자세한 내용은 [Amazon EC2의 ID 기반 정책](#iam-policies-for-amazon-ec2) 섹션을 참조하세요.
모든 Amazon EC2 API 작업을 지정하려면 다음과 같이 \$1 와일드카드를 사용합니다.
```
"Action": "ec2:*"
```
Amazon EC2 작업 목록을 보려면 *서비스 권한 부여 참조*에서 [Amazon EC2에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions)을 참조하세요.
## Amazon EC2 API 작업에 지원되는 리소스 수준 권한
*리소스 수준 권한*이란 사용자가 작업을 수행할 수 있는 리소스를 지정하는 기능을 말합니다. Amazon EC2는 리소스 수준 권한을 부분적으로 지원합니다. 즉, 필요 조건을 지정하거나 사용 가능한 특정 리소스를 지정하여 사용자가 특정 Amazon EC2 작업을 사용할 수 있는지 여부를 제어할 수 있습니다. 예를 들어 사용자에게 인스턴스 시작 권한을 부여하면서 특정 유형 또는 특정 AMI만 사용하도록 제한할 수 있습니다.
IAM 정책 설명에서 리소스를 지정하려면 Amazon 리소스 이름(ARN)을 사용합니다. ARN 값을 지정하는 방법에 대한 자세한 정보는 [Amazon EC2의 Amazon 리소스 이름(ARN)](#EC2_ARN_Format) 섹션을 참조하세요. API 작업이 개별 ARN을 지원하지 않는 경우 와일드카드(\$1)를 사용하여 모든 리소스가 작업의 영향을 받을 수 있도록 지정해야 합니다.
리소스 수준 권한을 지원하는 Amazon EC2 API 작업과, 정책에서 사용할 수 있는 ARN 및 조건 키를 식별하는 테이블을 보려면 [Amazon EC2에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)를 참조하세요.
Amazon EC2 API 작업에 사용하는 IAM 정책에는 태그 기반의 리소스 수준 권한을 적용할 수 있습니다. 이를 통해 사용자가 생성, 수정 또는 사용할 수 있는 리소스를 더욱 정확하게 제어할 수 있습니다. 자세한 내용은 [생성 시 Amazon EC2 리소스 태그 지정에 대한 권한 부여](supported-iam-actions-tagging.md) 섹션을 참조하세요.
## Amazon EC2의 Amazon 리소스 이름(ARN)
각 IAM 정책 명령문은 ARN을 사용하여 지정한 리소스에 적용됩니다.
ARN의 일반적인 구문은 다음과 같습니다.
```
arn:aws:[service]:[region]:[account-id]:resourceType/resourcePath
```
*서비스*
서비스(예: `ec2`)입니다.
*리전*
리소스의 리전(예: `us-east-1`)입니다.
*account-id*
AWS 계정 ID이며 하이픈은 제외합니다(예: `123456789012`).
*resourceType*
리소스의 유형(예: `instance`)입니다.
*resourcePath*
리소스를 식별하는 경로입니다. 경로에 \$1 와일드카드를 사용할 수 있습니다.
예를 들어 명령문에서 다음과 같이 ARN을 사용하여 특정 인스턴스(`i-1234567890abcdef0`)를 나타낼 수 있습니다.
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"
```
다음과 같이 \$1 와일드카드를 사용하여 특정 계정에 속하는 모든 인스턴스를 지정할 수도 있습니다.
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
```
다음과 같이 \$1 와일드카드를 사용하여 특정 계정에 속하는 모든 Amazon EC2 리소스를 지정할 수도 있습니다.
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:*"
```
모든 리소스를 지정해야 하거나 특정 API 작업이 ARN을 지원하지 않는 경우 다음과 같이 `Resource` 요소에 \$1 와일드카드를 사용합니다.
```
"Resource": "*"
```
다양한 Amazon EC2 API 작업에는 여러 리소스가 관여합니다. 예를 들어, `AttachVolume`은 Amazon EBS 볼륨을 인스턴스에 연결하므로 사용자에게 볼륨 사용 권한과 인스턴스 사용 권한이 있어야 합니다. 단일 명령문에서 여러 리소스를 지정하려면 다음과 같이 각 ARN을 쉼표로 구분합니다.
```
"Resource": ["arn1", "arn2"]
```
Amazon EC2 리소스에 대한 ARN 목록은 [Amazon EC2에서 정의한 리소스 유형](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-resources-for-iam-policies)을 참조하세요.
## Amazon EC2에 사용되는 조건 키
정책 명령문에서 정책이 적용되는 시점을 제어하는 조건을 지정할 수 있습니다. 각 조건에는 하나 이상의 키-값 쌍이 포함됩니다. 조건 키는 대/소문자를 구분하지 않습니다. AWS 전체 범위 조건 키 및 추가적인 서비스별 조건 키가 정의되어 있습니다.
Amazon EC2에 대한 서비스별 조건 키 목록은 [Amazon EC2의 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys)를 참조하세요. Amazon EC2는 AWS 전체 범위 조건 키도 구현합니다. 자세한 내용은 *IAM 사용 설명서*의 [모든 요청에서 사용 가능한 정보](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#policy-vars-infoallreqs)를 참조하세요.
모든 Amazon EC2 작업은 `aws:RequestedRegion` 및 `ec2:Region` 조건 키를 지원합니다. 자세한 내용은 [예: 특정 리전에 대한 액세스 제한](ExamplePolicies_EC2.md#iam-example-region) 섹션을 참조하세요.
IAM 정책에 조건 키를 사용하려면 `Condition` 명령문을 사용합니다. 예를 들어 다음 정책은 사용자에게 임의의 보안 그룹에 대한 인바운드 및 아웃바운드 규칙을 추가하고 제거하는 권한을 부여합니다. `ec2:Vpc` 조건 키를 사용하여 특정 VPC의 보안 그룹에서만 이러한 작업을 수행할 수 있도록 지정합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress"],
"Resource": "arn:aws:ec2:us-east-1:111122223333:security-group/*",
"Condition": {
"StringEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
}
}
}
]
}
```
------
여러 조건을 지정하거나 조건 하나에 여러 키를 지정하는 경우 논리적 AND 연산을 적용하여 평가합니다. 조건 하나에서 키 하나에 여러 값을 지정하면 논리적 OR 연산자를 적용하여 조건을 평가합니다. 모든 조건이 충족되어야 권한이 부여됩니다.
조건을 지정할 때 자리표시자를 사용할 수도 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM 정책 요소: 변수 및 태그](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) 섹션을 참조하세요.
**중요**
여러 조건 키들이 하나의 리소스에 딸려 있고, 일부 API 작업은 다수의 리소스를 사용합니다. 조건 키로 정책을 작성하는 경우에는 설명의 `Resource` 요소를 이용해 조건 키가 적용되는 리소스를 지정하십시오. 그렇게 하지 않으면, 조건 키가 해당되지 않는 리소스에 대해서는 조건 검사가 실패하여 정책이 사용자로 하여금 작업을 전혀 수행하지 못하게 막을 수도 있습니다. 리소스를 지정하고 싶지 않거나 다수의 API 작업을 포함하도록 정책의 `Action` 요소를 작성했다면, 반드시 `...IfExists` 조건 유형을 이용해 조건 키가 그것을 사용하지 않는 리소스에 대해서는 무시되도록 해야 합니다. 자세한 내용은 *IAM 사용 설명서*의 [...IfExists 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_IfExists) 단원을 참조하십시오.
**Topics**
+ [ec2:Attribute 조건 키](#attribute-key)
+ [ec2:ResourceID 조건 키](#imageId-key)
+ [ec2:SourceInstanceARN 조건 키](#SourceInstanceARN)
### ec2:Attribute 조건 키
`ec2:Attribute` 조건 키는 리소스의 속성으로 액세스를 필터링하는 조건에 사용할 수 있습니다.
이 조건 키는 문자열이나 정수와 같은 기본 데이터 유형의 속성 또는 **Value** 속성만 포함하는 복합 **[AttributeValue](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AttributeValue.html)** 객체(예: [ModifyImageAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) API 작업의 **Description** 또는 **ImdsSupport**객체)만 지원합니다. 조건 키는 [ModifyImageAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) API 작업의 **LaunchPermission** 객체와 같이 여러 속성을 가진 복합 객체에 사용할 수 없습니다.
예를 들어 다음 정책은 `ec2:Attribute/Description` 조건 키를 사용하여 **ModifyImageAttribute** API 작업의 복잡한 **Description** 객체에 의한 액세스를 필터링합니다. 조건 키는 이미지의 설명을 `Production` 또는 `Development`로 수정하는 요청만 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:ModifyImageAttribute",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:Attribute/Description": [
"Production",
"Development"
]
}
}
}
]
}
```
------
다음 예제 정책은 `ec2:Attribute` 조건 키를 사용하여 **ModifyImageAttribute** API 작업의 기본 **Attribute** 속성으로 액세스를 필터링합니다. 조건 키는 이미지 설명을 수정하려는 모든 요청을 거부합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:ModifyImageAttribute",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:Attribute": "Description"
}
}
}
]
}
```
------
### ec2:ResourceID 조건 키
지정된 API 작업과 함께 다음 `ec2:ResourceID` 조건 키를 사용하는 경우 조건 키 값은 API 작업에 의해 생성되는 결과 리소스를 지정하는 데 사용됩니다. `ec2:ResourceID` 조건 키는 API 요청에 지정된 소스 리소스를 지정하는 데 사용할 수 없습니다. 지정된 API와 함께 다음 `ec2:ResourceID` 조건 키 중 하나를 사용하는 경우 항상 와일드카드(`*`)를 지정해야 합니다. 다른 값을 지정하는 경우 조건은 런타임 중에 항상 `*`(으)로 해석됩니다. 예를 들어 **CopyImage** API와 함께 `ec2:ImageId` 조건 키를 사용하려면 다음과 같이 조건 키를 지정해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CopyImage",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:ImageID": "*"
}
}
}
]
}
```
------
다음 API 작업에는 이러한 조건 키를 사용하지 않는 것이 좋습니다.
+ `ec2:DhcpOptionsID` – `CreateDhcpOptions`
+ `ec2:ImageID` – `CopyImage`, `CreateImage`, `ImportImage`, `RegisterImage`
+ `ec2:InstanceID` – `RunInstances` 및 `ImportInstance`
+ `ec2:InternetGatewayID` – `CreateInternetGateway`
+ `ec2:NetworkAclID` – `CreateNetworkAcl`
+ `ec2:NetworkInterfaceID` – `CreateNetworkInterface`
+ `ec2:PlacementGroupName` – `CreatePlacementGroup`
+ `ec2:RouteTableID` – `CreateRouteTable`
+ `ec2:SecurityGroupID` – `CreateSecurityGroup`
+ `ec2:SnapshotID` – `CopySnapshot`, `CreateSnapshot`, `CreateSnapshots`, `ImportSnapshots`
+ `ec2:SubnetID` – `CreateSubnet`
+ `ec2:VolumeID` – `CreateVolume` 및 `ImportVolume`
+ `ec2:VpcID` – `CreateVpc`
+ `ec2:VpcPeeringConnectionID` – `CreateVpcPeeringConnection`
특정 리소스 ID를 기준으로 액세스를 필터링하려면 다음과 같이 `Resource` 정책 요소를 사용하는 것이 좋습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CopyImage",
"Resource": "arn:aws:ec2:us-east-1::image/ami-01234567890abcdef"
}
]
}
```
------
### ec2:SourceInstanceARN 조건 키
`ec2:SourceInstanceARN`을 사용하여 요청이 이루어진 인스턴스의 ARN을 지정합니다. 이는 [AWS 글로벌 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)이므로 Amazon EC2 이외의 서비스에서 사용할 수 있습니다. 정책 예제는 [예: 특정 인스턴스에서 다른 AWS 서비스의 리소스를 보는 것을 허용](ExamplePolicies_EC2.md#iam-example-source-instance) 섹션을 참조하세요.
## 속성 기반 액세스를 사용하여 액세스 제어
사용자에게 EC2 리소스 사용 권한을 부여하는 IAM 정책을 생성할 때 정책의 `Condition` 요소에 태그 정보를 포함시키면 태그를 기반으로 액세스를 제어할 수 있습니다. 이를 속성 기반 액세스 제어(ABAC)라고 합니다. ABAC를 통해 사용자는 수정, 사용 또는 삭제할 수 있는 리소스를 더욱 정확하게 제어할 수 있습니다. 자세한 내용은 [AWS용 ABAC란 무엇입니까?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 단원을 참조하세요.
예를 들어 사용자가 인스턴스를 종료할 수 있도록 허용하지만 인스턴스에 `environment=production` 태그가 있는 경우 작업을 거부하는 정책을 만들 수 있습니다. 이렇게 하려면 `aws:ResourceTag` 조건 키를 사용하여 리소스에 연결된 태그를 기반으로 리소스에 대한 액세스를 허용하거나 거부합니다.
```
"StringEquals": { "aws:ResourceTag/environment": "production" }
```
Amazon EC2 API 작업에서 `aws:ResourceTag` 조건 키를 사용한 액세스 제어를 지원하는지 알아보려면 [Amazon EC2에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)를 참조하세요. `Describe` 작업은 리소스 수준 권한을 지원하지 않기 때문에 조건 없이 별도의 명령문에 지정해야 합니다.
IAM 정책에 대한 예시는 [Amazon EC2 API에 대한 액세스를 제어하는 정책 예제](ExamplePolicies_EC2.md) 섹션을 참조하세요.
태그를 기준으로 리소스에 대한 사용자 액세스를 허용 또는 거부하는 경우 동일한 리소스에서 태그를 추가 또는 제거할 수 있도록 사용자를 명시적으로 거부할 것을 고려해야 합니다. 그렇지 않으면 사용자가 제한을 피해 태그를 수정하여 리소스에 대한 액세스 권한을 얻을 수 있습니다.
## 사용자, 그룹 및 역할에 권한 부여
액세스 권한을 제공하려면 사용자, 그룹 또는 역할에 권한을 추가하세요.
+ AWS IAM Identity Center의 사용자 및 그룹:
권한 세트를 생성합니다. *AWS IAM Identity Center 사용자 안내서*에서 [권한 세트 생성](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)의 지침을 따릅니다.
+ ID 제공업체를 통해 IAM에서 관리되는 사용자:
ID 페더레이션을 위한 역할을 생성합니다. *IAM 사용자 설명서*의 [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html)의 지침을 따릅니다.
+ IAM 사용자:
+ 사용자가 맡을 수 있는 역할을 생성합니다. *IAM 사용자 설명서*에서 [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html)의 지침을 따릅니다.
+ (권장되지 않음) 정책을 사용자에게 직접 연결하거나 사용자를 사용자 그룹에 추가합니다. *IAM 사용 설명서*에서 [사용자(콘솔)에 권한 추가](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)의 지침을 따릅니다.
## 사용자에게 필요한 권한이 있는지 확인
IAM 정책을 생성한 후에는 사용자에게 필요한 특정 API 작업 및 리소스를 사용할 권한이 제대로 부여되는지를 확인한 후에 정책을 실무에 적용하는 것이 좋습니다.
우선 테스트용으로 사용자를 생성하고 앞서 생성한 IAM 정책을 연결하여 사용자를 테스트합니다. 그런 다음 테스트 사용자 자격으로 요청을 수행합니다.
테스트 중인 Amazon EC2 작업에서 리소스를 생성하거나 수정하는 경우 `DryRun` 파라미터를 사용하여 요청을 제출하거나 AWS CLI 명령을 `--dry-run` 옵션과 함께 실행해야 합니다. 이렇게 하면 호출 시 권한 부여 확인은 완료되지만 작업은 완료되지 않습니다. 예를 들어 인스턴스를 실제로 종료하지 않고 사용자가 특정 인스턴스를 종료할 수 있는지 여부를 확인할 수 있습니다. 테스트 사용자에게 필요한 권한이 있는 경우 요청 시 `DryRunOperation`이 반환되고, 그렇지 않은 경우 `UnauthorizedOperation`이 반환됩니다.
정책이 사용자에게 정상적으로 권한을 부여하지 못하거나 권한을 과도하게 부여하는 경우, 원하는 결과가 나올 때까지 정책을 조정하고 다시 테스트할 수 있습니다.
**중요**
변경된 정책이 전파되어 효력을 발휘하려면 몇 분이 걸릴 수 있습니다. 따라서 정책을 업데이트한 경우 5분간 기다린 후에 테스트하는 것이 좋습니다.
요청 시 권한 부여 확인에 실패하면 진단 정보가 포함된 인코딩 메시지가 반환됩니다. `DecodeAuthorizationMessage` 작업을 사용하여 메시지를 디코딩할 수 있습니다. 자세한 내용은 *AWS Security Token Service API 참조*의 [DecodeAuthorizationMessage](https://docs.aws.amazon.com/STS/latest/APIReference/API_DecodeAuthorizationMessage.html)와 [decode-authorization-message](https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html)를 참조하세요.
# Amazon EC2 API에 대한 액세스를 제어하는 정책 예제
IAM 정책을 사용하여 Amazon EC2를 사용하는 데 필요한 권한을 사용자에게 부여할 수 있습니다. 단계별 지침은 **IAM 사용 설명서의 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요.
다음 예제는 사용자에게 Amazon EC2 사용 권한을 부여하는 데 사용할 수 있는 정책 명령문을 보여줍니다. 이러한 정책은 AWS CLI 또는 AWS SDK를 사용하는 요청에 맞게 설계되었습니다. 다음 예제에서는 자신의 정보로 각각의 *사용자 입력 자리 표시자*를 바꿉니다.
**Topics**
+ [읽기 전용 액세스](#iam-example-read-only)
+ [특정 리전에 대한 액세스를 제한합니다.](#iam-example-region)
+ [인스턴스 작업](#iam-example-instances)
+ [인스턴스 시작(RunInstances)](#iam-example-runinstances)
+ [스팟 인스턴스 작업](#iam-example-spot-instances)
+ [예약 인스턴스 작업](#iam-example-reservedinstances)
+ [리소스 태깅](#iam-example-taggingresources)
+ [IAM 역할 작업](#iam-example-iam-roles)
+ [라우팅 테이블 작업](#iam-example-route-tables)
+ [특정 인스턴스에서 다른 AWS 서비스의 리소스를 보는 것을 허용](#iam-example-source-instance)
+ [시작 템플릿 작업](#iam-example-launch-templates)
+ [인스턴스 메타데이터 작업](#iam-example-instance-metadata)
+ [Amazon EBS 볼륨 및 스냅샷 작업](#iam-example-ebs)
Amazon EC2 콘솔 작업과 관련된 예제 정책은 [Amazon EC2 콘솔에 대한 액세스를 제어하는 정책 예제](iam-policies-ec2-console.md) 섹션을 참조하세요.
## 예: 읽기 전용 액세스
다음 정책은 이름이 `Describe`로 시작되는 모든 Amazon EC2 API 작업을 사용할 권한을 부여합니다. `Resource` 요소에 와일드카드가 사용되었으므로 사용자가 이러한 API 작업에 모든 리소스를 지정할 수 있습니다. API 작업이 리소스 수준 권한을 지원하지 않는 경우에도 \$1 와일드카드가 필요합니다. Amazon EC2 API 작업에 사용할 수 있는 ARN에 대한 자세한 내용은 [Amazon EC2에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)를 참조하세요.
다른 명령문으로 해당 권한을 부여하지 않는 경우 리소스에 대해 작업을 수행할 권한은 부여되지 않습니다. 해당 API 작업을 사용할 권한은 기본적으로 거부됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
}
]
}
```
------
## 예: 특정 리전에 대한 액세스 제한
다음 정책은 유럽(프랑크푸르트) 리전이 아닌 경우 모든 Amazon EC2 API 작업을 사용할 수 있는 사용자 권한을 거부합니다. 모든 Amazon EC2 API 작업에서 지원하는 전역 조건 키 `aws:RequestedRegion`을 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "eu-central-1"
}
}
}
]
}
```
------
또는 Amazon EC2에 고유하고 모든 Amazon EC2 API 작업에서 지원하는 조건 키 `ec2:Region`을 사용할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"ec2:Region": "eu-central-1"
}
}
}
]
}
```
------
## 인스턴스 작업
**Topics**
+ [예제: 모든 인스턴스를 실행, 중지, 시작 및 종료](#iam-example-instances-all)
+ [예제: 모든 인스턴스를 설명할 수 있지만 특정 인스턴스만 중지, 시작 및 종료](#iam-example-instances-specific)
### 예제: 모든 인스턴스를 실행, 중지, 시작 및 종료
다음 정책은 사용자에게 `Action` 요소에 지정된 API 작업을 사용할 권한을 부여합니다. `Resource` 요소에 \$1 와일드카드가 사용되었으므로 사용자가 이러한 API 작업에 모든 리소스를 지정할 수 있습니다. API 작업이 리소스 수준 권한을 지원하지 않는 경우에도 \$1 와일드카드가 필요합니다. Amazon EC2 API 작업에 사용할 수 있는 ARN에 대한 자세한 내용은 [Amazon EC2에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)를 참조하세요.
다른 명령문으로 해당 권한을 부여하지 않는 경우 다른 API 작업을 사용할 권한은 부여되지 않습니다. 해당 API 작업을 사용할 권한은 기본적으로 거부됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeKeyPairs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeAvailabilityZones",
"ec2:RunInstances",
"ec2:TerminateInstances",
"ec2:StopInstances",
"ec2:StartInstances"
],
"Resource": "*"
}
]
}
```
------
### 예제: 모든 인스턴스를 설명할 수 있지만 특정 인스턴스만 중지, 시작 및 종료
다음 정책은 사용자가 모든 인스턴스를 설명하고, 인스턴스 i-1234567890abcdef0 및 i-0598c7d356eba48d7만 시작 및 중지하고, 리소스 태그가 "`purpose=test`"인 `us-east-1` 리전의 인스턴스만 종료하도록 허용합니다.
첫 번째 명령문의 `Resource` 요소에 \$1 와일드카드가 사용되었으므로 사용자가 작업에 모든 리소스를 지정할 수 있습니다. 여기에서는 모든 인스턴스를 나열할 수 있습니다. API 작업(여기에서는 `ec2:DescribeInstances`)이 리소스 수준 권한을 지원하지 않는 경우에도 \$1 와일드카드가 필요합니다. Amazon EC2 API 작업에 사용할 수 있는 ARN에 대한 자세한 내용은 [Amazon EC2에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)를 참조하세요.
두 번째 명령문의 `StopInstances` 및 `StartInstances` 작업에는 리소스 수준 권한이 사용되었습니다. `Resource` 요소의 ARN에 의해 특정 인스턴스가 지정되었습니다.
세 번째 문은 사용자가 지정된 AWS 계정에 속하며 `"purpose=test"` 태그가 있는 `us-east-1` 리전의 모든 인스턴스를 종료하도록 허용합니다. `Condition` 요소는 정책 명령문 적용 시에 평가됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:StopInstances",
"ec2:StartInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-1234567890abcdef0",
"arn:aws:ec2:us-east-1:111122223333:instance/i-0598c7d356eba48d7"
]
},
{
"Effect": "Allow",
"Action": "ec2:TerminateInstances",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/purpose": "test"
}
}
}
]
}
```
------
## 인스턴스 시작(RunInstances)
[RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) API 작업은 하나 이상의 온디맨드 인스턴스 또는 하나 이상의 스팟 인스턴스를 시작합니다. `RunInstances`는 AMI를 필요로 하며 인스턴스를 생성합니다. 사용자는 요청에 키 페어와 보안 그룹을 지정할 수 있습니다. VPC로 시작하는 경우 서브넷을 입력 받아 네트워크 인터페이스를 생성합니다. Amazon EBS 지원 AMI에서 시작하면 볼륨이 생성됩니다. 따라서 사용자가 이러한 Amazon EC2 리소스를 사용할 권한을 가지고 있어야 합니다. 사용자가 `RunInstances`에서 선택적 파라미터를 지정하도록 요구하거나 사용자가 파라미터에 특정 값을 사용하도록 제한하는 정책 명령문을 생성할 수 있습니다.
인스턴스를 시작하는 데 필요한 리소스 수준 권한에 대한 자세한 내용은 [Amazon EC2에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)를 참조하세요.
기본적으로는 사용자에게 생성된 인스턴스를 설명, 시작, 중지 또는 종료할 권한이 없습니다. 사용자에게 결과 인스턴스를 관리할 권한을 부여하는 방법 중 하나는 각 인스턴스에 대한 특정 태그를 생성하고 해당 태그를 갖는 인스턴스를 관리하도록 허용하는 명령문을 생성하는 것입니다. 자세한 내용은 [인스턴스 작업](#iam-example-instances) 섹션을 참조하세요.
**Topics**
+ [AMI](#iam-example-runinstances-ami)
+ [인스턴스 유형](#iam-example-runinstances-instance-type)
+ [서브넷](#iam-example-runinstances-subnet)
+ [EBS 볼륨](#iam-example-runinstances-volumes)
+ [Tags](#iam-example-runinstances-tags)
+ [시작 템플릿의 태그](#iam-example-tags-launch-template)
+ [탄력적 GPU](#iam-example-runinstances-egpu)
+ [시작 템플릿](#iam-example-runinstances-launch-templates)
### AMI
다음 정책은 사용자가 지정된 AMI(`ami-9e1670f7` 및 `ami-45cf5c3c`)만 사용하여 인스턴스를 시작하도록 허용합니다. 다른 명령문에서 해당 권한을 부여하지 않는 경우 다른 AMI를 사용하여 인스턴스를 시작할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-9e1670f7",
"arn:aws:ec2:us-east-1::image/ami-45cf5c3c",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*"
]
}
]
}
```
------
또는 다음 정책으로 사용자가 Amazon 소유의 모든 AMI 또는 신뢰할 수 있고 확인된 특정 파트너에서 인스턴스를 시작하도록 허용할 수 있습니다. 첫 번째 명령문의 `Condition` 요소는 `ec2:Owner`가 `amazon`인지 여부를 테스트합니다. 다른 명령문에서 해당 권한을 부여하지 않는 경우 다른 AMI를 사용하여 인스턴스를 시작할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
### 인스턴스 유형
다음 정책은 사용자가 `t2.micro` 및 `t2.small` 인스턴스 유형만 사용하여 인스턴스를 시작하도록 허용하므로 비용 통제에 도움이 됩니다. 첫 번째 명령문의 `Condition` 요소에서 `ec2:InstanceType`이 `t2.micro` 또는 `t2.small`인지 여부를 테스트하므로 더욱 큰 인스턴스는 시작할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:InstanceType": ["t2.micro", "t2.small"]
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
또는 `t2.micro` 및 `t2.small` 인스턴스 유형을 제외한 모든 인스턴스를 시작할 수 있는 사용자 권한을 거부하는 정책을 생성할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringNotEquals": {
"ec2:InstanceType": ["t2.micro", "t2.small"]
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
### 서브넷
다음 정책은 사용자가 지정된 서브넷(`subnet-12345678`)만 사용하여 인스턴스를 시작하도록 허용합니다. 다른 명령문에서 해당 권한을 부여하지 않는 경우 그룹에서 다른 서브넷으로 인스턴스를 시작할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:subnet/subnet-12345678",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
또는 다른 서브넷으로 인스턴스를 시작할 수 있는 사용자 권한을 거부하는 정책을 생성할 수 있습니다. 명령문에서 `subnet-12345678` 서브넷이 지정된 경우를 제외하고 네트워크 인터페이스를 생성할 권한을 거부하면 됩니다. 이러한 거부는 다른 서브넷으로 인스턴스를 시작하도록 허용할 목적으로 생성된 다른 정책을 모두 무시합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:network-interface/*"
],
"Condition": {
"ArnNotEquals": {
"ec2:Subnet": "arn:aws:ec2:us-east-1:111122223333:subnet/subnet-12345678"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
### EBS 볼륨
다음 정책은 인스턴스의 EBS 볼륨이 암호화된 경우에만 사용자가 인스턴스를 시작하는 것을 허용합니다. 사용자는 암호화된 스냅샷을 사용하여 생성된 AMI에서 인스턴스를 시작하여 루트 볼륨이 암호화되도록 해야 합니다. 시작 도중 사용자가 인스턴스에 연결하는 추가적 볼륨도 암호화되어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"Bool": {
"ec2:Encrypted": "true"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:security-group/*"
]
}
]
}
```
------
### Tags
**생성 시 인스턴스에 태그 지정**
다음 정책은 사용자가 인스턴스를 시작하고 생성 중에 인스턴스에 태그를 지정하는 것을 허용합니다. 태그를 적용하는 리소스 생성 작업의 경우, 사용자가 `CreateTags` 작업을 사용할 권한을 가지고 있어야 합니다. 두 번째 문은 `ec2:CreateAction` 조건 키를 사용하여 사용자가 `RunInstances`의 컨텍스트에 한해 인스턴스의 태그만을 생성하는 것을 허용합니다. 사용자는 기존의 리소스에 태그를 지정할 수 없으며, `RunInstances` 요청을 사용하여 볼륨에 태그를 지정할 수 없습니다.
자세한 내용은 [생성 시 Amazon EC2 리소스 태그 지정에 대한 권한 부여](supported-iam-actions-tagging.md) 섹션을 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
**생성 시 인스턴스 및 볼륨에 특정 태그를 사용하여 태그 지정**
다음 정책에는 태그 `aws:RequestTag` 및 `RunInstances`를 사용하여 `environment=production`에 의해 생성되는 인스턴스와 볼륨에 사용자가 태그를 지정해야 하는 `purpose=webserver` 조건 키가 포함됩니다. 사용자가 이 특정 키들을 전달하지 않거나 태그를 전혀 지정하지 않으면 요청은 실패합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production" ,
"aws:RequestTag/purpose": "webserver"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
**생성 시 인스턴스 및 볼륨에 하나 이상의 특정 태그를 사용하여 태그 지정**
다음 정책은 `ForAnyValue` 조건에서 `aws:TagKeys` 변경자를 사용하여 요청에서 적어도 하나의 태그가 지정되어야 하고 태그에 키 `environment` 또는 `webserver`가 포함되어야 함을 표시합니다. 태그는 인스턴스와 볼륨에 모두 적용되어야 합니다. 요청에서 어떤 태그 값도 지정할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": ["environment","webserver"]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
**인스턴스를 생성할 때 태그를 지정하는 경우 특정 태그를 사용해야 함**
다음 정책에서는 요청에서 태그를 지정할 필요가 없지만 지정하는 경우, 태그는 `purpose=test`여야 합니다. 다른 어떤 태그도 허용되지 않습니다. 사용자는 `RunInstances` 요청에서 태그 지정 가능한 어떤 리소스에도 태그를 적용할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/purpose": "test",
"ec2:CreateAction" : "RunInstances"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": "purpose"
}
}
}
]
}
```
------
RunInstances의 경우 생성 시 호출자가 태그를 지정할 수 없도록 하려면
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Effect": "Deny",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
spot-instances-request에 대해서만 특정 태그를 허용합니다. 여기서도 2번째 예외적인 비일관성이 적용됩니다. 일반적인 상황에서는 태그를 지정하지 않으면 인증되지 않습니다. spot-instances-request의 경우 spot-instances-request 태그가 없으면 이 정책이 평가되지 않으므로 태그가 지정되지 않은 Spot on Run 요청이 성공합니다.
### 시작 템플릿의 태그
아래 예제에서 사용자는 특정 시작 템플릿(`lt-09477bcd97b0d310e`)을 사용하는 경우에만 인스턴스를 시작할 수 있습니다. `ec2:IsLaunchTemplateResource` 조건 키는 사용자가 시작 템플릿에 지정된 모든 리소스를 재정의할 수 없도록 합니다. 이 명령문의 두 번째 부분은 사용자가 생성 시 인스턴스에 태그를 지정하도록 허용합니다. 이 부분은 시작 템플릿의 인스턴스에 대해 태그가 지정되어 있는 경우에 반드시 필요합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/lt-09477bcd97b0d310e"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
### 탄력적 GPU
다음 정책에서 사용자는 인스턴스를 시작하고 탄력적 GPU를 지정하여 인스턴스에 연결합니다. 사용자는 모든 리전에서 인스턴스를 시작할 수 있지만 `us-east-2` 리전에서 시작 작업 동안 탄력적 GPU만 연결할 수 있습니다.
`ec2:ElasticGpuType` 조건 키는 인스턴스가 `eg1.medium` 또는 `eg1.large` 탄력적 GPU 유형을 사용하는지 확인합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:111122223333:elastic-gpu/*"
],
"Condition": {
"StringEquals": {
"ec2:Region": "us-east-2",
"ec2:ElasticGpuType": [
"eg1.medium",
"eg1.large"
]
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:111122223333:network-interface/*",
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ec2:*:111122223333:subnet/*",
"arn:aws:ec2:*:111122223333:volume/*",
"arn:aws:ec2:*:111122223333:key-pair/*",
"arn:aws:ec2:*:111122223333:security-group/*"
]
}
]
}
```
------
### 시작 템플릿
아래 예제에서 사용자는 특정 시작 템플릿(`lt-09477bcd97b0d310e`)을 사용하는 경우에만 인스턴스를 시작할 수 있습니다. 사용자는 `RunInstances` 작업에서 파라미터를 지정하여 시작 템플릿의 모든 파라미터를 재정의할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/lt-09477bcd97b0d310e"
}
}
}
]
}
```
------
아래 예제에서 사용자는 시작 템플릿을 사용하는 경우에만 인스턴스를 시작할 수 있습니다. 정책은 `ec2:IsLaunchTemplateResource` 조건 키를 사용하여 사용자가 시작 템플릿의 기존 ARN을 재정의하지 못하도록 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
}
]
}
```
------
아래 예제는 사용자가 시작 템플릿을 사용하는 경우에만 인스턴스를 시작하도록 허용하는 정책입니다. 사용자는 요청 시 서브넷 및 네트워크 인터페이스 파라미터를 재정의할 수 없으며, 시작 템플릿에서만 이러한 파라미터들을 지정할 수 있습니다. 이 명령문의 첫 번째 부분은 [NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html) 요소를 사용하여 서브넷 및 네트워크 인터페이스를 제외한 다른 모든 리소스를 허용합니다. 이 명령문의 두 번째 부분은 시작 템플릿에서 나온 경우에만 서브넷 및 네트워크 인터페이스 리소스를 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"NotResource": ["arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*" ],
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": ["arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*" ],
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
}
]
}
```
------
아래 예제는 시작 템플릿을 사용하고 있고 시작 템플릿에 `Purpose=Webservers` 태그가 있는 경우에만 인스턴스를 시작할 수 있도록 허용합니다. 사용자는 `RunInstances` 작업의 어떤 시작 템플릿 파라미터도 재정의할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"NotResource": "arn:aws:ec2:us-east-1:111122223333:launch-template/*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:111122223333:launch-template/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Purpose": "Webservers"
}
}
}
]
}
```
------
## 스팟 인스턴스 작업
RunInstances 작업을 사용하여 스팟 인스턴스 요청을 생성하고 생성 시 스팟 인스턴스 요청을 태깅할 수 있습니다. RunInstances에 대해 지정할 리소스는 `spot-instances-request`입니다.
`spot-instances-request` 리소스는 다음과 같이 IAM 정책에서 평가됩니다.
+ 생성 시 스팟 인스턴스 요청을 태깅하지 않으면 Amazon EC2가 RunInstances 문에서 `spot-instances-request` 리소스를 평가하지 않습니다.
+ 생성 시 스팟 인스턴스 요청을 태깅하면 Amazon EC2가 RunInstances 문에서 `spot-instances-request` 리소스를 평가합니다.
따라서 `spot-instances-request` 리소스의 경우 IAM 정책에 다음 규칙이 적용됩니다.
+ RunInstances를 사용하여 스팟 인스턴스 요청을 생성하고 생성 시 스팟 인스턴스 요청을 태깅하지 않으려는 경우 `spot-instances-request` 리소스를 명시적으로 허용할 필요가 없습니다. 호출이 성공합니다.
+ RunInstances를 사용하여 스팟 인스턴스 요청을 생성하고 생성 시 스팟 인스턴스 요청을 태깅하려는 경우 RunInstances allow 문에 `spot-instances-request` 리소스를 포함해야 합니다. 그러지 않으면 호출이 실패합니다.
+ RunInstances를 사용하여 스팟 인스턴스 요청을 생성하고 생성 시 스팟 인스턴스 요청을 태깅하려는 경우 CreateTags allow 문에서 `spot-instances-request` 리소스 또는 `*` 와일드카드를 지정해야 합니다. 그러지 않으면 호출이 실패합니다.
RunInstances 또는 RequestSpotInstances를 사용하여 스팟 인스턴스를 요청할 수 있습니다. 다음 예제 IAM 정책은 RunInstances를 사용하여 스팟 인스턴스를 요청할 때만 적용됩니다.
**예: RunInstances를 사용한 스팟 인스턴스 요청**
다음 정책은 사용자가 RunInstances 작업을 사용하여 스팟 인스턴스를 요청할 수 있도록 허용합니다. RunInstances에서 생성되는 `spot-instances-request` 리소스는 스팟 인스턴스를 요청합니다.
**참고**
RunInstances를 사용하여 스팟 인스턴스 요청을 생성할 때 생성 시 스팟 인스턴스 요청을 태깅하지 않으려는 경우 `Resource` 목록에서 `spot-instances-request`를 생략할 수 있습니다. 생성 시 스팟 인스턴스 요청을 태깅하지 않으면 Amazon EC2가 RunInstances 문에서 `spot-instances-request` 리소스를 평가하지 않기 때문입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
}
]
}
```
------
**주의**
**지원되지 않음 – 예: 사용자에게 RunInstances를 사용하여 스팟 인스턴스를 요청할 수 있는 권한 거부**
`spot-instances-request` 리소스에는 다음 정책이 지원되지 않습니다.
다음 정책은 사용자에게 온디맨드 인스턴스를 시작할 수 있는 권한을 부여하지만 사용자에게 스팟 인스턴스를 요청할 수 있는 권한은 거부합니다. RunInstances에서 생성되는 `spot-instances-request` 리소스는 스팟 인스턴스를 요청하는 리소스입니다. 두 번째 문은 `spot-instances-request` 리소스에 대한 RunInstances 작업을 거부합니다. 그러나 생성 시 스팟 인스턴스 요청을 태깅하지 않으면 Amazon EC2가 RunInstances 문에서 `spot-instances-request` 리소스를 평가하지 않으므로 이 조건은 지원되지 않습니다.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*"
]
},
{
"Sid": "DenySpotInstancesRequestsNOTSUPPORTEDDONOTUSE",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:*:spot-instances-request/*"
}
]
}
```
**예: 생성 시 스팟 인스턴스 요청 태깅**
다음 정책은 사용자가 인스턴스 시작 중에 생성된 모든 리소스에 태그를 지정할 수 있도록 허용합니다. 첫 번째 문은 RunInstances에서 나열된 리소스를 생성할 수 있도록 허용합니다. RunInstances에서 생성되는 `spot-instances-request` 리소스는 스팟 인스턴스를 요청하는 리소스입니다. 두 번째 문은 `*` 와일드카드를 지정하여 인스턴스 시작 시 리소스가 생성될 때 모든 리소스에 태그를 지정하는 것을 허용합니다.
**참고**
생성 시 스팟 인스턴스 요청을 태깅하면 Amazon EC2가 RunInstances 문에서 `spot-instances-request` 리소스를 평가합니다. 따라서 RunInstances 작업의 경우 `spot-instances-request` 리소스를 명시적으로 허용해야 합니다. 그러지 않으면 호출이 실패합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Sid": "TagResources",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
**예: 스팟 인스턴스 요청에 대한 생성 시 태깅 거부**
다음 정책은 사용자에게 인스턴스 시작 중에 생성된 리소스에 태그를 지정할 수 있는 권한을 거부합니다.
첫 번째 문은 RunInstances에서 나열된 리소스를 생성할 수 있도록 허용합니다. RunInstances에서 생성되는 `spot-instances-request` 리소스는 스팟 인스턴스를 요청하는 리소스입니다. 두 번째 문은 `*` 와일드카드를 제공하여 인스턴스 시작 시 리소스가 생성될 때 모든 리소스에 태그를 지정하는 것을 거부합니다. 생성 시 `spot-instances-request` 또는 다른 리소스에 태그를 지정하면 RunInstances 호출이 실패합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Sid": "DenyTagResources",
"Effect": "Deny",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
**주의**
**지원되지 않음 - 예: 특정 태그가 할당된 경우에만 스팟 인스턴스 요청을 생성하는 것을 허용**
`spot-instances-request` 리소스에는 다음 정책이 지원되지 않습니다.
다음 정책은 요청이 특정 태그로 태깅된 경우에만 RunInstances에 스팟 인스턴스 요청을 생성할 수 있는 권한을 부여합니다.
첫 번째 문은 RunInstances에서 나열된 리소스를 생성할 수 있도록 허용합니다.
두 번째 문은 요청에 `environment=production` 태그가 있는 경우에만 사용자에게 스팟 인스턴스 요청을 생성할 수 있는 권한을 부여합니다. 이 조건이 RunInstances에서 생성된 다른 리소스에 적용되는 경우 태그를 지정하지 않으면 `Unauthenticated` 오류가 발생합니다. 그러나 스팟 인스턴스 요청에 태그가 지정되지 않은 경우 Amazon EC2는 RunInstances 문에서 `spot-instances-request` 리소스를 평가하지 않으므로 RunInstances에서 태깅되지 않은 스팟 인스턴스 요청이 생성됩니다.
사용자가 스팟 인스턴스 요청을 태깅하는 경우 Amazon EC2는 RunInstances 문에서 `spot-instances-request` 리소스를 평가하기 때문에 `environment=production` 이외의 다른 태그를 지정하면 `Unauthenticated` 오류가 발생합니다.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*"
]
},
{
"Sid": "RequestSpotInstancesOnlyIfTagIsEnvironmentProductionNOTSUPPORTEDDONOTUSE",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:*:spot-instances-request/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production"
}
}
},
{
"Sid": "TagResources",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
**예: 특정 태그가 할당된 경우 스팟 인스턴스 요청을 생성하는 것을 거부**
다음 정책은 요청이 `environment=production`으로 태깅된 경우 RunInstances에 스팟 인스턴스 요청을 생성할 수 있는 권한을 거부합니다.
첫 번째 문은 RunInstances에서 나열된 리소스를 생성할 수 있도록 허용합니다.
두 번째 문은 요청에 `environment=production` 태그가 있는 경우 사용자에게 스팟 인스턴스 요청을 생성할 수 있는 권한을 거부합니다. `environment=production`을 태그로 지정하면 `Unauthenticated` 오류가 발생합니다. 다른 태그를 지정하거나 태그를 지정하지 않으면 스팟 인스턴스 요청이 생성됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Sid": "DenySpotInstancesRequests",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:*:spot-instances-request/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production"
}
}
},
{
"Sid": "TagResources",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
## 예: 예약 인스턴스 작업
다음 정책에서는 계정에서 예약 인스턴스를 확인, 수정 및 구입할 수 있는 권한을 사용자에게 부여합니다.
개별 예약 인스턴스에 대해서는 리소스 수준 권한을 설정할 수 없습니다. 이 정책은 사용자들이 계정의 모든 예약 인스턴스에 액세스할 수 있음을 뜻합니다.
`Resource` 요소에서는 와일드카드(\$1)를 사용하여 사용자가 해당 작업에서 모든 리소스를 지정할 수 있음을 나타냅니다. 이 경우 사용자는 계정의 모든 예약 인스턴스를 나열하고 수정할 수 있습니다. 계정 자격 증명을 사용해 예약 인스턴스를 구매할 수도 있습니다. API 작업이 리소스 수준 권한을 지원하지 않는 경우에도 \$1 와일드카드가 필요합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeReservedInstances",
"ec2:ModifyReservedInstances",
"ec2:PurchaseReservedInstancesOffering",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeReservedInstancesOfferings"
],
"Resource": "*"
}
]
}
```
------
사용자에게 계정의 예약 인스턴스를 확인 및 수정하도록 허용하되 새 예약 인스턴스를 구매할 수는 없게 하려면
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeReservedInstances",
"ec2:ModifyReservedInstances",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
}
]
}
```
------
## 예: 태그 리소스
다음 정책은 태그에 키 `CreateTags` 및 값 `environment`이 포함된 경우에만 사용자가 `production` 작업을 사용하여 인스턴스에 태그를 적용하는 것을 허용합니다. 다른 어떤 태그도 사용할 수 없으며 사용자는 다른 어떤 리소스 유형에도 태그를 지정할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production"
}
}
}
]
}
```
------
다음 정책은 키가 `owner`이고 값이 username인 태그를 이미 가진 태그 지정 가능 리소스에 태그를 지정하는 것을 허용합니다. 또한 사용자는 요청에서 키가 `anycompany:environment-type`이고 값이 `test` 또는 `prod`인 태그를 지정해야 합니다. 사용자는 요청에서 추가 태그를 지정할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/anycompany:environment-type": ["test","prod"],
"aws:ResourceTag/owner": "${aws:username}"
}
}
}
]
}
```
------
사용자가 리소스의 특정 태그를 삭제하는 것을 허용하는 IAM 정책을 만들 수 있습니다. 예를 들어 요청에서 지정된 태그 키가 `environment` 또는 `cost-center`인 경우, 다음 정책은 사용자가 볼륨의 태그를 삭제하는 것을 허용합니다. 태그에는 어떤 값도 지정할 수 있지만 태그 키는 지정된 키 중 하나와 일치해야 합니다.
**참고**
리소스를 삭제하면 리소스에 지정되어 있는 모든 태그도 함께 삭제됩니다. 사용자는 `ec2:DeleteTags` 작업을 사용할 권한이 없어도 태그가 지정된 리소스를 삭제할 수 있습니다 . 삭제 작업을 수행할 권한만 있으면 됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:volume/*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment","cost-center"]
}
}
}
]
}
```
------
이 정책은 키가 `owner`이고 값이 username인 키로 리소스에 태그가 지정된 경우에 한해 어떤 리소스에서든 `environment=prod` 태그만 삭제하는 것을 허용합니다. 사용자는 리소스의 다른 어떤 태그도 삭제할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DeleteTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "prod",
"aws:ResourceTag/owner": "${aws:username}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment"]
}
}
}
]
}
```
------
## 예: IAM 역할 작업
다음 정책을 통해 사용자는 `department=test` 태그가 있는 인스턴스에 IAM 역할을 연결, 교체 및 분리할 수 있습니다. IAM 역할을 교체하거나 분리하려면 연결 ID가 필요하기 때문에 정책은 사용자에게 `ec2:DescribeIamInstanceProfileAssociations` 작업을 사용할 수 있는 권한도 부여합니다.
사용자가 인스턴스에 역할을 전달하기 위해서는 `iam:PassRole` 작업을 사용할 수 있는 권한이 있어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation",
"ec2:DisassociateIamInstanceProfile"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/department":"test"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:DescribeIamInstanceProfileAssociations",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/DevTeam*"
}
]
}
```
------
다음 정책을 통해 사용자는 모든 인스턴스에 IAM 역할을 연결하거나 교체할 수 있습니다. 사용자는 이름이 `TestRole-`로 시작하는 IAM 역할만 연결하거나 교체할 수 있습니다. `iam:PassRole` 작업의 경우, 인스턴스 프로파일이 아닌 IAM 역할의 이름을 지정하십시오(이름이 다른 경우). 자세한 내용은 [인스턴스 프로파일](iam-roles-for-amazon-ec2.md#ec2-instance-profile) 섹션을 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DescribeIamInstanceProfileAssociations",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/TestRole-*"
}
]
}
```
------
## 예: 라우팅 테이블 작업
다음 정책은 VPC `vpc-ec43eb89`에만 연결된 라우팅 테이블의 경로에 대해 사용자가 추가, 제거 및 바꾸기 작업을 수행할 수 있도록 허용합니다. `ec2:Vpc` 조건 키에 대한 VPC를 지정하려면 VPC의 전체 ARN을 지정해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DeleteRoute",
"ec2:CreateRoute",
"ec2:ReplaceRoute"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:route-table/*"
],
"Condition": {
"StringEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-ec43eb89"
}
}
}
]
}
```
------
## 예: 특정 인스턴스에서 다른 AWS 서비스의 리소스를 보는 것을 허용
다음은 IAM 역할에 연결할 수 있는 정책의 예제입니다. 이 정책은 인스턴스가 다양한 AWS 서비스에서 리소스를 확인하도록 허용합니다. `ec2:SourceInstanceARN` 글로벌 조건 키를 사용하여 요청이 이루어진 인스턴스가 `i-093452212644b0dd6` 인스턴스가 되도록 지정합니다. 동일한 IAM 역할이 다른 인스턴스와 연결된 경우에는 다른 인스턴스에서 이러한 작업을 수행할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVolumes",
"s3:ListAllMyBuckets",
"dynamodb:ListTables",
"rds:DescribeDBInstances"
],
"Resource": [
"*"
],
"Condition": {
"ArnEquals": {
"ec2:SourceInstanceARN": "arn:aws:ec2:us-east-1:111122223333:instance/i-093452212644b0dd6"
}
}
}
]
}
```
------
## 예: 시작 템플릿 작업
아래 정책은 특정 시작 템플릿(`lt-09477bcd97b0d3abc`)에서만 시작 템플릿 버전을 생성하고 시작 템플릿을 수정할 수 있도록 허용합니다. 사용자는 다른 시작 템플릿은 사용할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:CreateLaunchTemplateVersion",
"ec2:ModifyLaunchTemplate"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:us-east-1:111122223333:launch-template/lt-09477bcd97b0d3abc"
}
]
}
```
------
아래 정책은 시작 템플릿에 `Purpose`=`Testing` 태그가 지정되어 있는 경우에 모든 시작 템플릿 및 시작 템플릿 버전을 삭제할 수 있도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DeleteLaunchTemplate",
"ec2:DeleteLaunchTemplateVersions"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:us-east-1:111122223333:launch-template/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Purpose": "Testing"
}
}
}
]
}
```
------
## 인스턴스 메타데이터 작업
다음 정책은 사용자가 인스턴스 메타데이터 서비스 버전 2(IMDSv2)를 사용하여 [인스턴스 메타데이터](ec2-instance-metadata.md)만 검색할 수 있도록 합니다. 다음 정책 4개를 결합하여 명령문 4개를 가진 정책 하나로 만들 수 있습니다. 정책이 하나로 결합되면 이 정책을 서비스 제어 정책(SCP)으로 사용할 수 있습니다. 이 정책은 기존 IAM 정책에 적용한 *deny* 정책(기존 권한 취소 및 제한)이나 계정, 조직 단위(OU) 또는 전체 조직에서 전역적으로 적용되는 SCP와 똑같이 원활하게 적용됩니다.
**참고**
보안 주체에 RunInstances로 인스턴스를 시작할 수 있는 권한을 제공하는 정책과 함께 다음 RunInstances 메타데이터 옵션 정책을 사용해야 합니다. 또한 보안 주체에 RunInstances 권한이 없으면 인스턴스를 시작할 수 없습니다. 자세한 내용은 [인스턴스 작업](#iam-example-instances) 및 [인스턴스 시작(RunInstances)](#iam-example-runinstances)의 정책을 참조하세요.
**중요**
Auto Scaling 그룹을 사용할 때 모든 새 인스턴스에서 IMDSv2를 사용해야 하는 경우 Auto Scaling 그룹에서 *시작 템플릿*을 사용해야 합니다.
Auto Scaling 그룹이 시작 템플릿을 사용하는 경우 새 Auto Scaling 그룹이 생성될 때 IAM 보안 주체의 `ec2:RunInstances` 권한이 확인됩니다. 또한 새 시작 템플릿이나 새 버전의 시작 템플릿을 사용하도록 기존 Auto Scaling 그룹이 업데이트될 때도 확인됩니다.
`RunInstances`에 대한 IAM 보안 주체의 IMDSv1 사용에 대한 제한은 시작 템플릿을 사용하는 Auto Scaling 그룹이 생성 또는 업데이트될 때에만 확인됩니다. `Latest` 또는 `Default` 시작 템플릿을 사용하도록 구성된 Auto Scaling 그룹의 경우 새 버전의 시작 템플릿을 생성할 때 권한이 확인되지 않습니다. 권한을 확인하려면 *특정 버전*의 시작 템플릿을 사용하도록 Auto Scaling 그룹을 구성해야 합니다.
생성되는 새 보안 주체에 대해 IAM 권한 경계 또는 서비스 제어 정책(SCP)을 사용하여 조직의 모든 계정에 대해 시작 구성의 사용을 비활성화합니다. Auto Scaling 그룹 권한이 있는 기존 IAM 보안 주체의 경우 이 조건 키로 연결된 정책을 업데이트합니다. 시작 구성의 사용을 비활성화하려면 값이 `"autoscaling:LaunchConfigurationName"`로 지정된 `null` 조건 키를 사용하여 관련 SCP, 권한 경계 또는 IAM 정책을 생성하거나 수정합니다.
새 시작 템플릿의 경우 시작 템플릿에서 인스턴스 메타데이터 옵션을 구성합니다. 기존 시작 템플릿의 경우 새 버전의 시작 템플릿을 만들고 새 버전에서 인스턴스 메타데이터 옵션을 구성합니다.
보안 주체에게 시작 템플릿을 사용할 권한을 부여하는 정책에서 `$latest`를 지정하여 `$default` 및 `"autoscaling:LaunchTemplateVersionSpecified": "true"`의 연결을 제한합니다. 특정 버전의 시작 템플릿으로 사용을 제한하면 인스턴스 메타데이터 옵션이 구성된 버전을 사용하여 새 인스턴스가 시작되도록 할 수 있습니다. 자세한 내용은 *Amazon EC2 Auto Scaling API 참조*의 [LaunchTemplateSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_LaunchTemplateSpecification.html), 특히 `Version` 파라미터를 참조하십시오.
시작 구성을 사용하는 Auto Scaling 그룹의 경우 시작 구성을 시작 템플릿으로 바꿉니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용자 설명서*의 [Auto Scaling 그룹을 시작 템플릿으로 마이그레이션](https://docs.aws.amazon.com/autoscaling/ec2/userguide/migrate-to-launch-templates.html)을 참조하세요.
시작 템플릿을 사용하는 Auto Scaling 그룹의 경우 인스턴스 메타데이터 옵션이 구성된 새 시작 템플릿을 사용하거나 인스턴스 메타데이터 옵션이 구성된 현재 시작 템플릿의 새 버전을 사용해야 합니다. 자세한 내용은 [update-auto-scaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html)을 참조하세요.
**Topics**
+ [IMDSv2의 사용 요구](#iam-example-instance-metadata-requireIMDSv2)
+ [IMDSv2 옵트아웃 거부](#iam-example-instance-metadata-denyoptoutIMDSv2)
+ [최대 홉 제한 지정](#iam-example-instance-metadata-maxHopLimit)
+ [인스턴스 메타데이터 옵션을 수정할 수 있는 사용자 제한](#iam-example-instance-metadata-limit-modify-IMDS-options)
+ [IMDSv2에서 역할 자격 증명을 검색하도록 요구](#iam-example-instance-metadata-require-roles-to-use-IMDSv2-credentials)
### IMDSv2의 사용 요구
다음 정책에서는 IMDSv2(`"ec2:MetadataHttpTokens": "required"`로 표시) 사용을 요구하도록 인스턴스도 옵트인되지 않으면 RunInstances API를 호출할 수 없도록 지정합니다. 인스턴스가 IMDSv2를 요구하도록 지정하지 않으면 RunInstances API를 호출할 때 `UnauthorizedOperation` 오류가 발생합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireImdsV2",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:MetadataHttpTokens": "required"
}
}
}
]
}
```
------
### IMDSv2 옵트아웃 거부
다음 정책은 `ModifyInstanceMetadataOptions` API를 호출할 수 없으며 IMDSv1 또는 IMDSv2 옵션의 허용을 지정합니다. `ModifyInstanceMetadataOptions` API를 호출한다면 `HttpTokens` 속성은 `required`로 설정해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyIMDSv1HttpTokensModification",
"Effect": "Deny",
"Action": "ec2:ModifyInstanceMetadataOptions",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:Attribute/HttpTokens": "required"
},
"Null": {
"ec2:Attribute/HttpTokens": false
}
}
}]
}
```
------
### 최대 홉 제한 지정
다음 정책은 홉 제한도 지정하지 않으면(홉 제한은 3을 초과할 수 없음) RunInstances API를 호출할 수 없도록 지정합니다. 그렇게 하지 않으면 RunInstances API를 호출할 때 `UnauthorizedOperation` 오류가 발생합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MaxImdsHopLimit",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"NumericGreaterThan": {
"ec2:MetadataHttpPutResponseHopLimit": "3"
}
}
}
]
}
```
------
### 인스턴스 메타데이터 옵션을 수정할 수 있는 사용자 제한
다음 정책은 `ec2-imds-admins` 역할을 가진 사용자만 인스턴스 메타데이터 옵션을 변경할 수 있도록 허용합니다. `ec2-imds-admins` 역할이 아닌 보안 주체가 ModifyInstanceMetadataOptions API를 호출하려고 하면 `UnauthorizedOperation` 오류가 발생합니다. 이 명령문을 사용하여 ModifyInstanceMetadataOptions API 사용을 제어할 수 있습니다. 지금은 ModifyInstanceMetadataOptions API의 세부적인 액세스 제어(조건)가 없습니다.
### IMDSv2에서 역할 자격 증명을 검색하도록 요구
다음 정책은 이 정책이 역할에 적용되고, EC2 서비스가 이 역할을 맡으며, 그 결과로 생긴 자격 증명이 요청에 서명하는 데 사용되며, IMDSv2에서 검색한 EC2 역할 자격 증명으로 요청에 서명해야 한다고 지정합니다. 그렇게 하지 않으면 모든 API 호출에서 `UnauthorizedOperation` 오류가 발생합니다. 이 명령문/정책은 일반적으로 적용됩니다. EC2 역할 자격 증명으로 요청에 서명하지 않으면 요청은 아무 효과가 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireAllEc2RolesToUseV2",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NumericLessThan": {
"ec2:RoleDelivery": "2.0"
}
}
}
]
}
```
------
## Amazon EBS 볼륨 및 스냅샷 작업
Amazon EBS 볼륨 및 스냅샷 작업에 관한 정책 예는 [Identity-based policy examples for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security_iam_id-based-policy-examples.html)를 참조하세요.
# Amazon EC2 콘솔에 대한 액세스를 제어하는 정책 예제
IAM 정책을 사용하여 Amazon EC2를 사용하는 데 필요한 권한을 사용자에게 부여할 수 있습니다. 단계별 지침은 *IAM 사용 설명서*의 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요.
콘솔에서는 추가적인 API 작업을 통해 해당 기능을 구현하므로 이러한 정책이 예상과 다르게 작동할 수 있습니다. 예를 들어 `DescribeVolumes` API 작업만 사용할 권한을 갖는 경우 콘솔에서 볼륨을 조회하려고 하면 오류가 발생합니다. 이 섹션에서는 콘솔의 특정 부분을 사용하도록 허용하는 정책을 보여 줍니다. Amazon EC2 콘솔용 정책을 생성하는 방법에 대한 자세한 내용은 AWS 보안 블로그 게시물 [Granting Users Permission to Work in the Amazon EC2 Console](https://aws.amazon.com/blogs/security/granting-users-permission-to-work-in-the-amazon-ec2-console/)을 참조하세요.
다음 예제는 사용자에게 Amazon EC2 사용 권한을 부여하는 데 사용할 수 있는 정책 명령문을 보여줍니다. *user input placeholder*를 사용자의 정보로 바꿉니다. 이러한 정책은 AWS Management Console을 사용하는 요청에 맞게 설계되었습니다. Amazon EC2 콘솔은 단일 리소스를 표시하기 위해 여러 API 작업을 호출할 수 있으며, 사용자가 작업을 시도하고 콘솔에 오류가 표시되기 전까지는 명확하지 않을 수 있습니다. 자세한 내용은 AWS 보안 블로그 게시물 [Granting Users Permission to Work in the Amazon EC2 Console](https://aws.amazon.com/blogs/security/granting-users-permission-to-work-in-the-amazon-ec2-console/)을 참조하세요.
**Topics**
+ [읽기 전용 액세스](#ex-read-only)
+ [EC2 인스턴스 시작 마법사 사용](#ex-launch-wizard)
+ [보안 그룹 작업](#ex-security-groups)
+ [탄력적 IP 주소 작업](#ex-eip)
+ [예약 인스턴스 작업](#ex-reservedinstances)
콘솔에서 작업을 수행하는 데 필요한 API 작업을 파악하려는 경우 AWS CloudTrail 등 호출을 로깅하는 서비스를 사용할 수 있습니다. 정책에서 특정 리소스를 생성하거나 수정할 권한을 부여하지 않는 경우 콘솔에 진단 정보가 포함된 인코딩 메시지가 표시됩니다. AWS STS의 [DecodeAuthorizationMessage](https://docs.aws.amazon.com/STS/latest/APIReference/API_DecodeAuthorizationMessage.html) API 작업이나 AWS CLI의 [decode-authorization-message](https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html) 명령을 사용하여 메시지를 디코딩할 수 있습니다.
## 예: 읽기 전용 액세스
사용자가 Amazon EC2 콘솔에서 모든 리소스를 조회하도록 허용하려면 다음 예제와 같은 정책을 사용합니다. [예: 읽기 전용 액세스](ExamplePolicies_EC2.md#iam-example-read-only). 다른 명령문에서 해당 권한을 부여하지 않는 경우 이러한 리소스에 대해 작업을 수행하거나 새 리소스를 생성할 수는 없습니다.
**인스턴스, AMI 및 스냅샷 조회**
리소스 중 일부에 대한 읽기 전용 액세스를 제공할 수도 있습니다. 이렇게 하려면 `ec2:Describe` API 작업에서 \$1 와일드카드를 구체적인 리소스별 `ec2:Describe` 작업으로 대체합니다. 다음 정책은 사용자가 Amazon EC2 콘솔에서 모든 인스턴스, AMI 및 스냅샷을 조회하도록 허용합니다. `ec2:DescribeTags` 작업에서는 사용자가 퍼블릭 AMI를 조회할 수 있습니다. 콘솔에 퍼블릭 AMI를 표시하려면 태그 지정 정보가 필요하지만 사용자가 프라이빗 AMI만 조회하도록 하려면 이 작업을 제거할 수도 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeTags",
"ec2:DescribeSnapshots"
],
"Resource": "*"
}
]
}
```
------
**참고**
Amazon EC2 `ec2:Describe*` API 작업은 리소스별 권한을 지원하지 않으므로 사용자가 콘솔에서 조회할 수 있는 리소스를 개별적으로 제어할 수는 없습니다. 따라서 위 명령문의 `Resource` 요소에 \$1 와일드카드가 필요합니다. Amazon EC2 API 작업에 사용할 수 있는 ARN에 대한 자세한 내용은 [Amazon EC2에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)를 참조하세요.
**인스턴스 및 CloudWatch 측정치 조회**
다음 정책은 사용자로 하여금 **인스턴스** 페이지의 **모니터링** 탭에 있는 CloudWatch 경보 및 지표뿐만 아니라 Amazon EC2 콘솔의 인스턴스까지도 조회할 수 있도록 허용합니다. Amazon EC2 콘솔에서는 CloudWatch API를 사용하여 경보와 지표를 표시하므로 사용자에게 `cloudwatch:DescribeAlarms`, `cloudwatch:DescribeAlarmsForMetric`, `cloudwatch:ListMetrics`, `cloudwatch:GetMetricStatistics` 및 `cloudwatch:GetMetricData` 작업을 사용하는 권한을 부여해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricStatistics",
"cloudwatch:GetMetricData"
],
"Resource": "*"
}
]
}
```
------
## 예: EC2 인스턴스 시작 마법사 사용
Amazon EC2 인스턴스 시작 마법사는 인스턴스를 구성하고 시작하는 옵션이 있는 화면입니다. 사용자가 마법사의 옵션을 사용할 수 있도록 정책에 API 작업 사용 권한이 포함되어야 합니다. 해당 작업 사용 권한이 정책에 포함되지 않으면 마법사의 일부 항목이 제대로 로드되지 않고 사용자가 시작을 완료할 수 없습니다.
**기본 인스턴스 시작 마법사 액세스**
성공적으로 시작을 완료하려면 사용자에게 `ec2:RunInstances` API 작업 및 최소한 다음과 같은 API 작업 사용 권한을 부여해야 합니다.
+ `ec2:DescribeImages`: AMI를 조회하고 선택합니다.
+ `ec2:DescribeInstanceTypes`: 인스턴스 유형을 조회하고 선택합니다.
+ `ec2:DescribeVpcs`: 사용 가능한 네트워크 옵션을 조회합니다.
+ `ec2:DescribeSubnets`: 선택한 VPC에 대한 모든 사용 가능한 서브넷을 조회합니다.
+ `ec2:DescribeSecurityGroups` 또는 `ec2:CreateSecurityGroup`: 기존 보안 그룹을 조회하고 선택하거나 새로 생성합니다.
+ `ec2:DescribeKeyPairs` 또는 `ec2:CreateKeyPair`: 기존 키 페어를 선택하거나 새로 생성합니다.
+ `ec2:AuthorizeSecurityGroupIngress`: 인바운드 규칙을 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeInstanceTypes",
"ec2:DescribeKeyPairs",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:CreateSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateKeyPair"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*"
}
]
}
```
------
정책에 API 작업을 추가하여 다음과 같이 사용자에게 더 많은 옵션을 제공할 수 있습니다.
+ `ec2:DescribeAvailabilityZones`: 특정 가용 영역을 조회하고 선택합니다.
+ `ec2:DescribeNetworkInterfaces`: 선택한 서브넷의 기존 네트워크 인터페이스를 조회하고 선택합니다.
+ VPC 보안 그룹에 아웃바운드 규칙을 추가하려면 `ec2:AuthorizeSecurityGroupEgress` API 작업 사용 권한이 부여되어야 합니다. 기존 규칙을 수정 또는 삭제하려면 관련 `ec2:RevokeSecurityGroup*` API 작업 사용 권한이 부여되어야 합니다.
+ `ec2:CreateTags`: 에 의해 생성된 리소스에 태그 지정.`RunInstances` 자세한 내용은 [생성 시 Amazon EC2 리소스 태그 지정에 대한 권한 부여](supported-iam-actions-tagging.md) 섹션을 참조하세요. 이 작업을 사용할 권한이 없는 사용자가 인스턴스 시작 마법사의 태그 지정 페이지에서 태그를 지정하려 시도하는 경우, 시작은 실패합니다.
**중요**
인스턴스를 시작하는 동안 **Name**(이름)을 지정하면 태그가 생성되고 `ec2:CreateTags` 작업이 필요합니다. 사용자에게 `ec2:CreateTags` 작업을 사용할 수 있는 권한을 부여하면 `aws:ResourceTag` 조건 키를 사용하여 다른 리소스의 사용을 제한하지 못할 수 있으므로 주의해야 합니다. 사용자가 `ec2:CreateTags` 작업을 사용할 수 있는 권한을 부여받으면 리소스의 태그를 변경하여 제한을 우회할 수 있습니다. 자세한 내용은 [속성 기반 액세스를 사용하여 액세스 제어](iam-policies-for-amazon-ec2.md#control-access-with-tags) 섹션을 참조하세요.
+ AMI을 선택하는 데 Systems Manager 파라미터를 사용하려면 정책에 `ssm:DescribeParameters` 및 `ssm:GetParameters`를 추가해야 합니다. `ssm:DescribeParameters`는 사용자에게 Systems Manager 파라미터를 보고 선택할 수 있는 권한을 부여하며, `ssm:GetParameters`는 사용자에게 Systems Manager 파라미터의 값을 가져올 수 있는 권한을 부여합니다. 특정 Systems Manager 파라미터에 대한 액세스를 제한할 수도 있습니다. 자세한 내용은 이 섹션의 뒷부분에 있는 **특정 Systems Manager 파라미터에 대한 액세스 제한**을 참조하세요.
현재 Amazon EC2 `Describe*` API 작업은 리소스별 권한을 지원하지 않으므로 사용자가 인스턴스 시작 마법사에서 조회할 수 있는 리소스를 개별적으로 제한할 수는 없습니다. 그러나 `ec2:RunInstances` API 작업에 리소스별 권한을 적용하여 사용자가 인스턴스를 시작하는 데 사용 가능한 리소스를 제한할 수 있습니다. 사용자가 사용 권한이 없는 옵션을 선택하면 시작에 실패합니다.
**특정 인스턴스 유형, 서브넷 및 리전에 대한 액세스 제한**
다음 정책은 Amazon이 소유한 AMI를 사용하여 `t2.micro` 인스턴스를 시작하되 특정 서브넷(`subnet-1a2b3c4d`)으로만 시작하도록 허용합니다. 사용자는 지정된 리전에서만 시작할 수 있습니다. 사용자가 다른 리전을 선택하거나 인스턴스 시작 마법사에서 다른 인스턴스 유형, AMI 또는 서브넷을 선택하면 시작에 실패합니다.
첫 번째 문은 위 예제에 설명된 대로 사용자가 인스턴스 시작 마법사에서 옵션을 조회할 권한을 부여합니다. 두 번째 명령문은 `ec2:RunInstances` 작업에서 네트워크 인터페이스, 볼륨, 키 페어, 보안 그룹 및 서브넷 리소스를 사용할 권한을 부여합니다. 이 권한은 인스턴스를 VPC로 시작하는 데 필요합니다. `ec2:RunInstances` 작업 사용에 대한 자세한 내용은 [인스턴스 시작(RunInstances)](ExamplePolicies_EC2.md#iam-example-runinstances) 섹션을 참조하세요. 세 번째, 네 번째 명령문은 각각 인스턴스 및 AMI 리소스 사용 권한을 부여하지만 인스턴스가 `t2.micro` 인스턴스이고 AMI가 Amazon 또는 신뢰할 수 있고 검증된 특정 파트너의 소유인 경우로 한정합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeInstanceTypes",
"ec2:DescribeKeyPairs",
"ec2:CreateKeyPair",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets", "ec2:DescribeSecurityGroups",
"ec2:CreateSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action":"ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:network-interface/*",
"arn:aws:ec2:us-east-2:111122223333:volume/*",
"arn:aws:ec2:us-east-2:111122223333:key-pair/*",
"arn:aws:ec2:us-east-2:111122223333:security-group/*",
"arn:aws:ec2:us-east-2:111122223333:subnet/subnet-1a2b3c4d"
]
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:InstanceType": "t2.micro"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-2::image/ami-*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
}
]
}
```
------
**특정 Systems Manager 파라미터에 대한 액세스 제한**
다음 정책은 특정 이름의 Systems Manager 파라미터를 사용할 수 있는 액세스 권한을 부여합니다.
첫 번째 문은 인스턴스 시작 마법사에서 AMI를 선택할 때 Systems Manager 파라미터를 볼 수 있는 권한을 사용자에게 부여합니다. 두 번째 문은 사용자에게 `prod-*`라는 이름이 지정된 파라미터만 사용할 수 있는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters"
],
"Resource": "arn:aws:ssm:us-east-2:123456123456:parameter/prod-*"
}
]
}
```
------
## 예: 보안 그룹 작업
**보안 그룹 조회와 규칙의 추가 및 삭제**
다음 정책은 사용자가 Amazon EC2 콘솔에서 보안 그룹을 조회하고 인바운드 및 아웃바운드 규칙을 추가 및 제거하며 `Department=Test` 태그가 있는 기존 보안 그룹에 대한 규칙 설명을 나열하고 수정할 권한을 부여합니다.
첫 번째 명령문에서 `ec2:DescribeTags` 작업은 사용자가 콘솔에서 태그를 조회하도록 허용하므로 사용자가 수정 가능한 보안 그룹을 쉽게 식별할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:ModifySecurityGroupRules",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress"
],
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Department": "Test"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifySecurityGroupRules"
],
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:security-group-rule/*"
]
}
]}
```
------
**보안 그룹 생성 대화 상자 작업**
사용자가 Amazon EC2 콘솔에서 **보안 그룹 생성** 대화 상자를 사용하도록 허용하는 정책을 생성할 수 있습니다. 이 대화 상자를 사용하려면 최소한 다음과 같은 API 작업 사용 권한을 부여해야 합니다.
+ `ec2:CreateSecurityGroup`: 새 보안 그룹을 생성합니다.
+ `ec2:DescribeVpcs`: **VPC** 목록에서 기존 VPC의 목록을 조회합니다.
이 권한이 있으면 사용자가 새 보안 그룹을 생성할 수 있지만 규칙을 추가할 수는 없습니다. **보안 그룹 생성** 대화 상자에서 규칙 관련 작업을 수행하려면 정책에 다음 API 작업을 추가합니다.
+ `ec2:AuthorizeSecurityGroupIngress`: 인바운드 규칙을 추가합니다.
+ `ec2:AuthorizeSecurityGroupEgress`: VPC 보안 그룹에 아웃바운드 규칙을 추가합니다.
+ `ec2:RevokeSecurityGroupIngress`: 기존 인바운드 규칙을 수정하거나 삭제합니다. 이 권한은 사용자가 콘솔에서 **새로 복사** 기능을 사용하도록 허용하려는 경우에 유용합니다. 이 기능은 **보안 그룹 생성** 대화 상자를 열고 선택한 보안 그룹과 같은 규칙을 미리 입력합니다.
+ `ec2:RevokeSecurityGroupEgress`: VPC 보안 그룹의 아웃바운드 규칙을 수정하거나 삭제합니다. 이 권한은 모든 아웃바운드 트래픽을 허용하는 기본 아웃바운드 규칙을 사용자가 수정 또는 삭제하도록 허용하는 데 유용합니다.
+ `ec2:DeleteSecurityGroup`: 잘못된 규칙을 저장할 수 없도록 합니다. 콘솔에서 먼저 보안 그룹을 만든 후 지정된 규칙을 추가합니다. 규칙이 잘못된 경우 작업이 실패하고 콘솔이 보안 그룹을 삭제하려고 합니다. 사용자는 **보안 그룹 생성** 대화 상자에 남아 있기 때문에 잘못된 규칙을 수정한 후 보안 그룹을 다시 생성해 볼 수 있습니다. 이 API 작업은 필수적이지는 않지만 해당 사용 권한을 부여하지 않으면 사용자가 잘못된 규칙이 포함된 보안 그룹을 생성하려고 할 때 규칙이 없는 보안 그룹이 생성되며, 사용자가 이후에 규칙을 추가해야 합니다.
+ `ec2:UpdateSecurityGroupRuleDescriptionsIngress`: 수신(인바운드) 보안 그룹 규칙에 대한 설명을 추가하거나 업데이트합니다.
+ `ec2:UpdateSecurityGroupRuleDescriptionsEgress`: 발신(아웃바운드) 보안 그룹 규칙에 대한 설명을 추가하거나 업데이트합니다.
+ `ec2:ModifySecurityGroupRules`: 보안 그룹 규칙을 수정하려면
+ `ec2:DescribeSecurityGroupRules`: 보안 그룹 규칙을 나열하려면
다음 정책은 **보안 그룹 생성** 대화 상자를 사용하고 특정 VPC(`vpc-1a2b3c4d`)에 연결된 보안 그룹에 인바운드 및 아웃바운드 규칙을 생성할 권한을 부여합니다. 사용자는 VPC의 보안 그룹을 생성할 수 있지만 규칙을 추가할 수는 없습니다. 마찬가지로 VPC `vpc-1a2b3c4d`에 연결되지 않은 기존 보안 그룹에는 규칙을 추가할 수는 없습니다. 또한 콘솔에서 모든 보안 그룹을 조회할 권한이 부여됩니다. 따라서 사용자가 인바운드 규칙을 추가할 수 있는 보안 그룹을 쉽게 식별할 수 있습니다. 또한 이 정책은 VPC `vpc-1a2b3c4d`에 연결된 보안 그룹을 삭제할 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:CreateSecurityGroup",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress"
],
"Resource": "arn:aws:ec2:us-east-2:111122223333:security-group/*",
"Condition":{
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-2:111122223333:vpc/vpc-1a2b3c4d"
}
}
}
]
}
```
------
## 예: 탄력적 IP 주소 작업
사용자가 Amazon EC2 콘솔에서 탄력적 IP 주소를 볼 수 있도록 하려면 사용자에게 `ec2:DescribeAddresses` 작업을 사용할 수 있는 권한을 부여해야 합니다.
사용자에게 탄력적 IP 주소 관련 작업을 허용하려면 정책에 다음 작업을 추가합니다.
+ `ec2:AllocateAddress`: 탄력적 IP 주소를 할당합니다.
+ `ec2:ReleaseAddress`: 탄력적 IP 주소를 해제합니다.
+ `ec2:AssociateAddress`: 인스턴스 또는 네트워크 인터페이스에 탄력적 IP 주소를 연결합니다.
+ `ec2:DescribeNetworkInterfaces` 및 `ec2:DescribeInstances`: **주소 연결** 화면에서 작업합니다. 탄력적 IP 주소를 연결할 수 있는 네트워크 인터페이스나 가용 인스턴스가 화면에 표시됩니다.
+ `ec2:DisassociateAddress`: 인스턴스 또는 네트워크 인터페이스에서 탄력적 IP 주소를 분리합니다.
다음 정책을 통해 사용자는 탄력적 IP 주소를 확인하고 인스턴스에 할당, 연결할 수 있습니다. 사용자는 탄력적 IP 주소를 네트워크 인터페이스에 연결하거나 탄력적 IP 주소 연결을 끊거나 릴리스할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAddresses",
"ec2:AllocateAddress",
"ec2:DescribeInstances",
"ec2:AssociateAddress"
],
"Resource": "*"
}
]
}
```
------
## 예: 예약 인스턴스 작업
다음 정책은 사용자가 계정의 예약 인스턴스를 보고 수정할 수 있을 뿐만 아니라 AWS Management Console에서 새 예약 인스턴스를 구매할 수 있도록 허용합니다.
이 정책을 통해 사용자는 계정의 모든 예약 인스턴스 및 온디맨드 인스턴스를 볼 수 있습니다. 개별 예약 인스턴스에 대해서는 리소스 수준 권한을 설정할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeReservedInstances",
"ec2:ModifyReservedInstances",
"ec2:PurchaseReservedInstancesOffering",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeReservedInstancesOfferings"
],
"Resource": "*"
}
]
}
```
------
`ec2:DescribeAvailabilityZones` 작업은 Amazon EC2 콘솔이 예약 인스턴스를 구매할 수 있는 가용 영역에 대한 정보를 표시하도록 하는 데 필수적입니다. `ec2:DescribeInstances` 작업은 필수적이지는 않지만 사용자가 계정에서 인스턴스를 보고, 정확한 사양에 맞추기 위해 예약을 구매할 수 있도록 해줍니다.
API 작업을 조정해 사용자 액세스를 제한할 수 있습니다. 예를 들어 `ec2:DescribeInstances`와 `ec2:DescribeAvailabilityZones`를 제거하면 사용자가 읽기 전용 액세스 권한만을 갖게 됩니다.
# Amazon EC2에 대한 AWS 관리형 정책
사용자, 그룹 또는 역할에 권한을 추가할 때 정책을 직접 작성하는 것보다 AWS 관리형 정책을 사용하는 것이 더욱 편리합니다. 팀에 필요한 권한만 제공하는 [IAM 고객 관리형 정책을 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)하려면 시간과 전문 지식이 필요합니다. 빨리 시작하려면 AWS 관리형 정책을 사용할 수 있습니다. 이러한 정책은 일반적인 사용 사례에 적용되며 AWS계정에서 사용할 수 있습니다. AWS 관리형 정책에 대한 자세한 정보는 IAM 사용 설명서에서 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)을 참조하세요.**
AWS 서비스 유지 관리 및 AWS 관리형 정책 업데이트입니다. AWS 관리형 정책에서는 권한을 변경할 수 없습니다. 서비스에서 때때로 추가 권한을 AWS 관리형 정책에 추가하여 새로운 기능을 지원합니다. 이 유형의 업데이트는 정책이 연결된 모든 ID(사용자, 그룹 및 역할)에 적용됩니다. 서비스는 새로운 기능이 시작되거나 새 태스크를 사용할 수 있을 때 AWS 관리형 정책에 업데이트됩니다. 서비스는 AWS관리형 정책에서 권한을 제거하지 않기 때문에 정책 업데이트로 인해 기존 권한이 손상되지 않습니다.
또한 AWS는 여러 서비스의 직무에 대한 관리형 정책을 지원합니다. 예를 들어 **ReadOnlyAccess**라는 이름의 AWS 관리형 정책은 모든 AWS 서비스 및 리소스에 대한 읽기 전용 액세스 권한을 제공합니다. 서비스에서 새 기능을 시작하면 AWS가 새 작업 및 리소스에 대한 읽기 전용 권한을 추가합니다. 직무 정책의 목록과 설명은 *IAM 사용 설명서*의 [직무에 관한 AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)을 참조하세요.
## AWS 관리형 정책: AmazonEC2FullAccess
`AmazonEC2FullAccess` 정책을 IAM 자격 증명에 연결할 수 있습니다. 이 정책은 Amazon EC2에 대한 전체 액세스를 허용하는 권한을 부여합니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2FullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2FullAccess.html)를 참조하세요.
## AWS 관리형 정책: AmazonEC2ReadOnlyAccess
`AmazonEC2ReadOnlyAccess` 정책을 IAM 자격 증명에 연결할 수 있습니다. 이 정책은 Amazon EC2 대한 읽기 전용 액세스를 허용하는 권한을 부여합니다.
이 정책의 권한을 보려면 AWS 관리형 정책 참조의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html)를 참조하세요.**
## AWS 관리형 정책: AmazonEC2ImageReferencesAccessPolicy
`AmazonEC2ImageReferencesAccessPolicy` 정책을 IAM ID에 연결할 수 있습니다. 이 정책은 EC2 인스턴스, 시작 템플릿, Systems Manager 파라미터 및 Image Builder 레시피를 볼 수 있는 권한을 포함하여 EC2 DescribeImageReferences API를 사용하는 데 필요한 권한을 부여합니다. 이 정책은 `IncludeAllResourceTypes` 플래그를 지원하며 AWS가 새 리소스 유형에 대한 지원을 추가하면 계속 작동하므로 향후 정책 업데이트가 필요하지 않습니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ImageReferencesAccessPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ImageReferencesAccessPolicy.html)를 참조하세요.
## AWS 관리형 정책: AWSEC2CapacityReservationFleetRolePolicy
이 정책은 **AWSServiceRoleForEC2CapacityReservationFleet**이라는 서비스 연결 역할에 연결되어 사용자를 대신해 서비스가 용량 예약 플릿에서 용량 예약을 생성, 수정 및 취소할 수 있도록 합니다. 자세한 내용은 [용량 예약 플릿에 서비스 연결 역할 사용EC2 용량 관리자의 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요.
이 정책의 권한을 보려면 AWS 관리형 정책 참조의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityReservationFleetRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityReservationFleetRolePolicy.html)를 참조하세요.**
## AWS 관리형 정책: AWSEC2FleetServiceRolePolicy
이 정책은 **AWSServiceRoleForEC2Fleet**이라는 서비스 연결 역할에 연결되어 EC2 Fleet이 사용자를 대신하여 인스턴스를 요청, 시작, 종료 및 태깅할 수 있도록 합니다. 자세한 내용은 [EC2 Fleet의 서비스 연결 역할](ec2-fleet-prerequisites.md#ec2-fleet-service-linked-role) 섹션을 참조하세요.
이 정책의 권한을 보려면 AWS 관리형 정책 참조의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2FleetServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2FleetServiceRolePolicy.html)를 참조하세요.**
## AWS 관리형 정책: AWSEC2SpotFleetServiceRolePolicy
이 정책은 **AWSServiceRoleForEC2SpotFleet**이라는 서비스 연결 역할에 연결되어 스팟 플릿이 사용자를 대신하여 인스턴스를 시작하고 관리할 수 있도록 합니다. 자세한 내용은 [스팟 플릿의 서비스 연결 역할](spot-fleet-prerequisites.md#service-linked-roles-spot-fleet-requests) 섹션을 참조하세요.
이 정책의 권한을 보려면 AWS 관리형 정책 참조의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotFleetServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotFleetServiceRolePolicy.html)를 참조하세요.**
## AWS 관리형 정책: AWSEC2SpotServiceRolePolicy
이 정책은 **AWSServiceRoleForEC2Spot**이라는 서비스 연결 역할에 연결되어 Amazon EC2가 사용자를 대신하여 스팟 인스턴스를 시작하고 관리할 수 있도록 합니다. 자세한 내용은 [스팟 인스턴스 요청에 대한 서비스 연결 역할](service-linked-roles-spot-instance-requests.md) 섹션을 참조하세요.
이 정책의 권한을 보려면 AWS 관리형 정책 참조의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotServiceRolePolicy.html)를 참조하세요.**
## AWS 관리형 정책: AWSEC2VssSnapshotPolicy
Amazon EC2 Windows 인스턴스에서 사용할 IAM 인스턴스 프로파일 역할에 이 관리형 정책을 연결할 수 있습니다. 이 정책은 Amazon EC2가 자동으로 VSS 스냅샷을 생성하고 관리할 수 있는 권한을 부여합니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2VssSnapshotPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2VssSnapshotPolicy.html)를 참조하세요.
## AWS 관리형 정책: DeclarativePoliciesEC2Report
이 정책은 선언 정책에 대한 계정 상태 보고서를 생성하는 데 필요한 읽기 전용 API에 대한 액세스를 제공하기위해 `AWSServiceRoleForDeclarativePoliciesEC2Report`라는 서비스 연결 역할에 연결됩니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/DeclarativePoliciesEC2Report.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/DeclarativePoliciesEC2Report.html)를 참조하세요.
## AWS 관리형 정책: EC2FastLaunchFullAccess
인스턴스 프로필 또는 다른 IAM 역할에 `EC2FastLaunchFullAccess` 정책을 연결할 수 있습니다. 이 정책은 다음과 같이 EC2 Fast Launch 작업에 대한 전체 액세스 권한과 대상 권한을 부여합니다.
**권한 세부 정보**
+ **EC2 Fast Launch** — 관리 액세스 권한이 부여되어 해당 역할이 EC2 Fast Launch를 활성화 또는 비활성화하고 EC2 Fast Launch 이미지를 설명할 수 있습니다.
+ **Amazon EC2** - Amazon EC2 RunInstances, CreateTags, Describe 작업과 시작 템플릿 생성 및 수정 작업에 대한 액세스 권한이 부여됩니다. 네트워크와 보안 그룹 리소스를 생성하고, 수신 규칙을 승인하고, EC2 Fast Launch가 생성한 리소스를 삭제할 수 있는 액세스 권한도 부여됩니다.
+ **IAM** — 이름에 서비스 연결 역할을 생성할 수 있는 권한이 포함된 `ec2fastlaunch` 인스턴스 프로필을 가져오고 사용할 수 있는 액세스 권한이 부여됩니다. EC2FastLaunchServiceRolePolicy
+ **CloudFormation** - CloudFormation 스택을 설명 및 생성하고 생성한 스택을 삭제하기 위해 EC2 Fast Launch에 액세스할 수 있는 권한이 부여됩니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchFullAccess.html)를 참조하세요.
## AWS 관리형 정책: AWSEC2CapacityManagerServiceRolePolicy
이 정책은 EC2 용량 관리자가 사용자를 대신하여 용량 리소스를 관리하고 AWS Organizations와 통합할 수 있도록 허용하는 **AWSServiceRoleForEC2CapacityManager**라는 서비스 연결 역할에 연결됩니다. 자세한 내용은 [EC2 용량 관리자의 서비스 연결 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-service-linked-roles-cm.html)을 참조하세요.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityManagerServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityManagerServiceRolePolicy.html)를 참조하세요.
## AWS 관리형 정책: EC2FastLaunchServiceRolePolicy
이 정책은 **AWSServiceRoleForEC2FastLaunch**라는 서비스 연결 역할에 연결되어 Amazon EC2가 EC2 Fast Launch가 활성화된 AMI에서 인스턴스를 시작하는 데 걸리는 시간을 줄이는 사전 프로비저닝된 스냅샷 세트를 생성하고 관리할 수 있도록 합니다. 자세한 내용은 [EC2 Fast Launch를 위한 서비스 연결 역할](slr-windows-fast-launch.md) 섹션을 참조하세요.
이 정책의 권한을 보려면 AWS 관리형 정책 참조의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchServiceRolePolicy.html)를 참조하세요.**
## AWS 관리형 정책: Ec2InstanceConnect
`Ec2InstanceConnect` 정책을 IAM ID에 연결할 수 있습니다. 이 정책은 고객이 EC2 Instance Connect를 직접적으로 호출하여 EC2 인스턴스에 임시 키를 게시하고 ssh 또는 EC2 Instance Connect CLI를 통해 연결할 수 있는 권한을 부여합니다.
이 정책의 권한을 보려면 *AWS 관리형 정책 참조*의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2InstanceConnect.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2InstanceConnect.html)를 참조하세요.
## AWS 관리형 정책: Ec2InstanceConnectEndpoint
이 정책은 **AWSServiceRoleForEC2InstanceConnect**라는 서비스 연결 역할에 연결되어 EC2 Instance Connect 엔드포인트에서 자동으로 작업을 수행하도록 지원합니다. 자세한 내용은 [EC2 Instance Connect 엔드포인트에 대한 서비스 연결 역할](eice-slr.md) 섹션을 참조하세요.
이 정책의 권한을 보려면 AWS 관리형 정책 참조의 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/Ec2InstanceConnectEndpoint.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/Ec2InstanceConnectEndpoint.html)를 참조하세요.** 이 정책의 업데이트에 대한 설명은 [AWS 관리형 정책에 대한 Amazon EC2 업데이트](#security-iam-awsmanpol-updates)을 참조하세요.
## AWS 관리형 정책에 대한 Amazon EC2 업데이트
이 서비스가 이러한 변경 내용을 추적하기 시작한 이후부터 Amazon EC2의 AWS 관리형 정책 업데이트에 대한 세부 정보를 봅니다.
| 변경 | 설명 | 날짜 |
| --- | --- | --- |
| [AWSEC2CapacityManagerServiceRolePolicy](#security-iam-awsmanpol-AWSEC2CapacityManagerServiceRolePolicy) - 새 정책 | Amazon EC2는 고객이 사용자를 대신하여 용량 리소스를 관리하고 AWS Organizations와 통합할 수 있도록 이 정책을 추가했습니다. | 2025년 10월 15일 |
| [AmazonEC2ImageReferencesAccessPolicy](#security-iam-awsmanpol-AmazonEC2ImageReferencesAccessPolicy) - 새 정책 | Amazon EC2는 EC2 DescribeImageReferences API에서 지원하는 모든 리소스 유형을 스캔할 수 있는 권한을 제공하기 위해 이 정책을 추가했습니다. | 2025년 8월 26일 |
| [Ec2InstanceConnectEndpoint](#Ec2InstanceConnectEndpoint) - 정책 업데이트 | 기존 Instance Connect 엔드포인트의 수정을 지원하기 위해 Amazon EC2는 IPv6 주소를 할당 및 할당 해제하고 EC2 Instance Connect 엔드포인트에서 생성된 네트워크 인터페이스에서 보안 그룹을 수정할 수 있는 권한을 추가하도록이 정책을 업데이트했습니다. Amazon EC2는 Null 조건 연산자를 StringLike 조건 연산자로 대체하기 위해 이 정책도 업데이트했습니다. | 2025년 7월 31일 |
| [EC2FastLaunchServiceRolePolicy](#security-iam-awsmanpol-EC2FastLaunchServiceRolePolicy) - 정책 업데이트 | 분리된 리소스를 방지하기 위해 Amazon EC2는 볼륨, 볼륨 속성, 네트워크 인터페이스를 설명하고 EC2 Fast Launch가 생성한 볼륨 및 네트워크 인터페이스를 삭제할 수 있는 권한을 추가하도록 이 정책을 업데이트했습니다. | 2025년 7월 17일 |
| [EC2FastLaunchFullAccess](#security-iam-awsmanpol-EC2FastLaunchFullAccess) - 정책 업데이트 | Amazon EC2는 시작 템플릿 생성 및 수정 작업을 포함하고, 네트워크 및 보안 그룹 리소스를 생성하며, 수신 규칙을 승인하고, EC2 Fast Launch가 생성한 리소스를 삭제할 수 있도록 이 정책을 업데이트했습니다. CloudFormation 스택을 추가로 설명 및 생성하고 EC2 Fast Launch가 생성한 스택을 삭제할 수 있습니다. | 2025년 5월 14일 |
| [EC2FastLaunchServiceRolePolicy](#security-iam-awsmanpol-EC2FastLaunchServiceRolePolicy) - 정책 업데이트 | Amazon EC2는 이 정책을 업데이트하여 EC2 Fast Launch를 위한 이벤트 규칙을 생성하고 관리할 수 있도록 Amazon EventBridge 액세스 권한을 추가했습니다. 또한 EC2 Fast Launch는 이제 CloudFormation 스택을 설명할 수 있고, AWS License Manager와 연결된 AMI에서 인스턴스를 시작할 수 있으며, 사용 중지할 수 있는 AWS KMS 권한 부여 목록을 가져올 수 있고, 생성한 시작 템플릿을 삭제할 수 있습니다. | 2025년 5월 14일 |
| [AWSEC2CapacityReservationFleetRolePolicy](#security-iam-awsmanpol-AWSEC2CapacityReservationFleetRolePolicy) - 업데이트된 권한 | Amazon EC2는 StringLike 조건 연산자 대신 ArnLike 조건 연산자를 사용하도록 AWSEC2CapacityReservationFleetRolePolicy 관리형 정책을 업데이트했습니다. | 2025년 3월 3일 |
| [AmazonEC2ReadOnlyAccess](#security-iam-awsmanpol-AmazonEC2ReadOnlyAccess) – 권한 추가 | Amazon EC2는 GetSecurityGroupsForVpc 작업을 사용하여 보안 그룹을 검색할 수 있는 권한을 추가했습니다. | 2024년 12월 27일 |
| [EC2FastLaunchFullAccess](#security-iam-awsmanpol-EC2FastLaunchFullAccess) - 새 정책 | Amazon EC2는 인스턴스에서 EC2 Fast Launch 기능과 관련된 API 작업을 수행하기 위해 이 정책을 추가했습니다. 정책은 EC2 Fast Launch가 활성화된 AMI에서 시작된 인스턴스의 인스턴스 프로필에 연결할 수 있습니다. | 2024년 5월 14일 |
| [AWSEC2VssSnapshotPolicy](#security-iam-awsmanpol-AWSEC2VssSnapshotPolicy) - 새 정책 | Amazon EC2는 Amazon Machine Image(AMI) 및 EBS 스냅샷을 생성하고 태그를 추가할 수 있는 권한을 포함하는 AWSEC2VssSnapshotPolicy 정책을 추가했습니다. | 2024년 3월 28일 |
| [Ec2InstanceConnectEndpoint](#Ec2InstanceConnectEndpoint) - 새 정책 | Amazon EC2에서 Ec2InstanceConnectEndpoint 정책을 추가했습니다. 이 정책은 AWSServiceRoleForEC2InstanceConnect 서비스 연결 역할에 연결되어 EC2 Instance Connect 엔드포인트를 생성할 때 Amazon EC2가 사용자를 대신하여 작업을 수행할 수 있도록 허용합니다. | 2023년 1월 24일 |
| [EC2FastLaunchServiceRolePolicy](#security-iam-awsmanpol-EC2FastLaunchServiceRolePolicy) - 새 정책 | Amazon EC2는 사전 프로비저닝된 스냅샷 세트를 생성하여 Windows AMI가 인스턴스를 더 빠르게 시작할 수 있도록 EC2 Fast Launch 기능을 추가했습니다. | 2021년 11월 26일 |
| Amazon EC2 변경 사항 추적 시작 | Amazon EC2 AWS관리형 정책에 대한 변경 사항 추적을 시작했습니다. | 2021년 3월 1일 |
# Amazon EC2의 IAM 역할
애플리케이션은 AWS 자격 증명으로 API 요청에 서명해야 합니다. 따라서 애플리케이션 개발자는 EC2 인스턴스에서 실행되는 인스턴스의 자격 증명을 관리할 전략을 수립해야 합니다. 예를 들어 AWS 자격 증명을 인스턴스에 안전하게 배포하여 다른 사용자로부터 보호하는 한편 해당 인스턴스의 애플리케이션이 자격 증명을 사용하여 요청에 서명하도록 할 수 있습니다. 그러나 각 인스턴스에 자격 증명을 안전하게 배포하기란 쉽지 않으며, 스팟 인스턴스와 같이 AWS에서 자동으로 생성하는 인스턴스 또는 Auto Scaling 그룹의 인스턴스에 대해서는 특히 어렵습니다. 또한 AWS 자격 증명을 교체할 때 각 인스턴스의 자격 증명을 업데이트할 수 있어야 합니다.
애플리케이션이 사용하는 보안 자격 증명을 직접 관리할 필요 없이 인스턴스의 애플리케이션에서 안전하게 API 요청을 전송할 수 있도록 IAM 역할을 설계했습니다. AWS 자격 증명을 생성하고 배포하는 대신 다음과 같이 IAM 역할을 사용하여 API 요청 전송 권한을 위임할 수 있습니다.
1. IAM 역할 생성.
1. 역할을 수행할 수 있는 계정 또는 AWS 서비스를 정의합니다.
1. 역할을 수행하면서 애플리케이션이 사용할 수 있는 API 작업 및 리소스를 정의합니다.
1. 인스턴스를 시작할 때 역할을 지정하거나, 기존 인스턴스에 역할을 연결합니다.
1. 애플리케이션에서 임시 자격 증명 세트를 검색하여 사용하도록 합니다.
예를 들어 IAM 역할을 사용하여 인스턴스에서 실행되며 Amazon S3의 버킷을 사용해야 하는 애플리케이션에 해당 권한을 부여할 수 있습니다. JSON 형식으로 정책을 생성하여 IAM 역할에 권한을 지정할 수 있습니다. 이 방법은 사용자를 대상으로 정책을 생성할 때와 비슷합니다. 역할을 변경하면 모든 인스턴스에 변경 내용이 전파됩니다.
**참고**
Amazon EC2 IAM 역할 보안 인증에는 역할에 구성된 최대 세션 기간이 적용되지 않습니다. 자세한 내용은 *IAM 사용 설명서*의 [역할 수임 방법](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)을 참조하세요.
IAM 역할을 생성할 때, 애플리케이션에 필요한 특정 API 호출에 대한 액세스를 제한하는 최소 권한 IAM 정책을 연결합니다. Windows 간 통신의 경우 잘 정의되고 잘 문서화된 Windows 그룹 및 역할을 사용하여 Windows 인스턴스 간에 애플리케이션 수준의 액세스 권한을 부여합니다. 고객은 그룹 및 역할을 통해 최소 권한 애플리케이션 및 NTFS 폴더 수준 권한을 정의하여 애플리케이션별 요구 사항에 맞게 액세스를 제한할 수 있습니다.
인스턴스에 하나의 IAM 역할만 연결할 수 있지만, 여러 인스턴스에 동일한 역할을 연결할 수는 있습니다. IAM 역할 생성 및 사용에 대한 자세한 내용은 *IAM 사용 설명서*에서 [역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)을 참조하십시오.
IAM 정책에 리소스 수준 권한을 적용하여 사용자가 인스턴스에 IAM 역할을 연결, 교체 또는 분리할 수 있는 권한을 제어할 수 있습니다. 자세한 내용은 [Amazon EC2 API 작업에 지원되는 리소스 수준 권한](iam-policies-for-amazon-ec2.md#ec2-supported-iam-actions-resources) 및 다음 예제: [예: IAM 역할 작업](ExamplePolicies_EC2.md#iam-example-iam-roles) 섹션을 참조하세요.
**Topics**
+ [인스턴스 프로파일](#ec2-instance-profile)
+ [사용 사례에 대한 권한](#generate-policy-for-iam-role)
+ [보안 자격 증명 검색](instance-metadata-security-credentials.md)
+ [인스턴스에 역할을 연결할 수 있는 권한](permission-to-pass-iam-roles.md)
+ [인스턴스에 역할 연결](attach-iam-role.md)
+ [인스턴스 ID 역할](#ec2-instance-identity-roles)
## 인스턴스 프로파일
Amazon EC2에서는 *인스턴스 프로파일*을 IAM 역할의 컨테이너로 사용합니다. IAM 콘솔을 사용하여 IAM 역할을 생성하면 인스턴스 프로파일이 자동으로 생성되고 해당 역할과 동일한 이름이 지정됩니다. Amazon EC2 콘솔을 사용하여 IAM 역할로 인스턴스를 시작하거나 인스턴스에 IAM 역할을 연결하는 경우 인스턴스 프로파일 이름 목록을 기반으로 역할을 선택합니다.
AWS CLI, API 또는 AWS SDK를 사용하여 역할을 생성하면 역할과 인스턴스 프로파일이 별개의 작업으로 생성되며 이름은 각각 다를 수 있습니다. AWS CLI, API 또는 AWS SDK를 사용하여 IAM 역할로 인스턴스를 시작하거나 인스턴스에 IAM 역할을 연결하는 경우 인스턴스 프로파일 이름을 지정합니다.
인스턴스 프로파일은 하나의 IAM 역할만 포함할 수 있습니다. 여러 인스턴스 프로파일에 IAM 역할을 포함할 수 있습니다.
인스턴스에 대한 권한을 업데이트하려면 해당 인스턴스 프로파일을 교체합니다. 이 변경 사항이 적용되기까지 최대 1시간이 지연되므로 인스턴스 프로파일에서 역할을 제거하는 것은 권장되지 않습니다.
자세한 내용은 *IAM 사용 설명서*의 [인스턴스 프로파일 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)을 참조하세요.
## 사용 사례에 대한 권한
애플리케이션에 대한 IAM 역할을 처음 생성하는 경우 간혹 필요 이상의 권한을 부여하게 될 수 있습니다. 프로덕션 환경에서 애플리케이션을 시작하기 전에 IAM 역할에 대한 액세스 활동을 기반으로 IAM 정책을 생성할 수 있습니다. IAM Access Analyzer는 사용자의 AWS CloudTrail 로그를 검토하고 지정된 날짜 범위에 역할에 의해 사용된 권한이 포함된 정책 템플릿을 생성합니다. 템플릿을 사용하여 세분화된 권한을 가진 관리형 정책을 생성한 다음 IAM 역할에 연결할 수 있습니다. 이렇게 하면 특정 사용 사례에 따라 역할이 AWS 리소스와 상호 작용하는 데 필요한 권한만 부여할 수 있습니다. 이는 [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 모범 사례를 준수하는 데 도움이 됩니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM Access Analyzer 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)을 참조하세요.
# 인스턴스 메타데이터에서 보안 자격 증명 검색
인스턴스의 애플리케이션은 인스턴스 메타데이터 항목 `iam/security-credentials/`*role-name*에서 역할이 제공하는 보안 자격 증명을 검색합니다. 역할에 연결된 보안 자격 증명을 통해 역할에 정의한 작업 및 리소스에 대한 권한이 애플리케이션에 부여됩니다. 이러한 보안 자격 증명은 임시로 발급되며 자동으로 교체됩니다. 이전 자격 증명이 만료되기 최소 5분 전에 새 자격 증명이 제공됩니다.
인스턴스 메타데이터에 대한 자세한 내용은 [인스턴스 메타데이터를 사용하여 EC2 인스턴스를 관리합니다.](ec2-instance-metadata.md) 섹션을 참조하세요.
**주의**
IAM 역할과 함께 인스턴스 메타데이터를 사용하는 서비스를 사용하는 경우 서비스에서 사용자 대신 HTTP 호출을 수행할 때 자격 증명이 노출되지 않도록 주의하세요. 자격 증명이 노출될 수 있는 서비스 유형은 HTTP 프록시, HTML/CSS 검증 서비스, XML 포함을 지원하는 XML 프로세서 등입니다.
Amazon EC2 워크로드의 경우 아래 설명된 방법을 사용하여 세션 자격 증명을 검색하는 것이 좋습니다. 이러한 자격 증명을 사용하면 `sts:AssumeRole`을 사용하여 인스턴스와 이미 연결된 동일한 역할을 맡을 필요 없이 워크로드에서 AWS API 요청을 수행할 수 있습니다. 속성 기반 액세스 제어(ABAC)에 대한 세션 태그를 전달하거나 역할의 권한을 추가로 제한하기 위해 세션 정책을 전달해야 하는 경우가 아니면 이러한 역할 수임 호출은 동일한 임시 역할 세션 자격 증명의 새 세트를 생성하므로 불필요합니다.
워크로드가 역할을 사용하여 자체적으로 수임하는 경우 해당 역할이 자체적으로 수임하도록 명시적으로 허용하는 신뢰 정책을 생성해야 합니다. 신뢰 정책을 생성하지 않으면 `AccessDenied` 오류가 발생합니다. 자세한 내용은 *IAM 사용 설명서*의 [역할 신뢰 정책 업데이트](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html)를 참조하세요.
------
#### [ IMDSv2 ]
**Linux**
Linux 인스턴스에서 다음 명령을 실행하여 IAM 역할에 대한 보안 자격 증명을 검색합니다.
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
**Windows**
Windows 인스턴스에서 다음 cmdlet을 실행하여 IAM 역할에 대한 보안 자격 증명을 검색합니다.
```
[string]$token = Invoke-RestMethod `
-Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} `
-Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod `
-Headers @{"X-aws-ec2-metadata-token" = $token} `
-Method GET -Uri http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
------
#### [ IMDSv1 ]
**Linux**
Linux 인스턴스에서 다음 명령을 실행하여 IAM 역할에 대한 보안 자격 증명을 검색합니다.
```
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
**Windows**
Windows 인스턴스에서 다음 cmdlet을 실행하여 IAM 역할에 대한 보안 자격 증명을 검색합니다.
```
Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
------
다음은 예제 출력입니다. 보안 자격 증명을 검색할 수 없는 경우 *IAM 사용 설명서*의 [제 EC2 인스턴스의 임시 보안 자격 증명에 액세스할 수 없습니다.](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-ec2.html#troubleshoot_iam-ec2_no-keys)를 참조하세요.
```
{
"Code" : "Success",
"LastUpdated" : "2012-04-26T16:39:16Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
"SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token" : "token",
"Expiration" : "2017-05-17T15:09:54Z"
}
```
인스턴스에서 실행되는 애플리케이션, AWS CLI 및 Tools for Windows PowerShell 명령의 경우, 임시 보안 자격 증명을 명시적으로 받지 않아도 됩니다. AWS SDK, AWS CLI 및 Tools for Windows PowerShell이 EC2 인스턴스 메타데이터 서비스에서 자동으로 자격 증명을 받아 사용하기 때문입니다. 임시 보안 자격 증명을 사용하여 인스턴스 외부로 호출하려면(예: IAM 정책 테스트) 액세스 키, 보안 키 및 세션 토큰을 제공해야 합니다. 자세한 내용은 *IAM 사용 설명서*에서 [임시 보안 자격 증명을 사용하여 AWS 리소스에 대한 액세스 요청](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)을 참조하세요.
# 인스턴스에 IAM 역할을 연결할 수 있는 권한 부여
IAM 사용자와 같은 AWS 계정의 ID에는 IAM 역할로 Amazon EC2 인스턴스를 시작하거나, 인스턴스에 IAM 역할을 연결하거나, 인스턴스의 IAM 역할을 바꾸거나, 인스턴스에서 IAM 역할을 분리할 수 있는 특정 권한이 있어야 합니다. 필요에 따라 다음 API 작업을 사용할 수 있는 권한을 부여해야 합니다.
+ `iam:PassRole`
+ `ec2:AssociateIamInstanceProfile`
+ `ec2:DisassociateIamInstanceProfile`
+ `ec2:ReplaceIamInstanceProfileAssociation`
**참고**
`iam:PassRole`에 대한 리소스를 `*`로 지정하면 인스턴스에 모든 IAM 역할을 전달할 수 있는 액세스 권한이 부여됩니다. [최소 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)의 모범 사례를 따르려면 아래 정책 예제에서와 같이 `iam:PassRole`로 특정 IAM 역할의 ARN을 지정합니다.
**프로그래밍 방식 액세스를 위한 정책 예제**
다음 IAM 정책은 AWS CLI 또는 Amazon EC2 API를 사용하여 IAM 역할로 인스턴스를 시작하거나, 인스턴스에 IAM 역할을 연결하거나, 인스턴스의 IAM 역할을 바꿀 수 있는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:AssociateIamInstanceProfile",
"ec2:DisassociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/DevTeam*"
}
]
}
```
------
**콘솔 액세스에 대한 추가 요구 사항**
Amazon EC2 콘솔을 사용하여 동일한 태스크를 완료할 수 있는 권한을 부여하려면 `iam:ListInstanceProfiles` API 작업도 포함해야 합니다.
# IAM 역할을 인스턴스에 연결
IAM 역할을 만들고 시작 도중 또는 후에 인스턴스에 연결할 수 있습니다. IAM 역할을 교체하거나 분리할 수도 있습니다.
**인스턴스 시작 중 IAM 역할 생성 및 연결(권장)**
1. EC2 인스턴스를 시작하는 동안 **고급 세부 정보**를 확장합니다.
1. **IAM 인스턴스 프로파일** 섹션에서 **새 IAM 역할 생성**을 선택합니다.
1. 인라인 역할 생성 양식이 열리고 다음을 수행할 수 있습니다.
+ **역할 이름**(예: `EC2-S3-Access-Role`)을 지정합니다.
+ AWS 관리형 정책을 선택하거나 인스턴스에 대한 사용자 지정 정책을 생성하여 권한 정의
예를 들어, S3 액세스 권한을 부여하려면 `AmazonS3ReadOnlyAccess` 관리형 정책을 선택합니다.
+ `ec2.amazonaws.com`가 역할을 수임하도록 허용하는 신뢰 정책을 검토합니다.
+ 메타데이터에 대한 선택적 태그 추가
1. **역할 생성**을 선택합니다.
새로 생성된 역할은 자동으로 선택되며 인스턴스가 시작될 때 인스턴스 프로파일을 통해 인스턴스에 연결됩니다.
**참고**
인스턴스 시작 시 콘솔을 사용하여 역할을 생성하면 해당 역할과 동일한 이름의 인스턴스 프로파일이 자동으로 생성됩니다. 인스턴스 프로파일은 시작할 때 IAM 역할 정보를 인스턴스에 전달하는 컨테이너입니다.
**중요**
인스턴스에 하나의 IAM 역할만 연결할 수 있지만, 여러 인스턴스에 동일한 역할을 연결할 수는 있습니다.
애플리케이션에 필요한 특정 API 호출에 대한 액세스를 제한하는 최소 권한 IAM 정책을 연결합니다.
IAM 역할 생성 및 사용에 대한 자세한 내용은 *IAM 사용 설명서*에서 [역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)을 참조하십시오.
**인스턴스 시작 중 기존 IAM 역할 연결**
Amazon EC2 콘솔을 사용하여 시작 시 인스턴스에 기존 IAM 역할을 연결하려면 **고급 세부 정보**를 확장합니다. **IAM 인스턴스 프로파일** 드롭다운 목록에서 IAM 역할을 선택합니다.
**참고**
IAM 콘솔을 사용하여 IAM 역할을 생성한 경우 인스턴스 프로파일이 생성되고 역할과 동일한 이름이 지정됩니다. AWS CLI, API 또는 AWS SDK를 사용하여 IAM 역할을 생성한 경우 인스턴스 프로파일에 역할과 다른 이름을 지정했을 수 있습니다.
실행 중이거나 중지된 인스턴스에 IAM 역할을 연결할 수 있습니다. 인스턴스에 이미 IAM 역할이 연결되어 있는 경우 새 IAM 역할로 교체해야 합니다.
------
#### [ Console ]
**IAM 역할을 인스턴스에 연결하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 인스턴스를 선택합니다.
1. **Actions**(작업), **Security**(보안), **Modify IAM role**(IAM 역할 수정)을 선택합니다.
1. **IAM 역할**에 대해 IAM 인스턴스 프로파일을 선택합니다.
1. **IAM 역할 업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**IAM 역할을 인스턴스에 연결하려면**
[associate-iam-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html) 명령을 사용하여 인스턴스에 IAM 역할을 연결합니다. 인스턴스 프로파일을 지정할 때 인스턴스 프로파일의 Amazon 리소스 이름(ARN) 또는 이름을 사용할 수 있습니다.
```
aws ec2 associate-iam-instance-profile \
--instance-id i-1234567890abcdef0 \
--iam-instance-profile Name="TestRole-1"
```
------
#### [ PowerShell ]
**IAM 역할을 인스턴스에 연결하려면**
[Register-EC2IamInstanceProfile](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2IamInstanceProfile.html) cmdlet을 사용합니다.
```
Register-EC2IamInstanceProfile `
-InstanceId i-1234567890abcdef0 `
-IamInstanceProfile_Name TestRole-1
```
------
이미 IAM 역할이 연결된 인스턴스에서 IAM 역할을 교체하려면 인스턴스가 실행 중이어야 합니다. 기존 인스턴스를 먼저 분리하지 않고 인스턴스에 대한 IAM 역할을 변경하려는 경우 이 작업을 수행할 수 있습니다. 예를 들어 인스턴스에서 실행 중인 애플리케이션에서 수행된 API 작업이 중단되지 않도록 하기 위해 이 작업을 수행할 수 있습니다.
------
#### [ Console ]
**인스턴스에서 IAM 역할을 대체하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 인스턴스를 선택합니다.
1. **Actions**(작업), **Security**(보안), **Modify IAM role**(IAM 역할 수정)을 선택합니다.
1. **IAM 역할**에 대해 IAM 인스턴스 프로파일을 선택합니다.
1. **IAM 역할 업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**인스턴스에서 IAM 역할을 대체하려면**
1. 필요한 경우 [describe-iam-instance-profile-associations](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html) 명령을 사용하여 연결 ID를 가져옵니다.
```
aws ec2 describe-iam-instance-profile-associations \
--filters Name=instance-id,Values=i-1234567890abcdef0 \
--query IamInstanceProfileAssociations.AssociationId
```
1. [replace-iam-instance-profile-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-iam-instance-profile-association.html) 명령을 사용합니다. 기존 인스턴스 프로파일에 대한 연결 ID와 새 인스턴스 프로파일에 대한 ARN 또는 이름을 지정합니다.
```
aws ec2 replace-iam-instance-profile-association \
--association-id iip-assoc-0044d817db6c0a4ba \
--iam-instance-profile Name="TestRole-2"
```
------
#### [ PowerShell ]
**인스턴스에서 IAM 역할을 대체하려면**
1. 필요한 경우 [Get-EC2IamInstanceProfileAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2IamInstanceProfileAssociation.html) cmdlet을 사용하여 연결 ID를 가져옵니다.
```
(Get-EC2IamInstanceProfileAssociation -Filter @{Name="instance-id"; Values="i-0636508011d8e966a"}).AssociationId
```
1. [Set-EC2IamInstanceProfileAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2IamInstanceProfileAssociation.html) cmdlet을 사용합니다. 기존 인스턴스 프로파일에 대한 연결 ID와 새 인스턴스 프로파일에 대한 ARN 또는 이름을 지정합니다.
```
Set-EC2IamInstanceProfileAssociation `
-AssociationId iip-assoc-0044d817db6c0a4ba `
-IamInstanceProfile_Name TestRole-2
```
------
실행 중이거나 중지된 인스턴스에서 IAM 역할을 분리할 수 있습니다.
------
#### [ Console ]
**인스턴스에서 IAM 역할을 분리하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 인스턴스를 선택합니다.
1. **Actions**(작업), **Security**(보안), **Modify IAM role**(IAM 역할 수정)을 선택합니다.
1. **IAM 역할(IAM role)**에서 **IAM 역할 없음(No IAM Role)**을 선택합니다.
1. **IAM 역할 업데이트**를 선택합니다.
1. 확인 메시지가 나타나면 **분리**를 입력하고 **분리**를 선택합니다.
------
#### [ AWS CLI ]
**인스턴스에서 IAM 역할을 분리하려면**
1. 필요한 경우 [describe-iam-instance-profile-associations](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html)를 사용하여 분리할 IAM 인스턴스 프로파일에 대한 연결 ID를 가져옵니다.
```
aws ec2 describe-iam-instance-profile-associations \
--filters Name=instance-id,Values=i-1234567890abcdef0 \
--query IamInstanceProfileAssociations.AssociationId
```
1. [disassociate-iam-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html) 명령을 사용합니다.
```
aws ec2 disassociate-iam-instance-profile --association-id iip-assoc-0044d817db6c0a4ba
```
------
#### [ PowerShell ]
**인스턴스에서 IAM 역할을 분리하려면**
1. 필요한 경우 [Get-EC2IamInstanceProfileAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2IamInstanceProfileAssociation.html)을 사용하여 분리할 IAM 인스턴스 프로파일의 연결 ID를 가져옵니다.
```
(Get-EC2IamInstanceProfileAssociation -Filter @{Name="instance-id"; Values="i-0636508011d8e966a"}).AssociationId
```
1. [Unregister-EC2IamInstanceProfile](https://docs.aws.amazon.com/powershell/latest/reference/items/Unregister-EC2IamInstanceProfile.html) cmdlet을 사용합니다.
```
Unregister-EC2IamInstanceProfile -AssociationId iip-assoc-0044d817db6c0a4ba
```
------
## Amazon EC2 인스턴스의 인스턴스 자격 증명 역할
실행된 각 Amazon EC2 인스턴스에는 ID를 나타내는 *인스턴스 ID 역할*이 있습니다. 인스턴스 ID 역할은 일종의 IAM 역할입니다. 인스턴스 ID 역할을 사용하도록 통합된 AWS 서비스 및 기능은 이를 사용하여 서비스에서 인스턴스를 식별할 수 있습니다.
인스턴스 ID 역할 보안 인증 정보는 `/identity-credentials/ec2/security-credentials/ec2-instance`의 인스턴스 메타데이터 서비스(IMDS)에서 액세스할 수 있습니다. 보안 인증 정보는 AWS 임시 액세스 키 쌍과 세션 토큰으로 구성됩니다. 인스턴스 ID 역할을 사용하는 AWS 서비스에 대한 AWS Sigv4 요청에 서명하는 데 사용됩니다. 보안 인증 정보는 인스턴스 ID 역할을 사용하는 서비스 또는 기능이 인스턴스에서 활성화되었는지 여부에 관계없이 인스턴스 메타데이터에 표시됩니다.
인스턴스 ID 역할은 인스턴스가 시작될 때 자동으로 생성되며, 역할 신뢰 정책 문서가 없으며, ID 또는 리소스 정책의 적용을 받지 않습니다.
### 지원되는 서비스
다음 AWS 서비스는 인스턴스 ID 역할을 사용합니다.
+ **Amazon EC2** – [EC2 Instance Connect](connect-linux-inst-eic.md)는 인스턴스 ID 역할을 사용하여 Linux 인스턴스의 호스트 키를 업데이트합니다.
+ **Amazon GuardDuty** - [GuardDuty 런타임 모니터링](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)은 인스턴스 ID 역할을 사용하여 런타임 에이전트가 GuardDuty VPC 엔드포인트로 보안 원격 측정을 전송할 수 있도록 합니다.
+ **AWS Lambda** - [Lambda 관리형 인스턴스](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html)는 수명 주기 후크, 원격 측정 및 아티팩트 배포에 인스턴스 ID 역할을 사용합니다.
+ **AWS Security Token Service(AWS STS)** – 인스턴스 ID 역할 보안 인증 정보를 AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html) 작업과 함께 사용할 수 있습니다.
+ **AWS Systems Manager**— [기본 호스트 관리 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-default-host-management-configuration.html)을 사용하는 경우 AWS Systems Manager는 인스턴스 ID 역할에서 제공하는 ID를 사용하여 EC2 인스턴스를 등록합니다. 인스턴스를 식별한 후 Systems Manager는 사용자의 `AWSSystemsManagerDefaultEC2InstanceManagementRole` IAM 역할을 인스턴스에 전달할 수 있습니다.
인스턴스 ID 역할은 인스턴스 ID 역할과 통합되지 않으므로 다른 AWS 서비스 또는 기능과 함께 사용할 수 없습니다.
### 인스턴스 ID 역할 ARN
인스턴스 ID 역할 ARN은 다음과 같은 형식을 사용합니다.
```
arn:aws-partition:iam::account-number:assumed-role/aws:ec2-instance/instance-id
```
예제:
```
arn:aws:iam::0123456789012:assumed-role/aws:ec2-instance/i-1234567890abcdef0
```
ARN에 대한 자세한 내용은 *IAM 사용 설명서*의 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)을 참조하세요.
# Amazon EC2 인스턴스에 대한 업데이트 관리
EC2 인스턴스에서 운영 체제와 애플리케이션을 정기적으로 패치, 업데이트 및 보호하는 것이 좋습니다. [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html)를 사용하여 운영 체제와 애플리케이션 모두에 대해 보안 관련 업데이트를 설치하는 프로세스를 자동화할 수 있습니다.
Auto Scaling 그룹의 EC2 인스턴스의 경우 [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-patchasginstance.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-patchasginstance.html) 런북을 사용하여 패치가 진행 중인 인스턴스가 대체되는 것을 방지할 수 있습니다. 또는 자동 업데이트 서비스를 사용하거나, 애플리케이션 공급업체에서 제공하는 업데이트를 설치하기 위한 권장 프로세스를 사용할 수 있습니다.
**리소스**
+ **AL2023** - *Amazon Linux 2023 사용 설명서*의 [AL2023 업데이트](https://docs.aws.amazon.com/linux/al2023/ug/updating.html).
+ **AL2** - *Amazon Linux 2 사용 설명서*의 [Amazon Linux 2 인스턴스의 소프트웨어 관리](https://docs.aws.amazon.com/linux/al2/ug/managing-software.html).
+ **Windows 인스턴스** – [업데이트 관리](ec2-windows-security-best-practices.md#ec2-windows-update-management)
# Windows 인스턴스를 위한 보안 모범 사례
Windows 인스턴스에 대해 다음 보안 모범 사례를 따르는 것이 좋습니다.
**Topics**
+ [높은 수준의 보안 모범 사례](#high-level-security)
+ [업데이트 관리](#ec2-windows-update-management)
+ [구성 관리](#configuration-management)
+ [변경 관리](#change-management)
+ [Amazon EC2 Windows 인스턴스에 대한 감사 및 책임](#audit-accountability)
## 높은 수준의 보안 모범 사례
Windows 인스턴스에 대해 다음과 같은 높은 수준의 보안 모범 사례를 준수해야 합니다.
+ **최소 액세스** - 신뢰할 수 있고 예상되는 시스템 및 위치에만 액세스 권한을 부여합니다. 이는 Active Directory, Microsoft 비즈니스 생산성 서버 등 모든 Microsoft 제품 및 원격 데스크톱 서비스, 역방향 프록시 서버, IIS 웹 서버 등의 인프라 서비스에 적용됩니다. Amazon EC2 인스턴스 보안 그룹, 네트워크 액세스 제어 목록(ACL), Amazon VPC 퍼블릭/프라이빗 서브넷과 같은 AWS 기능을 사용하여 아키텍처의 여러 위치에 걸쳐 보안을 계층화합니다. 고객은 Windows 인스턴스 안에서 Windows 방화벽을 사용하여 해당 배포의 심층 방어 전략을 추가로 계층화할 수 있습니다. 시스템이 설계된 대로 작동하는 데 필요한 OS 구성 요소 및 애플리케이션만 설치하세요. IIS와 같은 인프라 서비스를 서비스 계정에서 실행하도록 구성하거나, 애플리케이션 풀 ID와 같은 기능을 사용하여 인프라 전체의 리소스에 로컬 또는 원격으로 액세스하도록 구성합니다.
+ **최소 권한** - 인스턴스 및 계정이 담당하는 기능을 수행하기 위해 필요한 최소 권한 집합을 결정합니다. 이렇게 정의된 권한만 허용하도록 이러한 서버 및 사용자를 제한합니다. 역할 기반 액세스 제어와 같은 기술을 사용하여 관리 계정의 노출 영역을 줄이고, 작업 수행을 위해 가장 제한된 역할을 만듭니다. NTFS의 EFS(파일 시스템 암호화)와 같은 OS 기능을 사용하여 저장된 민감한 데이터를 암호화하고, 그 데이터에 대한 애플리케이션 및 사용자 액세스를 제어합니다.
+ **구성 관리** - 바이러스 백신, 맬웨어 방지, 침입 탐지/방지 및 파일 무결성 모니터링이 포함된 호스트 기반 보호 제품군과 최신 보안 패치를 통합하는 기본 서버 구성을 생성합니다. 현재 기록된 기준선으로 각 서버를 평가하여 편차를 식별하고 플래그를 지정합니다. 각 서버가 적절한 로그 및 감사 데이터를 생성하고 안전하게 저장하도록 구성되어 있는지 확인합니다.
+ **변경 관리** - 변경 프로세스의 완전 자동화를 목표로 서버 구성 기준의 변경 사항을 제어하는 프로세스를 생성합니다. 또한 Windows PowerShell DSC와 함께 JEA(충분한 관리)를 활용하여 관리 액세스를 최소한의 필수 기능만으로 제한합니다.
+ **패치 관리** - EC2 인스턴스에서 운영 체제와 애플리케이션을 정기적으로 패치, 업데이트 및 보호하는 프로세스를 구현합니다.
+ **감사 로그** - Amazon EC2 인스턴스에 대한 액세스 및 모든 변경 사항을 감사하여 서버 무결성을 확인하고 승인된 변경 사항만 수행되도록 합니다 [IIS용 향상된 로깅](https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-85/enhanced-logging-for-iis85) 등의 기능을 활용하여 기본 로깅 기능을 향상시킵니다. VPC 흐름 로그 등 AWS 기능을 사용할 수 있으며, 허용/거부된 요청 및 API 호출 등 네트워크 액세스를 AWS CloudTrail로 각각 감사할 수도 있습니다.
## 업데이트 관리
Amazon EC2에서 Windows Server를 실행할 때 최상의 결과를 얻으려면 다음 모범 사례를 구현하는 것이 좋습니다.
+ [Configure Windows Update](#windows-update)
+ [Update drivers](#drivers)
+ [Use the latest Windows AMIs](#AMI)
+ [Test performance before migration](#test)
+ [Update launch agents](#agents)
+ 업데이트를 설치한 후 Windows 인스턴스를 재부팅합니다. 자세한 내용은 [Amazon EC2 인스턴스 재부팅](ec2-instance-reboot.md) 섹션을 참조하세요.
Windows 인스턴스를 새 버전의 Windows Server로 업그레이드하거나 마이그레이션하는 방법에 대한 자세한 내용은 [EC2 Windows 인스턴스를 새 버전의 Windows Server로 업그레이드](serverupgrade.md) 섹션을 참조하세요.
**Windows 업데이트 구성**
기본적으로 AWS Windows Server AMI에서 실행되는 인스턴스는 Windows 업데이트를 통해 업데이트를 받지 않습니다.
**Windows 드라이버 업데이트**
플릿 전체에 최신 문제 수정 및 성능 개선사항이 적용되도록 하려면 모든 Windows EC2 인스턴스에 최신 드라이버를 설치해야 합니다. 인스턴스 유형에 따라 AWS PV, Amazon ENA, AWS NVMe 드라이버를 업데이트해야 합니다.
+ [SNS 주제](xen-drivers-overview.md#drivers-subscribe-notifications)를 이용해 새로 출시된 드라이버에 관한 업데이트를 받으세요.
+ AWS Systems Manager Automation 런북 [AWSSupport-UpgradeWindowsAWSDrivers](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-upgradewindowsawsdrivers.html)를 사용하여 인스턴스 전반에 업데이트를 손쉽게 적용하세요.
**최신 Windows AMI를 사용하여 인스턴스 시작**
AWS는 최신 OS 패치, 드라이버, 시작 에이전트가 포함된 신규 Windows AMI를 매월 출시합니다. 새 인스턴스를 시작하거나 자체 사용자 지정 이미지를 만들 때는 최신 AMI를 활용해야 합니다.
+ AWS Windows AMI의 각 릴리스에 대한 업데이트를 보려면 [AWS Windows AMI 버전 기록](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/ec2-windows-ami-version-history.html) 섹션을 참조하세요.
+ 사용 가능한 최신 AMI를 이용해 이미지를 만드는 방법은 [Systems Manager 파라미터 스토어를 사용한 최신 Windows AMI에 대한 쿼리](https://aws.amazon.com/blogs/mt/query-for-the-latest-windows-ami-using-systems-manager-parameter-store/) 섹션을 참조하세요.
+ 데이터베이스 및 규정 준수 강화 사용 사례의 인스턴스를 시작하는 데 사용할 수 있는 특수 Windows AMI에 대한 자세한 내용은 *AWS Windows AMI 참조*에서 [특수 Windows AMI](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/specialized-windows-amis.html)를 참조하세요.
**마이그레이션하기 전 시스템/애플리케이션 성능 테스트**
엔터프라이즈 애플리케이션을 AWS로 마이그레이션하는 작업은 다양한 변수와 구성을 동반할 수 있습니다. 다음을 보장하라면 EC2 솔루션의 성능을 테스트해야 합니다.
+ 인스턴스 크기, 향상된 네트워킹, 테넌시(공유 또는 전용)를 포함한 인스턴스 유형이 올바르게 구성됩니다.
+ 인스턴스 토폴로지는 워크로드에 적합하며, 필요 시 전용 테넌시, 배치 그룹, 인스턴스 저장소 볼륨 및 베어 메탈과 같은 고성능 기능을 활용합니다.
**최신 버전의 EC2Launch v2 설치**
플릿 전체에 최신 개선 사항이 적용되도록 EC2Launch v2 에이전트를 최신 버전으로 업데이트하세요. 자세한 내용은 [EC2Launch v2 설치](ec2launch-v2-install.md) 섹션을 참조하세요.
혼합 플릿이 있거나 EC2Launch(Windows Server 2016 및 2019) 또는 EC2 Config(레거시 OS 전용) 에이전트를 계속 사용하고자 하는 경우 해당 에이전트를 최신 버전으로 업데이트하세요.
자동 업데이트는 다음 Windows Server 버전 및 시작 에이전트 조합에서 지원됩니다. **Amazon EC2 시작 에이전트**의 [SSM Quick Setup 호스트 관리](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html) 콘솔에서 자동 업데이트를 옵트인할 수 있습니다.
| Windows 버전 | EC2Launch v1 | EC2Launch v2 |
| --- | --- | --- |
| 2016 | ✓ | ✓ |
| 2019 | ✓ | ✓ |
| 2022 | | ✓ |
+ EC2Launch v2로 업데이트하는 방법에 대한 자세한 내용은 [최신 버전의 EC2Launch v2 설치](ec2launch-v2-install.md) 섹션을 참조하세요.
+ EC2Config를 수동으로 업데이트하는 방법에 대한 자세한 내용은 [최신 버전의 EC2Config 설치](UsingConfig_Install.md) 섹션을 참조하세요.
+ EC2Launch를 수동으로 업데이트하는 방법에 대한 자세한 내용은 [최신 버전의 EC2Launch 설치](ec2launch-download.md) 섹션을 참조하세요.
## 구성 관리
Amazon Machine Image(AMI)는 Amazon EC2 인스턴스에 대한 초기 구성을 제공합니다. 여기에는 Windows OS와 애플리케이션 및 보안 제어 같은 고객별 사용자 지정 옵션 등이 포함됩니다. 사용자 지정된 보안 구성 기준이 들어 있는 AMI 카탈로그를 생성하여 모든 Windows 인스턴스가 표준 보안 제어로 시작되도록 합니다. 보안 기준을 AMI에 베이킹하거나, EC2 인스턴스가 시작될 때 동적으로 부트스트래핑하거나, 하나의 제품으로 패키징하여 AWS Service Catalog 포트폴리오를 통해 균일하게 배포할 수 있습니다. AMI 보안 유지에 대한 자세한 내용은 [AMI 작성 모범 사례](https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html)를 참조하십시오.
각 Amazon EC2 인스턴스는 조직의 보안 표준을 준수해야 합니다. 필요 없는 Windows 역할 및 기능을 설치하지 말고, 악성 코드로부터 보호하고(바이러스 백신, 맬웨어 방지, 악용 완화) 호스트 무결성을 모니터링하고 침입 탐지를 수행하는 소프트웨어를 설치하세요. OS 보안 설정을 모니터링 및 유지 관리하고, 중요한 OS 파일의 무결성을 보호하며, 보안 기준에서 벗어나면 경보를 보내도록 보안 소프트웨어를 구성합니다. Microsoft, CIS(인터넷 보안 센터) 또는 NIST(미국 국립 표준 기술 연구소)에서 게시한 권장 보안 구성 벤치마크를 구현하는 것이 좋습니다. [SQL Server용 모범 사례 분석기](https://www.microsoft.com/en-us/download/details.aspx?id=29302) 등 특정 애플리케이션 서버를 위한 다른 Microsoft 도구를 사용하는 방법을 고려하십시오.
AWS 고객은 Amazon Inspector 평가를 실행하여 Amazon EC2 인스턴스에 배포된 애플리케이션의 보안 및 규정 준수를 개선할 수도 있습니다. Amazon Inspector는 애플리케이션의 취약성 또는 모범 사례와의 차이를 자동으로 평가하며, 공통의 보안 규정 준수 표준(예: PCI DSS)과 취약성 정의에 매핑된 수백 가지 규칙으로 구성된 기술 자료를 포함합니다. 원격 루트 로그인이 활성화되어 있는지 또는 취약한 소프트웨어 버전이 설치되어 있는지 확인하는 것이 대표적인 기본 제공 규칙입니다. 이러한 규칙은 AWS 보안 연구원이 정기적으로 업데이트합니다.
Windows 인스턴스를 보호할 때는 Active Directory 도메인 서비스를 구현하여 확장 가능하고 안전하며 관리하기 쉬운 인프라를 분산 위치에서 사용하는 것이 좋습니다. 또한 Amazon EC2 콘솔에서 인스턴스를 시작하거나 AWS CloudFormation 등의 Amazon EC2 프로비저닝 도구를 사용한 후 구성 드리프트가 발생하는 경우 Microsoft Windows PowerShell DSC와 같은 기본 OS 기능을 사용하여 구성 상태를 유지 관리하는 것이 좋습니다.
## 변경 관리
시작 시 Amazon EC2 인스턴스에 초기 보안 기준이 되고, 그 이후에는 진행 중인 Amazon EC2 변경 사항을 제어하여 가상 시스템의 보안을 유지합니다. AWS 리소스(예: 보안 그룹, 라우팅 테이블, 네트워크 ACL)뿐만 아니라 OS 및 애플리케이션 구성(예: Windows 또는 애플리케이션 패치 적용, 소프트웨어 업그레이드 또는 구성 파일 업데이트)에 대한 변경 사항을 승인하고 통합하는 변경 관리 프로세스를 설정합니다.
AWS는 AWS CloudTrail, AWS Config, CloudFormation, AWS Elastic Beanstalk 등의 AWS 리소스 변경 사항 관리를 위한 여러 가지 도구와 시스템 센터 운영 관리자 및 시스템 센터 가상 컴퓨터 관리자를 위한 관리 팩을 제공합니다. Microsoft는 매달 두 번째 화요일에(또는 필요에 따라) Windows 패치를 릴리스하고 AWS는 Microsoft가 패치를 릴리스한 후 5일 안에 AWS가 관리하는 모든 Windows AMI를 업데이트합니다. 따라서 모든 기본 AMI를 지속적으로 패치하고, CloudFormation 템플릿과 Auto Scaling 그룹 구성을 최신 AMI ID로 업데이트하고, 실행 중인 인스턴스 패치 관리를 자동화하는 도구를 구현해야 합니다.
Microsoft는 Windows OS 및 애플리케이션 변경 사항을 관리하기 위한 몇 가지 옵션을 제공합니다. 예를 들어, SCCM은 수명 주기 범위 전체에 걸쳐 환경을 수정할 수 있습니다. 비즈니스 요구 사항을 해결하고 변경 사항이 애플리케이션 SLA, 용량, 보안 및 재해 복구 절차에 미치는 영향을 제어하는 도구를 선택하세요. 수동 변경을 방지하고, 그 대신 자동화된 구성 관리 소프트웨어나 EC2 Run Command 또는 Windows PowerShell과 같은 명령줄 도구를 활용하여 반복 가능한 스크립트형 변경 프로세스를 구현하세요. 이러한 요구 사항을 지원하려면 Windows 인스턴스와의 모든 상호 작용에 향상된 로그 기능의 Bastion Host를 사용하여 모든 이벤트와 작업이 자동으로 기록되도록 하세요.
## Amazon EC2 Windows 인스턴스에 대한 감사 및 책임
AWS CloudTrail, AWS Config, AWS Config 규칙은 AWS 리소스 변경 감사를 위한 감사 및 변경 추적 기능을 제공합니다. 로컬 로그 파일을 중앙 로그 관리 시스템으로 전송하도록 Windows 이벤트 로그를 구성하여 보안 및 운영 동작 분석을 위해 로그 데이터를 보존합니다. Microsoft SCOM(시스템 센터 운영 관리자)은 Windows 인스턴스에 배포된 Microsoft 애플리케이션에 대한 정보를 집계하고 애플리케이션 역할 및 서비스를 기반으로 사전 구성된 규칙 및 사용자 지정 규칙 세트를 적용합니다. 시스템 센터 관리 팩은 SCOM을 기반으로 애플리케이션별 모니터링 및 구성 지침을 제공합니다. 이러한 [관리 팩](https://learn.microsoft.com/en-us/archive/technet-wiki/16174.microsoft-management-packs)은 Windows Server Active Directory, SharePoint Server 2013, Exchange Server 2013, Lync Server 2013, SQL Server 2014 등 다양한 서버와 기술을 지원합니다.
고객은 Microsoft 시스템 관리 도구 외에도 Amazon CloudWatch를 사용하여 인스턴스 CPU 사용률, 디스크 성능, 네트워크 I/O를 모니터링하고 호스트 및 인스턴스 상태 확인을 수행할 수 있습니다. EC2Config, EC2Launch, EC2Launch v2 시작 에이전트를 통해 Windows 인스턴스에 대한 고급 기능을 추가로 이용할 수 있습니다. 예를 들어 Windows 시스템, 보안, 애플리케이션 및 IIS(인터넷 정보 서비스) 로그를 CloudWatch Logs로 내보내고 이를 Amazon CloudWatch 메트릭 및 경보와 통합할 수 있습니다. 고객은 Windows 성능 카운터를 Amazon CloudWatch 사용자 지정 메트릭으로 내보내는 스크립트를 만들 수도 있습니다.
# Amazon EC2 키 페어 및 Amazon EC2 인스턴스
퍼블릭 키와 프라이빗 키로 구성되는 키 페어는 Amazon EC2 인스턴스에 연결할 때 자격 증명 입증에 사용하는 보안 자격 증명 집합입니다. Linux 인스턴스의 경우 프라이빗 키를 사용하여 인스턴스에 SSH로 안전하게 연결할 수 있습니다. Windows 인스턴스의 경우 인스턴스에 연결할 때 사용하는 관리자 암호를 복호화하려면 프라이빗 키가 필요합니다.
Amazon EC2는 퍼블릭 키를 인스턴스에 저장하며, 다음 다이어그램과 같이 프라이빗 키는 사용자가 저장합니다. 프라이빗 키를 소유하는 사람은 누구나 키 페어를 사용하는 인스턴스에 연결할 수 있으므로 보안 위치에 프라이빗 키를 저장해야 합니다.
![\[키 페어는 컴퓨터의 프라이빗 키와 인스턴스의 퍼블릭 키로 구성됩니다.\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/ec2-key-pair.png)
인스턴스를 시작할 때 [키 페어를 지정](ec2-instance-launch-parameters.md#liw-key-pair)하여 키 페어가 필요한 메서드를 사용하여 인스턴스에 연결할 수 있습니다. 보안 관리 방식에 따라 모든 인스턴스에 대해 동일한 키 페어를 지정하거나 다른 키 페어를 지정할 수 있습니다.
Linux 인스턴스의 경우 인스턴스가 처음 부팅될 때 시작 시 지정한 퍼블릭 키가 Linux 인스턴스에 `~/.ssh/authorized_keys` 내의 항목에 배치됩니다. SSH를 사용하여 Linux 인스턴스에 연결할 때 로그인하려면 퍼블릭 키에 해당하는 프라이빗 키를 지정해야 합니다.
EC2 인스턴스 연결에 대한 자세한 내용은 [EC2 인스턴스에 연결](connect.md) 섹션을 참조하세요.
**중요**
Amazon EC2에는 프라이빗 키의 사본이 보관되지 않으므로, 프라이빗 키를 분실하면 이를 복구할 방법이 전혀 없습니다. 그러나 분실된 프라이빗 키를 사용하는 인스턴스에 연결하는 방법은 여전히 있을 수 있습니다. 자세한 내용은 [프라이빗 키를 분실했습니다. 인스턴스에 연결하려면 어떻게 해야 하나요?](TroubleshootingInstancesConnecting.md#replacing-lost-key-pair) 섹션을 참조하세요.
키 페어의 대안으로 [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)를 사용하여 대화형 원클릭 브라우저 기반 셸 또는 AWS Command Line Interface(AWS CLI)로 인스턴스에 연결할 수 있습니다.
**Topics**
+ [Amazon EC2 인스턴스에 대한 키 페어 생성](create-key-pairs.md)
+ [키 페어 설명](describe-keys.md)
+ [키 페어 삭제](delete-key-pair.md)
+ [Linux 인스턴스에 대한 퍼블릭 키 추가 또는 바꾸기](replacing-key-pair.md)
+ [키 페어의 지문 확인](verify-keys.md)
# Amazon EC2 인스턴스에 대한 키 페어 생성
Amazon EC2를 사용하여 키 페어를 생성하거나 서드 파티 도구를 사용하여 키 페어를 생성한 후에 Amazon EC2로 가져올 수 있습니다.
Amazon EC2는 Linux 및 Windows 인스턴스에 대해 2048비트 SSH-2 RSA 키를 지원합니다. Amazon EC2는 Linux 인스턴스에 대한 ED25519 키도 지원합니다.
키 페어를 생성한 후 인스턴스에 연결하는 방법에 대한 지침은 [SSH를 사용하여 Linux 인스턴스에 연결](connect-to-linux-instance.md) 및 [RDP를 사용하여 Windows 인스턴스에 연결](connecting_to_windows_instance.md) 섹션을 참조하세요.
**Topics**
+ [Amazon EC2를 사용하여 키 페어 생성](#having-ec2-create-your-key-pair)
+ [AWS CloudFormation을 사용하여 키 페어 생성](#create-key-pair-cloudformation)
+ [서드 파티 도구를 사용하여 키 페어를 생성하고 Amazon EC2로 퍼블릭 키 가져오기](#how-to-generate-your-own-key-and-import-it-to-aws)
## Amazon EC2를 사용하여 키 페어 생성
Amazon EC2 사용하여 키 페어를 생성할 때 퍼블릭 키는 Amazon EC2에 저장되며 프라이빗 키는 사용자가 저장합니다.
리전당 최대 5,000개의 키 페어를 생성할 수 있습니다. 증가를 요청하려면 지원 케이스를 생성합니다. 자세한 내용을 알아보려면 [지원 사용 설명서](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)의 *지원 사례 만들기*를 참조하세요.
------
#### [ Console ]
**Amazon EC2를 사용하여 키 페어를 생성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 [**Network & Security**]에서 [**Key Pairs**]를 선택합니다.
1. **Create key pair(키 페어 생성)**를 선택합니다.
1. **이름**에 키 페어를 설명하는 이름을 입력합니다. Amazon EC2는 사용자가 키 이름으로 지정한 이름에 퍼블릭 키를 연결합니다. 키 이름에는 최대 255자의 ASCII 문자를 포함할 수 있습니다. 선행 또는 후행 공백을 포함할 수 없습니다.
1. 운영 체제에 적합한 키 페어 유형을 선택합니다.
(Linux 인스턴스)**키 페어 유형**에서 **RSA** 또는 **ED25519**를 선택합니다.
(Windows 인스턴스) **키 페어 유형**에서 **RSA**를 선택합니다. **ED25519** 키는 Windows 인스턴스에서 지원되지 않습니다.
1. **프라이빗 키 파일 형식(Private key file format)**에서 프라이빗 키를 저장할 형식을 선택합니다. OpenSSH에서 사용할 수 있는 형식으로 프라이빗 키를 저장하려면 **pem**을 선택합니다. PuTTY에서 사용할 수 있는 형식으로 프라이빗 키를 저장하려면 **ppk**를 선택합니다.
1. 퍼블릭 키에 태그를 추가하려면 **태그 추가(Add tag)**를 선택하고 해당 태그의 키와 값을 입력합니다. 각 태그에 대해 반복합니다.
1. **키 페어 생성(Create key pair)**를 선택합니다.
1. 브라우저에서 프라이빗 키 파일이 자동으로 다운로드됩니다. 기본 파일 이름은 키 페어의 이름으로 지정한 이름이며, 파일 이름 확장자는 선택한 파일 형식에 따라 결정됩니다. 안전한 장소에 프라이빗 키 파일을 저장합니다.
**중요**
이때가 사용자가 프라이빗 키 파일을 저장할 수 있는 유일한 기회입니다.
1. macOS 또는 Linux 컴퓨터에서 SSH 클라이언트를 사용하여 Linux 인스턴스에 연결할 계획이면 사용자만 프라이빗 키 파일을 읽을 수 있도록 다음 명령으로 해당 권한을 설정합니다.
```
chmod 400 key-pair-name.pem
```
이러한 권한을 설정하지 않으면 이 키 페어를 사용하여 인스턴스에 연결할 수 없습니다. 자세한 내용은 [오류: 보호되지 않는 프라이빗 키 파일](TroubleshootingInstancesConnecting.md#troubleshoot-unprotected-key) 섹션을 참조하세요.
------
#### [ AWS CLI ]
**Amazon EC2를 사용하여 키 페어를 생성하려면**
1. 다음과 같이 [https://docs.aws.amazon.com/cli/latest/reference/ec2/create-key-pair.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-key-pair.html) 명령을 사용하여 키 페어를 생성하고 프라이빗 키를 `.pem` 파일에 저장합니다. `--query` 옵션은 프라이빗 키 구성 요소를 출력에 인쇄합니다. `--output` 옵션은 지정된 파일에 프라이빗 키 구성 요소를 저장합니다. 확장명은 키 형식에 따라 `.pem` 또는 `.ppk`여야 합니다. 프라이빗 키 이름은 퍼블릭 키 이름과 다를 수 있지만, 사용상 편의를 위해 동일한 이름을 사용합니다.
```
aws ec2 create-key-pair \
--key-name my-key-pair \
--key-type rsa \
--key-format pem \
--query "KeyMaterial" \
--output text > my-key-pair.pem
```
1. macOS 또는 Linux 컴퓨터에서 SSH 클라이언트를 사용하여 Linux 인스턴스에 연결할 계획이면 사용자만 프라이빗 키 파일을 읽을 수 있도록 다음 명령으로 해당 권한을 설정합니다.
```
chmod 400 key-pair-name.pem
```
이러한 권한을 설정하지 않으면 이 키 페어를 사용하여 인스턴스에 연결할 수 없습니다. 자세한 내용은 [오류: 보호되지 않는 프라이빗 키 파일](TroubleshootingInstancesConnecting.md#troubleshoot-unprotected-key) 섹션을 참조하세요.
------
#### [ PowerShell ]
**Amazon EC2를 사용하여 키 페어를 생성하려면**
다음과 같이 [https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2KeyPair.html) cmdlet을 사용하여 키를 생성하고 생성한 키를 `.pem` 또는 `.ppk` 파일에 저장합니다. **Out-File** cmdlet은 특정 확장자가 있는 파일에 프라이빗 키 구성 요소를 저장합니다. 확장명은 키 형식에 따라 `.pem` 또는 `.ppk`여야 합니다. 프라이빗 키 이름은 퍼블릭 키 이름과 다를 수 있지만, 사용상 편의를 위해 동일한 이름을 사용합니다.
```
(New-EC2KeyPair `
-KeyName "my-key-pair" `
-KeyType "rsa" `
-KeyFormat "pem").KeyMaterial | Out-File -Encoding ascii -FilePath C:\path\my-key-pair.pem
```
------
## AWS CloudFormation을 사용하여 키 페어 생성
CloudFormation을 사용하여 새 키 페어를 생성하면 프라이빗 키가 AWS Systems Manager 파라미터 스토어에 저장됩니다. 다음은 파라미터 이름의 형식입니다.
```
/ec2/keypair/key_pair_id
```
자세한 내용을 알아보려면 *AWS Systems Manager 사용 설명서*의 [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)를 참조하세요.
**CloudFormation을 사용하여 키 페어를 생성하려면**
1. 템플릿에서 [AWS::EC2::KeyPair](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-keypair.html) 리소스를 사용합니다.
```
Resources:
NewKeyPair:
Type: 'AWS::EC2::KeyPair'
Properties:
KeyName: new-key-pair
```
1. 다음과 같이 [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) 명령을 사용하여 키 페어의 ID를 가져옵니다.
```
aws ec2 describe-key-pairs --filters Name=key-name,Values=new-key-pair --query KeyPairs[*].KeyPairId --output text
```
다음은 예제 출력입니다.
```
key-05abb699beEXAMPLE
```
1. 다음과 같이 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-parameter.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-parameter.html) 명령을 사용하여 키의 파라미터를 가져오고 키 구성 요소를 `.pem` 파일에 저장합니다.
```
aws ssm get-parameter --name /ec2/keypair/key-05abb699beEXAMPLE --with-decryption --query Parameter.Value --output text > new-key-pair.pem
```
**필수 IAM 권한**
CloudFormation이 사용자를 대신하여 파라미터 스토어 파라미터를 관리할 수 있도록 하려면 CloudFormation 또는 사용자가 수임하는 IAM 역할에 다음 권한이 있어야 합니다.
+ `ssm:PutParameter` - 이 프라이빗 키 구성 요소에 대한 파라미터를 생성할 수 있는 권한을 부여합니다.
+ `ssm:DeleteParameter` - 프라이빗 키 구성 요소를 저장하는 데 사용된 파라미터를 삭제할 권한을 부여합니다. 이 권한은 CloudFormation에서 키 페어를 가져왔거나 생성했는지에 관계없이 필요합니다.
CloudFormation은 키 페어를 생성할 때만 파라미터를 생성하고 키 페어를 가져올 때는 파라미터를 생성하지 않지만, 스택에 의해 생성되거나 가져온 키 페어를 삭제할 때 CloudFormation은 권한 확인을 수행하여 사용자에게 파라미터를 삭제할 권한이 있는지 확인합니다. CloudFormation은 사용자 계정의 파라미터와 일치하지 않는 조작된 파라미터 이름을 사용하여 필요한 권한을 테스트합니다. 따라서 `AccessDeniedException` 오류 메시지에 조작된 파라미터 이름이 표시될 수 있습니다.
## 서드 파티 도구를 사용하여 키 페어를 생성하고 Amazon EC2로 퍼블릭 키 가져오기
Amazon EC2를 사용하여 키 페어를 생성하는 대신에 서드 파티 도구를 사용하여 RSA 또는 ED25519 키 페어를 생성한 다음에 Amazon EC2로 퍼블릭 키를 가져올 수 있습니다.
**키 페어에 대한 요구 사항**
+ 지원되는 유형:
+ (Linux 및 Windows) RSA
+ (Linux만 해당) ED25519
**참고**
ED25519 키는 Windows 인스턴스에서 지원되지 않습니다.
+ Amazon EC2는 DSA 키를 허용하지 않습니다.
+ 지원되는 형식:
+ OpenSSH 퍼블릭 키 형식(Linux의 경우 `~/.ssh/authorized_keys`의 형식)
+ (Linux만 해당) EC2 Instance Connect API를 사용하는 동안 SSH를 사용하여 연결하는 경우 SSH2 형식도 지원됩니다.
+ SSH 프라이빗 키 파일 형식은 PEM 또는 PPK이어야 함
+ (RSA만 해당) Base64 인코딩 DER 형식
+ (RSA만 해당) [RFC 4716](https://www.ietf.org/rfc/rfc4716.txt)에 지정된 SSH 퍼블릭 키 파일 형식
+ 지원되는 길이:
+ 1024, 2048, 4096.
+ (Linux만 해당) EC2 Instance Connect API를 사용하는 동안 SSH를 사용하여 연결하는 경우 지원되는 길이는 2048 및 4096입니다.
**타사 도구를 이용한 키 페어 만들기**
1. 타사 도구로 원하는 키 페어를 생성합니다. 예를 들어 **ssh-keygen**(표준 OpenSSH 설치 시 제공되는 도구)을 사용할 수 있습니다. 또는 Java, Ruby, Python 등 각종 프로그래밍 언어에서 제공하는 표준 라이브러리를 사용하여 키 페어를 생성해도 됩니다.
**중요**
프라이빗 키는 PEM 또는 PPK 형식이어야 합니다. 예를 들어 `ssh-keygen -m PEM`을 사용하여 PEM 형식으로 OpenSSH 키를 생성합니다.
1. 퍼블릭 키는 로컬 파일에 저장합니다. 예: `~/.ssh/my-key-pair.pub`(Windows, macOS) 또는 `C:\keys\my-key-pair.pub`(Windows). 이 파일의 파일 이름 확장자는 중요하지 않습니다.
1. 프라이빗 키를 확장자가 `.pem` 또는 `.ppk`인 로컬 파일에 저장합니다. 예: `~/.ssh/my-key-pair.pem` `~/.ssh/my-key-pair.ppk`(Linux, macOS) 또는 `C:\keys\my-key-pair.pem` `C:\keys\my-key-pair.ppk`(Windows). 파일 확장자는 인스턴스에 연결하는 데 사용하는 도구에 따라 특정 파일 형식이 필요하므로 중요합니다. OpenSSH에는 `.pem` 파일이 필요한 반면, PuTTY에는 `.ppk` 파일이 필요합니다.
**중요**
프라이빗 키 파일을 안전한 장소에 저장합니다. 인스턴스를 시작할 때 퍼블릭 키의 이름을 제공하고, 인스턴스에 연결할 때마다 해당 프라이빗 키를 제공해야 합니다.
키 페어를 만든 후 다음 방법 중 하나를 사용하여 퍼블릭 키를 Amazon EC2로 가져옵니다.
------
#### [ Console ]
**Amazon EC2로 퍼블릭 키를 가져오려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 [**Key Pairs**]를 선택합니다.
1. **키 페어 가져오기**를 선택합니다.
1. [**이름(Name)**]에 퍼블릭 키를 설명하는 이름을 입력합니다. 이름에는 최대 255자의 ASCII 문자를 포함할 수 있습니다. 선행 또는 후행 공백을 포함할 수 없습니다.
**참고**
EC2 콘솔에서 인스턴스에 연결할 때 콘솔은 프라이빗 키 파일의 이름으로 이 이름을 제안합니다.
1. **찾아보기**를 선택하여 퍼블릭 키를 탐색하고 선택하거나 퍼블릭 키의 내용을 **퍼블릭 키 내용** 필드에 붙여 넣습니다.
1. **키 페어 가져오기**를 선택합니다.
1. 가져온 퍼블릭 키가 키 페어 목록에 나타나는지 확인합니다.
------
#### [ AWS CLI ]
**Amazon EC2로 퍼블릭 키를 가져오려면**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/import-key-pair.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/import-key-pair.html) 명령을 사용합니다.
```
aws ec2 import-key-pair \
--key-name my-key-pair \
--public-key-material fileb://path/my-key-pair.pub
```
**키 페어를 성공적으로 가져왔는지 확인하려면**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) 명령을 사용합니다.
```
aws ec2 describe-key-pairs --key-names my-key-pair
```
------
#### [ PowerShell ]
**Amazon EC2로 퍼블릭 키를 가져오려면**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Import-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Import-EC2KeyPair.html) cmdlet을 사용하세요.
```
$publickey=[Io.File]::ReadAllText("C:\Users\TestUser\.ssh\id_rsa.pub")
Import-EC2KeyPair `
-KeyName my-key-pair `
-PublicKey $publickey
```
**키 페어를 성공적으로 가져왔는지 확인하려면**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html) cmdlet을 사용하세요.
```
Get-EC2KeyPair -KeyName my-key-pair
```
------
# 키 페어 설명
Amazon EC2에 저장된 키 페어를 설명할 수 있습니다. 퍼블릭 키 구성 요소를 검색하고 시작 시 지정되었던 공개 키를 식별할 수도 있습니다.
**Topics**
+ [키 페어 설명](#describe-public-key)
+ [퍼블릭 키 구성 요소 검색](#retrieving-the-public-key)
+ [시작 시 지정된 퍼블릭 키 식별](#identify-key-pair-specified-at-launch)
## 키 페어 설명
Amazon EC2 저장된 퍼블릭 키에 대한 정보를 볼 수 있으며, 이러한 정보에는 퍼블릭 키 이름, ID, 키 유형, 지문, 퍼블릭 키 구성 요소, 키가 Amazon EC2에서 생성된 날짜 및 시간(UTC 표준 시간대. 키가 서드 파티 도구에 의해 생성된 경우에는 키를 Amazon EC2로 가져온 날짜 및 시간), 퍼블릭 키와 연결된 모든 태그가 포함됩니다.
------
#### [ Console ]
**키 페어에 대한 정보를 보는 방법**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 왼쪽 탐색에서 **키 페어(Key Pairs)**를 선택합니다.
1. **키 페어(Key pairs)** 테이블에서 각 퍼블릭 키에 대한 정보를 볼 수 있습니다.
![\[키 페어 테이블입니다.\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/key-pairs-describe-console.png)
1. 퍼블릭 키의 태그를 보려면 키 옆에 있는 확인란을 선택한 다음 **작업**, **태그 관리**를 선택합니다.
------
#### [ AWS CLI ]
**키 페어에 대한 정보를 보는 방법**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) 명령을 사용합니다.
```
aws ec2 describe-key-pairs --key-names key-pair-name
```
------
#### [ PowerShell ]
**키 페어에 대한 정보를 보는 방법**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html) cmdlet을 사용하세요.
```
Get-EC2KeyPair -KeyName key-pair-name
```
------
## 퍼블릭 키 구성 요소 검색
키 페어에 대한 퍼블릭 키 구성 요소를 가져올 수 있습니다. 다음은 퍼블릭 키 예제입니다. 참고로, 가독성을 위해 줄 바꿈이 추가되어 있습니다.
```
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
```
------
#### [ Private key ]
**ssh-keygen을 사용하여 퍼블릭 키 구성 요소를 검색하는 방법(Linux)**
로컬 Linux 또는 macOS 컴퓨터에서 **ssh-keygen** 명령을 사용합니다. 프라이빗 키(`.pem` 파일)를 다운로드한 경로를 지정합니다.
```
ssh-keygen -y -f /path_to_key_pair/my-key-pair.pem
```
이 **ssh-keygen** 명령이 작동하지 않으면 다음 **chmod** 명령을 실행하여 프라이빗 키 파일에 필요한 권한이 있는지 확인합니다.
```
chmod 400 key-pair-name.pem
```
**PuTTYgen을 사용하여 퍼블릭 키 구성 요소를 검색하는 방법(Windows)**
로컬 Windows 컴퓨터에서 PuTTYgen을 시작합니다. **로드(Load)**를 선택합니다. `.ppk` 또는 `.pem` 프라이빗 키 파일을 선택합니다. PuTTYgen의 **OpenSSH authorized\$1keys 파일에 붙여 넣기 위한 퍼블릭 키** 아래에 퍼블릭 키가 표시됩니다. 또한 **퍼블릭 키 저장**을 선택하고, 파일 이름을 지정한 다음, 파일을 저장하고, 파일을 열어서 퍼블릭 키를 볼 수도 있습니다.
------
#### [ AWS CLI ]
**퍼블릭 키 구성 요소를 검색하는 방법**
다음 [describe-key-pairs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) 명령을 사용하고 `--include-public-key` 옵션을 지정합니다.
```
aws ec2 describe-key-pairs \
--key-names key-pair-name \
--include-public-key \
--query "KeyPairs[].PublicKey"
```
------
#### [ PowerShell ]
**퍼블릭 키 구성 요소를 검색하는 방법**
[Get-EC2KeyPair](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html) cmdlet을 사용합니다.
```
(Get-EC2KeyPair -KeyName key-pair-name -IncludePublicKey $true).PublicKey
```
------
#### [ IMDSv2 ]
**Linux**
Linux 인스턴스에서 다음과 같은 명령을 실행합니다.
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
**Windows**
Windows 인스턴스에서 다음과 같은 cmdlet을 실행합니다.
```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
------
#### [ IMDSv1 ]
**Linux**
Linux 인스턴스에서 다음 명령을 실행합니다.
```
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
**Windows**
Windows 인스턴스에서 다음 cmdlet을 실행합니다.
```
Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
------
## 시작 시 지정된 퍼블릭 키 식별
인스턴스를 시작할 때 퍼블릭 키를 지정하면 인스턴스를 통해 퍼블릭 키 이름이 기록됩니다. 인스턴스에 대해 보고된 퍼블릭 키 이름은 인스턴스의 퍼블릭 키를 변경하거나 퍼블릭 키를 추가하더라도 변경되지 않습니다.
------
#### [ Console ]
**시작 시 지정된 퍼블릭 키를 식별하는 방법**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 인스턴스를 선택합니다.
1. **세부 정보** 탭의 **인스턴스 세부 정보**에서 **시작 시 할당된 키 페어**를 찾습니다.
------
#### [ AWS CLI ]
**시작 시 지정된 퍼블릭 키를 식별하는 방법**
다음 [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) 명령을 사용합니다.
```
aws ec2 describe-instances \
--instance-id i-1234567890abcdef0 \
--query "Reservations[].Instances[].KeyName" \
--output text
```
다음은 예제 출력입니다.
```
key-pair-name
```
------
#### [ PowerShell ]
**시작 시 지정된 퍼블릭 키를 식별하는 방법**
[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) cmdlet을 사용합니다.
```
(Get-EC2Instance -InstanceId i-1234567890abcdef0).Instances | Select KeyName
```
다음은 예제 출력입니다.
```
KeyName
-------
key-pair-name
```
------
# 키 페어 삭제
키 페어를 삭제할 수 있습니다. 그러면 Amazon EC2에 저장된 퍼블릭 키가 제거됩니다. 퍼블릭 키를 삭제해도 대응하는 프라이빗 키는 삭제되지 않습니다.
다음과 같은 방법을 사용하여 퍼블릭 키를 삭제하면 키 페어를 [생성](create-key-pairs.md#having-ec2-create-your-key-pair)하거나 [가져올](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws) 때 Amazon EC2에 저장한 퍼블릭 키만 삭제됩니다. 퍼블릭 키를 삭제하면 퍼블릭 키를 추가한 인스턴스의 퍼블릭 키는 인스턴스를 시작했을 때 또는 나중에 제거되지 않습니다. 로컬 컴퓨터의 프라이빗 키도 삭제되지 않습니다. 프라이빗 키(`.pem`) 파일이 그대로 있으면 Amazon EC2에서 삭제한 퍼블릭 키를 사용하여 시작한 인스턴스에 계속 연결할 수 있습니다.
**중요**
Auto Scaling 그룹을 사용 중인 경우(예: Elastic Beanstalk 환경에서) 연결된 시작 템플릿 또는 시작 구성에 삭제하려는 퍼블릭 키가 지정되지 않았는지 확인하세요. Amazon EC2 Auto Scaling은 비정상 인스턴스가 감지될 경우 대체 인스턴스를 시작합니다. 그러나 퍼블릭 키를 찾을 수 없으면 인스턴스가 시작되지 않습니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*에서 [시작 템플릿](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)을 참조하세요.
------
#### [ Console ]
**Amazon EC2의 퍼블릭 키를 삭제하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 [**Key Pairs**]를 선택합니다.
1. 삭제할 키 페어를 선택하고 **Actions**(작업), **Delete**(삭제)를 차례로 선택합니다.
1. 확인 필드에 `Delete`를 입력한 다음 **삭제**를 선택합니다.
------
#### [ AWS CLI ]
**Amazon EC2의 퍼블릭 키를 삭제하려면**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-key-pair.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-key-pair.html) 명령을 사용합니다.
```
aws ec2 delete-key-pair --key-name my-key-pair
```
------
#### [ PowerShell ]
**Amazon EC2의 퍼블릭 키를 삭제하려면**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2KeyPair.html) cmdlet을 사용하세요.
```
Remove-EC2KeyPair -KeyName my-key-pair
```
------
# Linux 인스턴스에 대한 퍼블릭 키 추가 또는 바꾸기
| |
| --- |
| 프라이빗 키를 분실한 경우 키 페어를 사용하는 모든 인스턴스에 대한 액세스 권한도 사라집니다. 시작 시 지정한 키 페어와 다른 키 페어를 사용하여 인스턴스에 연결하는 방법에 대한 자세한 내용은 [프라이빗 키를 분실했습니다](TroubleshootingInstancesConnecting.md#replacing-lost-key-pair)를 참조하세요. |
인스턴스를 시작할 때 [키 페어를 지정](ec2-instance-launch-parameters.md#liw-key-pair)할 수 있습니다. 시작 시 키 페어를 지정하면 인스턴스가 처음 부팅될 때 퍼블릭 키 구성 요소가 `~/.ssh/authorized_keys` 내 항목의 Linux 인스턴스에 배치됩니다. SSH를 사용하여 Linux 인스턴스에 처음 연결할 때, 기본 사용자와 Linux 인스턴스에 저장된 퍼블릭 키에 대응하는 프라이빗 키를 지정합니다.
인스턴스에 연결한 후, 인스턴스에 새 퍼블릭 키를 추가하거나 인스턴스의 퍼블릭 키를 교체(기존 퍼블릭 키를 삭제하고 새 키를 추가)하여 인스턴스의 기본 시스템 계정에 액세스하는 데 사용되는 키 쌍을 변경할 수 있습니다. 인스턴스에서 모든 퍼블릭 키를 제거할 수도 있습니다.
다음과 같은 이유로 키 페어를 추가하거나 바꿀 수 있습니다.
+ 조직 내 사용자가 별도의 키 페어를 사용하여 시스템 사용자에게 액세스해야 하는 경우 인스턴스에 퍼블릭 키 페어를 추가할 수 있습니다.
+ 프라이빗 키(`.pem` 파일)의 복사본을 보유하고 있는 누군가의 인스턴스 연결을 차단하려는 경우(예: 퇴사자) 인스턴스의 퍼블릭 키를 삭제하고 새 키로 교체할 수 있습니다.
+ 인스턴스에서 Linux AMI 생성하는 경우 퍼블릭 키 구성 요소가 인스턴스에서 AMI로 복사됩니다. AMI에서 인스턴스를 시작하는 경우 새 인스턴스에 원본 인스턴스의 키 페어가 포함됩니다. 프라이빗 키가 있는 사용자가 새 인스턴스에 연결할 수 없도록 AMI를 생성하기 *전에* 원본 인스턴스에서 퍼블릭 키를 제거할 수 있습니다.
다음 절차를 사용하여 기본 사용자(예: `ec2-user`)의 키 페어를 수정합니다. 인스턴스에 사용자를 추가하는 방법에 대한 자세한 내용은 인스턴스에 대한 운영 체제 설명서를 참조하세요.
**키 페어를 추가 또는 교체하는 방법**
1. [Amazon EC2 콘솔](create-key-pairs.md#having-ec2-create-your-key-pair) 또는 [타사 도구](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws)를 사용하여 새 키 페어를 만듭니다.
1. 새 키 페어에서 퍼블릭 키를 검색합니다. 자세한 내용은 [퍼블릭 키 구성 요소 검색](describe-keys.md#retrieving-the-public-key) 섹션을 참조하세요.
1. [인스턴스에 연결합니다](connect-to-linux-instance.md).
1. 해당 인스턴스에서 원하는 텍스트 편집기를 사용하여 `.ssh/authorized_keys` 파일을 엽니다. 새 키 쌍의 퍼블릭 키 정보를 기존 퍼블릭 키 정보 아래에 붙여넣은 후 파일을 저장합니다.
1. 인스턴스에서 연결을 해제합니다. 새 키 쌍의 프라이빗 키 파일을 사용하여 인스턴스에 연결할 수 있는지 테스트하세요.
1. 오토 스케일링, EC2 플릿 또는 시작 템플릿을 사용하여 인스턴스를 시작하는 경우 교체하려는 키 페어가 시작 템플릿 또는 시작 구성에 지정되어 있는지 확인합니다. 그렇지 않으면 인스턴스를 시작하지 못합니다.
1. (선택 사항) 기존 키 페어를 교체하는 경우 인스턴스에 연결하고 `.ssh/authorized_keys` 파일에서 원래 키 페어의 퍼블릭 키 정보를 삭제합니다.
**인스턴스에서 퍼블릭 키를 제거하려면**
1. [인스턴스에 연결합니다](connect-to-linux-instance.md).
1. 원하는 텍스트 편집기를 사용하여 인스턴스에서 `.ssh/authorized_keys` 파일을 엽니다. 퍼블릭 키 정보를 삭제한 후 파일을 저장합니다.
**주의**
인스턴스에서 모든 퍼블릭 키를 제거하고 인스턴스 연결을 끊으면, 대체 로그인 방법이 설정되어 있는 경우를 제외하고 해당 인스턴스에 다시 연결할 수 없습니다.
# 키 페어의 지문 확인
키 페어의 지문을 확인하려면 Amazon EC2 콘솔의 **키 페어** 페이지에 표시되거나 [describe-key-pairs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) 명령으로 반환된 지문을 로컬 컴퓨터에서 프라이빗 키를 사용하여 생성한 지문과 비교하세요. 이 지문들은 일치해야 합니다.
Amazon EC2가 지문을 계산할 때 Amazon EC2는 `=` 문자를 사용하여 지문에 패딩을 추가할 수 있습니다. **ssh-keygen** 등의 다른 도구는 이 패딩을 생략할 수 있습니다.
키 페어의 지문이 아닌 Linux EC2 인스턴스의 지문을 확인하려고 하는 경우에는 [인스턴스 지문 가져오기](connection-prereqs-general.md#connection-prereqs-fingerprint)를 참조하세요.
## 지문 계산 방법
Amazon EC2는 서로 다른 해시 함수를 사용하여 RSA 및 ED25519 키 페어의 지문을 계산합니다. 또한 RSA 키 페어의 경우 Amazon EC2는 키 페어가 Amazon EC2에서 생성되었는지 아니면 Amazon EC2로 가져왔는지에 따라 서로 다른 해시 함수를 사용하여 지문을 다르게 계산합니다.
다음 표에는 Amazon EC2에서 생성하여 Amazon EC2로 가져오는 RSA 및 ED25519 키 페어의 지문을 계산하는 데 사용되는 해시 함수가 나열되어 있습니다.
**(Linux 인스턴스) 지문을 계산하는 데 사용되는 해시 함수**
| 키 페어 소스 | RSA 키 페어(Windows 및 Linux) | ED25519 키 페어(Linux) |
| --- | --- | --- |
| Amazon EC2에서 생성 | SHA-1 | SHA-256 |
| Amazon EC2로 가져오기 | MD5¹ | SHA-256 |
Amazon EC2로 퍼블릭 RSA 키를 가져오면 지문은 MD5 해시 함수를 통해 계산됩니다. 이 방식은 서드 파티 도구를 사용했든지 Amazon EC2를 사용하여 생성한 기존 프라이빗 키에서 새 퍼블릭 키를 생성했든지, 키 페어를 생성한 방법과 상관없이 동일합니다.
## 서로 다른 리전에서 동일한 키 페어를 사용하는 경우
동일한 키 페어를 사용하여 다른 AWS 리전의 인스턴스에 연결하려는 경우, 퍼블릭 키를 사용할 모든 리전으로 가져와야 합니다. Amazon EC2를 사용하여 키 페어를 생성하는 경우 퍼블릭 키를 다른 리전으로 가져올 수 있도록 [퍼블릭 키 구성 요소 검색](describe-keys.md#retrieving-the-public-key)할 수 있습니다.
**참고**
Amazon EC2를 사용하여 RSA 키 페어를 생성한 다음 Amazon EC2 프라이빗 키에서 퍼블릭 키를 생성하는 경우, 가져온 퍼블릭 키의 지문은 원래 퍼블릭 키와 다릅니다. 이유는 Amazon EC2를 사용하여 생성된 원래 RSA 키의 지문이 SHA-1 해시 함수를 사용하여 계산되고, 가져온 RSA 키의 지문은 MD5 해시 함수를 사용하여 계산되기 때문입니다.
ED25519 키 페어의 경우 지문은 동일한 SHA-256 해시 함수가 지문 계산에 사용되기 때문에 Amazon EC2에서 생성했는지 또는 Amazon EC2로 가져왔는지와 관계없이 동일합니다.
## 프라이빗 키에서 지문 생성
다음 명령 중 하나를 사용하여 로컬 머신의 프라이빗 키에서 지문을 생성합니다.
Windows 로컬 컴퓨터를 사용 중인 경우 Linux용 Windows 하위 시스템(WSL)을 사용하여 다음 명령을 실행할 수 있습니다. [WSL을 사용하여 Windows에 Linux를 설치하는 방법](https://learn.microsoft.com/en-us/windows/wsl/install)의 지침을 이용하여 WSL과 Linux 배포를 설치하세요. 지침 속 사례는 Linux의 Ubuntu 배포를 설치하는 것이지만, 다른 배포의 설치에도 활용할 수 있습니다. 변경 사항을 적용하려면 컴퓨터를 다시 시작하라는 안내가 표시됩니다.
+ **Amazon EC2를 사용하여 키 페어를 만든 경우**
다음 예제와 같이 OpenSSL 도구를 사용하여 지문을 생성합니다.
RSA 키 페어의 경우:
```
openssl pkcs8 -in path_to_private_key -inform PEM -outform DER -topk8 -nocrypt | openssl sha1 -c
```
(Linux 인스턴스) ED25519 키 페어의 경우:
```
ssh-keygen -l -f path_to_private_key
```
+ **(RSA 키 페어만 해당) 퍼블릭 키를 Amazon EC2로 가져온 경우**
예를 들어, 타사 도구를 사용하거나 Amazon EC2로 생성된 기존 프라이빗 키에서 새 퍼블릭 키를 생성하여 키 페어를 생성한 방법에 관계없이 이 절차를 따를 수 있습니다.
다음 예제와 같이 OpenSSL 도구를 사용하여 지문을 생성합니다.
```
openssl rsa -in path_to_private_key -pubout -outform DER | openssl md5 -c
```
+ **OpenSSH 7.8 이상을 사용하여 OpenSSH 키 페어를 생성하고 Amazon EC2로 퍼블릭 키를 가져온 경우**
다음 예제와 같이 **ssh-keygen**을 사용하여 지문을 생성합니다.
RSA 키 페어의 경우:
```
ssh-keygen -ef path_to_private_key -m PEM | openssl rsa -RSAPublicKey_in -outform DER | openssl md5 -c
```
(Linux 인스턴스) ED25519 키 페어의 경우:
```
ssh-keygen -l -f path_to_private_key
```
# EC2 인스턴스에 대한 Amazon EC2 보안 그룹
*보안 그룹*은 EC2 인스턴스에 대한 수신 및 발신 트래픽을 제어하는 가상 방화벽 역할을 합니다. 인바운드 규칙은 인스턴스로 들어오는 트래픽을 제어하고 아웃바운드 규칙은 인스턴스에서 나가는 트래픽을 제어합니다. 인스턴스를 시작할 때 하나 이상의 보안 그룹을 지정할 수 있습니다. 보안 그룹을 지정하지 않을 경우 Amazon EC2에서 VPC에 대한 기본 보안 그룹이 사용됩니다. 인스턴스를 시작한 이후에는 해당 보안 그룹을 변경할 수 없습니다.
보안은 AWS와 사용자의 공동 책임입니다. 자세한 내용은 [Amazon EC2의 보안](ec2-security.md) 섹션을 참조하세요. AWS에서는 인스턴스의 보안을 유지하기 위한 도구 중 하나로 보안 그룹을 제공하며, 사용자는 보안 요구 사항에 맞게 보안 그룹을 구성해야 합니다. 보안 그룹으로 완전히 충족되지 않는 요구 사항이 있는 경우 보안 그룹을 사용하면서 인스턴스에 대한 자체 방화벽을 유지합니다.
**가격 책정**
보안 그룹을 사용해도 추가 요금이 부과되지 않습니다.
**Topics**
+ [개요](#security-group-basics)
+ [Amazon EC2 인스턴스에 대한 보안 그룹을 생성합니다.](creating-security-group.md)
+ [Amazon EC2 인스턴스에 대한 보안 그룹 변경](changing-security-group.md)
+ [Amazon EC2 보안 그룹 삭제](deleting-security-group.md)
+ [Amazon EC2 보안 그룹 연결 추적](security-group-connection-tracking.md)
+ [다양한 사용 사례에 대한 보안 그룹 규칙](security-group-rules-reference.md)
## 개요
각 인스턴스를 여러 보안 그룹과 연결하고, 각 보안 그룹을 여러 인스턴스와 연결할 수 있습니다. 연결된 인스턴스와 트래픽을 주고받을 수 있게 하는 규칙을 각 보안 그룹에 추가합니다. 언제든지 보안 그룹에 대한 규칙을 수정할 수 있습니다. 새 규칙 및 수정된 규칙은 보안 그룹에 연결된 모든 인스턴스에 자동으로 적용됩니다. Amazon EC2는 트래픽이 인스턴스에 도달하도록 허용할지 여부를 결정할 때 인스턴스와 연결된 모든 보안 그룹에서 모든 규칙을 평가합니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [보안 그룹 규칙](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)을 참조하세요.
다음 다이어그램은 서브넷, 인터넷 게이트웨이 및 보안 그룹이 있는 VPC를 보여줍니다. 서브넷에 EC2 인스턴스가 포함되어 있습니다. 보안 그룹은 인스턴스에 연결됩니다. 인스턴스에 연결되는 트래픽은 보안 그룹 규칙에서 허용되는 트래픽이 유일합니다. 예를 들어 네트워크에서 SSH 트래픽을 허용하는 규칙이 보안 그룹에 포함된 경우 SSH를 사용하여 컴퓨터에서 인스턴스로 연결할 수 있습니다. 연결된 리소스에서 모든 트래픽을 허용하는 규칙이 보안 그룹에 포함된 경우 각 인스턴스는 다른 인스턴스에서 전송된 모든 트래픽을 수신할 수 있습니다.
![\[보안 그룹이 있는 VPC. 서브넷의 EC2 인스턴스는 보안 그룹에 연결되어 있습니다.\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/ec2-security-groups.png)
보안 그룹은 상태가 저장됩니다. 사용자가 인스턴스에서 요청을 전송하면 해당 요청의 응답 트래픽은 인바운드 보안 그룹 규칙에 관계없이 인바운드 흐름이 허용됩니다. 또한 아웃바운드 규칙과 무관하게 허용된 인바운드 트래픽에 대한 반응으로 외부로 나가는 흐름이 수행됩니다. 자세한 내용은 [연결 추적](security-group-connection-tracking.md) 섹션을 참조하세요.
# Amazon EC2 인스턴스에 대한 보안 그룹을 생성합니다.
보안 그룹은 연결된 인스턴스에 대한 방화벽 역할을 하여 인스턴스 수준에서 인바운드 트래픽과 아웃바운드 트래픽을 모두 제어합니다. SSH(Linux 인스턴스) 또는 RDP(Windows 인스턴스)를 사용하여 인스턴스에 연결할 수 있도록 규칙을 보안 그룹에 추가할 수 있습니다. 웹 서버로 향하는 HTTP 및 HTTPS 트래픽과 같은 클라이언트 트래픽을 허용하는 규칙을 추가할 수도 있습니다.
인스턴스를 시작할 때 인스턴스에 보안 그룹을 연결할 수 있습니다. 보안 그룹에서 연결된 규칙을 추가하거나 제거하면 해당 보안 그룹을 연결한 모든 인스턴스에 변경 내용이 자동으로 적용됩니다.
인스턴스를 시작한 이후에는 추가 보안 그룹을 연결할 수 있습니다. 자세한 내용은 [Amazon EC2 인스턴스에 대한 보안 그룹 변경](changing-security-group.md) 섹션을 참조하세요.
보안 그룹을 생성할 때 또는 나중에 인바운드 및 아웃바운드 보안 그룹 규칙을 추가할 수 있습니다. 자세한 내용은 [보안 그룹 규칙 구성](changing-security-group.md#add-remove-security-group-rules) 섹션을 참조하세요. 보안 그룹에 추가할 수 있는 규칙의 예제는 [다양한 사용 사례에 대한 보안 그룹 규칙](security-group-rules-reference.md)의 내용을 참조하세요.
**고려 사항**
+ 새 보안 그룹에는 리소스에서 나가는 모든 트래픽을 허용하는 아웃바운드 규칙만 적용됩니다. 인바운드 트래픽을 사용하거나 아웃바운드 트래픽을 제한하려면 규칙을 추가해야 합니다.
+ 인스턴스에 대한 SSH 또는 RDP 액세스를 허용하는 규칙의 원본을 구성할 때는 모든 위치에서의 액세스를 허용하지 마세요.인터넷의 모든 IP 주소에서 인스턴스에 액세스할 수 있게 됩니다. 테스트 환경에서 잠시 사용하는 것은 괜찮지만 프로덕션 환경에서는 안전하지 않습니다.
+ 특정 포트에 대한 규칙이 여러 개 있는 경우 Amazon EC2는 최대 허용 규칙을 적용합니다. 예를 들어 IP 주소 203.0.113.1에서 TCP 포트 22(SSH)에 액세스할 수 있도록 허용하는 규칙과 어디서나 TCP 포트 22에 액세스할 수 있도록 허용하는 또 다른 규칙이 있는 경우 모든 사람이 TCP 포트 22에 액세스할 수 있습니다.
+ 인스턴스에 여러 보안 그룹을 연결할 수 있습니다. 따라서 한 인스턴스에 수백 개의 규칙이 적용될 수 있습니다. 이로 인해 인스턴스에 액세스할 때 문제가 발생할 수 있습니다. 규칙을 최대한 간략하게 만드는 것이 좋습니다.
+ 보안 그룹을 규칙의 소스 또는 대상으로 지정할 경우 규칙은 보안 그룹과 연결된 모든 인스턴스에 영향을 줍니다. 유입 트래픽은 퍼블릭 IP 주소 또는 탄력적 IP 주소가 아닌 원본 보안 그룹과 연결된 인스턴스의 프라이빗 IP 주소를 기반으로 허용됩니다. IP 주소에 대한 자세한 내용은 [Amazon EC2 인스턴스 IP 주소 지정](using-instance-addressing.md) 주제를 참조하세요.
+ Amazon EC2에서는 기본적으로 포트 25의 트래픽을 차단합니다. 자세한 내용은 [포트 25를 사용하여 전송되는 이메일 관련 제한](ec2-resource-limits.md#port-25-throttle) 섹션을 참조하세요.
------
#### [ Console ]
**보안 그룹을 생성하는 방법**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **보안 그룹**을 선택합니다.
1. **보안 그룹 생성**을 선택합니다.
1. 보안 그룹의 설명이 포함된 이름과 간단한 설명을 입력합니다. 보안 그룹을 생성한 후에는 보안 그룹에 대한 이름과 설명을 변경할 수 없습니다.
1. **VPC**에서 Amazon EC2 인스턴스를 실행할 VPC를 선택합니다.
1. (선택 사항) 인바운드 규칙을 추가하려면 **인바운드 규칙**을 선택합니다. 각 규칙에 대해 **규칙 추가**를 선택하고 프로토콜, 포트 및 소스를 지정합니다. 예를 들어 SSH 트래픽을 허용하려면 **유형**에서 **SSH**를 선택하고 **소스**에서 컴퓨터 또는 네트워크의 퍼블릭 IPv4 주소를 지정합니다.
1. (선택 사항) 아웃바운드 규칙을 추가하려면 **아웃바운드 규칙**을 선택합니다. 각 규칙에 대해 **규칙 추가**를 선택하고 프로토콜, 포트 및 대상을 지정합니다. 아니면 모든 아웃바운드 트래픽을 허용하는 기본 규칙을 유지할 수 있습니다.
1. (선택 사항) 태그를 추가하려면 **Add new tag**(새 태그 추가)를 선택하고 태그 키와 태그 값을 입력합니다.
1. **보안 그룹 생성**을 선택합니다.
------
#### [ AWS CLI ]
**보안 그룹을 생성하는 방법**
다음 [create-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html) 명령을 사용합니다.
```
aws ec2 create-security-group \
--group-name my-security-group \
--description "my security group" \
--vpc-id vpc-1234567890abcdef0
```
규칙을 추가하는 예제는 [보안 그룹 규칙 구성](changing-security-group.md#add-remove-security-group-rules) 섹션을 참조하세요.
------
#### [ PowerShell ]
**보안 그룹을 생성하는 방법**
[New-EC2SecurityGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2SecurityGroup.html) cmdlet을 사용합니다.
```
New-EC2SecurityGroup `
-GroupName my-security-group `
-Description "my security group" `
-VpcId vpc-1234567890abcdef0
```
규칙을 추가하는 예제는 [보안 그룹 규칙 구성](changing-security-group.md#add-remove-security-group-rules) 단원을 참조하세요.
------
# Amazon EC2 인스턴스에 대한 보안 그룹 변경
Amazon EC2 인스턴스를 시작할 때 해당 인스턴스에 대해 보안 그룹을 지정할 수 있습니다. 인스턴스를 시작한 이후에는 보안 그룹을 추가하거나 제거할 수 없습니다. 또한 언제든지 연결된 보안 그룹에 대한 보안 그룹 규칙을 추가, 제거 또는 편집할 수 있습니다.
보안 그룹은 네트워크 인터페이스와 연결됩니다. 보안 그룹을 추가하거나 제거하면 기본 네트워크 인터페이스와 연결된 보안 그룹이 변경됩니다. 보조 네트워크 인터페이스와 연결된 보안 그룹을 변경할 수도 있습니다. 자세한 내용은 [네트워크 인터페이스 속성 수정](modify-network-interface-attributes.md) 섹션을 참조하세요.
**Topics**
+ [보안 그룹 추가 또는 제거](#add-remove-instance-security-groups)
+ [보안 그룹 규칙 구성](#add-remove-security-group-rules)
## 보안 그룹 추가 또는 제거
인스턴스를 시작한 후 연결된 보안 그룹 목록에서 보안 그룹을 추가하거나 제거할 수 있습니다. 여러 보안 그룹을 인스턴스와 연결할 경우 각 보안 그룹의 규칙이 유효하게 결합된 단일 규칙 세트가 생성됩니다. Amazon EC2는 이 규칙 세트를 사용하여 트래픽을 허용할지 여부를 결정합니다.
**요구 사항**
+ 인스턴스는 `running` 또는 `stopped` 상태여야 합니다.
------
#### [ Console ]
**인스턴스에 대한 보안 그룹 변경**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 인스턴스를 선택한 다음 [**작업(Actions)**], [**보안(Security)**], [**보안 그룹 변경(Change security groups)**]을 선택합니다.
1. **연결된 보안 그룹**에서는 목록에서 보안 그룹을 선택하고 **보안 그룹 추가**를 선택합니다.
이미 연결된 보안 그룹을 제거하려면 보안 그룹의 **제거**를 선택합니다.
1. **저장**을 선택합니다.
------
#### [ AWS CLI ]
**인스턴스에 대한 보안 그룹 변경**
다음 [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) 명령을 사용합니다.
```
aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--groups sg-1234567890abcdef0
```
------
#### [ PowerShell ]
**인스턴스에 대한 보안 그룹 변경**
[Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html) cmdlet을 사용합니다.
```
Edit-EC2InstanceAttribute `
-InstanceId i-1234567890abcdef0 `
-Group sg-1234567890abcdef0
```
------
## 보안 그룹 규칙 구성
보안 그룹을 생성한 후 해당 보안 그룹 규칙을 추가, 업데이트 및 삭제할 수 있습니다. 규칙을 추가, 업데이트 또는 삭제하면 변경 내용이 보안 그룹과 연결된 모든 리소스에 자동으로 적용됩니다.
보안 그룹에 추가할 수 있는 규칙의 예제는 [다양한 사용 사례에 대한 보안 그룹 규칙](security-group-rules-reference.md)의 내용을 참조하세요.
**필수 권한**
시작하기 전에 필요한 권한이 있는지 확인하세요. 자세한 내용은 [예: 보안 그룹 작업](iam-policies-ec2-console.md#ex-security-groups) 섹션을 참조하세요.
**포트 및 프로토콜**
+ 콘솔에서 사전 정의된 유형을 선택하면 **프로토콜** 및 **포트 범위**가 지정됩니다. 포트 범위를 입력하려면 **사용자 지정 TCP** 또는 **사용자 지정 UDP** 중 하나를 선택해야 합니다.
+ AWS CLI에서 `--protocol` 및 `--port` 옵션을 사용하여 단일 포트가 있는 단일 규칙을 추가할 수 있습니다. 여러 규칙 또는 포트 범위가 있는 규칙을 추가하려면 `--ip-permissions` 옵션을 대신 사용합니다.
**소스 및 대상**
+ 콘솔에서 다음을 인바운드 규칙의 소스 또는 아웃바운드 규칙의 대상으로 지정할 수 있습니다.
+ **사용자 지정** - IPv4 CIDR 블록, IPv6 CIDR 블록, 보안 그룹 또는 접두사 목록.
+ **Anywhere-IPv4** – 0.0.0.0/0 IPv4 CIDR 블록.
+ **Anywhere-IPv6** – ::/0 IPv6 CIDR 블록.
+ **내 IP**: 로컬 컴퓨터의 퍼블릭 IPv4 주소.
+ AWS CLI에서 `--cidr` 옵션을 사용하여 IPv4 CIDR 블록을 지정하거나 `--source-group` 옵션을 사용하여 보안 그룹을 지정할 수 있습니다. 접두사 목록 또는 IPv6 CIDR 블록을 지정하려면 `--ip-permissions` 옵션을 사용합니다.
**주의**
포트 22(SSH) 또는 3389(RDP)에 대한 인바운드 규칙을 추가하는 경우 인스턴스에 액세스해야 하는 특정 IP 주소 또는 주소 범위만 승인하는 것이 좋습니다. **Anywhere-IPv4**를 선택하면 모든 IPv4 주소의 트래픽을 허용하고 지정된 프로토콜을 사용하여 인스턴스에 액세스합니다. **Anywhere-IPv6**를 선택하면 모든 IPv6 주소의 트래픽을 허용하고 지정된 프로토콜을 사용하여 인스턴스에 액세스합니다.
------
#### [ Console ]
**보안 그룹 규칙을 구성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **보안 그룹**을 선택합니다.
1. 보안 그룹을 선택합니다.
1. 인바운드 규칙을 편집하려면 **작업** 또는 **인바운드 규칙** 탭에서 **인바운드 규칙 편집**을 선택합니다.
1. 규칙을 추가하려면 **규칙 추가**를 선택한 다음 규칙의 유형, 프로토콜, 포트 및 소스를 입력합니다.
유형이 TCP 또는 UDP인 경우 허용할 포트 범위를 입력해야 합니다. 사용자 지정 ICMP의 경우 **프로토콜(Protocol)**에서 ICMP 유형 이름을 선택하고, 해당되는 경우 **포트 범위(Port range)**에서 코드 이름을 선택해야 합니다. 다른 유형에 대해 프로토콜과 포트 범위가 구성됩니다.
1. 규칙을 업데이트하려면 필요에 따라 프로토콜, 설명 및 소스를 변경합니다. 하지만 소스 유형을 변경할 수는 없습니다. 예를 들어 소스가 IPv4 CIDR 블록인 경우 IPv6 CIDR 블록, 접두사 목록 또는 보안 그룹을 지정할 수 없습니다.
1. 규칙을 삭제하려면 해당 **삭제** 버튼을 선택합니다.
1. 아웃바운드 규칙을 편집하려면 **작업** 또는 **아웃바운드 규칙** 탭에서 **아웃바운드 규칙 편집**을 선택합니다.
1. 규칙을 추가하려면 **규칙 추가**를 선택한 다음 규칙의 유형, 프로토콜, 포트 및 대상을 입력합니다. 또한 설명을 입력할 수 있습니다(선택 사항).
유형이 TCP 또는 UDP인 경우 허용할 포트 범위를 입력해야 합니다. 사용자 지정 ICMP의 경우 **프로토콜(Protocol)**에서 ICMP 유형 이름을 선택하고, 해당되는 경우 **포트 범위(Port range)**에서 코드 이름을 선택해야 합니다. 다른 유형에 대해 프로토콜과 포트 범위가 구성됩니다.
1. 규칙을 업데이트하려면 필요에 따라 프로토콜, 설명 및 소스를 변경합니다. 하지만 소스 유형을 변경할 수는 없습니다. 예를 들어 소스가 IPv4 CIDR 블록인 경우 IPv6 CIDR 블록, 접두사 목록 또는 보안 그룹을 지정할 수 없습니다.
1. 규칙을 삭제하려면 해당 **삭제** 버튼을 선택합니다.
1. **규칙 저장**을 선택합니다.
------
#### [ AWS CLI ]
**보안 그룹 규칙을 추가하는 방법**
[authorize-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html) 명령을 사용하여 인바운드 규칙을 추가합니다. 다음 예제에서는 지정된 접두사 목록 중 CIDR 블록의 인바운드 SSH 트래픽을 허용합니다.
```
aws ec2 authorize-security-group-ingress \
--group-id sg-1234567890abcdef0 \
--ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,PrefixListIds=[{PrefixListId=pl-f8a6439156EXAMPLE}]'
```
[authorize-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-egress.html) 명령을 사용하여 아웃바운드 규칙을 추가합니다. 다음 예제에서는 지정된 보안 그룹이 있는 인스턴스에 포트 80의 아웃바운드 TCP 트래픽을 허용합니다.
```
aws ec2 authorize-security-group-egress \
--group-id sg-1234567890abcdef0 \
--ip-permissions 'IpProtocol=tcp,FromPort=80,ToPort=80,UserIdGroupPairs=[{GroupId=sg-0aad1c26bb6EXAMPLE}]'
```
**무효 보안 그룹 규칙을 제거하는 방법**
다음 [revoke-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-ingress.html) 명령을 사용하여 인바운드 규칙을 제거합니다.
```
aws ec2 revoke-security-group-egress \
--group id sg-1234567890abcdef0 \
--security-group-rule-ids sgr-09ed298024EXAMPLE
```
다음 [revoke-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-egress.html) 명령을 사용하여 아웃바운드 규칙을 제거합니다.
```
aws ec2 revoke-security-group-ingress \
--group id sg-1234567890abcdef0 \
--security-group-rule-ids sgr-0352250c1aEXAMPLE
```
**보안 그룹 규칙을 수정하는 방법**
[modify-security-group-rules](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-security-group-rules.html) 명령을 사용합니다. 다음 예제에서는 지정된 보안 그룹 규칙의 IPv4 CIDR 블록을 변경합니다.
```
aws ec2 modify-security-group-rules \
--group id sg-1234567890abcdef0 \
--security-group-rules 'SecurityGroupRuleId=sgr-09ed298024EXAMPLE,SecurityGroupRule={IpProtocol=tcp,FromPort=80,ToPort=80,CidrIpv4=0.0.0.0/0}'
```
------
#### [ PowerShell ]
**보안 그룹 규칙을 추가하는 방법**
[Grant-EC2SecurityGroupIngress](https://docs.aws.amazon.com/powershell/latest/reference/items/Grant-EC2SecurityGroupIngress.html) cmdlet을 사용하여 인바운드 규칙을 추가합니다. 다음 예제에서는 지정된 접두사 목록 중 CIDR 블록의 인바운드 SSH 트래픽을 허용합니다.
```
$plid = New-Object -TypeName Amazon.EC2.Model.PrefixListId
$plid.Id = "pl-f8a6439156EXAMPLE"
Grant-EC2SecurityGroupIngress `
-GroupId sg-1234567890abcdef0 `
-IpPermission @{IpProtocol="tcp"; FromPort=22; ToPort=22; PrefixListIds=$plid}
```
[Grant-EC2SecurityGroupEgress](https://docs.aws.amazon.com/powershell/latest/reference/items/Grant-EC2SecurityGroupEgress.html) cmdlet을 사용하여 아웃바운드 규칙을 추가합니다. 다음 예제에서는 지정된 보안 그룹이 있는 인스턴스에 포트 80의 아웃바운드 TCP 트래픽을 허용합니다.
```
$uigp = New-Object -TypeName Amazon.EC2.Model.UserIdGroupPair
$uigp.GroupId = "sg-0aad1c26bb6EXAMPLE"
Grant-EC2SecurityGroupEgress `
-GroupId sg-1234567890abcdef0 `
-IpPermission @{IpProtocol="tcp"; FromPort=80; ToPort=80; UserIdGroupPairs=$uigp}
```
**무효 보안 그룹 규칙을 제거하는 방법**
[Revoke-EC2SecurityGroupIngress](https://docs.aws.amazon.com/powershell/latest/reference/items/Revoke-EC2SecurityGroupIngress.html) cmdlet을 사용하여 인바운드 규칙을 제거합니다.
```
Revoke-EC2SecurityGroupIngress `
-GroupId sg-1234567890abcdef0 `
-SecurityGroupRuleId sgr-09ed298024EXAMPLE
```
[Revoke-EC2SecurityGroupEgress](https://docs.aws.amazon.com/powershell/latest/reference/items/Revoke-EC2SecurityGroupEgress.html) cmdlet을 사용하여 아웃바운드 규칙을 제거합니다.
```
Revoke-EC2SecurityGroupEgress `
-GroupId sg-1234567890abcdef0 `
-SecurityGroupRuleId sgr-0352250c1aEXAMPLE
```
**보안 그룹 규칙을 수정하는 방법**
[Edit-EC2SecurityGroupRule](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2SecurityGroupRule.html) cmdlet을 사용합니다. 다음 예제에서는 지정된 보안 그룹 규칙의 IPv4 CIDR 블록을 변경합니다.
```
$sgrr = New-Object -TypeName Amazon.EC2.Model.SecurityGroupRuleRequest
$sgrr.IpProtocol = "tcp"
$sgrr.FromPort = 80
$sgrr.ToPort = 80
$sgrr.CidrIpv4 = "0.0.0.0/0"
$sgr = New-Object -TypeName Amazon.EC2.Model.SecurityGroupRuleUpdate
$sgr.SecurityGroupRuleId = "sgr-09ed298024EXAMPLE"
$sgr.SecurityGroupRule = $sgrr
Edit-EC2SecurityGroupRule `
-GroupId sg-1234567890abcdef0 `
-SecurityGroupRule $sgr
```
------
# Amazon EC2 보안 그룹 삭제
Amazon EC2 인스턴스에 사용할 보안 그룹 생성을 완료하면 이를 삭제할 수 있습니다.
**요구 사항**
+ 보안 그룹은 인스턴스 또는 네트워크 인터페이스와 연결할 수 없습니다.
+ 다른 보안 그룹의 규칙에서 보안 그룹을 참조할 수 없습니다.
------
#### [ Console ]
**보안 그룹을 삭제하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. (선택 사항) 보안 그룹이 인스턴스와 연결되어 있지 않은지 확인하려면 다음을 수행합니다.
1. 탐색 창에서 **Security Groups**를 선택합니다.
1. 삭제할 보안 그룹의 ID를 복사합니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 검색 창에서 **보안 그룹 ID가 동일함** 필터를 추가하고 보안 그룹의 ID를 붙여넣습니다. 결과가 없는 경우 보안 그룹이 인스턴스와 연결되지 않은 것입니다. 그렇지 않으면 보안 그룹을 삭제하기 전에 연결을 해제해야 합니다.
1. 탐색 창에서 **Security Groups**를 선택합니다.
1. 보안 그룹을 선택한 다음 **작업**, **보안 그룹 삭제**를 선택합니다.
1. 보안 그룹을 둘 이상 선택하면 확인 메시지가 표시됩니다. 일부 보안 그룹을 삭제할 수 없는 경우 각 보안 그룹의 상태가 표시되어 삭제 여부를 나타냅니다. 삭제를 확인하려면 **삭제**를 누릅니다.
1. **삭제**를 선택합니다.
------
#### [ AWS CLI ]
**보안 그룹을 삭제하려면**
다음 [delete-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-security-group.html) 명령을 사용합니다.
```
aws ec2 delete-security-group --group-id sg-1234567890abcdef0
```
------
#### [ PowerShell ]
**보안 그룹을 삭제하려면**
[Remove-EC2SecurityGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2SecurityGroup.html) cmdlet을 사용합니다.
```
Remove-EC2SecurityGroup -GroupId sg-1234567890abcdef0
```
------
# Amazon EC2 보안 그룹 연결 추적
보안 그룹은 연결 추적을 사용해 인스턴스가 송수신하는 트래픽에 대한 정보를 추적합니다. 규칙은 트래픽의 연결 상태를 기반으로 적용되어 해당 트래픽을 허용 또는 거부할지 결정합니다. 이 방법을 사용하면 보안 그룹의 상태가 유지됩니다. 인바운드 트래픽에 대한 응답은 아웃바운드 보안 그룹 규칙에 관계없이 인스턴스에서 나가도록 허용되며 반대의 경우도 마찬가지입니다.
예를 들어 홈 컴퓨터에서 인스턴스에 대해 netcat 또는 유사한 명령과 같은 명령을 시작하고, 인바운드 보안 그룹 규칙에서 ICMP 트래픽을 허용한다고 가정하겠습니다. 연결에 대한 정보(포트 정보 포함)가 추적됩니다. 명령에 대한 인스턴스의 응답 트래픽은 새로운 요청이 아니라 설정된 연결로 추적되며, 아웃바운드 보안 그룹 규칙이 아웃바운드 ICMP 트래픽을 제한하더라도 인스턴스에서 나가도록 허용됩니다.
TCP, UDP 또는 ICMP 이외의 프로토콜에 대해서는 IP 주소와 프로토콜 번호만 추적됩니다. 인스턴스에서 다른 호스트로 트래픽이 전송되고, 600초 이내에 동일한 트래픽 유형이 호스트에서 인스턴스로 전송되는 경우 인스턴스에 대한 보안 그룹에서는 인바운드 보안 그룹 규칙과 관계없이 해당 트래픽이 수락됩니다. 해당 트래픽이 원본 트래픽에 대한 응답 트래픽으로 간주되어 보안 그룹에서 수락됩니다.
보안 그룹 규칙을 변경하면 추적된 연결이 즉시 중단되지 않습니다. 기존 연결 시간이 초과할 때까지 보안 그룹에서 패킷이 계속 허용됩니다. 트래픽이 즉시 중단되거나 추적 상태와 관계없이 모든 트래픽에 방화벽 규칙이 적용되도록 서브넷의 네트워크 ACL을 사용할 수 있습니다. 네트워크 ACL은 상태 비저장이므로 자동으로 응답 트래픽을 허용하지 않습니다. 어느 방향이든 트래픽이 차단되는 네트워크 ACL을 추가하면 기존 연결이 끊어집니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [네트워크 ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) 섹션을 참조하세요.
**참고**
보안 그룹은 'VPC\$12 IP 주소'(**Amazon Route 53 개발자 가이드의 [Amazon Route 53 Resolver란 무엇인가요?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) 참조) 또는 'AmazonProvidedDNS'(**Amazon Virtual Private Cloud 사용 설명서의 [DHCP 옵션 세트로 작업](https://docs.aws.amazon.com/vpc/latest/userguide/DHCPOptionSet.html) 참조)라고도 하는 Route 53 Resolver에서 들어오고 나가는 DNS 트래픽에 영향을 미치지 않습니다. Route 53 Resolver를 통해 DNS 요청을 필터링하려면 Route 53 Resolver DNS 방화벽을 활성화하면 됩니다(Amazon Route 53 개발자 가이드의 [Route 53 Resolver DNS 방화벽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) 참조).**
## 추적되지 않는 연결
모든 트래픽 흐름이 추적되지는 않습니다. 모든 트래픽(0.0.0.0/0 또는 ::/0)에 대한 TCP 또는 UDP 흐름이 보안 그룹 규칙에서 허용되고 포트(0-65535)에 대한 모든 응답 트래픽(0.0.0.0/0 또는 ::/0)이 허용되는 해당 규칙이 다른 방향에 있는 경우에는 [자동으로 추적되는 연결](#automatic-tracking)의 일부가 아니면 트래픽 흐름이 추적되지 않습니다. 추적되지 않는 흐름에 대한 응답 트래픽은 추적 정보가 아니라 응답 트래픽이 허용되는 인바운드 또는 아웃바운드 규칙에 따라 허용됩니다.
흐름을 허용하는 규칙이 제거 또는 수정될 경우 추적되지 않는 트래픽 흐름이 즉시 중단됩니다. 예를 들어 열린 (0.0.0.0/0) 아웃바운드 규칙이 있고 인스턴스에 대한 모든 (0.0.0.0/0) 인바운드 SSH(TCP 포트 22) 트래픽을 허용하는 규칙을 제거하거나 연결이 더 이상 허용되지 않도록 수정할 경우 인스턴스에 대한 기존 SSH 연결이 즉시 삭제됩니다. 이전에 연결이 추적되지 않았으므로 변경으로 인해 연결이 끊어집니다. 반면에 처음에 SSH 연결이 허용되는(즉, 연결이 추적되었음) 더 좁은 범위의 인바운드 규칙이 있지만 현재 SSH 클라이언트의 주소에서 새 연결이 더는 허용되지 않도록 해당 규칙을 변경하는 경우 기존 SSH 연결은 추적되므로 중단되지 않습니다.
## 자동으로 추적되는 연결
다음을 통해 이루어진 연결은 보안 그룹 구성에 추적하도록 별도로 설정되어 있지 않더라도 자동으로 추적됩니다.
+ 외부 전용 인터넷 게이트웨이
+ Global Accelerator 액셀러레이터
+ NAT 게이트웨이
+ Network Firewall 방화벽 엔드포인트
+ Network Load Balancers
+ AWS PrivateLink(인터페이스 VPC 엔드포인트)
+ AWS Lambda(Hyperplane 탄력적 네트워크 인터페이스)
+ DynamoDB 게이트웨이 엔드포인트 - DynamoDB에 대한 각 연결은 2개의 conntrack 항목을 사용합니다.
## 연결 추적 허용량
Amazon EC2는 인스턴스당 추적할 수 있는 최대 연결 수를 정의합니다. 최대값에 도달하면 새 연결을 설정할 수 없기 때문에 전송하거나 수신하는 패킷이 삭제됩니다. 이 경우 패킷을 전송하고 수신하는 애플리케이션이 제대로 통신할 수 없습니다. `conntrack_allowance_available` 네트워크 성능 지표를 사용하여 해당 인스턴스 유형에 대해 여전히 사용 가능한 추적된 연결 수를 확인합니다.
인스턴스의 네트워크 트래픽이 추적할 수 있는 최대 연결 수를 초과하여 패킷이 삭제되었는지 여부를 확인하려면 `conntrack_allowance_exceeded` 네트워크 성능 지표를 사용합니다. 자세한 내용은 [EC2 인스턴스의 ENA 설정에 대한 네트워크 성능 모니터링](monitoring-network-performance-ena.md) 섹션을 참조하세요.
탄력적 로드 밸런싱을 통해 인스턴스당 추적할 수 있는 최대 연결 수를 초과할 경우 로드 밸런서에 등록된 인스턴스의 수 또는 로드 밸런서에 등록된 인스턴스의 크기를 조정하는 것이 좋습니다.
## 연결 추적 모범 사례
트래픽이 한 네트워크 인터페이스를 통해 인스턴스로 수신되고 다른 네트워크 인터페이스를 통해 송신되는 비대칭 라우팅을 사용하면 흐름을 추적하는 경우 인스턴스에서 달성할 수 있는 최고 성능을 줄일 수 있습니다.
보안 그룹에 대한 연결 추적이 활성화된 경우 최고의 성능을 유지하고 연결 관리를 최적화하려면 다음 구성을 사용하는 것이 좋습니다.
+ 가능하면 비대칭 라우팅 토폴로지를 사용하지 마세요.
+ 필터링에 보안 그룹 대신 네트워크 ACL을 사용합니다.
+ 연결 추적 기능이 있는 보안 그룹을 사용해야 하는 경우 유휴 연결 추적 제한 시간을 가능한 짧게 구성합니다. 유휴 연결 추적 제한 시간에 대한 자세한 내용은 다음 섹션을 참조하세요.
+ Nitrov6 인스턴스의 기본 제한 시간이 짧을수록 수명이 긴 연결(예: 데이터베이스 연결 풀, 영구 HTTP 연결 또는 스트리밍 워크로드)이 있는 애플리케이션은 인스턴스 시작 시 적합한 `TcpEstablishedTimeout` 값을 구성해야 합니다.
+ 수명이 긴 연결의 경우 연결을 열어 두고 추적된 상태를 유지하도록 TCP 연결 유지를 5분 미만의 간격으로 전송하도록 구성합니다. 그러면 유휴 제한 시간으로 인해 연결이 끊어지는 것을 방지하고 연결 재설정 오버헤드를 줄일 수 있습니다.
Nitro 시스템의 성능 조정에 대한 자세한 내용은 [성능 튜닝을 위한 Nitro 시스템 고려 사항](ena-nitro-perf.md) 섹션을 참조하세요.
## 유휴 연결 추적 제한 시간
보안 그룹은 설정된 각 연결을 추적하여 반환 패킷이 예상대로 전달되는지 확인합니다. 인스턴스당 추적할 수 있는 최대 연결 수가 있습니다. 유휴 상태로 유지되는 연결은 연결 추적 소진으로 이어져 연결이 추적되지 않고 패킷이 삭제될 수 있습니다. 탄력적 네트워크 인터페이스에서 유휴 연결 추적에 대한 제한 시간을 설정할 수 있습니다.
**참고**
이 기능은 [Nitro 기반 인스턴스](instance-types.md#instance-hypervisor-type)에서만 사용할 수 있습니다. 프로덕션으로 배포하기 전에 `350` 두 번째 기본 연결 추적 제한 시간을 단축하여 Nitrov6 세대 인스턴스에서 애플리케이션을 테스트해야 합니다.
구성 가능한 세 가지 제한 시간이 있습니다.
+ **TCP 설정 제한 시간**: 설정된 상태의 유휴 TCP 연결에 대한 제한 시간(초)입니다.
+ 최솟값: `60`초
+ 최댓값: `432000`초
+ 기본값: [Nitrov6](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) 인스턴스 유형(P6e-GB200 제외)의 경우 `350`초. 기타 인스턴스 유형 및 P6e-GB200의 경우 `432000`초.
+ 권장값: `432000`초 미만
+ **UDP 제한 시간**: 단일 방향 또는 단일 요청-응답 트랜잭션의 트래픽만 확인한 유휴 UDP 흐름의 제한 시간(초)입니다.
+ 최솟값: `30`초
+ 최댓값: `60`초
+ 기본값: `30`초
+ **UDP 스트림 제한 시간**: 둘 이상의 요청-응답 트랜잭션을 확인한 스트림으로 분류된 유휴 UDP 흐름의 제한 시간(초)입니다.
+ 최솟값: `60`초
+ 최댓값: `180`초
+ 기본값: `180`초
다음과 같은 경우에 기본 제한 시간을 수정해야 할 수 있습니다.
+ [EC2 인스턴스의 ENA 설정에 대한 네트워크 성능 모니터링](monitoring-network-performance-ena.md)Amazon EC2 네트워크 성능 지표를 사용하여 추적된 연결을 모니터링하는 경우 **conntrack\$1allowance\$1exceeded 및 **conntrack\$1allowance\$1available 지표를 사용하면 삭제된 패킷과 추적된 연결 사용률을 모니터링하여 스케일 업 또는 아웃 작업을 통해 EC2 인스턴스 용량을 사전에 관리하여 패킷을 삭제하기 전에 네트워크 연결 수요를 충족할 수 있습니다. EC2 인스턴스에서 conntrack\$1allowance\$1exceeded 삭제가 관찰되는 경우 부적절한 클라이언트 또는 네트워크 미들 박스로 인해 발생하는 오래된 TCP/UDP 세션을 설명하기 위해 더 낮은 TCP 설정 제한 시간을 설정하는 것이 도움이 될 수 있습니다.**
+ 일반적으로 로드 밸런서 또는 방화벽에는 60\$190분 범위의 TCP 설정 유휴 제한 시간이 있습니다. 네트워크 방화벽과 같은 어플라이언스에서 매우 많은 수(10만 개 이상)의 연결을 처리할 것으로 예상되는 워크로드를 실행하는 경우 EC2 네트워크 인터페이스에서 유사한 제한 시간을 구성하는 것이 좋습니다.
+ 비대칭 라우팅 토폴로지를 사용하는 워크로드를 실행하는 경우 TCP 설정 유휴 제한 시간을 60초로 구성하는 것이 좋습니다.
+ DNS, SIP, SNMP, Syslog, Radius 및 UDP를 주로 사용하여 요청을 처리하는 기타 서비스와 같이 연결 수가 많은 워크로드를 실행하는 경우 'UDP-Stream' 제한 시간을 60초로 설정하면 기존 용량의 규모/성능이 향상되고 그레이 페일(gray failure)이 발생하지 않습니다.
+ Network Load Balancer를 통한 TCP/UDP 연결의 경우 모든 연결이 추적됩니다. TCP 흐름의 유휴 제한 시간 값은 350초이고 UDP 흐름은 120초이며 인터페이스 수준 제한 시간 값에 따라 다릅니다. 로드 밸런서의 기본값보다 제한 시간에 대한 유연성을 더 높이기 위해 네트워크 인터페이스 수준에서 제한 시간을 구성할 수 있습니다.
다음 작업을 수행할 때 연결 추적 제한 시간을 구성할 수 있는 옵션이 있습니다.
+ [네트워크 인터페이스 생성](create-network-interface.md)
+ [네트워크 인터페이스 속성 수정](modify-network-interface-attributes.md)
+ [EC2 인스턴스 시작](ec2-instance-launch-parameters.md#liw-network-settings)
+ [EC2 인스턴스 시작 템플릿 생성](ec2-instance-launch-parameters.md#liw-network-settings)
## 예제
다음 예제의 보안 그룹에는 TCP 및 ICMP 트래픽이 허용되는 인바운드 규칙과 모든 아웃 바운드 트래픽이 허용되는 아웃 바운드 규칙이 있습니다.
**인바운드**
| 프로토콜 유형 | 포트 번호 | 소스 |
| --- | --- | --- |
| TCP | 22 (SSH) | 203.0.113.1/32 |
| TCP | 80(HTTP) | 0.0.0.0/0 |
| TCP | 80(HTTP) | ::/0 |
| ICMP | 모두 | 0.0.0.0/0 |
**아웃바운드**
| 프로토콜 유형 | 포트 번호 | Destination |
| --- | --- | --- |
| 모두 | 모두 | 0.0.0.0/0 |
| 모두 | 모두 | ::/0 |
인스턴스 또는 네트워크 인터페이스에 대한 직접 네트워크 연결에서는 추적 동작이 다음과 같습니다.
+ 인바운드 규칙에서 모든 IP 주소(0.0.0.0/0)가 아니라 203.0.113.1/32의 트래픽만 허용되므로 포트 22(SSH)의 인바운드 및 아웃바운드 TCP 트래픽이 추적됩니다.
+ 인바운드 및 아웃바운드 규칙에서 모든 TCP 트래픽이 허용되므로 포트 80(HTTP)의 인바운드 및 아웃바운드 TCP 트래픽이 추적되지 않습니다.
+ ICMP 트래픽은 항상 추적됩니다.
IPv4 트래픽에 대한 아웃바운드 규칙을 제거하는 경우 포트 80(HTTP)의 트래픽을 포함하여 모든 인바운드 및 아웃바운드 IPv4 트래픽이 추적됩니다. IPv6 트래픽에 대한 아웃바운드 규칙을 제거하는 경우 IPv6 트래픽에 동일하게 적용됩니다.
# 다양한 사용 사례에 대한 보안 그룹 규칙
보안 그룹을 생성하고 보안 그룹과 연결된 인스턴스의 역할을 반영하는 규칙을 추가합니다. 예를 들어 웹 서버로 구성된 인스턴스에는 인바운드 HTTP 및 HTTPS 액세스를 허용하는 보안 그룹 규칙이 필요합니다. 마찬가지로 데이터베이스 인스턴스에는 데이터베이스 유형에 대한 액세스(예: MySQL의 경우 포트 3306을 통한 액세스)를 허용하는 규칙이 필요합니다.
다음은 특정한 종류의 액세스에 대해 보안 그룹에 추가할 수 있는 규칙의 종류를 예로 든 것입니다.
**Topics**
+ [웹 서버 규칙](#sg-rules-web-server)
+ [데이터베이스 서버 규칙](#sg-rules-db-server)
+ [컴퓨터에서 인스턴스 연결에 대한 규칙](#sg-rules-local-access)
+ [보안 그룹이 동일한 인스턴스에서 인스턴스에 대한 연결 규칙](#sg-rules-other-instances)
+ [Ping/ICMP 규칙](#sg-rules-ping)
+ [DNS 서버 규칙](#sg-rules-dns)
+ [Amazon EFS 규칙](#sg-rules-efs)
+ [Elastic Load Balancing 규칙](#sg-rules-elb)
지침은 [보안 그룹 생성](creating-security-group.md) 및 [보안 그룹 규칙 구성](changing-security-group.md#add-remove-security-group-rules) 섹션을 참조하세요.
## 웹 서버 규칙
다음 인바운드 규칙에서는 임의의 IP 주소로부터 HTTP 및 HTTPS 액세스를 허용합니다. VPC가 IPv6용으로 활성화되면 IPv6 주소에서 인바운드 HTTP 및 HTTPS 트래픽을 제어하기 위한 규칙을 추가할 수 있습니다.
| 프로토콜 유형 | 프로토콜 번호 | 포트 | 소스 IP | 참고 |
| --- | --- | --- | --- | --- |
| TCP | 6 | 80(HTTP) | 0.0.0.0/0 | 임의의 IPv4 주소에서 인바운드 HTTP 액세스를 허용함 |
| TCP | 6 | 443(HTTPS) | 0.0.0.0/0 | 임의의 IPv4 주소에서 인바운드 HTTPS 액세스를 허용함 |
| TCP | 6 | 80(HTTP) | ::/0 | 임의의 IPv6 주소에서 인바운드 HTTP 액세스를 허용함 |
| TCP | 6 | 443(HTTPS) | ::/0 | 임의의 IPv6 주소에서 인바운드 HTTPS 액세스를 허용함 |
## 데이터베이스 서버 규칙
다음의 인바운드 규칙은 인스턴스에서 실행 중인 데이터베이스의 유형에 따라 데이터베이스 액세스를 위해 추가할 수 있는 규칙을 예로 든 것입니다. Amazon RDS DB 인스턴스에 대한 자세한 내용은 [Amazon RDS 사용 설명서](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/)를 참조하세요.
원본 IP의 경우 다음 중 하나를 지정합니다.
+ 로컬 네트워크의 특정 IP 주소 또는 IP 주소 범위(CIDR 블록 표기법)
+ 데이터베이스에 액세스하는 인스턴스 그룹의 보안 그룹 ID
| 프로토콜 유형 | 프로토콜 번호 | 포트 | 참고 |
| --- | --- | --- | --- |
| TCP | 6 | 1433(MS SQL) | Microsoft SQL Server 데이터베이스 액세스를 위한 기본 포트(예: Amazon RDS 인스턴스에서) |
| TCP | 6 | 3306(MYSQL/Aurora) | MySQL 또는 Aurora 데이터베이스 액세스를 위한 기본 포트(예: Amazon RDS 인스턴스에서) |
| TCP | 6 | 5439(Redshift) | Amazon Redshift 클러스터 데이터베이스 액세스를 위한 기본 포트. |
| TCP | 6 | 5432(PostgreSQL) | PostgreSQL 데이터베이스 액세스를 위한 기본 포트(예: Amazon RDS 인스턴스에서) |
| TCP | 6 | 1521(Oracle) | Oracle 데이터베이스 액세스를 위한 기본 포트(예: Amazon RDS 인스턴스에서) |
선택적으로 데이터베이스 서버의 아웃바운드 트래픽을 제한할 수 있습니다. 예를 들어 소프트웨어 업데이트를 위해 인터넷 액세스를 허용하지만 다른 모든 종류의 트래픽은 제한할 수 있습니다. 먼저 모든 아웃바운드 트래픽을 허용하는 기본 아웃바운드 규칙을 제거해야 합니다.
| 프로토콜 유형 | 프로토콜 번호 | 포트 | 목적지 IP | 참고 |
| --- | --- | --- | --- | --- |
| TCP | 6 | 80(HTTP) | 0.0.0.0/0 | 임의의 IPv4 주소에 대한 아웃바운드 HTTP 액세스를 허용함 |
| TCP | 6 | 443(HTTPS) | 0.0.0.0/0 | 임의의 IPv4 주소에 대한 아웃바운드 HTTPS 액세스를 허용함 |
| TCP | 6 | 80(HTTP) | ::/0 | (IPv6 사용 VPC만 해당) 임의의 IPv6 주소에 대한 아웃바운드 HTTP 액세스를 허용함 |
| TCP | 6 | 443(HTTPS) | ::/0 | (IPv6 사용 VPC만 해당) 임의의 IPv6 주소에 대한 아웃바운드 HTTPS 액세스를 허용함 |
## 컴퓨터에서 인스턴스 연결에 대한 규칙
인스턴스에 연결하려면 보안 그룹에 SSH 액세스(Linux 인스턴스) 또는 RDP 액세스(Windows 인스턴스)를 허용하는 인바운드 규칙이 있어야 합니다.
| 프로토콜 유형 | 프로토콜 번호 | 포트 | 소스 IP |
| --- | --- | --- | --- |
| TCP | 6 | 22(SSH) | 컴퓨터의 퍼블릭 IPv4 주소 또는 로컬 네트워크의 IP 주소 범위. IPv6를 위해 VPC가 활성화되어 있고 인스턴스에 IPv6 주소가 있는 경우 IPv6 주소 또는 범위를 입력할 수 있습니다. |
| TCP | 6 | 3389(RDP) | 컴퓨터의 퍼블릭 IPv4 주소 또는 로컬 네트워크의 IP 주소 범위. IPv6를 위해 VPC가 활성화되어 있고 인스턴스에 IPv6 주소가 있는 경우 IPv6 주소 또는 범위를 입력할 수 있습니다. |
## 보안 그룹이 동일한 인스턴스에서 인스턴스에 대한 연결 규칙
같은 보안 그룹과 연결된 여러 인스턴스가 서로 통신할 수 있게 하려면 이에 대한 규칙을 명시적으로 추가해야 합니다.
**참고**
미들박스 어플라이언스를 통해 서로 다른 서브넷에 있는 두 인스턴스 간의 트래픽을 전달하도록 경로를 구성하는 경우 두 인스턴스에 대한 보안 그룹이 인스턴스 간에 트래픽이 흐르도록 허용해야 합니다. 각 인스턴스의 보안 그룹은 다른 인스턴스의 프라이빗 IP 주소 또는 다른 인스턴스가 포함된 서브넷의 CIDR 범위를 소스로 참조해야 합니다. 다른 인스턴스의 보안 그룹을 소스로 참조하면 인스턴스 간에 트래픽이 흐를 수 없습니다.
다음 표에서는 연결된 인스턴스가 서로 통신할 수 있도록 하기 위한 보안 그룹의 인바운드 규칙을 설명합니다. 이 규칙에서는 모든 유형의 트래픽을 허용합니다.
| 프로토콜 유형 | 프로토콜 번호 | 포트 | 소스 IP |
| --- | --- | --- | --- |
| -1(모두) | -1(모두) | -1(모두) | 보안 그룹의 ID 또는 다른 인스턴스가 포함된 서브넷의 CIDR 범위(참고 사항 참조). |
## Ping/ICMP 규칙
**ping** 명령은 ICMP 트래픽의 한 유형입니다. 인스턴스를 ping하려면 다음과 같은 인바운드 ICMP 규칙 중 하나를 추가해야 합니다.
| Type | 프로토콜 | 소스 |
| --- | --- | --- |
| 사용자 지정 ICMP - IPv4 | 에코 요청 | 컴퓨터의 퍼블릭 IPv4 주소, 특정 IPv4 주소 또는 위치와 관계없는 IPv4 또는 IPv6 주소입니다. |
| 모든 ICMP - IPv4 | IPv4 ICMP(1) | 컴퓨터의 퍼블릭 IPv4 주소, 특정 IPv4 주소 또는 위치와 관계없는 IPv4 또는 IPv6 주소입니다. |
**ping6** 명령을 사용하여 인스턴스에 대한 IPv6 주소를 ping하려면 다음 인바운드 ICMPv6 규칙을 추가해야 합니다.
| Type | 프로토콜 | 소스 |
| --- | --- | --- |
| 모든 ICMP - IPv6 | IPv6 ICMP(58) | 컴퓨터의 IPv6 주소, 특정 IPv4 주소 또는 위치와 관계없는 IPv4 또는 IPv6 주소 |
## DNS 서버 규칙
EC2 인스턴스를 DNS 서버로 설정한 경우 TCP 및 UDP 트래픽이 포트 53을 통해 DNS 서버에 연결할 수 있는지 확인해야 합니다.
원본 IP의 경우 다음 중 하나를 지정합니다.
+ 네트워크의 IP 주소 또는 IP 주소 범위(CIDR 블록 표기법)
+ 네트워크에서 DNS 서버로의 액세스를 필요로 하는 인스턴스 세트에 대한 보안 그룹의 ID
| 프로토콜 유형 | 프로토콜 번호 | 포트 |
| --- | --- | --- |
| TCP | 6 | 53 |
| UDP | 17 | 53 |
## Amazon EFS 규칙
Amazon EC2 인스턴스에서 Amazon EFS 파일 시스템을 사용하려면 Amazon EFS 마운트 대상과 연결되는 보안 그룹이 NFS 프로토콜을 통한 트래픽 전송을 허용해야 합니다.
| 프로토콜 유형 | 프로토콜 번호 | 포트 | 소스 IP | 참고 |
| --- | --- | --- | --- | --- |
| TCP | 6 | 2049(NFS) | 보안 그룹의 ID | 이 보안 그룹과 연결된 리소스(탑재 대상 포함)에서 인바운드 NFS 액세스를 허용합니다. |
Amazon EFS 파일 시스템을 Amazon EC2 인스턴스에 마운트하려면 인스턴스에 연결해야 합니다. 따라서 인스턴스와 연결되는 보안 그룹은 로컬 컴퓨터 또는 로컬 네트워크의 인바운드 SSH 트래픽을 허용하는 규칙이 필요합니다.
| 프로토콜 유형 | 프로토콜 번호 | 포트 | 소스 IP | 참고 |
| --- | --- | --- | --- | --- |
| TCP | 6 | 22(SSH) | 로컬 컴퓨터의 IP 주소 범위 또는 네트워크의 IP 주소 범위(CIDR 블록 표기법). | 로컬 컴퓨터로부터의 인바운드 SSH 액세스를 허용합니다. |
## Elastic Load Balancing 규칙
로드 밸런서에 EC2 인스턴스를 등록하는 경우 로드 밸런서에 연결된 보안 그룹은 인스턴스와의 통신을 허용해야 합니다. 자세한 내용은 Elastic Load Balancing 설명서에서 다음을 참조하세요.
+ [Application Load Balancer 보안 그룹](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-update-security-groups.html)
+ [Network Load Balancer의 보안 그룹](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-security-groups.html)
+ [Classic Load Balancer 보안 그룹 구성](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-vpc-security-groups.html)
# Amazon EC2 인스턴스의 NitroTPM
NitroTPM(Nitro Trusted Platform Module)은 [AWS Nitro System](https://aws.amazon.com//ec2/nitro/)에서 제공하는 가상 디바이스로서 [TPM 2.0 사양](https://trustedcomputinggroup.org/resource/trusted-platform-module-2-0-a-brief-introduction/)을 준수합니다. 인스턴스를 인증하는 데 사용되는 아티팩트(예: 암호, 인증서 또는 암호화 키)를 안전하게 저장합니다. NitroTPM은 키를 생성하여 암호화 기능(예: 해시, 서명, 암호화 및 암호 해독)에 사용할 수 있습니다.
NitroTPM은 부트로더와 운영 체제가 모든 부팅 바이너리의 암호화 해시를 생성하여 NitroTPM 내부 플랫폼 구성 레지스터(PCR)의 이전 값과 결합하는 프로세스인 측정된 부팅**을 제공합니다. 측정된 부팅을 사용하면 NitroTPM에서 서명된 PCR 값을 가져와서 이를 사용하여 원격 엔터티에 인스턴스 부팅 소프트웨어의 무결성을 입증할 수 있습니다. 이를 원격 증명**이라고 합니다.
NitroTPM을 사용하면 키 및 암호에 특정 PCR 값으로 태그를 지정할 수 있으므로 PCR 값 즉, 인스턴스 무결성이 변경되면 절대 액세스할 수 없습니다. 이러한 특수한 형태의 조건부 액세스 권한을 밀봉 및 밀봉 해제**라고 합니다. [BitLocker](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/)와 같은 운영 체제 기술은 NitroTPM을 사용하여 드라이브 암호 해독 키를 밀봉합니다. 따라서 운영 체제가 올바르게 부팅되어 정상 작동이 확인된 상태일 경우에만 드라이브의 암호를 해독할 수 있습니다.
NitroTPM을 사용하려면 NitroTPM 지원을 위해 구성된 [Amazon Machine Image](AMIs.md)(AMI)를 선택한 다음 AMI를 사용하여 [Nitro 기반 인스턴스](instance-types.md#instance-hypervisor-type)를 시작해야 합니다. Amazon의 사전 빌드된 AMI 중 하나를 선택하거나 직접 생성할 수 있습니다.
**가격 책정**
NitroTPM 사용에 대한 추가 비용은 없습니다. 사용하는 기본 리소스에 대해서만 비용을 지불합니다.
**Topics**
+ [요구 사항](enable-nitrotpm-prerequisites.md)
+ [NitroTPM용 Linux AMI 활성화](enable-nitrotpm-support-on-ami.md)
+ [AMI가 NitroTPM에 대해 활성화되어 있는지 확인](verify-nitrotpm-support-on-ami.md)
+ [NitroTPM 활성화 또는 중지](nitrotpm-instance.md)
+ [인스턴스가 NitroTPM에 대해 활성화되어 있는지 확인](verify-nitrotpm-support-on-instance.md)
+ [퍼블릭 인증 키 검색](retrieve-ekpub.md)
# Amazon EC2 인스턴스에서 NitroTPM을 사용하기 위한 요구 사항
NitroTPM이 활성화된 인스턴스를 시작하려면 다음 요구 사항이 충족되어야 합니다.
**Topics**
+ [AMI](#nitrotpm-ami)
+ [인스턴스 유형](#nitrotpm-instancetypes)
+ [고려 사항](#nitrotpm-considerations)
## AMI
AMI에서 NitroTPM이 활성화되어 있어야 합니다.
**Linux AMI**
사전 구성된 AMI는 없습니다. 자체 AMI를 구성해야 합니다. 자세한 내용은 [NitroTPM용 Linux AMI 활성화](enable-nitrotpm-support-on-ami.md) 섹션을 참조하세요.
**Windows AMI**
Microsoft 키를 사용하여 NitroTPM과 UEFI 보안 부팅을 위해 사전 구성된 AWS Windows AMI를 찾으려면 *AWS Windows AMIs Reference*의 [Find Windows Server AMIs configured with NitroTPM and UEFI Secure Boot](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/ami-windows-tpm.html#ami-windows-tpm-find)를 참조하세요.
**참고**
**운영 체제** - AMI에는 TPM 2.0 CRB(Command Response Buffer) 드라이버가 있는 운영 체제가 포함되어야 합니다. 대부분의 최신 운영 체제에는 TPM 2.0 CRB 드라이버가 포함되어 있습니다.
**UEFI 부팅 모드** - AMI는 UEFI 부팅 모드에 맞게 구성되어야 합니다. 자세한 내용은 [Amazon EC2 인스턴스의 UEFI 보안 부팅](uefi-secure-boot.md) 섹션을 참조하세요.
## 인스턴스 유형
다음 가상화 인스턴스 유형 중 하나를 사용해야 합니다.
+ **범용**: M5, M5a, M5ad, M5d, M5dn, M5n, M5zn, M6a, M6g, M6gd, M6i, M6id, M6idn, M6in, M7a, M7g, M7gd, M7i, M7i-flex, M8a, M8azn, M8g, M8gb, M8gd, M8gn, M8i, M8id, M8i-flex, T3, T3a, T4g
+ **컴퓨팅 최적화**: C5, C5a, C5ad, C5d, C5n, C6a, C6g, C6gd, C6gn, C6i, C6id, C6in, C7a, C7g, C7gd, C7gn, C7i, C7i-flex, C8a, C8g, C8gb, C8gd, C8gn, C8i, C8id, C8i-flex
+ **메모리 최적화**: R5, R5a, R5ad, R5b, R5d, R5dn, R5n, R6a, R6g, R6gd, R6i, R6id, R6idn, R6in, R7a, R7g, R7gd, R7i, R7iz, R8a, R8g, R8gb, R8gd, R8gn, R8i, R8id, R8i-flex, U7i-6tb, U7i-8tb, U7i-12tb, U7in-16tb, U7in-24tb, U7in-32tb, X2idn, X2iedn, X2iezn, X8g, X8aedz, X8i, z1d
+ **스토리지 최적화**: D3, D3en, I3en, I4i, I7i, I7ie, I8g, I8ge, Im4gn
+ **가속 컴퓨팅**: F2, G4dn, G5, G6, G6e, G6f, Gr6, Gr6f, G7e, Inf1, Inf2, P5, P5e, P5en, P6-B200, P6-B300, Trn2, Trn2u
+ **고성능 컴퓨팅: **Hpc6a, Hpc6id, Hpc8a
## 고려 사항
NitroTPM 사용 시 다음 사항을 고려하세요.
+ NitroTPM이 활성화된 AMI를 사용하여 인스턴스를 시작한 후 인스턴스 유형을 변경하려면 선택한 새 인스턴스 유형 역시 NitroTPM을 지원해야 합니다.
+ NitroTPM 기반 키로 암호화된 BitLocker 볼륨은 원본 인스턴스에서만 사용할 수 있습니다.
+ NitroTPM 상태는 Amazon EC2 콘솔에 표시되지 않습니다.
+ NitroTPM 상태는 [Amazon EBS 스냅샷](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html)에 포함되지 않습니다.
+ NitroTPM 상태는 [VM Import/Export](https://docs.aws.amazon.com/vm-import/latest/userguide/) 이미지에 포함되지 않습니다.
+ NitroTPM은 AWS Outposts, 로컬 영역 또는 Wavelength 영역에서 지원되지 않습니다.
# NitroTPM용 Linux AMI 활성화
인스턴스에 대해 NitroTPM을 활성화하려면 NitroTPM이 활성화된 AMI를 사용하여 인스턴스를 시작해야 합니다. 등록할 때 NitroTPM 지원 Linux AMI를 구성해야 합니다. NitroTPM 지원은 나중에 구성할 수 없습니다.
NitroTPM 지원을 위해 사전 구성된 Windows AMI 목록은 [Amazon EC2 인스턴스에서 NitroTPM을 사용하기 위한 요구 사항](enable-nitrotpm-prerequisites.md) 섹션을 참조하세요.
[RegisterImage](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RegisterImage.html) API를 사용하여 NitroTPM이 구성된 AMI를 생성해야 합니다. Amazon EC2 콘솔 또는 VM Import/Export를 사용할 수는 없습니다.
**NitroTPM용 Linux AMI 활성화**
1. 필요한 Linux AMI를 사용하여 임시 인스턴스를 시작합니다. 콘솔에 있는 인스턴스의 **스토리지** 탭에서 인스턴스의 루트 볼륨 ID를 찾을 수 있습니다.
1. 인스턴스가 `running` 상태에 도달하면 인스턴스의 루트 볼륨 스냅샷을 생성합니다. 자세한 내용은 [EBS 볼륨의 스냅샷 생성](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-create-snapshot.html)을 참조하세요.
1. 생성한 스냅샷을 AMI로 등록합니다. 블록 디바이스 매핑에서 루트 볼륨에 대해 생성한 스냅샷을 지정합니다.
다음은 예제 [register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) 명령입니다. `--tpm-support`에 `v2.0`을 지정합니다. `--boot-mode`에 `uefi`을 지정합니다.
```
aws ec2 register-image \
--name my-image \
--boot-mode uefi \
--architecture x86_64 \
--root-device-name /dev/xvda \
--block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=snap-0abcdef1234567890} \
--tpm-support v2.0
```
다음은 [Register-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2Image.html) cmdlet의 예입니다.
```
$block = @{SnapshotId=snap-0abcdef1234567890}
Register-EC2Image `
-Name my-image `
-Architecture "x86_64" `
-RootDeviceName /dev/xvda `
-BlockDeviceMapping @{DeviceName="/dev/xvda";Ebs=$block} `
-BootMode Uefi `
-TpmSupport V20
```
1. 1단계에서 시작한 임시 인스턴스를 종료합니다.
# AMI가 NitroTPM에 대해 활성화되어 있는지 확인
인스턴스에 대해 NitroTPM을 활성화하려면 NitroTPM이 활성화된 AMI를 사용하여 인스턴스를 시작해야 합니다. 이미지를 설명하여 NitroTPM이 활성화되어 있는지 확인할 수 있습니다. AMI 소유자인 경우 `tpmSupport` 이미지 속성을 설명할 수 있습니다.
Amazon EC2 콘솔에는 `TpmSupport`가 표시되지 않습니다.
------
#### [ AWS CLI ]
**NitroTPM이 활성화되어 있는지 확인하려면**
[describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) 명령을 사용합니다.
```
aws ec2 describe-images \
--image-ids ami-0abcdef1234567890 \
--query Images[*].TpmSupport
```
AMI에 대해 NitroTPM이 활성화된 출력이 다음과 같습니다. TPM이 활성화되지 않은 경우 출력이 비어 있습니다.
```
[
"v2.0"
]
```
또는 AMI 소유자인 경우 [describe-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-image-attribute.html) 명령을 `tpmSupport` 속성과 함께 사용합니다.
```
aws ec2 describe-image-attribute \
--image-id ami-0abcdef1234567890 \
--attribute tpmSupport
```
다음은 예제 출력입니다.
```
{
"ImageId": "ami-0abcdef1234567890",
"TpmSupport": {
"Value": "v2.0"
}
}
```
**NitroTPM이 활성화되어 있는 AMI를 찾으려면**
다음 예제는 NitroTPM이 활성화된 상태로 소유한 AMI의 ID를 나열합니다.
```
aws ec2 describe-images \
--owners self \
--filters Name=tpm-support,Values=v2.0 \
--query Images[].ImageId
```
------
#### [ PowerShell ]
**NitroTPM이 활성화되어 있는지 확인하려면**
[Get-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Image.html) cmdlet을 사용합니다.
```
Get-EC2Image `
-ImageId ami-0abcdef1234567890 | Select TpmSupport
```
AMI에 대해 NitroTPM이 활성화된 출력이 다음과 같습니다. TPM이 활성화되지 않은 경우 출력이 비어 있습니다.
```
TpmSupport
----------
v2.0
```
또는 AMI 소유자인 경우 [Get-EC2ImageAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2ImageAttribute.html) cmdlet을 `tpmSupport` 속성과 함께 사용합니다.
```
Get-EC2ImageAttribute `
-ImageId ami-0abcdef1234567890 `
-Attribute tpmSupport
```
**NitroTPM이 활성화되어 있는 AMI를 찾으려면**
다음 예제는 NitroTPM이 활성화된 상태로 소유한 AMI의 ID를 나열합니다.
```
Get-EC2Image `
-Owner self `
-Filter @{Name="tpm-support; Values="v2.0"} | Select ImageId
```
------
# Amazon EC2 인스턴스에서 NitroTPM 활성화 또는 중지
시작 시에만 NitroTPM에 대해 Amazon EC2 인스턴스를 활성화할 수 있습니다. NitroTPM에 대해 인스턴스를 활성화하면 비활성화할 수 없습니다. 더 이상 NitroTPM을 사용할 필요가 없는 경우 사용을 중지하도록 운영 체제를 구성해야 합니다.
**Topics**
+ [NitroTPM이 사용 설정된 상태로 인스턴스 시작](#launch-instance-with-nitrotpm)
+ [인스턴스에서 NitroTPM 사용 중지](#disable-nitrotpm-support-on-instance)
## NitroTPM이 사용 설정된 상태로 인스턴스 시작
[필수 구성 요소](enable-nitrotpm-prerequisites.md)를 사용하여 인스턴스를 시작하는 경우 NitroTPM이 인스턴스에서 자동으로 활성화됩니다. 시작 시에만 인스턴스에서 NitroTPM을 활성화할 수 있습니다. 인스턴스 시작에 대한 자세한 정보는 [Amazon EC2 인스턴스 시작하기](LaunchingAndUsingInstances.md) 섹션을 참조하세요.
## 인스턴스에서 NitroTPM 사용 중지
NitroTPM이 활성화된 상태로 인스턴스를 시작하면 인스턴스에 대해 NitroTPM을 사용 중지할 수 없습니다. 그러나 다음 도구를 통해 인스턴스에서 TPM 2.0 디바이스 드라이버를 비활성화하여, NitroTPM 사용을 중지하도록 운영 체제를 구성할 수 있습니다.
+ **Linux 인스턴스**의 경우 tpm-tools를 사용합니다.
+ **Windows 인스턴스**의 경우 TPM 관리 콘솔(tpm.msc)을 사용합니다.
디바이스 드라이버 사용 중지에 대한 자세한 정보는 운영 체제 설명서를 참조하세요.
# Amazon EC2 인스턴스가 NitroTPM에 대해 활성화되어 있는지 확인
Amazon EC2 인스턴스에 NitroTPM이 활성화되어 있는지 확인할 수 있습니다. 인스턴스에 NitroTPM 지원이 활성화된 경우 명령이 `"v2.0"`을 반환합니다. 그렇게 하지 않으면 출력에 `TpmSupport` 필드가 없습니다.
Amazon EC2 콘솔에는 `TpmSupport` 필드가 표시되지 않습니다.
------
#### [ AWS CLI ]
**인스턴스가 NitroTPM에 대해 활성화되어 있는지 확인하려면 다음을 수행하세요.**
아래와 같이 [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) 명령을 사용합니다.
```
aws ec2 describe-instances \
--instance-ids i-1234567890abcdef0 \
--query Reservations[].Instances[].TpmSupport
```
------
#### [ PowerShell ]
**인스턴스가 NitroTPM에 대해 활성화되어 있는지 확인하려면 다음을 수행하세요.**
[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) cmdlet을 사용합니다.
```
(Get-EC2Instance `
-InstanceId i-1234567890abcdef0).Instances.TpmSupport
```
------
## Windows 인스턴스에서 NitroTPM 액세스 권한 확인
**(Windows 인스턴스만 해당) Windows에서 NitroTPM에 액세스할 수 있는지 확인하려면 다음을 수행하세요.**
1. [EC2 Windows 인스턴스에 연결합니다.](connecting_to_windows_instance.md)
1. 인스턴스에서 tpm.msc 프로그램을 실행합니다.
**로컬 컴퓨터의 TPM 관리** 창이 열립니다.
1. **TPM 제조업체 정보(TPM Manufacturer Information)** 필드를 확인합니다. 인스턴스의 제조업체 이름과 NitroTPM 버전이 포함되어 있습니다.
![\[로컬 컴퓨터의 TPM 관리 창 및 인스턴스의 NitroTPM 버전을 표시하는 TPM 제조업체 정보(TPM Manufacturer Information) 필드입니다.\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/tpm-1.png)
# EC2 인스턴스의 퍼블릭 인증 키 검색
언제든지 인스턴스의 퍼블릭 인증 키를 안전하게 검색할 수 있습니다.
------
#### [ AWS CLI ]
**인스턴스의 퍼블릭 인증 키를 검색하는 방법**
[get-instance-tpm-ek-pub](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-tpm-ek-pub.html) 명령을 사용합니다.
**예제 1.**
다음 예제는 지정한 인스턴스의 `rsa-2048` 퍼블릭 인증 키(`tpmt` 형식)를 가져옵니다.
```
aws ec2 get-instance-tpm-ek-pub \
--instance-id i-1234567890abcdef0 \
--key-format tpmt \
--key-type rsa-2048
```
다음은 출력 예제입니다.
```
{
"InstanceId": "i-01234567890abcdef",
"KeyFormat": "tpmt",
"KeyType": "rsa-2048",
"KeyValue": "AAEACwADALIAIINxl2dEhLEXAMPLEUal1yT9UtduBlILZPKh2hszFGmqAAYAgABDA
EXAMPLEAAABAOiRd7WmgtdGNoV1h/AxmW+CXExblG8pEUfNm0LOLiYnEXAMPLERqApiFa/UhvEYqN4
Z7jKMD/usbhsQaAB1gKA5RmzuhSazHQkax7EXAMPLEzDthlS7HNGuYn5eG7qnJndRcakS+iNxT8Hvf
0S1ZtNuItMs+Yp4SO6aU28MT/JZkOKsXIdMerY3GdWbNQz9AvYbMEXAMPLEPyHfzgVO0QTTJVGdDxh
vxtXCOu9GYf0crbjEXAMPLEd4YTbWdDdgOKWF9fjzDytJSDhrLAOUctNzHPCd/92l5zEXAMPLEOIFA
Ss50C0/802c17W2pMSVHvCCa9lYCiAfxH/vYKovAAE="
}
```
**예제 2.**
다음 예제는 지정한 인스턴스의 `rsa-2048` 퍼블릭 인증 키(`der` 형식)를 가져옵니다.
```
aws ec2 get-instance-tpm-ek-pub \
--instance-id i-1234567890abcdef0 \
--key-format der \
--key-type rsa-2048
```
다음은 출력 예제입니다.
```
{
"InstanceId": "i-1234567890abcdef0",
"KeyFormat": "der",
"KeyType": "rsa-2048",
"KeyValue": "MIIBIjANBgEXAMPLEw0BAQEFAAOCAQ8AMIIBCgKCAQEA6JF3taEXAMPLEXWH8DGZb4
JcTFuUbykRR82bQs4uJifaKSOv5NGoEXAMPLEG8Rio3hnuMowP+6xuGxBoAHWAoDlGbO6FJrMdEXAMP
LEnYUHvMO2GVLsc0a5ifl4buqcmd1FxqRL6I3FPwe9/REXAMPLE0yz5inhI7ppTbwxP8lmQ4qxch0x6
tjcZ1Zs1DP0EXAMPLERUYLQ/Id/OBU7RBNMlUZ0PGG/G1cI670Zh/RytuOdx9iEXAMPLEtZ0N2A4pYX
1+PMPK0lIOGssA5Ry03Mc8J3/3aXnOD2/ASRQ4gUBKznQLT/zTZEXAMPLEJUe8IJr2VgKIB/Ef+9gqi
8AAQIDAQAB"
}
```
------
#### [ PowerShell ]
**인스턴스의 퍼블릭 인증 키를 검색하는 방법**
[Get-EC2InstanceTpmEkPub](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceTpmEkPub.html) cmdlet을 사용합니다.
**예제 1.**
다음 예제는 지정한 인스턴스의 `rsa-2048` 퍼블릭 인증 키(`tpmt` 형식)를 가져옵니다.
```
Get-EC2InstanceTpmEkPub `
-InstanceId i-1234567890abcdef0 `
-KeyFormat tpmt `
-KeyType rsa-2048
```
**예제 2.**
다음 예제는 지정한 인스턴스의 `rsa-2048` 퍼블릭 인증 키(`der` 형식)를 가져옵니다.
```
Get-EC2InstanceTpmEkPub `
-InstanceId i-1234567890abcdef0 `
-KeyFormat der `
-KeyType rsa-2048
```
------
# Amazon EC2 인스턴스 증명
증명은 신뢰할 수 있는 소프트웨어, 드라이버 및 부팅 프로세스만 Amazon EC2 인스턴스에서 실행되고 있음을 모든 당사자에게 암호화된 방식으로 증명할 수 있는 프로세스입니다. Amazon EC2 인스턴스 증명은 Nitro Trusted Platform Module(NitroTPM) 및 *증명 가능한 AMI*에 기반합니다.
증명의 첫 번째 단계는 **증명 가능한 AMI를 빌드**하고 해당 AMI의 *참조 측정값*을 결정하는 것입니다. 증명 가능한 AMI는 처음부터 증명을 위해 빌드된 AMI입니다. 참조 측정값은 AMI에 포함된 모든 소프트웨어 및 구성의 측정값입니다. 참조 측정값을 얻는 방법에 대한 자세한 내용은 [이미지 설명 샘플 빌드](build-sample-ami.md) 섹션을 참조하세요.
![\[증명 가능한 AMI로 참조 측정값 생성.\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/attestable-ami.PNG)
다음 단계에서는 증명 가능한 AMI를 사용하여 [Nitro-TPM 지원 EC2 인스턴스](enable-nitrotpm-prerequisites.md#nitrotpm-instancetypes)를 시작합니다. 인스턴스를 시작한 후 [NitroTPM 도구](attestation-get-doc.md)를 사용하여 *증명 문서*를 생성할 수 있습니다. 그런 다음 증명 문서에서 EC2 인스턴스의 실제 측정값을 참조 측정값과 비교하여 인스턴스에 신뢰할 수 있는 소프트웨어 및 구성이 있는지 확인할 수 있습니다.
증명 가능한 AMI 생성 프로세스 중에 생성된 참조 측정값을 인스턴스의 증명 문서에 포함된 측정값과 비교하여 신뢰할 수 있는 소프트웨어 및 코드만 인스턴스에서 실행되고 있는지 검증할 수 있습니다.
![\[증명 문서 생성.\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/attestation-document.PNG)
## AWS KMS와의 통합
프로세스에서 측정값을 더 쉽게 비교하기 위해 AWS Key Management Service(AWS KMS)를 증명 문서의 확인자로 사용할 수 있습니다. AWS KMS를 사용하면 참조 측정값과 일치하는 측정값을 증명 문서에 제공하는 경우에만 KMS 키로 특정 작업을 허용하는 증명 기반 KMS 키 정책을 생성할 수 있습니다. 이렇게 하려면 참조 측정값을 조건 키 값으로 사용하는 KMS 키 정책에 특정 조건 키를 추가하고 조건 키가 충족되면 허용되는 KMS 작업을 지정합니다.
KMS 키를 사용하여 KMS 작업을 수행하는 경우 증명 문서를 KMS 요청에 연결해야 합니다. 그런 다음 AWS KMS에서는 증명 문서의 측정값을 KMS 키 정책의 참조 측정값과 비교하여 검증하고 측정값이 일치하는 경우에만 키 액세스를 허용합니다.
또한 인스턴스에 대한 증명 문서를 생성하는 경우 소유한 키 페어에 대한 퍼블릭 키를 지정해야 합니다. 지정된 퍼블릭 키는 증명 문서에 포함됩니다. AWS KMS에서 증명 문서를 검증하고 복호화 작업을 허용하는 경우 반환되기 전에 증명 문서에 포함된 퍼블릭 키로 응답을 자동 암호화합니다. 이를 통해 응답을 해독하고 증명 문서에 포함된 퍼블릭 키와 일치하는 프라이빗 키에만 사용할 수 있습니다.
이를 통해 신뢰할 수 있는 소프트웨어 및 코드를 실행하는 인스턴스만 KMS 키를 사용하여 암호화 작업을 수행할 수 있습니다.
## 격리된 컴퓨팅 환경 증명
일반적으로 EC2 인스턴스를 빌드하고 **격리된 컴퓨팅 환경**으로 구성할 수 있습니다. 이 환경에서는 대화형 액세스를 제공하지 않으며 관리자와 사용자가 EC2 인스턴스에서 처리 중인 데이터에 액세스할 수 있는 메커니즘도 제공하지 않습니다. EC2 인스턴스 증명을 사용하면 인스턴스가 격리된 컴퓨팅 환경으로 실행되고 있음을 서드 파티 또는 서비스에 증명할 수 있습니다. 자세한 내용은 [자체 운영자로부터 데이터 격리](isolate-data-operators.md) 섹션을 참조하세요.
예제는 격리된 컴퓨팅 환경을 생성하는 [Amazon Linux 2023 이미지 설명 샘플](build-sample-ami.md)을 참조하세요. 이 이미지 설명 샘플을 시작점으로 사용하고 요구 사항에 맞게 사용자 지정할 수 있습니다.
## AWS 공동 책임 모델
NitroTPM 및 증명 가능한 AMI는 EC2 인스턴스에서 증명을 설정하고 구성하는 데 도움이 되는 구성 요소입니다. 해당 사용 사례에 맞게 AMI를 구성할 책임이 사용자에게 있습니다. 자세한 내용은 [AWS 공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)을 참조하세요.
**Topics**
+ [AWS KMS와의 통합](#attestation-kms)
+ [격리된 컴퓨팅 환경 증명](#attestation-isolated-compute-environments)
+ [AWS 공동 책임 모델](#attestation-shared-responsibility)
+ [증명 가능한 AMI](attestable-ami.md)
+ [증명을 위해 AWS KMS 준비](prepare-attestation-service.md)
+ [NitroTPM 증명 문서 가져오기](attestation-get-doc.md)
+ [AWS KMS과 통합](attestation-attest.md)
+ [자체 운영자로부터 데이터 격리](isolate-data-operators.md)
# 증명 가능한 AMI
증명 가능한 AMI는 모든 콘텐츠를 나타내는 해당 암호화 해시가 있는 Amazon Machine Image(AMI)입니다. 해시는 AMI 생성 프로세스 중에 생성되며 애플리케이션, 코드 및 부팅 프로세스를 포함하여 해당 AMI의 전체 콘텐츠를 기반으로 계산됩니다.
## 증명 가능한 상태 유지 관리
인스턴스의 측정값은 초기 부팅 상태에 기반합니다. 시작 후 인스턴스에 적용되고 다시 시작 후에도 해당 지속되는 모든 소프트웨어 또는 코드 변경 내용은 다시 시작 후 인스턴스의 측정값을 변경합니다. 측정값이 변경되면 증명 가능한 AMI의 참조 측정값과 차이가 나고 인스턴스가 다시 시작된 후 인스턴스는 더 이상 AWS KMS에 대해 증명될 수 없습니다. 따라서 증명 가능한 AMI를 활용하려면 인스턴스가 다시 시작된 후 원래 부팅 상태로 돌아와야 합니다.
항상 원래 부팅 상태로 돌아가면 인스턴스가 다시 시작된 후 성공적으로 증명할 수 있습니다. 다음 유틸리티를 사용하여 다시 시작 후에도 인스턴스가 증명 가능한 상태를 유지하도록 보장할 수 있습니다.
+ `erofs` - 읽기 전용 파일 시스템 개선. 이 유틸리티는 루트 파일 시스템이 읽기 전용인지 확인합니다. 이 유틸리티를 사용하면 `/etc`, `/run`, `/var`을 포함한 파일 시스템에 대한 쓰기가 메모리에 저장되었다가 인스턴스가 다시 시작될 때 손실되므로 루트 파일 시스템이 원래 시작 상태로 유지됩니다. 자세한 내용은 [erofs 설명서](https://docs.kernel.org/filesystems/erofs.html)를 참조하세요.
+ `dm-verity` - 읽기 전용 루트 파일 시스템에 대한 무결성 보호를 제공합니다. 유틸리티는 파일 시스템 블록의 해시를 계산하고 커널 명령줄에 저장합니다. 이를 통해 부팅 중에 커널에서 파일 시스템의 무결성을 확인할 수 있습니다. 자세한 내용은 [dm-verity 설명서](https://docs.kernel.org/admin-guide/device-mapper/verity.html)를 참조하세요.
## 증명 가능한 AMI를 생성하기 위한 요구 사항
다음은 증명 가능한 AMI의 요구 사항입니다.
+ **기본 운영 체제** - Amazon Linux 2023 및 [NixOS](https://github.com/aws/nitrotpm-attestation-samples)
+ **아키텍처** - `x86_64` 또는 `arm64` 아키텍처
+ **TPM 지원** - NitroTPM을 활성화해야 합니다. 자세한 내용은 [Amazon EC2 인스턴스에서 NitroTPM을 사용하기 위한 요구 사항](enable-nitrotpm-prerequisites.md) 섹션을 참조하세요.
+ **부팅 모드** - UEFI 부팅 모드를 활성화해야 합니다.
**Topics**
+ [증명 가능한 상태 유지 관리](#maintain-attestability)
+ [증명 가능한 AMI를 생성하기 위한 요구 사항](#ami-attestable-requirements)
+ [증명 가능한 AMI 생성](#sample-ami)
+ [이미지 설명 샘플 빌드](build-sample-ami.md)
+ [Amazon Linux 2023 이미지 설명 샘플](al2023-isolated-compute-recipe.md)
+ [이미지 설명 샘플 사용자 지정](customize-sample-ami.md)
+ [PCR 측정값 계산](create-pcr-compute.md)
## 증명 가능한 AMI 생성
증명 가능한 AMI를 생성하려면 [KIWI Next Generation(KIWI NG)](https://osinside.github.io/kiwi/)와 함께 Amazon Linux 2023을 사용해야 합니다. Amazon Linux 2023은 KIWI NG를 사용하여 증명 가능한 AMI를 빌드하는 데 필요한 모든 소프트웨어와 유틸리티를 제공합니다.
KIWI NG는 사전 구성된 Linux 기반 이미지를 빌드하기 위한 오픈 소스 도구입니다. KIWI NG는 이미지의 콘텐츠를 정의하는 XML *이미지 설명*을 사용합니다. 이미지 설명에서는 특정 사용 사례에 즉시 사용 가능한 AMI를 빌드하기 위해 실행할 기본 운영 체제, 소프트웨어, 커널 구성 및 스크립트를 지정합니다.
AMI 빌드 시간 중에 `nitro-tpm-pcr-compute` 유틸리티를 사용하여 KIWI NG에서 생성된 통합 커널 이미지(UKI)를 기반으로 참조 측정값을 생성해야 합니다. `nitro-tpm-pcr-compute` 유틸리티 사용에 대한 자세한 내용은 [사용자 지정 AMI에 대한 PCR 측정값 계산](create-pcr-compute.md) 섹션을 참조하세요.
AWS에서는 격리된 컴퓨팅 환경에서 EC2 인스턴스를 구성하는 데 필요한 모든 구성을 포함하는 샘플 Amazon Linux 2023 이미지 설명을 제공합니다. 자세한 내용은 [Amazon Linux 2023 이미지 설명 샘플 빌드](build-sample-ami.md) 섹션을 참조하세요.
# Amazon Linux 2023 이미지 설명 샘플 빌드
AWS는 워크로드에 대한 자체 사용자 지정 증명 가능 AMI를 생성하기 위한 시작점으로 사용할 수 있는 Amazon Linux 2023 이미지 설명 샘플을 제공합니다. 이미지 설명 샘플에는 기본 운영 체제로 Amazon Linux 2023, 파일 시스템 불변성에 대한 `dm-verity` 및 `erofs` 구성이 포함되어 있으며, 모든 대화형 액세스(예: SSH, EC2 Instance Connect 및 직렬 콘솔)를 제거하여 격리된 컴퓨팅 환경을 생성합니다. 이미지 설명 샘플에 대한 자세한 내용은 [Github repo](https://github.com/amazonlinux/kiwi-image-descriptions-examples)를 참조하세요.
이미지 설명 샘플은 `/usr/bin/` 디렉터리의 빌드된 이미지에 NitroTPM 도구(`nitro-tpm-pcr-compute` 및 `nitro-tpm-attest`)를 자동으로 설치합니다. 이를 통해 하면 AMI에서 시작된 인스턴스에 도구가 사전 설치됩니다.
이미지 설명 샘플에는 참조 측정값을 생성하는 데 필요한 명령이 포함된 `edit_boot_install.sh` 스크립트가 포함되어 있습니다. 스크립트는 KIWI NG에서 생성한 원시 디스크 이미지 파일(`.raw`)을 루프백 디바이스에 탑재하고 파일 확장자가 `.efi`인 UKI를 찾은 다음 `nitro-tpm-pcr-compute` 유틸리티를 실행하여 AMI에 대한 참조 측정값을 생성합니다. 스크립트는 빌드 시간 중에 KIWI NG에 의해 자동으로 실행됩니다.
이 자습서에서는 이미지 설명 샘플을 빌드하여 증명 가능한 AMI를 생성하는 방법을 보여줍니다.
자체 이미지 설명 생성에 대한 자세한 내용은 다음 KIWI NG 설명서를 참조하세요.
+ [빠른 시작](https://osinside.github.io/kiwi/quickstart.html)
+ [이미지 설명](https://osinside.github.io/kiwi/image_description.html)
+ [Amazon Linux 2023 이미지 설명 샘플](https://github.com/amazonlinux/kiwi-image-descriptions-examples)
사전 조건
이 자습서를 완료하려면 IAM 자격 증명에 다음 권한이 있어야 합니다.
+ `arn:aws:ec2:*::snapshot/*`에 대한 `ebs:CompleteSnapshot`, `ebs:StartSnapshot` 및 `ebs:PutSnapshotBlock`
+ 모든 리소스에서 `ec2:RegisterImage`
**KIWI NG를 사용하여 샘플 Amazon Linux 2023 이미지 설명을 빌드하는 방법**
1. 최신 AL2023 AMI를 사용하여 Amazon EC2 인스턴스를 시작하세요. 인스턴스에 AMI를 빌드하기에 충분한 스토리지 공간이 있는지 확인하려면 최소 12GB의 스토리지를 프로비저닝해야 합니다.
1. 필요한 종속 항목을 설치합니다. 다음 명령은 다음 유틸리티를 설치합니다.
+ `kiwi-cli`
+ `veritysetup`
+ `erofs-utils`
+ `aws-nitro-tpm-tools`
```
sudo dnf install -y kiwi-cli python3-kiwi kiwi-systemdeps-core python3-poetry-core qemu-img veritysetup erofs-utils git cargo aws-nitro-tpm-tools
```
1. `coldsnap` 유틸리티를 설치하세요. 이 유틸리티를 사용하면 원시 이미지 데이터에서 Amazon EBS 스냅샷을 생성할 수 있습니다. 이 유틸리티를 사용하여 KIWI NG에서 생성한 원시 디스크 이미지 파일에서 EBS 스냅샷을 생성합니다.
```
git clone https://github.com/awslabs/coldsnap.git
cd coldsnap
cargo install --locked coldsnap
cd ..
```
1. 이미지 설명 샘플 파일을 가져오세요.
```
sudo dnf install kiwi-image-descriptions-examples
```
이미지 설명 샘플 파일은 `/usr/share/kiwi-image-descriptions-examples/al2023/attestable-image-example` 디렉터리에 다운로드됩니다.
1. KIWI NG `system build` 명령을 사용하여 샘플 이미지 설명을 빌드하세요. 다음 명령은 `./image` 디렉터리에서 원시 디스크 이미지 파일을 생성합니다.
```
sudo kiwi-ng \
--color-output \
--loglevel 0 \
system build \
--description /usr/share/kiwi-image-descriptions-examples/al2023/attestable-image-example \
--target-dir ./image
```
자세한 내용은 [kiwi-ng system build](https://osinside.github.io/kiwi/commands/system_build.html) 설명서를 참조하세요.
1. AMI에 대한 참조 측정값을 가져오세요. 측정값은 이전 단계의 이미지 빌드 시간 중에 `nitro-tpm-pcr-compute` 유틸리티에 의해 생성됩니다. 참조 측정값은 `./image/pcr_measurements.json` 파일에서 찾을 수 있습니다.
측정값은 다음 JSON 형식으로 제공됩니다.
```
{
"Measurements": {
"HashAlgorithm": "SHA384 { ... }",
"PCR4": "PCR4_measurement",
"PCR7": "PCR7_measurement",
"PCR12": "PCR12_measurement"
}
}
```
1. `coldsnap` 유틸리티를 사용하여 KIWI NG에서 생성한 원시 디스크 이미지를 EBS 스냅샷에 업로드하세요. 명령은 스냅샷 ID를 반환합니다. 다음 단계에 필요하므로 ID를 기록하세요
```
SNAPSHOT=$(.cargo/bin/coldsnap upload ./image/al2023*.raw)
echo "Created snapshot: $SNAPSHOT"
```
`coldsnap` 유틸리티에 대한 자세한 내용은 [coldsnap GitHub repo](https://github.com/awslabs/coldsnap)를 참조하세요.
1. 이전 단계의 스냅샷을 사용하여 TPM 2.0 지원 AMI를 UEFI 부팅 모드로 등록하세요. `--architecture`의 경우 Intel에 대해 `x86_64` 또는 Graviton에 대해 `arm64`를 지정하세요.
```
aws ec2 register-image \
--name "attestable_isolated_al2023_ami" \
--virtualization-type hvm \
--boot-mode uefi \
--architecture x86_64|arm64 \
--root-device-name /dev/xvda \
--block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=${SNAPSHOT}} \
--tpm-support v2.0 \
--ena-support
```
# Amazon Linux 2023 이미지 설명 샘플
다음은 Amazon Linux 2023 이미지 설명 샘플의 특징입니다.
1. **통합 커널 이미지(UKI) 부팅** - 커널, `initrd` 및 부팅 파라미터를 변경할 수 없는 하나의 이미지로 결합하는 서명된 단일 바이너리를 사용하여 부팅합니다.
1. **읽기 전용 루트 파일 시스템** - dm-verity 보호와 함께 향상된 읽기 전용 파일 시스템(`erofs`)을 사용하여 루트 파일 시스템을 수정할 수 없고 해당 루트 파일 시스템이 암호화 무결성 확인을 유지하는지 확인합니다.
1. **임시 오버레이 파일 시스템** - `/etc`, `/run` 및 `/var`과 같은 디렉터리에 대한 임시 쓰기를 허용하는 임시 오버레이 파일 시스템을 생성합니다. 이 오버레이 파일 시스템은 메모리에만 존재하므로 인스턴스가 재부팅되면 모든 변경 사항이 자동으로 손실되어 시스템이 원래의 신뢰할 수 있는 상태로 돌아갑니다.
1. **원격 액세스 방법 비활성화됨** - 원격 액세스를 방지하기 위해 다음 원격 액세스 메커니즘을 제거합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/al2023-isolated-compute-recipe.html)
\$1 자세한 내용은 [ Image Description Elements](https://osinside.github.io/kiwi/image_description/elements.html#packages-ignore)를 참조하세요.
# 워크로드에 대한 Amazon Linux 2023 이미지 설명 샘플 사용자 지정
Amazon Linux 2023 이미지 설명 샘플을 사용자 지정하고 특정 워크로드에 필요한 소프트웨어 패키지, 스크립트 및 파일을 포함할 수 있습니다. KIWI NG 이미지 설명의 다양한 요소에 추가하거나 수정하여 사용자 지정할 수 있습니다.
**Topics**
+ [리포지토리 관리](#prepare-custom-image-repos)
+ [패키지 관리](#customize-sample-ami-packages)
+ [파일 및 디렉터리 추가](#customize-sample-ami-overlay)
+ [사용자 지정 스크립트 추가](#customize-sample-ami-script)
## 리포지토리 관리
기본적으로 이미지 설명 샘플에는 Amazon Linux 2023 코어 리포지토리의 미러 엔드포인트를 가리키는 단일 `` 요소가 포함됩니다. 필요한 경우 필요한 소프트웨어를 설치할 다른 리포지토리에 대한 참조를 추가할 수 있습니다.
이미지 설명 샘플은 `` 요소에 정의된 `dnf` 패키지 관리자를 사용합니다.
리포지토리 추가에 대한 자세한 내용은 [Setting up Repositories](https://osinside.github.io/kiwi/concept_and_workflow/repository_setup.html)를 참조하세요.
## 패키지 관리
기본적으로 이미지 설명 샘플에는 `erofs` 읽기 전용 파일 시스템이 있는 격리된 컴퓨팅 환경을 위한 Amazon Linux 2023 증명 가능한 AMI를 생성하는 데 필요한 모든 패키지가 포함되어 있습니다.
이미지 설명의 `` 요소에 추가하여 이미지 설명에 추가 소프트웨어 패키지를 포함할 수 있습니다. `` 요소는 AMI에 설치해야 하는 모든 소프트웨어를 정의합니다.
`` 요소를 사용하여 특정 소프트웨어 패키지를 제거하거나 삭제할 수도 있습니다.
이미지 설명에서 패키지를 추가하거나 제거하는 방법에 대한 자세한 내용은[Adding and Removing Packages](https://osinside.github.io/kiwi/concept_and_workflow/packages.html#)를 참조하세요.
## 파일 및 디렉터리 추가
이미지 설명 샘플에는 오버레이 트리 디렉터리(`/root/`)가 포함됩니다. 오버레이 트리 디렉터리는 이미지 빌드 프로세스 중에 이미지에 복사될 파일과 디렉터리가 포함된 디렉터리입니다. 오버레이 트리 디렉터리에 배치하는 모든 파일과 디렉터리는 이미지 빌드 프로세스 중에 이미지의 루트 파일 시스템에 직접 복사됩니다.
오버레이 트리 디렉터리는 모든 패키지가 설치된 후 이미지에 복사됩니다. 새 파일은 추가되고 기존 파일은 덮어씁니다.
## 사용자 지정 스크립트 추가
이미지 설명 샘플에는 단일 사용자 지정 스크립트(`edit_boot_install.sh`)가 포함되어 있습니다. 이 스크립트에는 `nitro-tpm-pcr-compute` 유틸리티를 실행하는 데 필요한 명령이 포함되어 있으며, 이 명령은 이미지 콘텐츠를 기반으로 참조 측정값을 생성합니다. 이 스크립트는 부트로더가 설치된 직후 직접 호출됩니다.
필요한 경우 이미지 설명에 사용자 지정 스크립트를 포함하여 이미지 빌드 프로세스 중에 또는 이미지를 처음 부팅할 때 작업 또는 구성을 수행할 수 있습니다. 스크립트를 사용하면 이미지 설명만으로는 달성할 수 없는 방식으로 이미지를 사용자 지정할 수 있습니다.
이미지 설명에 사용자 지정 스크립트를 포함하려면 스크립트 유형에 따라 올바른 이름을 지정하고 `appliance.kiwi` 파일과 동일한 디렉터리에 추가해야 합니다. KIWI NG는 이름을 올바르게 지정하고 올바른 위치에 배치된 스크립트를 이미지 설명 파일에서 명시적으로 참조할 필요 없이 자동으로 감지하고 실행합니다.
KIWI NG에서 지원하는 스크립트에 대한 자세한 내용은 [User-Defined Scripts](https://osinside.github.io/kiwi/concept_and_workflow/shell_scripts.html)를 참조하세요.
# 사용자 지정 AMI에 대한 PCR 측정값 계산
`nitro-tpm-pcr-compute` 유틸리티를 사용하면 통합 커널 이미지(UKI)를 기반으로 빌드 시간 동안 증명 가능한 AMI에 대한 참조 측정값을 생성할 수 있습니다.
Amazon Linux 2023 이미지 설명 샘플은 `/usr/bin/` 디렉터리의 빌드된 이미지에 유틸리티를 자동으로 설치합니다. 이미지 설명 샘플에는 이미지 빌드 시간 동안 참조 측정값을 생성하기 위해 유틸리티를 실행하는 데 필요한 명령이 포함된 스크립트도 포함되어 있습니다. 이미지 설명 샘플을 사용하는 경우 유틸리티를 설치하거나 수동으로 실행하지 않아도 됩니다. 자세한 내용은 [Amazon Linux 2023 이미지 설명 샘플 빌드](build-sample-ami.md) 섹션을 참조하세요.
## `nitro-tpm-pcr-compute` 유틸리티 설치
Amazon Linux 2023을 사용하는 경우 다음과 같이 Amazon Linux 리포지토리에서 `nitro-tpm-pcr-compute` 유틸리티를 설치할 수 있습니다.
```
sudo yum install aws-nitro-tpm-tools
```
도구는 `/usr/bin` 디렉터리에 설치됩니다.
## `nitro-tpm-pcr-compute` 유틸리티 사용
유틸리티는 참조 측정값을 생성하기 위해 단일 명령(`nitro-tpm-pcr-compute`)을 제공합니다.
명령을 실행할 때 다음을 지정해야 합니다.
+ 통합 커널 이미지(`UKI.efi`) - 표준 부팅 및 UEFI에 필요합니다.
**증명 가능한 AMI에 대한 참조 측정값을 생성하는 방법:**
다음 명령과 파라미터를 사용합니다.
```
/usr/bin/nitro-tpm-pcr-compute \
--image UKI.efi
```
유틸리티는 참조 측정값을 다음 JSON 형식으로 반환합니다.
```
{
"Measurements": {
"HashAlgorithm": "SHA384 { ... }",
"PCR4": "PCR4_measurement",
"PCR7": "PCR7_measurement",
"PCR12": "PCR12_measurement"
}
}
```
`nitro-tpm-pcr-compute` 유틸리티 사용 방법에 대한 실제 예제는 [Amazon Linux 2023 이미지 설명 샘플](build-sample-ami.md)에 포함된 `edit_boot_install.sh` 스크립트를 참조하세요.
# 증명을 위해 AWS KMS 준비
**참고**
서드 파티 서비스를 증명하는 경우 증명 문서를 수신, 구문 분석 및 검증하기 위한 자체 사용자 지정 메커니즘을 빌드해야 합니다. 자세한 내용은 [NitroTPM 증명 문서 검증](nitrotpm-attestation-document-validate.md) 섹션을 참조하세요.
증명 가능한 AMI를 생성한 후에는 Amazon EC2 인스턴스의 요청을 검증하는 데 사용할 수 있는 참조 측정값이 있어야 합니다. AWS KMS에서는 NitroTPM을 사용한 증명에 대한 기본 지원을 제공합니다.
보안 암호 데이터를 암호화하는 데 사용한 AWS KMS 키의 경우, 증명 가능한 AMI 생성 프로세스에서 생성한 참조 측정값과 일치하는 측정값을 포함한 증명 문서가 API 요청에 포함된 경우에만 키 액세스를 허용하는 키 정책을 추가합니다. 표준 부팅의 경우 PCR4 및 PCR12 측정값을 사용하고, 보안 부팅의 경우 PCR7 측정값을 사용합니다. 이를 통해 증명 가능한 AMI를 사용하여 시작된 인스턴스의 요청만 AWS KMS 키를 사용하여 암호화 작업을 수행할 수 있습니다.
AWS KMS에서는 NitroTPM KMS 키 정책에 대한 증명 기반 조건을 생성할 수 있도록 하는 `kms:RecipientAttestation:NitroTPMPCR4`, `kms:RecipientAttestation:NitroTPMPCR7` 및 `kms:RecipientAttestation:NitroTPMPCR12` 조건 키를 제공합니다. 자세한 내용은 [Condition keys for NitroTPM](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-nitro-tpm.html)을 참조하세요.
예를 들어 다음 AWS KMS 키 정책은 요청이 `MyEC2InstanceRole` 인스턴스 프로파일이 연결된 인스턴스에서 시작되는 경우 그리고 특정 PCR 4 및 PCR 12 값을 포함하는 증명 문서가 요청에 포함된 경우에만 키 액세스를 허용합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow requests from instances with attested AMI only",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/MyEC2InstanceRole"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:GenerateRandom"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"kms:RecipientAttestation:NitroTPMPCR4":"EXAMPLE6b9b3d89a53b13f5dfd14a1049ec0b80a9ae4b159adde479e9f7f512f33e835a0b9023ca51ada02160EXAMPLE",
"kms:RecipientAttestation:NitroTPMPCR12":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
}
}
]
}
```
# NitroTPM 증명 문서 가져오기
증명 문서는 NitroTPM 증명 프로세스의 핵심 구성 요소입니다. 여기에는 인스턴스의 ID를 확인하고 신뢰할 수 있는 소프트웨어만 실행 중임을 증명하는 데 사용할 수 있는 일련의 암호화 측정값이 포함되어 있습니다. NitroTPM 증명에 대한 기본 지원을 제공하는 AWS KMS에서 증명 문서를 사용하거나 자체 암호화 증명 메커니즘을 빌드할 수 있습니다.
`nitro-tpm-attest` 유틸리티를 사용하면 런타임 중에 Amazon EC2 인스턴스에 대해 서명된 NitroTPM 증명 문서를 검색할 수 있습니다.
Amazon Linux 2023 이미지 설명 샘플은 `/usr/bin/` 디렉터리의 빌드된 이미지에 유틸리티를 자동으로 설치합니다. 이를 통해 하면 AMI를 사용하여 시작된 인스턴스에 유틸리티가 사전 설치됩니다. 유틸리티를 수동으로 설치하지 않아도 됩니다. 자세한 내용은 [Amazon Linux 2023 이미지 설명 샘플 빌드](build-sample-ami.md) 섹션을 참조하세요.
**Topics**
+ [`nitro-tpm-attest` 유틸리티 설치](#nitro-tpm-attest-install)
+ [`nitro-tpm-attest` 유틸리티 사용](#nitro-tpm-attest-use)
+ [NitroTPM 증명 문서](nitrotpm-attestation-document-content.md)
+ [증명 문서 검증](nitrotpm-attestation-document-validate.md)
## `nitro-tpm-attest` 유틸리티 설치
Amazon Linux 2023을 사용하는 경우 다음과 같이 Amazon Linux 리포지토리에서 `nitro-tpm-attest` 유틸리티를 설치할 수 있습니다.
```
sudo yum install aws-nitro-tpm-tools
```
## `nitro-tpm-attest` 유틸리티 사용
유틸리티는 증명 문서를 검색하기 위한 단일 명령(`nitro-tpm-attest`)을 제공합니다. 이 명령은 Concise Binary Object Representation(CBOR)으로 인코딩되고 CBOR 객체 서명 및 암호화(COSE)를 사용하여 서명된 증명 문서를 반환합니다.
명령을 실행할 때 다음과 같은 선택적 파라미터를 지정할 수 있습니다.
+ `public-key` - AWS KMS 또는 외부 서비스에서 응답 데이터가 반환되기 전에 응답 데이터를 암호화하는 데 사용할 수 있는 퍼블릭 키. 이를 통해 프라이빗 키를 소유한 의도한 수신자만 데이터를 해독할 수 있습니다. 예를 들어 AWS KMS로 증명하는 경우 이 서비스는 증명 문서의 퍼블릭 키로 일반 텍스트 데이터를 암호화하고 응답의 `CiphertextForRecipient` 필드에 결과적으로 생성된 사이퍼텍스트를 반환합니다. RSA 키만 지원됩니다.
+ `user-data` - 사용자 데이터를 사용하여 서명된 추가 데이터를 외부 서비스로 전송할 수 있습니다. 이 사용자 데이터는 요청 인스턴스와 외부 서비스 간에 합의된 프로토콜을 완료하는 데 사용할 수 있습니다. AWS KMS를 사용한 증명에는 사용되지 않습니다.
+ `nonce` - nonce를 사용하여 인스턴스와 외부 서비스 간에 챌린지 및 응답 인증을 설정하여 위장 공격을 방지할 수 있습니다. nonce를 사용하면 외부 서비스가 이전 증명 문서를 재사용하는 위장자가 아닌 활성 인스턴스와 상호 작용하는지 확인할 수 있습니다. AWS KMS를 사용한 증명에는 사용되지 않습니다.
**증명 문서를 검색하는 방법**
다음 명령과 선택적 파라미터를 사용합니다.
```
/usr/bin/nitro-tpm-attest \
--public-key rsa_public_key \
--user-data user_data \
--nonce nonce
```
RSA 키 페어를 생성하는 방법과 퍼블릭 키를 사용하여 증명을 요청하는 방법을 보여주는 전체 예제는 [nitro-tpm-attest GitHub repo](https://github.com/aws/NitroTPM-Tools/)를 참조하세요.
# NitroTPM 증명 문서 콘텐츠
증명 문서는 NitroTPM에서 생성되며 Nitro 하이퍼바이저에서 서명됩니다. 여기에는 Amazon EC2 인스턴스와 관련된 일련의 플랫폼 구성 레지스터(PCR) 값이 포함됩니다. 다음 PCR이 증명 문서에 포함됩니다.
**중요**
PCR0 및 PCR1은 일반적으로 AWS에 의해 제어되는 초기 부팅 코드를 측정하는 데 사용됩니다. 초기 부팅 코드를 안전하게 업데이트할 수 있도록 이러한 PCR에는 항상 상수 값이 포함됩니다.
+ `PCR0` - 코어 시스템 펌웨어 실행 코드
+ `PCR1` - 코어 시스템 펌웨어 데이터
+ `PCR2` - 확장 또는 플러그형 실행 코드
+ `PCR3` - 확장 또는 플러그형 펌웨어 데이터
+ `PCR4` - 부트 관리자 코드
+ `PCR5` - 부트 관리자 코드 구성, 데이터 및 GPT 파티션 테이블
+ `PCR6` - 호스트 플랫폼 제조업체 세부 정보
+ `PCR7` - 보안 부팅 정책
+ `PCR8 - 15` - 정적 운영 체제에서 사용하도록 정의됨
+ `PCR16` - 디버그
+ `PCR23` - 애플리케이션 지원
**PCR4**, **PCR7** 및 **PCR12**는 특히 인스턴스가 증명 가능한 AMI를 사용하여 시작되었는지 검증하는 데 사용됩니다. PCR4 및 PCR12는 표준 부팅으로 검증하는 데 사용할 수 있고 PCR7은 보안 부팅으로 검증하는 데 사용할 수 있습니다.
+ **PCR4(부트 관리자 코드)** - 인스턴스가 시작되면 NitroTPM은 UEFI 환경에서 실행되는 모든 바이너리의 암호화 해시를 생성합니다. 증명 가능한 AMI를 사용하면 이러한 부트 바이너리에 일치하는 해시가 없는 바이너리의 향후 로드를 방지하는 해시가 포함되어 있습니다. 이러한 방법으로 단일 부트 바이너리 해시는 인스턴스가 실행할 코드를 정확하게 설명할 수 있습니다.
+ **PCR7(보안 부팅 정책)** - UEFI 보안 부팅 서명 키로 UEFI 부팅 바이너리에 서명할 수 있습니다. UEFI 보안 부팅이 활성화되면 UEFI는 구성된 정책과 일치하지 않는 UEFI 부팅 바이너리의 실행을 방지합니다. PCR7에는 인스턴스의 UEFI 보안 부팅 정책의 해시가 포함되어 있습니다.
인스턴스 업데이트 전반에 걸쳐 지속되는 단일 KMS 정책을 유지해야 하는 경우 PCR7로 검증하는 정책을 생성하여 UEFI 보안 부팅 인증서를 검증할 수 있습니다. 증명 가능한 AMI를 생성하는 동안 인증서로 부트 바이너리에 서명하고 AMI의 UEFI 데이터에서 유일하게 허용되는 인증서로 설치할 수 있습니다. 이전의 신뢰할 수 없는 AMI에서 시작된 인스턴스가 KMS 정책을 통과하지 못하게 하려는 경우에도 이 모델에서는 여전히 새 인증서를 생성하고 정책에 설치한 후 AMI를 업데이트해야 합니다.
+ **PCR12** — UEFI 부팅 바이너리에 전달된 명령줄의 해시를 포함합니다. 표준 부팅의 경우, 명령줄이 변경되지 않았음을 검증하기 위해 PCR4와 함께 필수로 사용됩니다.
# NitroTPM 증명 문서 검증
**참고**
이 주제는 서드 파티 키 관리 서비스를 사용하고 자체 증명 문서 검증 메커니즘을 빌드해야 하는 사용자를 대상으로 합니다.
이 주제에서는 전체 NitroTPM 증명 흐름에 대한 상세 개요를 제공합니다. 또한 증명 문서가 요청될 때 AWS Nitro 시스템에서 생성되는 내용을 설명하고 키 관리 서비스가 증명 문서를 처리하는 방법을 설명합니다.
**Topics**
+ [증명 문서](#doc-def)
+ [증명 문서 검증](#validation-process)
증명의 목적은 인스턴스가 실행 중인 코드와 구성을 기반으로 신뢰할 수 있는 엔터티임을 증명하는 것입니다. 인스턴스에 대한 신뢰의 근간에는 증명 문서를 제공하는 AWS Nitro 시스템이 있습니다.
증명 문서는 모든 서비스에 통합할 수 있는 게시된 인증 기관을 포함하는 AWS Nitro 증명 퍼블릭 키 인프라(PKI)에 의해 서명됩니다.
## 증명 문서
증명 문서는 Concise Binary Object Representation(CBOR)으로 인코딩되고 CBOR 객체 서명 및 암호화(COSE)를 사용하여 서명됩니다.
CBOR에 대한 자세한 내용은 [RFC 8949: Concise Binary Object Representation (CBOR)](https://www.rfc-editor.org/rfc/rfc8949.html)을 참조하세요.
### 증명 문서 사양
다음은 증명 문서의 구조를 보여줍니다.
```
AttestationDocument = {
module_id: text, ; issuing Nitro hypervisor module ID
timestamp: uint .size 8, ; UTC time when document was created, in
; milliseconds since UNIX epoch
digest: digest, ; the digest function used for calculating the
; register values
nitrotpm_pcrs: { + index => pcr }, ; map of PCRs at the moment the Attestation Document was generated
certificate: cert, ; the public key certificate for the public key
; that was used to sign the Attestation Document
cabundle: [* cert], ; issuing CA bundle for infrastructure certificate
? public_key: user_data, ; an optional DER-encoded key the attestation
; consumer can use to encrypt data with
? user_data: user_data, ; additional signed user data, defined by protocol
? nonce: user_data, ; an optional cryptographic nonce provided by the
; attestation consumer as a proof of authenticity
}
cert = bytes .size (1..1024) ; DER encoded certificate
user_data = bytes .size (0..1024)
pcr = bytes .size (32/48/64) ; PCR content
index = 0..31
digest = "SHA384"
```
증명 문서의 선택적 파라미터(`public_key`, `user_data`, `nonce`)를 사용하여 증명 인스턴스와 외부 서비스 간에 사용자 지정 검증 프로토콜을 설정할 수 있습니다.
## 증명 문서 검증
Nitro 하이퍼바이저에서 증명 문서를 요청하는 경우 서명된 증명 문서가 포함된 바이너리 BLOB이 수신됩니다. 서명된 증명 문서는 CBOR로 인코딩되고 COSE로 서명된 객체(COSE\$1Sign1 서명 구조 사용)입니다. 전체 검증 프로세스에는 다음 단계가 포함됩니다.
1. CBOR 객체를 디코딩하고 COSE\$1Sign1 구조에 매핑하세요.
1. COSE\$1Sign1 구조에서 증명 문서를 추출하세요.
1. 인증서의 체인을 확인하세요.
1. 증명 문서에 올바르게 서명되었는지 확인하세요.
증명 문서는 상용 AWS 파티션에 대한 루트 인증서를 포함하는 AWS Nitro 증명 PKI에 의해 서명됩니다. 루트 인증서는 [https://aws-nitro-enclaves.amazonaws.com/AWS\$1NitroEnclaves\$1Root-G1.zip](https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip)에서 다운로드할 수 있으며 다음 지문을 사용하여 확인할 수 있습니다.
```
64:1A:03:21:A3:E2:44:EF:E4:56:46:31:95:D6:06:31:7E:D7:CD:CC:3C:17:56:E0:98:93:F3:C6:8F:79:BB:5B
```
루트 인증서는 AWS Certificate Manager 프라이빗 인증 기관(AWS Private CA)의 프라이빗 키에 기반하며 수명은 30년입니다. PCA의 제목 형식은 다음과 같습니다.
```
CN=aws.nitro-enclaves, C=US, O=Amazon, OU=AWS
```
**Topics**
+ [COSE 및 CBOR](#COSE-CBOR)
+ [의미 체계 유효성](#semantic-validation)
+ [인증서 유효성](#cert-validity)
+ [인증서 체인 유효성](#chain)
### COSE 및 CBOR
일반적으로 COSE\$1Sign1 서명 구조는 메시지에 하나의 서명만 배치되는 경우에 사용됩니다. 콘텐츠와 서명을 처리하는 파라미터는 COSE\$1Sign을 분리하는 대신 보호된 헤더에 배치됩니다. 구조는 사용할 컨텍스트에 따라 태그가 지정되거나 지정되지 않은 상태로 인코딩할 수 있습니다. 태그가 지정된 COSE\$1Sign1 구조는 CBOR 태그 18로 식별됩니다.
본문, 서명 그리고 본문 및 서명에 대한 정보를 전달하는 CBOR 객체를 COSE\$1Sign1 구조라고 합니다. COSE\$1Sign1 구조는 CBOR 배열입니다. 배열에는 다음 필드가 포함됩니다.
```
[
protected: Header,
unprotected: Header,
payload: This field contains the serialized content to be signed,
signature: This field contains the computed signature value.
]
```
증명 문서의 컨텍스트에서 배열에는 다음이 포함됩니다.
```
18(/* COSE_Sign1 CBOR tag is 18 */
{1: -35}, /* This is equivalent with {algorithm: ECDS 384} */
{}, /* We have nothing in unprotected */
$ATTESTATION_DOCUMENT_CONTENT /* Attestation Document */,
signature /* This is the signature */
)
```
CBOR에 대한 자세한 내용은 [RFC 8949: Concise Binary Object Representation (CBOR)](https://www.rfc-editor.org/rfc/rfc8949.html)을 참조하세요.
### 의미 체계 유효성
증명 문서에는 항상 다음 순서로 CA 번들이 포함됩니다.
```
[ ROOT_CERT - INTERM_1 - INTERM_2 .... - INTERM_N]
0 1 2 N - 1
```
[Java PKI API Programmer’s Guide](https://docs.oracle.com/javase/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html)의 Java CertPath와 같은 일부 기존 도구는 다른 순서로 정렬되어야 할 수 있으므로 이 순서를 염주에 두어야 합니다.
인증서를 검증하려면 증명 문서 CA 번들에서 시작하여 필요한 체인을 생성합니다. 여기서 `TARGET_CERT`는 증명 문서의 인증서입니다.
```
[TARGET_CERT, INTERM_N, ..... , INTERM_2, INTERM_1, ROOT_CERT]
```
### 인증서 유효성
체인의 모든 인증서에서 현재 날짜가 인증서에 지정된 유효 기간에 포함되는지 확인해야 합니다.
### 인증서 체인 유효성
일반적으로 한 CA가 서명한 퍼블릭 키 소유자의 인증서와 다른 CA가 서명한 0개 이상의 추가 CA 인증서로 구성된 여러 인증서 체인이 필요할 수 있습니다. 퍼블릭 키 사용자는 제한된 수의 보장된 CA 퍼블릭 키로만 초기화되므로 인증 경로라고 하는 이러한 체인이 필요합니다. 인터넷 PKI에 대한 인증 경로 검증 절차는 X.509에 제공된 알고리즘에 기반합니다. 인증 경로 처리 시 주체 고유 이름 및/또는 주체 대체 이름과 주체 퍼블릭 키 간의 바인딩을 확인합니다. 바인딩은 신뢰 당사자가 지정한 경로 및 입력을 구성하는 인증서에 지정된 제약 조건에 의해 제한됩니다. 기본 제약 조건 및 정책 제약 조건 확장을 통해 인증 경로 처리 로직이 의사 결정 프로세스를 자동화할 수 있습니다.
**참고**
검증을 수행할 때 CRL을 비활성화해야 합니다.
Java를 사용하면 루트 경로 및 생성된 인증서 체인부터 시작하여 다음과 같이 체인 검증이 수행됩니다.
```
validateCertsPath(certChain, rootCertficate) {
/* The trust anchor is the root CA to trust */
trustAnchors.add(rootCertificate);
/* We need PKIX parameters to specify the trust anchors
* and disable the CRL validation
*/
validationParameters = new PKIXParameters(trustAnchors);
certPathValidator = CertPathValidator.getInstance(PKIX);
validationParameters.setRevocationEnabled(false);
/* We are ensuring that certificates are chained correctly */
certPathValidator.validate(certPath, validationParameters);
}
```
# AWS KMS과 통합
인스턴스에는 NitroTPM에서 검색된 증명 문서를 사용하여 AWS KMS API 요청을 수행할 수 있는 애플리케이션이 있어야 합니다. 증명 문서를 사용하여 요청하는 경우 AWS KMS는 제공된 증명 문서의 측정값을 KMS 키 정책의 참조 측정값과 비교하여 검증합니다. 요청은 증명 문서의 측정값이 KMS 키 정책의 참조 측정값과 일치하는 경우에만 허용됩니다.
증명 문서를 사용하여 [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html), [DeriveSharedSecret](https://docs.aws.amazon.com/kms/latest/APIReference/API_DeriveSharedSecret.html), [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html), [GenerateDataKeyPair](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPair.html) 또는 [GenerateRandom](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateRandom.html) API 작업을 호출하면, 이러한 API는 응답에 포함될 평문을 증명 문서에 포함된 퍼블릭 키로 암호화하며, 평문 대신 사이퍼텍스트를 반환합니다. 이 사이퍼텍스트는 인스턴스에서 생성된 일치하는 프라이빗 키를 사용해야만 해독할 수 있습니다.
자세한 내용은 *AWS Key Management Service 개발자 가이드*의 [Cryptographic attestation for NitroTPM](https://docs.aws.amazon.com/kms/latest/developerguide/services-nitro-enclaves.html)을 참조하세요.
**참고**
서드 파티 서비스를 증명하는 경우 증명 문서를 수신, 구문 분석 및 검증하기 위한 자체 사용자 지정 메커니즘을 빌드해야 합니다. 자세한 내용은 [NitroTPM 증명 문서 검증](nitrotpm-attestation-document-validate.md) 섹션을 참조하세요.
# 자체 운영자로부터 데이터 격리
AWS Nitro 시스템에는 [운영자 액세스 권한이 없습니다](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/no-aws-operator-access.html). AWS 시스템이나 사용자가 Amazon EC2 Nitro 호스트에 로그인하거나 EC2 인스턴스의 메모리에 액세스하거나 암호화된 로컬 인스턴스 스토리지 또는 암호화된 원격 Amazon EBS 볼륨에 저장된 고객 데이터에 액세스할 수 있는 메커니즘이 없습니다.
매우 민감한 데이터를 처리하는 경우 자체 운영자라도 EC2 인스턴스에 액세스하지 못하도록 하여 해당 데이터에 대한 액세스를 제한하는 것이 좋습니다.
격리된 컴퓨팅 환경을 제공하도록 구성된 사용자 지정 증명 가능한 AMI를 생성할 수 있습니다. AMI 구성은 워크로드 및 애플리케이션 요구 사항에 따라 달라집니다. AMI를 빌드하여 격리된 컴퓨팅 환경을 생성하는 경우 다음 모범 사례를 고려합니다.
+ **모든 대화형 액세스 제거**: 이를 통해 운영자 또는 사용자가 인스턴스에 액세스하지 못하도록 합니다.
+ **신뢰할 수 있는 소프트웨어 및 코드만**: 해당 항목만 AMI에 포함해야 합니다.
+ **네트워크 방화벽 구성**: 인스턴스 내에서 네트워크 방화벽을 구성하여 액세스를 차단합니다.
+ **읽기 전용 및 변경 불가능한 상태**: 모든 스토리지 및 파일 시스템에 해당 상태가 적용되었는지 확인합니다.
+ **인스턴스 액세스 제한**: 인증, 권한 부여 및 로깅된 API 직접 호출로 인스턴스의 액세스를 제한합니다.
# 대화형 액세스 권한이 없는 증명 가능한 AMI 업데이트
격리된 컴퓨팅 환경 AMI를 사용하여 인스턴스를 시작한 후에는 사용자 또는 운영자가 인스턴스에 연결할 방법이 없습니다. 즉, 시작 후 인스턴스에 소프트웨어를 설치하거나 업데이트할 방법이 없습니다.
새 소프트웨어 또는 소프트웨어 업데이트가 필요한 경우 필요한 소프트웨어 또는 소프트웨어 업데이트가 포함된 새 증명 가능한 AMI를 생성해야 합니다. 그런 다음 해당 AMI를 사용하여 새 인스턴스를 시작하거나 원래 인스턴스에서 루트 볼륨 교체를 수행합니다. AMI에서 소프트웨어를 변경하면 새 해시가 생성됩니다.
다음 작업을 수행하면 NitroTPM 증명 문서의 참조 측정값이 변경됩니다.
+ 증명 가능한 AMI로 시작된 인스턴스 중지 및 시작
+ 다른 AMI로 루트 볼륨 교체 수행
이러한 작업을 수행하는 경우 새 참조 측정값으로 증명 서비스를 업데이트해야 합니다. 예를 들어 증명에 AWS KMS를 사용하는 경우 KMS 키 정책을 새 참조 측정값으로 업데이트해야 합니다.
인스턴스는 전체 인스턴스 수명 주기 동안 NitroTPM 키 구성 요소를 유지하고 중지 또는 시작 및 루트 볼륨 교체 작업을 통해 유지됩니다.
# Windows 인스턴스용 Credential Guard
AWS Nitro System은 Amazon Elastic Compute Cloud(Amazon EC2) Windows 인스턴스용 Credential Guard를 지원합니다. Credential Guard는 Windows 커널 보호를 넘어 Windows 사용자 자격 증명 및 코드 무결성 적용과 같은 보안 자산을 보호하기 위해 격리된 환경을 생성할 수 있는 Windows VBS 기능입니다. EC2 Windows 인스턴스를 실행할 때 Credential Guard는 AWS Nitro 시스템을 사용하여 Windows 로그인 자격 증명이 운영 체제 메모리에서 추출되지 않도록 보호합니다.
**Topics**
+ [사전 조건](#credential-guard-prerequisites)
+ [지원되는 인스턴스 시작](#credential-guard-launch-instance)
+ [메모리 무결성 비활성화](#disable-memory-integrity)
+ [Credential Guard 켜기](#turn-on-credential-guard)
+ [Credential Guard가 실행 중인지 확인](#verify-credential-guard)
## 사전 조건
Credential Guard를 활용하려면 Windows 인스턴스가 다음 사전 조건을 충족해야 합니다.
**Amazon 머신 이미지(AMI)**
NitroTPM 및 UEFI Secure Boot를 활성화하도록 AMI를 미리 구성해야 합니다. 지원되는 AMI에 대한 자세한 내용은 [Amazon EC2 인스턴스에서 NitroTPM을 사용하기 위한 요구 사항](enable-nitrotpm-prerequisites.md) 섹션을 참조하세요.
**메모리 무결성**
*하이퍼바이저 보호 코드 무결성(HVCI)* 또는 *하이퍼바이저 적용 코드 무결성*이라고도 하는 *메모리 무결성*은 지원되지 않습니다. Credential Guard를 켜기 전에 이 기능이 비활성화되었는지 반드시 확인해야 합니다. 자세한 내용은 [메모리 무결성 비활성화](#disable-memory-integrity) 섹션을 참조하세요.
**인스턴스 유형**
달리 명시하지 않는 한 `C5`, `C5d`, `C5n`, `C6i`, `C6id`, `C6in`, `C7i`, `C7i-flex`, `M5`, `M5d`, `M5dn`, `M5n`, `M5zn`, `M6i`, `M6id`, `M6idn`, `M6in`, `M7i`, `M7i-flex`, `R5`, `R5b`, `R5d`, `R5dn`, `R5n`, `R6i`, `R6id`, `R6idn`, `R6in` `R7i`, `R7iz`, `T3` 인스턴스 유형은 모든 크기에서 Credential Guard를 지원합니다.
+ NitroTPM에는 공통적으로 필요한 몇 가지 인스턴스 유형이 있지만 Credential Guard를 지원하려면 인스턴스 유형이 앞의 인스턴스 유형 중 하나여야 합니다.
+ 다음은 Credential Guard를 지원하지 않습니다.
+ 베어 메탈 인스턴스.
+ `C7i.48xlarge`, `M7i.48xlarge`, `R7i.48xlarge` 인스턴스 유형.
인스턴스 유형에 대한 자세한 내용은 [Amazon EC2 Intance Types 설명서](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-types.html)를 참조하세요.
## 지원되는 인스턴스 시작
Amazon EC2 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하여 Credential Guard를 지원할 수 있는 인스턴스를 시작할 수 있습니다. 인스턴스를 시작하려면 AWS 리전마다 고유한 호환되는 AMI ID가 필요합니다.
**작은 정보**
다음 링크를 사용하여 Amazon EC2 콘솔에서 호환되는 Amazon 제공 AMI를 사용하여 인스턴스를 검색하고 시작할 수 있습니다.
[https://console.aws.amazon.com/ec2/v2/home?#Images:visibility=public-images;v=3;search=:TPM-Windows_Server;ownerAlias=amazon](https://console.aws.amazon.com/ec2/v2/home?#Images:visibility=public-images;v=3;search=:TPM-Windows_Server;ownerAlias=amazon)
------
#### [ Console ]
**인스턴스 시작**
지원되는 인스턴스 유형과 사전 구성된 Windows AMI를 지정하여 [인스턴스를 시작](ec2-launch-instance-wizard.md)하는 단계를 따르세요.
------
#### [ AWS CLI ]
**인스턴스 시작**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) 명령을 사용하여 지원되는 인스턴스 유형과 미리 구성된 Windows AMI를 사용하여 인스턴스를 시작합니다.
```
aws ec2 run-instances \
--image-id resolve:ssm:/aws/service/ami-windows-latest/TPM-Windows_Server-2022-English-Full-Base \
--instance-type c6i.large \
--region us-east-1 \
--subnet-id subnet-0abcdef1234567890
--key-name key-name
```
------
#### [ PowerShell ]
**인스턴스 시작**
[https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html) 명령을 사용하여 지원되는 인스턴스 유형과 미리 구성된 Windows AMI를 사용하여 인스턴스를 시작합니다.
```
New-EC2Instance `
-ImageId resolve:ssm:/aws/service/ami-windows-latest/TPM-Windows_Server-2022-English-Full-Base `
-InstanceType c6i.large `
-Region us-east-1 `
-SubnetId subnet-0abcdef1234567890 `
-KeyName key-name
```
------
## 메모리 무결성 비활성화
로컬 그룹 정책 편집기를 사용하여 지원되는 시나리오에서 메모리 무결성을 비활성화할 수 있습니다. **가상화 기반 코드 무결성 보호** 아래 각 구성 설정에 대해 다음 지침을 적용할 수 있습니다.
+ **잠금 없이 활성화** - 메모리 무결성을 비활성화하려면 설정을 **비활성화됨**으로 수정하세요.
+ **UEFI 잠금으로 활성화** – 메모리 무결성이 UEFI 잠금으로 활성화되었습니다. 메모리 무결성을 UEFI 잠금으로 활성화한 후에는 비활성화할 수 없습니다. 메모리 무결성이 비활성화된 새 인스턴스를 생성하고 지원되지 않는 인스턴스를 사용하지 않는 경우 종료하는 것이 좋습니다.
**로컬 그룹 정책 편집기로 메모리 무결성을 비활성화하려면**
1. RDP를 사용하여 관리자 권한이 있는 사용자 계정으로 인스턴스에 연결합니다. 자세한 내용은 [RDP 클라이언트를 사용하여 Windows 인스턴스에 연결](connect-rdp.md) 섹션을 참조하세요.
1. 시작 메뉴를 열고 **cmd**를 검색하여 명령 프롬프트를 시작합니다.
1. `gpedit.msc` 명령을 실행하여 로컬 그룹 정책 편집기를 엽니다.
1. 로컬 그룹 정책 편집기에서 **컴퓨터 구성**, **관리 템플릿**, **시스템** 및 **디바이스 가드**를 선택합니다.
1. **가상화 기반 보안 켜기**를 선택한 다음 **정책 설정 편집**을 선택합니다.
1. **가상화 기반 코드 무결성 보호**에 대한 설정 드롭다운을 열고 **비활성화**를 선택한 후 **적용**을 선택합니다.
1. 인스턴스를 재부팅하여 변경 사항을 적용합니다.
## Credential Guard 켜기
지원되는 인스턴스 유형과 호환되는 AMI로 Windows 인스턴스를 시작하고 메모리 무결성이 비활성화되었음을 확인한 후 Credential Guard를 켤 수 있습니다.
**중요**
다음 단계를 수행하여 Credential Guard를 켜려면 관리자 권한이 필요합니다.
**Credential Guard 켜기**
1. RDP를 사용하여 관리자 권한이 있는 사용자 계정으로 인스턴스에 연결합니다. 자세한 내용은 [RDP 클라이언트를 사용하여 Windows 인스턴스에 연결](connect-rdp.md) 섹션을 참조하세요.
1. 시작 메뉴를 열고 **cmd**를 검색하여 명령 프롬프트를 시작합니다.
1. `gpedit.msc` 명령을 실행하여 로컬 그룹 정책 편집기를 엽니다.
1. 로컬 그룹 정책 편집기에서 **컴퓨터 구성**, **관리 템플릿**, **시스템** 및 **디바이스 가드**를 선택합니다.
1. **가상화 기반 보안 켜기**를 선택한 다음 **정책 설정 편집**을 선택합니다.
1. **가상화 기반 보안 켜기** 메뉴에서 **활성화**를 선택합니다.
1. **플랫폼 보안 수준 선택**에서 **보안 부팅 및 DMA 보호**를 선택합니다.
1. **Credential Guard 구성**에서 **UEFI 잠금으로 활성화**를 선택합니다.
**참고**
나머지 정책 설정은 Credential Guard를 활성화하는 데 필요하지 않으며 **구성되지 않음**으로 둘 수 있습니다.
다음 이미지에는 앞서 설명한 대로 구성된 VBS 설정이 표시됩니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/vbs-credential-guard-gpo-enabled.png)
1. 인스턴스를 재부팅하여 설정을 적용합니다.
## Credential Guard가 실행 중인지 확인
Microsoft 시스템 정보(`Msinfo32.exe`) 도구를 사용하여 Credential Guard가 실행 중인지 확인할 수 있습니다.
**중요**
먼저 인스턴스를 재부팅하여 Credential Guard를 활성화하는 데 필요한 정책 설정 적용을 마쳐야 합니다.
**Credential Guard가 실행 중인지 확인**
1. 원격 데스크톱 프로토콜(RDP)을 사용하여 인스턴스에 연결합니다. 자세한 내용은 [RDP 클라이언트를 사용하여 Windows 인스턴스에 연결](connect-rdp.md) 섹션을 참조하세요.
1. 인스턴스에 대한 RDP 세션 내에서 시작 메뉴를 열고 **cmd**를 검색하여 명령 프롬프트를 시작합니다.
1. `msinfo32.exe` 명령을 실행하여 시스템 정보를 엽니다.
1. Microsoft 시스템 정보 도구는 VBS 구성의 세부 정보를 나열합니다. 가상화 기반 보안 서비스 옆에서 **Credential Guard**가 **실행 중**으로 표시되는지 확인합니다.
다음 이미지에는 앞서 설명한 대로 VBS가 실행 중임이 표시됩니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/vbs-credential-guard-msinfo32-enabled.png)
# 인터페이스 VPC 엔드포인트를 사용하여 Amazon EC2에 액세스
VPC와 Amazon EC2 API의 리소스 간에 프라이빗 연결을 생성하여 VPC의 보안 태세를 개선할 수 있습니다. 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 Direct Connect 연결을 사용하지 않고 VPC에 있는 것처럼 Amazon EC2 API에 액세스할 수 있습니다. VPC의 EC2 인스턴스는 Amazon EC2 API에 액세스하는 데 퍼블릭 IP 주소가 필요하지 않습니다.
자세한 정보는 *AWS PrivateLink 가이드*의 [AWS PrivateLink를 통해 AWS 서비스에 액세스](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)를 참조하세요.
**Topics**
+ [인터페이스 VPC 엔드포인트 생성](#create-endpoint)
+ [엔드포인트 정책 생성](#endpoint-policy)
## 인터페이스 VPC 엔드포인트 생성
다음 서비스 이름을 사용하여 Amazon EC2에 대한 인터페이스 엔드포인트를 생성합니다.
+ **com.amazonaws.*region*.ec2** - Amazon EC2 API 작업에 대한 엔드포인트를 생성합니다.
자세한 정보는 *AWS PrivateLink 가이드*의 [인터페이스 VPC 엔드포인트를 사용하여 AWS 서비스에 액세스](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)를 참조하세요.
## 엔드포인트 정책 생성
엔드포인트 정책은 인터페이스 엔드포인트에 연결할 수 있는 IAM 리소스입니다. 기본 엔드포인트 정책을 사용하면 인터페이스 엔드포인트를 통해 Amazon EC2 API에 대한 전체 액세스를 허용합니다. VPC에서 Amazon EC2 API에 허용되는 액세스를 제어하려면 사용자 지정 엔드포인트 정책을 인터페이스 엔드포인트에 연결합니다.
엔드포인트 정책은 다음 정보를 지정합니다.
+ 작업을 수행할 수 있는 보안 주체.
+ 수행할 수 있는 작업
+ 작업을 수행할 수 있는 리소스
**중요**
Amazon EC2에 대한 인터페이스 VPC 엔드포인트에 기본값이 아닌 정책이 적용되면 `RequestLimitExceeded` 실패와 같은 특정 API 요청 실패가 AWS CloudTrail 또는 Amazon CloudWatch에 로깅되지 않을 수 있습니다.
자세한 정보는 *AWS PrivateLink 가이드*의 [엔드포인트 정책을 사용하여 서비스에 대한 액세스 제어](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)를 참조하세요.
다음 예는 암호화되지 않은 볼륨을 생성하거나 암호화되지 않은 볼륨으로 인스턴스를 시작할 수 있는 권한을 거부하는 VPC 엔드포인트 정책을 보여 줍니다. 또한 이 정책 예에서는 다른 모든 Amazon EC2 작업을 수행할 수 있는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": [
"ec2:CreateVolume"
],
"Effect": "Deny",
"Resource": "*",
"Principal": "*",
"Condition": {
"Bool": {
"ec2:Encrypted": "false"
}
}
},
{
"Action": [
"ec2:RunInstances"
],
"Effect": "Deny",
"Resource": "*",
"Principal": "*",
"Condition": {
"Bool": {
"ec2:Encrypted": "false"
}
}
}]
}
```
------