서버실에 장비를 직접 두고 쓰는(On-Prem) 환경 기준

1. 용어 정리

테이프 소산

소산 = 흩어서 보관한다 = 다른 장소로 옮겨 보관

테이프: 백업용 자기 테이프

테이프 소산: 백업 테이프를 만들어서 물리적으로 다른 건물/금고에 가져다 보관하는 것

클라우드 대응: 테이프를 금고에 넣을 필요 없이, 다른 AWS 리전(서울→도쿄)이나 다른 AWS 계정으로 복제

WORM 테이프/디스크

Write Once, Read Many, 한 번 쓰면 수정/삭제 불가, 읽기만 가능 (like DVD-R)

한번 기록하면 덮어쓰기가 물리적으로 불가능한 테이프

S3 Object Lock

Object: S3에 저장되는 파일 하나하나

S3 Object Lock: S3에 올린 파일을 일정 기간 동안 삭제/수정 못하게 잠그는 기능

- Governance Mode: 특별 권한 있는 사람은 해제 가능

- Compliance Mode: 아무도 해제 불가(루트 계정도 못 지움)

* 파일 단위 잠금

Governance
Users with specific IAM permissions can overwrite or delete protected object versions during the retention period.

Compliance
No users can overwrite or delete protected object versions during the retention period.

Backup Vault Lock

Backup Vault: AWS Backup 서비스가 백업본을 저장하는 금고

* AWS Backup 전체 금고 단위 잠금

2. 백업 방식 관련 용어

3-2-1 규칙

3개의 백업 복사본을

2가지 다른 종류의 매체에

1개는 반드시 외부(오프사이트)에

예: On-Prem - 서버 자체 디스크, 외장 디스크 백업, 테이프 소산

클라우드 - 원본 EBS 디스크, 같은 리전 스냅샷, 다른 리전/다른 계정 복제본

온라인/오프라인 백업

- 온라인 백업: 시스템 가동 중에 백업 (서비스 중단 없음)

- 오프라인 백업: 시스템 멈추고 백업 (네트워크에서 완전히 분리된 상태)

* 클라우드에서는 오프라인이라는 개념 자체가 없음 → Object Lock으로 "논리적 오프라인"을 대체

스냅샷 / AMI

- 스냅샷: 디스크 사진 찍기, 특정 시점의 디스크 상태를 그대로 저장

- AMI: 서버 통째로 복사, OS + 프로그램 + 설정을 하나의 이미지로 묶은 것. 이걸로 새 서버를 바로 만들 수 있음

PITR (Point-in-Time Recovery)

특정 시점으로 복원

- RDS(데이터베이스)에서 최대 35일 이내 아무 시점 지정하여 특정 시점으로 되돌리기 가능

- 전통적 백업은 "매일 밤 12시 백업본"만 있어서 12시~다음날 사이 데이터는 유실될 수 있으나, PITR은 이를 해결

IaC (Infrastructure as Code)

인프라를 코드로 관리함

- On-Prem: 서버 설정을 엑셀에 기록 → 설정 파일 백업

- 클라우드: Terraform 코드로 인프라를 정의 → Git에 저장 → 코드만 있으면 인프라를 똑같이 재생성 가능

* 설정 파일 백업이 아니라 코드 형상관리(Git)가 백업의 본질

VPC 엔드포인트 사용의 대체 방법은 관리형 인스턴스에서 아웃바운드 인터넷 액세스를 허용하는 것이다. 이 경우 관리형 인스턴스는 다음 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽도 허용해야 한다.

Run Command / State Manager 메시지 채널 (Polling)

SSM Agent가 SSM 서비스를 주기적으로 폴링하여 "실행할 명령이 있나?" 확인하고 결과를 반환

Logical Components of Zero Trust Architecture

서브젝트(Subject)

컴퓨터 시스템에서 작동, 엔터프라이즈 리소스에 접속할 수 있는 개념

애플리케이션 또는 장치로 정의

리소스(resource)

제로 트러스트 시스템에서 보호해야 하는 기업의 애플리케이션, 데이터, 문서나 워크로드

정책 적용 지점(PEP, Policy Enforcement Point)

리소스에 접속할 수 있는 지점

정책 결정 지점(PDP, Policy Decision Point)

