공부용

CTEM 정의

CTEM(지속적 위협 노출 관리): 조직의 공격 표면 전반에서 보안 노출을 지속적으로 식별하고, 실제 위협으로 이어질 가능성을 검증한 뒤, 우선순위에 따라 대응까지 연결하는 선제적 보안 관리 체계.

• 보안 이유 많이 찾아내기 < 조직의 비즈니스와 서비스 환경을 고려한 실제 침해 가능성이 높고 피해 규모가 클 수 있는 노출을 먼저 가려내고 개선

*노출(Exposure): 소프트웨어 취약점 뿐만 아니라 인터넷에 공개된 자산과 서비스/잘못된 클라우드 서비스/불필요하게 유지된 계정/과도한 권한 등 공격자가 침해에 활용할 수 있는 다양한 조건을 포함함.

취약점 관리와 CTEM 차이점

• 취약점 관리(Vulnerability Management): 시스템과 애플리케이션에서 발견된 취약점을 식별하고 기술적 심각도에 따라 패치 또는 설정 변경을 수행하는 데 초점을 둠.
• CTEM: 취약점 관리와 같은 활동을 필요로 하나, 주기적 취약점 점검 및 단발적인 조치에 더해 변화하는 보안 위협을 실시간으로 파악하고 대응하는 체계적인 보안 전략. 개별 취약점의 심각도만으로 대응 순서를 정하는 것이 아니라, 자산 중요도/외부 노출 여부/공격자의 접근 가능성/계정과 권한의 연결 관계/기존 보안 통제의 효과 등을 고려해 실제 위험도 판단.

CTEM 프로세스

조직 환경의 변화에 따라 새롭게 생기는 노출을 확인하고, 실제 위험을 검증하며 개선 결과를 다시 운영에 반영하는 반복 구조.

1. 범위 설정(Scoping): 조직이 보호해야 할 대상과 관리 범위 설정. 침해 사고 발생 시 조직의 비즈니스에 큰 영향을 줄 수 있는 영역이 우선 대상이 됨.
2. 노출 식별(Discovery): 설정된 범위 안에서 공격자가 활용할 수 있는 노출을 찾아내는 단계. 관리 목록에 포함되지 않은 외부 노출 시스템이나 미식별 자산까지 함께 확인.
3. 우선순위화(Prioritization): 식별된 모든 노출을 동일하게 처리하는 것이 아니라, 실제 위험이 큰 항목부터 우선순위를 정함.
4. 검증(Validation): 우선순위가 높은 노출이 실제로 공격에 활용될 수 있는지 확인하는 단계. 조직이 실제로 감수하고 있는 위험을 구체화하고 불필요한 부담을 줄이는 과정.
5. 개선 실행(Mobilization): 패치 적용, 권한 축소, 불필요한 계정 정리, 접근 통제 강화, 네트워크 분리 등 위험을 줄이기 위한 구체적인 조치 수행.

CTEM의 이점

1. 조직이 실제로 줄여야 할 위험을 선별하고 공격자가 활용할 수 있는 노출을 지속적으로 줄여 나가는 데에 이점이 존재.
   → 공격 표면이 넓어지고 보안 경보가 증가하는 환경에서 CTEM은 보안팀이 제한된 자원을 효과적으로 활용할 수 있도록 도움. 보안 사각지대를 줄이고 대응 우선순위를 정할 수 있음.
2. 취약점, 자산, 권한, 위협 정보, 조치 결과를 하나의 흐름으로 연결함으로써 보안 운영을 보다 체계적으로 만듦. 이를 통해 변화하는 IT 환경과 위협에 맞춰 위험을 반복적으로 확인하고 개선할 수 있음.

CTEM 운영에서 SOC

SOC(Security Operations Center, 보안운영센터): 위협 정보를 지속적으로 관찰하고 운영에 반영할 중심 조직.

• 기존: 보안 이벤트를 모니터링하고 침해 여부를 분석/대응하는 역할 수행해옴.
• CTEM 환경: 기존에 더해 공격 표면에서 확인된 노출과 실제 보안 이벤트, 위협 인텔리전스, 자산 정보를 함께 분석해 우선 대응이 필요한 위험을 식별함. 이후 조치가 이루어진 뒤에는 해당 위험이 실제로 줄어들었는지 확인하고, 그 결과를 다시 운영에 반영하는 역할을 맡을 수 있음.

본 게시글은 아래의 링크 속 콘텐츠를 기반으로 작성.

https://www.igloo.co.kr/security-information/ctem%ec%a7%80%ec%86%8d%ec%a0%81-%ec%9c%84%ed%98%91-%eb%85%b8%ec%b6%9c-%ea%b4%80%eb%a6%ac%ec%9d%b4%eb%9e%80-%eb%ac%b4%ec%97%87%ec%9d%b8%ea%b0%80%ec%9a%94/

이 글은 아래의 책을 읽고 공부 목적으로 작성됨.

칼 길버트, 벤자민 카우딜, 「AWS 침투 테스트」

AWS의 IAM 서비스: 사용자의 계정을 인증하는 여러 방법 제공함. 일반적으로 사용자 계정과 역할의 인증 지원.

• IAM 사용자: 환경에 장기적으로 접근해야 할 때 자격증명을 구성하는 방법 제공.
• 역할: 사용자/서비스/애플리케이션에 임시로 필요한 자격증명을 위임하는 방법 제공.
• AWS IAM 그룹: 자주 사용되는 공통 권한을 사용자 그룹에 부여할 수 있음. 사용자는 최대 10개 그룹에 속할 수 있음.

(1) IAM 사용자, 그룹, 역할과 관련 권한 생성

사용자 생성

1. AWS 웹 콘솔에 로그인 후 IAM 서비스 페이지로 이동
2. 사용자 추가 버튼 클릭
3. 액세스 유형:
   - 프로그래밍 방식 액세스: 사용자의 액세스 키 ID와 비밀 액세스 키 생성
   - AWS Management Console 액세스: 사용자가 AWS 웹 콘솔을 접근할 암호를 자동 생성하거나 직접 설정 가능
4. 사용자 이름 적고 다음 버튼
5. 권한 설정 3가지 옵션:
   - IAM 그룹에 사용자 추가
   - 다른 기존 사용자의 권한 복사
   - 기존 IAM 정책을 사용자에게 바로 연결
6. 검색 상자에 AmazonEC2FullAccess 입력 후 체크박스에 체크
   *해당 정책은 사용자에게 EC2 서비스 + EC2와 자주 사용되는 기타 서비스에 대한 전체 액세스 권한 제공
   IAM 정책 2가지 유형:
   - AWS가 관리하는 정책: AWS에서 관리하는 사전에 정의된 권한 집합
   - 고객이 관리하는 정책: 정책을 사용자 맞춤 설정 가능
7. 다음 버튼 - 사용자 추가 버튼
8. 액세스 키 ID와 비밀 액세스 키를 조회하거나 다운하는 옵션 제공됨

역할 또는 그룹 생성 시에도 동일한 과정으로 생성.

