SW BBANG K

브라우저 주소창에 '주의 요함' 또는 'Not Secure' 경고가 뜨는 순간, 사용자 이탈은 시작된다. EC2 위에서 Nginx로 서비스를 운영 중인데 아직 HTTP만 열려 있다면, Let's Encrypt의 무료 SSL 인증서와 Certbot을 이용해 30분 안에 HTTPS를 완성할 수 있다. 이 글은 실제 운영 환경에서 겪는 함정 — 보안 그룹 누락, 도메인 검증 실패, 자동 갱신 설정 오류 — 까지 포함해 처음부터 끝까지 다룬다. TL;DR — EC2 HTTPS 설정 핵심 요약 단계 작업 주요 확인 포인트 1 보안 그룹에서 443 포트 개방 인바운드 규칙 HTTPS(443) 추가 2 도메인 A 레코드를 EC2 퍼블릭 IP로 연결 DNS 전파 확인 필수 3 Nginx 설치 및 서버 블록 구성 server_name에 실제 도메인 입력 4 Certbot 설치 및 인증서 발급 --nginx 플러그인 사용 5 자동 갱신 크론 또는 systemd 타이머 확인 certbot renew --dry-run 통과 여부 HTTPS 인증서 발급이 작동하는 방식 Let's Encrypt는 ACME(Automated Certificate Management Environment) 프로토콜로 도메인 소유권을 검증한다. Certbot의 --nginx 플러그인은 HTTP-01 챌린지를 사용하는데, 이 과정에서 Let's Encrypt 서버가 외부에서 http://<your-domain>/.well-known/acme-challenge/ 경로에 접근할 수 있어야 한다. 즉, EC2 보안 그룹의 80번 포트가 열려 있지 않으면 챌린지 자체가 실패한다 — 이게 가장 흔한 첫 번째 함정이다. sequenceDiagram participant CB a...

웹 앱에 회원가입과 로그인을 붙이려고 Cognito를 열었다가 'User Pools'와 'Identity Pools' 두 개가 보이는 순간 멈칫하게 된다. 이름도 비슷하고, 콘솔에서 나란히 있으니 같은 것처럼 보이지만 실제로는 완전히 다른 문제를 해결하는 서비스다. AWS Cognito User Pools로 사용자 데이터베이스를 관리하는 것이 일반적인 로그인 구현의 정답이다. TL;DR — AWS Cognito User Pools vs Identity Pools 항목 User Pools Identity Pools 핵심 역할 사용자 디렉터리 (회원가입/로그인) AWS 리소스 접근 권한 위임 발급 토큰 ID Token, Access Token, Refresh Token (JWT) 임시 AWS 자격증명 (STS) 사용 시나리오 앱 로그인, 사용자 프로필 관리 S3 직접 업로드, DynamoDB 직접 접근 사용자 DB 관리 ✅ 직접 관리 ❌ 관리하지 않음 소셜 로그인 연동 Google, Facebook, SAML 등 내장 지원 User Pools 포함 외부 IdP 결과를 AWS 권한으로 교환 AWS Cognito의 두 구성요소가 동작하는 방식 User Pools는 말 그대로 사용자 데이터베이스다. 이메일/비밀번호, 전화번호, 소셜 계정으로 가입한 사용자 레코드를 저장하고, 인증 성공 시 JWT 토큰 세 개(ID Token, Access Token, Refresh Token)를 발급한다. 앱 서버나 API Gateway는 이 JWT를 검증해서 요청을 인가한다. Identity Pools는 사용자를 저장하지 않는다. 대신 이미 인증된 사용자(User Pools JWT, Google OAuth 토큰, SAML Assertion 등)를 받아서 AWS STS로부터 임시 자격증명을 ...

