클라우드 기반 취약점 진단

올빼미·2024년 12월 12일

가상화

: 하드웨어를 소프트웨어적으로 표현

클라우드 컴퓨팅

: it리소스를 인터넷을 통해 온디맨드로 제공하고 사용한 만큼만 비용을 지불하는 것

클라우드 컴퓨팅 유형

laaS : 네트워킹,컴퓨터 및 스토리지 공간에 대한 액세스 제공
PaaS : 기본 인프라 관리x > 앱 개발과 관리에 집중 가능
SaaS : "완전한 제품", 인프라 관리x

클라우드 컴퓨팅의 장점

민첩성 : 광범위한 기술에 쉽게 엑세스 가능, 필요에따라 빠르게 구동가능
탄력성 : 필요한 만큼 리소스를 프로비저닝, 리소스 확장과 축소 가능
비용 절감

aws에서 요금을 지불하는 방법

사용량에 따른 요금
커밋을 통한 비용절감
더많이 사용하여 더 적은 비용을 지불

리전

: aws가 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치

가용 영역(AZ)

: aws 리전의 중복 전력, 네트워킹 및 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성

IAM

AWS 서비스 및 리소스에 대한 액세스와 ID를 안전하게 관리
사용자(users), 그룹(group), 역할(role), 정책(policy)으로 구성
리전에 속하는 서비스가 아닌 글로벌 서비스
식별 → 인증 → 인가
- 사용자 : AWS의 기능과 자원을 이용하는 객체
  - 사용자 식별 방법 : 사용자의 고유 식별자 = AWS 계정 ID
  - 사용자 자격증명 방법
    - AWS Managemetn Console 암호
    - Access Key = Accerss Key ID + Secret Access Key
    - SSH Key ⇒ AWS에 생성한 EC2 인스턴스로 SSH 접속할 때 사용
    - 서버 인증서
- 그룹 : 여러 사용자에게 공통으로 권한을 부여하기 위해서 만든 개념
- 권한 : 어떤 작업을 할 수 있는지 여부를 명시한 규칙
- 정책 : 권한을 정의하는 aws의 객체
  - 자격 증명 기반 정책 : 자격증명이 무슨 작업을 어느 리소스에서 어떤 조건에서 수행할 수 있는지를 제어하는 json 권한 정책문서
    - 관리형 정책 : 다수의 사용자, 그룹 및 역활에 독립적으로 연결할수 있는 자격 증명 기반 정책
    - 인라인 정책 : 단일 사용자, 그룹 또는 역활에 직접 추가하는 정책
  - 리소스 기반 정책 : (인라인 정책) S3 버킷과 같은 리소스에 연결하는 정책으로 지정된 보안 주체에 해당 리소스에 대한 특정 작업을 수행할 수 있는 권한을 부여하여 이러한 권한이 적용되는 조건을 정의
  - 권한 경계 : 관리형 정책을 사용해 자격 증명 정책이 IAM 엔티티(사용자 또는 역할)에 부여할 수 있는 최대 권한을 설정하기 위한 고급 기능
json 정책 문서

json 정책문서의 구조

문서 상단에 정책 전반의 선택적 정보
하나 이상의 Statement로 구성
각 Statement에는 단일 권한에 대한 정보가 포함
정책에 여러 Statement가 포함된 경우 AWS는 이를 평가할 때 Statement 전체에 논리 OR를 적용

json 정책 요소

Version
- 정책 언어의 버전
- 최신 버전 "2012-10-17" 사용을 권장
Statement (필수)
- 단일 문 또는 개별 문의 배열을 포함
- "Statement": [ { ... }, { ... }, { ... } ]
Sid
- 문(statement) 배열에서 각 문에 할당
- JSON 정책 내에서 고유해야 하며, 정책 문에 대한 설명으로 사용이 가능
Effect (필수)
- 문의 허용 또는 명시적 거부를 지정
- Allow 또는 Deny 값을 가질 수 있음 (대소문자를 구분)
- 기본적으로 리소스 액세스는 거부되므로, 리소스 액세스를 허용하려면 Effect 요소를 Allow로 설정해야 함
Principal
- 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시
Action (필수)
- 특정 작업의 허용 똔느 거부 여부를 지정
Resources (필수)
- 문에서 다루는 객체를 ARN을 사용해 지정
Condition
- 정책이 효력이 발생하는 시점에 대한 조건을 지정
  "Condition" : { "{condition-operator}" : { "{condition-key}" : "{condition-value}" } }