ID를 확인(인증)받고 ID와 콘텍스트에 따라 해당 서브젝트에 최소한의 권한만 부여하고 이것을 PEP가 실행하는 형태

References: 

[1] Zero Trust Architecture, NIST Special Publication 800-207, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

RAG와 에이전트

색인화(index): 나중에 빠르게 검색할 수 있도록 데이터를 처리하는 작업

질의(query): 관련 데이터를 검색하기 위해 시스템에 요청을 전송하는 과정

청크(chunk): 문서를 더 관리하기 쉬운 분할 방법, 문서 전체를 그냥 검색하면 컨텍스트가 지나치게 길어질 수 있기 때문

의미 기반 검색(semantic retrieval): 임베딩 기반 검색기의 문서의 의미가 질의와 얼마나 가까운지를 기준으로 순위를 매기는 방식

벡터 데이터베이스(vector database): 임베딩을 저장하는 데이터베이스 (임베딩 기반 검색에서 색인화가 하는, 원본 데이터 청크를 임베딩으로 변환하여 만들어진 임베딩)

컨텍스트 정밀도(context precision): 검색된 모든 문서 중에서 실제로 질의와 관련된 문서의 비율은 얼마인가?

컨텍스트 재현율(context recall): 질의와 관련된 모든 문서 중에서 실제로 검색된 문서의 비율은 얼마인가?

7. 파인튜닝

모델 전체나 일부를 추가로 학습시켜 특정 작업에 맞게 모델을 조정하는 과정

모델의 가중치를 요청하는 방식으로 모델을 조정하는 방식으로 모델을 변화시킴

(↔ 모델에 지시, 컨텍스트, 도구를 제공해 모델을 조정하는 프롬프트 기반 방법)

7.1. 파인튜닝 개요

파인튜닝은 전이 학습(transfer learning, TL)의 한 방법인데, 전이 학습은 1976년 보지노프스키(Bozinovski)와 풀고시(Fulgosi)가 처음 제안한 개념

전이 학습: 한 작업에서 얻은 지식을 새롭지만 관련된 작업에 활용해 학습 속도를 높이는 데 중점을 둠

전이 학습은 표본 효율성(sample efficiency)을 높여 모델이 더 적은 예시로도 같은 행동을 학습할 수 있게 함

지속적 사전 학습(continued pre-training): 자기 지도 파인튜닝 

- 비싼 작업별 데이터로 사전 학습 모델을 파인튜닝하기 전에, 저렴한 관련 분야 데이터로 먼저 자기 지도 학습을 적용

인필링 파인튜닝(infilling finetunning): 지도 파인튜닝을 통해 (다음 토큰을 예측하거나) 빈칸을 채우도록 모델을 파인튜닝

- 앞뒤 토큰을 모두 활용해 빈칸을 채우는 마스크 모델, 텍스트 편집 및 코드 디버깅 같은 작업에 특히 유용함

롱 컨텍스트 파인튜닝(long-context finetunning): 컨텍스트 길이를 늘리기 위해 모델을 파인튜닝

- 위치 임베딩 조정 같은 모델 구조의 수정이 필요

7.2. 파인튜닝이 필요한 경우

JSON이나 YAML 같은 특정 구조의 출력을 생성할 때, 파인튜닝이 효과적임

7.3. 메모리 병목 현상

부분 파인튜닝(partial finetuning): 모델 파라미터의 일부만 업데이트

파라미터 효율적(parameter-efficient, PEFT): 적은 파라미터를 사용하면서도 전체 파인튜닝에 가까운 성능을 달성하는 기법

- 일반적으로, 수십 배 더 적은 학습 가능한 파라미터를 사용해 전체 파인튜닝에 근접한 성능을 달성할 수 있다면 파라미터 효율적이라고 봄

랭크: 원본 가중치 행렬을 두 개의 작은 행렬로 분해할 때의 차원 크기

가중치: 뉴런 간 연결의 강도

양자화(quantization): 정밀도를 낮추는 것

- 모델 값을 표현하는 데 필요한 비트 수가 적을수록, 모델의 메모리 사용량도 줄어듦

- 100억 파라미터 모델이 32비트 형식이면 가중치에 40GB가 필요하지만, 같은 모델이 16비트 형식으로 표현하면 20GB면 충분함