신규 개발자가 입사할 때마다 S3, CodeCommit, CloudWatch 정책을 한 명씩 붙이다 보면, 어느 순간 누군가의 계정에만 정책이 빠져 있거나 퇴사자 계정에 권한이 남아 있는 상황을 마주하게 된다. IAM 그룹은 이 문제를 구조적으로 해결하는 가장 기본적인 수단이다. TL;DR: IAM 그룹 vs 사용자 직접 연결 기준 사용자 직접 연결 IAM 그룹 연결 신규 사용자 온보딩 정책을 매번 수동 연결 그룹 추가만으로 완료 권한 변경 사용자 수만큼 반복 작업 그룹 정책 1회 수정으로 전파 퇴사자 처리 각 정책을 개별 분리 그룹 멤버십 제거로 권한 회수 감사(Audit) 사용자별 정책 목록 확인 필요 그룹 단위로 권한 범위 파악 가능 실수 가능성 높음 (누락, 중복 발생) 낮음 (그룹 정책이 단일 진실 공급원) IAM 그룹이 작동하는 방식 IAM 그룹은 사용자의 컨테이너다. 그룹 자체는 자격 증명이 아니므로 로그인하거나 임시 자격 증명을 발급받을 수 없다. 그룹에 연결된 정책은 그룹의 모든 멤버에게 적용된다. 사용자가 여러 그룹에 속하면 각 그룹의 정책이 합산되어 평가된다. 한 사용자에게 직접 연결된 정책과 그룹을 통해 상속된 정책은 IAM 평가 엔진에서 동일하게 처리된다. 단, Explicit Deny는 어떤 경로로 Allow가 부여되었든 항상 우선한다. graph LR G["Developers 그룹 정책 연결 지점"] --> P1["AmazonS3ReadOnlyAccess"] G --> P2["CloudWatchReadOnlyAccess"] U1["alice"] --> G U2["bob"] --> G U3["신규 사용자 추가 ...

S3 버킷에 암호화를 적용하려고 콘솔을 열었을 때, 'AWS 관리형 키(aws/s3)'와 '고객 관리형 키(CMK)' 두 가지 선택지 앞에서 멈춰본 경험이 있을 것이다. 단순히 '암호화만 되면 되는 거 아닌가?'라고 생각했다가, 나중에 KMS API 호출 비용 청구서를 받고 당황하거나, 감사 요건을 충족하지 못해 다시 설계를 뒤집는 상황이 실제로 발생한다. AWS KMS 키 유형 선택은 보안 정책, 운영 복잡도, 비용 모두에 직접적인 영향을 미친다. TL;DR: AWS 관리형 키 vs 고객 관리형 키 (CMK) 핵심 비교 항목 AWS 관리형 키 (aws/s3) 고객 관리형 키 (CMK) 키 생성 주체 AWS가 자동 생성 사용자가 직접 생성 키 정책 제어 불가 (AWS 관리) 완전 제어 가능 키 로테이션 제어 AWS 자동 관리 (1년) 사용자 설정 가능 교차 계정 접근 불가 키 정책으로 허용 가능 월 키 관리 비용 무료 키당 월 $1 (대칭 키 기준) API 호출 비용 발생 (요청당 과금) 발생 (요청당 과금) CloudTrail 감사 제한적 모든 키 사용 이벤트 기록 Bucket Key 지원 지원 지원 AWS KMS가 S3 암호화에서 동작하는 방식 S3의 SSE-KMS 암호화는 봉투 암호화(envelope encr...

레포지토리가 private이니까 괜찮다고 생각했던 DB 비밀번호가 GitHub 유출 사고의 주인공이 되는 건 순식간이다. Secrets Manager를 왜 써야 하는지, 자동 로테이션이 실제로 어떻게 동작하는지 운영 관점에서 정리한다. TL;DR: 핵심 비교 항목 하드코딩 / 환경변수 AWS Secrets Manager 비밀번호 노출 경로 코드, 로그, CI/CD 환경변수 API 호출 시점에만 메모리 접근 로테이션 수동 (배포 필요) 자동 (Lambda 기반, 무중단) 감사 추적 없음 CloudTrail로 모든 접근 기록 접근 제어 코드 접근 권한 = 비밀번호 접근 IAM 정책으로 세분화 비용 0원 (보안 사고 비용 제외) 시크릿당 월 과금 — AWS 공식 문서 확인 왜 Secrets Manager가 필요한가 — 하드코딩의 실제 위협 모델 'private 레포니까 괜찮다'는 가정이 깨지는 시나리오는 생각보다 많다. 팀원 계정 탈취, 실수로 public 전환, CI/CD 파이프라인 로그 노출, 컨테이너 이미지 레이어 분석 — 이 중 하나라도 발생하면 비밀번호가 코드에 있는 순간 게임 오버다. 환경변수도 완전한 해결책이 아니다. docker inspect , /proc/<pid>/environ , 애플리케이션 에러 로그에 환경변수가 그대로 출력되는 사례는 실제 운영 환경에서 반복적으로 발생한다. 비밀번호를 '어디에 두느냐'가 아니라 '누가, 언제, 어떤 경로로 접근하느냐'를 제어하는 것이 핵심이다. 하드코딩은 자물쇠 없는 금고다. 금고가 지하실에 있다고 안전한 게 아니다 — 지하실 문이 열리는 순간 모든 게 노출된다. Secrets Manager 동작 원리 Secrets Manager는 단순한 키-값 저장소가 아니다. 시크릿 값 자체...

어느 날 오전, 모니터링 알림이 울리고 확인해보니 운영 중이던 EC2 인스턴스가 없다. 콘솔에서 찾을 수 없고, Auto Scaling 그룹도 아니다. 누군가 TerminateInstances API를 직접 호출한 것이다. CloudTrail Event History는 이 상황에서 가장 먼저 열어야 할 도구다. TL;DR — 핵심 요약 단계 목적 핵심 확인 항목 1. Event History 필터 TerminateInstances 이벤트 검색 이벤트 이름, 리소스 ID 2. 이벤트 상세 확인 호출 주체 식별 userIdentity, sourceIPAddress 3. CLI로 정밀 조회 인스턴스 ID 기준 필터링 lookup-events 파라미터 4. 원인 분석 역할/사용자 권한 검토 assumedRole, sessionContext CloudTrail Event History가 동작하는 방식 CloudTrail은 AWS 계정 내 API 호출을 기록하는 감사 로그 서비스다. 리전별로 활성화되며, 별도 Trail을 구성하지 않아도 Event History 는 기본적으로 각 리전에서 최근 90일간의 관리 이벤트(Management Events)를 자동으로 보관한다. EC2 인스턴스 종료는 TerminateInstances API 호출로 기록되며, 이 이벤트에는 호출 주체, 시간, 소스 IP, 대상 리소스 정보가 포함된다. 중요한 점은 Event History가 기록하는 것은 관리 이벤트(Management Events) 뿐이라는 것이다. S3 객체 읽기 같은 데이터 이벤트는 별도 Trail 설정이 필요하다. EC2 종료는 관리 이벤트에 해당하므로 기본 Event History에서 조회 가능하다. sequenceDiagram participant U as IAM 사용자/역할 partic...

처음 IAM 정책 JSON을 열어봤을 때, 왜 이 권한이 작동하는지 혹은 왜 막히는지 파악하지 못해서 한참을 헤맨 경험이 있을 것이다. IAM 정책 구조 의 네 가지 핵심 요소 — Effect , Action , Resource , Condition — 를 정확히 이해하지 못하면, 권한 오류는 항상 예상치 못한 곳에서 터진다. TL;DR — IAM 정책 핵심 요소 비교 요소 역할 필수 여부 핵심 주의사항 Effect Allow 또는 Deny 결정 필수 Explicit Deny는 모든 Allow를 재정의 Action 허용/거부할 API 작업 지정 필수 서비스 네임스페이스:작업명 형식 필수 Resource 정책이 적용될 AWS 리소스 범위 필수 일부 작업은 * 만 허용 Condition 정책 적용 조건 (선택적 필터) 선택 조건 키는 서비스별로 지원 범위가 다름 IAM 정책이 평가되는 방식 IAM 정책은 단순한 허용 목록이 아니다. AWS는 요청이 들어올 때마다 해당 요청에 적용되는 모든 정책을 수집하고, 정해진 평가 로직에 따라 최종 Allow/Deny를 결정한다. 이 평가 순서를 모르면 왜 권한이 막히는지 절대 파악할 수 없다. graph TD A["API 요청 수신"] --> B{"Explicit Deny 존재 여부"} B -- "Yes" --> C["즉시 거부 (Deny)"] B -- "No...