포스트

1. Cloud Security

게시
By UI-JIN KIM 33 분읽는 시간

클라우드

1. 개념 및 구조

1) 특징

클라우드는 내/외부적으로 다양한 특징이 있고, 이에 따라 책임 추적성이 필요하다는 특징이 있다.

멀티테넌시

가상화된 자원을 다수의 사용자가 공유하는 형태
$\rightarrow$ 물리적 /가상화 기반/ 컨테이너 기반/ 인스턴스 격리 등, 다양한 방식으로 자원을 격리하여 관리하는 것이 필요함

가상화 취약점에 대한 보안관리가 필요

접근성

누구나 인터넷을 통해 쉽게 자원을 사용

격리 유형접근 주체예시
사내망 접근내부 사용자전용망
운영자 접근관리자IAM, MFA
사용자 접근최종 사용자MFA
외부 접근3rd partyAPI Gateway

$\rightarrow$ 접근 통제: 제로트러스트를 기반으로 접근 주체에 따라 접근성을 분류하는 것이 필요
$\rightarrow$ 보안 관제: 명확한 책임 추적성을 통한 보안 관제가 필요
$\rightarrow$ 성능 유지: 여러 서버에 트래픽을 분산시켜 안전성과 성능을 보장할 필요(로드 밸런싱)

탄력성

생성한 자원의 구조 변경이나 신규 자원 생성/삭제가 쉽고 빠름

alt text

$\rightarrow$ IT 자원의 수요 변화에 신속하고 탄력적인 보안을 적용할 수 있는 방안이 필요(오토 스케일링)

Ondemand Self Service

플랫폼과 앱 자체를 필요시 즉시 사용 가능하기 때문에 변화 속도에 맞춰 신속 대응 가능

현황 파악 및 취약점 관리를 위한 속도를 따라가기 어려움
(3rd party 제품, 오픈소스 사용에 따른 SW 패치 관리)

사용량 기반 과금

하드웨어/소프트웨어의 구매/유지 및 인건비 등의 비용이 절감

보안 설정 및 관리 범위의 복잡성 증대

2) 가상화

가상화란 물리적 자원을 논리적으로 분리하고 추상화 하여, 하나의 물리적 시스템 위에 여러개의 독립적인 시스템을 실행할 수 있는 기술을 말한다.

자원의 가상화

ⅰ) 하드웨어 가상화(VM)ⅱ) OS 가상화(Docker)
alt textalt text
물리 서버 위에 하이퍼 바이저 설치커널을 공유하는 격리된 실행환경
Host OS, Guest OS 존재Host OS만 존재
Host 커널 공유
완벽한 격리프로세스 격리
ⅲ) Storage 가상화ⅲ) Network 가상화
블록 기반 가상화
파일 기반 가상화
Software Defined Storage
$\rightarrow$ HCI(Hyper Converged Infra)		Software Defined Network
(서로 다른 물리적 환경에서도 일관된 네트워크)

오버레이 네트워크 기술

서버 가상화

  • 하드웨어 가상화
    • Type1(Bare-matal): HW에 직접 하이퍼바이저 설치
    • Type2(Hosted): 기존 OS위에 하이퍼 바이저 설치
    • 하드웨어 지원: CPU 자체가 가상화를 지원하여 효율성 향상
  • OS레벨: 하나의 OS 커널 위에 여러 개의 격리된 공간 생성
  • 패러가상화: OS가 가상화된 하드웨어임을 인식하고 하이퍼바이저와 직접 통신
  • 어플리케이션 가상화: 앱 실행 환경만 가상화

※ SDDC(데이터센터 가상화): 서버, 스토리지, 네트워크 등 데이터센터 전반을 소프트웨어로 가상화하고 자동화한 개념

3) 분류

배치 모델

 PublicPrivateHybrid/Multi
접근 주체민간기관기관 + 민간
장점비용 절감
유연성		보안성효율성

서비스 모델