선형 결합, 구면 선형 보간법

PEFT 기법들

어댑터 기반 방법(adapter-based method): 모델 가중치에 추가 모듈을 붙이는 모든 방식, 파라미터를 추가하기 때문에 부가적 방법이라고도 부름 (모델 구조에 학습 가능한 파라미터를 추가)

- 예: LoRA, BitFit, IA3, LongLoRA

소프트 프롬프트 기반 방법(soft prompt-based method): 특별한 학습 가능한 토큰을 도입해 모델이 입력을 처리하는 방식을 바꿈

- 예: 프리픽스 튜닝, P-튜닝, 프롬프트 튜닝

LoRA

로라가 쓰이는? 이유가, 풀 파인튜닝하면 파라미터가 박혀서 기존에 작업하던 것도 멍청해짐 → 그걸 재앙적 망각이라고 함

개별 가중치 행렬에 적용 가능, 특정 가중치 행렬이 주어지면 LoRA는 이 행렬을 두 개의 더 작은 행렬의 곱으로 분해하고, 이 작은 행렬들을 업데이트한 후 다시 원래 행렬로 병합하는 방식

n x m 차원의 가중치 행렬 W

1. 더 작은 행렬들의 차원을 선택, 선택된 값을 r이라고 하자.

두 개의 행렬을 구성: A(n x r 차원)와 B(r x m 차원)

두 행렬의 곱 W_{AB}는 원래 행렬 W와 동일한 차원을 가진다. (여기서 r은 LoRA 랭크라고 부름)

2. W_{AB}를 원래 가중치 행렬 W에 더해 새로운 가중치 행렬 W'를 생성. 모델에서는 W 대신 W'을 사용.

하이퍼파라미터 α를 통해 W_{AB}가 새 행렬에 얼마나 영향을 미칠지 조절할 수 있다: W' = W + α/r W_{AB}

3. 파인튜닝 과정에서는 A와 B의 파라미터만 업데이트하고, W는 변경하지 않고 그대로 유지한다.

LoRA는 오래전부터 활용되어 온 차원 축소 기법인 저랭크 분해(low-rank factorization) 개념을 토대로 만들어짐

이 방식의 핵심은 큰 행렬을 두 개의 작은 행렬 곱으로 분해해 파라미터 수를 줄여서 계산량과 메모리 요구사항을 줄여줌

예: 9 x 9 행렬은 9 x 1과 1 x 9 크기의 두 행렬 곱으로 분해

- 원래 행렬은 81개의 파라미터를 가지지만, 분해된 두 행렬은 합해서 단 18개의 파라미터만 필요함

-

Fine-Tuning 방법의 계층 구조: 복잡도에 따라 4단계로 구분한다.

1. 풀 튜닝(Full Tuning) - 가장 단순하지만 비용이 많이 듦
2. 프롬프팅(Prompting) - 중간 단계
3. 검색 증강 생성(RAG) - 더 복잡한 방식
4. 파라미터 효율적 튜닝(PEFT) - 가장 복잡하지만 효율적

• user+management@example.com - for your management account
• user+logs@example.com - for your log archive account
• user+audit@example.com - for your audit account
• user+sandbox@example.com - for your sandbox account, created via the Account factory

AWS CLI v2 with IAM Identity Center

From your terminal, run the following command to sign-in to IAM Identity Center.

aws configure sso

Profile name [AWSAdministratorAccess-0112xxxxxxxx]: ManagementAccount

aws sts get-caller-identity --query 'Account' --output text --profile ManagementAccount

Control catalog

SCP (Service Control Policy), RCP (Resource Control Policy)

SCP: 모든 IAM 주체(사용자, 역할)에게 영향

RCP: 리소스 레벨 (지원 리소스: S3 버킷, Lambda 함수)

Account Factory에서 Default VPC 설정 수행 시 

Control Tower 관리 CloudFormation Stack 확인

- Account Baseline, Security Baseline이 기본으로 설정됨, CT 관리 계정에서 CloudFormation StackSet으로 관리됨

References:

AWS Control Tower Guide, https://catalog.workshops.aws/control-tower/en-US/prerequisites/email-addresses

마스크 언어 모델