• 그룹: 그룹 생성 후 IAM 그룹 페이지에서 '그룹에 사용자 추가' 버튼을 클릭하면 새로운 사용자 추가 가능. 사용자가 속한 그룹 및 적용되는 정책 확인하려면 그룹 탭을 클릭
• 역할: 신뢰 관계라는 중요 기능 존재, 이는 역할을 맡을 수 있는 개체와 어떤 조건에서 발생할 수 있는지 등을 명시함.

(2) IAM 정책으로 API 액션과 접근 가능한 자원 제한

IAM 정책: 계정의 사용자, 역할, 그룹이 권한을 위임하는 방법. 권한이 허용/거부, 권한으로 사용/사용불가 자원, 규칙 적용 조건들이 명시된 JSON 문서.

IAM 정책 구조 예제(JSON)

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "MyGeneralEC2Statement"
			"Effect": "Allow",
			"Action": "ec2:*", "Resource": "*"
		},
        {
			"Effect": "Allow",
			"Action": [
            	"iam:GetUser"
			],
			"Resource": "arn:aws:iam::123456789012:user/TestUser"
		},
        {
			"Effect": "Allow",
			"Action": "sts:AssumeRole",
			"Resource": "*",
			"Condition":
            	{
				"Bool": {
					"aws:MultiFactorAuthPresent": "true"
                    }
				}
		}
	]
}

• Version 키: 사용된 정책 언어의 버전 명시. 최신 버전을 사용하는 것이 권장됨.
• Statement 키: JSON 오브젝트의 statement 목록. Statement는 각 권한의 개별 선언과 관련된 설정. Sid, Effect, Action, NotAction, Principal, Resource, Condition 키로 구성 가능.
  • Sid: 선택적 필드, 정책의 여러 statement를 구분하는 데 도움되도록 사용자가 정한 문자열. 입력 시 읽는 사람의 이해를 도울 수 있음.
  • Effect: 필수적 필드, Allow/Deny로 설정 가능. 열거된 AWS 권한이 허용됐는지, 거부됐는지를 선언함.
  • Action / NotAction: 둘 중 하나는 필수적, AWS 권한 집합 명시. 거의 NotAction보다 Action이 사용됨. 권한은 [AWS 서비스] : [권한] 형식으로 설정됨.
  • Principal: 다른 종류의 IAM 정책에 사용됨. 이 키는 statement가 적용되어야 할 자원을 나타내지만 사용자, 역할, 그룹의 권한 정책에 자동으로 포함됨.
  • Resource: 필수적 필드, Action/NotAction에서 명시된 권한들이 어떤 AWS 자원에 적용되는지에 관한 목록.
  • Condition: 선택적 필드, 어떤 조건에서 statement가 적용되는지 명시.

공격자 입장: IAM 정책이 동작하는 방법을 이해하는 것 중요.

→ 정책을 분석할 수 있으면 현재 환경에서의 정확한 접근 권한, 허용될 거 같은 특정 API 호출이 접근 거부 오류로 실패하는 원인을 파악 가능하기 때문.

키 분석 시, 공격자가 보고 싶은 구문:

{
	"Effect": "Allow",
    "Action": "*",
    "Resource": "*"
}

위의 구문은 관리자 수준의 권한을 제공함.

• * 문자는 와일드카드이고, AWS와 관련한 모든 권한을 허용함을 의미.
• 자원 역시 와일드카드로 명시됐으므로 타깃 계정의 모든 자원에 대해 API 호출 실행 가능.

인라인 정책: 관리형 정책과는 달리 사용자, 역할, 그룹에 직접 생성 가능. 그러나 보안 모범 사례에서는 인라인 정책 사용X를 권장.

(3) IAM 액세스 키 사용

AWS API 호출

1. AWS 명령줄 인터페이스(CLI) 설치:
   pip install awscli --upgrade --user
2. 설치 성공 확인:
   aws --version
3. AWS CLI에 사용자 자격 증명을 추가해 API를 호출하려면, 테스트 프로파일에 자격증명을 저장하도록 함:
   aws configure --profile [사용자명]
4. 액세스 키 ID, 비밀 키 등 값 입력: 앞에서 사용자 생성 시에 표시됐음. 리전 선택, 디폴트 추력 형식=json.
5. 해당 프로파일의 자격증명/설정 업데이트하려면 동일한 명령을 다시 실행. 프로파일 이름은 추가하는 키에 따라 적절하게 변경. 자격증명 사용 시 명심할 것은 API 호출 시 올바른 자격증명이 사용되도록 모든 AWS CLI 명령에 --profile [사용자명] 인자를 포함해야 하는 것.
6. STS(Security Token Service)에서 제공하는 명령어 GetCallerIdentity API: 모든 AWS 사용자 및 역할에서 호출 가능, IAM 정책으로 거부될 수 없음.
   aws sts get-caller-identity --profile [사용자명]
7. 위 명령 후에 출력에는 사용자 ID, 계정 ID, 현재 사용자의 ARN(Amazon 리소스 이름)이 포함됨.
   - 사용자 ID: API의 백엔드에서 사용자를 참조하는 방법.
   - 계정 ID: 사용자가 속한 계정의 ID. 이를 획득한 경우, 타깃 계정에 로그를 남기지 않으면서 계정에 존재하는 사용자와 역할을 열거 가능. 이는 사회 공학 기법에 도움됨.
   
   

서비스 목록 출력 or 참조하는 방법 확인:

#서비스가 인자로 주어지지 않았으므로 이용 가능한 모든 서비스 출력
aws a

#EC2 서비스를 타깃으로 한 실행 가능한 명령어
aws ec2 a

#설명, 제한, 지원되는 인자 등 AWS 서비스/API에 관해 더 많은 정보를 보려면 help 명령 사용
aws ec2 help

#특정 API에 관한 help
aws ec2 describe-instances help

(4) AWS API 요청 서명

대부분의 API는 AWS 서버로 전송 전 포함하고 있는 일부 데이터 서명이 필요. 이는 API 호출자의 신원 확인, 데이터 변조 방지, 재전송 공격을 막는 등의 이유가 존재.

서명은 5분 동안 유효하기 때문에 5분 이내에 요청을 가로채고 다시 전송한다면 재전송 공격은 가능.

대부분의 경우 AWS CLI, AWS SDK가 자동으로 요청 서명을 처리하므로 신경 쓸 필요X. 그러나 수동으로 API 요청을 서명해야 하는 경우가 존재.

→ AWS SDK가 지원되지 않는 프로그래밍 언어 사용하는 경우 / AWS 서버로 전송되는 요청을 완전하기 제어하기를 원하는 경우

AWS API 요청을 서명 v4로 수동 서명하는 프로세스:

1. 표준 요청 생성
2. 서명할 문자열 생성
3. 문자열의 서명 연산
4. HTTP 요청에 서명 추가

자세한 사항은 AWS 문서 확인.

이 글은 아래의 책을 읽고 공부 목적으로 작성됨.

칼 길버트, 벤자민 카우딜, 「AWS 침투 테스트」

해당 장에서는 AWS S3 버킷의 개념, 사용 용도, 구성, 접근 방법을 설명함.

(1) 첫 S3 버킷 구성

