Home

1. 아키텍처 문서화 목적

본 문서는 200명 이하 규모의 초기 기업을 대상으로, AWS 기반 DevSecOps 아키텍처의 설계 원칙과 구현 방안을 체계적으로 정리한 가이드입니다.

문서의 목적은 다음과 같습니다:

안정적이고 보안이 내재화된 인프라 제공: 초기 기업이 별도의 전문 인력 없이도 안전한 클라우드 환경을 즉시 활용 가능
표준화된 환경 제시: IaC 기반으로 모든 리소스와 정책을 코드로 관리하여 환경 간 일관성을 확보
운영 효율성 강화: 배포 자동화, 보안 점검 자동화로 운영 리스크를 최소화
협업 기반 제공: 개발팀·운영팀·보안팀 간 원활한 협업이 가능한 프로세스 제공

2. DevSecOps가 무엇인가?

1) DevSecOps의 개념

DevSecOps는 개발(Development), 운영(Operations), 보안(Security)을 하나의 프로세스로 통합하는 접근 방식입니다. 즉, 보안은 더 이상 배포 후 검증하는 요소가 아니라, 개발 초기부터 코드와 자동화 파이프라인에 내재화된 필수 요소입니다.

이 프로젝트에서는 Terraform 기반 IaC, GitHub Actions CI/CD, 자동화된 보안 점검을 통해 이를 구현했습니다.

2) DevOps와의 차이점

구분	DevOps	DevSecOps
핵심 목표	개발과 운영 자동화, 효율성 강화	개발·운영 + 보안 내재화, 규제 대응, 취약점 사전 차단
보안 접근 방식	배포 이후 점검(Post-Security)	개발 단계에서 보안 검증(Shift-Left Security)
자동화 범위	빌드, 테스트, 배포	빌드, 테스트, 배포 + 보안 스캔(tfsec), 취약점 탐지, 정책 준수 검증

3) DevSecOps의 필요성

보안 인력 부족: 초기 기업은 전담 보안팀이 없는 경우가 많아 수동 검증은 비효율적
설정 실수 리스크: 하나의 권한 설정 오류나 잘못된 네트워크 구성 → 심각한 보안 사고로 이어질 수 있음
Shift-Left 비용 절감: 초기 단계에서 보안 취약점 제거 → 사후 대응 비용 대비 훨씬 경제적임

3. 아키텍처 개요

전체 아키텍처 설계도

아키텍처 동작 흐름
- CI/CD 파이프라인
  - 개발자가 GitHub Repository에 코드를 push
  - GitHub Actions가 실행되어 tfsec으로 보안 스캔 수행
  - 인증은 IAM OIDC를 통해 AWS에 위임
- 인프라 프로비저닝
  - Terraform을 통해 각 계정별 리소스 배포
  - Remote State는 Identity Account의 S3 버킷 + DynamoDB로 관리
- AMI 빌드 및 배포
  - Packer가 표준 AMI 빌드
  - Ansible로 구성 관리 후 AMI Repository에 저장
  - ECS Task가 최신 AMI 또는 컨테이너 이미지 기반으로 실행
- 로그 및 보안 모니터링
  - 모든 API 로그는 CloudTrail에서 Operation Account의 S3 Log Bucket으로 전달
  - EventBridge가 이벤트 트리거 → Lambda가 처리 → OpenSearch로 분석 및 Slack 알림
  - Amazon Inspector가 EC2 및 컨테이너 취약점 스캔 후 결과 알림
- 애플리케이션 트래픽 처리
  - 외부 트래픽 → WAF → ALB → ECS 서비스로 라우팅
  - ECS는 Auto Scaling을 통해 컨테이너 워크로드 조정

1) 어카운트 개요

멀티 어카운트

AWS Multi-Account 전략은 역할별로 계정을 분리하고, 각 계정에 최소 권한을 적용해 보안과 운영 효율성을 강화하는 방법입니다. 이를 통해 보안 강화, 운영 단순화, 비용 가시성 확보, 확장성 보장이 가능합니다.
Management Account
- 역할
  - AWS Organizations 상위 관리 계정
  - IAM Identity Center를 통한 중앙 인증 관리
  - 감사 및 비용 관리