누락된 토큰 전후 컨텍스트를 사용해 시퀀스의 어느 위치에서든 누락된 토큰을 예측하도록 학습

e.g., 내가 가장 좋아하는 __는 파란색이다.

자기회귀 언어 모델

이전 토큰들만 보고 시퀀스의 다음 토큰을 예측하도록 학습

e.g., 내가 가장 좋아하는 색상은 __이다.

생성형 AI (generative AI)

언어 모델의 출력에는 제한이 없다. 언어 모델은 정해진 유한한 어휘만을 사용해서 무한히 다양한 결과물을 만들어 낼 수 있다.

이처럼 정해진 답 없이 개방형 출력을 생성하는 모델을 생성 모델(generative model)이라고 부르는데, 여기에서 생성형 AI라는 용어가 유래됐다.

프롬프트 엔지니어링

원하는 제품 설명 예시와 함께 상세한 지시를 모델에 제공하는 방법

검색 증강 생성(retrieval-augmented generation, RAG)

데이터베이스를 활용해 지시를 보완하는 것, 모델을 고객 리뷰 데이터베이스에 연결하여 더 나은 설명을 생성하도록 할 수 있음

1. 개요

AWS Organizations 환경에서 sts:AssumeRoot는 Management Account 또는 Delegated Admin 계정에서 멤버 계정의 Root 수준 임시 세션을 획득하여, 사전 정의된 Task Policy 범위 내에서 특권 작업(Privileged Action)을 수행할 수 있는 기능입니다.

이를 통해 멤버 계정별로 Root 자격증명(비밀번호, 액세스 키, MFA)을 개별 관리하지 않고도, 중앙에서 Root 수준의 긴급 조치를 수행할 수 있습니다.

2. AssumeRoot가 필요한 케이스

2.1 S3 버킷 정책 잠금 해제

예시 시나리오: 버킷 정책에 "Effect": "Deny", "Principal": "*" 를 잘못 적용하여, 관리자 포함 전체 접근이 차단된 경우. 일반 IAM 권한으로는 해당 정책을 수정할 수 없으며, Root 세션으로만 정책 삭제 가능

2.2 SQS 큐 정책 잠금 해제

예시 시나리오: SQS 큐 정책에서 모든 Principal에 대해 Deny를 적용하여, 연동된 Lambda/EC2 등 워크로드가 메시지를 처리하지 못하고 서비스 장애가 발생한 경우

2.3 멤버 계정 Root 자격증명 삭제

예시 시나리오: Organizations 환경에서 멤버 계정의 Root 자격증명을 중앙에서 일괄 제거하여, Root 직접 로그인을 원천 차단하고 중앙 집중식 루트 액세스만 허용하는 경우

2.4 멤버 계정 Root 비밀번호 복구

예시 시나리오: 특정 멤버 계정에서 Root 수준의 콘솔 접근이 필요하나(예: 특정 서비스의 Root-only 설정 변경), Root 비밀번호가 설정되어 있지 않은 경우 임시로 비밀번호를 생성하여 접근

2.5 Root 자격증명 현황 감사

예시 시나리오: 분기별 보안 감사에서 전체 멤버 계정의 Root 자격증명이 제거되었는지 일괄 확인. 자격증명이 남아있는 계정에 대해 IAMDeleteRootUserCredentials로 후속 조치

2.6 케이스 요약

3. 사전 구성

3.1 Root access management 활성화

Management Account에서 Root Access Management를 활성화합니다.

• 경로: Control Tower 계정의 IAM > Access Management > Root access management > Enable

활성화 시 다음 두 가지 기능이 사용 가능합니다:

• Root credentials management: 멤버 계정의 Root 자격증명을 중앙에서 관리(삭제/생성/감사)
• Root sessions: 멤버 계정에 대한 Root 수준 임시 세션 획득(Take privileged action)

3.2 Delegated Admin 등록 (선택)

Management Account 외에 특정 계정(예: Audit)에서도 AssumeRoot를 수행할 수 있도록 Delegated Admin을 등록합니다. 관리자 계정 외에도, 이 회원 계정은 다른 회원 계정에 대한 중앙 집중식 루트 액세스 권한을 갖게 됩니다.

Enable 이후, Management 계정에서 Delegated Admin 등록 확인: 계정(예: Audit)이 정상적으로 등록되었는지 확인

aws organizations list-delegated-administrators --service-principal iam.amazonaws.com

• 참고: Delegated Admin 등록 여부는 의사결정 사항. 등록하지 않는 경우 Management Account에서만 AssumeRoot 수행 가능.

기존은 아래와 같이 호출하는 IAM 자격증명에 sts:AssumeRoot 권한이 없었으나, 위임된 계정에서 접근 가능해집니다.

Access denied to : You don't have permission to perform this action.You don't have permissions to access this resource.

3.3 Permission Set 생성

AssumeRoot를 수행할 담당자에게 할당할 Permission Set을 생성합니다.

Audit 계정에서 사용하는 IAM 역할(Permission Set)에 sts:AssumeRoot 권한이 있는지 확인

• Management 계정 콘솔 > IAM Identity Center > Permission Sets

Audit 계정에 할당된 Permission Set 선택 (해당 계정에 할당된 퍼미션셋은 AWS accounts의 structure에서 확인)

3.3.1 Create permission set

Step 1. Specify permission set details

Permission set type: Custom permission set

Step 2. Specify policies and permissions boundary

Inline policy

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowAssumeRoot",
			"Effect": "Allow",
			"Action": "sts:AssumeRoot",
			"Resource": "*"
		},
		{
			"Sid": "AllowListAccounts",
			"Effect": "Allow",
			"Action": [
				"organizations:ListDelegatedAdministrators",
				"organizations:ListAWSServiceAccessForOrganization",
				"organizations:DescribeOrganization",
				"organizations:ListRoots",
				"organizations:ListAccountsForParent",
				"organizations:ListOrganizationalUnitsForParent",
				"ec2:DescribeRegions",
				"sso:DescribeRegisteredRegions",
				"sso:ListInstances",
				"iam:ListSTSRegionalEndpointsStatus",
				"iam:GetOutboundWebIdentityFederationInfo",
				"iam:GetAccountSummary",
				"iam:ListAccountAliases",
				"iam:ListOrganizationsFeatures",
				"account:GetAccountInformation"
			],
			"Resource": "*"
		}
	]
}

• AllowListAccounts Statement는 콘솔에서 Root access management 화면의 조직 구조 조회 및 Take privileged action 대상 계정을 확인하기 위해 필요합니다. 이 권한이 없으면 콘솔에서 계정 목록 및 OU 구조를 로드할 수 없습니다.

Step 3. Specify permission set details

• Permission set name: BreakGlassAssumeRoot
• Description: Break Glass - sts:AssumeRoot for emergency privileged access
• Session duration: 1 hour (최소한으로 설정)

3.3.2 Take privileged action 권한 추가 할당

Delete S3 bucket policy

Delete SQS queue policy

Allow password recovery

임시 루트 세션의 범위를 지정할 수 있습니다.

• policy/root-task/IAMDeleteRootUserCredentials
  루트 세션은 멤버 루트 자격 증명(콘솔 암호, 액세스 키, 서명 인증서 및 MFA 장치)을 삭제할 수 있도록 범위가 제한됩니다.
• policy/root-task/IAMCreateRootUserPassword
  루트 세션은 멤버 루트 로그인 프로필 생성을 허용하도록 범위가 지정됩니다.
• policy/root-task/IAMAuditRootUserCredentials
  루트 세션은 루트 자격 증명을 검토하도록 범위가 지정됩니다.
• policy/root-task/S3UnlockBucketPolicy
  루트 세션은 S3 버킷 정책을 삭제할 수 있도록 범위가 지정됩니다.
• policy/root-task/SQSUnlockQueuePolicy
  루트 세션은 SQS 큐 리소스 정책을 삭제할 수 있도록 범위가 지정됩니다.

3.3.3 Permission Set 계정 할당

생성한 Permission Set을 대상 계정(Management Account 또는 Delegated Admin 계정)에 할당합니다.

• 경로: IAM Identity Center → AWS accounts → 대상 계정 선택 → Assign users or groups

Step 1 - Users and groups: Break Glass 담당자 사용자 또는 그룹 선택