1. S3 홈페이지로 이동.
2. 버킷 만들기 클릭.
3. 버킷 이름 입력.
   -고유한 이름 사용, DNS 준수.
   -최소 3글자 ~ 최대 63글자 사이의 길이로 설정.
   -대문자/언더바 문자 허용X.
   -소문자/숫자/하이픈 포함 가능. (.) 문자를 사용해 분리 가능.
   -IP 주소 형태로 설정하지X.
4. 리전은 환경에 맞게 선택.
5. 생성 클릭: 버킷 생성됨.
6. 버킷 활성화 상태에서 오브젝트 업로드 가능.
   *오브젝트: 이미지 파일, 음악 파일, 영상 파일, 문서 등 어떤 파일이든 해당됨.
7. 오브젝트 업로드: 버킷 클릭 후 업로드 선택.
8. 오브젝트 다운로드: 오브젝트의 체크박스 선택 후 다운로드 클릭.

(2) S3 권한과 접근 API

S3 버킷이 가진 두 종류의 권한 시스템:

1. 접근 제어 정책(ACP, Access Control Policies): 웹 UI에서 주로 사용. ACP는 두 번째 권한 시스템의 단순화된 추상화 계층.
2. IAM 접근 정책: 각 권한의 상세 내용을 볼 수 있는 JSON 오브젝트로 저장되어 있음.

권한: 버킷/오브젝트에 적용될 수 있음.

• 버킷 권한: 마스터 키와 유사. 
• 오브젝트 권한: 오브젝트 접근 권한을 부여하기 위해 버킷 권한을 먼저 부여한 뒤, 오브젝트 권한을 추가로 제공해야 함.

S3 버킷 오브젝트에 접근하는 방법: WebGUI / AWS CLI

AWS CLI 사용해 오브젝트를 업로드하고 다운하는 방법:

sudo apt install awscli

▲ awscli 설치

awscli를 새로운 자격증명으로 구성하기 위해 액세스 키 ID와 비밀 액세스 키가 필요.

• AWS Management Console에 로그인.
• 페이지 우측 상단에서 계정 이름 클릭.
• 드롭다운 메뉴에서 내 보안 자격증명 클릭.
• 새 액세스 키 만들기 클릭.
• 액세스 키 표시 링크를 클릭해 액세스 키 ID와 보안 액세스 키를 복사

aws configure

▲ 해당 명령어 입력 후

• 액세스 키 ID와 비밀 액세스 키 입력. 해당 키들이 외부에 유출되지 않아야 함.
• 리전 기본 설정.
• 출력 형식은 설정할 필요X.

aws s3 ls s3://[버킷 이름]

▲ S3 버킷 콘텐츠에 접근.

aws s3 ls s3://[버킷 이름]/[폴더 이름]

▲ 버킷 안 특정 폴더를 탐색.

aws s3 cp [파일 이름] s3://[버킷 이름]/[폴더 이름]/[파일이름]

▲ S3 버킷에 파일 업로드. cp 명령어/복사하려는 파일명/목적지 버킷 전체 경로 입력.

aws s3 rm s3://[버킷 이름]/[폴더 이름]/[파일 이름]

▲ S3 버킷에서 파일 삭제. rm 명렁어/삭제하려는 파일의 전체 경로 입력.

<접근 제어 정책(ACP)/접근 제어 리스트(ACL)>

접근 제어 리스트(ACL): 방화벽 정책과 매우 유사. S3 버킷으로의 접근을 허용하는 데 사용. 각 S3 버킷은 접근 제어 리스트가 적용되어 있음.

4가지 주요 접근 제어 리스트:

• 읽기: 읽기 권한이 부여된 사용자는 버킷 내 오브젝트의 파일명/파일 크기/최근 수정 정보 등을 확인 가능. 접근 권한이 있는 오브젝트 다운 가능.
• 쓰기: 쓰기 권한이 부여된 사용자는 오브젝트를 읽거나 삭제, 업로드 가능. 권한이 없는 오브젝트를 삭제할 가능성 존재(??)
• 읽기-acp: 접근 제어 읽기 권한이 부여된 사용자는 버킷/오브젝트의 접근 제어 리스트를 볼 수 있음.
• 쓰기-acp: 접근 제어 쓰기 권한이 부여된 사용자는 버킷/오브젝트의 접근 제어 리스트를 변경할 수 있음.

오브젝트: 특정 피부여자에 대해 위 4종류 리스트 조합으로 최대 20개 정책을 설정 가능. 피부여자는 AWS 계정이나 사전에 정의된 그룹일 수 있으며, IAM 계정은 피부여자가 될 수 없음.

<버킷 정책>

버킷 정책: 각 S3 버킷에 할당돼 있으며, 버킷/오브젝트에 적용 가능.