alt text

  • IaaS : Infra as a Service
  • PaaS : Platform as a Service
  • SaaS : Software as a Service
  • FaaS : Funtions as a Service
  • CaaS : Container as a Service

4) Cloud Native

클라우드 네이티브란 클라우드 환경에 최적화된 설계 방식을 말한다.
클라우드 네이티브의 핵심 요소는 컨테이너, MSA, DevOps, CI/CD가 있다.

클라우드 네이티브의 보안을 위한 요소로는 제로트러스트, SBOM등이 있다.

※ 제로 트러스트(어떤 것이든 신뢰하지 않음)
내부/외부를 구분 없이 모든 사용자, 기기, 애플리케이션의 접근을 철저히 인증하고 최소 권한만 부여하며 지속적으로 모니터링하는 보안 전략 (기술: 접근관리, 네트워크 분리, 단말 보안, 워크로드 보안, 데이터 보안)

※ SBOM(소프트웨어 자재 명세서)
소프트웨어 제품을 구성하는 모든 오픈소스 및 서드파티 구성 요소, 라이브러리, 모듈, 종속성, 라이선스 정보 등을 상세히 나열한 명세서로 위험 식별을 위한 핵심 요소

Container(K8S)

컨테이너란 다양한 환경에서 실행가능하도록 코드와 라이브러리를 패키징한 소프트웨어 단위를 의미한다.

  • Docker: 컨테이너를 실행해주는 엔진
  • K8S: 컨테이너 배포 및 운영 관리 자동화 툴

alt text

K8S는 위의 그림과 크게 마스터(Control Plane)와 Worker Node로 구성되어 있다.

  • Worker Node에는 k8s의 최소 관리 단위인 pod이 존재하고, 이 Pod에는 최소 한개 이상의 컨테이너가 실행된다.
  • Control Plane은 지속적으로 State를 확인하고, 목표 State와 비교하여 지속적으로 차이점을 줄이는 과정을 진행한다.
    (e.g. 자동 복구, 자동 확장, 무중단 배포)

이러한 Container를 클라우드에서 활용하기 위해서는 다양한 관점의 보안 전략이 필요하다.

LayerK8S 보안예시
1. Cloud클라우드 공급자 보안
(CSP가 Control Plane를 책임짐)
(단, Fargate 사용 시 Workernode까지)		(CSP별 K8s Service)

EKS(Amazon)
AKS(Azure)
GKE(google)
2. Cluster쿠버네티스 시스템 자체/ 설정 보안RBAC(역할 기반 접근 제어) 사용
etcd는 Control Plane에서만 접근
etcd에 저장하는 데이터는 암호화
3. Container어플리케이션 이미지의 보안
(컨테이너 이미지 위/변조방지)		 
4. Code소스코드 보안 

MSA

Monolithic 구조Microservice 구조
alt textalt text
각 서비스들이 강하게 결합되어
하나의 전체 시스템을 이루는 구조		작은 서비스 단위로 분리하고 느슨한 결합을 통해
벌집처럼 모여 하나의 전체 시스템을 이루는 구조
구조가 간단
Test 간단
Data 정합성 확보 간단		Scalability
Fault-Tolerance
Faster deployment

클라우드 기반 MSA 도입 시 가장 중요한 것은 서비스별 상이한 IT 아키텍쳐를 가지고 있기 때문에, 아키텍쳐별 보안 구조를 수립해야한다는 점이다.
또한 독립 서비스들을 통합적으로 모니터링하는 것이 중요하다(DevSecOps)

CI/CD + DevOps

  • CI/CD: 지속적인 통합과 배포를 통해 어플리케이션 개발 단계(개발-통합-저장-빌드-테스트)를 자동화하는 방법을 말한다.
    (e.g. 대표 서비스: Jira(계획), Jenkins(빌드, 테스트, 배포))

  • DevOps: 개발과 운영 간 프로세스를 매끄럽게 연결하고, 자동화를 통해 효율성을 극대화 하는 방법
    (e.g. Agile(점진적 개발/개선), 워터폴)