JSON 정책 구문 예시

자격 증명 기반 정책으로 example_bucket이라는 하나의 Amazon S3 버킷 목록을 암시된 보안 주체를 허용 한다.

{
	"Version": "2012-10-17", 
	"Statement": {
		"Resource": "arn:aws:s3:::exampel_bucket", 
		"Action": "s3:ListBucket", 
		"Effect": "Allow"
	}
}

모든 리소스에 모든 동작을 허용

{
	"Version": "2012-10-17", 
	"Statement": {
		"Resource": "*", 
		"Action": "*", 
		"Effect": "Allow"
	}
}

!! 안전한 권한 부여 방법 ⇒ 최소 권한 부여

방법 1. 모든 리소스에 모든 동작을 허용 → 필요 이상의 권한을 부여 ⇒ 안전하지 않음

방법 2. DynamoDB에 대한 액션을 구체화 ⇒ DynamoDB의 모든 테이블에 대해 read/write가 가능 ⇒ (접근하면 안 되는) 다른 테이블에 대해서도 접근이 가능하므로 안전하지 않음

방법 3. 사용할 테이블을 제한(한정) ⇒ myDynamoDBTable에 대해서만 read/write 하도록 제한

방법 4. 특정 조건을 명시 ⇒ IP 주소가 1.2.3.4인 곳에서 접근하는 경우에만 myDynamoDBTable에 read/write할 수 있도록 제한

CSRF = 크로스 사이트 요청 위조

: 요청의 절차와 주체를 확인하지 않고 요청을 처리했을 때 발생하는 문제
-> 희생자의 권한으로 요청이 처리

방어기법 1. 요청의 절차를 확인
- 토큰을 이용해서 요청 절차를 검증 ⇒ 선행 페이지에 토큰을 전달하고 요청으로 전달된 토큰을 검증
- CAPTCHA
- reCAPTCHA
방어 기법 2. 요청 주체를 확인 ⇒ 주요 기능에 대해서는 재인증, 재인가
- 주요기능 : 생성, 수정, 삭제하는 기능, 중요 정보(개인 정보, 인증 정보, 금융 정보, ...)를 취급하는 기능, 과금이 발생하는 경우
- 임의의 값을 생성 → abc > 서버에서 보관
- 패스워드 변경처리
  - 1. 인증 여부를 확인
  - 1. 요청처리에 필요한 값이 전달되었는지 확인 > newpw
  - 1. 요청처리에 필요한 서버 내부의 값을 추출 > 세션 > userid
  - 1. 요청을 통해 전달된 값과 서버에서 보관하고 있는 값이 일치하면 요청을 처리!
  - 1. userid의 패스워드를 newpd로 업데이트
- 변경 버튼을 클릭하면 서버가 부여한 토큰 값이 자동으로 서버로 전달 > 토큰 생성, 전달 과정에 사용자가 관여하지 않음
  
  -> CAPTCHA : 자동화된 요청을 방지 = 요청 생성 과정에 사용자가 개입하도록 만듬 > 사용자와의 상호작용을 통해서 요청 처리

AWS CLI 명령어

List* ⇒ 자원의 목록을 나열(목록 조회)하는 데 사용
예) ListBuckets, ListInstances, ListUsers
Describe* ⇒ 특정 리소스에 대한 세부 정보를 확인
예) DescribeInstances, DescribeDBInstances, DescribeVolumes
Get* ⇒ 자원 자체 또는 특정 데이터를 가져오는 작업
예) GetObject (S3 객체(파일) 다운로드)
Put* ⇒ 기존 자원에 데이터를 쓰거나 업데이트
예) PutObject (S3에 파일을 업로드)
Create* ⇒ 새로운 자원(리소스)를 생성
예) CreateBucket, CreateInstance, CreateDBInstance

AWS 클라우드 보안 가이드

1.1 사용자 계정_관리

모든 AWS 리소스는 AWS 계정의 소유이고, 리소스 생성 또는 액세스 권한은 권한 정책에
따라 결정됩니다. 계정 관리자는 IAM 자격 증명(즉, 사용자, 그룹, 역할)에 권한 정책을
연결할 수 있으며 적절한 권한을 통한 서비스 관리가 이루어져야 합니다.

