# CTO로서의 역할에 대한 고찰 - v5: 보안 및 인프라 관리 체계

> 작성일: 2025-12-10
> 대상: 내부 팀원
> 시리즈: CTO 업무 정립 과정 5/10

## v4에서의 깨달음

아키텍처는 시스템의 구조다. 하지만 아무리 좋은 구조라도 **보안**이 뚫리면 소용없다. 한 번의 보안 사고가 회사를 망칠 수 있다.

보안은 "나중에"가 없다. 사고가 나면 이미 늦다. 그리고 보안은 한 번 설정하고 끝이 아니다. 지속적으로 점검하고 개선해야 한다.

## 우리가 직면한 보안 현실

솔직히 말하자. 지금 우리의 보안 상태는:
- 비밀번호 정책이 없다
- API 키가 코드에 하드코딩되어 있다
- 정기적인 보안 점검이 없다
- 데이터 백업이 자동화되어 있지 않다
- 접근 권한 관리가 애매하다

무섭다. 하지만 인정하는 것이 첫 걸음이다.

## 보안의 우선순위

모든 것을 한 번에 할 수는 없다. 우선순위를 정해야 한다.

### 긴급 (이번 주)
1. **환경 변수 분리**: 코드에서 API 키 제거
2. **GitHub 시크릿 검사**: 과거 커밋에 민감 정보 있는지 확인
3. **관리자 비밀번호 변경**: 강력한 비밀번호로

### 중요 (이번 달)
1. **HTTPS 강제**: 모든 통신 암호화
2. **데이터베이스 백업 자동화**: 매일 백업
3. **에러 로그에서 민감 정보 제거**: 스택 트레이스 노출 방지

### 장기 (다음 분기)
1. **침투 테스트**: 전문가에게 의뢰
2. **보안 교육**: 팀원 대상
3. **보안 인증**: ISO 27001 등 검토

## 인증 및 인가 체계

누가 무엇을 할 수 있는지 명확해야 한다.

### 현재 방식
- JWT 토큰 기반 인증
- 유효 기간: 24시간
- Refresh 토큰: 30일

### 개선 사항
1. **다단계 인증 (MFA)**: 중요 계정에 적용
2. **역할 기반 접근 제어 (RBAC)**:
   - Admin: 모든 권한
   - Editor: 콘텐츠 편집
   - Viewer: 읽기만
3. **API 키 관리**:
   - 키 로테이션: 6개월마다
   - 키별 사용량 모니터링
   - 의심 활동 감지

## 데이터 보호

우리가 다루는 데이터는 고객의 사업 정보다. 유출되면 큰 문제다.

### 데이터 분류
1. **Public**: 누구나 볼 수 있는 데이터 (블로그 글 등)
2. **Internal**: 내부 직원만 (내부 문서)
3. **Confidential**: 권한자만 (고객 사업 계획)
4. **Restricted**: 최소 인원만 (결제 정보, 개인정보)

### 보호 조치
- **암호화**:
  - 저장 시: AES-256
  - 전송 시: TLS 1.3
- **백업**:
  - 빈도: 매일 자동
  - 보관: 30일
  - 위치: AWS S3 (암호화)
  - 복구 테스트: 월 1회
- **접근 로그**:
  - 누가, 언제, 무엇을 접근했는지 기록
  - 90일 보관

## 인프라 보안

시스템 레벨의 보안도 중요하다.

### 서버 보안
```
현재 상태 → 목표 상태

[ ] SSH 비밀번호 로그인 → [✓] SSH 키만 허용
[ ] root 직접 로그인 → [✓] sudo 사용자만
[ ] 방화벽 규칙 없음 → [✓] 필요한 포트만 열기
[ ] OS 업데이트 수동 → [✓] 자동 보안 패치
```

### AWS 보안 체크리스트
- [x] MFA 활성화
- [ ] IAM 최소 권한 원칙
- [ ] S3 버킷 공개 차단
- [ ] CloudTrail 로깅 활성화
- [ ] Security Group 최소화
- [ ] RDS 암호화 활성화

## 보안 모니터링

공격을 100% 막을 수는 없다. 하지만 빨리 감지하면 피해를 줄일 수 있다.