보안 설정(DevSecOps)

AST(Application Security Test): 개발 파이프라인 전반에 걸쳐 보안 테스트를 수행하는 것

  • 개발 단계
    ⅰ) SCA(Software Composition Analysis): 오픈소스 라이브러리 및 라이선스 점검
    ⅱ) SAST(Static Application Security Test): 소스 코드 분석

  • 빌드/테스트 단계
    ⅰ) DAST(Dynamic Application Security Test): 어플리케이션 실행 상태에서 모의 해킹

  • 배포단계
    ⅰ) RASP

  • 통합
    CNAPP(Cloud Native Application Protection Platform): 개발부터 운영까지의 모든 클라우드 인프라 보안 위협을 하나로 통합하여 관리하는 플랫폼

Serverless

서버리스 컴퓨팅은 어플리케이션을 구축하고 실행하기 위해 서버 관리가 필요 없는 아키텍쳐를 말한다. 이를 통해 새로운 Cloud Native 컴퓨팅 모델이 가능해졌다.
(e.g. FaaS, CaaS, MSA도 구현 가능)

  • 장점: 비용, Scalability
  • 단점: 최대 수행시간(15분), 메모리, 함수 초기화 시간 필요

대표 서비스: Lambda

alt text

  1. Lambda 생성시 사용자 Account에 MicroVM을 할당
  2. Lambda에 배포되는 코드는 자동 암호화
    (환경변수 암호화는 수동 설정)
  3. 코드 실행을 위한 환경 할당
    (라이브러리, 임시 스토리지)
  4. Event 발생 시(동기식: API Gateway 연결, 비동기식: S3파일 변경, Stream: 데이터 스트림 처리시) Lambda 전용 VPC에서 생성/실행

보안 설정

ⅰ) 인증/권한: 사용자/리소스에 최소권한 부여, 코드 서명 활성화(서명 후 변경 여부 확인)
ⅱ) 접근 통제: 함수 VPC 사용, 다른 계정에 의한 함수 접근 차단
ⅲ) 데이터 보호: 데이터 암호화(AWS KMS), 환경변수 전송중 암호화(AWS Certificate Manager), 임시 스토리지 사용 후 수동 삭제
$\qquad$ (함수 초기화 $\rightarrow$ 함수 실행(임시 스토리지 유지=사용자간 데이터 공유 가능) $\rightarrow$ 함수 종료(데이터 삭제))
ⅳ) 로깅
ⅴ) 데이터에 따른 함수 분리

5) Access Control(접근 제어)

개념AWSAzureGCP
IAM 서비스AWS IAMAzure Entra IDCloud IAM
리소스용 IDIAM RoleManaged IdentityService Account
권한 정의IAM Policy (JSON)RBAC RoleIAM Role
토큰 발급STSEntra IDOAuth 2.0
인증 대상User / RoleUser / MIUser / SA

의미

  • AWS(Policy 중심): 이 Role은 무엇을 할 수 있는가(행위)
  • Azure(ID+RBAC 중심): 이 ID가 어디까지 접근 가능한가?
  • GCP(Resource 계층 중심): 어느 계층(Project/Folder/Organization)에서 권한을 부여했는가

2. CSP(Cloud Service Provider) & MSP(Managed Service Provider)

각 CSP 별로 Resource Management이 다르다.

alt text

그 외

  • Oracle(OCI)
  • Samsung(SCP)

이러한 자원 관리 방식과 더불어 구축 및 운영 비용, 편리성 보안 요구사항 등을 고려하여 적절한 CSP를 선택하는 것이 중요하다.

1) AWS

alt text

글로벌 인프라

  • Region: 데이터 센터가 위치한 지역(각 Region은 최소 2개 이상의 데이터 센터를 가짐)
  • AZ: Region내에서 데이터 센터를 논리적으로 묶어놓은 영역
  • Edge Location: CDN(CloudFront), Route53, Shield, WAF등을 제공