(*) AWS 관리형 정책
서비스 내 FULL ACCESS 등과 같이 중요도가 높은 AWS 관리형 정책은 EC2 서비스
관리/운영자 및 관련 담당자 외에 다른 IAM 계정에 아래와 같은 권한 할당이 되지 않도록
해야합니다. 그중에서도 AWS Admin Console 관리자(AdministratorAccess) 권한은 다수의
IAM 계정에 설정되지 않도록 관리 조치가 필요합니다

Console Admin = Management Console 관리자 = 루트 사용자 = AWS 가입에 사용한 계정

1.2 IAM 사용자 계정_단일화 관리

모든 AWS 리소스는 AWS 계정의 소유이고, 리소스 생성 또는 액세스 권한은 권한 정책에 따라 결정됩니다. 계정 관리자는 IAM 자격 증명(즉, 사용자, 그룹, 역할)에 권한 정책을 연결할 수 있으며 적절한 권한을 통한 서비스 관리가 이루어져야 합니다.

(*) 적절한 IAM 계정 사용

AWS IAM 계정 생성 시 1인 1계정 발급을 원칙
1명의 담당자가 다수의 IAM 계정을 보유하는 것을 지양
Cloud 서비스 리소스 사용이 필요할 경우 내부 정책을 기준으로 목적에 맞게 권한이 부여되어야 합니다.
※ Cloud 서비스 별 IAM 계정 생성 및 관리 금지

1.3 IAM 사용자 계정_식별 관리

IAM 사용자 계정에는 태그를 추가 가능
태그 : 사용자를 표현하는 정보 및 직책의 내용을 포함, IAM 사용자에 대한 액세스 구성, 추정 또는 제어가 가능

1.4 IAM 그룹 사용자_계정 관리

IAM 그룹 사용자(IAM 사용자들의 집합)
- 그룹에 대한 IAM 권한 적용 시 그룹 내 사용자들에게 일괄 적용
- AWS 사용자들에 대한 권한을 쉽게 관리

IAM 사용자 계정 단일화 관리

태그 설정 여부 확인
태그의 이름과 계정이 1:1 관계를 유지하는지 확인
list-user-tags 명령어 사용
그가 지정되어 있지 않으면 취약

IAM 역할 및 권한에 대한 현황을 확인

사용자 그룹에 할당된 권한을 조회
⇒ list-attached-group-policies (그룹에 연결된 관리형 정책을 조회)
⇒ list-group-policies (그룹에 연결된 인라인 정책을 조회)
=> get-group-policy(그룹에 적용된 인라인 정책 문서의 내용을 조회)

1.5 Key Pair_접근 관리

EC2는 키(Key)를 이용한 암호화 기법을 제공
Key Pair : 퍼블릭/프라이빗 키를 통해 각각 데이터의 암호화 및 해독을 하는데 사용되는 키
보안성을 향상시킬 수 있으므로 EC2 인스턴스 생성 시 Key Pair 등록을 권장
Amazon EC2에 사용되는 키는 ‘2048비트 SSH-2 RSA 키’ + Key Pair는 리전당 최대 5천 개까지 보유 가능

암호화 / 복호화

원문 --(알고리즘+키)--> 암호문
- 암호화 : 원문 > 암호문
- 복호화 : 암호문 > 원문
암복호화가 가능 = 양방향 암호화 시스템
대칭키 암호화 VS 공개키 암호화
- 대칭키 암호화 : 암호화키=복호화키
  -> 유일키,비밀키,관용 암호화 방식
  -> 키 분배 및 관리 중요
- 비대칭키 암호화 : 암호화키 != 복호화키
  -> 개인키/공개키=키쌍을 생성, 암복호화에 다른 키 사용
  -> 공개키 암호화
Hash = Message Digest = 암호화만 가능! = 단방향 암호화 시스템
- 단방향성 : 인증 정보 저장 및 인증 처리
- 유일성 : 무결성 검사 ㄱㄴ
- 가능한 공격 : 사전 대입 공격, 무작위 대입 공격, 레인보우 테이블을 이용한 공격

1.6 Key Pair_보관 관리

Key Pair 는 타 사용자가 확인이 가능한 공개된 위치에 보관하게 될 경우 > EC2 Instance 에 무단으로 접근이 가능 > 비인가자가 쉽게 유추 및 접근이 불가능한 장소에 보관해야 함

