Day 4 - 데이터 보호의 기본: 암호화, 키 관리, 비밀 보관

왜 암호화라는 게 필요해졌나

클라우드 이전에는 보안을 이렇게 생각했다. "서버가 우리 전산실 안에 있고 그 방문은 잠겨 있으니 안전하다." 그런데 이 방식은 담장이 뚫리는 순간 아무것도 남지 않는다. 백업 테이프를 옮기다 분실했는데 안의 고객 명부가 평문이거나, 폐기한 디스크에서 예전 데이터가 되살아나는 사고가 반복됐다. "접근을 막는 것"만으로는 부족하다는 뜻이다. 그래서 발상을 하나 더 얹었다. 데이터 자체를 못 읽게 만들어 둔다.

일기장을 남이 못 보게 하는 방법은 두 가지다. ① 방문을 잠근다 — 접근 통제(IAM, 방화벽). ② 일기를 나만 아는 암호로 쓴다 — 암호화. 보안은 이 둘을 겹쳐서 쓴다. 하나가 뚫려도 다른 하나가 남기 때문이며, 이걸 심층 방어(Defense in Depth)라 부른다.

용어를 세 개만 먼저 잡고 간다. 사람이 그냥 읽을 수 있는 원래 데이터가 평문(Plaintext), 알아볼 수 없게 변환된 결과가 암호문(Ciphertext), 그 둘 사이를 오가게 해주는 비밀값이 키(Key)다. 편지에 비유하면 그대로 쓴 편지 / 암호로 바꿔 쓴 편지 / 해독 규칙표에 해당한다.

암호화가 안전한 이유는 알고리즘이 비밀이어서가 아니라 키가 비밀이기 때문이다. 그래서 암호화의 안전성은 곧 열쇠 관리의 안전성이고, 뒤에 나올 KMS·CloudHSM이 존재하는 이유가 바로 이것이다.

담장을 믿지 말고 안에 든 것 자체를 잠가야 한다. 그리고 열쇠가 어디 있는지 늘 알고 있어야 한다.

암호화의 두 가지 상태

데이터는 두 가지 상황에서 보호되어야 한다.