• Audit 계정에 로그인하는 IAM Identity Center 사용자/그룹이 실제로 sts:AssumeRoot API를 호출할 수 있도록 IAM 권한을 부여하는 것 (Audit 계정에 로그인하는 사람에게 AssumeRoot 실행 권한 부여)

Step 2 - Permission sets: BreakGlassAssumeRoot 선택

Step 3 - Review and submit: 내용 확인 후 Submit

4. 사용 절차

4.1 콘솔에서 Take Privileged Action 수행

1. Access Portal URL에 접속하여 SSO 로그인

- Access Portal URL: IAM Identity Center > Dashboard > Settings summary > AWS access portal URL (형식: https://d-xxxxxxxxxx.awsapps.com/start)

2. 대상 계정에서 BreakGlassAssumeRoot Permission Set으로 Management Console 접근

3. IAM > Access Management > Root access management > Organizational structure에서 대상 멤버 계정 선택

4. Take privileged action 클릭 후 수행할 작업 선택:

• Delete S3 bucket policy
• Delete SQS queue policy
• Allow password recovery

4.2 CLI에서 AssumeRoot 수행 (참고)

콘솔 대신 CLI로 수행하는 경우의 절차입니다:

# 1. AssumeRoot 호출하여 임시 자격증명 획득
aws sts assume-root \\
  --target-principal <멤버-계정-ID> \\
  --task-policy-arn arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy \\
  --duration-seconds 900

# 2. 발급받은 임시 자격증명 설정
export AWS_ACCESS_KEY_ID="발급받은값"
export AWS_SECRET_ACCESS_KEY="발급받은값"
export AWS_SESSION_TOKEN="발급받은값"

# 3. Root 세션으로 작업 수행 (예: S3 버킷 정책 삭제)
aws s3api delete-bucket-policy --bucket <버킷명>

# 4. 임시 자격증명 해제
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

5. 테스트 시나리오

5.1 S3 버킷 정책 잠금 해제 테스트

Step 1. S3 버킷 생성/조회 (멤버 계정)

멤버 계정에서 테스트용 S3 버킷을 생성합니다.

Step 2. 잠금 버킷 정책 적용 (멤버 계정)

모든 Principal의 접근을 차단하는 Deny 정책을 적용합니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAll",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::assumeroot-saraheee",
        "arn:aws:s3:::assumeroot-saraheee/*"
      ]
    }
  ]
}

Step 3. 잠금 확인 (멤버 계정)

버킷 소유자 포함 모든 IAM 자격증명으로 접근이 차단되었는지 확인합니다:

# 버킷 정책 조회 시도 → Access Denied
aws s3api get-bucket-policy --bucket assumeroot-saraheee

# 버킷 정책 삭제 시도 → Access Denied
aws s3api delete-bucket-policy --bucket assumeroot-saraheee

# 오브젝트 목록 조회 시도 → Access Denied
aws s3 ls s3://assumeroot-saraheee

Step 4. Task Privileged Action 수행 (관리/위임 계정)

관리 계정(또는 Delegated Admin 계정)의 콘솔에서 Root access management로 이동하여 Take privileged action을 수행합니다.

CLI 사용 시에는 sts:AssumeRoot API를 직접 호출합니다. (4.2절 참고)

Step 5. S3 버킷 정책 삭제 (Root 세션)

Delete S3 bucket policy 작업을 선택하고, 잠긴 버킷을 지정하여 정책을 삭제합니다.

Step 6. 정상 접근 복구 확인 (멤버 계정)

버킷 정책 삭제 후, 멤버 계정에서 다시 정상 접근이 가능한지 확인합니다.

5.2 SQS 큐 정책 잠금 해제 테스트

Step 1. SQS 큐 생성 (멤버 계정)

멤버 계정에서 테스트용 SQS 큐를 생성합니다.

Step 2. 잠금 큐 정책 적용 (멤버 계정)

모든 Principal의 접근을 차단하는 Deny 정책을 적용합니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAll",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:ap-northeast-2:xxxxxxxxxxxx:assumeroot-saraheee"
    }
  ]
}

Step 3. 잠금 확인 (멤버 계정)

메시지 송수신 및 큐 정책 변경이 차단되었는지 확인합니다:

• 참고: 수 분 소요