키 페어 목록을 조회 > 키페어가 퍼블릭 접근이 불가능한 S3 버킷에 저장되어 있는지 확인
- 키 페어가 없는 경우 → 해당 없음
- 키 페어가 있는 경우
  - 퍼블릭 접근이 가능한 S3 버킷에 키 페어가 저장되어 있으면 → 취약
  - 퍼블릭 접근이 불가능한 S3 버킷에 키 페어가 저장되어 있으면 → 양호

Flask 기반 웹 애플리케이션 개발

Flask : python의 마이크로 웹 프레임워크
static : 정적 리소스(이미지, CSS파일,JS 파일...) 가 위치
template : 템플릿 파일이 위치

리다이렉션 취약점 = 신뢰되지 않는 URL 주소로 자동접속 연결

1.7 Admin Console 관리자_정책 관리

루트 사용자 계정(AWS Cloud 사용을 위해 처음 발급한 계정) : IAM 사용자 계정과 달리 모든 서비스에 접근할 수 있는 최고 관리자 계정

인터넷 연결이 가능한 망에서 계정 정보를 인력하여 WEB Console에 접근한다.
기본적으로 IAM계정이여야 안전
진단기준 : admin console 계정을 서비스 용도로 사용하지 않은 경우에 양호

1.8 Admin Console 계정_Access Key 활성화 및 사용주기 관리

진단기준 : AWS Admin Console 계정에 Access Key가 존재하지 않고 IAM 사용자 계정에 대한 Access Key 사용 주기가 60일 이내일 경우에 양호로 판단

1.9 MFA 설정

AWS Multi-Factor Authentication(MFA) : 사용자 이름과 암호 외에 보안을 한층 더 강화할 수 있는 방법

사용자가 AWS 웹 사이트에 로그인할 때 사용자 이름과 암호뿐만 아니라 AWS MFA 디바이스의 인증 응답을 입력하라는 메시지가 표시
다중 요소를 통해 AWS 계정 설정 및 리소스에 대한 보안을 높일 수 있다.
MFA를 구현하는 데 사용할 수 있는 세 가지 인증 요소
- 1) 사용자가 알고 있는 것(예: 비밀번호, PIN, 암호) ⇐ 지식 기반 인증
- 2) 사용자가 소유하고 있는 것(예: 스마트폰, USB 드라이브, 토큰 장치) ⇐ 소유 기반 인증
- 3) 사용자의 신체적 특징(예: 지문, 얼굴 인식, 음성 인증) ⇐ 특징 기반 인증
판정 기준 ⇒ AWS 계정 및 IAM 사용자 계정 로그인 시 MFA가 활성화 되어 있을 경우 "양호"로 판정

1.10 AWS 계정 패스워드_정책 관리

AWS Admin Console Account 계정 및 IAM 사용자 계정의 암호 설정할 때 유추하기 쉬운 암호를 설정 > 비 인가된 사용자가 해당 계정을 획득하여 접근 가능성이 존재

안전한 패스워드란 ?
제 3자가 쉽게 추측할수 X, 시스템에 저장되어있는 이용자 정보 또는 인터넷을 통해 전송되는 정보를 해킹하여 이용자의 패스워드를 알아낼 수 없거나 알아낸다 하더라도 많은 시간이 요구되는 패스워드

두 종류 이상의 문자구성과 9자리 이상의 길이로 된 문자열
10자리 이상의 길이로 구성된 문자열(숫자로만 구성X)

판정기준 : Admin Console 및 IAM 계정의 패스워드 복잡성 기준 준수 및 암호 만료/재사용 제한을 설정하고 있을 경우 "양호"로 판정

2.1 인스턴스 서비스_정책 관리

AWS 인스턴스 서비스(EC2, RDS, S3 등)의 리소스 생성 또는 액세스 권한은 권한 정책에 따라 결정됩니다.

판정 기준 : 인스턴스 서비스 IAM 사용 권한이 각각 서비스 역할에 맞게 설정되어 있을 경우 "양호"로 판정
사용 권한이 맞게 설정 = 사용자별로 할당된 권한 정보와 비교
사용 권한이 맞게 설정되어있는지 확인하는 절차(함수)
- list_users() ⇐ 사용자 정보 조회
- list_attached_user_policies() ⇐ IAM 사용자에게 부여된 관리형 정책을 조회
- list_user_polices() ⇐ 사용자에게 부여된 인라인 정책을 조회
- list_groups_for_user() ⇐ 사용자가 속한 그룹을 조회
- list_attached_group_policies() ⇐ 그룹에 할당된 관리형 정책을 조회
- list_group_policies() ⇐ 그룹에 할당된 인라인 정책을 조회