- 주요 리소스
  - CloudTrail: 모든 계정의 API 활동 로깅
  - IAM Identity Center: 사용자 접근 제어
  - Cost & Usage Report, Cost Explorer: 비용 분석 및 보고
  - S3 & DynamoDB (Terraform State 관리)
Identity Account
- 역할
  - IAM Identity Center 기반 인증 및 접근 제어 관리
  - 조직 사용자 계정 및 권한 정책 중앙 관리
- 주요 리소스
  - AWS Organizations
  - IAM Identity Center (Identity Store & SSO)
  - S3 & DynamoDB (Terraform State 관리)
Operation Account
- 역할
  - 중앙 로그 수집 및 운영 리소스 관리
  - 로그 분석 후 보안·운영 모니터링
- 주요 리소스
  - CloudTrail
  - OpenSearch
  - Amazon EventBridge: 보안 이벤트 트리거
  - S3 CloudTrail Logs (로그 저장용 S3 버킷)
  - Lambda Log Processor (CloudTrail 로그 파싱 및 분석 처리)
  - AWS Lambda: 로그 처리 및 알림
  - Packer & Ansible: AMI 빌드 및 설정 관리
  - S3 & DynamoDB (Terraform State 관리)
Production Account
- 역할
  - 애플리케이션 실행 환경 제공
- 주요 리소스
  - S3: 애플리케이션 아티팩트 저장
  - WAF + ALB: 트래픽 보안 및 로드밸런싱
  - ECS: 컨테이너 기반 애플리케이션 실행
  - Task Definitions: 애플리케이션 구성 정의

4. IaC

1) IaC 개요

IaC(Infrastructure as Code)는 인프라 구성을 코드로 정의하고 관리하는 방식입니다. DevSecOps 환경에서 IaC는 인프라 자동화와 보안 내재화를 구현하여, 운영과 개발 간의 불일치를 제거하는 핵심 요소로 작용합니다.

[IaC의 특징]

자동화: 인프라 배포를 자동화하여 운영 효율성 극대화
일관성 보장: 동일한 코드를 통해 모든 환경에서 동일한 인프라 재현 능
투명성: 모든 변경 사항은 코드로 관리되어, Git을 통해 이력 추적 가능

2) IaC 필요성

기존 방식: 서버, 네트워크, 스토리지를 수동으로 설정하여, 작업 시간이 증가하고 인적 오류가 발생할 수 있었음
현대 환경: 클라우드 활용 확산으로 인해, 배포 빈도 및 환경 복잡성이 증가함

[IaC 도입 효과]

비용 절감 및 배포 속도 향상
인프라 구성의 표준화 및 일관성 확보
보안 강화 (암호화, 접근 제어 등 정책 코드화)
변경 사항 자동 추적 및 감사 로그 확보

3) 기술 스택

IaC 도구: Terraform
Backend: AWS S3 (State 저장), DynamoDB (State Lock)

4) Account Baseline

Account Baseline은 본 ****DevSecOps 아키텍처의 멀티 어카운트 구조에서 모든 계정에 공통으로 적용되는 보안 및 운영 표준 설정입니다. 이 설정은 IaC 기반으로 자동화되며, 각 계정의 안전성과 일관성을 보장합니다.

[각 계정 기본 구성 요소]

S3 버킷: Terraform State 저장소 (각 계정의 리소스의 상태 파일을 저장함)
DynamoDB 테이블: State Lock 관리 (동시 실행 방지)
KMS Key: S3 암호화를 위한 고객 관리형 키
IAM Role & Policy: 최소 권한 원칙 기반 Terraform 실행 권한

[목적]

IaC 기반 인프라 관리 표준화
보안 내재화 (암호화, 접근 제어, 감사 로깅)
협업 시 충돌 방지 및 변경 이력 관리

5) Terraform State 관리