네트워크 공간: 계정, Region, VPC/AZ, Subnet

Computing ServiceNetworking Service
EC2
Auto Scaling
Lambda
LightSail		VPC
Direct Connect
ELB
Route53
CloudFront
$\rightarrow$ CDN서비스: S3와 같은 서비스와 달리 ISP에 직접 연결됨(빠른 전송 가능)
Storage ServiceDatabse ServiceSecurity Service
S3
EBS(블록: 빠름)
EFS(파일: 확장성)
Glacier(객체: 내부 정보 걱정X)		RDS
DynamoDB
ElastiCache		AWS Control Tower
AWS WAF
AWS Shield
GuardDuty
Inspector
CloudTrail
CloudWatch
Key Management Service

인증/권한관리

클라우드 리소스에 “누가”, “어떻게” 접근할 수 있는지를 제어하는 역할

  • IAM: 사용자(User), 그룹(Group), 역할(Role)을 생성하고 Policy를 할당하여 사용
    • Policy: Json 형태로 권한을 정의하여 IAM 개체에 연결
    • Role: 임시 자격 증명(AccessKey: 장기 자격 증명)
  • AWS Control Tower: 다중 계정 환경에서 보안 정책을 중앙에서 설정하고 제어하는 서비스(Landing Zone 역할)

보안 관리

  • IAM(Root): 최소 권한만 가지고 제한된 용도(비용 관리)에만 사용되어야 한다.
  • IAM(User): MFA, KMS 등의 보안 설정 적용

네트워크 보안

alt text

VPC를 통해 내외부의 트래픽 흐름을 제어하고 공격을 차단

  • 구성
    • PCX: VPC와 VPC 연결
    • DX: VPC와 온프레미스를 연결
    • VPN: 인터넷을 기반한 터널 암호화 통신(IGW 사용 X)
    • VPC: Region내의 모든 AZ에 적용시킬 수 있는 가상 네트워크
      • Internet Gateway를 통해 외부 인터넷과 통신 가능
      • Endpoint를 통해 IG없이 Private한 통신 환경 유지 가능(+ 비용절감)
    • Subnet: VPC를 논리적인 작은 단위로 분할한 Subnetwork(Public과 Private로 구분), NACL/RT를 반드시 수반함
      • NACL: 서브넷 단위의 방화벽 (Stateless, Allow/Deny, Blacklist 주로 사용)
      • Rout Tables(Subnet ↔ IGW/NAT/Transit)
    • Security Group: ENI 단위의 방화벽 (Stateful, Allow, whitelist, 2개이상 → OR규칙)
    • WAF(웹 앱 방화벽): ACL(Access Control List)을 통해 네트워크 규칙을 정의
  • 라우팅 ENI
    • Internet Gateway(VPC ↔ Internet), Public Subnet에 위치
    • NAT Gateway(Private Subnet → Internet), Public Subnet에 위치
    • Transit Gateway(VPC 중앙 관리)

※ Stateful: Inbound규칙 == Outbound 규칙 ※ Stateless: Inbound규칙 != Outbound 규칙 ※ Inbound(밖 → 안), Outbound(안 → 밖)

보안 관리

  • Public/Private 망 분리 및 인터넷 연결점 최소화
  • 네트워크 접근 통제: 리소스는 Allow 규칙으로 접근 통제

  • 미사용 SG 삭제

  • 암호화
    ⅰ) 인터넷 구간 통신시 HTTPS(암호화) 적용
    ⅱ) CloudFront/ELB 서비스를 사용해 네트워크 구간 암호화 필요

서버(Computing) 보안

Web HostingServerless WebContainer Web
alt textalt textalt text
EC2LambdaECR, EKS
데이터 암호화 필요사용 시 인터넷에 정보가 노출되지
않도록 VPC 사용		K8S 사용 시 데이터를 안전하게
관리하고 접근제어 실시