2.2 네트워크 서비스_정책 관리

AWS 네트워크 서비스(VPC, Route 53, Direct Connect 등)의 리소스 생성 또는 액세스 권한은 권한 정책에 따라 결정됩니다.

2.3 기타 서비스_정책 관리

AWS 기타 서비스(CloudWatch, CloudTrail, KMS 등)의 리소스 생성 또는 액세스 권한은 권한 정책에 따라 결정됩니다.

3. 가상 리소스 관리

3.1 보안 그룹 인/아웃바운드_ANY 설정 관리

VPC에서의 보안 그룹의 역활 : EC2 인스턴스에 대한 인/아웃바운드 트래픽을 제어하는 가상 방화벽 역할
VPC에서 EC2 인스턴스를 시작할 때 최대 5개의 보안 그룹에 인스턴스를 할당가능
보안 그룹은 서브넷 수준이 아니라 인스턴스 수준에서 작동하므로 VPC에 있는 서브넷의 각 인스턴스를 서로 다른 보안 그룹 세트에 할당 가능
보안 그룹은 인/아웃바운드의 규칙 편집을 통해 특정 소스(출발지)에서의 통신이 가능하도록 유형(네트워크 프로토콜) 및 단일/범위 포트를 설정 가능

판정 기준 : 보안 그룹 내 인/아웃바운드의 포트가 Any로 허용되어 있지 않을 경우 "양호"

3.2 보안 그룹 인/아웃바운드_불필요 정책 관리

판정 기준 : 보안 그룹 인/아웃바운드 규칙 내 불필요한 정책(Source, Destination)이 존재하지 않는 경우 "양호"

3.3 네트워크 ACL 인/아웃바운드 트래픽 정책 관리

네트워크 ACL(Access Control List) : 1개 이상의 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC의 선택적 보안 계층
보안 그룹과 비슷한 규칙으로 네트워크 ACL을 설정하여 VPC에 보안 계층을 더 추가 가능
ACL은 VPC 서브넷 계층에서 동작하며 VPC 서브넷과는 1:1로 대응
정책의 방식은 허용(Allow) 및 거부(deny) 정책(WhiteList or BlackList) 기능으로 Stateless 방식으로 사용
VPC에 있는 각 서브넷을 네트워크 ACL과 연결하여 사용할 수 있으며, 서브넷을 네트워크 ACL에 명시적으로 연결하지 않을 경우, 서브넷은 기본 네트워크 ACL에 자동적으로 연결
(단, 하나의 네트워크 ACL은 다수의 서브넷과 연결할 수 있지만 하나의 서브넷은 하나의 ACL에만 연결할 수 있음)

VPC(Vitual Private Cloud)

: AWS 사용자 계정 전용 가상 네트워크

AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리
VPC Peering : 한 AWS 리전 안에서만 존재할 수 있고, 한 리전에 만든 VPC는 다른 리전에서는 보이지 않음
생성시 RFC 1918에 지정된 프라이빗 주소 체계 사용을 권장
- 10.0.0.0/8 ⇒ 10.0.0.0 - 10.255.255.255
- 172.16.0.0/12 ⇒ 172.16.0.0 - 172.31.255.255
- 192.168.0.0/16 ⇒ 192.168.0.0 - 192.168.255.255

기본 VPC 구성요소 (default VPC)

기본 VPC의 생성 방법
- IPv4 CIDR 블록의 크기가 /16인 VPC를 만든다 (172.31.0.0/16).
- 각 가용 영역에 크기 /20의 기본 서브넷을 생성
- 인터넷 게이트웨이를 만들어 기본 VPC에 연결
- 기본 라우팅 테이블에 모든 트래픽(0.0.0.0/0)이 인터넷 게이트웨이로 전달되는 경로를 추가
- 기본 보안 그룹을 만들어 기본 VPC와 연결
- 네트워크 ACL(액세스 제어 목록)을 생성하여 기본 VPC와 연결
- AWS 계정에서 설정된 기본 DHCP 옵션을 기본 VPC와 연결
웹 서비스 환경
대상그룹(타켓그룹) : 어느쪽으로 라우팅할지 정함

1. 네트워크 구성

2. 인스턴스1 생성

3. 인스턴스2 + AMI 생성

4. 로드밸런서 구성

5. 로드밸런서를 통해서만 이용할수 있게 변경