# 메시지 전송 시도
aws sqs send-message  --queue-url <https://sqs.ap-northeast-2.amazonaws.com/xxxxxxxxxxxx/assumeroot-saraheee> --message-body "test"

# 큐 속성 조회 시도
aws sqs get-queue-attributes --queue-url <https://sqs.ap-northeast-2.amazonaws.com/xxxxxxxxxxxx/assumeroot-saraheee> --attribute-names All

# 큐 정책 변경 시도 (빈 정책으로 삭제 시도)
aws sqs set-queue-attributes --queue-url <https://sqs.ap-northeast-2.amazonaws.com/xxxxxxxxxxxx/assumeroot-saraheee> --attributes '{"Policy": ""}'

Step 4. Take Privileged Action 수행 (관리/위임 계정)

관리 계정(또는 Delegated Admin 계정)의 콘솔에서 Root access management로 이동하여 Take privileged action을 수행합니다.

CLI 사용 시에는 sts:AssumeRoot API를 직접 호출합니다. (4.2절 참고)

Step 5. SQS 큐 정책 삭제 (Root 세션)

Delete SQS queue policy 작업을 선택하고, 잠긴 큐의 ARN을 지정하여 정책을 삭제합니다:

• SQS Queue ARN: arn:aws:sqs:ap-northeast-2:xxxxxxxxxxxx:assumeroot-saraheee

Step 6. 복구 확인 (멤버 계정)

큐 정책 삭제 후, 멤버 계정에서 다시 정상 접근이 가능한지 확인합니다:

6. Task Policy 상세

Appendix

구성 시 발생 가능한 권한 부족 오류 및 해결

(참고) 권한 부족 1.

CloudTrail Event history

• organizations:ListDelegatedAdministrators
• organizations:ListAWSServiceAccessForOrganization
• sso:DescribeRegisteredRegions
• organizations:DescribeOrganization
• ec2:DescribeRegions

로그 에러

"errorMessage": "User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSReservedSSO_BreakGlassAssumeRoot_xxxxxxxxxxxxxxxx/saraheee@email.com is not authorized to perform: organizations:DescribeOrganization on resource: * because no identity-based policy allows the organizations:DescribeOrganization action",

(참고) 권한 부족 2.

We couldn't load the root of the organization.

You don't have permissions to see this resource, because the management account has not granted you the permissions to view accounts.

CloudTrail Event history

로그 에러

"errorMessage": "User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSReservedSSO_BreakGlassAssumeRoot_xxxxxxxxxxxxxxxx/saraheee@email.com is not authorized to perform: iam:GetOutboundWebIdentityFederationInfo on resource: * because no identity-based policy allows the iam:GetOutboundWebIdentityFederationInfo action",

• organizations:DescribeOrganization
• organizations:ListRoots
• sso:ListInstances
• iam:ListSTSRegionalEndpointsStatus
• iam:GetOutboundWebIdentityFederationInfo

(참고) 권한 부족 3.

We couldn't load organizational units.

You don't have permissions to see this resource, because the management account has not granted you the permissions to view accounts.

CloudTrail Event history

• iam:GetAccountSummary
• iam:ListAccountAliases
• account:GetAccountInformation
• iam:ListOrganizationsFeatures
• organizations:ListAccountsForParent
• organizations:ListOrganizationalUnitsForParent

조회 완료

RNN, LSTM

Transformer model

Attention

같은 문장 내에서 단어들 간의 관계

QKV (Query, Key, Value)

예: I love her 영어를 한국어로 번역하는 것

Query: '나는'이라는 주체

Key: 연관성을 찾는 대상 (I, love, her)

Value: Q와 K의 유사성을 계산하여 유사한 만큼의 값을 가져오는 것

d_k의 루트 값으로 나누어주는 이유: d_k 값이 너무 커지게 되면 행렬의 연산 값도 커지면서 softmax 함수가 극도로 작은 기울기를 갖는 영역을 가지게될 수 있음 → 0에 가까운 값으로 정규화시킴

References

[논문리뷰] Attention is All you need의 이해 - https://lcyking.tistory.com/entry/%EB%85%BC%EB%AC%B8%EB%A6%AC%EB%B7%B0-Attention-is-All-you-need%EC%9D%98-%EC%9D%B4%ED%95%B4