보안 관리

  • 접근제어
    Bastion Host(중계서버)를 활용해 개발/운영 용 등으로 분리하여 운영할 필요
    Endpoint 활용
  • 분산제어
    트래픽 부하를 여러 서버로 분산하여 전달할 필요 있음(ELB)
  • 로깅 및 취약점 관리
    VPC내에 Function을 구성하고, 컨테이너 이미지에 대한 취약점을 스캔하여 관리할 필요

DB/Storage 보안

관계형 DBNoSQL DBStorage
RDSDynamoDBS3
w.t. ServerServerless온라인 객체 스토리지

보안 관리

  • 권한 제어: DB 관리자만 접근 가능하도록 설정
  • Private Subnet으로 구성(NAT Gateway 생성 금지)
  • Public Storage가 필요할 경우 별도로 분리 운영
  • Endpoint를 사용하여 트래픽이 AWS 네트워크를 벗어나지 않도록 통제
  • 암호화: AWS KMS을 사용해 정보 전송 및 저장 시 암호화
    (키 자동교체 및 암호화 등)

보안 관제(Monitoring + Logging)

ⅰ) Trust Adviser: 비용 최적화, 보안, 관련 등의 “권장 사항 제공”

ⅱ) AWS GuardDuty: 인스턴스 침해, 계정 침해, 버킷 침해 “정찰”

ⅲ) AWS Inspector: AWS에 배포된 애플리케이션의 보안 및 규정 준수 “평가”

ⅳ) AWS Shiled: AWS로 들어오는 트래픽을 검사하여 DDoS 예방

ⅴ) AWS CloudTrail: 계정의 보안 감사 지원 서비스(AWS에서 누가 무엇을 했는지)

ⅵ) AWS CloudWatch: 로그 관리 서비스(AWS에서 무슨일이 일어났는지)

보안 관리

  • CSP가 제공하는 권장 사항 설정
  • 서비스 접속 이력 및 사용 이력 로깅
  • DAST, SAST<br
    주기적으로 어플리케이션 전체 점검할 시간을 확보하는 것과, 시큐어 코딩을 통해 개발 단계부터 취약한 코드 수정 필요

2) MSP(Managed Service Provider)

alt text

CMP(Cloud Management Platform)를 활용해 CSP 운영부터 클라우드 전환/구축/컨설팅 등의 서비스를 전문적으로 제공하는 사업자

  • 메가존 CMP
    Hyper billing, Hyper Watch
  • 베스핀 글로벌 CMP
    OpsNow, Dev OS
  • 삼성 SDS CMP
    Cloud in One

1) 클라우드 도입 절차

단계내용
목표 설정도입 이유 등
계획 수립적합한 클라우드 서비스(IaaS, SaaS, …)
클라우드 설계(Public, Private, …)
적합한 CSP 선정(비용, 편의성 고려)
도입
(마이그레이션))		ⅰ) Retain: 기존 시스템 유지
ⅱ) RePlatforming: OS/DB 등 플랫폼만 바꿈
ⅲ) ReHosting: 있는 그대로 옮김(빠름)
ⅳ) ReFactoring: 클라우드 환경에 맞춰 새로 개발
ⅴ) RePurchasing: 기존 시스템 폐기 후 SaaS(완제품) 구매
ⅵ) Retire: 불필요한 시스템 폐기
운영지속적인 보안 모니터링
취약점 관리
대응체계 마련

3. 위협

공급망, 서드파티 위험 증가

2) 사례

CSP 문제

  • 관리 실수
  • 시스템 오류
  • 천재지변

사용자 문제

  • 관리자 실수
  • Snowflake 데이터 유출(크리덴셜 관리 미흡)
    MFA 미적용 및 접근 권한 관리 취약으로 인해 도난당한 로그인 정보를 이용해 클라우드 서버가 공격당함

SKT 해킹사고 사례

3. 대응

1) 아키텍쳐

책임 공유 모델