Terraform은 인프라의 실제 상태를 State 파일에 저장하여 변경 사항을 추적합니다.

State 파일은 ‘Source of Truth’ 이므로 안전한 관리가 필수입니다.

[Remote State 장점]

S3
- 중앙 집중형 저장 방식: 모든 팀원이 동일한 State 파일을 참조하여 환경 불일치 방지
- 멀티 환경 관리 용이: 계정별로 state를 분리하여 관리 가능
- 협업 효율성 향상: 로컬 State 공유 불필요
DynamoDB
- State Lock: 동시 실행으로 인한 충돌 및 데이터 손상 방지

[예시 Backend 설정]

# identity 계정의 state를 저장하는 S3 버킷의 baceknd 설정 
terraform {
  backend "s3" {
    bucket         = "cloudfence-identity-state"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-2"
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}

5. CI/CD

1) 개요

CI/CD는 코드 변경 사항을 효율적으로 통합(Continuous Integration) 하고, 자동화된 방식으로 배포(Continuous Deployment) 하는 일련의 프로세스를 의미합니다.

[CI (지속적인 통합)]

개발자가 변경한 코드를 지속적으로 통합
충돌 조기 발견 및 자동 테스트로 품질 유지

[CD (지속적인 배포)]

테스트를 통과한 코드를 운영 환경에 자동으로 배포
배포 속도 향상 및 수작업 최소화

[도입 효과]

빠른 피드백
수작업 배포로 인한 실수 감소
품질 유지 및 관리 효율화

2) 사용 도구 및 기술 스택

Github Actions를 통한 워크플로우 자동화
AWS OIDC 기반 인증을 통한 AWS 자격 증명
Infracost를 통한 리소스 변경에 따른 비용 예측
tfsec를 통한 인프라 보안 취약점 스캐너

3) 파이프라인 구성

CI 파이프라인 (ci.yml)

실행 조건: main 브랜치로 Pull Request 생성 시
변경 감지: 변경된 .tf 파일 존재 여부를 기준으로 실행 대상 디렉토리 필터링
Matrix 구성: 변경된 디렉토리를 배열로 구성해 병렬 실행

단계별 설명:

변경 디렉토리 감지
- PR 브랜치 vs main 브랜치 비교하여 변경 파일 추출
- .tf 파일 포함 여부로 CI 대상 디렉토리 필터링
Terraform 실행
- OIDC 기반 AWS 인증
- terraform init, fmt, validate 실행
- terraform plan 결과 PR 댓글로 출력
보안 스캔 (tfsec)
- HIGH 이상 취약점 발생 시 실패 처리
- LOW / MEDIUM 경고는 Slack 알림
비용 분석 (Infracost)
- 변경 리소스 비용 분석 결과 PR 댓글로 출력
Drift 탐지
- 변경 사항과 현재 상태가 불일치할 경우 알림 표시

[PR comment: terraform Plan 결과 출력]

테이블에서 Plan의 상태, 실행한 파일의 경로와 시간을 파악할 수 있습니다.

Status
- success: Terraform plan 시 변경 사항이 오류 없이 정상적으로 적용될 예정일 경우 표시 Plan output을 통해 변경된 리소스 및 설정 확인 가능, 변경 사항이 없는 경우 “no changes”라는 문구 표시
- failed: Terraform plan 시 변경 사항이 정상적으로 적용되지 않고, 오류가 발생할 때 표시 구체적인 오류 내용은 아래의 Plan Error에서 확인 가능
Directory: 변경된 인프라 파일 중 plan을 실행한 파일 경로
Executed At: Terraform plan 명령어가 실행된 날짜와 시간

[PR comment: Infracost 비용 분석 결과]

리소스 비용이 없는 경우

리소스 비용이 나온 경우

CD 파이프라인 (cd.yml)

실행 조건: main 브랜치에 변경 사항 push 될 때
변경 감지: dorny/paths-filter 사용하여 .tf 파일 변경 유무 확인
제외 조건: .terraform, modules 하위는 무시