= 개별 인스턴스로 접속 x

코드형 인프라(IaC, Infrastructure as Code)

: 수동 프로세스 및 설정 대신 코드를 사용하여 컴퓨팅 인프라를 프로비저닝하고 지원하는 기능

수동 인프라 관리는 시간이 많이 걸리고 오류가 발생하기 쉽다
코드형 인프라를 사용하면 원하는 상태에 도달하기 위한 모든 단계를 포함하지 않고도 인프라의 원하는 상태를 정의

사이트 신뢰성 엔지니어링(SRE, Site Reliability Engineering)

: 소프트웨어 도구를 사용하여 시스템 관리 및 애플리케이션 모니터링과 같은 IT 인프라 작업을 자동화하는 관행

조직은 SRE를 사용하여 개발 팀의 빈번한 업데이트 중에도 소프트웨어 응용 프로그램의 안정성을 유지
대규모 시스템을 관리하는 것이 수백 대의 기계를 수동으로 관리하는 것보다 지속 가능하기 때문에 확장 가능한 소프트웨어 시스템의 신뢰성을 향상시킨다.

AWS Cloudformation

: AWS 리소스를 모델링하고 설정하여 리소스 관리 시간을 줄이고 AWS에서 실행되는 애플리케이션에 더 많은 시간을 사용하도록 해 주는 서비스

필요한 모든 AWS 리소스를 설명하는 템플릿을 생성하면 CloudFormation이 해당 리소스의 프로비저닝과 구성을 담당
AWS 리소스를 개별적으로 생성하고 구성할 필요가 없으며 어떤 것이 무엇에 의존하는지 파악할 필요도 없음 > CloudFormation에서 모든 것을 처리하기 때문에

구성 요소

템플릿 : JSON 또는 YAML 형식의 텍스트 파일
- AWS 리소스 구축을 위한 청사진으로 사용
스택
- 하나의 단위로 관련 리소스를 관리
- 스택을 생성, 업데이트, 삭제하여 리소스 모음을 생성, 업데이트 및 삭제
- 스택의 모든 리소스는 템플릿으로 정의
변경 세트 : 리소스를 변경하기 전에 제안된 변경 사항 요약
- 변경 세트를 사용하면 변경 사항을 구현하기 이전에 해당 변경이 실행 중인 리소스 특히, 중요 리소스에 미치는 영향을 확인할 수 있다.

CloudFormation 작동 방식

1. Infrastructure Composer (인프라 컴포저) 또는 텍스트 편집기를 사용하여 JSON 또는 YAML 형식으로 템플릿을 생성하거나 수정
2. 템플릿을 로컬 또는 Amazon S3 버킷에 저장
3. 템플릿 파일의 위치(예: 로컬 컴퓨터의 경로 또는 Amazon S3 URL)를 지정하여 스택을 생성 (템플릿에 파라미터가 포함되어 있는 경우 스택을 생성할 때 입력 값을 지정할 수 있음)

변경 세트로 스택 업데이트

3. 업데이트하려는 스택과 수정된 템플릿의 위치(예: 로컬 컴퓨터의 경로 또는 Amazon S3 URL)를 지정하여 변경 세트를 생성합니다. 템플릿에 파라미터가 포함되어 있는 경우 변경 세트를 생성할 때 값을 지정할 수 있습니다.
4. 변경 세트를 보고 기대하는 변경을 CloudFormation에서 수행할지 확인합니다. 예를 들어 CloudFormation에서 중요한 스택 리소스를 대체할지 확인합니다. 원하는 변경 사항을 포함할 때까지 변경 세트는 필요한 만큼 생성할 수 있습니다.

스택 삭제

삭제할 스택을 지정하면 CloudFormation에서는 해당 스택과 스택 내 모든 리소스를 삭제한다.
템플릿을 저장하고 있는 S3 버킷은 별도로 (수동으로) 삭제해야 함

스택 업데이트

: SSH 접속이 가능하도록 등록된 키 페어를 선택하고, 보안그룹에 인바운드 22번 포트를 허용하도록 수정

키 페어가 AWS에 등록되어 있고, 개인키를 가지고 있다
SH로 접속 가능한 IP 대역을 사용자가 입력하도록 해서 접속을 제한
파라미터로 처리 (CIDR 형식에 맞춰서 문자열로 자유롭게 입력)

올빼미

시들시들한 올빼미

이전 포스트