1. 전송 중 암호화 (Encryption in Transit): 데이터가 네트워크를 통해 이동하는 동안의 보호. 브라우저와 서버 사이를 오가는 데이터를 가로채도 읽을 수 없게 한다. 대표 기술은 TLS/SSL(https://로 시작하는 통신)이다.

2. 저장 시 암호화 (Encryption at Rest): 데이터가 디스크나 스토리지에 저장되어 있는 동안의 보호. 누군가 물리 디스크나 저장된 파일에 접근해도 키 없이는 읽을 수 없다. S3, EBS, RDS 등 대부분의 AWS 스토리지 서비스가 저장 시 암호화를 지원한다.

"이동 중 가로채기를 막아라" → 전송 중 암호화(TLS). "저장된 데이터를 보호하라" → 저장 시 암호화. 시험에서 두 상태를 구분하는 문제가 있으므로 "in transit vs at rest"를 또렷이 기억한다.

전송 중 암호화를 그림으로 이해하기

가장 쉬운 비유는 엽서와 봉인된 편지다. 엽서는 겉면에 내용이 다 적혀 있어 우체국 직원도 배달원도 다 읽을 수 있다 — 암호화되지 않은 통신(http://)이다. 봉인된 편지는 받는 사람만 뜯어볼 수 있다 — TLS로 암호화된 통신(https://)이다.

카페 공용 와이파이로 쇼핑몰에 로그인할 때를 떠올려 본다. 같은 와이파이에 붙은 사람은 오가는 신호를 들여다볼 수 있지만, 사이트가 https://라면 신호를 다 받아 적어도 아이디와 비밀번호는 뒤죽박죽인 글자로만 보인다. 주소창의 자물쇠 아이콘이 "이 통신은 봉인돼 있다"는 표시다.

여기에 딸린 실무 골칫거리가 하나 있었다. TLS를 쓰려면 인증서(Certificate)가 필요한데, 인증서는 유효기간이 있어 주기적으로 갱신해야 한다.

• AWS Certificate Manager(ACM): TLS/SSL 인증서를 발급·저장·갱신해주는 서비스. ACM에서 발급한 공용 인증서는 갱신이 자동 처리돼 "만료 깜빡" 사고를 막는다. 인증서는 CloudFront, 로드 밸런서, API Gateway 같은 앞단 서비스에 연결해 쓴다.

한 중견 유통사는 쇼핑몰 인증서 갱신을 담당 직원이 달력에 메모해 수동으로 처리했다. 그 직원이 퇴사한 다음 해 아무도 모르는 사이 인증서가 만료됐고, 월요일 아침 접속한 고객들에게 빨간 경고 화면이 떴다. 사람이 기억해야 할 일을 사람에게 맡긴 것이 원인이었다.

저장 시 암호화를 그림으로 이해하기

이번 비유는 창고에 쌓아둔 상자다. 창고 문을 아무리 튼튼하게 잠가도 도둑이 벽을 뚫거나 직원이 상자를 들고 나가면 끝이다. 그런데 상자 안 서류가 전부 암호로 적혀 있다면? 통째로 가져가도 얻는 게 없다.

AWS에서 저장 시 암호화는 대체로 체크박스 하나로 켜진다. 애플리케이션 코드를 고칠 필요가 거의 없다. 쓸 때 자동으로 잠기고 권한 있는 요청이 읽을 때 자동으로 풀리므로, 사용자 입장에서는 달라진 게 없는데 디스크 위의 실체만 암호문으로 바뀌어 있다. S3의 객체, EBS 볼륨과 스냅샷, RDS의 저장 파일과 백업, EFS의 파일, DynamoDB의 항목이 모두 이런 방식으로 보호된다.

한 가지 더 구분할 짝이 있다. 누가 잠그느냐다. AWS 서비스가 저장하는 시점에 잠그면 서버 측 암호화(Server-Side), 내 애플리케이션이 보내기 전에 잠그고 보내면 클라이언트 측 암호화(Client-Side)다. 설정이 간단한 서버 측이 기본이고, "AWS조차 평문을 보면 안 된다"는 요구가 있을 때만 클라이언트 측을 쓴다.

⚠️ 함정: "저장 시 암호화를 켰으니 완전히 안전하다"는 문장은 오답 신호다. 저장 시와 전송 중은 별개이며, 디스크가 암호화돼 있어도 그 데이터를 http://로 내려받으면 네트워크 구간에서는 그대로 노출된다.

⚠️ 함정: 암호화는 잘못 부여한 권한을 막아주지 않는다. S3 버킷이 암호화돼 있어도 "누구나 읽기 가능"으로 공개해 두면 요청자에게는 복호화된 평문이 그대로 내려간다. 암호화는 "매체를 훔쳐간 사람"을 막는 장치이지 "권한을 받은 요청"을 막는 장치가 아니다. 그래서 암호화와 IAM은 항상 같이 간다.

KMS: 암호화 키를 관리하는 서비스

암호화를 하려면 키(Key)가 필요하다. 그런데 키 자체를 어디에 어떻게 안전하게 보관하느냐가 새로운 문제다. 이걸 해결하는 것이 AWS KMS(Key Management Service)다.

KMS는 암호화 키를 생성·저장·관리·교체해주는 완전 관리형 서비스다. S3, EBS, RDS 등 대부분의 AWS 서비스와 통합되어, 체크박스 하나로 "이 데이터를 KMS 키로 암호화" 설정을 할 수 있다. 키에 대한 접근은 IAM으로 통제하고, 누가 언제 키를 썼는지는 CloudTrail에 기록된다.

KMS의 키 관리 방식:

• AWS 관리형 키: AWS가 대신 관리.
• 고객 관리형 키(CMK): 고객이 직접 만들고 권한·교체 정책을 통제.

"AWS 서비스 전반의 암호화 키를 손쉽게 만들고 관리하라"가 보이면 KMS다. 키 관리를 위임하면서도 통합이 간편한 것이 KMS의 핵심 가치다.

열쇠 관리가 왜 그렇게 어려운 일인가

집 현관에 최고급 도어락을 달아놓고 비밀번호를 옆 우편함에 포스트잇으로 붙여둔다면 도어락은 아무 의미가 없다. 암호화도 똑같다. 데이터를 아무리 튼튼히 잠가도 열쇠가 그 옆에 놓여 있으면 잠근 적 없는 것과 같다. 그런데 실무에서 열쇠를 제대로 두는 일은 성가시다. 열쇠를 어디에 둘지, 누가 접근하게 할지, 언제 바꿀지, 누가 언제 썼는지 어떻게 남길지를 전부 정해야 한다. 회사마다 각자 해결하다 보니 열쇠 관리가 오히려 보안의 가장 약한 고리가 되곤 했다.

KMS는 이 질문들에 대한 답을 하나의 서비스로 묶어 제공한다. 은행 대여금고를 빌리는 것과 비슷하다. 금고를 직접 만들고 지키는 대신 전문 기관의 금고를 빌리고, 나는 "누가 이 칸을 열 수 있는지"만 정한다. 중요한 성질이 하나 있다. 키 자체는 KMS 밖으로 나오지 않는다. 요청을 KMS 안으로 보내고 결과만 돌려받는 구조라 키가 복사·유출될 여지가 원천적으로 줄어든다.

앞서 던진 질문에는 이렇게 답한다. 누가 쓸 수 있는지는 IAM 정책과 키 정책으로 통제하고, 누가 언제 썼는지는 CloudTrail에 남으며, 주기적 교체는 고객 관리형 키에 자동 교체를 켜두면 되고, 다른 서비스와의 연결은 S3·EBS·RDS 화면에서 키를 고르기만 하면 끝난다.

함정: KMS 키 삭제는 그 키로 암호화한 데이터를 영구히 못 읽게 만든다. 그래서 KMS는 즉시 삭제가 아니라 대기 기간을 둔 예약 삭제 방식을 쓴다.

의료 데이터를 다루는 한 헬스케어 스타트업은 환자 기록을 암호화하면서 열쇠 문자열을 서버 설정 파일에 넣어두고 있었다. 서버와 개발자가 늘면서 그 열쇠는 여러 노트북과 저장소로 복사됐고, 결국 "이 열쇠 사본이 세상에 몇 개인지 아무도 대답 못 하는 상태"가 됐다. 이 회사는 열쇠를 KMS로 옮기고 서버에는 열쇠 대신 KMS를 호출할 권한(IAM 역할)만 부여했다. 그러자 열쇠 사본이 사라졌고, 사용 기록이 CloudTrail에 남았으며, 퇴사자 차단은 권한 회수만으로 끝나게 됐다.

CloudHSM: 전용 하드웨어 키 관리

KMS는 여러 고객이 공유하는 인프라 위에서 동작한다(키는 격리되지만). 그런데 일부 규제 산업은 "키를 우리 전용 하드웨어에 두고, AWS조차 접근하지 못하게 하라"고 요구한다. 이때 쓰는 것이 AWS CloudHSM이다.

CloudHSM은 고객 전용 하드웨어 보안 모듈(HSM, Hardware Security Module)을 제공한다. 키가 검증된 전용 하드웨어 안에서만 다뤄지며, 고객이 키를 완전히 단독 통제한다. 더 엄격한 규정 준수(예: FIPS 140-2 Level 3)나 키에 대한 완전한 단독 통제가 필요할 때 선택한다.

"전용 하드웨어에서, AWS도 접근 못 하게, 키를 완전히 단독 통제하라"가 보이면 CloudHSM이다. 그 외 일반적인 키 관리는 통합이 쉬운 KMS가 기본 선택이다.

앞서 KMS를 은행 대여금고에 비유했다. 그렇다면 CloudHSM은 집 지하실에 직접 설치한 전용 금고다. 관리가 번거로운 대신 "여기엔 나 말고 아무도 손댈 수 없다"를 스스로 증명할 수 있다. 그 증명을 감사에게 제출해야 하는 일부 산업만 전용 금고를 짓는다.

함정: "보안이 더 중요하니까 무조건 CloudHSM"은 시험에서 오답 유도 선택지다. 특별한 단서 없이 "암호화 키를 관리하고 싶다"고만 하면 정답은 KMS다. CloudHSM이 정답이 되려면 문항 안에 전용 하드웨어, 단독 통제, AWS도 접근 불가, 엄격한 규제 요구(FIPS 등) 같은 단서가 반드시 등장한다.

카드 결제를 대행하는 한 회사가 감사에서 "결제 승인에 쓰는 키가 저장·사용되는 물리 장비를 특정하고, 접근 가능한 사람 명단을 제출하라"는 요구를 받았다. 관리형 서비스로는 답할 수 없는 질문이었다. 이 회사는 결제 승인 키만 CloudHSM으로 옮기고 나머지 로그·백업 암호화는 그대로 KMS를 썼다. 현실에서는 이렇게 "규제가 걸린 부분만 CloudHSM"으로 가는 경우가 많다.

Secrets Manager: 비밀 정보의 안전한 보관

데이터베이스 비밀번호, API 키, 토큰 같은 비밀(Secret)을 코드에 하드코딩하거나 설정 파일에 평문으로 두는 것은 위험하다. 유출되면 곧바로 침해로 이어진다. AWS Secrets Manager는 이런 비밀 정보를 안전하게 저장하고, 애플리케이션이 실행 중에 안전하게 꺼내 쓰도록 해준다.

핵심 특징은 자동 교체(rotation)다. 예를 들어 RDS 데이터베이스 비밀번호를 주기적으로 자동 변경하도록 설정하면, 사람이 손대지 않아도 비밀이 정기적으로 갱신된다.

"DB 비밀번호/API 키를 코드에 박지 않고 안전하게 보관·자동 교체하라"가 보이면 Secrets Manager다. "키(암호화용)"는 KMS, "비밀(자격 증명)"은 Secrets Manager로 구분하면 헷갈리지 않는다.

이 서비스가 생긴 이유

개발을 시작하면 누구나 한 번은 소스코드 안에 데이터베이스 주소와 비밀번호를 그대로 적어 넣는다. 문제는 그 코드가 혼자 보는 물건이 아니라는 점이다. 코드는 팀원 전원의 노트북으로 복제되고, 형상 관리 저장소의 과거 기록에는 지운 뒤에도 남는다. 무엇보다 비밀번호를 바꾸려면 코드를 고치고 다시 배포해야 하므로 결국 아무도 바꾸지 않게 된다.

Secrets Manager는 이 구조를 뒤집는다. 비밀번호를 코드가 아니라 금고 안에 두고, 코드에는 "그 금고의 몇 번 칸"이라는 이름만 적는다.

[예전] 코드 ──► "비밀번호는 p@ssw0rd!"   (코드 안에 그대로)
[지금] 코드 ──► "prod/주문DB/자격증명 을 달라"
                  ▼ (IAM 권한 확인)
           [Secrets Manager] ──► 현재 유효한 값 응답 + 주기적 자동 교체

이렇게 바꿔야 자동 교체가 비로소 가능해진다. 코드에 값이 박혀 있지 않으니 금고가 비밀번호를 갈아 끼워도 애플리케이션은 다음에 물어볼 때 새 값을 받아갈 뿐이다. RDS 같은 데이터베이스와는 이 교체가 통합돼 있어 양쪽 값을 함께 갱신해준다.

Secrets Manager vs Parameter Store

자주 함께 등장하는 짝이 AWS Systems Manager Parameter Store다. 둘 다 값을 안전하게 저장해 주지만 무게중심이 다르다.

시험 수준에서는 이 한 줄이면 충분하다. "자동 교체"라는 단어가 문항에 있으면 Secrets Manager.

오늘 나온 서비스들은 역할이 비슷해 자주 뒤섞이는데, "무엇을 보관하는가"로 나누면 깔끔하다. 열쇠는 KMS(전용 하드웨어면 CloudHSM), 비밀번호·API 키는 Secrets Manager, TLS 인증서는 ACM이다.

함정: "API 키를 KMS에 저장한다"는 선택지는 그럴듯해 보이지만 틀렸다. KMS는 키를 만들고 쓰게 해주는 곳이지 임의의 비밀 문자열을 넣어두는 창고가 아니다. 반대로 "데이터베이스를 암호화할 키를 Secrets Manager에서 만든다"도 오답이다. 만들고 쓰는 열쇠는 KMS, 넣어두고 꺼내 쓰는 비밀값은 Secrets Manager.

시험에 이렇게 나온다

CLF-C02의 데이터 보호 문항은 대부분 "문장 속 단서 → 서비스" 단순 매칭이다. 아래 표의 왼쪽 표현이 보이면 오른쪽을 떠올리면 된다.

오답 함정: ① 전송 중과 저장 시를 하나로 묶는 서술(둘은 별개다) ② 단서 없이 CloudHSM을 고르는 것(기본은 KMS) ③ 암호화가 권한 문제까지 해결한다는 서술(권한은 IAM의 몫) ④ Secrets Manager와 KMS를 뒤바꾸는 것(비밀값이냐 열쇠냐).

암호화·키 관리 서비스별 한 줄 정체성

다음 글에서는 Week 4 전체 — 공동 책임 모델·IAM·보안 서비스·규정 준수·데이터 보호 — 를 종합 복습하며, 시험에서 자주 헷갈리는 포인트를 한 번에 정리한다.

📖 용어

• 암호화(Encryption) : 데이터를 열쇠 없이는 읽을 수 없는 형태로 바꾸는 것. 훔쳐가도 소용없게 만드는 장치다.
• 평문 / 암호문 / 키 : 그냥 읽히는 원본 / 알아볼 수 없게 변환된 결과 / 그 둘을 오가게 하는 비밀값.
• 전송 중 암호화(in transit) : 네트워크를 오가는 동안 보호. https://의 TLS가 대표.
• 저장 시 암호화(at rest) : 디스크·스토리지에 놓여 있는 동안 보호. 대개 체크박스로 켠다.
• TLS/SSL : 통신 구간을 봉인해 중간에서 못 읽게 하는 표준 기술. 브라우저 자물쇠 아이콘의 정체.
• ACM(Certificate Manager) : TLS 인증서를 발급·저장·자동 갱신해주는 서비스. 만료 사고를 막는다.
• KMS : 암호화 키를 만들고 보관·통제·교체해주는 관리형 서비스. 키 관리의 기본 선택지.
• CloudHSM : 고객 전용 하드웨어 보안 모듈. AWS도 접근 못 하는 단독 키 통제가 필요할 때 쓴다.
• Secrets Manager : 비밀번호·API 키 같은 자격 증명을 보관하고 주기적으로 자동 교체해주는 금고.
• Parameter Store : 설정값·구성 파라미터를 보관하는 범용 저장소. 자동 교체는 Secrets Manager의 몫이다.
• 심층 방어(Defense in Depth) : 접근 통제·암호화·탐지를 겹겹이 쌓아 하나가 뚫려도 버티게 하는 사고방식.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

웹 브라우저와 서버 사이를 오가는 데이터를 가로채기로부터 보호하는 것은 어떤 유형의 암호화인가?

• A저장 시 암호화(at rest)
• B전송 중 암호화(in transit)
• C디스크 암호화
• D키 교체

문제 2

S3, EBS, RDS 등 여러 AWS 서비스에서 사용하는 암호화 키를 손쉽게 생성하고 중앙에서 관리하려 한다. 가장 적합한 서비스는?

• AAWS Secrets Manager
• BAWS KMS
• CAmazon Macie
• DAWS Artifact

문제 3

엄격한 규정 준수 요구에 따라 암호화 키를 고객 전용 하드웨어에서 단독으로 통제해야 한다. 가장 적합한 서비스는?

• AAWS KMS의 AWS 관리형 키
• BAWS CloudHSM
• CAWS Secrets Manager
• DAmazon Inspector

문제 4

데이터베이스 비밀번호와 API 키를 코드에 하드코딩하지 않고 안전하게 보관하며, 주기적으로 자동 교체하려 한다. 가장 적합한 서비스는?

• AAWS KMS
• BAWS CloudHSM
• CAWS Secrets Manager
• DAWS WAF

문제 5

저장 시 암호화(encryption at rest)에 대한 설명으로 옳은 것은?

• A네트워크를 통해 전송되는 데이터를 보호한다
• B디스크나 스토리지에 저장된 데이터를 키 없이 읽지 못하게 보호한다
• CHTTPS 통신을 의미한다
• D오직 EC2에서만 사용할 수 있다