### 모니터링 항목
1. **비정상 로그인 시도**
   - 짧은 시간 내 다수 실패
   - 알려지지 않은 IP
   - 새로운 디바이스

2. **비정상 API 사용**
   - 갑작스런 트래픽 증가
   - 오류율 급증
   - 비정상 패턴

3. **데이터 접근 이상**
   - 대량 다운로드
   - 정상 근무 시간 외 접근
   - 권한 없는 접근 시도

### 알림 설정
- **긴급**: Slack + 이메일 + SMS
- **중요**: Slack + 이메일
- **일반**: 이메일만

## 재해 복구 계획 (DR Plan)

"만약 서버가 날아가면?"을 생각해야 한다.

### RTO/RPO 정의
- **RTO (Recovery Time Objective)**: 복구 목표 시간 → 4시간
- **RPO (Recovery Point Objective)**: 허용 데이터 손실 → 24시간

즉, 서버가 날아가도 4시간 내에 복구하고, 최대 24시간 전 데이터까지는 복구한다.

### 복구 절차
```markdown
## 장애 발생 시

### 1단계: 상황 파악 (15분)
- [ ] 장애 범위 확인
- [ ] 영향받는 서비스 목록
- [ ] 사용자 공지 게시

### 2단계: 임시 복구 (1시간)
- [ ] 백업 서버 활성화
- [ ] DNS 변경
- [ ] 기본 기능 복구

### 3단계: 완전 복구 (3시간)
- [ ] 원인 분석
- [ ] 데이터 복구
- [ ] 모든 기능 검증

### 4단계: 사후 조치 (1주일)
- [ ] 포스트모텀 작성
- [ ] 재발 방지 대책
- [ ] 문서 업데이트
```

## 보안 체크리스트

매월 점검할 항목:

### 월간 보안 점검
- [ ] 비밀번호 만료 확인
- [ ] 미사용 계정 비활성화
- [ ] 로그 리뷰 (이상 활동)
- [ ] 백업 복구 테스트
- [ ] 소프트웨어 업데이트
- [ ] 접근 권한 재검토

### 분기별 보안 점검
- [ ] 보안 스캔 실행
- [ ] 침투 테스트
- [ ] 재해 복구 훈련
- [ ] 보안 정책 리뷰

## SECURITY.md 문서 구조

보안 관련 모든 정보를 정리:

```markdown
# Security Policy

## 1. 보고 절차
- 보안 취약점 발견 시 연락처
- 보고 양식

## 2. 인증/인가
- 사용자 인증 방식
- API 키 관리
- 권한 체계

## 3. 데이터 보호
- 암호화 방식
- 백업 정책
- 개인정보 처리

## 4. 인프라 보안
- 서버 접근 관리
- 네트워크 설정
- 방화벽 규칙

## 5. 사고 대응
- 장애 대응 절차
- 연락망
- 에스컬레이션

## 6. 정기 점검
- 월간 체크리스트
- 분기별 감사
```

## 실행 계획

**이번 주**:
- 코드에서 API 키 제거, 환경 변수로 이동
- GitHub 시크릿 스캔 활성화
- 관리자 비밀번호 변경 (1Password 도입)

**다음 주**:
- HTTPS 강제 설정
- 데이터베이스 백업 스크립트 작성
- 보안 모니터링 알림 설정

**이번 달**:
- SECURITY.md 작성
- AWS 보안 체크리스트 완료
- 첫 백업 복구 테스트

## 다음 편 예고

v6에서는 **코드 품질 및 기술 부채 관리**를 다룬다:
- 코드 품질 측정 지표
- 정적 분석 도구 도입
- 기술 부채 추적 방법
- 리팩토링 전략

보안이 방어라면, 코드 품질은 지속 가능성이다.

## 마치며

보안은 무섭다. 하지만 피할 수 없다. 그리고 생각보다 할 수 있는 것이 많다.

완벽한 보안은 없다. 하지만 "아무것도 안 하는 것"과 "기본이라도 하는 것"의 차이는 크다.

이번 주부터 시작하자. 코드에서 API 키부터 제거하자.

---

**글자 수**: 약 2,200자
**다음 편**: v6 - 코드 품질 및 기술 부채 관리