최근, 멀티/하이브리트 클라우드 환경 확대로 책임 범위가 복잡해졌다.

가용성을 고려한 보안 아키텍쳐

클라우드는 서비스가 24시간 365일 제공되어야 하고, 장애가 발생하더라도 서비스가 유지되어야 한다. 이를 위해서 다음과 같은 구성을 활용할 수 있다.

  • Multi-Region: Region간 접근 통제, 이중화, 백업 정책
  • Multi-Cloud: 표준화된 보안정책, 멀티클라우드 가시성 확보
  • Container: 민감 데이터 격리 등

고성능을 위한 보안 아키텍쳐

고성능을 위해서는 서비스별로 오토 스케일링이 필요하고, 최소한의 잉여자원을 남기는 것이 중요하다.

  • 오토 스케일링 설정
  • 인터페이스와 공용 클라우드 자원을 최소한으로 설정

비용 효율을 위한 보안 아키텍쳐

온프레미스/Private Cloud 대비 저렴한 비용의 아키텍쳐

  • 저렴하거나 무료로 제공되는 경량화된 클라우드 서비스 활용
  • 서비스 사용중에만 리소스 사용(e.g. 서버리스 기능 활용)

2) 관리 범위

기업 내부

관리적 보안기술적 보안물리적 보안
보안 정책
보안 점검
보안 교육		정보 유출 방지
해킹 공격 방어		시설 보안
백업 및 분산 저장

기업 내/외부

alt text

ㅇ

3) 보안 거버넌스

기본적으로 무결성, 기밀성 가용성을 기반으로 책임 추적성까지 적용한다. 이를 위해서는 다음 특성이 필요하다.

  • Surface Reduction
  • Workload Seperation
  • LAnding Zone

보안관리 기준 및 지침

  • ISO/IEC 27000시리즈(27017: 클라우드 특화, 27018: 개인정보 특화)
  • NIST

예시

  • 소규모 클라우드: 비용 효율적인 보안이 중요

  • 대규모 클라우드: 표준화된 자동화, 중앙 집중식 모니터링이 중요

  • 접근제어: 관리콘솔에 대해서는 MFA설정 및 사업장 NAT IP에 대해서만 허용

4) 서비스

5) Keyless

Access KeyKeyless
alt textalt text

클라우드 리소스에 접근하기 위해서는 Access Key가 있어야 한다. 하지만 Key 구조는 Key가 유출되면 접근 권한이 탈취당할 수 있기 때문에, ⅰ) 접근제어(허용된 IP에서만 접근), ⅱ) 보유 수량(IAM 사용자 별 1개의 Key), ⅲ) 교체(90일에 1회 이상 교체, 기존 Key는 15일 이내 파기)의 관리 기준이 존재하였다.

이러한 번거로움을 해결하기 위해 Access Key 대신 클라우드 자체의 권한을 활용하는 방식이 제안되었다.

From AWS

기존 방식

  1. 키 발급: 관리자가 AWS에서 IAM을 생성하고 Access key & Secret Key를 받음
  2. 키 저장: 개발자는 이 키를 복사하여 EC2 서버 내부의 소스코드/환경변수/설정파일에 저장.
  3. 앱 실행: 파일에 저장된 키를 읽어 S3등 AWS 서비스에 요청
  4. 키 관리: 보안 규정에 따라 키 관리가 필요

보안 설정(Keyless)

  1. 권한 부여: IAM Role을 만들고(e.g. S3읽기 권한), EC2 인스턴스에 이 Role을 부여
  2. 자격 증명 요청(앱 → STS)
  3. 자격 증명 전달(STS → 앱): STS(Security Token Service)는 EC2의 Role을 확인 후, 임시 자격 증명을 발급
  4. 앱 실행: 임시 키를 사용해 S3 등 AWS 서비스에 요청

이 외에도, AWS에서 Azure/GCP의 자원에 접근하기 위해서 다음과 같은 방식을 사용할 수 있다.

To AzureTo GCP
@AWS
1) Cognito Identity Pool 생성
2) Pool에서 토큰을 발급받을 수 있는 Role 생성

@Azure
1) Managed Identity 생성
2) Federate Credential에 Cognito URL 등록		@GCP
1) WIF Pool 생성 후 AWS ID 등록
2) GCP Service Account와 WIF Pool을 연결

@AWS
1) GCP 자격증명 파일 EC2로 업로드
EC2 → Cognito: OIDC 토큰 요청
EC2 → Azure AD: 인증 요청
Azure AD → EC2: Azure Access Token 발급
접속		EC2 → GCP: 접속 요청
GCP → EC2: 자격 증명 확인 후 Credential 발급
접속

From Azure

보안 설정(Keyless)

  1. 권한 부여: Azure에서 Managed ID를 생성 후 타깃 Resource에 대한 IAM(RBAC)을 이 ID에 할당.
  2. 자격 증명 요청 (Azure VM → Azure Entra ID)
  3. 자격 증명 전달 (Azure Entra ID → Azure VM): Role을 확인 후 임시 자격 증명 전달
  4. 앱 실행: 임시 키를 사용해 Storage 접속

이 외에도, Azure에서 AWS/GCP의 자원에 접근하기 위해서 다음과 같은 방식을 사용할 수 있다.

To AWSTo GCP
@Azure
1) Azure Managed ID(User Assigned) 생성 및 할당

@AWS
1) IAM Identity Provider에 Azure AD 등록
2) 해당 Provider를 신뢰하는 IAM Role 생성		@Azure
1) App Registration 생성
2) Managed Identity 생성 및 VM 할당

@GCP
1) WIF(Workload Identity Federation) Pool 생성
2) GCP Service Account와 WIF 연결
Azure VM → Azure AD: ID Token(OIDC) 요청
Azure VM → AWS STS: ID Token 전달
AWS STS → Azure VM: 임시 자격 증명 발급
접속		Azure VM → Azure AD: ID Token 요청
Azure VM → GCP WIF: Token 교환 요청
GCP STS → Azure VM: GCP Access Token 발급
접속

From GCP

보안 설정(Key less)

  1. 권한 부여: Service Account를 생성하여 필요한 Role을 부여하고, VM 생성 시 이 Service Account를 연결(Attach) [cite: 1173-1180].
  2. 자격 증명 요청(앱 → Metadata Server): VM 내부 앱(Google Client Library)이 메타데이터 서버에 자격 증명을 요청 [cite: 1259-1260].
  3. 토큰 발급(Metadata Server → 앱): 메타데이터 서버는 Service Account의 권한을 확인하고 Access Token을 반환 [cite: 1254-1256].
  4. 앱 실행: 발급받은 토큰을 사용하여 GCS(Storage) 등 리소스에 접속 [cite: 1261-1268].

이 외에도, GCP에서 AWS/Azure의 자원에 접근하기 위해서 다음과 같은 방식을 사용할 수 있다.

[cite_start]To AWS [cite: 1287-1293, 1368-1389][cite_start]To Azure [cite: 1420-1433, 1490-1496]
@GCP
1) Service Account 생성 및 VM 할당

@AWS
1) IAM Identity Provider에 Google 등록
2) Web Identity 타입의 IAM Role 생성 (Google 신뢰 설정)		@GCP
1) Service Account 생성 및 VM 할당

@Azure
1) App Registration 생성
2) Federated Credential 설정 (Issuer: Google, Subject: GCP SA ID)
GCP VM → Metadata: Google ID Token(JWT) 요청
GCP VM → AWS STS: AssumeRoleWithWebIdentity 호출
AWS STS → GCP VM: 임시 자격 증명 발급
접속		GCP VM → Metadata: Google ID Token 요청
GCP VM → Azure AD: 인증 요청 (ID Token 전달)
Azure AD → GCP VM: Azure Access Token 발급
접속
Domain Knowledge, Cybersecurity
cloud
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.