+여러 개의 버킷이 있을 때 정책을 복사 가능하며, /data/*처럼 자원을 특정해 개별 폴더에 정책 적용 가능. 버킷 속성 페이지의 권한 탭에 들어가면 웹 UI를 사용해 S3 버킷에 정책 추가 가능.

<IAM 계정 정책>

IAM 계정 정책: 개별 IAM 계정에 접근을 설정하기 위해 사용. 접근 제어 리스트 권한이 특정 IAM 계정에만 적용돼야 하는 상황에 유용.

IAM 사용 vs 버킷 정책 사용: 동일한 권한이 여러 사용자에게 적용돼야 하는지, 여러 사용자에게 다른 권한이 적용돼야 하는지를 기준으로 판단. 후자의 경우 IAM 정책이 더 적합.

<접근 정책>

접근 정책: 사용자에게 부여된 오브젝트/버킷 권한을 상세히 표현한 것으로, JSON 형식으로 저장됨.

접근 정책의 3가지 주요 부분: "Statement", "Action", "Resource"

{
	"Version": "2008-02-27",
    "Statement": [
    {
	"Sid": "Statement",
        "Effect": "Allow",
        "Principal": {
	"AWS": "arn:aws:iam::Account-ID:user/kirit"
        },
	"Action": [
		"s3:GetBucketLocation",
            	"s3:l_istBucket",
            	"s3:GetObject"
		],
		"Resource": [
			"am:aws:s3:::kirit-bucket"
			]
		}
	]
}

▲ JSON 형식의 버킷 정책 예제.

• "Statement" 섹션: "Effect": "Allow" / "Principal" 섹션이 "AWS": "arn:aws:iam::Acount-ID:user/kirit"을 포함. "kirit" 사용자가 오브젝트에 대한 권한을 부여받았음을 의미.
• "Action" 섹션: 어떤 권한이 사용자에게 허용됐는지 보여줌.
  -"s3:ListBucket" 권한: 사용자가 버킷의 오브젝트 목록을 보는 것이 허용됨.
  -"s3:GetObject" 권한: 사용자는 버킷에서 오브젝트를 다운할 수 있음.
• Resource 부분: 어떠한 자원에 권한이 부여됐는지 나타냄.

→ kirit-bucket이라는 버킷에 대해 GetBucketLocation.ListBucket, GetObject 권한을 kirit 사용자 계정에 허용한 정책.

(3) 취약한 S3 버킷 생성

전 세계로 공개된 취약한 S3 버킷에 읽기 및 쓰기 시도하는 실습. 실습을 위해 S3 버킷을 구성하고 공개적으로 읽기/쓰기를 허용해 의도적으로 취약하도록 설정.

S3 홈페이지로 이동해 공개적으로 접근 가능한 취약한 버킷 생성.

1. 새로운 S3 버킷 생성.
2. 선택한 버킷에 대한 퍼블릭 액세스 차단 편집 설정 클릭.
3. 체크박스 모두 해제 후 저장. → 버킷에 적용된 접근 제한을 모두 제거하고자 수행.
4. 확인을 입력한 후 확인 클릭.
5. 버킷 클릭 후 사이드 패널에서 권한 탭 클릭.
6. 액세스 제어 목록으로 이동해 퍼블릭 액세스 밑 Everyone을 클릭. 사이드 패널이 열리면 체크박스 모두 체크. → AWS에게 퍼블릭 액세스를 허용하도록 지시하는 설정.
7. 저장 클릭.

취약한 버킷에 오브젝트 업로드. 예제에서는 작은 크기의 텍스트 파일을 버킷에 업로드 함.

1. 작은 텍스트 문서 생성.
2. 버킷에서 업로드를 클릭.
3. 파일을 선택 후 업로드.
4. 파일이 업로드되면 오브젝트를 클릭해 외부에서 접근이 가능한 URL 확인.

8장에서 S3 버킷을 공격하는 방법 및 공격 도구를 다룸.

1. 사전 준비

(1) IAM 계정 만들기

• 루트 계정으로 콘솔에 로그인
• AWS 화면 맨 위 검색창에 IAM이라고 검색하고 클릭해서 들어감
• 왼쪽 메뉴에서 IAM 사용자를 클릭
• 오른쪽 상단의 주황색 사용자 생성 버튼을 누름

계정 설정

• AWS Management Console에 대한 사용자 액세스 권한 제공'은 체크X (컴퓨터 명령창으로만 쓸 거라 웹 로그인 권한은 필요 없음)
• 권한 설정 방식: 정책 직접 연결
• 권한 검색창: PowerUserAccess / AmazonAthenaFullAccess (아테나 실습 목적) / AWSCloudTrail_FullAccess

(2) 비밀 키 발급

• 생성한 IAM 계정이 보일 텐데, 그 계정을 클릭
• 보안 자격 증명 탭 클릭
• 액세스 키 영역의 액세스 키 만들기 버튼 누름

액세스 키 설정

• 용도 선택: CLI
• 권장 사항 확인 체크박스에 체크
• 설명 작성 불필요
• 이 다음 액세스 키와 비밀 액세스 키 확인 가능 → 비밀 액세스 키는 다시 확인 불가하므로 따로 저장해둘 것

(3) cmd에 키 등록

aws configure

AWS Access Key ID [None]: # 방금 발급받은 액세스 키 입력 후 엔터
AWS Secret Access Key [None]: # 비밀 액세스 키 입력 후 엔터
Default region name [None]: # ap-northeast-2 입력 후 엔터 (서울 리전)
Default output format [None]: # 그냥 엔터

(4) Stratus Red Team 설치

Git 링크: https://github.com/datadog/stratus-red-team/releases

깃허브에서 운영체제에 맞는 zip 파일을 받아 압축 해제 후 stratus.exe 파일 사용 (나의 경우 Windows_x86_64)

(5) AWS 환경 구축

S3 버킷 생성

• AWS 콘솔에서 S3 서비스로 이동
• 버킷 생성 누르고, 이름 설정
• 고급 설정 - 객체 잠금 비활성화 되어있는지 확인 후 생성

CloudTrail 설정

• AWS 콘솔에서 CloudTrail 서비스로 이동
• 추적 생성 버튼 클릭
• 추적 이름 입력
• 저장 위치: 기존 S3 버킷 사용 - 위에서 만든 S3 버킷 설정
• 로그 파일 SSE-KMS 암호화: 비활성화(실습 위한 것이므로)
• 다음 - 관리 이벤트만 체크 후 생성. 데이터 이벤트 체크할 경우 비용 이슈O.

2. 깃 돌려보기

• exe 파일이 있는 폴더에서 cmd 창을 열기
• 공격 명령어 실행(2번 명령어 실행 시 해당 터미널 창에서도 aws configure를 설정해야 함)

#1. 사용 가능한 공격 리스트가 잘 나오는지 확인 (작동 테스트)
.\stratus.exe list

#2. 백도어 공격(리스트 중 있어야 함)
.\stratus.exe detonate aws.exfiltration.s3-backdoor-bucket-policy

2번 실행 과정에서 오류가 나는데, 사용자 이름이 한글인 경우 오류가 날 수 있다고 함. 그래서 임시로 아래와 같이 설정해 준다. (나의 경우에도 오류가 났음)

set AWS_ACCESS_KEY_ID=본인의_액세스_키_ID
set AWS_SECRET_ACCESS_KEY=본인의_비밀_액세스_키
set AWS_REGION=ap-northeast-2

이렇게 설정해 주고 다시 공격 명령어를 입력하면 사진처럼 뜨고 공격 로그 생성 성공

3. Amazon Athena로 공격 흔적 탐색

(1) Athena 테이블 생성

• AWS 콘솔에서 CloudTrail로 이동
• 왼쪽 메뉴에서 이벤트 기록 버튼 
• Athena 테이블 생성 버튼
• 버킷을 처음에 생성했던 버킷으로 선택 후 생성

(2) Athena 기본 세팅

• AWS 콘솔에서 Athena 서비스로 이동
• 데이터 쿼리 시작 박스 - Athena 콘솔에서 데이터 쿼리 버튼 클릭
• Athena 쿼리 편집기 열기

쿼리 편집기 설정

• 데이터 소스: AwsDataCatalog로 되어있는지 확인
• 데이터베이스: CloudTrail 로그를 파싱하기 위해 미리 만들어둔 데이터베이스 이름을 선택
• 테이블: 그 데이터베이스 안에 생성된 로그 테이블 이름이 왼쪽에 잘 보이는지 확인
• 설정 편집 버튼 - 결과 쿼리 위치: s3://[버킷 이름]/athena-results/

(3) Athena에서 쿼리 입력

• 데이터베이스: default / 테이블: cloudtrail_aws_logs 형태로 테이블이 생성된 상태
• 아래 SQL문을 입력하고 실행

SELECT 
    eventtime, 
    eventname, 
    sourceipaddress, 
    useragent,
    useridentity.arn
FROM 
    "default"."테이블_이름"
WHERE 
    eventname = 'PutBucketPolicy'
ORDER BY 
    eventtime DESC;

결과

• eventtime: 공격이 발생한 정확한 시간. 뒤에 붙은 Z는 UTC 기준이라는 뜻. KST는 UTC보다 9시간 빠르므로 한국 기준 공격 일어난 시간은 2026년 5월 20일 오전 10시 18분 16초
• eventname: 해커가 호출한 AWS API 명령어. S3 버킷의 외부 접근 권한을 제어하는 버킷 정책을 강제로 생성하거나 수정했다는 뜻. → 백도어를 심기 위해 API를 조작한 흔적.
• sourceipaddress: 공격 명령을 날린 해커의 실제 IP 주소.
• useragent: 공격자가 어떤 프로그램/도구를 사용해 AWS에 접속했는지 보여주는 식별자. 정상 사용자는 웹 브라우저/AWS CLI 사용, 여기서는 stratus-red-team이라는 시그니처가 찍혀 있음.
• arn: 공격 행위를 수행하는 데 사용된 AWS 계정의 고유 식별 주소. 실습을 위해 발급했던 IAM 계정이 도용되었음을 의미.

워게임을 풀고 공부를 진행했다.

https://hae9-9.tistory.com/125

1. 도메인/S3 구조

S3 주소 구조: https://[버킷이름].s3.amazonaws.com

• 메인 도메인: amazonaws.com
• 1차 서브(하위) 도메인: s3
• 2차 서브 도메인: [버킷 이름]

→ S3 버킷이 해당 형태로 서브도메인을 자동 생성하기 때문에 해당 구조가 나옴.

워게임 버킷 이름인 flaws.cloud를 해당 주소 구조에 넣으면

https://flaws.cloud.s3.amazonaws.com 이 나온다. 

해당 xml 파일은 원래 보안이 잘 된 버킷의 경우, 접근 거부 에러가 나야 함. 그러나 이 워게임은 권한 취약점을 이용한 문제이므로 사진처럼 확인이 가능.

2. 도메인 레코드

nslookup -type=txt flaws.cloud

-type=txt 옵션: 개발자 또는 보안 담당자가 도메인 소유권 인증이나 메모를 위해 등록한 TXT 레코드를 조회하는 명령어. 그런데 사진에서는 도메인의 기본 관리 정보를 제공함. 이는 레코드 내용이 없거나, 결과값을 제대로 찾지 못하여 던져준 값임.

→ 경우에 따라 해당 TXT 레코드에 중요한 내용이 적혀있을 수 있음. 따라서 공격자는 정보 수집 단계에서 DNS 레코드를 확인.

사이트에 들어가면 사진과 같은 화면이 나온다.

우선 별도의 단서가 없는지 f12를 눌러서 확인해 보았으나, 주석으로 html 코드에는 단서가 없다고 안내해 주고 있다.

도전 과제: 첫 번째 서브도메인을 찾기.

+일단 모든과제는 flaws.cloud의 하위 도메인임.

도메인을 잘 모르니 공식 문서를 확인함. 서브 도메인(=하위 도메인)은 도메인 이름 앞에 오는 url 부분.

예시를 들면 blog.naver.com에서

• .com: 탑 레벨 도메인(TLD)
• naver.com: 메인 도메인(Root 도메인)
• blog: 서브 도메인(하위 도메인)

도메인 목록을 조회해야 하나 싶었는데 도통 모르겠어서 힌트1을 봤다..

flaws.cloud 사이트는 S3 버킷에 호스팅되어 있으며, S3 버킷에 사이트를 호스팅할 때 버킷 이름은 도메인 이름과 일치해야 함.

→ flaws.cloud의 버킷 이름도 flaws.cloud

일단 별도의 권한을 가진 계정이 없으므로, --no-sign-request를 통해 프로필 검사를 뛰어넘었다.

aws s3 ls s3://flaws.cloud --no-sign-request

여기 보면 secret-dd02c7c.html 문서가 보인다. 해당 이름을 브라우저 주소인 flaws.cloud 뒤에 붙여 넣어 flaws.cloud/secret-dd02c7c.html으로 접속하였다.

그러면 Level 2로 넘어가는 링크가 나온다.

http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/

Level 1 교훈: S3 버킷을 다양한 권한과 기능으로 설정 가능, 정적 파일 호스팅에도 사용 가능. 그러나 버킷 권한을 너무 느슨하게 설정하는 경우가 있음.

실수를 피하는 방법: 기본적으로 S3 버킷을 생성 시 비공개로 보호됨. 웹 페이지로 접근 가능하게 하려고 정적 웹 호스팅 설정을 활성화하고 버킷 정책을 변경해 모든 사용자에게 s3:GetObject 권한을 부여. 여기서 문제되는 부분은 모든 사용자에게 목록 보기 권한을 추가한 것.

개인 공부 목적으로 작성된 글이며, 틀린 정보나 해석이 있을 수 있음.

http://flaws.cloud/

클로드 미토스(Claude Mythos): 앤트로픽(Anthropic)이 공개한 차세대 AI 모델. 

1. 클로드 미토스의 등장

클로드 미토스는 코딩 능력, 학문적 추론, 사이버 보안 영역에서 기존 모델인 클로드 오퍼스 4.6(Claude Opus 4.6)을 크게 상회하는 기능을 가짐. 현재 일반 사용자에게 개방되지 않고 일부 인프라 기업/기관에만 제한적으로 제공. 

→ 이유: 사이버 보안 위험.

실제로 미토스 공개 후 주요 국가의 정부/금융당국이 즉각 대응에 나섬. → 미토스가 보안 환경에 영향을 미칠 수 있는 변수로 받아들여짐.

클로드 미토스 프리뷰 성능: 기존 모델에 비해 비약적으로 상승했는데, 특히 실제 소프트웨어 버그를 스스로 찾아 고치는 SWE-bench PRO/이미지가 포함된 복합 코딩 문제를 해결하는 SWE-bench Multimodal에서 20%p 이상의 성능 개선을 보인 것으로 나타남. 그 외 추론 능력, 에이전트 역량을 측정하는 벤치마크에서도 기존 모델과 타사 모델을 모두 상회.

→ AI 모델의 스스로 문제를 찾아내고 해결하는 능력이 인간 수준~그 이상으로 올라온 것을 시사.

2. 미토스 프리뷰를 공개하지 못한 이유

공개하지 못한 것은 단순 성능 향상이 아니라 사이버 보안 영역에서 보여준 역량 때문으로, 오픈BSD/FF엠펙/프리BSD 등 오픈소스 소프트웨어에서 아무도 발견하지 못했던 보안 취약점을 스스로 찾아내고 공격 코드까지 작성하였음.

기술적 관점: 기존 보안 분석 도구와 미토스 프리뷰의 접근 방식은 근본적으로 다름.

• 기존 도구: 퍼징/정적 분석으로 개별 취약점을 탐지하는 데 집중.
• 미토스: 코드의 맥락을 이해한 뒤, 취약 가능성이 있는 경로를 스스로 가정하고 이를 검증.

3. 프로젝트 글래스윙 출범

• 장기적 관점: AI 기술은 공격자보다 방어자에게 더 큰 이점 제공, 전체 보안 수준 끌어올릴 가능성 O.
• 단기적 관점: 새로운 기술은 대개 공격자에 의해 먼저 활용되는 경향. 앤트로픽은 이런 변화를 사이버 보안 환경의 구조를 뒤흔드는 전환점으로 인식.

앤트로픽이 핵심 소프트웨어 인프라를 보호로 목표로 하는 프로젝트 글래스윙(Project Glasswing)을 공식 발표.

→ 구글, AWS, 애플, 리눅스재단, 마이크로소프트, 엔비디아 등을 포함한 기업들이 참여. 이들은 공동으로 AI를 활용해 주요 소프트웨어 시스템의 취약점을 사전에 식별하고 대응.

AI 보안 위협 → 국가와 금융 시스템 전반으로 확산될 수 있음.

보안 환경의 변화:

• 기존: 취약점이 발견된 이후 대응
• 전환: AI를 활용해 사전에 취약점을 탐지하고 예방하는 구조, 그리고 이를 자동화할 수 있는가에 보안 경쟁력이 달려 있음.

미토스 논란: 사이버보안 패러다임이 근본적으로 변환하고 있음을 보여주는 사례, 정부와 기업은 AI 기반 위협에 대응하기 위해 기존 체계를 재정비하고 대응 구조를 강화할 필요가 O.

본 게시글은 아래의 링크 속 콘텐츠를 기반으로 작성.

https://www.igloo.co.kr/security-information/%ED%95%B4%EC%BB%A4%EB%A5%BC-%EB%8C%80%EC%B2%B4%ED%95%A0-ai-%ED%81%B4%EB%A1%9C%EB%93%9C-%EB%AF%B8%ED%86%A0%EC%8A%A4/

워게임을 풀고 공부를 진행했다.

https://hae9-9.tistory.com/122

이전의 이미지 파일을 추출해 보고, 그 파일을 분석해 보는 실습을 진행.

추출 명령어

docker save 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latest -o level2.tar

명령어 실행 결과:

추출한 파일을 바탕화면으로 옮긴 뒤, 압축을 풀었다.

압축 해제 후 level2/blobs/sha256 폴더에 들어가면

사진과 같은 파일이 뜬다. 이는 문제를 풀 당시에 확인했던 manifest에 나왔던 항목들과 일치하는데, 확장자가 없는 파일로 뜬다. 이 중 사이즈가 213으로 가장 작아 의심스러웠던 파일인 4fbdf...를 바탕화면에 복사한다.

후에 이름 변경으로 맨끝에 .tar.gz를 추가하여 확장자를 변경한다. 이것이 가능한 이유는 도커의 레이어가 실제로는 Gzip으로 압축된 Tar 파일이기 때문이다.

압축을 풀고 폴더를 타고 들어가면 파일이 하나 나온다.

start.sh라는 제목의 파일명이다. 의심한 파일에 기대하던 값이 나오진 않았으나, 이런 식으로 반복하면 파일을 하나하나 확인할 수 있음을 배웠다.

파일 해석:

• #!/bin/bash: 이 파일을 /bin/bash를 통해 해석하라고 운영체제에 알리는 선언문.
• &: 백그라운드 실행을 의미.
• nginx: 웹서버인 Nginx를 실행.

<학습 내용 정리>

도커 이미지 구조:

• Content Addressable Storage(내용 주소 지정 저장소): 도커는 파일 이름이 아니라 파일의 내용을 해시한 값으로 이름을 붙임.
• Immutable Layers(불변의 레이어): 한 번 만들어진 레이어는 절대 변하지 않음. 도커는 각 레이어들을 합쳐서 하나의 파일 시스템처럼 보여줌.

포렌식 관점의 주의사항:

• 데이터 영속성: 실습에서처럼, 개발자가 다음 레이어에서 비밀번호 파일을 지웠다고 하더라도 이전 레이어에는 그 파일이 그대로 남아있음.

레벨2 문제 사이트: http://container.target.flaws2.cloud/

컨테이너로 실행된다고 함. S3 버킷과 마찬가지로 AWS의 다른 리소스도 개방형 권한을 가질 수 있음.

주어진 힌트: ECR(Elastic Container Registry)의 이름이 level2

주어진 사이트에 들어가니 로그인 팝업 창이 뜨는 것을 확인할 수 있음. 아무 정보나 무작위로 넣어 로그인을 시도하니 다시 같은 팝업 창이 뜸.

취소 버튼을 누르니

사진과 같은 화면이 뜸. 401 에러는 단순 로그인 시, 제공된 정보가 없거나 잘못되어 접근이 거부되었음을 의미하는 오류이므로 정상적 에러임.

ngnix: 웹 서버, 프록시 서버, 캐싱, 분산 처리 등의 기능을 제공.

버프 스위트로 분석해본 것(로그인 시도 패킷)

메소드가 GET이고, 웹서버의 루트 경로(/)에 데이터를 요청 중.

호스트: container.target.flaws2.cloud

인증 방식: 기본 인증을 사용 중. 이는 로그인 팝업창을 통해 아이디와 비밀번호를 입력했을 때 생성되는 방식. Basic 뒤의 인코딩된 내용은 디코딩 시 내가 입력했던 값인 aaa와 bbb가 나옴.

일단 주어진 힌트라도 확인함.

ECR: 가벼운 컨테이너 런타임 실행환경을 위해 빌드된 이미지들을 저장하는 곳. → 문제 사이트 이미지가 이 컨테이너에 들어가 있는 듯함.

AWS 공식 문서: https://docs.aws.amazon.com/cli/v1/userguide/cli_ecr_code_examples.html

위의 문서에서 ECR 저장소에 있는 이미지 목록을 보기 위한 명령어가 주어짐. 여기서 저장소 이름도 주어졌으니 해당 명령어를 이름에 맞게 변형하면 아래의 명령어가 나옴.

aws ecr list-images --repository-name level2

근데 그냥 명령어를 터미널에 입력하면 aws configure를 안 했기 때문에 에러가 남. 일단 이전 단계에서 얻었던 정보를 토대로 aws configure를 시도함. (그런데 그대로 입력하면 토큰 만료가 되어 오류가 나므로, 1단계에서 사용했던 과정을 반복해서 다시 시도해봄.)

• "AWS_ACCESS_KEY_ID":"ASIAZQNB3KHGOJCB6BA5"
• "AWS_SECRET_ACCESS_KEY":"FjKkia36em5d9zzVaZeY1Vu22BlDTLoi8x1puIw1"
• "AWS_DEFAULT_REGION":"us-east-1"
• "AWS_SESSION_TOKEN":"IQoJb3JpZ2luX2VjEGUaCXVzLWVhc3QtMSJHMEUCIQCNkJ7mlX0aNNpTXf+g/RlXRz2B1LrRxW+D2vae+RKxgwIgScyir3qjyAqjtRLpB9PH0R/3sFdz/dgCBQvJ41ydPBAqywMILhADGgw2NTM3MTEzMzE3ODgiDCK+1dsvVWgd6VUk8SqoAyf70LPnog59o9R+cywl0ifncjp8fk1DQlaVq/R2WQccx6wgoD9XRMhdDpRhsI+Nke1PoKynoP9jTM71k3CSGAhJdqHYfwbJnmR3/YZScCWfwcDwPForxDGBl7JxFQgq9ucG0/3laYneExegZfJql/pmv2NT/ca+zu/Qj/5kwttjN5J9BHgqaX6SLUTflMczvgpcAGRaKa1Hokqc4Vb4TEfX9LsyhvcrI2xehyoDslH17e68cV/4HnbVxWXXCfnq7W4OgR0BlBHwphwQy4Smqfl76UfvXzq9Vyd5y5F02/bitzcLx+xJtIYjEGOYJXy63nn31TTyTpQD2QKATppi0fFGqL9r+obPMIY0XLuKnWsC+8hVmq2ykG6aWygNerOqcskFqelZhvRX+KVIdRoPb+E5aYQkbtAG3ektuRVxrJBmwkG86Z7so2zJcar4MM3dKsZ/4DHLZyrt8H3md7QWAhjcZ2/2tKPvb64hs851urrj0/fThjVHxgfeX95+tEhlnXIbBsqqLmPWoy3AVm+eV50k7sC/PqNH52npjDgbA/j7zgKgg8Rci3AwiLeM0AY6oQG8f79L9AxmckRXBkgBRw1xKQpiRu0Ai7YHN16SHr35U6SuLLCYPaRCrjVok8cZWIgfI/yqjYnhK+pP7iVn0elUPbOc14xRlz6c7F200Gzlc/u8xlzKonMl8e0ywUyE6pdO3sO9IJTVHeqNQCceIQcLsRdMWa6W8+pRYdnCp59wghhXutWA2JfxAoHwXZ3of0WNTVjq0Y3CWGnZ/1s3xGtXHA=="

→ 이전에 level1에서 구한 값을 현재 구한 값과 비교하면, 액세스 키와 시크릿 액세스 키 값만 변경된 것을 확인할 수 있음. 만일 다음에도 사용한다면 해당 값만 확인하면 될 듯하다.

아까 만든 프로필을 덧붙여서 명령어를 수정.

aws ecr list-images --repository-name level2 --profile flaws2

사진과 같이 imageDigest와 imageTag를 확인 가능. 서치해보면

imageDigest: 변경 불가능한 컨테이너 이미지의 특정 버전을 고유하게 식별하는 암호화 해시.

imageTag: 변경 가능.

구한 태그를 이용해 이미지의 Manifest를 확인.

aws ecr batch-get-image --repository-name level2 --image-ids imageTag=latest --profile flaws2

사진에서

registryId: 653711331788

해당 정보를 이용해 ECR에 로그인.

aws ecr get-login-password --region us-east-1 --profile flaws2 | docker login --username AWS --password-stdin 653711331788.dkr.ecr.us-east-1.amazonaws.com

로그인 후 이미지 내려받기(도커 실행 필요).

docker pull 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latestdocker pull 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latest

내려받은 이미지의 히스토리를 확인. → 실행됐던 쉘 명령어들이 나옴.

docker history --no-trunc 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latest
IMAGE

사진처럼 결과가 나오는데 사진의 내용보다 긴 내용이 나옴.

이 중 의심스러운 내용:

/bin/sh -c htpasswd -b -c /etc/nginx/.htpasswd flaws2 secret_password

키워드에 대놓고 password가 있어서 의심스러웠음. 보니까 이게 하드코딩된 로그인 정보.

명령어 분석.

• /bin/sh -c: 뒤에 오는 문자열을 쉘 명령어로 실행하라는 의미.
• htpasswd: 아까 Nginx와 같은 웹 서버의 기본 인증(Basic Authentication)에 사용할 사용자 이름과 비밀번호를 관리하는 유틸리티.
• -b: Batch(배치) 모드. 비밀번호를 명령어 뒤에 직접 적겠다는 뜻.
• -c: Create(생성) 모드. 지정한 경로에 새로운 .htpasswd 파일을 만듦.
• /etc/nginx/.htpasswd: 생성한 비밀번호가 저장될 경로. Nginx 설정 파일에서 이 경로를 참조해 사용자를 인증함.
• flaws2: 로그인 시 사용할 아이디
• secret_password: 로그인 시 사용할 비밀번호

로그인 정보대로 팝업 창에 입력해 주면

사진과 같이 다음 레벨의 주소가 나온다.

http://level3-oc6ou6dnkw8sszwvdrraxc5t5udrsw3s.flaws2.cloud/

나온 교훈:

AWS에는 공개할 수 있는 리소스가 많이 있고, 이러한 리소스에 이름 뿐만 아니라 계정 ID, 리전까지 포함해야 하므로 무차별 대입 공격은 어려움. 그러나 공개 리소스를 사용하는 것은 가급적 피하는 것이 좋다.

개인 공부 목적으로 작성된 글이며, 틀린 정보나 해석이 있을 수 있음.

http://level2-g9785tw8478k4awxtbox9kk3c5ka8iiz.flaws2.cloud/

이 글은 아래의 자료를 읽고 공부 목적으로 작성됨.

럭키바닐라3, 「AWS 직원이 알려주는 AWS 클라우드 아키텍처」

9장: 새 VPC로 기존 아키텍처 마이그레이션 하기

기존 Default VPC에서 운영 중인 아키텍처를 새 VPC로 옮기는 작업 필요.

해야 하는 일:

1. 데이터를 저장하고 있는 것들을 옮기기(보안이 중요하기 때문): 데이터베이스 RDS를 DB 서브넷으로
2. EC2 인스턴스들을 옮기기: 웹 서버와 앱 서버가 분리된 상황에서의 EC2 인스턴스 위치 문제 → 둘 다 프라이빗 서브넷으로 옮김.
   *웹 서버: 인터넷을 통해 접근해야 함. 퍼블릭 서브넷에 위치.
   *앱 서버: 프라이빗 서브넷에 위치.
   → 이는 고전적인 방식, 그러나 공격 리스크를 최소화하기 위해, 웹 서버를 프라이빗 서브넷에 배치하고 밸런서만 외부로 노출시켜 보안성을 강화하는 구성이 선호되는 추세.

RDS를 마이그레이션하는 방법:

(1) Snapshot

• 장점: 간단함. 모든 데이터/설정을 포함해 옮길 수 있음.
• 단점: 다운타임 발생, 즉 복원 시점 이후의 데이터는 복제되지 않음. 특정 테이블만 복제 불가능.

(2) DMS(Database Migration Service)

• 장점: 무중단/최소 다운타임 가능. 이기종 DB 지원. 부분 마이그레이션 가능.
• 단점: 초기 설정 복잡. 제약 조건 복제 불완전. 비용 추가 발생.

이 책에서 해볼 것은 스냅샷을 통한 마이그레이션.

*주의 깊게 봐야할 부분: RDS의 서브넷 그룹. 어느 서브넷에 RDS를 위치시킬지 선택하는 작업. 서브넷 그룹을 만들지 않고 RDS를 만들면 아무 서브넷에 만들어질 수 있으므로, 그룹을 명확히 지정해서 만들어야 함.

실습

더보기

  1. RDS 생성: Aurora and RDS에서 생성.

(무료 플랜이기 때문에 책에서의 설정과 차이가 있음.)

 

2. RDS 스냅샷: RDS 데이터베이스 메뉴에서 생성한 lec-db 선택 후 스냅샷 생성 버튼 클릭

 

 3. RDS 삭제: Aurora and RDS에서 lec-db 삭제.

+최종 스냅샷 생성/자동 백업 보존 체크 해제.

 

4. RDS 서브넷 그룹 생성: Aurora and RDS에서 서브넷 그룹 생성.

 

5. 보안 그룹 생성: VPC에서 보안 그룹 생성 - 보안 그룹은 VPC에 종속되므로 기존 VPC의 보안 그룹은 사용 불가.

 

7. RDS 복원: Aurora and RDS에서 스냅샷 복원 클릭.

(사진에서는 VPC를 생성하지 않아 기본으로 선택하였으나 실제로는 생성한 VPC를 선택해야 함.)

 

 

10장: 내부(internal) ELB 사용하기

위의 아키텍처:

• 일정한 트래픽을 받는 경우: 문제X.
• 인스턴스가 늘어났다 줄어드는 경우: 문제 발생O. → 인프라가 타이트 커플링 되어 있다는 것.

*타이트 커플링(Tight Coupling): 시스템 구성 요소들이 서로 강하게 의존하는 구조.

사용자들은 로드 밸런서를 통해 웹서버에 접속.

• 웹서버가 처리해야 하는 정적 데이터: 웹서버에 저장되어 있는 것을 사용자에게 그대로 전달.
• 연산/기록이 필요한 데이터: 앱서버에 전달. 앱서버가 데베에 기록/데베의 데이터를 가져와 처리 후 사용자에게 전달.

현재 구조: 웹서버와 앱서버 모두 오토스케일링 되어 있음. 그러나 앱서버가 오토스케일링에 의해 늘어나면, 새로운 앱서버 인스턴스 IP를 웹서버에 알려줘야 함. → 웹서버에 앱서버의 IP 주소 리스트를 갱신해야 함. 이는 불편함.

루즈 커플링(Loose Coupling) 구조: 융통성 있고 유연한 구조.

위의 아키텍처를 루즈 커플링 구조로 만들기: 웹서버와 앱서버 사이에 내부 로드밸런서를 생성. 혹은 SNS, SQS, Kafka 같은 서비스도 존재.

위 아키텍처 장점: 웹서버는 내부 로드 밸런서의 주소만 알면, 로드 밸런서가 알아서 타겟 그룹에 있는 앱서버에 트래픽을 전달. IP 주소를 알 필요가 X. 장애가 있는 앱서버에는 트래픽을 차단.

실습

11장: 보안 그룹 참조 사용하기

보안 그룹 참조(Security Group Reference): 한 보안 그룹을 다른 보안 그룹의 인바운드 규칙에 설정하는 기능.

*보안 그룹: 방화벽 규칙 집합. 누가 어느 포트로 들어올 수 있는지를 결정하는 규칙.

보안 그룹은 보통 IP 주소를 직접 넣어 설정하는데, IP 주소 대신 보안 그룹을 참조하여 해당 보안 그룹에 속한 인스턴스들이 들어올 수 있는지를 설정할 수 있음. → 이를 보안 그룹 참조라 함.

현재까지의 아키텍처에 5개의 보안 그룹이 사용됨.

• 인터넷 경계 로드 밸런서: lucky-elb-sg
• 웹서버: lucky-web-instance-sg
• 내부 로드 밸런서: lucky-internal-elb-sg
• 앱서버: lucky-app-instance-sg
• 데이터베이스: lucky-db-sg

만들려는 구조:

• 데이터베이스: 앱서버만 접근 가능.
• 앱서버: 내부 로드 밸런서에서만 접근 가능.
• 내부 로드 밸런서: 웹서버에서만 접근 가능.
• 웹서버: 인터넷 경계 로드 밸런서만 접근 가능.

→ 해당 구조를 보안 그룹으로 만들기.

실습

12장: 인스턴스 관리 방법 알아보기

인터넷으로 접근 가능한 인스턴스에 접근하는 방법 3가지

• 빠르고 간편하게 접속이 필요한 경우: EC2 인스턴스 연결.
• 보안 중심의 운영 환경: Session Manager.
• 스크립트/자동화에 주로 사용하거나 고전적인 방법을 선호하는 경우: SSH 클라이언트.

EC2 인스턴스 연결 기능을 사용하기 위해서, 보안 그룹에서 22번 포트인 SSH가 열려 있어야 함. 그러나 프라이빗 서브넷은 인터넷을 통해 접근할 수 없으므로 SSH 포트를 열어둘 수 X.

→ 인스턴스가 프라이빗 서브넷으로 옮겨지면 위 방법들을 사용 불가능. 

인터넷에 직접 접근이 불가능한 프라이빗 서브넷의 인스턴스에 접근하는 방법

• Bastion 서버 생성
• Session Manager

(1) Bastion 서버 생성

Bastion 서버: 관례적으로 사용하는 용어로, 관리용 서버.

위 그림처럼 퍼블릭 서브넷에 SSH 포트가 추가된 인스턴스를 만드는 것이 Bastion 서버.

→ 기존에 인스턴스를 만든 것과 동일. 단지 웹 서버용이 아니므로 보안 그룹에서 http, https 포트를 열지 않는 것뿐임.

퍼블릭 서브넷에 Bastion 서버를 만들면, 해당 서버는 프라이빗 서브넷에 있는 인스턴스에 접근 가능해짐. 단, 서브넷에 있는 인스턴스도 SSH 포트가 열려 있어야 하며, 프라이빗 키를 발급받아야 가능.

1. 인스턴스 생성 시 키 페어 생성.
2. 키 페어 생성 시 [키페어이름].pem 파일이 다운됨.
3. 터미널을 열어 pem 파일이 존재하는 디렉터리로 이동.
4. chmod 400 [키페어이름].pem 명령어로 권한 변경.
5. ssh -i [다운로드 받은 키] ec2-user@[인스턴스의 공인 IP]
   위의 명령어 실행 시 퍼블릭 인스턴스에 접속 가능.
   → 그러나 Bastion 서버에 키가 없어서 프라이빗 서브넷의 인스턴스에 접근 불가능. Bastion 서버에 키를 업로드해 그 키로 다른 인스턴스에 인증할 필요O.
6. scp -i [인스턴스 접근할 때 사용하는 키] [업로드할 키] ec2-user@[인스턴스의 공인 IP]:[키를 업로드할 디렉터리 위치]
   위의 명령어는 키를 업로드하는 명령어.
7. 다시 5번의 명령어로 Bastion 서버에 로그인하여 다른 인스턴스들에게도 명령어를 사용해 접속 시, 원할히 접속 가능.
8. 키를 업로드 했으니 Bastion 서버에서 EC2 인스턴스 연결 방법으로도 다른 서버 관리 가능해짐.

Bastion 서버에서 EC2 인스턴스 연결 방법으로 다른 서버를 관리할 수 있음.

→ 리스크: 키 관리를 해야 함.

(2) Session Manager

키를 관리하지 않고 SSH 포트를 열지 않고 인스턴스들을 관리하는 방법: Session Manager 사용.

*Session Manager: Systems Manager의 하위 기능.

Session Manager 사용 방법: 

• Systems Manager Agent 설치.
• 인스턴스에 System Manager Agent 프로그램 설치.
• 인스턴스가 Systems Manager를 사용할 수 있도록 권한 부여: AmazonSSMManagedInstanceCore 권한 적용.
  (EC2 인스턴스에 권한 부여하는 방법: IAM 서비스의 역할(Role) 사용.)

몇 개 안 되는 인스턴스의 경우, Session Manager를 사용해 하나씩 접속하여 명령어 실행 가능. 그러나 개수가 늘어날수록 일일이 인스턴스에 접속해 관리 불가능.

→ 이 때문에 AWS에서 Systems Manager를 사용함.

Systems Manager 기능 설명: